Grokking-System-Design
  • 译者
  • 0. 系统设计面试指南
  • 1. 设计类似TinyURL的短链服务
  • 2. 设计 Pastebin
  • 3. 设计Instagram
  • 4. 设计Dropbox
  • 5. 设计Facebook Messager
  • 6. 设计 Twitter
  • 7. 设计YouTube或Netflix
  • 8. 设计输入提示建议
  • 9. 设计API限流器
  • 10. 设计 Twitter 搜索
  • 11. 设计网络爬虫
  • 12. 设计 Facebook 的新闻信息流
  • 13. 设计 Yelp 或附近的朋友
  • 14. 设计 Uber 后端
  • 15. 设计票务大师
  • 16. 附加资源
  • 17. 分布式系统的核心特征
  • 18. 负载均衡
  • 19. 缓存
  • 20. 分片或数据分块
  • 21. 索引
  • 22. 代理
  • 23. 冗余和复制
  • 24. SQL 与 NoSQL
  • 25. CAP 理论
  • 26. 一致性哈希
  • 27. 长轮询 / WebSockets / 服务器发送事件
Powered by GitBook
On this page

25. CAP 理论

Previous24. SQL 与 NoSQLNext26. 一致性哈希

Last updated 2 years ago

CAP 定理指出,分布式软件系统不可能同时提供以下三项中的两项以上 (CAP):一致性、可用性和分区容错性。设计一个分布式系统时,CAP 之间的权衡几乎是首要考虑的事情。 CAP 理论在设计分布式系统时指导我们,以下三个中只能选满足两个:

一致性:

所有节点同时看到相同的数据。一致性是通过在允许进一步读取之前更新几个节点来实现的。

可用性:

每个请求都会获得成功/失败的响应。可用性是通过在不同服务器之间数据副本来实现。

分区容错性:

系统在消息丢失或部分失败时可以继续服务。具有分区容错性的系统可以承受任意数量的不会导致整个网络瘫痪的网络故障。数据是在节点和网络中做好副本,以保持系统通过间歇性中断启动。

我们无法建立一个持续可用的具有顺序一致,并且可以容忍任何分区故障特点的通用数据存储。 只能构建具有这三个属性中的任意两个的系统。 因为,为了达到一致性,所有节点都应该以相同的顺序看到相同的更新。但是如果网络出现分区,在客户端从过期分区中读取数据之前,一个分区中的更新可能不会,将其发送到其他分区。 唯一能做的就是应对这种可能性的方法是停止为过期的请求提供服务分区,但随后服务不再是100% 可用。