冷热分离

1. 识别冷热数据： 作者将“最后更新时间超过一个月且状态为‘关闭’”的工单定义为冷数据，其余为热数据。
• 思考： 这里的判断标准是根据什么来制定的？(答案：根据业务场景和用户查询习惯，大部分情况下用户只关心近期的工单。)

2. 数据分离： 将冷数据迁移到新的数据库（冷库），原数据库保留热数据（热库）。

3. 触发机制： 作者对比了三种触发机制：
• 修改业务代码： 每次数据更新都判断是否需要进行冷热分离。
• 优点： 逻辑清晰，实时性高。
• 缺点： 代码侵入性强，每次更新都要判断，影响性能。
• 监听数据库binlog： 通过监听数据库的binlog日志来判断数据是否需要迁移。
• 优点： 与业务代码解耦。
• 缺点： 实现相对复杂。
• 定时扫描数据库： 定期扫描数据库，将符合条件的数据迁移到冷库。
• 优点： 实现简单，对业务代码无侵入。
• 缺点： 实时性较差。
作者最终选择了定时扫描数据库，因为业务场景允许一定的延迟，而且实现简单。

4. 执行数据迁移： 作者采用的方案是：
• 在热库中给需要迁移的数据加一个标识。
• 找出所有待迁移的数据。
• 在冷库中保存一份数据（要保证幂等性，避免重复插入）。
• 从热库中删除对应的数据。
• 使用多个线程并发执行迁移，提高效率。

• 问题： 在将数据从热库迁移到冷库的过程中，如果发生错误（例如程序异常、服务器宕机、网络中断等），可能会导致数据丢失或重复。

• 解决方案：
• 事务： 如果数据库支持事务，可以将数据复制和删除操作放在同一个事务中，确保这两个操作要么同时成功，要么同时失败。
• 标识 + 幂等性： 正如书中所说，给要迁移的数据添加一个标识（例如：is_cold=1），然后在冷库中插入数据前先根据数据的唯一标识（例如订单ID）进行查询，如果已经存在则不插入，确保幂等性。
• 重试机制： 如果数据迁移失败，可以进行重试。重试机制需要考虑重试次数、重试间隔等因素，避免无限重试导致系统压力过大。
• 对账机制： 数据迁移完成后，可以进行数据对账，例如对比热库和冷库中迁移的数据量是否一致，确保数据没有丢失或重复

• 问题： 在高并发场景下，多个线程可能同时操作同一条数据，例如一个线程正在将数据迁移到冷库，而另一个线程正在修改这条数据，可能会导致数据不一致。

• 解决方案：
• 加锁： 在迁移数据时，可以对要迁移的数据进行加锁，例如使用数据库的行锁或表锁，防止其他线程同时修改这条数据。但是，加锁会影响系统的并发性能，需要根据实际情况进行权衡。书中提到了锁超时机制，以防止锁长时间不释放导致死锁。
• 乐观锁： 使用版本号或时间戳等机制来实现乐观锁，在更新数据前先检查数据的版本号或时间戳是否发生变化，如果发生变化则说明数据已经被其他线程修改，此时可以选择重试或放弃更新。
• 先处理写，再迁移： 可以将写操作优先于数据迁移操作，例如在数据更新时，先更新热库中的数据，再将其标记为待迁移，最后由定时任务将待迁移的数据迁移到冷库。这样可以避免在数据迁移过程中发生数据更新导致的不一致问题。

• 问题： 数据从热库迁移到冷库需要一定的时间，在这段时间内，如果用户访问冷库，可能会看到旧的数据。

• 解决方案：
• 根据业务场景容忍延迟： 如果业务场景允许一定的数据延迟，例如用户查询历史订单，可以接受短暂的数据不一致。
• 提示用户： 可以在页面上提示用户数据可能存在延迟，或者让用户手动刷新数据。
• 先查询热库，再查询冷库： 如果业务场景要求较高的数据实时性，可以在查询数据时先查询热库，如果热库中没有找到数据，再去冷库中查询。

读写分离

• 主库（Master）： 负责处理写操作（INSERT, UPDATE, DELETE）。

• 从库（Slave）： 负责处理读操作（SELECT）。

• 数据同步： 主库的数据需要实时同步到从库。

• 分担压力： 读操作通常比写操作频繁得多，将读操作分离到从库，可以减轻主库的压力，提高系统的整体性能。

• 提高读性能： 从库可以针对读操作进行优化，例如使用更多的索引、使用更快的存储介质等。

• 提高可用性： 即使主库出现故障，从库仍然可以提供读服务，保证系统的可用性。

• 根据工单ID查询

• 根据客户名称查询

• 根据工单状态查询

• 根据工单创建时间范围查询

• 根据多个条件的组合进行查询（例如：查询某个时间段内，状态为“处理中”，并且客户名称包含“XX”的所有工单）

