1.集群复制的两种方式
1.状态转移(State Transfer)：主 把所有的状态靠复制并发送给 从。
2.复制状态机(Replicated State Machine)：从有缺德状态，client发送操作给 主，主按照顺序发送到 从，所有的 从 执行所有的操作，如果初始状态相同，输入相同，则最后状态相同（raft就是采用这种方式）。
2.物理架构
两台物理机，以及共享磁盘
3.Deterministic replay
1.Non-Deterministic。比如虚拟中断，读取时钟等等，主从可能不一致的情况。
对于不确定的行的输入必须记录足够的信息来重放
1.事件发生时的指令的序号
2.日志类型。可能是不同网络数据输入，也可能是怪异的指令
3.数据。
4.FT 协议(FT Protocol)
1.日志不写入磁盘而是通过logging channel发给 从机，从机实时重放日志。
2.如果主机故障，从机接手，此时从机应该和主机状态完全一直并继续运行
3.主机必须在从机接收到了日志之后才会给client回复（也就是说一次完整的commit这些在分布式系统里似乎都是相似的）
4.从机无法判断主机是在宕机之前还是之后发送了最后的输出，从机可能会重新执行一次输出操作（VMware通过网络基础设施检测重复数据包，防止输出重传到客户端）。
5.发现与处理故障
通过udp心跳包和监控logging channel上的流量相结合来检测。（心跳超时或者流量停止则代表故障）
1.如果主机故障，从机必须重放日志，知道消费完最后一个日志，才能替代主机。
2.为了确保只有一个虚拟机成为主机避免脑裂，Vmware在共享存储上执行一个原子的 test-and-set锁指令。该操作每次只能向一台机器返回成功，但如果共享存储完蛋了，那就真的没了。
3.当一台虚拟机发生故障的时。VMware ft会在另一台物理机上自动启动新的备份虚拟机来回复冗余.
6.如何在在主机运行时启动一个状态相同的从机？
应Vmware提供的VNware VMotion的工具，允许在最小化中断的代价下，将运行中的虚拟机从一台服务器迁移到另一台服务器，允许将虚拟机克隆到远程主机上。该操作打断主机的时间不超过一秒。
7.logging channel
主机写日志到log buffer 从机从log buffer消费，如果从机读到空白日志则暂停运行，直到日志不为空。如果主机发先log buffer满了也会暂停运行直到日志被清除，这种暂停会影响虚拟机的客户端。因此，我们的实现必须最小化主机日志缓冲写满的可能性。
写满原因
1.带宽小，传输慢
2.从机执行慢，日志堆积多
当从机落后主机超过一秒的时候，减少主机cpu资源来减缓执行速度。
8.磁盘io的一些问题
1.非阻塞磁盘可以执行并发操作，但是同一磁盘位置的读写可能出现不一致。解决方案就是检测这类io，然后强制主从机器顺序一致，怎么检测论文没说。
2.虚拟上的应用程序或者操作系统操作磁盘的读写操作可能导致内存的竞争。使用一块大小和磁盘正在操作的内存大小一致的缓存（Bounce buffer）处理，我们在缓存力读数据，写的时候先写到缓存，缓存在去落盘。这个基本和数据库中buffer pool差不多的感觉。
3.磁盘io在主机上失败，主机故障从机接手了，发送错表明io失败，然后重试io
9.替代方案
1.不使用共享磁盘，那么磁盘间也需要同步。
2.在从机上执行磁盘读取，好处分担io操作的压力，坏处提高commit的难度，即如果主机上读取成功，从机读取失败怎么办。又添加了额外的杂程度。
网友评论