分布式事务

问题：
1、性能问题
2、单节点可靠性问题

解决：扩展服务器，通过增加服务器数量分担性能上问题，解决单点可靠性问题。

路径：
1、数据分区，把数据分片分不到不同服务器上
2、数据镜像，实现不同服务器系统数据服务

数据分片无法解决数据丢失问题，数据高可用性需要通过数据冗余来实现，
但数据冗余会带来数据一致性问题，数据一致性又会影响性能。

1、数据可靠性：容灾、多副本、自动切换failover
2、数据一致性：事务处理
3、性能：吞吐量、响应速度

上述3者是无法同时实现的。

数据一致性模型：
1、弱一致性 异步处理，性能好，控制复杂
2、最终一致性 异步处理，性能好，控制复杂
3、强一致性 同步处理，性能差，控制简单

master-slave模式，一般都是实现最终一致性模型，通过master push数据或slave pull数据，如果在slave的pull周期内master宕机，则会出现丢失数据风险。
如果不允许丢失数据，则置slave read-only等待master恢复。
如果允许丢失数据，slave替换成为master，实现failover。
如果是计算节点，不包含数据，没有数据丢失和数据一致性问题，master-slave可解决单点故障问题。

master-slave也可以实现强一致性模型，更新master之后更新slave，两者成功则同步成功，如果slave失败，则标识slave不可用，并回复同步失败。
如果有多个slave，则可以允许部分slave同步失败，其他成功的slave可以提供冗余服务，不可用slave等同步后恢复可用状态。

master-master模式，多个master同时提供write/read服务，master之间通过异步数据同步实现最终一致。如果一个master宕机，另外一个master可以继续提供读写服务，但未同步数据可能存在丢失风险。
多个master对同一数据做修改可能出现版本冲突，可能需要开发者介入解决。

事务模型：
两段式提交模型：由协调者统一管理各个参与者状态
第一阶段：协调者询问各个参与是否可以执行提交操作，各个参与制接收到询问后，申请资源，给资源上锁，写redo、undo、log等操作

第二阶段：如果各个参与者确认可以执行提交，则协调者发送“提交操作”命令给参与，参与者接收到命令后，执行提交操作，并回复完成
如果有参与者拒接执行，则协调者发送“回滚操作”命令给参与者，参与者释放资源，并回复完成

两端式提交是强一致性模型，这带来两个问题
1、阻塞操作，影响性能
2、超时等待

为了解决上述问题，提出了三段式提交模型
1、将第一阶段的询问操作独立出来，这样整个操作分为
a、canCommit b、preComit c、doCommit
2、增加超时处理机制

paxos算法：
1、通过全局递增序列串化操作顺序
2、分为prepare和accept两个阶段，其实就是2pc的变体

prepare：询问各个参与制是否接受提案，参与者只处理接到的提案中值最大的提案，并回复yes

accept；提案者接到到半数以上参与回复的确认，则向所有accept发送accept request，如果没超过半数，则提案失败

参与者接到accept request，假如该提案是最新的，则执行该提案，否则拒接修改。

zk是一个master-slave结构

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
服务器5启动，后面的逻辑同服务器4成为小弟。