• 主库：MySQL
• 职责： 处理工单数据的 写入（创建工单）和 更新（修改工单状态、添加备注等）。
• 特点： MySQL擅长事务处理，能保证数据的一致性和完整性。

• 从库：Elasticsearch
• 职责： 处理工单数据的 查询。
• 特点： Elasticsearch擅长复杂的搜索和分析，可以快速地执行各种查询操作，即使数据量很大也能保持良好的性能。

• 数据同步： 需要将MySQL（主库）中的工单数据 实时同步 到Elasticsearch（从库）。

1. 应用服务写入数据到MySQL： 当用户创建一个新的工单或更新一个工单时，应用服务会将数据写入到MySQL数据库中。

2. MySQL触发binlog： MySQL数据库会记录数据的变更日志（binlog）。

3. 消息队列（MQ）订阅binlog： 使用一个消息队列（例如Kafka）来订阅MySQL的binlog。

4. 消息队列将数据变更消息发送给Elasticsearch同步服务： 当MySQL中的数据发生变化时，消息队列会将数据变更消息发送给一个专门负责数据同步的服务（例如，可以称之为Elasticsearch同步服务）。

5. Elasticsearch同步服务更新Elasticsearch索引： Elasticsearch同步服务接收到消息后，解析消息内容，并根据消息内容更新Elasticsearch中的工单数据索引。

1. 用户在前端发起查询请求： 用户在工单查询页面输入查询条件，例如工单状态、创建时间等。

2. 查询请求发送到Elasticsearch： 前端将查询请求发送到Elasticsearch集群。

3. Elasticsearch执行查询： Elasticsearch根据查询条件，在工单数据索引中执行查询操作。

4. Elasticsearch返回查询结果： Elasticsearch将查询结果返回给前端。

5. 前端展示查询结果： 前端将查询结果展示给用户。

shardingsphere

自动路由规则

• 写操作：所有 INSERT/UPDATE/DELETE 语句自动路由到主库（master）。

• 读操作：所有 SELECT 语句自动路由到从库（slave1 或 slave2）

数据不一致的问题：

(1) 强一致性（主库读）

• 场景：金融交易、订单支付等对实时性要求极高的操作。

• 方案：
• 写后读主库：写入主库后，后续的读请求强制走主库。
• Hint 强制路由：通过中间件（如 ShardingSphere）的 Hint 机制强制路由到主库。

(2) 会话一致性（同一会话内读主库）

• 场景：用户提交表单后需要立即查看结果（如发布文章后跳转到详情页）。

• 方案：
• 粘性会话（Sticky Session）：同一会话内的读请求路由到主库，可通过 Cookie 或 Token 标识会话。
• 时间窗口控制：写入后的一段时间内（如 3 秒），读请求强制走主库。

(3) 最终一致性（容忍延迟）

• 场景：商品列表展示、评论加载等非敏感操作。

• 方案：
• 异步同步：接受主从延迟（如 1 秒），通过监控同步状态确保最终一致。
• 业务降级：若从库延迟过高，自动切换读主库。

数据同步：

主从复制机制优化

• MySQL 半同步复制（Semi-Sync Replication）
• 原理：主库提交事务前，至少一个从库确认收到 Binlog。
• 配置：
 
• 优点：降低数据丢失风险，提升同步可靠性。

• GTID（全局事务标识）
• 原理：为每个事务分配唯一 ID，便于追踪和修复主从不一致。
• 配置：
ini
Copy

(2) 同步工具的选择与容错

• 工具选择：
• Canal：基于 MySQL Binlog 的增量订阅和消费组件。
• Debezium：支持多种数据库的分布式 CDC（Change Data Capture）工具。
• Maxwell：轻量级的 MySQL Binlog 解析工具。

• 容错设计：
• 断点续传：记录同步位置（如 Binlog Offset），中断后从断点恢复。
• 重试机制：网络波动时自动重试，避免数据丢失。
• 死信队列（DLQ）：同步失败的数据存入队列，人工介入修复。

(3) 数据一致性校验与修复

• 定期校验：使用工具（如 pt-table-checksum）对比主从数据一致性。

• 自动修复：通过 pt-table-sync 修复不一致数据。

分表分库

分库分表解决的核心问题

二、分库分表的实现方式

1. 垂直分片（Vertical Sharding）

• 定义：按业务模块拆分表到不同的数据库（如用户库、订单库、商品库）。

• 示例：
• 原始单库：main_db（包含 users, orders, products 表）。
• 垂直拆分后：
• user_db：仅含 users 表。
• order_db：仅含 orders 表。
• product_db：仅含 products 表。

• 优点：业务解耦，降低单库压力。

• 缺点：无法解决单表数据量过大的问题。

2. 水平分片（Horizontal Sharding）

• 定义：将同一张表的数据按规则拆分到多个数据库或表中。

• 示例：将 orders 表按 user_id 分片到 4 个库，每个库分 4 张表（共 16 张表）。
• 分库规则：user_id % 4 → 路由到 order_db_0 至 order_db_3。
• 分表规则：order_id % 4 → 路由到 orders_0 至 orders_3。

