前兩天看了看一下消息隊列——RabbitMQ，從配置到使用，說說消息隊列MQ的工作機制.
使用者再指定隊列内發送消息，消息會被發送到消息隊列伺服器（如果是本地，則為127.0.0.1）的交換機上，緩存到broker上，交換機會根據指定的路由的key來比對所要消費的隊列 而消費監聽器在不斷拉取或者消息路由器推送要消費的消息，如果消息消費完成，确認消息，進而broker上再删除該消息；如果抛異常了，重試消費，到達設定的門檻值之後還未消費成功，則進入了死信隊列，是以在監聽消費者隊列中，大都需要建立一個死信隊列，用來對消費失敗或者隊列不存在的消息進行重新路由消費（在1000并發下[jmeter]消費速度明顯比rocketmq慢【可能跟硬體有關】）。
RocketMQ是用java語言開發的一款消息隊列，之前金融的項目中用到了這款消息隊列。流程大緻是先發送消息，然後記錄該消息的狀态，如果消息沒有消費，重新發送至消費方讓其消費，消費完成之後再确認消息。其實原理大緻都一樣，如果使用者選擇的是Topic（也就是訂閱/釋出），broker會比對目前訂閱的topic[主題]（消息隊列的組，比如訂單topic，支付topic 等都分開路由）以及指定的隊列比對規則(rabbitmq為 queue.# [表示發送到該隊列下的所有key都在這個隊列下消費]、RocketMQ為shardingKey[會先根據topic分組，然後再根據tag【子标簽】進行分類，比如充值，下單都訂閱的支付的topic，但其tag可為recharge_tag,invest_tag，最後用shardingkey來對消息進行排序路由，天然支援順序消費，金融類用的較多]），在使用rocketmq，發送消息之前需要對消息防重複crc32校驗并序列化到硬碟（mysql/redis/等等***/），防止重複發送同一消息導緻失去了幂等性，再消費完成消息之後再進行确認消息（rocketmq丢失消息率幾乎為0，消息堆積能力非常高，可在配置檔案中配置多個屬性）。