架构面试场景题（二）

什么是CAP

CAP定理，也被称为Brewer定理，是分布式计算中的一个重要概念。它由计算机科学家Eric Brewer于2000年提出，并由Seth Gilbert和Nancy Lynch于2002年正式证明。CAP定理强调了分布式系统中三个关键属性之间的固有权衡，这三个属性分别是一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。

以下是CAP定理的详细解释：

一致性（Consistency） ：
- 在分布式系统中，一致性意味着系统中的所有节点在同一时间看到相同的数据。
- 换句话说，当发生写操作时，所有后续的读操作都应反映该写操作。
- 一致性保证了数据的同步性。
可用性（Availability） ：
- 可用性指的是系统中每个节点对读和写请求的响应能力，即使一些节点经历故障或延迟。
- 可用性系统确保请求得到响应，但不保证它包含最新的写入。
- 在一个高可用的系统中，即使某些节点出现故障，用户仍然能够提交请求并获得响应。
分区容忍性（Partition Tolerance） ：
- 分区容忍性涉及系统在发生网络分区（通信失败）时继续运行和提供服务的能力。
- 它意味着系统可以容忍消息的丢失或节点间通信的延迟。
- 在分布式系统中，节点之间的网络通信可能会发生故障，导致节点之间无法直接通信，形成网络分区。

CAP定理的核心思想是，一个分布式系统最多只能同时实现这三个属性中的两个。具体来说，系统设计者必须在以下三者之间做出权衡：

一致性与可用性 ：如果系统选择一致性和可用性，那么它会牺牲分区容忍性。在这种情况下，系统在发生网络分区时可能会停止服务，直到网络恢复，以确保数据的一致性和系统的可用性。传统的关系型数据库（如MySQL、PostgreSQL）通常属于这一类别。
一致性与分区容忍性 ：如果系统选择一致性和分区容忍性，那么它会牺牲可用性。在网络分区发生时，系统会优先保证数据的一致性，即使这意味着在分区期间无法提供服务。HBase和Zookeeper等系统在某些配置下可以保证一致性和分区容忍性。
可用性与分区容忍性 ：如果系统选择可用性和分区容忍性，那么它会牺牲一致性。在网络分区发生时，系统会继续处理请求，即使这可能导致数据的不一致。这种系统通常依赖于"最终一致性"模型，即数据在一定时间内会达到一致性状态。DynamoDB、Cassandra等NoSQL数据库系统在设计时会优先保证可用性和分区容忍性。

为什么必须要保证分区容错性（Base理论）

BASE理论由eBay的架构师提出，是对CAP理论的一种延伸和补充。CAP理论指出，一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）这三个属性。而BASE理论则提供了一种新的视角，即在无法做到强一致性的情况下，每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

BASE理论包含三个核心要素：

基本可用（Basically Available） ：
- 系统保证在出现故障或部分失效的情况下仍然可以保证基本的可用性。这意味着虽然系统可能无法保证100%的可用性，但是它仍然会尽力保证在任何时候都能够提供基本的服务。
- 基本可用通常允许系统在出现故障时部分功能暂时失效，但其他功能仍然可以正常工作。
软状态（Soft State） ：
- 系统中的数据状态可以在一段时间内是不一致的，即系统中的数据副本可能存在短暂的冲突或不同步。这种状态是暂时的，系统会通过后续的处理来逐渐将数据状态调整为一致。
- 软状态允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性。
最终一致性（Eventually Consistent） ：
- 系统的数据最终会达到一致的状态，但在某个时间点上可能存在不一致的情况。分布式系统中的不同节点可能具有不同的数据副本，而这些副本之间的同步需要一定的时间。
- 最终一致性要求系统在一定时间范围内能够达到数据的一致性，允许在同步过程中存在短暂的不一致状态。

二、BASE理论的应用场景

BASE理论适用于大型高可用、可扩展的分布式系统。与传统ACID（原子性、一致性、隔离性、持久性）特性相反，BASE理论通过牺牲强一致性来获得可用性，并允许数据在短时间内的不一致，但最终达到一致状态。

在实际应用中，BASE理论常用于以下场景：

