Log Replication 日志复制问题
Replicated state machine 复制状态机
分布式服务中，为了保证流量不会压垮服务器，会将一个server复制成很多副本同时提供相同的服务。多副本服务就会出现副本的一致性问题，比如client1将replica1的X值设置为1，而client2将replica2的X值设置为2，这样如果另一个客户client3从不同的副本获取到的X值可能是1也可能是2，这就导致了副本的一致性问题。
复制状态机就是用来解决副本的一致性问题的，每个副本都是状态机的实现，而且是确定状态机(Deterministic finite-state machine)。使用状态机来实现每个服务器的副本就保证了对相同的输入，每个副本都会产生一致的输出。并且，将每个客户端的请求汇总成一个序列，每个副本都按照这个序列来执行，这就解决了副本的不一致问题。
复制状态机（Replicated State Machine）是指多台机器具有完全相同的状态，运行完全相同的确定性状态机。它让多台机器协同工作犹如一个强化的组合，其中少数机器宕机不影响整体的可用性。复制状态机是实现容错的基本方法，被广泛应用于数据复制和高可用等场景，一直是工业界和学术界的关注热点。越来越多的系统采用复制状态机来实现高可用，如ZooKeeper、ETCD、MySQL Group Replication、TiDB等，各种复制协议和系统架构的研究也层出不穷。如何抽象一个复制状态机系统的架构，使之更加通用和易用呢？本文从复制状态机模型出发，结合一些业界的前沿研究，总结复制状态机系统的架构抽象，在系统架构设计时具有一定参考意义。
复制状态机一般通过复制日志来实现，简单地描述一下：leader将写请求封装成一个个的 `log entry`，然后将这些 `entries`复制到 `follower`（从节点），所有 `follower`都按照这个这个顺序执行其中的 `command`（指令），那么所有 `server`的状态一定是一致的，这就是 `raft`的做法。
复制过程：
1.客户端的请求包含了被复制状态机执行的指令，并转发给leader；
2.leader把指令作为新的日志，并发送给其他server，让他们复制。
3.假如日志被安全的复制（收到超过majority的ack），leader会将日志添加到状态机中，并返回给客户端；
4.如果follower丢失，leader会不断重试，直到全部follower都最终存储了所有日志条目。
当然，以上都是理想情况，如果出现崩溃、网络中断等情况，则可能出现日志不正常的现象，则需要考虑数据一致性和安全性问题。
- 本文标签： 日志 SpringCloud
- 本文链接： http://www.ysxbohui.com/article/317
- 版权声明： 本文由狂奔的程序猿原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
热门推荐
相关文章
近期评论
-
来自： 留言板
-
来自： 留言板
-
来自： 使用Drools进行规则文件开发
-
来自： mybatis批量插入数据
-
来自： 留言板
