消息中间件的作用：
-
系统解耦
多系统直接相互调用
失败重试机制
例如：订单和财务信息就可以使用 mq 异步处理 使订单和财务系统之间进行解耦，如果财务系统有任何异常就不会影响用户的正常下单 -
填谷削峰
某时间数据量剧增的情况
MQ 主要解决瞬时写压力大于应用服务能力导致信息丢失、系统奔溃等问题 -
异步调用
不要求系统之间同步反馈结果，也能保证数据的最终一致性。 -
压测测试
线上有些链路不好压测，可以通过堆积一定量消息再放开来压测 这也是压力测试的一种手段
提升性能
当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统 -
降低系统的可用性
提高系统的复杂度
我们应该注意什么问题呢？
-
降低系统的可用性
-
提高系统的复杂度
-
需要保证数据的最终一致性
| 功能项 | Kafka | RabbitMQ | RocketMQ | Pulsar(研究中) |
|---|---|---|---|---|
| 优先级队列 | 不支持 | 支持，建议优先级大小设置在0-10之间 | 支持，维护不同的优先级队列，根据message的优先级发送到对于的队列中 | - |
| 延迟队列 | 不支持 | 支持 | 支持 | - |
| 死信队列 | 不支持 | 支持 | 支持 | - |
| 重试队列 | 不支持 | 支持 | 支持 | - |
| 消费模式 | pull拉模式 | pull + push | pull+长轮询 | - |
| 广播消费 | 支持，kafka对于广播消息的支持更加正统 | 支持 | 支持 | - |
| 批量消息 | 支持，生产者异步发送 | 支持 | 支持，生产者同步发送 | - |
| 消息回溯 | 支持.Kakfa支持按照offset和timestam两种维度进行消息回溯 | 不支持，一旦被确认消费就会被删除 | 支持 | - |
| 消息堆积 | 支持，海量消息堆积，堆积能力和磁盘大小挂钩 | 支持，但是内存达到阀值时，性能会受影响 | 支持海量消息堆积 | - |
| 持久化方式 | 消息队列，segment方式 | 支持 | 消息队列 | - |
| 消息追踪 | 不支持。消息追踪可以通过外部系统来支持，但是支持粒度没有内置的细腻。 | 支持 | 支持 | - |
| 消息过滤 | 客户端级别的支持，可用过kafka stream进行消息过滤 | 不支持，二次封装较简单 | 支持，可通过message tag、属性进行过滤 | - |
| 多租户 | 不支持 | 支持 | 不支持 | 支持 |
| 多协议支持 | 只支持定义协议，目前几个主流版本之间存在兼容性问题 | AMQP | JMS ，OpenMessaging | - |
| 跨语言支持 | 当前版本采用Java编写，支持多种语言的客户端 | 采用Erlang编写，支持多种语言客户端 | Java, C++, Go | - |
| 流量控制 | 支持client和user级别，通过主动设置可将流控作用于生产者或消费者 | 流量控制基于credit-base算法，是内部被动触发的保护机制，作用于生产者层面 | RocketMQ提供了针对于不同维度的流量控制 | - |
| 消息顺序性 | 支持普通的顺序消息，即对于单个分区的消息发送和消费是有序的，但是不保证不重复 | 顺序性的条件比较苛刻，需要单线程发送，单线程消费并且不采用延迟队列、优先级队列等一些高级功能，从某种意义上来书不支持顺序性 | 支持普通的顺序消息和严格的顺序消息 | - |
| 幂等性 | 支持单个Producer单个分区的会话幂等性 | 不支持 | 不支持，不解决消息的重复问题 | - |
| 事务性消息 | 最新版支持事务消息 | 支持 | 最新版的metaq支持事务消息 | - |
| 性能 | 最高 | 高 | 高 | - |
| 高可用和容错 | 使用partition的副本机制和isr选举机制保证高可用 | 普通集群非高可用，可用镜像模式和主备集群 | 通过broker的master和slave实现高可用 | - |
| 幂等性 | 支持单个Producer单个分区的会话幂等性 | 不支持 | 不支持，不解决消息的重复问题 | - |
| 定时消息 | 不支持 | 支持 | 支持 | - |
| 负载均衡 | 客户端消费者负载均衡，需要一个broker作为coordinator | 默认是轮询 | 客户端负载均衡，支持平均和轮询分配 | - |
| 刷盘策略 | 默认是异步刷盘 | 默认是内存存储 | 默认同步刷盘 | - |
