分布式系统下，分布式数据库遇到的挑战

分布式系统下，分布式数据库遇到的挑战

 

　　分布式系统下，当访问关系型数据库的i/o占用太高，内存不足，访问过慢的状况下，能够考虑流流行的分库分表的策略，可是这样也会到来不少新的技术挑战。

 

1.分布式事务

 

　　当仍是单体应用，单体数据库时，彻底不须要考虑事务的一致性问题，由于mysql已经帮咱们处理事务问题(ACID)，可是这只是针对单体状况下，若是是多个数据库，主从备份，读写分离，那么就会可能形成事务不一致的状况，那么什么事分布式事务，分布式

　　事务又该如何解决呢？

　　

　　1.有关于事务的概念

　　　　本地事务：本地事务的优势就是支持严格的ACID特性，高效，可靠，状态能够只在资源管理器中维护，并且应用编程模型简单。

　　　　全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。

　　　　两阶段事务：两阶段事务提交采用的是X/OPEN组织所定义的DTP模型，经过抽象出来的AP, TM, RM的概念能够保证事务的强一致性。 其中TM和RM间采用XA的协议进行双向通讯。 与传统的本地事务相比，

　　　　　　　　　　XA事务增长了prepare阶段，数据库除了被动接受提交指令外，还能够反向通知调用方事务是否能够被提交。 所以TM能够收集全部分支事务的prepare结果，最后进行原子的提交，保证事务的强一致性。

　　　　　　

　　　　BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是容许短期内不一样步，E表示最终一致性，数据最终是一致的，可是实时是不一致的。原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的须要，只有下降一致性和隔离性的要求。

 　　　   CAP定理：对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适应的场景，真是的业务系统中一般是ACID与CAP的混合体。分布式系统中最重要的是知足业务需求，而不是追求高度抽象，绝对的系统特性。C表示一致性，也就是全部用户看到的数据是同样的。

　　　　　　　　　A表示可用性，是指总能找到一个可用的数据副本。P表示分区容错性，可以容忍网络中断等故障。

 

　　2.解决方案

　　　　1.两阶段（2PC）解决方案

　　　　　　

 

　　　　　　

　　　　　　　　两阶段提交其实比较简单，这边有两个资源提供准备和提交两个接口。

　　　　　　　　因为隔离性互斥的要求，在事务执行过程当中，全部的资源都是被锁定的，这种状况只适合执行时间肯定的短事务。 可是为了保证分布式事务的一致性，大都是采用串行化的隔离级别来保证事务一致性，这样会下降系统的吞吐。

　　　　　　　　但由于2PC的协议成本比较高，又有全局锁的问题，性能会比较差。 如今你们基本上不会采用这种强一致解决方案。

 

　　　　2.TCC事务补偿方案

　　　　　　                              

 

　　　　　　　　　　　　

　　　　　　　　　　　　　　TCC名字的由来是其中包含了 try, confirm, cancel三个操做。

　　　　　　　　　　　　　　与两阶段提交相比，TCC位于业务服务层， 没有单独的准备阶段，Try操做能够灵活选择业务资源锁的粒度。TCC是经过最终一致性来解决系统性能问题的这个设计，对咱们设计抉择有很大的启发。 有些时候系统的技术问题是能够经过业务建模的方式来解决的。

 

 

　　　　3.Saga事务

　　　　　　Saga这个概念来源于三十多年前的一篇数据库论文Sagas ，一个Saga事务是一个有多个短时事务组成的长时的事务。 在分布式事务场景下，咱们把一个Saga分布式事务看作是一个由多个本地事务组成的事务，每一个本地事务都有一个与之对应的补偿事务。

　　　　　　在Saga事务的执行过程当中，若是某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操做，这样保证Saga相关的本地事务要么都是执行成功，要么经过补偿恢复成为事务执行以前的状态。

　　　　　　Saga定义了一个事务中的每一个子事务都有一个与之对应的反向补偿操做。由Saga事务管理器根据程序执行结果生成一张有向无环图，并在须要执行回滚操做时，根据该图依次按照相反的顺序调用反向补偿操做。Saga事务管理器只用于控制什么时候重试，什么时候补偿，

　　　　　　并不负责补偿的内容，补偿的具体操做须要由开发者自行提供。

 

 　　　　　　

　　　　　　SAGA能够看作一个异步的、利用队列实现的补偿事务。

　　　　　　其适用于无需立刻返回业务发起方最终状态的场景，例如：你的请求已提交，请稍后查询或留意通知 之类。

　　　　　　将上述补偿事务的场景用SAGA改写，其流程以下：

• • • 　　　　订单服务建立最终状态未知的订单记录，并提交事务
    • 　　　　现金服务扣除所需的金额，并提交事务
    • 　　　　订单服务更新订单状态为成功，并提交事务

　　　　以上为成功的流程，若现金服务扣除金额失败，那么，最后一步订单服务将会更新订单状态为失败。

　　　　其业务编码工做量比补偿事务多一点，包括如下内容：

• • • 　　　　订单服务建立初始订单的逻辑
    • 　　　　订单服务确认订单成功的逻辑
    • 　　　　订单服务确认订单失败的逻辑
    • 　　　　现金服务扣除现金的逻辑
    • 　　　　现金服务补偿返回现金的逻辑

　　　　但其相对于补偿事务形态有性能上的优点，全部的本地子事务执行过程当中，都无需等待其调用的子事务执行，减小了加锁的时间，这在事务流程较多较长的业务中性能优点更为明显。同时，其利用队列进行进行通信，具备削峰填谷的做用。

　　　　所以该形式适用于不须要同步返回发起方执行最终结果、能够进行补偿、对性能要求较高、不介意额外编码的业务场景。

　　　　但固然SAGA也能够进行稍微改造，变成与TCC相似、能够进行资源预留的形态。

 

　　　　4.基于消息事务　　　　

　　　　　　基于消息实现的事务适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其余数据源的数据变动跟随发起方进行的业务场景。

　　　　　　举个例子，假设存在业务规则：某笔订单成功后，为用户加必定的积分。

　　　　　　在这条规则里，管理订单数据源的服务为事务发起方，管理积分数据源的服务为事务跟随者。

　　　　　　从这个过程能够看到，基于消息队列实现的事务存在如下操做：

• • • 　　　　订单服务建立订单，提交本地事务
    • 　　       订单服务发布一条消息
    • 　　　　积分服务收到消息后加积分

　　　　咱们能够看到它的总体流程是比较简单的，同时业务开发工做量也不大：

• • • 　　　　编写订单服务里订单建立的逻辑
    • 　　　　编写积分服务里增长积分的逻辑

　　　　　　能够看到该事务形态过程简单，性能消耗小，发起方与跟随方之间的流量峰谷可使用队列填平，同时业务开发工做量也基本与单机事务没有差异，都不须要编写反向的业务逻辑过程。所以基于消息队列实现的事务是咱们除了单机事务外最优先考虑使用的形态。

 

　　　　单机事务》基于消息的事务》基于补偿的事务》TCC事务