2021 L4
主备机制
两种方法：状态转移复制，复制状态机；
一般的错误：
- 主从复制可解决：fail-stop failures，宕机
- 不可解决：logic bugs，软件/配置出错，或者是恶意错误，即攻击；
挑战：
- 如何确定主节点真的挂了；（在分布式环境中，无法区分网络分区和机器故障）
- 如何同步主从一致 -> 必须保证顺序应用变更 && 解决非决定论（non-determinism）；
- 故障转移
状态转移复制：主节点每处理完一个请求，响应前先同步检查点（checkPoint）给从节点
复制状态机（RSM）：主节点先同步操作（operation）给从节点，让从节点执行操作后响应，自己在进行操作后响应客户端；
VM-FT:
主备断开后（网络原因，双方都没挂），都请求将存储服务器的test-and-set状态标志位 置1（原子操作），第一个到达的请求正常置1，第二个到达的一端会发现该标志位已经是1了，则会终止自己；第一个成功置1的机器会变为主机，并且请求复制新的备机出来（VMFT中的修复方案由人工执行），当备机生成后，test-and-set状态标志位会被复位为0（注意，第一次的主机如果没拿到to live状态，则会被及时回收，不会在标志位复位后才请求置1）；
将中断和有关数据和信息写入日志并在日志channel发送给备机，即保存在备机的缓存中，让中断可以被顺序执行，执行中断时，cpu将控制权交给OS（即虚拟机监视器）；
FT的Boot，日志channel（位于FT层）传送非确定性的指令，此时控制器会交给FT（trap），如磁盘io等，之后将指令的结果传给备机，确保备机使用相同的值（备机因此会落后）；是因为备机的FT不会执行该指令，所以需要直接获取寄存器哪里被修改（结果）并直接应用；（主机完成操作前，备机不会执行下一个日志）
主机响应client前，需要确保日志被送到备机，虽然备机不一定会立刻执行，但是要确保它拥有该日志，如果主机挂了，则备机会在一定时间内执行完剩下的日志赶上主机后，才对外提供服务；
客户端向主机发送请求后，会有FT将请求传给主机，并且通过日志channel传给备机，当主机完成后，将响应先发到FT，FT会等待备机返回接收到日志的响应后，才将主机的响应正常交回给客户端；
不应该在指令层使用复制状态机，而是在应用层应用；