• 优点：解决单表数据量和并发压力。

• 缺点：跨库查询复杂，需业务层或中间件支持。

三、分库分表的具体策略

1. 分片键选择

• 原则：选择查询频率高、数据分布均匀的字段（如 user_id、order_id）。

• 常见分片键：
• 用户ID（user_id）：适合用户维度查询（如查询某用户的所有订单）。
• 订单ID（order_id）：适合按订单精确查询。
• 时间（create_time）：适合按时间范围查询（如按月分表）。

2. 分片算法

完整示例：电商订单表水平分库分表

1. 场景需求

• 订单表 orders 数据量已达 10 亿，单库性能无法支撑。

• 高频查询：按 user_id 查订单列表，按 order_id 查订单详情。

2. 分片方案

• 分片键：user_id（用户维度查询最多）。

• 分库数量：4 个库（order_db_0 至 order_db_3）。

• 分表数量：每库 4 张表（orders_0 至 orders_3）。

• 路由规则：
• 库选择：user_id % 4 → 确定库。
• 表选择：user_id % 4 → 确定表。

3. 数据分布示例

读缓存

读缓存解决的问题及使用场景（以 Redis 为例）

1. 缓解数据库压力：高频读请求直接命中缓存，避免频繁访问数据库。

2. 提升响应速度：内存读写速度远高于磁盘（如 Redis 可达 10万+ QPS）。

3. 降低系统耦合：缓存层可作为数据库的缓冲屏障。

二、缓存加载策略

1. 预加载（Pre-Loading）

• 原理：系统启动时或数据变更前主动加载数据到缓存。

• 适用场景：已知热点数据（如首页推荐列表）

2. 懒加载（Lazy-Loading）

• 原理：按需加载数据，首次请求时触发缓存写入。

• 适用场景：动态或低频数据（如用户个性化配置）。

• Redis 实现：

缓存失效策略

1. TTL（Time-To-Live）

• Redis 实现：SETEX 或 EXPIRE 命令设置过期时间。

2. 主动淘汰

• 策略：LRU/LFU 算法自动淘汰旧数据。

• Redis 配置：

缓存的更新策略

1. 先更新缓存，再更新数据库

流程：

1. 更新缓存 → 2. 更新数据库

优点：

• 实现简单：无复杂逻辑，适合简单业务。

• 读性能高：后续读请求直接命中最新缓存。

缺点：

• 数据不一致风险高：若数据库更新失败，缓存中是脏数据。

• 回滚困难：数据库失败后需回滚缓存（Redis 不支持事务回滚）。

场景举例：

• 临时统计数据（如页面 UV 计数），允许短暂不一致。

Redis 伪代码：

2. 先删除缓存，再更新数据库

流程：

1. 删除缓存 → 2. 更新数据库

优点：

• 避免旧数据残留：删除缓存后，下次读取会触发缓存重建。

缺点：

• 缓存击穿风险：删除缓存后，若数据库更新未完成时有大量请求涌入，会穿透到数据库。

• 短暂不一致：数据库更新期间，新请求可能读到旧数据并回填缓存。

场景举例：

• 低频写操作（如修改用户昵称），可容忍短暂不一致。

Redis 伪代码：

3. 先更新数据库，再删除缓存

流程：

1. 更新数据库 → 2. 删除缓存

优点：

• 降低不一致概率：数据库更新成功后才会删除缓存。

• 实现简单：适合大多数业务场景。

缺点：

• 删除失败风险：若第二步删除缓存失败，缓存中仍是旧数据。

• 并发问题：在删除缓存前，可能有请求读取到旧数据并回填缓存。

场景举例：

• 高频读场景（如商品价格更新），结合重试机制保障删除成功。

Redis 优化方案：

4. 先删除缓存，更新数据库，再删除缓存（延迟双删）

流程：

1. 删除缓存 → 2. 更新数据库 → 3. 延迟一段时间后再次删除缓存

优点：

• 进一步降低不一致：处理并发请求在更新期间写入旧数据到缓存的问题。

缺点：

• 实现复杂：需引入延迟队列或定时任务。

• 性能损耗：二次删除增加延迟。

适用场景：

• 高并发强一致性场景（如库存扣减）。

Redis 实现示例：

策略对比与选型指南

实际工程中的组合策略

1. 基础方案：优先使用 「先更新数据库，再删除缓存」，配合以下优化：
• 异步重试：若缓存删除失败，通过消息队列重试。
• 互斥锁：防止缓存击穿（Redis 的 SETNX 或 Redlock）。

2. 高阶方案：在金融级场景使用 「延迟双删」，结合以下手段：
• 监听数据库 Binlog：通过 Canal 或 Debezium 监听数据库变更，触发二次删除。
• 设置合理延迟时间：根据业务并发量调整二次删除的延迟（通常 100ms~1s）。

总结

