kafka01 与其他消息系统对比

消息系统分类

Peer-to-Peer
基于Pull或者Polling接收消息
发送到队列中的消息被一个而且仅仅一个接受者所接收，即使有多个接收者在同一个队列中侦听同一消息
支持异步“即发即弃”的消息传送方式（发送后没接收就丢弃），也支持同步请求/应答传送方式（发送了之后必须收到才发下一个）

发布/订阅
发布到一个主题（Topic）的消息，可被多个订阅者所接收发布/订阅
可基于Push消费数据，也可以基于Pull或者Polling
数据解耦能力比P2P模型要强

对比

	Kafka	RabbitMQ	ActiveMQ	Redis
消息回溯	支持，无论是否被消费都会保留，可设置策略进行过滤删除（基于消息超时或消息大小）	不支持，一旦被确认消费就会标记删除	不支持	可设置消息过期时间，自动过期
API完备性	高	高	中	高
单机吞吐量	十万级	万级	万级	十万级
首次部署难度	中	低	低	低
消息堆积	支持	支持（内存堆积达到特定阈值可能会影响性能）	支持（有上线，当消息过期或存储设备溢出时，会终结它）	支持（有上线，服务器容量不够会容易崩溃造成数据丢失）
消息持久化（数据持久化到硬盘）	支持	支持	不支持	支持
多语言支持	支持，Java优先	语言无关	支持，Java优先	支持
消息优先级设置（某些消息被优先处理）	不支持	支持	支持	支持
消息延迟（消息被发送之后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费）	不支持	支持	支持	支持
消费模式（①推模式：由消息中间件主动地将消息推送给消费者；②拉模式：由消费者主动向消息中间件拉取消息）	拉模式	推模式+拉模式	推模式+拉模式	拉模式
消息追溯	不支持	支持（有插件，可进行界面管理）	支持（可进行界面管理）	支持
常用场景	日志处理、大数据等	金融支持机构	降低服务之间的耦合	共享Cache、共享Session
运维管理	有多种插件可进行监控，如Kafka Management	有多种插件可进行监控，如rabbitmq_management(不利于做二次开发和维护）	无	有多种插件可进行监控，如zabbix