JAVA面试题速记-分布式架构知识点-元一软件

1. 什么是分布式系统中的CAP原则

• CAP原则，它指出在一个分布式系统中，不可能同时满足以下三个核心保证：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。
• 一致性（Consistency）一致性意味着在分布式系统中的所有数据副本，在同一时刻是否同样的值。换句话说，一旦数据被更新，所有的用户都应该能够读取到最新的值。一致性可以进一步细分为强一致性、弱一致性和最终一致性，其中强一致性要求数据在更新后立即对所有用户可见，而最终一致性则允许系统在一段时间内达到数据一致的状态。
• 可用性（Availability）可用性保证每个请求不管成功或者失败都有响应。即使在部分系统组件失败或网络分区的情况下，系统仍然需要保证响应用户的请求，哪怕是在无法保证数据一致性的情况下。
• 分区容错性（Partition tolerance）分区容错性是指系统中任意信息的丢失或失败不会影响系统的继续运作。在实际的网络环境中，消息可能会丢失或延迟，因此分区容错性是分布式系统设计中必须要考虑的因素。
• CAP原则的权衡 由于网络分区在实际应用中是不可避免的，因此分布式系统设计时通常需要在一致性和可用性之间做出权衡。根据CAP原则，系统可以是以下两种类型之一：
• CP（一致性+分区容错性）：系统优先保证一致性，即使这意味着在网络分区发生时部分或全部请求无法得到及时响应。
• AP（可用性+分区容错性）：系统优先保证可用性，即使这意味着在网络分区发生时系统可能无法保证数据的即时一致性。

2.CAP 理论中 AP 方案的延伸BASE 理论

• BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足 BASE 理论的事务，我们称之为柔性事务。

• 基本可用 ： 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网址交易付款出现问题来，商品依然可以正常浏览。

• 软状态： 由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单中的“支付中”、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。

• 最终一致性： 最终一致是指的经过一段时间后，所有节点数据都将会达到一致。如订单的“支付中”状态，最终会变为“支付成功”或者“支付失败”，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

3. 分布式事务 Seata模式概述

• 在微服务架构中，分布式 事务是保障多个服务间数据一致性的关键。Seata作为开源的分布式事务解决方案，提供了AT（Auto Transaction）、TCC（Try-Confirm-Cancel）、Saga和XA四种主要事务模式。

• AT模式：基于数据库本地事务，通过代理数据源自动提交全局事务，适用于业务逻辑简单、对一致性要求较高的场景。
• TCC模式：通过开发者手动实现Try、Confirm、Cancel三个阶段的方法，提供灵活控制能力，适合复杂业务流程。
• Saga模式：适用于长周期、异步执行的事务处理，具备良好的容错性和可恢复性。
• XA模式：遵循传统的二阶段提交协议，保证强一致性，但性能开销较大。
• 各模式实现原理对比分析

• • • AT 基于数据库行锁和Undo Log进行回滚 最终一致 高 中等 低
    • TCC 需要开发者编写Try/Confirm/Cancel方法 强一致 依赖业务逻辑 高 高
    • Saga 顺序执行事务并记录补偿操作，失败时逆向执行 最终一致 低 高 中等
    • XA 两阶段提交协议，协调者统一管理资源 强一致 高 低 低

• 适用场景与优缺点深度 剖析
• 不同业务场景下，选择合适的事务模式至关重要。

AT模式 : 优点：无需修改业务代码，兼容性强；支持主流数据库。 缺点：不支持嵌套事务；不适合涉及多种资源类型的复杂业务。 用场景：订单支付、库存扣减等短事务。

TCC模式: 优点：高度可控，支持复杂组合事务；支持跨服务、跨资源。缺点：需大量业务编码；补偿逻辑设计复杂。适用场景：金融交易、账务系统等。

Saga模式: 优点：适合长时间运行任务；易于扩展。缺点：状态机管理复杂；补偿失败需人工干预。适用场景：物流调度、审批流程等。

XA模式: 优点：标准协议，强一致性；适合传统数据库环境。缺点：性能差；资源锁定时间长。适用场景：银行核心系统、数据迁移等。

4. 聊一下分布式锁原理和解决方案

• 场景通俗解释(电商案例): 同一时间点 ,两个微服务 A,微服务 B,进入了 订单服务的扣除库存方法中 ,微服务 A 和微服务 B 都查询到了还有1个 ,A 扣除了库存 1 个,B 也扣除库存 1 个,造成了超卖.这时候就用到分布式锁了.
• 基于数据库：利用唯一索引或SELECT ... FOR UPDATE实现，简单易用但性能差，需自行处理死锁与主从延迟问题。
• 基于Zookeeper：利用临时顺序节点和Watcher机制实现，可靠性高且天然避免死锁，支持公平锁，需要额外搭建注册中心或集群。
• 单纯的setnx key 无法满足业务场景:

• • a 不设置超时时间系统崩了 崩了后谁也拿不到锁,
  • b 设置超长过期时间系统崩了了可以时间到可以释放锁但资源占用高,
  • c 设置短过期时间业务还没处理完锁就释放了立马就被其他线程锁上了,
  • d 某线程 A 拿到锁还没操作完过期时间到了 线程 B 刚拿到锁操作 A 线程操作完释放了 B的锁 ,又引入了新问题删除了别人的锁 在 value 加入客户端 ID 避免删除别人的锁,
  • e:以上情况都乐观处理完 发现finally 块删除锁是非原子操作的又引入了lua脚本
  • 于是Redisson 就出现了为了解决以上问题.