电子商务网站 ：
- 在高峰期，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面，但其他功能（如浏览商品）仍然可以正常使用。
- 允许异步的数据复制方式，将数据副本在后台进行异步同步，从而提高系统的响应性能和可用性。
社交媒体平台 ：
- 用户需要实时地与其他用户进行互动，并获取最新的信息更新。
- 可以采用缓存技术和分布式数据存储，以加速数据访问和查询。
- 在一致性方面，可以采用最终一致性的策略，即用户可以看到稍有延迟的最新数据。
金融交易系统 ：
- 数据的一致性和可靠性至关重要。
- 但在某些情况下，为了提高性能和可用性，可能会采用最终一致性的策略，并通过其他手段（如分布式事务）来确保关键数据的一致性。

三、BASE理论与CAP理论的关系

BASE理论是对CAP理论的一种延伸和补充。CAP理论强调了分布式系统中三个关键属性之间的固有权衡，而BASE理论则提供了一种新的视角和解决方案。具体来说：

CAP理论指出，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个属性。
BASE理论则强调，在无法做到强一致性的情况下，可以通过牺牲部分一致性来获得更高的可用性和灵活性。
BASE理论中的基本可用、软状态和最终一致性三个要素，正是对CAP理论中一致性、可用性和分区容忍性权衡的结果。

四、BASE理论的优缺点

优点：

提高了系统的可用性和灵活性 ：通过牺牲部分一致性，BASE理论允许系统在出现故障或部分失效的情况下仍然能够提供服务。
支持大规模分布式系统 ：BASE理论适用于大型高可用、可扩展的分布式系统，能够满足高并发和大规模数据处理的需求。

缺点：

数据一致性难以保证 ：由于允许数据在短时间内的不一致，BASE理论可能导致数据冲突和不一致的问题。
系统复杂度增加 ：为了实现最终一致性，系统需要采用复杂的同步机制和算法，增加了系统的复杂度和维护成本。

综上所述，BASE理论是分布式系统设计中的一种重要理论，它强调在一致性、可用性和分区容忍性之间做出权衡。通过牺牲部分一致性，BASE理论提高了系统的可用性和灵活性，并支持大规模分布式系统。然而，它也存在数据一致性难以保证和系统复杂度增加等缺点。因此，在设计和实现分布式系统时，需要充分考虑BASE理论的应用场景和优缺点，并根据具体需求进行权衡和选择。

什么是微服务的五大核心组件，三大配件，一般都会用到哪些组件

五大核心组件服务治理

注册中心 Eureka AP 高可用 Nacos Consul ZK CP 服务治理的八大功能

配置中心 apollo Nacos disconf config 配置是如何推送到服务端的是不是实时生效的权限

网关过滤器链 zuul gataway

声明式远程调用 Fegin OpenFegin

负载均衡 Ribbon loadbanlance

三大配件

链路追踪用户 20W --- 首页 15W------商品详情页 25W---------购物车 20W ----订单 2W----库存 5W --- 支付 1W 1W的并发

zipkin skywalking Cat pingpoint

日志监控告警 Elk Prometheus + Grafana

断路器双11 618 电商主动的降低并发关键的节点限流的操作 100 100订单

Sentinel Hystrixs 20台服务器

在微服务架构下，如何判定性能的标准：

在微服务架构下，判别接口性能的标准一般可以从以下几个方面进行评估：

请求响应时间：这是最基本的性能评估指标之一。请求响应时间指的是从客户端发出请求到服务器处理完请求并返回响应所需要的时间。一般来说，请求响应时间越短，说明服务性能越好。互联网项目一般要求1S以内，交互频繁的项目 300ms
吞吐量：吞吐量指的是在一定时间内可以处理的请求数量百分比值。一般来说，吞吐量越高，说明服务性能越好。 JVM的吞吐量 96%以上业务处理时间/（业务处理时间+垃圾收集时间） 99/100=99%
并发能力：并发能力指的是服务器同时处理多个请求的能力。一般来说，服务器的并发能力越强，说明服务性能越好。不好定标准不同的服务，不同的接口，并发能力不一样用户频繁访问，有访问压力的接口，一条链路上的最低点单纯的CRUD不会成为性能瓶颈
容错能力：容错能力指的是在出现异常情况时，服务器的自我保护和恢复能力。一般来说，容错能力越强，说明服务性能越好。失败重试 5S 3次特殊的全局异常捕获读取数据库海量数据
稳定性：稳定性指的是服务在长时间运行过程中，是否出现过崩溃、死锁等问题。一般来说，稳定性越高，说明服务性能越好。全局可用性 99.9% 可靠性99%

