标签：持久化   cap   幂等性   轻量   锁定   消费   成功   mic   重新投递   

柔性事务解决方案架构

在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。柔性事务有两个特性：基本可用和柔性状态。所谓基本可用是指分布式系统出现故障的时候允许损失一部分的可用性。柔性状态是指允许系统存在中间状态，这个中间状态不会影响系统整体的可用性，比如数据库读写分离的主从同步延迟等。柔性事务的一致性指的是最终一致性。

• 实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。
• 消息：业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息发送状态确认系统定期找到未确认发送或者回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或者消息内容确认该消息是否有效。被动方的处理结果不会影响主动方的处理结果，被动方的消息处理操作是幂等操作。
• 成本：可靠的消息系统建设成本，一次消息发送需要两次请求，业务处理服务需要实现消息状态回查接口。
• 优点：消息数据独立存储，独立伸缩，降低业务系统和消息系统之间的耦合。对最终一致性时间敏感度较高，降低业务被动方的实现成本。兼容所有实现JMS标准的MQ中间件，确保业务数据可靠的前提下，实现业务的最终一致性，理想状态下是准实时的一致性。

• TCC事务补偿型方案

• 

   

  • 实现：一个完整的业务活动由一个主业务服务于若干的从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供TCC型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动的操作，并在业务活动提交时确认所有的TCC型操作的Confirm操作，在业务活动取消时调用所有TCC型操作的Cancel操作。
  • 成本：实现TCC操作的成本较高，业务活动结束的时候Confirm和Cancel操作的执行成本。业务活动的日志成本。
  • 使用范围：强隔离性，严格一致性要求的业务活动。适用于执行时间较短的业务，比如处理账户或者收费等等。
  • 特点：不与具体的服务框架耦合，位于业务服务层，而不是资源层，可以灵活的选择业务资源的锁定粒度。TCC里对每个服务资源操作的是本地事务，数据被锁住的时间短，可扩展性好，可以说是为独立部署的SOA服务而设计的。最大努力通知型

   

最大努力通知型

• 实现：业务活动的主动方在完成处理之后向业务活动的被动方发送消息，允许消息丢失。业务活动的被动方根据定时策略，向业务活动的主动方查询，恢复丢失的业务消息。
• 约束：被动方的处理结果不影响主动方的处理结果。
• 成本：业务查询与校对系统的建设成本。
• 使用范围：对业务最终一致性的时间敏感度低。跨企业的业务活动。
• 特点：业务活动的主动方在完成业务处理之后，向业务活动的被动方发送通知消息。主动方可以设置时间阶梯通知规则，在通知失败后按规则重复通知，知道通知N次后不再通知。主动方提供校对查询接口给被动方按需校对查询，用户恢复丢失的业务消息。
• 适用范围：银行通知，商户通知。

基于可靠消息的最终一致性方案详解

（一）、消息发送一致性

消息中间件在分布式系统中的核心作用就是异步通讯、应用解耦和并发缓冲（也叫作流量削峰）。在分布式环境下，需要通过网络进行通讯，就引入了数据传输的不确定性，也就是CAP理论中的分区容错性。

 消息发送一致性是指产生消息的业务动作与消息发送一致，也就是说如果业务操作成功，那么由这个业务操作所产生的消息一定要发送出去，否则就丢失。

（二）、保证消息一致的变通做法

1. 发送消息：主动方现将应用把消息发给消息中间件，消息状态标记为“待确认”状态。
2. 消息中间件收到消息后，把消息持久化到消息存储中，但是并不影响被动方投递消息。
3. 消息中间件返回消息持久化结果，主动方根据返回的结果进行判断如何进行业务操作处理：
   1. 失败：放弃执行业务操作处理，结束，必要时向上层返回处理结果。
   2. 成功：执行业务操作处理。
4. 业务操作完成后，把业务操作结果返回给消息中间件。
5. 消息中间件收到业务操作结构后，根据业务结果进行处理：
   1. 失败：删除消息存储中的消息，结束。
   2. 成功：更新消息存储中的消息状态为“待发送”，然后执行消息投递。
6. 前面的正向流程都成功之后，向被动方应用投递消息。

但是在上面的处理流程中，任何一个环节都有可能出现问题。

消息重复发送问题和业务接口幂等性设计

 对于未确认的消息，采用按规则重新投递的方式进行处理。对于以上流程，消息重复发送会导致业务处理接口出现重复调用的问题。消息消费过程中消息重复发送的主要原因就是消费者成功接收处理完消息后，消息中间件没有及时更新投递状态导致的。如果允许消息重复发送，那么消费方应该实现业务接口的幂等性设计。

本地消息服务方案

• 实现思路：
  1. 主动方应用系统通过业务操作完成业务数据的操作，在准备发送消息的时候将消息存储在主动方应用系统一份，另一份发送到实时消息服务
  2. 被动方应用系统监听实时消息系统中的消息，当被动方完成消息处理后通过调用主动方接口完成消息确认
  3. 主动方接收到消息确认以后删除消息数据。
  4. 通过消息查询服务查询到消息被接收之后再规定的时间内没有返回ACK确认消息就通过消息恢复系统重新发送消息。
• 优点：
  1. 消息的时效性比较高
  2. 从应用设计的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。
  3. 方案轻量级，容易实现。
• 缺点：
  1. 与具体的业务场景绑定，耦合性强，不可以共用。
  2. 消息数据与业务数据同步，占用业务系统资源。
  3. 业务系统在使用关系型数据库的情况下消息服务性能会受到关系型数据库的并发性能限制。
  4. 独立消息服务方

分布式事务解决方案

标签：持久化   cap   幂等性   轻量   锁定   消费   成功   mic   重新投递   

原文地址：https://www.cnblogs.com/zj-xu/p/11934580.html