🏆本文收录于「滚雪球学SpringBoot」(全网一个名)专栏，希望能够助你一臂之力，帮你早日登顶实现财富自由🚀；同时，欢迎大家关注&&收藏&&订阅！持续更新中，up！up！up！！
🧩 一、深入理解强一致性与高可用性：你必须知道的基础概念
🌐 什么是强一致性？
在分布式系统架构中，强一致性意味着系统中的所有节点在任何时刻都能够访问到相同的数据。这是一个理想化的概念：它要求每次操作后，系统的所有副本都必须立即同步，确保数据在全局范围内的一致性。
举个简单的例子：
比如说在一个银行系统中，如果用户从账户A转账到账户B，强一致性要求：转账金额从账户A扣除后，账户B立刻到账。即使某个数据库节点宕机，系统也必须确保账户B的数据一致。这就是强一致性。
⚡ 强一致性的好处：
- 事务保障：强一致性确保了每一个数据操作的准确性和原子性；
- 防止数据错乱：通过强一致性，系统能够避免数据在多个副本之间产生不一致的状态，保证最终状态的正确性。
❌ 强一致性的挑战：
- 延迟高：每一次数据变更都需要同步，往往会导致操作的延迟；
- 性能瓶颈：当系统规模增大时，强一致性往往要求在所有节点之间进行同步，带来额外的网络通信和处理开销；
- 系统复杂性高：为了实现强一致性，通常需要使用分布式事务、两段提交等机制，增加了系统的复杂性。
🏃♂️ 什么是高可用性？
高可用性 （High Availability，简称HA），它是一种设计目标，它侧重于系统在面对部分故障时，仍然能够提供服务，并尽可能减少服务的中断时间。高可用性的系统通常有冗余备份机制，一旦某个节点出现故障，流量会被自动切换到其他健康的节点，确保用户能够继续正常使用系统。
举个栗子：
假设你在使用一个电商平台购买商品，而支付服务因为某种原因出现了故障，但是库存服务和订单服务仍然运行正常。用户依然可以继续下单，只是支付环节暂时不可用。虽然支付系统暂时出现问题，但整体系统仍然在运行，这就是高可用性的体现。
⚡ 高可用性的好处：
- 系统不容易宕机：即使部分服务出现故障，系统能够通过自动恢复机制保持运行；
- 适应高并发：高可用性系统通常能够承受更高的并发压力，因为它们具有自动故障转移和负载均衡功能。
❌ 高可用性的挑战：
- 数据不一致：为了保证高可用性，系统可能在某些时候允许不同节点的数据存在短暂的不一致状态；
- 复杂的故障恢复机制：为保证高可用性，系统需要额外的资源来监控和恢复故障节点，增加了运维的复杂性。
架构对比图：强一致性 vs 高可用性
如下给大家画张图，大家一眼便懂！以辅助大家理解：
✅ 架构图说明：左边是串行+事务确保强一致，右边使用异步/消息驱动提高可用性。
🧠 二、强一致性与高可用性：该如何在它们之间做选择？
如果大家面对这个问题，请问如何作答？
🏅 选择一：强一致性优先
适用场景：
- 金融领域：如银行、支付、证券等，系统中的每一笔交易都至关重要，不能有任何数据丢失或错误。例如，转账系统必须保证数据一致性，不能出现资金错乱的情况。
- 电商库存管理：如果库存数量错误，可能会导致超卖现象，影响用户体验。因此，在库存扣减操作上需要确保强一致性。
优缺点：
- 优点：系统能够保证数据的一致性，避免了"脏数据"产生，避免了数据错乱或错误更新；
- 缺点：强一致性通常伴随着较高的延迟，需要牺牲一部分系统的响应速度。
典型架构：
- 分布式事务（两阶段提交、TCC等）
- 强一致性保证（例如使用Zookeeper进行协调）
🏅 选择二：高可用性优先
适用场景：
- 社交平台：如Facebook、Twitter，数据一致性对这些平台的核心功能影响不大。用户可能看到过时的内容，但这不会影响大部分功能的正常使用。
- 内容分发系统：如视频平台、新闻平台，数据不一致的影响较小，因为即使是旧版本的数据也不至于影响用户体验。
优缺点：
- 优点：系统能在节点宕机或高并发的情况下保持高效响应，确保服务的可用性；
- 缺点：短时间内可能会出现数据不一致，最终一致性机制可能需要一定的时间来同步数据。
典型架构：
- 事件驱动架构
- 异步消息传递机制（如Kafka、RabbitMQ）
🛠️ 三、延迟预算分配：如何在两者之间找到平衡？
🔍 什么是延迟预算？
在高可用性与强一致性之间，我们无法得到"完美"的解决方案。延迟预算是指在系统中，允许的最大延迟时间。换句话说，它定义了系统中每个操作的容忍延迟。如果操作超出延迟预算，系统就必须进行回滚、重试或采取其他容错措施。
🔑 如何进行延迟预算分配？
-
明确业务优先级：
不同的业务场景对一致性和可用性的需求不同。通过分析不同业务流程的延迟容忍度，可以确定哪些服务可以接受较高的延迟，哪些服务必须保持较低的延迟。
-
合理设置延迟阈值：
根据系统的整体架构和业务需求，设定每个操作的延迟预算。例如，支付系统的延迟预算可能非常低，而库存查询操作的延迟预算可以适当放宽。
-
分配延迟预算：
对于每一个操作链路，我们需要分配合理的延迟预算，并确保这些操作能在预算范围内完成。可以通过优先级调度 、流量控制等手段来保证关键操作的延迟在预算内。
📝 示例：支付和库存扣减系统的延迟预算分配
java
public class DelayBudgetManager {
private final long paymentDelayLimit = 500; // 支付最大延迟500ms
private final long stockCheckDelayLimit = 1000; // 库存检查最大延迟1秒
public void processOrder(Order order) {
long startTime = System.currentTimeMillis();
// 处理支付操作
if (processPayment(order)) {
long elapsedTime = System.currentTimeMillis() - startTime;
if (elapsedTime > paymentDelayLimit) {
log.warn("⚠️ 支付操作延迟超过预算！耗时：{}ms", elapsedTime);
}
}
// 检查库存
startTime = System.currentTimeMillis();
if (checkStockAvailability(order)) {
long elapsedTime = System.currentTimeMillis() - startTime;
if (elapsedTime > stockCheckDelayLimit) {
log.warn("⚠️ 库存检查延迟超过预算！耗时：{}ms", elapsedTime);
}
}
}
private boolean processPayment(Order order) {
// 模拟支付处理逻辑
return true;
}
private boolean checkStockAvailability(Order order) {
// 模拟库存检查逻辑
return true;
}
}
接着，我给大家绘张延迟预算控制流程图---订单流程中的延迟预算分配，大家就明白了。
🎯 四、制定一致性等级的选型策略：如何在不同场景下选择合适的一致性等级？
🚦 策略 1：金融、电商等高一致性场景
- 一致性等级：强一致性（使用分布式事务）
- 延迟预算 ：严格控制延迟，确保操作在200ms以内。
- 技术选型 ：
- 分布式事务 （如 Saga 或 TCC 模式）
- 消息队列 ：确保最终一致性，使用可靠的消息队列（如 Kafka 或 RabbitMQ）
🚦 策略 2：社交平台、内容发布等高可用性场景
- 一致性等级：最终一致性（牺牲短期一致性，采用补偿机制）
- 延迟预算：延迟预算可以适当放宽，容忍数秒的延迟。
- 技术选型 ：
- CQRS（命令查询职责分离）
- Event Sourcing（事件源架构）
- 异步数据同步、事件驱动架构
🧠 结语：架构师的一点体会------延迟预算和一致性并不是敌人
通过这篇文章，我们深入分析了强一致性与高可用性之间的差异，探讨了如何根据不同场景分配延迟预算，并提出了合理的延迟预算分配模型。通过合理的架构设计和策略选择，我们完全可以在高可用和强一致之间找到平衡，确保系统既能高效响应用户需求，又能保证数据的一致性。
🔑关键是：延迟预算并不是一个固定的"规则"，而是一个根据不同需求进行调整和优化的过程。架构设计的灵活性和可调节性，才是支撑高可用与强一致的关键！
👇那么，亲爱的架构师朋友们，平时你们在设计系统时，有遇到过类似的困扰吗？你们又是如何做出延迟预算选择的？
欢迎评论区留言讨论，一起分享架构设计的心得！
📣 关于我
我是bug菌，CSDN | 掘金 | InfoQ | 51CTO | 华为云 | 阿里云 | 腾讯云 等社区博客专家，C站博客之星Top30，华为云多年度十佳博主&最具价值贡献奖，掘金多年度人气作者Top40，掘金等各大社区平台签约作者，51CTO年度博主Top12，掘金/InfoQ/51CTO等社区优质创作者；全网粉丝合计 30w+ ；硬核微信公众号「猿圈奇妙屋」，欢迎你的加入！免费白嫖最新BAT互联网公司面试真题、4000G PDF电子书籍、简历模板等海量资料，你想要的我都有，关键是你不来拿。
-End-