1.分布式事务前奏事务：事务是由一组操作组成的可靠的独立工作单元，事务具有ACID的特性，即原子性、一致性、隔离性和持久性。本地事务：当事务由资源管理器在本地管理时，称为本地事务。本地事务的优点是支持严格的ACID特性，高效可靠，状态只能在资源管理器中维护，应用编程模型简单。但是，本地事务不具备分布式事务的处理能力，隔离的最小单位受到资源管理器的限制。全局事务：当事务被全局事务管理器全局管理时，就成为全局事务。事务管理器负责管理全局事务状态和参与资源，协调资源的一致性提交和回滚。TX协议：应用程序或应用服务器与事务管理器之间的接口。XA协议：全局事务管理器和资源管理器之间的接口。XA是由X/Open组织提出的分布式事务规范。本规范主要定义了全局事务管理器和本地资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向系统接口，作为事务管理器和多个资源管理器之间的沟通桥梁。之所以需要XA，是因为在分布式系统中，理论上两台机器无法达到一致状态，所以引入单点进行协调。由全局事务管理器管理和协调的事务可以跨越多个资源和进程。全局事务管理器一般使用XA两阶段协议与数据库进行交互。AP：Applicationprogram，可以理解为使用DTP（DataToolsPlatform）的程序。RM：资源管理器，这里可以是DBMS或者消息服务器管理系统，应用程序通过资源管理器控制资源，资源必须实现XA定义的接口。资源管理器负责控制和管理实际资源。TM：TransactionManager，负责协调和管理事务，提供AP编程接口和管理资源管理器。事务管理器控制全局事务，管理事务的生命周期，并协调资源。两阶段提交协议：XA在全局事务中协调多个资源的机制。TM和RM之间采用两阶段提交方案来解决一致性问题。双节点提交需要一个协调器（TM）来保存所有参与者（RM）节点的操作结果，并指示这些节点是否需要最终提交。两阶段提交的局限性在于协议成本、准备阶段的持久成本、全局事务状态的持久成本以及许多潜在故障点造成的漏洞。准备之后和提交之前的失败会导致一系列的隔离和恢复问题。BASE理论：BA指基本业务可用性，支持分区失效，S表示灵活状态，即允许短时间不同步，E表示最终一致性，数据最终一致，但实时不一致。必须从根本上保证原子性和持久性。对于可用性、性能和服务降级的需求，只能降低对一致性和隔离性的要求。CAP定理：对于共享数据系统，最多同时拥有两个CAP，任意两个都有各自适合的场景。真实的业务系统通常是ACID和CAP的混合体。分布式系统最重要的是满足业务需求，而不是追求高度抽象和绝对的系统特性。C表示一致性，即所有用户看到的数据都是一样的。A表示可用性，这意味着始终可以找到数据的可用副本。P表示partitionfaulttolerance，可以容忍网络中断等故障。灵活事务中的服务模式：1）可查询操作：服务操作具有全局唯一标识，操作具有唯一且确定的时间。2）幂等操作：多次重复调用产生的业务结果与调用一次产生的结果相同。一是通过业务操作实现幂等，二是缓存所有请求和处理结果，最后检测到重复请求后，自动返回之前的处理结果。3）TCC运行：Try阶段：尝试执行业务，完成所有业务检查，并达到一致性；预留必要的业务资源，实现准隔离。Confirm阶段：实际执行业务，不做任何检查，只适用Try阶段预留的业务资源，Confirm操作也必须满足幂等性；Cancel阶段：取消业务的执行，释放Try阶段预留的业务资源，Cancel操作必须是幂等的。TCC和2PC（两阶段提交）协议的区别：TCC位于业务服务层，而不是资源层。TCC没有单独的准备阶段。Try操作兼具资源操作和准备能力。TCC中的Try操作可以灵活选择业务资源和锁粒度。TCC的开发成本高于2PC。其实TCC也是一个二阶段运算，只是TCC不等同于2PC运算。4）可补偿操作：Do阶段：实际执行业务处理，业务处理结果对外可见；补偿阶段：抵消或部分抵消正向业务操作的业务结果，补偿操作满足幂等性。约束条件：薪酬操作在业务上具有可行性，业务执行结果不孤立或薪酬不全所带来的风险和成本可控。其实TCC的Confirm和Cancel操作都可以看成补偿操作。2.灵活的事务解决方案架构在电子商务领域等互联网场景下，传统事务暴露出数据库性能和处理能力的瓶颈。灵活事务有两个特点：基本可用性和灵活状态。所谓基本可用性，就是当分布式系统出现故障时，允许损失一部分可用性。弹性状态是指允许系统存在于一个中间状态，不会影响系统整体的可用性，比如数据库读写分离的主从同步延迟等。灵活事务的一致性指的是最终一致性。基于可靠消息的最终一致性方案1）实现：业务事务提交前，业务处理服务请求发送消息给实时消息服务，实时消息服务只记录消息数据，不记录消息数据实际上发送它。业务交易提交后，业务处理服务会向实时消息服务发送确认。实时消息服务只有在确认发送命令后才会真正发送消息。2）消息：业务事务回滚后，业务处理服务取消发送给实时消息服务。消息发送状态确认系统定期查找未确认或回滚的消息，向业务处理服务查询消息状态，业务处理服务根据消息ID或消息内容确认消息是否有效。被动方的处理结果不会影响主动方的处理结果，被动方的消息处理操作是幂等操作。3）成本：可靠的消息系统的构建成本需要两次请求发送一条消息，业务处理服务需要实现消息状态检查接口。4）优点：消息数据独立存储，独立伸缩，降低了业务系统和消息系统之间的耦合度。对最终一致性时间高度敏感，降低业务被动端的实施成本。兼容所有实现JMS标准的MQ中间件，在保证业务数据可靠性的前提下，实现业务的最终一致性，理想的准实时一致性。TCC交易补偿方案1）实现：一个完整??的业务活动由一个主业务服务于多个从业务服务组成。主业务服务负责发起和完成整个业务活动。从业务服务中提供TCC式的业务运营。业务活动经理控制业务活动的一致性。注册业务活动的操作，业务活动提交时确认所有TCC类操作的Confirm操作，业务活动取消时调用所有TCC类操作的Cancel操作。2）成本：执行TCC操作的成本比较高，业务活动结束时的Confirm和Cancel操作的执行成本。业务活动的日志成本。3）使用范围：隔离性强、一致性要求严格的业务活动。适用于执行时间短的业务，如办理账务或收费等。4）特点：不与特定的服务框架耦合，位于业务服务层而不是资源层，可以灵活选择业务资源的锁定粒度。在TCC中，每个服务资源都运行一个本地事务，数据锁定时间短，扩展性好。可以说是为独立部署的SOA服务而设计的。Best-effort通知类型1）实现：业务活动的主动方处理后向业务活动的被动方发送消息，允许消息丢失。业务活动的被动端根据定时策略查询业务活动的主动端，恢复丢失的业务信息。2）约束条件：被动端的处理结果不影响主动端的处理结果。3）成本：业务查询校对系统的建设成本。4）使用范围：对业务最终一致性的时间敏感性低。跨企业的业务活动。5）特点：业务活动的主动方完成业务处理后，向业务活动的被动方发送通知消息。主动方可以设置时间阶梯通知规则，通知失败后按规则重复通知，N次通知后不再通知。主动方提供校对查询接口供被动方按需校对查询，用户恢复丢失的业务消息。适用范围：银行通知、商户通知。3、基于可靠消息的最终一致性方案分布式系统中消息发送一致性消息中间件的核心作用是异步通信、应用解耦和并发缓冲（也称为流量削峰）。在分布式环境中，需要通过网络进行通信，这就引入了数据传输的不确定性，这就是CAP理论中的分区容错。消息发送一致性是指产生消息的业务动作与消息发送是一致的，也就是说，如果业务操作成功，则业务操作产生的消息必须发送出去，否则会丢失。处理方式一：publicvoidcompleteOrderService{//processorderorder.process;//sendaccountingoriginalvouchermessagepipe.sendAccountingVouchetMessage;}上述案例中，如果业务操作成功，在消息发送前应用失败，则消息发不出去，导致消息丢失，进而导致订单系统和账务系统数据不一致。如果消息系统或网络异常，消息将发不出去，数据也会不一致。处理方式二：publicvoidcompleteOrderService(){//发送记账原始凭证消息pipe.sendAccountingVouchetMessage();//处理订单order.process();}如果把上面两个操作的顺序反过来，这种情况就更不可接受的如果消息发送出去，业务订单可能会失败，导致订单系统和业务系统数据不一致。那么JMS标准中的XA协议能否保证发送的一致性呢？在JMS协议标准的API中，有很多以XA开头的接口，其实就是上面说的支持XA协议（基于两阶段提交协议）的全局事务类型。界面。XAConnection.classXAConnectionFactory.classXAQueueConnection.classXAQueueConnectionFactory.classXASession.classXATopicConnection.classXATopicConnectionFactory.classXATopicSession.classJMS中的XA系列接口可以提供对分布式事务的支持。但是在XA模式下引用分布式事务会带来很多限制。需要业务操作的资源必须支持XA协议，但并不是所有的资源都支持XA协议。两阶段提交协议的成本。DTP模型的局限性如持久化成本，如：全局锁定、高成本、低性能。使用XA协议违背了灵活事务的初衷。保证消息一致性的备选方法1)发送消息：主动方此时会通过应用向消息中间件发送消息，消息状态会被标记为“等待确认”。2）消息中间件收到消息后，将消息持久化到消息存储中，但不影响被动方传递消息。3）消息中间件返回消息持久化结果，主动方根据返回结果判断业务操作如何处理：失败：放弃业务操作处理的执行，结束，将处理结果返回给上层必要时分层；成功：执行业务操作处理。4）业务操作完成后，将业务操作结果返回给消息中间件。消息中间件收到业务操作结构后，根据业务结果进行处理：失败：删除消息库中的消息，结束；成功：更新消息库中的消息状态为“待发送”，然后进行消息投递。前面的转发过程成功后，将消息传递给被动应用程序。但是，在上述处理流程中，任何一个环节都可能出现问题。常规MQ消息处理流程及特点常规MQ队列处理流程无法实现消息一致性。消息传递的本质是消息消费，可以细化。消息重复发送问题及业务接口幂等性设计对于未确认的消息，采用按规则重新投递的方式进行处理。对于上述流程，重复发送消息会导致重复调用业务处理接口的问题。消息消费过程中重复发送消息的主要原因是消费者成功接收并处理消息后，消息中间件没有及时更新发送状态。如果允许重复发送消息，消费者应该实现业务接口的幂等设计。本地消息服务方案1）实现思路：主动方应用系统通过业务操作完成对业务数据的操作，准备发送消息时将消息存储在主动方应用系统的一份中，另一份发送给真实的-定时消息服务；被动方应用系统监听实时消息系统中的消息，当被动方完成消息处理后，调用主动方接口完成消息确认；主动方收到消息确认后删除消息数据；通过报文查询服务，可以指定在收到报文后，如果在规定时间内没有返回ACK确认报文，则通过报文恢复系统重新发送报文。2）优点：消息的及时性比较高；从应用设计的角度实现消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖；该解决方案是轻量级的，易于实现。3）缺点：绑定到特定的业务场景，耦合性强，不能共享；消息数据与业务数据同步，占用业务系统资源；当业务系统使用关系型数据库时，消息服务性能会受到关系型数据库的并发性能限制。独立消息服务方案1）实现思路：消息预发：主动方应用系统预发消息，消息服务子系统对消息进行存储。如果存储出现故障，则无法进行业务操作。如果存储返回成功，则执行业务操作。执行业务操作：如果业务操作执行成功，将业务操作执行成功的状态发送给消息服务子系统。消息服务子系统将消息的状态修改为“可发送”。发送消息到实时消息服务：当消息状态发生变化时，立即将消息发送到实时消息服务。接下来，消息会被消息服务的消费者监听，然后被消费。消息状态子系统：相当于定时任务系统，定时在消息服务子系统中查找确认超时的消息，定时在活跃的应用系统中查找未处理的任务，并进行相应的处理。消息消费：当一条消息被消费时，向实时消息服务发送ACK，然后实时消息服务删除该消息。同时调用消息服务子系统将消息修改为“已消费”状态。消息恢复子系统：当消费者返回一条消息时，由于网络中断等其他原因导致消息没有被及时确认，因此消息恢复子系统需要定期在消息服务子系统中找出未被确认的消息。将未确认的消息放入实时消息服务中重做，因为被动应用系统的接口是幂等的。2）优点：消息服务独立部署，独立维护，独立伸缩。消息存储可以根据需要选择不同的数据库进行集成实现。消息服务可以被相同的使用场景所使用，减少重复服务构建的成本。从分布式服务应用设计开发的角度，实现消息数据的可靠性。消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。降低了业务系统与消息系统之间的耦合度，有利于系统的扩展和维护。3）缺点：发送一条消息需要两次请求；主动方的应用系统需要实现业务运行状态的验证和查询接口。消息服务子系统示例消息数据表的设计与实现：
