主要观点总结
文章主要讨论了架构设计中关于CAP的理论及其在工程实践中的启示。作者指出在异步网络环境下，不能保证每个请求都返回最新的数据，并给出了相关的设计建议。
关键观点总结
关键观点1: CAP理论概述
文章简要介绍了CAP理论，强调了其在工程架构设计中的重要性。
关键观点2: 异步网络环境下的设计启示
作者指出在异步网络环境下，不要期望每个请求都返回最新的数据，并给出了关于性能与扩展性的设计建议。
关键观点3: 工程实践中的启示
文章讨论了如何在工程实践中应用CAP理论的启示，包括设置超时、实现冗余与故障自动转移、以及关于一致性的最佳实践。
关键观点4: CAP与业务连续性
作者强调了为了保证业务连续性，需要关注节点、机架、机房的冗余和容错，以及如何在不同的分布式系统中应用这些实践。
关键观点5: 推荐阅读材料
文章推荐了《关于CAP的18个问题》作为补充阅读材料，以便更深入地了解CAP理论。
正文
一句大白话总结：异步网络环境下，不要痴心妄想去设计一个系统，每个请求都返回最新的数据。这里所指的，异步网络（asynchronous network），是什么意思？意思就是：没法保证，在明确的，有限的时间内，完成消息投递。这里有一个重要的推论：发出一个消息很久没有收到回复，我们无法判断，是节点故障，还是消息要投递or处理很久。这里面的工程启示是：要对消息投递设置超时，以确保我们能在有限的时间内，得到一个响应，以便业务流程继续推进下去。画外音：超时发生时，我们仍然不知道是节点故障，还是消息要投递or处理很久。实现冗余的前提下，要么客户端重试，要么服务端故障自动转移。为了让调用方无感，有更好的体验，高可用的最佳实践是冗余+故障自动转移。画外音：同一个集群内的多个节点，应该部署在不同的机架上，以防止机架掉电。15年前，我们在百度部署服务的时候，要考虑哪些节点部署在土城机房，哪些节点部署在酒仙机房，万一机房挂了怎么办。现在的工程师估计不考虑这些问题了。CAP的证明抽象了这样一个系统，有一个值X，有两个操作：所谓的强一致性是指，某个set(X)成功后，后续所有get()都将在有限的时间内返回最新的值。对应的弱一致性，不是所有get()都能在有限的时间内返回最新的值。这里面的工程架构最佳设计实践是：大部分业务系统，在认可网络故障P的前提下，优先保证A而牺牲C，将C退化为“最终一致性”。这个工程实践，在许多分布式系统中都得到了广泛的应用。最后，简单做一个总结，CAP对工程架构设计的启示是什么？一句话：异步网络环境下，不存在一个系统，每个请求都返回最新的数据。C，大部分情况下，可以优先AP，并将强一致性退化为最终一致性，允许读旧数据；https://github.com/henryr/cap-faqhttps://www.the-paper-trail.org/page/cap-faq/非常通俗，全面的介绍了大部分对CAP的疑问，文章不长，10分钟搞定。我将以短视频+图文+直播+星球社群的形式，系统性的分享架构设计中的100个相关知识点，欢迎感兴趣的童鞋关注。
本篇的前序短视频在这：
平台对专业内容不推流，大家多帮忙标星，以及点赞，转发，在看三连。感谢！
下一期，和大家聊聊一致性模型与工程实践。
