介绍在理论计算机科学中，CAP定理，又称布鲁尔定理，指出对于一个分布式计算系统，不可能同时满足以下三点：Consistent一致性（相当于所有节点访问相同的最新数据副本）可用性（每次请求都能得到无错误的响应——但不保证得到的数据是最新的数据）分区容错性（Partitiontolerance）（就实际效果而言，分区相当于通信的时限要求，如果系统不能在时限内实现数据一致性，则说明发生了分区，当前操作必须在C和A之间进行选择）根据定理，分布式系统只能满足三项中的两项，但不能同时满足三项。理解CAP理论的最简单方法是想象分区两侧各有两个节点。允许至少一个节点更新状态会导致数据不一致，即丢失C属性。如果为了保证数据的一致性，将分区一侧的节点设置为不可用，那么A属性就丢失了。除非两个节点可以相互通信，否则C和A都可以得到保证，进而导致P属性的丢失。这个定义是不是让人看了一头雾水，多看几遍会不会感觉清楚一点？CAP理论听起来很抽象。本文试图通过生活中的例子，用通俗易懂的语言来解释CAP理论的含义。CAP的故事很有趣。请点击链接https://zhuanlan.zhihu.com/p/265670196查看或点击阅读原文阅读。相信看完这个小故事，重新理解前面的定义可能会更好。Cap的权衡通过CAP理论，我们无法同时满足一致性、可用性和分区容错性这三个特性，那么我们如何进行权衡呢？在分布式系统中基本不可能选择CA而放弃P。.因为分区在分布式环境中是不可避免的，如果我们要放弃P，就意味着我们要放弃分布式系统，所以CAP理论就不用讨论了。如果我们选择CP而放弃A，分布式系统就无法实现可用性，经常宕机或者停止提供服务，那么用户体验很差，就像之前的“微盟数据库删除事件”一样，只有数据全部找回后才会继续对外提供服务，这期间有多长停机时间，以及给企业造成了多少损失。我们常见的CP分布式系统有分布式数据库（redis）、Zookeeper等，它们优先保证数据的强一致性而放弃了系统的可用性。放弃AP，放弃C，要保证高可用，允许分区，就需要放弃一致性。一旦出现网络问题，节点之间可能会失去联系。为了保证高可用，需要在用户访问时立即返回，这样每个节点只能用本地数据提供服务，会导致全局数据不一致。现在大部分场景应该以牺牲一致性（维护最终一致性）为代价来选择可用性，就像我们春节抢红包的时候，不会马上告诉你抢了多少钱，只是提醒你抢了多久等到以后再拿。去检查。而我们春节抢票的时候，明明看到这条高铁还是有盖章的，但是当你填写验证码和乘客信息，实际提交订单的时候，它会告诉你没有门票。返回列表页查看车次时，也继续显示有车票。虽然使用体验有点不友好，但也可以接受。综上所述，CAP没有更好的选择。只能根据自己的业务场景来选择，选择适合自己的。基础理论BASE：全称：BasicallyAvailable（基本可用）、Softstate（软状态）和Eventuallyconsistent（最终一致性）三个词组，由ebay的架构师提出。Base理论是CAP中一致性和可用性之间权衡的结果。它来源于大规模互联网分布式实践的总结，并基于CAP定理逐渐演化而来。它的核心思想是：即使不可能实现强一致性（Strongconsistency），每个应用程序也可以根据自己的业务特点采用合适的方法使系统达到最终一致性（Eventualconsistency）。基本可用（BasicallyAvailable）什么是基本可用？牺牲性能（服务响应时间）和体验（部分功能体验）来保证基本的可用性。牺牲性能：比如我们查询商品，正常的响应时间是1s左右返回结果，但是如果基本可用，返回结果是10s。牺牲体验：比如双十一期间，淘宝只会保证核心功能可用（下单、支付等），其他非核心功能（退货、换地址等）都会降级。关于降级的细节，可以看之前的文章《高并发系统三大利器之降级》SoftState（软状态）允许一个不影响整体可用性的中间状态，即允许系统在多个不同节点的数据副本中存在数据延迟。EventualConsistency（最终一致性）说的是softstate，然后就不能一直是softstate，要有个时间限制。截止日期后，应保证所有副本保持数据一致性。以达到数据的最终一致性。这个时间限制取决于网络延迟、系统负载、数据复制方案设计等因素。系统可以保证在没有其他新的更新操作的情况下，数据最终会达到一个一致的状态，因此所有客户端访问系统的数据最终都能够获得最新的值。最后，由于自己的无知和知识的匮乏，难免有错误。如果您发现错误，请留言指出给我，我会改正。本文转载自微信公众号「java财经」，可通过以下二维码关注。转载本文请联系爪哇财经公众号。
