这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
一、本堂课重点内容：
- 作业讲解
二、作业讲解
- 数据库里的一致性和分布式系统中的一致性有什么区别？？
答：
-
无论是单机事务的一致性，还是分布式事务的一致性，可以发现都是针对数据库的事务而言的，然而分布式系统的一致性是一个更加多元和复杂的场景，单纯的2PC或者3PC协议无法满足分布式系统中的其他一致性需求。
-
因此有CAP理论，讨论分布式系统的一致性涉及到更多的一个概念可能是共识。举个最简单的例子就是在一个或多个进程提议了一个值后，通过某种协议让所有进程对这个值达成共识（一致），为了就某个值达成共识，各个进程需要提出自己的提议，最终通过分布式一致性算法，使得所有正确运行的进程学习到相同的值。
-
分布式一致性算法例如Paxos、Raft以及Zab协议等。Paxos算法是布式系统中通用的一致性方案中的一种，它能达到某种最终一致性的状态。Raft，不同于Paxos直接从分布式一致性问题出发推导出来，Raft则是从多副本状态机的角度提出，使用更强的假设来减少需要考虑的状态，使之变的易于理解和实现。Zab协议 的全称是Zookeeper Atomic Broadcast（Zookeeper原子广播）。Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。
- 两阶段提交中，什么场景需要数据库管理员介入？
- 当事务超时或者其他问题导致事务无法完成时，需要数据库管理员介入。
- 三阶段提交缓和两阶段提交的哪两个问题？
- commit阶段网络分区带来的数据不一致问题
- 性能问题
- 什么场景适合乐观锁？什么场景适合悲观锁？
-
悲观锁：每次获取到数据的时候，都会担心数据被修改，所以每次获取数据的时候都会进行加锁，确保在自己使用的过程中数据不会被别人修改，使用完成后进行数据解锁。期间对该数据进行读写的其他线程都会进行等待。适合写入操作比较频繁的场景
-
乐观锁：每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁。但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新；如果没有被修改，则进行数据更新。期间该数据可以被其他线程进行读写操作。适合读取操作比较频繁的场景
- 在共识协议中，为什么说允许数据被覆盖会带来数据一致性问题？
- 因为数据被覆盖而不加锁，就会自然而言产生数据不一致的问题。
- RAFT协议中，Leader写成功日志Log20但未同步给Followers后宕机，Follower重新选举后产生一条新日志Log20，这时Leader重启，整个系统发现两种不一样的Log20的记录，请问如何区分并拒掉前面的Log20？
- 在RAFT协议中，如果Leader写入了一条成功日志Log20但没有在宕机前与Followers同步，随后Follower重新选举产生了一条新日志Log20，当原先的Leader重启时，系统发现两种不同的Log20记录，为了区分并拒绝先前的Log20，系统使用了term编号的概念。每个日志条目都被分配了一个term编号，这是在创建条目时leader的term。具有较高term编号的日志条目被认为是更近的，因此被采纳为正确的。在这种情况下，具有较高term编号的日志将被保留，而具有较低term编号的日志将被拒绝。
13.RAFT协议中，Stale读是如何产生的？该如何解决Stale读的问题？
- 脑裂现象：发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read
- 引入一个新的概念, region leader。