• 优先选择：先更新数据库再删除缓存 + 异步重试，覆盖 90% 场景。

• 极端场景：延迟双删 + Binlog 监听，解决高并发强一致性问题。

• 避免使用：先更新缓存再更新数据库，除非业务允许脏数据长期存在。

三大缓存问题解决方案

1. 缓存穿透（Cache Penetration）

• 问题：恶意请求不存在的数据（如 id=-1）。

• 解决方案：
• 布隆过滤器（Bloom Filter）拦截非法请求。
• 缓存空值：SETEX null 60 并设置较短过期时间。

2. 缓存击穿（Cache Breakdown）

• 问题：热点数据过期瞬间大量请求压垮数据库。

• 解决方案：
• 互斥锁（Redis 的 SETNX）：
• 逻辑过期：缓存永不过期，后台异步更新。

3. 缓存雪崩（Cache Avalanche）

• 问题：大量缓存同时失效导致数据库压力激增。

• 解决方案：
• 随机化过期时间：基础过期时间 + 随机偏移量。
• 多级缓存：本地缓存（如 Caffeine） + Redis 分层失效。
• 集群高可用：Redis Sentinel 或 Cluster 避免单点故障。

写缓存

• 削峰填谷： 写缓存可以将突发的写请求流量平滑地写入到数据库中，避免数据库被瞬间压垮。就像一个水库，可以拦蓄洪水，然后在下游慢慢泄洪。

• 提高响应速度： 写缓存的性能通常比数据库高得多，可以快速地响应用户的写请求，提升用户体验。

• 保护数据库： 通过将写请求先写入缓存，可以减少直接对数据库的写入操作，保护数据库免受高并发写请求的冲击

1. 触发机制：请求数量 + 时间间隔双触发

• 实现方式：
• 计数器触发：使用Redis的List或Stream结构缓存请求，每次写入时检查列表长度。当长度达到阈值（如1000条）时，触发批量落库。
• 定时器触发：结合后台任务（如Redis的键空间通知或外部定时任务框架），每隔固定时间（如5秒）强制触发一次落库，防止低流量时数据滞留。

• 示例代码逻辑：

2. 批量落库大小：动态调整 + 性能压测

• 动态配置：将批量大小（如BATCH_SIZE=500）存储在Redis或配置中心，支持运行时调整。

• 性能优化：
• 通过压测确定数据库的吞吐量极限（如单次批量插入最多1000条时，数据库延迟在50ms内）。
• 根据业务高峰/低谷动态调整批次大小（如高峰时减小批次，避免数据库过载）。

3. 数据丢失风险：持久化 + 重试 + 备份

• Redis持久化：
• 启用AOF（Append-Only File）并配置为appendfsync everysec，平衡性能与数据安全。
• 定期备份RDB快照到云存储（如S3）。

• 落库失败处理：
• 重试机制：失败时记录重试次数，使用指数退避策略（如1s、2s、4s...重试）。
• 死信队列：将多次重试失败的数据转移到独立队列（如Redis的dead_letter_queue），后续人工干预或异步修复。

• 冗余备份：
• 写入Redis前，先发送到消息队列（如Kafka）作为备份，确保即使Redis宕机，数据仍可通过消息队列恢复。

4. 并发控制：原子操作 + 分布式锁

• 写入缓存时的并发：
• 利用Redis单线程特性，直接使用LPUSH或XADD命令，天然原子性。

• 批量落库时的并发：
• 分布式锁：使用SETNX或Redisson实现锁，确保同一时间只有一个线程处理批量落库。
• 数据库事务：在落库时开启事务，确保批量操作原子提交，失败时整体回滚。

• 数据一致性：
• 使用乐观锁（如版本号）或悲观锁（SELECT FOR UPDATE）避免数据库并发写入冲突。

5. 扩展优化与监控

• 顺序保证：
• 使用Redis Streams结构，确保消息顺序消费，避免乱序落库。

• 内存控制：
• 为Redis设置最大内存限制，配合淘汰策略（如volatile-lru），避免OOM。

• 监控告警：
• 监控Redis内存、批量落库延迟、失败重试次数等指标。
• 配置告警（如Prometheus + Grafana），当队列堆积或失败率超标时通知运维。

设计电商秒杀系统

1. 架构设计

分层架构

核心组件

1. 前端层：静态页面 + 动态验证（防止脚本刷单）

2. 网关层：流量控制、熔断降级、请求过滤

3. 服务层：无状态服务集群，处理核心秒杀逻辑

4. 缓存层：Redis（库存预热、原子扣减）

5. 数据库层：MySQL（最终数据持久化）+ 分库分表

6. 消息队列：Kafka/RocketMQ（异步削峰、订单处理）

2. 高并发应对策略

(1) 流量控制

• 前端优化：
• 静态资源CDN加速，减少服务器带宽压力。
• 按钮防重复点击（点击后置灰，倒计时结束恢复）。
• 动态验证码（滑块/算术验证码）过滤机器人请求。

