背景
- 互联网应用拆分为微服务、解决各个微服务模块的互相通信问题、并能够提供大流量技术支撑
{———-}
应用场景
- 微服务之间的通信问题
- 具体的业务场景有很多、比如、支付完成后的订单状态修改、用户充值后的vip等级提升、物流信息等等
- 各个微服务之间的消息、业务场景有：按实时性可分为实时消息、非实时消息；
组成部件
- rocketmq 有两个部件 nameserver：服务管理中心、broker：消息存储中心
- nameserver管理业务服务注册、保证服务稳定运行
- broker负责消息的持久化、保证消息不丢失
解决问题
- 应用解耦
- 替换应用上的https协议、又能保证服务之间的动态性
- 流量削峰
- 非即时消息、延后处理
- 消息分发
- 消息生产者只负责消息生产、消息消费者只负责消息消费、只管把消息发到消息队列、而不关心、哪台服务消费这个消息
- 消息轮询消费、不会造成只在某一台机器上消费、压跨服务器
- 保证分布式事务的最终一致性
- 动态扩容
发展
- 目前已是apache的顶级项目、
- 2017年双十一的主要驱动力、处理消息万亿级别、tps:5600万
- java语言开发、对java开发者亲和度较高
技术选型
rocketmq、rabbitmq、kafka
- 没有谁好谁坏
- kafka起源最早、解决消息流处理问题、最早解决监控平台对各个服务模块的消息监控、
- rabbitmq、采用AMQP协议开发、建立了最早的消息模型、定义了消息驱动模式、
- rocketmq、类似于kafka、不过语言是java、经历了阿里的双十一足以证明它的性能。
个人见解
- 吞吐量优先、消息丢失小事、选择kafka、kafka的吞吐量要强一个量级
- 稳定不丢消息：rocketmq、tabbitmq、
- rabbitmq底层是erlang语言、erlang语言特性、并发性能优秀、
- rocketmq底层netty、异步机制优秀
- 实时性要求高、同时又要求高的吞吐量 rabbitmq
- 非实时性要求高、同时又要求高吞吐量 rocketmq
