分布式事务

Sharding的基本思想就要把一个 数据库 切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。 需要特别说明的是：当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。比如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意的关联关系，因此你可以按“功能模块”划分表格，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了

分布式事务 概念： 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。 本质上来说，分布式事务就是为了保证不同数据库的数据一致性。实现分布式事务方案有很多种，有阿里的seata，基于tcc的高性能分布式事务框架hmily和lcn等开源框架外，还有基于mq来实现分布式事务解决方案(常见的有rabbitmq、kafka等)。本文介绍基于kafka简单实现原理。 描述： 不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一种方法同样可以解决分布式事务问题, 并且性能较好, 这就是我这篇文章要介绍的使用事件,本地事务以及消息队列来实现分布式事务. 我们从一个简单的实例入手. 基本所有互联网应用都会有用户注册的功能. 在这个例子中, 我们对于用户注册有两步操作: 注册成功, 保存用户信息.

1.LCN： 该模式对代码的嵌入性为低。 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。 2.TCC 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。 该模式对有无本地事务控制都可以支持使用面广。 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。 3.TXC 该模式同样对代码的嵌入性低。 该模式仅限于对支持SQL方式的模块支持。 该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。 该模式不会占用数据库的连接资源。 来源： https://my.oschina.net/pjpj/blog/3114181

分布式领域CAP理论： Consistency(一致性), 数据一致更新，所有数据变动都是同步的。 Availability(可用性), 好的响应性能。 Partition tolerance(分区容错性) 可靠性。 要做到 CP， 系统可以把这个数据只放在一个节点上，其他节点收到请求后向这个节点读或写数据，并返回结果。 要做到 CA， 一个现实的例子就是单点的数据库。 要做到 AP， 系统只要每次对写都返回成功，对读都返回固定的某个值就可以了。 CAP 理论更重要的一个结果是， 在 Partial Synchronous System (半同步系统) 中，一个弱化的 CAP 是能达到的: * 对所有的数据访问，总返回一个结果 * 如果期间没有报文丢失，那么返回一个满足 consistency 要求的结果。 很像mysql的半同步复制技术。 关系数据库的ACID模型拥有：即事物的acid属性。 Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。 Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。 Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。 Durability. 一旦事务完成，就不能返回。 来源： oschina 链接： https://my.oschina.net/u/2460176/blog

MQ背景&选型 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 目前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相比于Rabbitmq、kafka具有主要优势特性有： • 支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持） • 支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提） • 支持18个级别的延迟消息（rabbitmq和kafka不支持） • 支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认） • 支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持） • 支持重复消费（rabbitmq不支持，kafka支持） Rocketmq、kafka、Rabbitmq的详细对比，请参照下表格： RocketMQ集群概述 RocketMQ集群部署结构 image

分布式一致性理论 CAP 理论 一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。 如下： 选项 描述 C(Consistence) 一致性 ，指数据在多个副本之间能够保持一致的特性（ 严格的一致性 ）。 A(Availability) 可用性 ，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 P(Network partitioning) 分区容错性 ，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 Base 理论 BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。 既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ） 基本可用 允许出现响应时间损失或者功能损失。 软状态 允许系统中的数据存在中间状态

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

声明： 本篇主要对所用到的技术做了归纳总结，对源码讲解较少，如果有基础的朋友可以直接下载源码结合时序图更能容易理解；基础比较弱的朋友建议先看看资料自看源码这样更容易理解。这里的部分资料来源于网络，所以这里对那些资料提供者表达衷心的感谢。 方案： 业务流程：Tss库向Saas转移库存，order为记录表。 技术栈： Springboot+mysql+postgreSQL+atomikos+mybatis 项目代码地址：https://github.com/bao17634/springboot-kafka-demo.git 1、分布式事务模型 ACID 实现 1.1、X/Open XA 协议（XA） 最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing(DTP)模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。 DTP模型如图： TM：全局事务管理器 RM：多个资源管理器 AP：应用程序 全局事务管理器负责管理全局事务状态与参与的资源，协同资源一起提交或回滚;资源管理器则负责具体的资源操作。 XA 协议主要描述了 TM 与 RM 之间的接口，允许多个资源在同一分布式事务中访问。 基于 DTP 模型的分布式事务流程大致如下： XA接口详解 XA接口时双向的系统接口

一、背景 在微服务架构中，我们常常使用异步化的手段来提升系统的 吞吐量 和 解耦 上下游，而构建异步架构最常用的手段就是使用 消息队列(MQ) ，那异步架构怎样才能实现数据一致性呢？本文主要介绍如何使用 RocketMQ 的 事务消息 来解决一致性问题。 RocketMQ 是阿里巴巴开源的分布式消息中间件，目前已成为 Apache 的顶级项目。历经多次天猫双十一海量消息考验，具有高性能、低延时和高可靠等特性 PS ：同步场景怎样保证一致性？请看文章《 Spring Cloud同步场景分布式事务怎样做？试试Seata 》 二、MQ选型 可以看到在 业务处理 方面来说 RocketMQ 优于其他对手，而且原生支持 事务消息 PS ：业务系统用的是其他 MQ 产品但是又需要 事务消息 怎么办？学习原理自己开发实现！ 三、什么是事务消息 例如下图的场景：生成订单记录 -> MQ -> 增加积分 我们是应该先 创建订单记录 ，还是先 发送MQ消息 呢？ 先发送MQ消息 ：这个明显是不行的，因为如果消息发送成功，而订单创建失败的话是没办法把消息收回来的 先创建订单记录 ：如果订单创建成功后MQ消息发送失败 抛出异常 ，因为两个操作都在本地事务中所以订单数据是可以 回滚 的 上面的 方式二 看似没问题，但是 网络是不可靠的 ！如果 MQ 的响应因为网络原因没有收到

在分布式系统中著有 CAP 理论，该理论由加州大学伯克利分校的 Eric Brewer 教授提出，阐述了在一个分布式系统中不可能同时满足 一致性（Consistency） 、 可用性（Availability） ，以及 分区容错性（Partition tolerance） 。 C：一致性 在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致。 A：可用性 可用性描述了系统对用户的服务能力，所谓可用是指在用户容忍的时间范围内返回用户期望的结果。 P：分区容错性 分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。 对于一个分布式系统而言，我们要始终假设网络是不可靠的，因此分区容错性是对一个分布式系统最基本的要求，我们的切入点更多的是尝试在可用性和一致性之间寻找一个平衡点，但这也并非要求我们在系统设计时一直建立在网络出现分区的场景之上，然后对一致性和可用性在选择时非此即彼。实际上 Eric Brewer 在 2012 年就曾指出 CAP 理论证明不能同时满足一致性、可用性，以及分区容错性的观点在实际系统设计指导上存在一定的误导性 。传统对于 CAP 理论的理解认为在设计分布式系统时必须满足 P，然后在