说实话，学习分布式系统真不是件容易的事，但咱就是说弄懂了之后就hen有成就感。

当需要真正的全局顺序时往往需要基于共识的全局逻辑时钟——通过Paxos或Raft等协议，让集群就事件顺序达成一致。

分布式解决了规模和可靠问题，但也引入了新的复杂性。

这些问题Ke以归结为"四个不可靠"：通信不可靠、时钟不可靠、顺序不可靠、状态不可靠。

这就是著名的CAP定理的背景：在网络分区发生时系统必须在一致性和可用性之间选择。

值得注意的是可用性不仅指"Neng否响应"，也包括"响应是否足够快" ——一个需要等待10秒才Neng返回的系统，对用户而言可Neng和不可用没有区别。

单机的计算Neng力、存储容量和网络带宽dou存在物理上限。

当业务增长超出单机承载Neng力时我们需要将负载分散到多台机器上。

哈希分区对键进行哈希运算，根据哈希值决定归属分区。

优点是数据分布均匀，避免热点；缺点是牺牲了范围查询Neng力，只Neng支持点查。

范围分区将数据按键的范围划分。

例如用户ID -10000分到节点A，-20000分到节点B。

优点是支持高效的范围查询；缺点是容易产生热点——Ru果大量新用户注册，Zui后一个分区会承受巨大压力。

静态分区的分区数在系统启动时确定。

当负载变化需要调整时Ke以通过分区预分配进行Rebalance——预先创建远多于当前节点数的分区，扩容时只需将部分分区迁移到新节点。

强一致性确保所有节点kan到相同的数据视图。

实现手段包括同步复制和Quorum策略。

代价是延迟增加、可用性降低。

Zui终一致性允许副本暂时不一致，但保证Zui终收敛。

实现手段包括异步复制和Gossip协议。

优点是高可用低延迟，代价是应用需要处理读到旧数据的情况。

如何学习分布式系统?

Raft是目前Zui流行的共识算法，因其易于理解而广泛应用。

Raft的核心机制包括：Leader选举与任期机制, 日志复制.

Leader选举与任期机制: 集群在任一时刻Zui多只有一个Leader，每个Leader有一个单调递增的任期号。当Follower超时未收到Leader心跳时会发起选举，获得多数票者成为新Leader。任期机制确保了旧Leader不会干扰新Leader的决策。害，这个机制挺巧妙的，你懂的！

不是我说你得理解分布式系统的脉络和关键点，这样才Nenggeng好地学习它。 然后我就按照因果链的形式来重新整理了一篇关于分布式的文章。 从分布式解决的问题开始，再到常见的解决问题的手段，然后是分布式引入的新问题 ，Zui后是我自己认为的一些重要设计原则。 沿着本文的因果链思考：我们因为规模和可靠的需求而引入分布式；通过分区和复制来解决这些需求；分区和复制带来了通信、时钟、顺序、状态四个不可靠；我们用确认重试、逻辑时钟、窗口水位、共识算法等手段来应对这些不可靠；Zui后在工程实践中，我们接受不完美、追求概率性保证、坚持局部Zui大化。 说实话，这么多内容，一下子全掌握挺难的，但只要一步步来就没啥大问题。 这篇文章仅是纲要性质，Ru果要详细展开其中的每个方面需要一本巨著的篇幅，不过说不定哪天我还真有可Neng写本这方面的巨著 ：）哈哈哈，开玩笑啦！ 但咱就是说理解了这些基本的东西，再去深入学习其他相关的知识，就相对容易多了。