RabbitMQ(一)之工作模式、生產者消息確認機制

1、work queues 工作隊列模式

工作隊列模式是多個消費者同時消費同一個隊列中的數據,默認情況下,MQ會把所有請求平均發送給每一個消費者。可以設置處理完成后在獲取下一條。channel.basicQos(1),消費者偽代碼如下:

        //獲取TCP長連接
        Connection conn = RabbitUtils.getConnection();
        //創建通信“通道”,相當于TCP中的虛擬連接
        Channel channel = conn.createChannel();

        //創建隊列,聲明并創建一個隊列,如果隊列已存在,則使用這個隊列
        //第一個參數:隊列名稱ID
        //第二個參數:是否持久化,false對應不持久化數據,MQ停掉數據就會丟失
        //第三個參數:是否隊列私有化,false則代表所有消費者都可以訪問,true代表只有第一次擁有它的消費者才能一直使用,其他消費者不讓訪問
        //第四個:是否自動刪除,false代表連接停掉后不自動刪除掉這個隊列
        //其他額外的參數, null
        channel.queueDeclare("rabbit-sms",false, false, false, null);
        //如果不寫basicQos(1),則自動MQ會將所有請求平均發送給所有消費者
        //basicQos,MQ不再對消費者一次發送多個請求,而是消費者處理完一個消息后(確認后),在從隊列中獲取一個新的
        channel.basicQos(1);//處理完一個取一個
        channel.basicConsume(RabbitConstant.QUEUE_SMS , false , new DefaultConsumer(channel){
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
                String jsonSMS = new String(body);
                System.out.println("短信發送成功:" + jsonSMS);
                //false只確認簽收當前的消息,設置為true的時候則代表簽收該消費者所有未簽收的消息
                channel.basicAck(envelope.getDeliveryTag() , false);
            }
        });

2、Pub、Sub 發布訂閱模式

后面的模式會使用到交換機(Exchange),交換機是接收生產者發送的消息,在根據Exchange類型不同區別發送到消費者,或者將消息丟棄,Exchange只負責轉發消息,不具備存儲消息的能力。因此如果沒有任何隊列與Exchange綁定,或者沒有符合路由規則的隊列,那么消息會丟失

Exchange類型:

Fanout:廣播,將消息發送給所有綁定到交換機的隊列
Direct:定向,把消息發送給符合指定routingkey的隊列
Topic:通配符,把消息發送給符合routing pattern(路由模式)的隊列

發布訂閱模式是所有消費者獲得的消息相同。與工作隊列模式不同的是,生產者和消費者需要綁定到同一個交換機上。工作隊列模式不需要設置交換機(實際上,底層也會實用一個默認的交換機)。

生產者偽代碼:

        Connection connection = RabbitUtils.getConnection();
        Channel channel = connection.createChannel();
        channel.basicPublish("交換機名稱","" , null , "需要發送的內容".getBytes());
        channel.close();
        connection.close();

消費者偽代碼:

        Connection connection = RabbitUtils.getConnection();
        final Channel channel = connection.createChannel();
        channel.queueDeclare(RabbitConstant.QUEUE_BAIDU, false, false, false, null);

        //queueBind用于將隊列與交換機綁定
        channel.queueBind("自己的隊列名", "交換機名稱", "路由key(暫時用不到)");
        channel.basicQos(1);
        channel.basicConsume(RabbitConstant.QUEUE_BAIDU , false , new DefaultConsumer(channel){
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
                System.out.println("訂閱到的信息:" + new String(body));
                channel.basicAck(envelope.getDeliveryTag() , false);
            }
        });

3、Routing 路由模式

隊列與交換機的綁定需要制定一個RoutingKey(路由的key),消息發送方在向交換機(Exchange)發送消息時,也必須指定RoutingKey,Exchange不在把消息發送給每一個綁定的隊列,而是根據消息的RoutingKey進行判斷,只有綁定隊列的RoutingKey與生產消息的RoutingKey完全一致才會收到消息。RoutingKey可以綁定多個。

生產者偽代碼:

        //省略了創建連接和關閉連接的代碼
        channel.basicPublish("交換機的名稱","所要發送到哪個RoutingKey(RoutingKey1、RoutingKey2)" , null , "需要發送的內容");

消費者偽代碼:

        //省略了創建連接的代碼
        channel.queueDeclare("隊列名稱", false, false, false, null);
        //queueBind用于將隊列與交換機綁定
        //參數1:隊列名 參數2:交互機名  參數三:路由key
        channel.queueBind("隊列名稱", "Exchange  Name", "RoutingKey1");
        channel.queueBind("隊列名稱", "Exchange  Name", "RoutingKey2");
        channel.basicQos(1);
        channel.basicConsume("隊列名稱" , false , new DefaultConsumer(channel){
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
                System.out.println("接受到的信息:" + new String(body));
                channel.basicAck(envelope.getDeliveryTag() , false);
            }
        });

4、Topic 通配符模式

Topic模式與Routing模式工作類似,Topic模式的Exchange可以讓隊列在綁定RoutingKey的時候使用通配符,RoutingKey一般是用一個或者多個單詞組成,例如:order.type1.pay、order.type2.pay。

通配符規則: #表示匹配一個或者多個詞,只能匹配一個詞。例如:order.#可以匹配上述兩個key,order.就不能匹配到,order.type1.*就可以匹配到order.type1.pay。

Topic模式下的發布者與Routing模式下的相同。只是消費者有所區別

消費者偽代碼如下:

//省略了創建鏈接的代碼
//RourtingKey可以使用通配符進行匹配。order.#可以匹配到order.type1.pay、order.type2.pay,多個路由
channel.queueBind("隊列名稱", "Exchange Name", "order.#");

5、RabbitMQ的消息確認機制

RabbitMQ提供了一個監聽器(Listener)來接收消息的投遞狀態,消息確認涉及到兩種狀態,Confirm和Return:

Confirm代表生產者將消息送到Broker時產生的狀態,包括:ack代表Broker已經將數據接收成功,nack代表Broker拒收消息。原因可能有很多種,如隊列已滿、限流、IO異常等等。

Return代表消息已經被Broker正常接收,消息已經ack,但Broker沒有對應的隊列進行投遞時,產生的狀態,消息將被退回給生產者。

上述兩種狀態只代表生產者與Broker之間的消息投遞情況,與消費者是否接收和確認無關

        //省略了創建連接的代碼
        //開啟confirm監聽模式
        channel.confirmSelect();
        //Confirm
        channel.addConfirmListener(new ConfirmListener() {
            public void handleAck(long l, boolean b) throws IOException {
                //第二個參數代表接收的數據是否為批量接收,一般我們用不到。
                System.out.println("消息已被Broker接收,Tag:" + l );
            }
            public void handleNack(long l, boolean b) throws IOException {
                System.out.println("消息已被Broker拒收,Tag:" + l);
            }
        });
        //Return
       channel.addReturnListener(new ReturnCallback() {
            public void handle(Return r) {
                System.err.println("===========================");
                System.err.println("Return編碼:" + r.getReplyCode() + "-Return描述:" + r.getReplyText());
                System.err.println("交換機:" + r.getExchange() + "-路由key:" + r.getRoutingKey() );
                System.err.println("Return主題:" + new String(r.getBody()));
                System.err.println("===========================");
            }
        });
        //次處省略了發送消息的相關代碼
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,406評論 6 538
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,034評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,413評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,449評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,165評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,559評論 1 325
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,606評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,781評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,327評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,084評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,278評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,849評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,495評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,927評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,172評論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,010評論 3 396
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,241評論 2 375

推薦閱讀更多精彩內容