joyblur的博客

Gossip协议：流言蜚语，原来也可以实现一致性有一部分同学的业务在可用性上比较敏感，比如监控主机和业务运行的告警系统。这个时 候，相信你希望自己的系统能在极端情况下（比如集群中只有一个节点在运行）也能运行。 回忆了二阶段提交协议和 Raft 算法之后，你发现它们都需要全部节点或者大多数节点正常 运行，才能稳定运行，那么它们就不适合了。而根据 Base 理论，你需要实现最终一致性， 怎么样才能实现最终一致性呢？在我看来，你可以通过 Gossip 协议实现这个目标。Gossip 协议，顾名思义，就像流言

一致哈希算法：如何分群，突破集群的“领导者”限制？如果我们通过 Raft 算法实现了 KV 存储， 虽然领导者模型简化了算法实现和共识协商，但写请求只能限制在领导者节点上处理，导致了集群的接入性能约等于单机，那么随着业务发展，集群的性能可能就扛不住了，会造成系 统过载和服务不可用，这时该怎么办呢？其实这是一个非常常见的问题。在我看来，这时我们就要通过分集群，突破单集群的性能限制了。说到这儿，有同学可能会说了，分集群还不简单吗？加个 Proxy 层，由 Proxy 层处理来自 客户端的读写请求，接收到读写

Raft算法（三）：如何解决成员变更的问题？在日常工作中，你可能会遇到服务器故障的情况，这时你就需要替换集群中的服务器。如果 遇到需要改变数据副本数的情况，则需要增加或移除集群中的服务器。总的来说，在日常工 作中，集群中的服务器数量是会发生变化的。讲到这儿，也许你会问：“Raft 是共识算法，对集群成员进行变更时（比如增加 2 台服务器），会不会因为集群分裂，出现 2 个领导者呢？”在我看来，的确会出现这个问题，因为 Raft 的领导者选举，建立在“大多数”的基础之上，那么当成员变更时，集群成员发生

Raft算法（一）：如何选举领导者？Raft 算法属于 Multi-Paxos 算法，它是在兰伯特 Multi-Paxos 思想的基础上，做了一些简 化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理 解和算法实现上都相对容易许多。除此之外，Raft 算法是现在分布式系统开发首选的共识算法。绝大多数选用 Paxos 算法的 系统（比如 Cubby、Spanner）都是在 Raft 算法发布前开发的，当时没得选；而全新的系统大多选择了 Raft 算法（比如 Etcd、Cons

Paxos算法（一）：如何在多个节点间确定某变量的值？提到分布式算法，就不得不提 Paxos 算法，在过去几十年里，它基本上是分布式共识的代名词，因为当前最常用的一批共识算法都是基于它改进的。比如，Fast Paxos 算法、 Cheap Paxos 算法、Raft 算法、ZAB 协议等等。而很多同学都会在准确和系统理解 Paxos 算法上踩坑，比如，只知道它可以用来达成共识，但不知道它是如何达成共识的。 这其实侧面说明了 Paxos 算法有一定的难度，可分布式算法本身就很复杂，Paxos 算法自然也不会

Paxos算法（二）：Multi-Paxos不是一个算法，而是统称Basic Paxos 只能就单个值（Value）达成共识，一旦遇到为一系列的值实现共识的时候，它就不管用了。虽然兰伯特提到可以通过多次执行 Basic Paxos 实例（比如每接收到一个值时，就执行一次 Basic Paxos 算法）实现一系列值的共 识。但是，很多同学读完论文后，应该还是两眼摸黑，虽然每个英文单词都能读懂，但还是不理解兰伯特提到的 Multi-Paxos，为什么 Multi-Paxos 这么难理解呢？在我看来，兰伯特