1.CAP理论
C:一致性（Consistency） A:可用性（Availability）和分区容错性（Partition tolerance）。在一个分布式系统里面不可能同时满足CAP这三个基本需求，最多只能同时满足其中两项（在现在分布式系统中P是都会满足）。
一致性：是指数据在多个副本之间是否能够保持一致性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保持数据任然处于一致的状态。即针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性。反之若用户读到了旧数据（脏读），则为分布式数据不一致情况。
可用性：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性：分布式在遇到任何网络分区故障的时候，任然需要能够保证对外提供一致性和可用性的服务。在分布式系统中，不同节点分布在不同的子网络中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。
放弃CAP定理
放弃P：最简单的做法是将所有的服务在一个节点上
放弃A：即某个节点发生故障，则程序不可用
放弃C：放弃一致性是指放弃强一直性，保留最终一致性，数据最终会达到一个一致状态，但是在中间可能出现不一致的情况。
2.BASE理论
基本可用（Basically Available）、Soft state（软状态）、Eventually consistent（最终一致性）
基本可用：值分布式系统发生故障的时候，允许损失部分可用性。
① 响应时间上的损失②功能上损失 例如降级操作
软状态：即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
最终一致性：最终一致性是指系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
最终一致性的5个变种
因果一致性：进程A更新通知进程B，那么进程B对该数据的访问能够获取到进程A更新后的值，B进程更新要基于更新后的值。
读已之所写：进程A更新数据之后，进程A读取的最新值，不能是旧值
会话一致性：系统保证在同一个有效会话中实现“读已之所写”的一致性。
单调读一致性：一个进程从系统中读取一个值后，那么系统对进程后续的任何数据访问不应该返回更旧的值。
单调写一致性：系统保证同一个进程的写操作被顺序执行。
3.分布式一致协议
2PC提交：二阶段提交，顾名思义二阶段提交是将事务的提交过程分成了两个阶段来处理。
阶段一：提交事务请求
1.事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2.执行事务
各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。
3.参与者向协调者反馈事务询问的响应。
如果参与者成功执行了实务操作，那么就反馈Yes，表示事务可以执行，否则返回No。
阶段二：执行事务提交
假如协调者从所有的参与者获得反馈都是Yes响应，那么就会执行事务提交。
1.发送提交请求
协调者向参与者节点发出Commit请求
2.事务提交
参与者接收到Commit请求后，会执行事务提交操作
3.反馈事务结果
4.完成事务
协调者接收到参与者反馈的Ack信息后，完成事务。
中断事务
假如有一个参与者相协调者反馈了No响应，或者在等待超时之后，协调者无法接收到所有参与者的反馈响应，那么就会中断事务。
1.发送回滚请求
协调者向所有参与者节点发出Rollback请求。
2.事务回滚
利用Undo信息来执行事务回滚操作
3.反馈事务回滚结果
4.中断事务
协调者接收到所有参与者反馈的Ack消息后，完成事务中断。
优点：原理简单，实现方便
缺点：同步阻塞、单点问题、数据不一致、太过保守
同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。
单点问题：一旦协调者出现问题那么整个阶段提交将无法运转，在阶段二中出现故障（即阶段一完成后阶段二开始之前），那么其他参与者将会一直处于锁定事务资源状态，而无法继续完成事务操作。
数据不一致问题：在阶段二，执行事务提交之后，发生网络故障或者协调者崩溃，导致只有部分参与者接收到Commit请求。这部分收到Commit请求的参与者就会进行事务提交，而其他没有收到Commit请求参与者则无法进行事务提交。于是整个系统出现了数据不一致性问题。
太过保守：在阶段一事务提交询问过程中，参与者发生故障导致协调者无法获取所有参与者响应信息的话，协调者只能依靠自身的超时机制来判断是否中断事务。即没有完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
3PC提交
3PC提交是2PC提交的改进版，将二阶段“提交事务请求”一分为二，形成了CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。
阶段一：CanCommit
1.事务询问
协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并等待响应。
2.各参与者向协调者反馈事务询问的响应。
可以进行事务提交，反馈Yes状态，进入预备状态，否则返回No
阶段二：PreCommit
协调者根据参与者的反馈来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能。
1.执行事务预提交
如果参与者响应都是Yes，就会执行预提交。
1.协调者发送预提交请求
协调者向所有参与者发送PreCommit请求，并进入Prepared阶段
2.事务预提交
参与者接受到PreCommit请求后，会执行日志操作，并将Undo和Redo信息记录到日志信息中去
3.参与者向协调者反馈事务执行结果
2.中断事务
参与者反馈No，或者在等待超时之后，协调者无法接收到所有参与者的反馈响应。
1.中断请求
协调者向参与者发送abort请求
2.中断事务
无论是收到来自协调者的abort请求还是参与者等待协调者请求过程中出现超时等待，参与者都会中断事务。
阶段三：doCommit
该阶段进行真正的事务提交，会存在两种情况。
1、执行事务提交
参与者在阶段二反馈都为Yes
1.发送提交请求。
协调者向参与者发送doCommit请求，自身从预提交状态转换到提交状态
2.事务提交
3.参与者向协调者返回结果
4.完成事务提交
2、中断事务
协调者接收到了参与者反馈的No响应，或者在等待超时之后，协调者无法就到到所有参与者的反馈响应。
1.发送中断请求
2.事务回滚
3.反馈事务回滚结果
4，事务中断
需要注意：一但进入阶段三，可能会存在以下两种故障
1.协调者出现问题
2.协调者与参与者之间出现网络故障
无论哪种情况，最终都会导致参与者无法及时收到来自协调者的doCommit或abort请求，参与者都会在等待超时之后，进行进行事务提交。
优点：降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点：参与者接收到preCommit请求后若协调者和参与者出现网络故障，参与者会进行事务提交，从而导致数据不一致。