分布式事务、一致性的主流解决手段
互联网的ACID、CAP、Base理论:
ACID:数据库的四个特性(原子性,隔离性,一致性,持久性)
首先要很清楚的认知什么是ACID,一般关系型数据库都会保证ACID这个特性,那么ACID对于一致性来说,就是一种最直接且最有效的强一致性。001中所看到的Q1,关于订单和库存的问题,如果在数据量较小的情况下,可以利用关系型数据库的强一致性解决。无非就是把订单表和库存表放到同一个关系型数据库之中去操作,利用其ACID的特性去达到一致性。然而很明显我们的互联网电商系统往往都是具有大规模、高并发的特性,必须采用对高并发压力的”分而治之,大事化小,小事化了”的思想去做,否则难以抗住动辄就是上亿级别流量的需求、以及吞吐量和性能上的需求。(正常互联网大厂不会加任何的事务,也不应该加事务处理,什么所谓的TCC、两阶段提交或三阶段提交基本不会应用在生产;都是应用补偿方式、记录日志方式将分布式事务进行解决;加事务就代表降性能。)
对于Q1的问题,如果能通过数据库设计去做,尽量保证订单和库存表放到同一个数据库分片中,这样可以通过关系型数据库层面去解决不一致的问题了。(纵向扩展)
但是有时候往往我们做不到这样的设计,可能由于业务规则的复杂以及限制,我们无法去将其规划到同一个数据库分片之中,这种情况就需要实现最终一致性了。 OK?何为最终一致性?这就需要我们知道第二个基础理论,CAP(帽子原理)
CAP:帽子理论
•概念: CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。CAP理论首先把分布式系统中的三个特性进行了如下归纳:
•一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
•可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
•分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求,也就是尽管网络上有部分消息丢失,但是系统仍然可以继续工作。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。
•CAP原理证明任何分布式系统只可以同时满足两点,无法满足三者兼顾。
CP经典框架:Zookeeper
采用原子消息广播,是唯一使用Paxos算法来保障数据的强一致性,但是其做不到强可用性,ZK集群大的时候会出现局部崩溃等事件,所以其满足了CP,宁愿服务不对外提供数据,也不会出现提供不一致的数据,所以其架构的核心是满足CP原则;注释:Zookeeper的单调性:https://blog.csdn.net/paincupid/article/details/80610441
ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果ZooKeeper下所有节点都断开了,或者集群中出现了网络分割的故障(注:由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper会将它们都从自己管理范围中剔除出去,外界就不能访问到这些节点了,即便这些节点本身是“健康”的,可以正常提供服务的;所以导致到达这些节点的服务请求被丢失了。(注:这也是为什么ZooKeeper不满足CAP中A的原因)
AP经典框架:springcloud、Eureka
目前为止:springcloud比较适合中小型互联网公司快速搭建;
BASE:对应帽子理论的解决思想理论(用于解决CAP不可协同性)
BASE是互联网实际操作过程中不断发展而成,即前辈经验积累而成;
•如果说我们用化学的角度去衡量一致性的问题,那么ACID 就是(酸),而BASE理论就是(碱)。
•BASE思想解决了CAP理论所提出的分布式系统的一致性和可用性不可兼得的问题。
•BASE是Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent(最终一致性)三个短语的简写,BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
BASE中的三要素:
•BA: 基本可用,应用策略保障请求可以执行;
•S:软状态,这个状态可以在一段时间内不同步,业务可以容忍;
•E:最终一致,在一定的时间窗口内,数据达到最终的一致性即可。