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 重试消息的压力。