https://blog.csdn.net/wanghang88/article/details/79762761
1：分布式事物的理解：
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，分布式事务需要保证这些小操作要么全部成功，要么全部失败;本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
2：分布式事物产生的原因：
a）数据库分库分表;
当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。
b)应用SOA化；
就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心等,对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。
3）分布式的使用场景：
支付：一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败，并且卖家账户对应卖家数据库,买家对应买家的数据库，对不同数据库的操作必然需要引入分布式事务。
在线下单：在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态,库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。
4）常见的分布式事物解决方案：
a）基于XA协议的两阶段提交，
XA是一个分布式事务协议,XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也，XA也有致命的缺点，那就是性能不理想,往往并发量很高，XA无法满足高并发场景。
b)消息事务+最终一致性
所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性。
具体原理：
其执行的顺序：
b.1)A系统向消息中间件发送一条预备消息;
b.2)消息中间件保存预备消息并返回成功;
b.3)消息中间件保存预备消息并返回成功；
b.4)A发送提交消息给消息中间件；
对于这个顺序执行的分析：
步骤一出错，则整个事务失败，不会执行A的本地操作;
步骤二出错，则整个事务失败，不会执行A的本地操作；
步骤三出错，这时候需要回滚预备消息,回滚方法,：A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息。
步骤四出错,这时候A的本地事务是成功的，回滚本地A操作的成功,不需要回滚：其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务。
c）高并发场景下基于消息中间件的两阶段提交的分布式事物：
比如：将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作
B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作。如果B本地操作失败，消息会重投,直到B操作成功。这样就变相地实现了A与B的分布式事务。
虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的,当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。
d）TCC编程模式,
TCC编程模式，也是两阶段提交的一个变种。
TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。
以在线下单为例：Try阶段会去扣库存,Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存,TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。
4)总结：
分布式事务，本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务;部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式;完全控制就是完全实现两阶段提交。
分布式理论
分为 CAP定理 and BASE理论
CAP定理
他指出WEB服务无法同时满足一下3个属性：
- 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
- 可用性(Availability) ： 每个操作都必须以可预期的响应结束
- 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成
具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
这个定理在迄今为止的分布式系统中都是适用的
数据库的2PC（两阶段提交） 又叫做 XA Transactions。
，XA 是一个两阶段提交协议，该协议分为以 下两个阶段：
- 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
- 第二阶段：事务协调器要求每个数据库提交数据。
其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。
如果CAP 定理是对的，那么它一定会影响到可用性。
BASE理论
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
通过两种手段来扩展我们的数据服务
1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。
2）数据镜像：让所有的服务器都有相同的数据，提供相当的服务。
，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储 但是，加入更多的机器，会让我们的数据服务变得很复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性
简单说来：
1）要想让数据有高可用性，就得写多份数据。
2）写多份的问题会导致数据一致性的问题。
3）数据一致性的问题又会引发性能问题
数据库分库分表( 单表数据量达到1000W)
目的就在于减少数据库的负担，缩短查询时间。
数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。
为两种切分模式 ：
一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；
另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。
垂直切分
即业务切分
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。
垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
下面来分析下垂直切分的优缺点：
优点：
拆分后业务清晰，拆分规则明确。
系统之间整合或扩展容易。
数据维护简单。
缺点：
部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度。
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
事务处理复杂。
由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶
颈，所以就需要水平拆分来做解决。
水平拆分
水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中
包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果
库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。
几种典型的分片规则包括：
按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。
按照日期，将不同月甚至日的数据分散到不同的库中。
按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。
切分原则都是根据业务找到适合的切分规则分散到不同的库，
优点：
拆分规则抽象好，join 操作基本可以数据库做。
不存在单库大数据，高并发的性能瓶颈。
应用端改造较少。
提高了系统的稳定性跟负载能力。
缺点：
拆分规则难以抽象。
分片事务一致性难以解决。
数据多次扩展难度跟维护量极大。
跨库 join 性能较差。
分库分表可以在不同的层做。一般来说有以下几种：
jdbc层：实现复杂，属于轻量级，对应用基本没有侵入性;缺点是不能复用数据库连接，在应用部署多的时候资源耗费大，不适于大规模部署。类似当当网的sharding-jdbc.
ORM层：比如蘑菇街TSharding框架封装mybatis，实现简单。缺点是必须依赖ORM层，侵入性比较大。
DBProxy层：如cobar和mycat，可以做到连接复用，性能不错，完全没侵入性。缺点是实现复杂，框架比较重，维护工作量大。
DAO层：实现简单，缺点是分表比较麻烦。美团的框架似乎就是这样做到。
无论怎么做分库分表，其基本思路都是一样的。需要有分库路由，分库规则，分库关键字
分库数量
分库数量首先和单库能处理的记录数有关，一般来说，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。
在满足上述前提下，如果分库数量少，达不到分散存储和减轻DB性能压力的目的；如果分库的数量多，好处是每个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序需要访问多个库，如果是并发模式，要消耗宝贵的线程资源；如果是串行模式，执行时间会急剧增加。
最后分库数量还直接影响硬件的投入，一般每个分库跑在单独物理机上，多一个库意味多一台设备。所以具体分多少个库，要综合评估，一般初次分库建议分4-8个库。
路由透明
分库从某种意义上来说，意味着DB schema改变了，必然影响应用，但这种改变和业务无关，所以要尽量保证分库对应用代码透明，分库逻辑尽量在数据访问层处理。当然完全做到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：
对于单库访问，比如查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。
对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。
几种典型的数据分片规则为：
1、根据数值范围 ： 按照时间区间或ID区间来切分
2、根据数值取模 ： 一般采用hash取模mod的切分方式
问题：