• 网关层限流：
• 令牌桶算法：限制每秒请求量（如10万QPS）。
• IP/用户限流：同一用户每秒最多1次请求。
• 队列排队：请求超出阈值时返回“排队中”提示（如小米手机抢购）。

(2) 异步削峰

• 请求异步化：
• 用户点击后，请求直接进入消息队列，返回“处理中”状态。
• 后端消费队列生成订单，完成后通知用户。

• 消息队列设计：
• 使用Kafka分区，按商品ID分片，保证同一商品的请求顺序处理。
• 消费者集群并行处理，提升吞吐量。

(3) 无状态服务横向扩展

• 服务层采用Kubernetes动态扩缩容，根据CPU/内存负载自动增减实例。

3. 数据一致性保障

(1) 库存防超卖

• Redis原子扣减：
• 秒杀开始前，将库存预热到Redis（INIT_STOCK = 1000）。
• 使用DECR命令扣减库存（原子操作，无需锁）：

• 数据库最终一致性：
• Redis扣减成功后，发送消息到MQ，异步更新MySQL库存。
• 使用事务消息（如RocketMQ事务消息）保证本地事务与消息发送的原子性。

(2) 订单幂等性

• 用户ID+商品ID生成唯一订单号，结合数据库唯一索引防止重复下单。

4. 容灾与降级

(1) 熔断降级

• 监控Redis、MySQL、MQ的响应时间，超出阈值时触发降级策略：
• 限流模式：直接返回“活动太火爆，请稍后再试”。
• 兜底数据：展示静态库存数量（如“仅剩最后100件”）。

(2) 数据持久化

• Redis持久化：AOF每秒刷盘 + RDB定时快照。

• MySQL Binlog同步：通过Canal监听Binlog，补偿Redis与数据库的数据不一致。

(3) 故障转移

• Redis主从集群 + Sentinel哨兵模式，主节点宕机自动切换。

• MySQL主从读写分离，主库宕机切从库（半同步复制）。

5. 性能压测与监控

(1) 压测指标

• 模拟10万用户并发，验证：
• Redis吞吐量（目标：10万QPS）。
• MySQL写入延迟（目标：<50ms）。
• 系统整体TP99响应时间（目标：<200ms）。

(2) 监控告警

• 核心监控项：
• Redis内存、连接数、命中率。
• MySQL主从延迟、慢查询。
• MQ堆积量、消费延迟。

• 告警阈值：
• Redis内存 >80% → 触发扩容。
• 订单处理延迟 >5秒 → 触发消费者扩容。

6. 完整流程示例

1. 用户请求：
• 前端：点击秒杀按钮 → 发送请求到网关，携带用户ID和商品ID。

2. 网关层：
• 校验用户令牌 → 限流（如令牌桶10万QPS） → 放行到服务层。

3. 服务层：
• 调用Redis执行Lua脚本扣减库存。
• 扣减成功 → 生成订单号，发送消息到MQ。
• 扣减失败 → 返回“库存不足”。

4. 异步处理：
• MQ消费者读取消息，写入MySQL订单表，更新库存（UPDATE stock SET stock = stock - 1 WHERE id=#{item_id} AND stock > 0）。

5. 结果通知：
• 订单创建成功 → 短信/站内信通知用户。
• 订单创建失败（如数据库唯一键冲突） → 回滚Redis库存（INCR）。

7. 优化扩展

• 热点数据隔离：将热门商品（如iPhone）的库存拆分到独立Redis实例。

• 分布式锁兜底：极端情况下（如Redis宕机），使用Redisson分布式锁 + MySQL行锁扣减库存。

• 动态库存预热：根据历史数据预测秒杀商品，提前加载到缓存。

总结

1. 吞吐量：支持百万级QPS。

2. 一致性：通过Redis原子操作 + 事务消息，超卖率趋近于0。

3. 可用性：故障自动转移，99.99%可用性。

注册和发现

一、Nacos 是什么？

1. 服务注册与发现：服务实例自动注册，消费者动态发现服务列表。

2. 配置管理：集中管理所有环境、应用的配置，支持动态更新。

3. 服务健康监测：自动检测服务实例健康状态，剔除异常节点。

4. 动态DNS服务：基于权重的负载均衡和路由策略。

二、Nacos 核心机制详解（面试必问！）

1. 服务注册与发现

• 工作流程：
1. 服务启动时，向Nacos Server发送注册请求（包含IP、端口、服务名）。
2. Nacos Server将服务信息存储到注册表（内存或持久化存储）。
3. 消费者通过服务名查询Nacos，获取可用实例列表。
4. 客户端本地缓存列表，定时（默认1秒）同步更新。

• 关键配置：

• 面试问题：
• 临时实例 vs 持久实例：
• 临时实例（默认）：通过客户端心跳保持存活，宕机自动剔除。
• 持久实例：需服务端主动探测，适合数据库等有状态服务。
• 注册表存储方式：
• 默认内存存储（AP模式高可用），可选MySQL持久化（CP模式）。

