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