消息队列初探

1. 知识点以及应用场景

2. 常用消息队列场景

1. 异步控制，例如电商场景中的下单成功后对用户其他日志的记录、发送短信、后续操作等，可以下单成功后立即返回成功信息，后续操作由消息队列慢慢消费
2. 流量控制，流量爆发，可以通过消息队列进行削峰，不至于一下所有的请求都打到服务器，过多的线程可能会导致 死锁或直接宕机。后续还发展出来了令牌桶的概念，可以通过网关去获取令牌的操作控制流量
3. 服务解耦，上下游服务如果依次调用、耦合度高，每次修改一个服务，都需要调试升级关联服务，
4. 发布订阅模式的观察者模式场景
5. 广播等

3. 消息队列的选择

几点硬性的需求

1. 消息不会丢失、支持持久化
2. 集群、可以横向扩展、高可用
3. 性能

选型

1. RabbitMQ（开箱即用易于维护）
   1. 特点
      1. Erlang语言编写
      2. AMQP 协议
      3. 特色的功能是支持非常灵活的路由配置
      4. 消息堆积的支持并不好，大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降
   2. 消息模型
      队列模型，通过Exchange来实现1-1或者1-多，主题模型
2. RocketMQ（在线业务、金融、稳定）
   1. 特点
      1. Java开发
      2. 社区活跃
      3. 响应时延毫秒级
   2. 消息模型
      发布订阅（主题）、队列，发布确认、消费确认 否则重发，保证数据一定可以发布、一定可以消费，但是这样引入了一个问题，消息为了保证有序性，一条消息在消费完之前，之后的消息就没办法被消费，没有办法横向扩展
      所以RocketMq引入了主题 + 消费组的概念，多个主题维护多个消费位置，多个消费组去消费不同主题的消息，每个消费组都会完整的消费一份主题中的消息，消费组重的消费者是竞争的关系
3. Kafuka（海量的消息、流计算、大数据）
   1. 特点
      1. 周边生态系统的兼容性是最好
      2. Scala 和 Java 语言开发
      3. 时延较高，有个缓冲的过程，可以处理超大规模数据
   2. 消息模型
      与RocketMq一致，消费组、主题（这里叫分区），剩下的确认机制、发布订阅模型基本一致
4. ActiveMQ
   1. 社区较老

4. 分布式事务

1. 2PC（Two-phase Commit，也叫二阶段提交）
2. TCC(Try-Confirm-Cancel)
3. 事务消息（异步更新数据、不要求实时性、要求数据一致性）
   

todo - 利用事务消息实现一个下单成功、购物车清空商品的事务程序
git地址：https://github.com/lyflyy/servicecomb_rocketmq.git