2. 配置管理

• 核心概念：
• Data ID：配置的唯一标识，格式：${prefix}-${spring.profile.active}.${file-extension}。
• Group：配置分组，默认DEFAULT_GROUP，用于环境隔离。
• Namespace：命名空间，实现多租户隔离（如dev/test/prod环境）。

• 动态配置更新：

• 配置监听原理：
• 客户端通过长轮询（Long Polling）机制监听配置变更。
• 默认每30秒检查一次，服务端有变更立即返回，否则hold住29.5秒。

• 面试问题：
• 如何保证配置更新的实时性？
• 长轮询机制 + 客户端本地缓存 + 版本号比对。
• 配置回滚如何实现？
• Nacos控制台提供历史版本一键回滚功能。

三、Nacos 高可用与集群（生产必会！）

1. 集群部署方案

• 最小集群：3个Nacos节点 + 1个MySQL集群（或内嵌Derby）。

• 架构图：

• 配置要点：
• 修改conf/cluster.conf，列出所有节点IP:Port。
• 数据库配置application.properties：

2. 数据一致性模型

• AP模式（默认）：
• 使用自研的Distro协议，保证最终一致性。
• 适用场景：服务发现（允许短暂不一致）。

• CP模式：
• 使用Raft协议，保证强一致性。
• 适用场景：配置管理、数据库注册（要求强一致）。

四、实际应用场景与代码示例

1. 服务发现 + 负载均衡

2. 多环境配置隔离

• 命名空间：为每个环境（dev/test/prod）创建独立Namespace。

• 配置示例：

3. 灰度发布

• 基于元数据路由：

五、常见问题排查（实战经验）

1. 服务注册失败：
• 检查Nacos Server是否可达。
• 查看客户端日志中的心跳发送状态。

2. 配置不生效：
• 确认@RefreshScope注解已添加。
• 检查Data ID、Group、Namespace是否匹配。

3. 集群节点数据不一致：
• AP模式下短暂不一致是正常的，持续不一致需检查网络分区。

六、面试加分项

1. Nacos 2.0 新特性：
• 长连接代替HTTP轮询，减少网络开销。
• 增强鉴权和安全机制。

2. 与Spring Cloud Alibaba整合：

3. 性能调优：
• 调整心跳间隔（不宜过短，避免服务端压力）。
• 使用MySQL分库分表存储海量配置。

总结

• 如何用Nacos实现服务平滑上下线？

• 如何设计多环境配置隔离？

• 如何处理服务发现中的网络分区问题？

全链路日志

1. 全链路追踪：可视化请求路径，快速定位瓶颈服务。

2. 日志集中分析：通过Trace ID关联所有相关日志。

3. 业务上下文增强：在Span和日志中添加业务标签（如订单ID、仓库编号）

熔断

• 熔断器（Circuit Breaker）： 熔断机制的核心组件，负责监控服务的调用情况，并在服务出现故障时触发熔断。

• 触发条件： 判断服务是否需要熔断的条件，例如：
• 错误率： 当服务调用的错误率达到一定阈值时触发熔断。
• 响应时间： 当服务调用的响应时间超过一定阈值时触发熔断。
• 请求数： 当服务调用的请求数达到一定阈值时触发熔断。

• 熔断状态： 熔断器通常有三种状态：
• 关闭（Closed）： 正常状态，允许请求通过。
• 打开（Open）： 熔断状态，所有请求都被拒绝，并快速返回fallback结果。
• 半开（Half-Open）： 熔断器打开一段时间后，会进入半开状态，允许少量请求通过，如果这些请求都成功，则将熔断器关闭，否则继续保持打开状态。

• Fallback（回退）： 当熔断器打开时，返回的预定义结果。例如，可以返回一个默认值、一个错误提示或一个备用方案。

限流

• 限流： 主动预防，控制进入系统的流量，防止系统过载。

• 熔断： 被动保护，当系统出现故障时，快速失败，防止故障扩散。

1. 算法选择：优先使用令牌桶应对突发流量

2. 维度设计：结合业务特征设置限流维度

3. 动态调整：根据实时负载弹性伸缩

4. 降级策略：限流后返回队列位置/等待时间

1. 网关层：用Nginx/Sentinel做粗粒度防护

2. 服务层：用Sentinel/Resilience4j实现细粒度规则

3. 数据层：限制连接池大小防止拖垮数据库

微服务的问题

• 问题： 如何合理地划分微服务的职责边界？ 职责划分过细，会导致服务数量过多，增加系统复杂性；职责划分过粗，又失去了微服务的意义。 实际工作中，职责划分往往受到人员、工期、组织架构的影响，甚至最后与最初的设计完全不同。

• 例子： 一个商品库存，应该放在商品服务还是门店服务？一个相关商品设置功能，因为门店服务开发人员忙，最后放到了商品服务里。