在实际的性能测试中，除了以上几个方面，还可以根据具体业务需求进行评估。同时，在进行性能测试时，需要考虑到并发场景、请求量、负载均衡、缓存等因素对服务性能的影响，综合评估服务的性能表现。

Nacos脑裂可能出现的几种情况：

Nacos 作为分布式系统中的注册中心和配置中心，其脑裂（Split-Brain）问题通常与集群模式下的数据一致性和选举机制相关。以下是 Nacos 脑裂可能出现的情况

脑裂指在分布式集群中，由于网络分区（如节点间通信中断），导致集群分裂为多个独立子集群，每个子集群误认为自己是唯一存活的集群，并独立处理请求，最终引发数据不一致或服务冲突

原因：

网络分区 ：节点间通信中断，形成多个独立子集群。
选举机制缺陷 ：若多个子集群同时选举出 Leader，可能导致数据写入冲突。
心跳机制失效 ：节点无法感知其他节点的存活状态，误判 Leader 失效。

Nacos 脑裂的可能场景与案例

1. CP 模式下的 Raft 集群

场景：Nacos 在 CP 模式下使用 Raft 算法保障强一致性。若集群节点数为偶数（如 4 节点），当网络分区导致集群分裂为两个 2 节点的子集群时，两个子集群均无法满足"过半投票"（需至少 3 票），从而无法选举新 Leader。此时整个集群不可用，但不会出现脑裂。
案例：某集群部署了 4 个节点，网络故障导致分裂为两个子集群（各 2 节点）。由于 Raft 要求过半投票，两个子集群均无法选举 Leader，最终服务不可用，但无数据冲突。

规避手段：

Raft 要求 Leader 必须获得超过半数的节点投票，确保同一任期内仅有一个 Leader。若网络分区导致子集群节点数不足半数，则无法选举新 Leader，避免脑裂。
示例：5 节点集群分裂为 3 节点和 2 节点子集群，仅 3 节点子集群可选举 Leader，2 节点子集群无法写入，避免数据冲突

2. AP 模式下的 Distro 协议

场景：Nacos 默认 AP 模式下使用 Distro 协议（最终一致性）。网络分区时，各子集群独立处理请求，可能导致临时数据不一致。但 Distro 协议通过异步同步修复数据，最终达到一致，严格来说不产生传统意义的脑裂。
案例：两个机房部署 Nacos 集群，网络中断后，两个机房各自处理服务注册请求。恢复通信后，通过 Distro 的数据同步机制合并冲突数据，最终保持一致。

规避手段：起监听，确定各个节点的数据一致不一致的情况记录下来最后再去解决

3. 混合部署与配置错误

场景：集群节点配置不一致（如部分节点启用 CP 模式，部分启用 AP 模式），可能导致协议冲突，引发数据不一致。
案例：某运维误将部分节点配置为 CP 模式，其余保持 AP 模式。网络分区时，CP 子集群尝试强一致性同步，而 AP 子集群继续响应请求，导致服务状态混乱

规避方式：统一集群模式（全切为 CP 或 AP），并重启节点

服务划分原则

在微服务架构中，服务划分可以基于多种因素，例如业务功能、数据域、可扩展性、可维护性等。以下是一些常用的划分方法：

基于业务功能：将服务划分为不同的业务功能单元，例如订单服务、支付服务、用户服务等。耦合度会非常高，这种方式开发会比较便捷适用于比较小的项目 L1：订单生成，临时单的生成L3：查看所有的订单，根据条件筛选查看订单
基于数据域：将服务按照数据领域进行划分，例如客户服务（用户中心）、订单服务（订单中心）、库存服务（WMS数据中心）等。大型项目做的事情
基于可扩展性：将服务划分为可以水平扩展的单元，例如将前端服务划分为多个负载均衡的实例，每个实例都可以处理一部分流量。线性扩容集群
基于可维护性：将服务划分为易于维护和更新的单元，例如将核心服务与辅助服务分离，将通用功能提取为独立的服务。基于领域的方式 DDD的方式

