分布式事务原理

RabbtiMQ

过程：
RabbitMQ 分为：生产者，消费者，Broker中心。
生产者：
1.生产者和Broker建立连接，建立Channel通道
2.生成者发送消息到MQ，即到Broker中心（交换机+队列）
3.交换机将消息发到指定的队列上
消费者：
1.消费者和Broker建立连接，建立Channel通道
2.消费者监听指定的队列
3.队列上有消息，则把消息发送到消费者

RabbitMQ类型

1.默认交换机类型

 - 简单模式：使用默认交换机，1对1
 - 工作模式：使用默认交换机，多个消费者监听同一队列，只有1个消费者可以消费。

2.订阅模式
交换机类型为：faout类型。交换机会把消息复制到绑定的队列上
3.路由模式
交换机类型为：direct类型。交换机会根据key,把消息发送到指定队列上。
4.主题模式
交换机类型为:topic类型。交换机可以将key 绑定到表达式的一个范围的队列上。

分布式事务

概念：一个应用系统需要拆分成两个子系统，其中一个系统对应一个库，此时也需要用到分布式事务。

本地消息表保证分布式事务

可靠消息保证分布式事务一致性。即：保证生产者不丢失消息，保证MQ不丢失消息（持久化磁盘），保证消费者一定消费消息。

生产者

1.执行下单操作，将插入订单和插入本地消息表作为一个事务进行提交。
2.启动独立的线程，Spring Task定时对本地消息表中的消息进行扫描并发送至MQ，在消息中间件反馈发送成功后删除该消息日志，否则等待定时任务下一周期重试。
**注意：**通过生产者确认机制Confirm实现。RabbitMQ中的生产者确认功能是AMQP规范的增强功能，当生产者的消息已经成功路由，或者消息被放入队列（消息队列持久化时），一个Basic.Ack请求会被发送到生产者，如果消息无法路由，代理服务器将发送一个Basic.Nack RPC请求用于表示失败。

MQ 持久化

1.delivery_mode=2，持久化消息
2.持久化消息队列到磁盘
当发送的消息被持久化磁盘后，会给生产者发送Ack,此时将该消息的本地消息表的删除。

消费者

关闭自动Ack,在确保消息被处理完，事务提交后，然后再代码里手动调用Ack。若MQ收不到Ack,会一直重发送消息。同时消费者要保证幂等性。并且若重发到一定次数，可以将消息放到死信丢列中，并进行人工报警。

幂等性如何保证的？

1.幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的。
2.实现方式？
1）使用数据库的全局唯一索引，建表的时候，设置某个字段为唯一索引，这样就可以避免重复插入的问题。但是数据库层面压力很大。
2）使用 redis 等实现分布式锁，这样就可以在插入的时候持有这个锁，插入完成之后再去释放这个锁。

死信队列

1.何时进入死信队列

• 消息被否定确认，使用 channel.basicNack 或 channel.basicReject ，并且此时requeue
  属性被设置为false。
• 消息在队列的存活时间超过设置的TTL时间。
• 消息队列的消息数量已经超过最大队列长度
  2.如何使用？
  死信队列，也是一个普通的交换机。启动一个线程，监控消费者的系统是否恢复，若恢复正常，则线程就处理死信队列的订单，进行重新消费。

延迟队列

1.什么是延迟队列？
延时队列，最重要的特性就体现在它的延时属性上，跟普通的队列不一样的是，普通队列中的元素总是等着希望被早点取出处理，而延时队列中的元素则是希望被在指定时间得到取出和处理，所以延时队列中的元素是都是带时间属性的，通常来说是需要被处理的消息或者任务。
2.如何实现？
ttl：过期时间。可以设置队列的过期时间，或者消息的过期时间。若两者同时出现，取最小值。
1）根据需要延时时间的不同，利用不同的routingkey将消息路由到不同的延时队列，每个队列都设置了不同的TTL属性，并绑定在同一个死信交换机中，消息过期后，根据routingkey的不同，又会被路由到不同的死信队列中，消费者只需要监听对应的死信队列进行处理即可。

2）可以使用一个RabbitMQ的插件，在消息粒度上添加TTL，并使其在设置的TTL时间及时死亡。更加灵活。
3）定期轮询（数据库等）亦可以，作为一个扩展。