可靠事件模式
在可靠事件模式中，当我们尝试将订单和支付两个微服务进行分别管理的时候，需要找到一种媒介用于在这两个服务之间进行数据传递。一般而言，消息中间件（Message-Oriented Middleware，MOM）适合扮演数据传递媒介的角色。
在正常情况下，该流程能够满足业务需求。但我们仔细分析整个过程，不难发现可能存在如下问题：
某个服务在更新了业务实体后发布消息失败；
虽然服务发布事件成功，但是消息中间件未能正确推送事件到订阅的服务；
接受事件的服务重复消费事件。
重复消费场景，一般的处理方法是由业务代码控制幂等性。例如，在支付服务中传入一个订单时，可以通过判断该订单所对应的唯一Id 是否已经处理的方式避免对其再次处理。而前两个问题概括起来就是要解决消息传递的可靠性问题，这是通过可靠事件模式实现数据最终一致性的关键点，也是该模式的名称由来。
可靠事件模式对以上场景的解决方案就是使用一个本地事件表。
微服务在进行业务操作时需要将业务数据和事件保存在同一个本地事务中，由本地事务保证更新业务和发布事件的原子性。发布的事件被保存在本地事件表中，然后该服务实时发布一个事件通知关联的业务服务，如果事件发布成功则立即删除本地事件表中的事件。
实现策略
事件生产者，事件消费者，事件服务。
事件服务由以下三个组件构成：
事件确认组件
事件确认表现为一种定时机制，用于处理事件没有被成功发送的场景。
事件恢复组件
事件恢复组件同样是一种定时机制，根据本地事件表中的事件状态，专门处理状态为已确认但还没有被成功消费且已超时的事件。
实时消息传递组件
基于特定的消息中间件工具和框架将事件作为消息进行发送的组件。
补偿模式
补偿模式（Compensation Pattern）的基本思路在于使用一个额外的补偿服务来协调各个需要保证一致性的微服务，补偿服务按顺序依次调用各个微服务，如果某个微服务调用失败就撤销之前所有已经完成的微服务。在这个过程中，补偿服务对需要保证一致性的微服务提供补偿操作。
对于补偿服务而言，所有微服务的操作记录是一个关键点，因为操作记录是执行取消操作的前提。实现补充模式的关键要素是记录完整的业务流水，可以通过业务流水的状态来确定需要补偿的步骤，同时业务流水为补偿操作提供需要的业务数据。
补偿服务作为一个服务调用过程同样存在调用不成功的情况。这个时候需要通过一定的健壮性机制来保证补偿的成功率，也就是说补偿服务的相关操作本身就应该具备幂等性。