• 反思： 微服务划分需要结合业务、团队、技术等多方面因素综合考虑，没有银弹，需要在实践中不断调整。

• 问题： 微服务应该拆分到多细的粒度？ 拆得过细，会导致服务数量过多，增加运维和管理的复杂度；拆得过粗，又失去了微服务的优势。

• 例子： 一个加盟商管理，从最开始的一个服务，到拆分出财务、员工管理、返点、子门店等多个服务，最后变成了一个团队维护几十个服务，新员工难以入手。

• 反思： 需要根据团队规模、业务复杂度、技术能力等因素综合考虑， 找到一个平衡点。作者建议以3~4人维护为宜。 警惕为了“微服务”而“微服务”。

• 问题： 随着微服务数量的增多，没有人能够清楚地了解整个系统的架构，难以对系统进行整体把控和优化。

• 例子： 领导要求各个团队提供微服务清单，并解释每个微服务的作用。因为服务太多，且涉及多个团队，大家都难以描述清楚。

• 反思： 需要建立完善的文档和监控机制，并定期进行架构评审，确保架构的清晰和可控。

• 问题： 由于缺乏有效的代码共享机制，导致不同微服务中存在大量重复的代码，降低了开发效率，也增加了维护成本。

• 例子： 一个日志埋点工具，因为版本依赖问题，不得不在多个微服务中复制粘贴代码。

• 反思： 需要建立统一的代码规范和公共组件库，并思考更有效的方式解决版本冲突。

• 问题： 相比单体应用，微服务架构需要部署更多的服务实例，占用更多的服务器资源。

• 例子： 一个简单的应用拆分成多个微服务后，服务器数量从5台增加到15台。

• 反思： 需要根据实际的业务需求和系统负载来评估微服务的拆分粒度，避免过度拆分。

• 问题： 在微服务架构下，一个业务操作可能需要跨多个服务和多个数据库，如何保证数据的一致性？

• 例子： 一个下单流程，需要调用订单服务、库存服务、支付服务等多个服务，如何保证这些服务要么全部成功，要么全部失败？

• 反思： 分布式事务是微服务架构中的一个难题，没有完美的解决方案，需要根据具体的业务场景选择合适的方案，例如TCC模式、Seata等。

• 问题： 微服务之间存在复杂的依赖关系，一个服务的变更可能会影响到其他服务，导致系统不稳定。

• 例子： 商品服务依赖门店服务，门店服务又依赖商品服务，形成循环依赖；财务系统作为底层服务，几乎依赖了所有其他业务系统。

• 反思： 需要合理设计服务之间的依赖关系，避免循环依赖和复杂的依赖链。

• 问题： 微服务架构下，一个业务流程通常需要多个服务协同完成，如何进行高效的联调测试？

• 例子： 一个项目涉及30多个服务，接口文档核对、联调花费了大量的时间。

• 反思： 需要建立完善的接口文档管理机制，并使用Mock服务等工具来提高联调效率。

• 问题： 微服务数量众多，如何快速、高效地部署和管理这些服务？

• 例子： 开发人员希望在本地搭建完整的微服务环境进行调试，但由于服务数量太多，本地环境无法支撑。

• 反思： 需要借助容器技术（例如Docker、Kubernetes）来实现服务的快速部署和管理。

多个服务数据库的数据一致性

1. Saga 模式

实现方式：

• 编排式（Choreography）：
• 各服务通过事件发布/订阅驱动流程。
• 流程示例：
1. 订单服务创建订单（Pending状态），发布OrderCreated事件。
2. 库存服务监听事件，扣减库存并发布StockReduced事件。
3. 支付服务监听事件，生成支付单并发布PaymentCreated事件。
4. 若所有成功，订单服务确认订单；若某一步失败（如支付失败），触发补偿事件（如PaymentFailed），各服务回滚操作。
• 优点：去中心化，服务间松耦合。
• 缺点：复杂度高，难调试。

• 编配式（Orchestration）：
• 引入协调器（Orchestrator）集中管理流程。
• 流程示例：
1. 协调器调用订单服务创建订单。
2. 成功后调用库存服务扣减库存。
3. 最后调用支付服务生成支付信息。
4. 若某步失败，协调器触发补偿操作（如恢复库存、删除订单）。
• 优点：流程可控，易监控。
• 缺点：协调器可能成为单点故障。

2. TCC（Try-Confirm-Cancel）模式

流程示例：

1. Try阶段：
• 库存服务：预扣库存（状态为冻结）。
• 订单服务：生成预订单（状态为待确认）。
• 支付服务：预生成支付单（状态为冻结）。

2. Confirm阶段：
• 若所有Try成功，各服务提交操作（库存扣减、订单生效、支付完成）。

3. Cancel阶段：
• 若任一Try失败，各服务回滚（恢复库存、删除预订单、取消支付）。

3. 基于消息队列的最终一致性

流程示例：

