分布式事务（一）CAP

1998年，计算机科学家Eric Brewer（埃里克-布鲁尔）提出，分布式系统的三个特性：

• Consistency，一致性
• Availability，可用性
• Partition tolerance，分区容错性
  Eric Brewer给出CAP定义：
  三特性同时只能满足两个
  就像三个圆互相两两相交，但是没有共同相交的区域。
  
  如图，可以选择CA，CP，AP，但是不能选择CAP

Partition tolerance 分区容错性

一个学术的概念，一个多个节点组成的分布式系统中，如果某一节点因为网络异常，网络波动，断电，崩溃，宕机等原因出现不能通信，称为发生分区。

在分布式系统的定义中，如果发生这种分区，分布式系统的其他节点要可以继续提供服务，而不是整个分布式系统挂掉，否则不能称作是分布式系统。

所以分区容错性是分布式系统必需要满足的特性。

而满足CA系统的，大多数是关系型的数据库RDBMS，或者基于RDBMS的单节点应用。

如图，G1、G2两个节点和client客户端组成一个分布式系统，G1、G2之间通过网络通信。
分区：G1、G2不能通信时，叫产生分区。
分区容错：G1、G2产生分区，继续提供服务
分区不容错：G1、G2产生分区，不再提供服务

需要注意的是，分区必然发生，单不是总是发生，当没有发生分区时，分布式系统是可以同时满足CA的。

• 分布式系统，一组独立的计算机，作为整体提供服务，如果一个计算机一样
• 分布式系统，构建在网络之上，必然包含分区容错性。否则不能再称为为分布式系统，所以P通常必选。
• 实践中，分布式系统通常CP或AP

Consistency 一致性

G1，G1两个节点和client组成一个简易的分布式系统，G1，G2的某一个数据初始值是vo，写在要写为v1

1. client向G1写入v1，G1值改变为v1
2. G1通过网络向G2同步v1
3. client从G1节点读取数据，读到v1
4. client从G2节点读取数据获取到v1

一致性：写数据之后，从任意节点读到写入数据。

Availability 可用性

某一时刻，任意节点，只要收到请求，就要响应
A，C互相矛盾，发生分区时，保证A就要放弃C，保证C就要放弃A

AP之Eureka

eureka服务注册服务发现组件使用AP模式

如图四个应用application1 applicaiton2 applicaiton3 applicaiton4四个应用，通过eureka client和包括三个节点的eureka集群进行服务注册服务发现活动，服务之间通过rpc远程调用。

eureka之间通过replicate进行数据复制

• Register：服务注册，自己的IP和端口注册给eureka
• Renew：发送心跳
• Cancel：服务下线
• Get Registry：获取注册信息
• Replicate：Eureka集群数据同步
• RPC：远程调用

当eureka集群中的某一个节点发生分区时，eureka节点各自提供服务注册服务发现功能，此时eureka节点之间的数据可能不一致，服务发现会出现异常。

CP之zookeeper

zookeeper的设计，在发生分区时，保证一致性。
下图描述，三个zk节点组成的Zookeeper集群中，有三个客户端在读写数据，在一次写数据的过程中zk如何保持一致性。

1. 客户端发起写数据请求
2. 客户端请求到Follower节点时，转发请求到Leader节点
3. Leader节点发起修改数据提议
4. Follower节点针对提议给出确认
5. Leader节点发起commit操作
6. 返回状态到客户端
   特殊名词

• proposal，提议，Leader将请求头，事务体，zxid和请求本身序列化到proposal对象中，作为对zk状态变更的一次提议。
• ack，Acknowledge character，确认字符
• commit，zk确认提议可以提交，发送commit消息，指示follower提交变更

对于2n+1个节点的zk集群，发生分区时：

• 如果有超过n+1个节点正常，则正常写数据，客户端连接到分区节点，读不到最新数据，弱一致性
• 如果有超过n+1个节点分区，则集群不可用
• Leader发生分区则重新选举，集群不可用

AP&CP之nacos

如图一个三个nacos节点的nacos集群，nacos控制台，三个应用applcation1两个，application2，applicaiton3共四个节点，application1一个节点作为临时实例注册到nacos，一个applcaiton1作为永久实例注册到nacos，application2和application3作为临时实例注册到nacos。

服务注册方面，临时实例通过AP的方式注册到nacos集群，nacos集群通过异步的方式同步数据，发生分区时，分区nacos独立提供服务注册服务发现功能。

配置方面，上图描述了发布配置的过程，在nacos多个节点保持同步

1. 控制台发起发布配置请求
2. 请求到Follower节点时，转发到Leader节点
3. Leader节点提交raftlog到Follower节点
4. Follower节点返回同意raftlog修改请求
5. Leader，Follower各个节点apply写数据
6. Leader节点返回响应到收到请求的Follower节点
7. 返回响应大控制台

Nacos1.0.0开始支持AP、CP和Mixed混合模式
根据功能：

• 配置管理，元数据管理基于CP模式
• 服务管理，永久实例基于CP模式
• 服务管理临时实例，基于AP模式
• CP模式下Leader分区重新选举，Follower节点分区超过半数不可用，集群不可用

需要指出的是，nacos不是同时支持CAP三要素，而是部分功能支持CP，部分功能支持AP

nacos临时实例和永久实例

临时实例，通过心跳保活，不会持久化实例信息，当没有心跳时剔除。如果又上报心跳，则又注册实例。
永久实例，实例信息持久化到nacos服务端，即时实例不存在，也不会删除，只是修改健康状态。
临时实例，分区发生时，也可以进行注册，下线，获取注册服务信息等活动

raft
raft是一种分布式系统的共识算法，多个服务器节点之间通过投票，选举，达到共识的算法。

常见的AP CP系统

发生分区时满足AP

• Cassandra
• Kafka（通过配置满足AP）
• FastDFS
• Eureka
• CouchDB
  发生分区时满足CP
• HBase
• Redis
• MongoDB
• Zookeeper
• Consul
• Kafka（通过配置满足CP）
• ElasticSearch
• HDFS

（完^_^）