http://mini.eastday.com/a/160602082336272.html
消息中間件要解決的問題
Publis/Subscribe
保證html
Message Priority
支持優先級ios
As of RabbitMQ 3.5.0, there is now in-core support for AMQP standard per-message priorities.網絡
http://stackoverflow.com/questions/10745084/rabbitmq-and-message-priorityapp
Message Ordering
能夠保證有序異步
Section 4.7 of the AMQP 0-9-1 core specification explains the conditions under which ordering is guaranteed: messages published in one channel, passing through one exchange and one queue and one outgoing channel will be received in the same order that they were sent. RabbitMQ offers stronger guarantees since release 2.7.0.分佈式
So can anyone help me out and point me to the right doc or example that shows whether it is guaranteed or not?post
http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-Message-Sequence-Guarantee-td34102.html性能
Messages can be returned to the queue using AMQP methods that feature a requeue parameter (basic.recover, basic.reject and basic.nack), or due to a channel closing while holding unacknowledged messages. Any of these scenarios caused messages to be requeued at the back of the queue for RabbitMQ releases earlier than 2.7.0. From RabbitMQ release 2.7.0, messages are always held in the queue in publication order, even in the presence of requeueing or channel closure. (emphasis added)fetch
there is no way to guarantee a priori that messages are answered in order with multiple consumers. But RabbitMQ will make a best-effort.spa
http://stackoverflow.com/questions/21363302/rabbitmq-message-order-of-delivery
RabbitMq 在只有一個consumer的狀況下，是能夠保證徹底有序的，即便出現reinqueue操做。 若是有多個consumer狀況下，是沒法保證嚴格一致。
RabbitMQ Message Sequence Guarantee http://stackoverflow.com/questions/22387275/rabbitmq-message-sequence-guarantee
Message Filter
rabbitmq 自然支持
Message Persistence
磁盤化持久化
Message Reliablity
(1). Broker 正常關閉 (2). Broker 異常 Crash (3). OS Crash (4). 機器掉電,可是能當即恢復供電狀況。 (5). 機器沒法開機(多是cpu、主板、內存等關鍵設備損壞) (6). 磁盤設備損壞。
(1)、(2)、(3)、(4)四種狀況都屬於硬件資源可當即恢復狀況,RocketMQ 在這四種狀況下能保證消息不丟,或 者丟失少許數據(依賴刷盤方式是同步仍是異步)。 (5)、(6)屬於單點故障,且沒法恢復,一旦發生,在此單點上的消息所有丟失。RocketMQ 在這兩種狀況下,通 過異步複製,可保證 99%的消息不丟,可是仍然會有極少許的消息可能丟失。經過同步雙寫技術能夠徹底避免單點, 同步雙寫勢必會影響性能,適合對消息可靠性要求極高的場合,例如與 Money 相關的應用。
Publisher Confirms and Transactions Mirrored queues support both Publisher Confirms and Transactions. The semantics chosen are that in the case of both confirms and transactions, the action spans all mirrors of the queue. So in the case of a transaction, a tx.commit-ok will only be returned to a client when the transaction has been applied across all mirrors of the queue. Equally, in the case of publisher confirms, a message will only be confirmed to the publisher when it has been accepted by all of the mirrors. It is correct to think of the semantics as being the same as a message being routed to multiple normal queues, and of a transaction with publications within that similarly are routed to multiple queues.
https://www.rabbitmq.com/ha.html
從這裏來看，Rabbitmq的confirm或T事務是能夠保證 不丟數據的。
http://blog.csdn.net/zyz511919766/article/details/41896823
Low Latency Messaging
採用的是pull模型
The AMQP 0-9-1 Model has the following view of the world: messages are published to exchanges, which are often compared to post offices or mailboxes. Exchanges then distribute message copies to queues using rules called bindings. Then AMQP brokers either deliver messages to consumers subscribed to queues, or consumers fetch/pull messages from queues on demand.
https://www.rabbitmq.com/tutorials/amqp-concepts.html
At least Once
知足
Exactly Only Once
rabbitmq也不支持。
- (1). 發送消息階段,不容許發送重複的消息。
- (2). 消費消息階段,不容許消費重複的消息。
只有以上兩個條件都知足狀況下,才能認爲消息是「Exactly Only Once」,而要實現以上兩點,在分佈式系統環境下,不可避免要產生巨大的開銷。因此 RocketMQ 爲了追求高性能,並不保證此特性,要求在業務上進行去重, 也就是說消費消息要作到冪等性。RocketMQ 雖然不能嚴格保證不重複,可是正常狀況下不多會出現重複發送、消 費狀況,只有網絡異常,Consumer 啓停等異常狀況下會出現消息重複。
此問題的本質緣由是網絡調用存在不肯定性,即既不成功也不失敗的第三種狀態,因此才產生了消息重複性問 題。
Broker的Buffer滿了怎麼辦?
磁盤存儲，問題不大
回溯消費
無此功能。所以Rabbitmq沒有在中心節點永久存儲數據，消費完後就會被刪除掉了。
消息堆積
評估消息堆積能力主要有如下四點:
- (1). 消息能堆積多少條,多少字節?即消息的堆積容量。
- (2). 消息堆積後,發消息的吞吐量大小,是否會受堆積影響?
- (3). 消息堆積後,正常消費的Consumer是否會受影響?
- (4). 消息堆積後,訪問堆積在磁盤的消息時,吞吐量有多大?
分佈式事務
支持
定時消息
不支持，可是能夠改造
消息重試
Consumer 消費消息失敗後,要提供一種重試機制,令消息再消費一次。Consumer 消費消息失敗一般能夠認爲 有如下幾種狀況
-
因爲消息自己的緣由,例如反序列化失敗,消息數據自己沒法處理(例如話費充值,當前消息的手機號被註銷,沒法充值)等。這種錯誤一般須要跳過這條消息,再消費其餘消息,而這條失敗的消息即便馬上重試消費,99%也不成功,因此最好提供一種定時重試機制,即過 10s 秒後再重試。
-
因爲依賴的下游應用服務不可用,例如 db 鏈接不可用,外系統網絡不可達等。 遇到這種錯誤,即便跳過當前失敗的消息,消費其餘消息一樣也會報錯。這種狀況建議應用 sleep 30s,再 消費下一條消息,這樣能夠減輕 Broker 重試消息的壓力。