在面试时，应该清楚地解释您所选择的划分方法，并说明其优缺点以及在什么情况下该方法适用。此外，您应该能够描述如何将这些服务组合成一个完整的应用程序，并讨论在不同服务之间通信的方式。最后，您可能需要讨论一些与微服务相关的挑战，例如服务发现、服务治理、数据一致性等，并说明您如何解决这些挑战

配置中心几种配置推送方式以及nacos的推送方式

1、动态监听

Push表示服务端主动将数据变更信息推送给客户端

复制代码

推送的模式服务器必须保持客户端的长连接，这样服务端会耗费大量的内存，并且还要检测链接的有效性。需要一些心跳机制来维护

Pull表示客户端主动去服务端拉取数据

复制代码

这样客户端缺少了时效性，客户端不可能实时的从服务端拉取的，他要有时间间隔的。这个时间间隔不好控制，时间长了就实时性不高，时间短了，如果配置没有变化时候他会有需要无效的拉取。

2、动态刷新流程图（长轮询机制）

客户端会轮询向服务端发出一个长连接请求，这个长连接最多30s就会超时，服务端收到客户端的请求会先判断当前是否有配置更新，有则立即返回如果没有服务端会将这个请求拿住"hold"29.5s加入队列，最后0.5s再检测配置文件无论有没有更新都进行正常返回，但等待的29.5s期间有配置更新可以提前结束并返回。

Nacos服务端采用长轮询机制相比传统的短轮询或简单的长连接具有多个显著的好处。以下是对这些好处的详细归纳：

1. 降低推送延迟

减少延迟时间：在短轮询中，客户端需要定期（如每5秒）向服务端发送请求以检查配置是否更新，这可能导致较大的延迟。如果配置变更发生在两次轮询之间，客户端需要等待直到下一次轮询才能获取到更新。而长轮询机制下，客户端发起请求后，服务端会hold住该请求，直到配置发生变化或达到超时时间才返回结果，从而显著降低了推送延迟。

2. 减轻服务端压力

减少无效请求：在传统的轮询机制中，无论配置是否发生变化，客户端都会定期发送请求，这会对服务端造成不必要的压力。而在长轮询中，当配置未发生变化时，服务端会挂起客户端的请求，不会立即返回响应，从而减少了无效请求的数量，减轻了服务端的压力。
资源利用更高效：由于长轮询减少了无效请求，服务端的资源（如CPU、内存、数据库连接等）可以得到更有效的利用，提高了整体的资源利用率。

3. 实现更高效的配置推送

实时性更强：长轮询机制使得配置变更能够更实时地推送到客户端。一旦配置发生变化，服务端会立即将更新推送给所有等待的客户端，而无需等待下一次轮询周期。
减少客户端资源消耗：客户端无需频繁地发送请求以检查配置是否更新，从而减少了网络带宽和CPU资源的消耗。

4. 更好的用户体验

减少等待时间：由于推送延迟的降低，用户在访问依赖于配置的服务时能够更快地看到更新后的内容，从而提升了用户体验。
更稳定的服务：长轮询机制有助于保持服务的稳定性，减少了因配置未及时更新而导致的服务异常或错误。

5. 易于实现和维护

代码简洁：长轮询机制的实现相对简单，通常只需要在服务端维护一个等待队列和相应的超时机制即可。
易于扩展：随着业务的增长和配置项的增多，长轮询机制可以很容易地进行扩展以支持更多的客户端和更复杂的配置场景。

综上所述，Nacos服务端采用长轮询机制具有降低推送延迟、减轻服务端压力、实现更高效的配置推送、提升用户体验以及易于实现和维护等多个好处。这些好处使得Nacos成为了一个高效、可靠且易于扩展的配置中心解决方案。

性能优化：

Jprofiler 方法热点定位

JVM基础的性能分析 Jvisualvm 堆栈内存分配 GC次数

MAT：内存泄露根据支配树去判断当前的情况线程命名

Async Profiler 定位CPU的热点锁的瓶颈

以前的项目

4个后端 1个前端 2个开发 1个产品

6个后端 1个测试 2组开发（12个）运维