常见消息队列对比分析
消息系统分类
Peer-to-Peer
- 基于Pull或者Polling接收消息
- 发送到队列中的消息被一个而且仅仅一个接受者所接收，即使有多个接收者在同一个队列中侦听同一消息
- 支持异步“即发即弃”的消息传送方式（发送后没接收就丢弃），也支持同步请求/应答传送方式（发送了之后必须收到才发下一个）
发布/订阅
- 发布到一个主题（Topic）的消息，可被多个订阅者所接收发布/订阅
- 可基于Push消费数据，也可以基于Pull或者Polling
- 数据解耦能力比P2P模型要强
根据实际的需求选择适当的消息系统方式，是希望共享，还是独享数据
消息系统使用场景
- 解耦：各个系统之间通过消息系统这个统一的接口交换数据，无须了解彼此的存在，避免强依赖
- 冗余：部分消息系统具有消息持久化能力，可规避消息处理前丢失的风险
- 扩展：消息系统是统一的数据接口，各系统可独立扩展
- 峰值处理能力：消息系统可顶住峰值流量，业务系统可根据处理能力从消息系统中获取并处理对应量的请求
- 可恢复性：某个系统中部分组件失效并不会影响整个系统，恢复后仍然可从消息系统中获取并处理数据
- 异步通信：在不需要立即处理请求的场景下，可以将请求放入消息系统，合适的时候再处理
常用消息系统对比
| Kafka | RabbitMQ | ActiveMQ | Redis | |
| 消息回溯 | 支持，无论是否被消费都会保留，可设置策略进行过滤删除（基于消息超时或消息大小） | 不支持，一旦被确认消费就会标记删除 | 不支持 | 可设置消息过期时间，自动过期 |
| API完备性 | 高 | 高 | 中 | 高 |
| 单机吞吐量 | 十万级 | 万级 | 万级 | 十万级 |
| 首次部署难度 | 中 | 低 | 低 | 低 |
| 消息堆积 | 支持 | 支持（内存堆积达到特定阈值可能会影响性能） | 支持（有上线，当消息过期或存储设备溢出时，会终结它） | 支持（有上线，服务器容量不够会容易崩溃造成数据丢失） |
| 消息持久化（数据持久化到硬盘） | 支持 | 支持 | 不支持 | 支持 |
| 多语言支持 | 支持，Java优先 | 语言无关 | 支持，Java优先 | 支持 |
| 消息优先级设置（某些消息被优先处理） | 不支持 | 支持 | 支持 | 支持 |
| 消息延迟（消息被发送之后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费） | 不支持 | 支持 | 支持 | 支持 |
| 消费模式（①推模式：由消息中间件主动地将消息推送给消费者；②拉模式：由消费者主动向消息中间件拉取消息） | 拉模式 | 推模式+拉模式 | 推模式+拉模式 | 拉模式 |
| 消息追溯 | 不支持 | 支持（有插件，可进行界面管理） | 支持（可进行界面管理） | 支持 |
| 常用场景 | 日志处理、大数据等 | 金融支持机构 | 降低服务之间的耦合 | 共享Cache、共享Session |
| 运维管理 | 有多种插件可进行监控，如Kafka Management | 有多种插件可进行监控，如rabbitmq_management(不利于做二次开发和维护） | 无 | 有多种插件可进行监控，如zabbix |