案例背景CAP理论是分布式系统中的核心基础理论。虽然面试官不会在面试中直接问你CAP理论的原理，但是面试中遇到的分布式系统设计问题，都绕不开你对CAP的理解和思考。而且，在面试中，面试官对面试不同职位的应聘者的要求也会不同，你回答的深度也会不同。所以在本讲中，我将从初中级研发工程师和高级研发工程师两个不同的角度来分析一下面试思路。案例分析相信大家只要学过分布式技术的相关知识，就基本知道CAP理论指的是什么：C（Consistency）是数据一致性，A（Availability）是服务可用性，P（Partitiontolerance）是分区容忍度。C、A、P只能同时满足两个目标，由于在分布式系统中必须保留P，所以需要在C和A之间进行权衡。如果要保证服务的可用性，就选择AP模式，如果要保证一致性，就选择CP模式。如果很多考生发现面试题（比如“为了数据容灾，我们会做数据的主从备份，主从节点的数据一致性对调用方有什么影响？”）涉及对“的理解”CAPandThinking”，会下意识地做出类似的回答：“CAP理论描述的是在网络分区的情况下，需要在C和A之间做一个权衡，所以从调用者的角度来看会影响到系统不可用。”.如果是我，我大概会给及格分，认为这样的回答只能证明你有准备，不能证明你有能力。因为在面试中遇到理论问题时，仅仅通过表面上的概念性解释，是很难向面试官证明自己的技术能力的。面试官会认为你是分布式系统的新手，或者对分布式系统没有深入的了解。如果这恰好是你的第一道面试题，会直接影响面试官对你的第一印象，甚至会影响到你。评分。以我的经验来看，要想回答得更好，需要先掌握CAP的原理、实战经验、技术认知，再结合具体的面试题进行分析。问答理解原理现在有一个分布式系统A，它有一个副本A1。正常情况下，客户端Client向系统A写入数据，然后数据从节点A同步到节点A1，然后以成功状态返回给客户端。此时客户端Client从任意一个节点A或者A1读取数据，可以读取到最新写入的数据，说明A和A1的数据是一致的，A和A1也是可用的。但由于网络不可靠，节点A和A1的网络随时可能因中断而分区。所谓网络分区是指节点A和A1由于网络故障而被隔离在不同的网络子集中。此时节点A的数据无法及时同步到节点A1。在分布式系统中，由于网络问题造成的网络分区是常态。也就是说，当发生网络分区时，根据CAP理论，需要在A和C之间做一个trade-off，即保证系统的可用性还是保证数据的一致性。你应该注意这里。上面的例子有个大前提是系统有网络分区，但实际情况是大部分时间没有网络分区（网络不会经常出问题）。那么你是否仍然必须三选二（CP或AP）？事实上，不同的分布式系统需要根据业务场景和业务需求在三种CAP之间进行取舍。CAP理论用于指导系统设计时需要衡量的因素，而不是做出绝对的选择。当网络没有分区时，CAP理论并没有给出衡量A和C的因素，但是如果你做过实际的分布式系统设计，你一定会发现系统数据同步的延迟（Latency），即,例子中节点A向节点A1同步数据的时间是衡量A和C最重要的因素，此时不会有绝对的AP模型或CP模型，而是要综合考虑实际业务场景。因此，将会有PACELC“Reference1”等新模型对原有的CAP理论进行优化，理论指导实践，实践优化理论。根据PACELC模型的定义，如果存在网络分区，系统必须在A和C之间取得平衡，否则（Else，即PACELC中的E）当系统在没有网络分区的情况下运行时，系统需要要在L（延迟）和C中取得平衡。但是仅仅了解这一层还不够，还需要用落地的经验来证明。实践经验你需要认识到互联网的分布式设计是数据一致性和系统可用性之间的权衡，而不是两者兼而有之，这一点尤为重要。因此，即使无法实现强一致性（简单来说，强一致性就是任何时候所有用户查询到的数据都是最新的），也可以根据自己的业务特点采用合适的方法使系统最终具有一致性.这时候就要引入BASE理论，它是CAP理论的延伸。BASE是BasiclyAvailable（基本可用）、SoftState（软状态）和EventuallyConsistent（最终一致性）这三个词的缩写。它的作用是保证系统的可用性，然后用最终一致性代替强一致性。分布式系统设计中最具指导意义的经验总结。那么在实际项目中，如何运用BASE理论来指导设计实践呢？BASE中的基本可用性是指保证核心功能的基本可用性。其实是在“易用性”上的一种妥协。次要功能的展示，保证产品交易主流程的可用性，也就是我们常说的服务降级；为了错开双十一的高峰期，电商网站会将预售商品的支付时间延迟十到二十分钟，这就是流量调峰；当你抢购商品时，往往会在队列中等待处理，这也是一种常用的延迟队列。软态和最终一致性是指让系统中的数据以一种中间状态存在，这也是一种为了系统可用性而牺牲一段时间内数据一致性，从而保证最终数据一致性的做法。目前，这种处理数据的方式几乎已经成为互联网的标准设计模式。最经典的例子就是，用户下单的时候，不需要实际去扣库存，只是在前台统计数量，然后用异步任务去后台批处理。如果你想应聘初级或中级研发工程师，那么结合以上思路，从理论理解到实际操作，你已经可以比较清楚地回答CAP理论了。答题逻辑可以参考我给的建议：首先充分理解理论原理，不要只浮在概念上；其次，要有自己的思维，体现思维能力的差异；然后理论联系实际，讨论处理问题时的实际思维逻辑。技术认知如果你应聘的是高级研发工程师或者架构师，在回答的时候要尽可能的展示你的知识体系和技术判断。这是这两个职位的基本素质。由于分布式技术错综复杂，各种技术相互耦合，在面试中，如果能通过CAP理论的一个知识点，拓展出一个脉络清晰的分布式核心技术的知识体系，就能拉开与自己的差距。其他的。分布式系统看起来像一台计算机。计算机包括五大体系结构（即冯·诺依曼结构），它有五个主要部件：控制器、运算器、存储器、输入和输出。你可以这样理解：一个分布式系统也包括这五个组成部分，其中最重要的是计算和存储。计算和存储由一系列网络节点组成。每个节点之间的通信是输入输出，每个节点之间的调度管理是控制器。分布式架构技术的构成从这个角度来看，分布式系统就像一台网络计算机，其知识体系包括四个方面：内存，即分布式存储系统，如NoSQL数据库存储；计算器，即分布式计算，如分布式并行计算；输入输出，即分布式系统通信，如同步RPC调用、异步消息队列；controller，即调度管理，如流量调度、任务调度、资源调度等。大家可以从这四个角度来总结分布式系统的知识体系。那么具体解决问题的方法是什么？以“Redis是否可以作为分布式锁”为例，作为一名资深研发工程师，来分析一下隐藏在问题背后的分布式理论知识和解题思路。解决问题的思路表明，现实中存在的问题一般都是通过Redis实现锁和超时时间，使用setnx方法来控制锁的过期时间。但是在极端情况下，当Reids主节点挂了，但是锁还没有同步到从节点上，根据哨兵机制，从节点变成了主节点，继续提供服务。这时候另一个线程可以再次请求锁，这时候就会有两个线程拿到锁。回归理论的指导按照CAP理论的理解，Redis的设计模型是AP模型，而分布式锁是CP场景，所以将Redis的AP模型的架构应用到CP场景是显而易见的，底层技术选择错误。扩展到知识体系Redis属于分布式存储系统，想必大家心中都有分布式存储系统领域的知识体系。想一想它的数据存储、数据分布、数据复制、数据一致性是怎么做的，用什么技术来实现，为什么要选择这样的技术或算法。你要学会从多个维度、多角度对同一个分布式问题的不同方法进行比较分析，然后综合权衡各种方法的优缺点，最终形成自己的技术认知和技术判断。有技术判断，比如通过Redis，可以想到分布式缓存系统目前的发展现状和技术实现。如果让你做一个“Redis”，你会考虑什么问题等。虽然不建议在实际工作中重复“造轮子”，但一定要在面试中表现出自己有“造轮子”的能力.总结CAP理论看似简单，但在面试中，对它的理解深度可以从侧面反映出你对分布式系统的整体理解和控制能力。因此，面试时不仅要掌握如何回答案例中关于CAP原理的问题，还要掌握回答问题的思路。以后遇到类似的理论知识考察，可以从三个层面来回答。展示理论深度。可以从一个众所周知的知识点出发，通俗易懂地回答，比如它的工作原理、优缺点、适用场景等。结合落地经验。不能仅仅停留在理论理解上，还要结合落地方案的技术实现，这样才能体现出你的技术闭环思维。展示知识体系。这是任何程序员向上发展的基本能力。理论深度和落地经验体现了程序员的基本素质，而知识体系和技术判断则体现了你是否达到了架构师能力的极限。文末送大家一句话：“技术人，既要有落地能力，又要有飘上天的能力”。文章来源：JAVA日知录
