🏆本文收录于「滚雪球学SpringBoot」(全网一个名)专栏，希望能够助你一臂之力，帮你早日登顶实现财富自由🚀；同时，欢迎大家关注&&收藏&&订阅！持续更新中，up！up！up！！
🎬 前言 | 一致性选择的“选择题”：你真的选对了吗？
作为一名全栈开发者，想跟大家聊个现象，你在构建分布式系统时，是不是听到过各种关于一致性的讨论，那你们最终是强一致性还是最终一致性？其实说实话，无论是强一致性（Strong Consistency）还是最终一致性（Eventual Consistency），每种方案背后都有其适用的场景和权衡。当你在设计架构时，不同的选择可能意味着完全不同的系统表现，它们分别解决不同层面的系统需求，这点是毋庸置疑的。
你可能会问：“系统到底是应该保证强一致性，还是最终一致性？”
Good question！但这并没有一个标准答案——因为你面对的场景决定了你的选择。而决定选择的又是你面临的业务需求。
本篇文章我将深入探讨强一致性和最终一致性的设计选择，并且详细分析Paxos/Raft协议与CRDT/Event Sourcing分别适合什么场景，帮助大家更好地理解并决策何时选强一致性、何时选最终一致性。
🧩 什么是强一致性与最终一致性？
1️⃣ 强一致性（Strong Consistency）：每次读取的都是最新的！
强一致性是分布式系统设计中的“黄金标准”。它意味着，在一个分布式系统中，每个节点的数据必须在任何时候都保持一致。当你发起一个数据写入请求时，所有节点必须同时更新数据，保证每个客户端读取到的数据都是最新的。
特点：
- 数据同步更新：当数据更新时，所有副本必须立即同步。
- 读取操作始终返回最新的有效数据，无任何延迟。
- 牺牲了可用性，即系统必须保证所有节点在数据写入时都达成一致，可能导致一些写操作阻塞或出现延迟。
举个栗子：
假设你在银行系统中进行转账操作。假如你从A账户转账100元到B账户，系统需要确保A账户减少100元的同时，B账户增加100元。此时数据一致性是至关重要的，并且无论是哪个节点进行查询，都必须获得最新的账户余额，否则可能会造成账目错误。
2️⃣ 最终一致性（Eventual Consistency）**：允许短期不一致，最终达成一致
与强一致性不同，最终一致性容忍系统的暂时性不一致，它并不要求在每次数据更新时系统中的所有副本都保持同步。数据更新在不同节点之间传播存在延迟，但最终所有节点会在某个时间点达到一致。
特点：
- 容忍暂时不一致：系统可以接受在短时间内的数据不一致。
- 较高的可用性和容错性：即便部分节点失联，系统依然能够继续工作。
- 适合高并发和分区容错性要求高的场景。
举个例子：
你在社交平台上点赞，可能几秒钟后点赞才会在朋友的页面上显示，或者在高并发的场景下，多个用户点赞可能在不同节点上显示时间不同。但这并不影响整体的使用体验，因为最终数据会同步一致。
⚔️ 强一致性 vs 最终一致性：如何选择？
Paxos/Raft协议：实现强一致性的武器
🧱 Raft协议：
Raft，它是一种分布式一致性协议，其核心目标是确保在多个节点的分布式系统中，能够通过选举机制选举出一个领导者来保证一致性。领导者负责处理所有的写入请求，确保所有写操作按顺序同步到所有节点。Raft协议比Paxos协议要简单易懂，且更容易实现，已经成为很多分布式系统的一部分。
特点：
- 采用领导者选举，确保只有一个节点能够处理写入请求。
- 写入操作通过日志复制同步到所有节点，保证数据一致性。
- 在发生故障时，Raft能够迅速恢复，并继续确保一致性。
适用场景：
- 分布式数据库：如 Etcd、Zookeeper，它们通过Raft协议来保证数据的一致性和高可用性。
- 分布式协调：如分布式锁服务、分布式事务，需要确保写入的一致性。
🍃 Raft协议伪代码示例：
// Raft协议中，领导者节点将日志条目复制到各个跟随者
raft.AppendEntries(log_entry) -> leader sends log entries to followers;
🧱 Paxos协议：
Paxos协议，它是经典的分布式一致性算法，通过提出者、接受者和学习者的角色体系进行分布式协商，确保所有节点数据一致。尽管Paxos能够确保一致性，但它的实现比较复杂，更多的是理论上的概念，而实际应用中，Raft协议更加易于实现和理解。
适用场景：
- 高一致性要求的分布式系统，例如需要保证数据库或服务之间一致性的场景。
- 需要高可靠性和强一致性的事务系统。
CRDT/Event Sourcing：支持最终一致性的武器
🧱 CRDT（Conflict-Free Replicated Data Types）：
CRDT，它是一种分布式数据结构，设计用于保证最终一致性，即使在多个节点上并行更新数据，也能确保数据最终同步一致。CRDT的优势在于，它能在多个节点上并行执行修改操作，且无需协调，能够通过自动合并机制确保最终一致性。
特点：
- 无需锁机制，支持高并发操作。
- 自动解决冲突，确保最终一致性。
- 适合分布式系统中数据写入频繁的场景。
适用场景：
- 社交平台：如点赞、评论、动态等操作，这些操作对一致性要求不高，可以容忍一定的延迟和不一致，适合使用CRDT来实现最终一致性。
- 分布式缓存：如用户会话、商品库存等，能够容忍短期的不一致。
🍃 CRDT代码示例：
// CRDT计数器增加示例
let counter = new CRDT.Counter();
counter.increment(1); // 节点1增加
counter.increment(2); // 节点2增加
🧱 Event Sourcing（事件溯源）：
Event Sourcing，它是一种将系统的所有变化存储为事件的模式，适用于需要高可用性且对一致性有较低要求的系统。在这种模式下，系统状态通过一系列事件的组合来重建，而不是存储当前的状态数据。通过事件溯源，系统可以重建过去的每一个状态，适合最终一致性的场景。
特点：
- 以事件为中心，存储所有数据的变化历史。
- 支持异步处理，事件可以按顺序执行。
- 适合分布式环境下的数据同步和恢复。
适用场景：
- 复杂的业务流程系统：如金融审计、银行业务等场景，能够通过回溯每一个事件来重建系统状态。
- 日志系统和消息队列：比如 Kafka 等系统，通过事件溯源保证数据的最终一致性。
🍃 Event Sourcing代码示例：
-- 事件溯源：记录每一个库存变化事件
INSERT INTO event_store (event_type, payload)
VALUES ('InventoryUpdated', '{"product_id":1001, "quantity":-1}');
🧠 总结：如何选择强一致性或最终一致性？
在构建分布式架构时，面临选择强一致性还是最终一致性问题，其实答案取决于你系统的需求。简单来说，没有绝对正确的选择，只有最适合的选择。
-
强一致性（Paxos/Raft协议）：适用于对数据一致性要求高、对系统可用性要求相对较低的场景，典型应用如金融系统、分布式数据库、分布式锁服务等。
-
最终一致性（CRDT/Event Sourcing）：适用于高可用性和容错性要求高、可以容忍数据短期不一致的场景，典型应用如社交平台、分布式缓存系统、实时协作系统等。
所以真的没有哪个最好，而且有一点也是最重要的：真正了解你的业务需求，选对架构模型，才能确保系统的稳定性和可扩展性。
灵魂拷问：你的系统真的需要“强一致性”吗？还是说可以接受“最终一致性”的灵活性？欢迎诸位大佬评论区交流~
📣 关于我
我是bug菌，CSDN | 掘金 | InfoQ | 51CTO | 华为云 | 阿里云 | 腾讯云 等社区博客专家，C站博客之星Top30，华为云多年度十佳博主&最具价值贡献奖，掘金多年度人气作者Top40，掘金等各大社区平台签约作者，51CTO年度博主Top12，掘金/InfoQ/51CTO等社区优质创作者；全网粉丝合计 30w+ ；硬核微信公众号「猿圈奇妙屋」，欢迎你的加入！免费白嫖最新BAT互联网公司面试真题、4000G PDF电子书籍、简历模板等海量资料，你想要的我都有，关键是你不来拿。
-End-
