引言😵
由于CAP理论的严格性，我们急需一种构建高可用，可扩展的分布式互联网应用的指导原则，于是出现了BASE理论。BASE理论强调系统的可用性和最终一致性，而不是强一致性。下面让我们一起了解一下。
Basically Available（基本可用）😯
定义：在分布式系统中，即使发生不可预知的故障，系统也要保证核心功能仍然可用，即使不是全部功能都能正常运行，提升系统的容错能力和可用性。
实现方式
- 负载均衡：通过将请求分发到多个服务器，避免单点故障，确保部分服务器可用时，系统仍能响应请求。
- 服务降级：当系统资源紧张或出现故障时，关闭部分非核心功能，保证核心功能的可用性。
- 数据备份：通过数据冗余备份，当主节点故障时，可以快速切换到备用节点，保证数据的可用性。
- 削峰减流：使用消息队列集群来抵挡突发的流量冲击，按照一定速率给数据库消费。
使用场景
- 电商网站：在促销活动期间，即使部分服务器压力过大，仍然保证用户可以浏览商品和下单。
- 社交网络：即使部分服务器出现故障，仍然保证用户可以查看和发布动态。
- 在线游戏：即使部分服务器不稳定，仍然保证用户可以进行游戏。
Soft State（软状态）😪
定义：系统中的数据可以存在中间状态，不要求所有数据时刻保持一致性。
简单来说，就是数据可能暂时不一致，状态可能会随着时间变化而自动更新，且不要求系统立即同步所有节点的数据。这里就代表了牺牲强一致性。
实现方式：
- 异步复制：主节点将数据变更异步复制到备用节点，允许数据在一段时间内存在不一致。
- 最终一致性协议：使用如Paxos、Raft等一致性协议，保证数据在经过一段时间的同步后，最终达到一致的状态。
使用场景：
- 电商网站：用户下单后，订单状态的更新可能存在延迟，但最终会更新为已支付或已发货状态。
- 社交网络：用户发布动态后，动态的显示可能存在延迟，但最终会显示在所有用户的timeline中。
- 在线游戏：玩家的等级和装备信息可能存在延迟，但最终会同步到所有客户端。
Eventually Consistent（最终一致）😗
定义： 所有对系统的更新操作，在经过一段时间后，最终会使得所有副本达到一致状态。
实现方式：
- 读时修复：在读取数据时，检测数据是否一致，如果不一致则进行修复。
- 写时修复：在写入数据时，同时更新所有副本，保证数据的一致性。
- 异步修复：定期检测数据是否一致，如果不一致则进行修复。
使用场景：
- DNS：域名解析记录在全球各地的DNS服务器上同步，最终达到一致。
- CDN：内容分发网络将内容缓存到全球各地的节点上，最终达到一致。
- 分布式缓存：缓存数据在多个节点上同步，最终达到一致
总结❤️
如果你看了这篇文章有收获可以点赞+关注+收藏🤩，这是对笔者更新的最大鼓励！如果你有更多方案或者文章中有错漏之处，请在评论区提出帮助笔者勘误，祝你拿到更好的offer！