mit 6/824 lec 6 raft1
作者：互联网
6.1 脑裂 (split brain)
- 容错系统，存在多个副本，但是需要单个节点来决定在多个副本中，谁是主(Primary)
- 这种情况下会产生脑裂
- 脑裂的解决方式:
- 构建不可能出现故障的网络。比如连接了CPU和内存的线路就是不可能出现故障的网络，要花很多钱
- 人工解决。在客户端需要等待两个服务器响应的情况下，如果只有一个服务器响应，那么不要执行操作，要运维去修复。
6.2 过半票决 (Majority Vote)
- 网络分区是指，网络出现故障，将网络分割为两半，网络两边独立运行，不能够访问对方，那么形成了两个网络分区
- 过半票决，是raft论文的基本概念，以及实现自动恢复，同时避免脑裂的多副本系统。，一般适合于服务器数量是奇数的网络，要点在于在任何时候为了完成任何操作，你必须凑够过半的服务器来批准相应的操作，逻辑是
- 通用的方程是如果系统有2 * F + 1个服务器，那么系统可以最多接收F个服务器，仍然可以正常工作
- 由于每次操作需要过半的服务器来批准，那么每一个操作对应的过半服务器，必然至少包含一个服务器存在于上一个操作的过半服务器中
6.3 Raft初探
- Raft会以库的形式呈现在服务中。如果你有一个基于Raft的多副本服务，那么每个副本将会由两部分组成：应用程序和Raft库。应用程序负责接收RPC或者其他客户端请求，不同节点的Raft库之间相互合作，来维护多副本之间的操作同步。
- Raft在应用程序底层，提供容错。Raft本身会保持状态，也就是会记录状态日志
- 对于一个三个节点的raft kv服务器集群而言，一个请求给服务器集群，
- Leader节点的应用程序会将来自客户端的请求向下送给Raft层，
- 并且将这个操作提交到多副本的Raft日志
- 当Leader的节点直到过半的节点有这个操作的拷贝之后，那么Leader的Raft层会通知应用程序，也就是Key-Value数据库，来说明：刚刚你提交给我的操作，已经提交给过半副本了，现在可以真正执行这个用户请求了
- 在Leader节点被提交后，每个副本节点的Raft层都会将相同的操作提交到本地应用程序层
6.4 Log同步时序
- 从时序的角度看Raft Log同步，
- Leader的Raft层会发送一个添加日志(AppendEntires)的RPC到其他两个副本,
- 之后Leader会等到其他副本响应，直到过半(包括Leader节点自己)的节点响应返回
- Leader在收到过半服务器的正确响应之后，Leader会执行客户端请求，并将结果返回给客户端
服务器3也会将响应返回给Leader，这个响应有用但不需要等待
- 对于Leader之外的服务器，在Leader提交之后，那么Leader会去将这个消息通知给其他副本，这个committed消息会被夹带在下一个AppendEntries中
- Leader需要给副本发送心跳？对于客户端的请求稀疏的情况需要Leader发送心跳包，心跳包用来告诉follower当前Leader还活着,当follower的定时器过了一段时间没有收到Leader的心跳包，那么之后就会发送新Leader的选举
6.5 日志
- Log的作用：
- Log是Leader来对操作排序的一种手段。即如果有是个客户端同时向Leader发出请求，那么Leader必须确认一个顺序，其他副本都会遵从同样的顺序，Log是一些按照数字编号的槽位(类似数组)
- Log对于非Leader的副本而言，一些还未执行的操作，会放在其中，直到Leader发送了新的commit号，这些操作可能会被丢弃
- 对于发送给副本的操作，可能需要重新传送，那么Log中记录了可能需要重传的操作
- Log对于故障节点的恢复，一个Raft节点故障重启之后，Log保留在磁盘中，那么Log会被Raft节点用来从头执行其中的操作进而重建故障前的状态，实现持久化
- 确认操作？确认是指Leader发来的committed消息，那么确认与累计可以很快
必要时，需要follower去发送消息给Leader进行流量控制
标签：副本,节点,Log,Leader,lec,服务器,824,Raft,mit 来源： https://www.cnblogs.com/mlmz/p/16297906.html