1. 知识点以及应用场景
2. 常用消息队列场景
- 异步控制,例如电商场景中的下单成功后对用户其他日志的记录、发送短信、后续操作等,可以下单成功后立即返回成功信息,后续操作由消息队列慢慢消费
- 流量控制,流量爆发,可以通过消息队列进行削峰,不至于一下所有的请求都打到服务器,过多的线程可能会导致 死锁或直接宕机。后续还发展出来了令牌桶的概念,可以通过网关去获取令牌的操作控制流量
- 服务解耦,上下游服务如果依次调用、耦合度高,每次修改一个服务,都需要调试升级关联服务,
- 发布订阅模式的观察者模式场景
- 广播等
3. 消息队列的选择
几点硬性的需求
- 消息不会丢失、支持持久化
- 集群、可以横向扩展、高可用
- 性能
选型
- RabbitMQ(开箱即用易于维护)
- 特点
- Erlang语言编写
- AMQP 协议
- 特色的功能是支持非常灵活的路由配置
- 消息堆积的支持并不好,大量消息积压的时候,会导致 RabbitMQ 的性能急剧下降
- 消息模型
队列模型,通过Exchange来实现1-1或者1-多,主题模型
- 特点
- RocketMQ(在线业务、金融、稳定)
- 特点
- Java开发
- 社区活跃
- 响应时延毫秒级
- 消息模型
发布订阅(主题)、队列,发布确认、消费确认 否则重发,保证数据一定可以发布、一定可以消费,但是这样引入了一个问题,消息为了保证有序性,一条消息在消费完之前,之后的消息就没办法被消费,没有办法横向扩展
所以RocketMq引入了主题 + 消费组的概念,多个主题维护多个消费位置,多个消费组去消费不同主题的消息,每个消费组都会完整的消费一份主题中的消息,消费组重的消费者是竞争的关系
- 特点
- Kafuka(海量的消息、流计算、大数据)
- 特点
- 周边生态系统的兼容性是最好
- Scala 和 Java 语言开发
- 时延较高,有个缓冲的过程,可以处理超大规模数据
- 消息模型
与RocketMq一致,消费组、主题(这里叫分区),剩下的确认机制、发布订阅模型基本一致
- 特点
- ActiveMQ
- 社区较老
4. 分布式事务
- 2PC(Two-phase Commit,也叫二阶段提交)
- TCC(Try-Confirm-Cancel)
- 事务消息(异步更新数据、不要求实时性、要求数据一致性)
todo - 利用事务消息实现一个下单成功、购物车清空商品的事务程序
git地址:https://github.com/lyflyy/servicecomb_rocketmq.git