1. 订单服务创建订单，同时插入本地事务表（状态为进行中），发布OrderCreated事件。

2. 库存服务消费事件，扣减库存并发布StockReduced事件。

3. 支付服务消费事件，生成支付单并发布PaymentCreated事件。

4. 若所有成功，订单服务更新事务状态为完成；若失败，触发补偿消息。

• 消息幂等性：通过唯一ID去重，避免重复消费。

• 事务状态表：记录本地事务状态，定时扫描未完成事务进行重试或补偿。

• 死信队列：处理多次重试失败的消息，人工介入修复。

4. 分布式事务框架（如Seata）

AT模式（自动补偿）示例：

1. 全局事务协调器（TC）拦截业务SQL，生成前后镜像（用于回滚）。

2. 各服务执行本地事务，提交前向TC注册分支事务。

3. 若全部成功，TC通知提交；若失败，TC通过镜像数据自动回滚。

方案对比与选型建议

实施要点

1. 幂等性设计：所有操作需支持重复执行（如通过唯一事务ID）。

2. 补偿完备性：确保每个正向操作都有对应的补偿逻辑。

3. 监控与告警：跟踪事务状态，及时发现和修复不一致。

4. 超时与重试：合理设置超时时间，结合指数退避重试策略。

5. 人工兜底：提供管理界面手动干预异常事务。

微服务之间的数据同步

1. 数据冗余设计原则

• 最小化冗余：仅同步必要字段（如商品ID、名称、分类、型号），避免全量复制。

• 业务场景驱动：
• 订单服务：存储商品快照（如下单时的名称、价格），用于历史订单展示。
• 采购服务：存储库存、供应商信息，用于采购计划。

• 明确所有权：商品信息以商品服务为唯一权威数据源，其他服务冗余数据为只读副本。

2. 数据同步方案

方案一：事件驱动异步同步（最终一致性）

• 核心流程：
1. 商品服务在商品信息变更时（如名称修改、库存更新），发布领域事件（如ProductUpdated），包含变更后的关键字段。
2. 消息队列（如Kafka、RabbitMQ）可靠传递事件。
3. 订单服务和采购服务订阅事件，更新本地冗余数据。

• 关键设计：
• 幂等性：事件携带唯一ID或版本号，避免重复更新。
• 数据快照：事件中携带完整字段，避免多次查询商品服务。
• 补偿机制：若消费失败，通过死信队列重试或人工干预。

• 优点：松耦合、高可用、适合高频变更。

• 缺点：短暂数据不一致窗口（通常毫秒级）。

方案二：CDC（变更数据捕获）工具同步

• 实现方式：
1. 使用工具（如Debezium）监听商品服务数据库的binlog，捕获数据变更。
2. 将变更事件发送到消息队列。
3. 订单和采购服务消费事件，更新本地数据库。

• 适用场景：需同步大量字段或无法修改商品服务代码时。

• 优点：无业务代码侵入，实时性强。

• 缺点：需处理数据库Schema变更，运维复杂度高。

方案三：API聚合查询（避免冗余）

• 核心流程：
• 订单和采购服务在需要商品信息时，实时调用商品服务的API（如GET /products/{id}）。

• 适用场景：数据变更频繁但查询频率低，或对数据实时性要求极高。

• 优化措施：
• 本地缓存：使用Redis缓存商品信息，设置合理TTL。
• 批量查询：合并多个商品ID请求，减少网络开销。

• 优点：无冗余数据，一致性高。

• 缺点：依赖商品服务可用性，高并发下可能性能瓶颈。

3. 混合策略：按业务场景选择

4. 一致性保障措施

• 版本控制：
• 商品信息表增加version字段，每次更新递增。
• 事件中携带版本号，服务更新时校验版本，防止旧数据覆盖。

• 数据校对（Reconciliation）：
• 定时任务对比商品服务与订单/采购服务的数据差异，修复不一致。

• 监控与告警：
• 监控消息队列积压、同步延迟、API错误率，及时发现异常。

5. 技术栈示例

1. 事件驱动：Kafka（消息队列） + Avro（Schema序列化）。

2. CDC工具：Debezium + MySQL binlog。

3. 缓存：Redis（缓存商品信息） + 本地Caffeine（高频查询）。

4. API网关：聚合商品、订单、采购接口，减少客户端调用次数。

6. 注意事项

1. 避免跨服务事务：不要为同步数据引入分布式事务（如2PC），改用最终一致性。

2. 领域事件设计：事件应携带业务语义（如ProductPriceUpdated而非TableRowUpdated）。

3. 数据生命周期：订单服务的商品快照需永久保留，采购服务的冗余数据可设置TTL。

总结

• 订单服务订阅ProductUpdated事件，存储商品快照。

• 采购服务通过CDC监听库存变更，实时更新本地数据。

• 商品服务保持权威数据源地位，通过API提供实时查询。 结合版本控制、幂等性和监控，实现高效、可靠的数据同步。