• 基于Redisson(推荐)：通过SET key value NX EX lua脚本 加锁，结合唯一值(UUID)和Lua脚本保证释放锁的原子性，性能高但需注意主从切换导致锁丢失，可用Redisson封装实现自动续期（Watch Dog）。

5. 聊一下分布式消息解决方案

如何保证消息不丢失

RocketMQ在设计上通过生产者端、Broker端、消费者端三方面协同，最大程度保证消息在传输、存储、消费全链路中的可靠性。

生产者端保障生产者应优先使用同步发送模式，发送成功需等待Broker返回SEND_OK确认。RocketMQ客户端内置失败重试机制，默认会在不同Broker间轮询重发。若多次重试仍失败，业务系统需本地持久化消息（如存数据库），并通过定时任务等方式补偿发送。此外，可结合事务消息机制，将业务操作与消息发送绑定，确保一致性。

Broker端保障Broker负责消息的持久化存储与可靠投递。RocketMQ支持两种刷盘策略：

• SYNC_FLUSH：同步刷盘，写入磁盘成功后才返回ACK，可靠性高但性能略低。
• ASYNC_FLUSH：异步刷盘，默认200ms批量落盘，性能高但在宕机时可能丢失极少量数据。 在集群部署中，可启用同步主从复制（SYNC_MASTER）并设置minInSyncReplicas≥2，确保主节点宕机时从节点可接管，避免数据丢失。Broker还内置消费重试机制，失败消息会进入重试队列，最多重试16次，最终进入死信队列供人工处理。

消费者端保障消费者应采用手动ACK模式，业务处理成功后再返回CONSUME_SUCCESS，否则返回RECONSUME_LATER触发Broker重投递。由于重试可能导致重复消息，消费者需实现幂等性处理（如基于messageId去重），防止数据异常。

总结RocketMQ通过同步发送+重试补偿、同步刷盘+主从复制、手动ACK+幂等消费等机制，实现了端到端的高可靠消息传输。在高可用集群部署和合理参数配置下，可做到消息“几乎零丢失”，适用于对可靠性要求极高的业务场景。

6. rocketMQ如何保证消息的顺序性

• 生产者端的顺序性

在生产者端，RocketMQ通过确保消息发送的顺序来保证顺序性。为了避免由于网络波动或服务器异常导致的消息发送顺序错乱，RocketMQ采用了同步发送和业务状态控制的方式。例如，在订单系统中，可以通过业务时间的天然间隔和业务状态控制来减少顺序错乱的情况。此外，还可以通过分布式锁来锁定业务主键，控制不同生产者间的发送顺序。

• 存储端的顺序性

在消息存储端，RocketMQ通过控制消息队列来保证顺序性。每个Topic下划分了多个Queue，生产者在发送消息时不指定具体的Queue，而是通过Topic来指定发送。为了避免不同订单的消息被分配到不同的Queue，从而打乱顺序，RocketMQ允许将相同订单的消息放入同一个Queue中。这通过队列隔离来实现局部顺序性，保证同一订单的消息顺序性。

• 消费者端的顺序性

在消费者端，RocketMQ通过加锁机制来保证顺序性。消费者在启动时会向Broker申请对MessageQueue加锁，确保后续这个队列的消息只会发送给这个消费者。在消费消息时，消费者会申请MessageQueue锁，确保同一时间只有一个线程处理消息。此外，为了防止重复消费，还会对ProcessQueue加锁。

• 使用有序消费模式

在消费失败的情况下，RocketMQ提供了有序消费模式，例如ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT，表示稍后消费。这样，即使消费者服务出现问题，也不会影响后续消息的消费顺序。

总结

RocketMQ通过确保生产者、Queue和消费者之间的一对一关系，以及通过自定义负载均衡模式和有序消费模式来保证消息的顺序性。这些机制虽然可能会带来吞吐量降低和阻塞风险，但对于需要严格消息顺序的业务场景来说，这是必要的代价。

7. 分布式架构下大数据量如何处理

• 单体服务项目低成本改进方案

• • 采用 mysql 主从复制读写分离策略 和双机热备改造方案
  • 业务层扩展 Nginx 负载均衡 水平扩展
  • 数据层中通旧业务架构 1 个 Master 十几个 Slave
  • 优点可以把 40%-60%查询打到从库上, 缺点仍然无法解决单节点数据存储瓶颈

• 分布式架构改进方案 ShardingSphere

• • 数据库垂直拆分和水平拆分: 推荐垂直拆分 更符合领域驱动设计（DDD）： 在垂直分库中，订单库只负责订单表，用户库只负责用户表, 例如订单中心,用户中心,产品中心等。 避免耦合： 垂直分库强制开发者只能通过 API 或应用层服务进行交互，这恰好符合 DDD 倡导的聚合根之间通过“应用服务”或“领域事件”通信的原则。
  • 表结构垂直拆分和水平拆分: 水平拆分： 把一个表的数据拆分到多个数据库，每个数据库中的表结构不变。例如订单表 8000万条数据累计，表按照求模拆分为 order_1,order_2，数据分别路由到不同的表中。也可以按照月(推荐)拆分 order_20261(1 月分的数据) order_20262(2 月分数据) 类推
  • 分库分表面临问题和解决:主键重复问题:采用分布式主键 Snowflake 分布式事务:可采用主流 seata 分布式事务解决方案