Rabbit MQ

http://mini.eastday.com/a/160602082336272.html

 

消息中间件要解决的问题

Publis/Subscribe

保证

Message Priority

支持优先级

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-priority

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?

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)

there is no way to guarantee a priori that messages are answered in order with multiple consumers. But RabbitMQ will make a best-effort.

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

http://fengchj.com/?p=2273

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 消费消息失败通常可以认为 有以下几种情况

1. 由于消息本身的原因,例如反序列化失败,消息数据本身无法处理(例如话费充值,当前消息的手机号被注销,无法充值)等。这种错误通常需要跳过这条消息,再消费其他消息,而这条失败的消息即使立刻重试消费,99%也不成功,所以最好提供一种定时重试机制,即过 10s 秒后再重试。

2. 由于依赖的下游应用服务不可用,例如 db 连接不可用,外系统网络不可达等。 遇到这种错误,即使跳过当前失败的消息,消费其他消息同样也会报错。这种情况建议应用 sleep 30s,再 消费下一条消息,这样可以减轻 Broker 重试消息的压力。