读书笔记-从paxos到zookeeper

1. 分布式架构

目录

1. 分布式架构

2. 2PC和3PC

---

• 分布式系统的概念：分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅通过消息传递来进行通信和协调的系统。《分布式系统概念与设计》

• 分布式系统的特征：分布性，对等性(没有主从之分)，并发性，缺乏全局时钟，总会有故障发生

ACID：

    atomicity：原子性。最小操作单元，操作不会被打断，要么全成功执行，要么全部不执行。

    consistency：一致性。执行前后的状态只可能是由A->B，中间不会被打断，不可能由A进入C状态。

    isolation：隔离性。事务之间互不影响。

        未授权读取：事务A可以读到事务B执行过程中的变量值。

        授权读取：事务A可以读到事务B完成前后的变量值，但是不能读到事务B执行过程中的值。

        可重复读取：事务A在执行过程中，读到的总是在事务A执行时刻读到的值。无论该值在事务B中是否被修改。

        串行读：事务无法并发，只能一个一个串行化执行，所以一个变量也不可能在多个事务中被修改。

 

durability：持久性。一旦事务执行成功，那么对应数据的变更应该是永久性的。如果DB挂掉，只要还可以重启那么应该就可以恢复到事务执行以后的状态的。

cap理论：一致性，可用性，分区容忍性。一个分区通常可以理解为时一个子网，例如一个机房。分区内部通过内网连接。分区之间通过外网例如光缆进行数据同步。

base理论：基本可用，软状态，最终一致性。

    基本可用：不等于系统不可用，只是损失部分可用性。例如：响应时间损失(耗时变大，页面打开变慢)，功能损失（部分功能被降级，比如没有广告词）

    软状态：允许系统中的数据存在中间状态（非实时强一致性），但它不影响系统的整体可用性。允许系统不同节点间数据的同步存在延时。

    最终一致性：经过一定时间以后可以保证不同分区间数据的最终一致。

 

总的来说base理论主要面向大型高可用可扩展的分布式系统，和传统事务的acid特性是相反的。它完全不同于acid的强一致性，提出了牺牲强一致性来获得更好的可用性，允许短时间内的数据不一致，但保证了数据的最终一致。但在实际业务场景中，不同系统和模块单元对数据一致性的要求是不同的，所以通常base和acid理论会被结合在一起使用。

 

https://www.cnblogs.com/shoshana-kong/p/10516404.html mysql事务隔离级别说明。

 

2. 2PC和3PC

2PC：

• 提交事务申请

  • 事务询问。协调者向所有事务参与者询问是否可以执行事务操作，等待响应。

  • 执行事务。各参与者执行事务操作，将undo和redo信息记录到事务日志中。

  • 参与者想协调者返回执行结果。

• 执行事务提交(发送提交和回滚请求是根据第一阶段结果而定的)

  • 协调者向参与者发送提交/回滚请求。

  • 参与者提交/回滚事务。正式提交事务。

  • 反馈事务提交/回滚的结果。

  • 完成/中断事务。

优点：原理简单，实现方便。

缺点：同步阻塞，单点问题。

二阶段提交中每个参与者在提交完事务以后，都需要等到其他参与者的结果以后才能进行接下来的操作。否则是一直阻塞等待的。

执行完阶段一如果协调者挂了，那么所以有的参与者都是被挂起状态的。

如果协调者在第二阶段只给部分参与者发送完请求以后就挂了，那么会有数据不一致性的问题产生。

 

 

3PC：

• CanCommit

  • 协调者向参与者发起是否能执行事务的询问。

  • 参与者想协调者反馈是否可以执行事务。

• PreCommit(如果CanCommit阶段有参与者无法执行事务，那么以下步骤改为中断事务的操作)

  • 发送预提交请求。

  • 事务预提交。执行事务操作，记录undo和redo信息到事务日志中。

  • 参与者反馈事务执行的响应。

• DoCommit(如果PreCommit阶段有参与者无法执行事务，那么以下步骤改为中断事务的操作)

  • 发送提交请求。

  • 事务提交。

  • 反馈事务提交结果。

  • 完成事务。

    优点：降低了阻塞的范围，并且可以在单点故障以后继续达成一致。(第二阶段只要执行完成，那么一定会提交请求。)

    缺点：在收到PreCommit消息以后如果出现分区，那么最终收到PreCommit的消息仍会提交，所以可能会出现不一致的情况。

 

paxos算法：

• proposer生成一个提案n，然后向Acceptor超过半数的子集发送编号为n的prepare请求。

• 如果一个acceptor收到一个提案n，且n大于acceptor所相应过得所有prepare请求编号，那么它会返回已响应过的最大的编号。并且它不会再批准任何小于n的提案。

• 如果proposer收到半数以上acceptor返回编号为n的提案，那么他会发送一个针对编号n提案的accept请求给acceptor。

• acceptor只要没有回复过大于n的提案，它就可以通过这个提案。

• 另外如果propose生成的提案n无法获得半数以上acceptor的投票，那么proposer会生成一个新的提案m，继续发送prepare请求。

这里注意提案的编号都是递增的。