共 5 篇相关文章
这篇从金融数据库的视角出发，探讨了如何在实际工程中打破CAP理论的悲观论断，实现“持续可用”。作者首先明确了金融级数据库的两大支柱：强一致性（保证ACID）和高可用性（秒级故障恢复）。针对CAP理论中一致性与可用性的矛盾，文章指出CAP中的A（任何节点都须响应）与工程实践中的高可用（HA）存在差异——通过快速剔除故障节点、依赖多数派存活继续服务，系统仍能满足业务需求。 文章对比了两种实现路径：传统的共享存储方案虽成熟但成本高且无法跨机房；而基于Paxos的分布式方案则通过强同步与多数派选举，能在容忍单IDC故障的同时保持强一致与高性能。作者结合实践经验指出，若架构设计得当（如OceanBase的实现），强同步带来的额外延时可控制在同城0.5ms左右，吞吐量影响低于10%。 文章最终结论是：在同城环境下，采用Paxos协议的系统能够做到持续可用；而在异地场景，由于网络延迟，仍需根据业务需求在一致性与可用性之间做出权衡。
Paxos协议以其晦涩难懂而闻名，但这篇技术博客提供了一个清新的视角：用逻辑时钟来重述它。作者认为，一旦从带时钟同步的RPC协议出发，复杂的共识流程就变得直观起来。 文章首先构建了一个基于逻辑时钟的通信框架。它引入一个全局计数器（globalClock）来产生全局递增的时间戳，规定所有网络消息必须携带时间戳，且接收方拒绝处理“过时”的请求。这个简单的同步机制，为后续的协议设计打下了确定性基础。 在此基础上，Paxos的两个阶段被清晰地映射为两类带时钟的请求。Proposer在Prepare阶段（设置时钟、广播提案号）和Accept阶段（发送具体提案）中，都遵循“时钟必须严格递增”的规则。Acceptor则依据收到的消息时间戳与本地时钟的比较，来决定是接受还是拒绝。这样一来，协议中复杂的冲突避免和提案推进，被转化为了对时钟值的比较和递增操作。 更进一步，文章指出可以摆脱中心化的全局时钟服务。每台机器的本地时钟可由一个二元组（轮次编号roundNumber, 服务器ID）构成。通过定义先比较轮次再比较ID的规则，保证了分布式环境下时间戳的全局唯一性和单调性，使得整个协议更加贴近实际部署场景。 总而言之，这种重述方式将分布式共识中抽象的“提案编号”竞争，转化为对逻辑时钟值的单调递增和比较操作，让Paxos协议的内在逻辑——即如何利用确定的全局顺序来避免冲突、达成一致——变得异常清晰。
这篇讲的是分布式协调框架ZooKeeper如何在实际项目中“物尽其用”。作者从ZooKeeper基于Paxos算法实现强一致性的核心特性出发，系统地梳理了它在分布式环境中的多种典型应用场景。 与单纯的概念介绍不同，文章的价值在于结合了作者身边的真实项目例子，对这些场景进行了归类。它点明了一个重要事实：ZooKeeper的许多用法（比如作为配置中心、命名服务或分布式锁）并非其设计之初就规划好的，而是广大开发者在实践中，根据框架特性不断摸索和总结出来的“奇技淫巧”。 如果你想了解ZooKeeper除了基础文档之外，还能在哪些具体的架构环节发挥作用，这篇文章提供了一个清晰的图谱。作者也借此邀请读者分享自己的实战经验，共同探讨这个框架的更多可能性。
这篇讲的是Redis在性能已经很极致的情况下，又引入了一种新的存储模式——diskstore。作者从Redis作者antirez持续高强度的开发活动切入，指出他不仅在新的cluster代码里融入了Dynamo与Paxos的核心思想，更在持久化层面提出了diskstore方案。 文章对比了Redis与Memcached的发展态势。在Memcached多年缺乏重大更新、难以应对Web 2.0时代复杂需求的背景下，Redis通过diskstore等持续演进，在数据可靠性、扩展性和复杂数据结构支持上建立了明确优势。这使得原本需要技术人员为Memcached做大量额外适配工作的场景，现在有了更开箱即用的选择。 核心来看，diskstore模式平衡了Redis原有的内存高速与持久化存储的需求，而融入分布式共识思想则预示了其向更大规模系统演进的方向。文章通过这一技术演进案例，展现了高性能系统在架构层面如何通过持续创新来保持生命力。
这篇讲的是Paxos算法如何在实际的大型分布式系统中“落地”。文章开篇就点出Paxos在分布式算法领域的核心地位，并以Google Chubby的实践作为引子，探讨了在真实工程环境中应用Paxos所面临的共性挑战。 作者并没有停留在算法理论层面，而是聚焦于具体的场景拆解。比如，在构建高可用的分布式锁服务、维护全局一致的配置中心，或是处理集群节点动态增减时，Paxos及其变种如何成为解决数据一致性难题的关键。文章分析了在这些场景下，为什么传统的单点或简单复制方案会失效，而Paxos通过其多数派投票和提案编号机制，能有效容忍节点故障和网络分区，确保系统在异常情况下仍能达成一致。 特别值得注意的是，文章可能还探讨了工程化落地的取舍，例如性能与一致性的平衡、Multi-Paxos的优化思路，以及像ZooKeeper（基于ZAB协议）和Chubby等著名系统如何对经典Paxos进行适应和改进。这使得内容不仅讲清了“是什么”，更说明了“怎么用”以及“为什么这么用”。 通过结合具体的系统案例和工程约束，文章将抽象的算法原理具象化为可触摸的架构决策，为理解大规模分布式系统的心脏如何跳动提供了清晰的脉络。
