CAP理论：一个分布式系统不可能满足一致性（consistency）、可用性（Availability）、分区容错性（Partition tolerance）这三个基本需求。一般分区容错性P是分布式系统需要强保证的内容，那么剩下的就是在C和A中间做取舍。
一致性可分为：
1、强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。
2、单调一致性（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可 获取的数据顺序必是单调递增的。
3、会话一致性（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值 会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。示例case：php的session概念。
4、最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
5、弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。
2PC（二阶段提交）：准备阶段和提交阶段。
第一阶段：提交事务请求阶段
a.协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
b.各参与者节点执行事务操作，并将Undo信息和Redo信息写入事务日志中。
c.各参与者向协调者反馈事务询问的相应。如果参与者成功执行了事务操作，则反馈协调者YES响应，表示事务可以执行；如果参与者事务操作执行失败，则返回协调者NO响应。
第二阶段：执行事务提交
如果各参与者反馈的都是YES响应，则就会执行事务提交。
a.发送提交请求。协调者向所有参与者发出Commit请求。
b.事务提交。参与者接受到Commit请求后，会正式执行事务提交操作，在完成提交后，释放资源。
c.完成事务。协调者接收到所有参与者反馈的ACK消息后，完成事务。
中断事务：假如有反馈者向协调者反馈了No响应，或等待超时，则会中断事务。
a.发送回滚请求。
b.事务回滚。参与者接收到Rollback请求后，会用第一阶段记录的undo信息来执行事务回滚操作
c.反馈事务回滚结果。回滚后向协调者发送ACK消息。
d.协调者收到反馈的ACK消息后，完成事务中断。
2PC存在的问题：同步阻塞（各参与者无法进行其他任务操作）、单点问题（协调者出现问题，整个系统无法运转）、数据不一致（协调者发送部分commit请求，挂了，其他参与者没收到）、太过保守（任意节点的失败都会导致整个事务的失败）
3PC（三阶段提交）：准备阶段，预提交阶段和do提交阶段。
与2PC相比，3PC在准备阶段接收到是否可以执行执行事务的询问后，各参与者并没有立即执行事务，而是进入预提交事务阶段，等待协调者发送第三阶段的doCommit请求，当接收到协调者doCommit请求后，正式提交事务，并向协调者反馈ACK。
在进入阶段三时，如果协调者出现问题，或协调者与参与者之间出现网络故障，参与者在等待超时之后，会进行事务提交。
3PC存在的问题：假如协调者出现问题，参与者默认提交事务，仍然会有数据不一致问题。
网友评论