消息队列简单概念

消息队列要满足以下特性

• 消息的可靠传递：确保不会丢失消息.
• Cluster: 支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不可以丢失消息.
• 性能：具备足够好的性能，能满足大多数性能要求.

常用的消息队列

• rabbitMQ:
• rocketMQ:
• Kafka:

队列、主题、分区

• 队列先进先出 严格有序
  

• 消费者之间实际上是竞争关系，如果要求每个消费者都能收到全量的消息.如对于一份订单数据，需要优惠卷系统，商品系统都接收到消息，就不能满足要求，一个可行的就是为每个消费者都创建一个队列.但是同样一份数据复制到生产中会造成浪费，而且生产者必须知道有多少个消费者，这违背了解耦设计的初衷，于是有了发布-订阅模型

• 消息的发送方被称为发布者，消息的接收方被称为订阅者，存储消息的容器被称为主题，和上面没有本质区别，有的区别是一份消息能不能被消费多次的问题，大多数的消息模型都是基于发布订阅模型，也有少数例外

消息模型

• rabbitMQ: 队列模型，怎么实现上面的消费者之间的竞争关系，通过Exchange配置的交换机
  

• rocketMQ: 标准的发布订阅模型
  

• Kafaka：和上面一样，标准的发布订阅模型,唯一区别是Kafaka中的队列叫做分区,含义和功能并没有本质的区别.

消息队列中的事务

• 提到事务大多想到的是数据库，但是为什么消息队列也需要事务呢，消息队列中的事务主要解决生产者和消费者不一致的数据一致性问题，使用消息队列更加合理
  

• 对于订单来说，主要执行俩个操作

  1. 创建了订单
  2. 发送消息给消息队列，内容就是刚刚创建好的订单

• 在上面操作中，可能会存在

  1. 创建了订单，没有清理购物车
  2. 订单没有创建成功，购物车的商品被清掉了

• 需要解决的问题变为上述任意步骤都可能失败的情况下，还要确保订单库和购物车库的一致性

  1.对于购物车系统来说，失败了处理比较简单，只要执行购物车清理后在提交消息确认即可，如果失败，没有提交，消息会自动重试
  2.关键对于订单系统，创建和发送消息要么都成功，要么都失败，不允许一个成功一个失败的场景，这就是分布式事务要解决的问题

什么是分布式事务
*事务四个属性 ACID ,对于分布式事务严格的实现ACID基本是不可能的，在保证可用性和不严重牺牲性能的情况下，光实现数据一致性