Spring Boot内容系统高并发设计：帖子详情与评论架构实践

1. 项目概述：为什么一个“帖子详情+评论”功能值得单独深挖

在某内容社区的迭代过程中，我接手了一个看似平平无奇的需求：“实现帖子详情页及评论功能”。表面看，这不过是 Spring Boot 项目里一个再普通不过的 CRUD 模块——查一条帖子、查它的评论列表、提交一条新评论。但实际落地时，我连续三天没合眼，不是因为逻辑复杂，而是因为所有“理所当然”的设计，在真实用户行为和并发场景下全被推翻重来。

你可能也遇到过：前端传个postId=123，后端直接postMapper.selectById(123)，再commentMapper.selectByPostId(123)，返回 JSON 完事。这种写法在单元测试里跑得飞起，一上预发环境，用户刷详情页卡顿、评论提交失败率突然飙升到 15%、凌晨三点收到数据库连接池耗尽告警……问题不在代码有没有 bug，而在于我们默认把“帖子详情+评论”当成了静态快照，忽略了它背后真实的业务脉络：帖子有热度衰减、评论有实时性要求、用户会频繁刷新、爬虫会批量抓取、审核机制要介入、敏感词要过滤、未登录用户也要能看——这些都不是“加个 @Transactional 就完事”的事情。

这个项目标题里藏着三个关键隐性需求：数据一致性边界（帖子状态变更时评论是否同步冻结）、读写分离策略（详情页是高读低写，评论是高写低读）、扩展性锚点（未来要支持点赞、收藏、@提醒、图片上传、评论回复嵌套）。我后来把整个模块拆成四层：展示层（DTO 裁剪与组装）、聚合层（PostWithComments 聚合根）、领域层（CommentStatus、PostVisibility 等值对象）、基础设施层（分库分表路由、缓存穿透防护）。光是评论列表的分页查询，我们就否决了三种方案：MySQLLIMIT offset, size在百万级数据下偏移量越大越慢；Elasticsearch 全文检索对简单排序支持弱；Redis Sorted Set 存储时间戳做分页，又面临内存膨胀风险。最终采用“主键 ID + 时间戳”双条件游标分页，配合本地缓存预热，QPS 从 800 稳定提升到 3200。

如果你正在用 Spring Boot 做内容类系统，或者正被“明明功能都实现了，一压测就崩”困扰，这篇就是为你写的。它不讲 Spring Boot 基础配置，不堆注解清单，只聚焦一个真实场景：如何让“帖子详情及评论”这个高频入口，在千万级用户规模下，既扛住流量，又守住数据语义，还能快速迭代。接下来我会带你从零开始，把每个技术决策背后的算盘、踩过的坑、实测数据，掰开揉碎讲清楚。

2. 整体架构设计与核心思路拆解

2.1 为什么放弃“单表 JOIN 查询”，选择“分步聚合”模式

最直觉的实现方式，是写一条 SQL：

SELECT p.*, c.* FROM post p LEFT JOIN comment c ON p.id = c.post_id WHERE p.id = ? ORDER BY c.create_time DESC;

然后用 MyBatis 的<collection>标签自动映射成Post对象嵌套List<Comment>。我在第一版就用了这个方案，本地测试一切正常。但上线后发现两个致命问题：

• 数据库连接占用时间翻倍：JOIN 查询需要锁住两张表的相关行，当帖子有 500+ 条评论时，单次查询平均耗时从 12ms 涨到 47ms，且连接释放延迟明显。监控显示数据库活跃连接数在高峰时段持续高于阈值，拖慢其他业务接口。
• 缓存粒度失控：如果把整个PostWithComments对象缓存到 Redis，那么只要有一条新评论插入，就得清空整个帖子的缓存。而实际场景中，90% 的评论操作只影响最后一页，却导致首页详情页全部缓存失效，缓存命中率从 89% 暴跌至 34%。

我们转而采用“分步聚合”：先查帖子主数据，再查评论列表，最后在应用层组装。听起来多了一次网络调用，但收益远超预期：

1. 缓存可分级：帖子主数据（标题、作者、正文）缓存 24 小时，评论列表（按分页）缓存 5 分钟，互不影响；
2. 查询可异步化：帖子详情是强依赖，评论列表可降级为异步加载（前端先渲染帖子，再发请求拉评论）；
3. 限流可精细化：对/post/{id}接口限流 1000 QPS，对/post/{id}/comments接口限流 5000 QPS，匹配真实流量分布。

提示：分步聚合不是银弹。它增加了应用层逻辑复杂度，要求严格控制事务边界。我们的做法是：帖子查询用只读事务（@Transactional(readOnly = true)），评论查询完全不加事务，新增评论才开启独立事务。这样既避免了长事务锁表，又保证了写操作的数据一致性。

2.2 评论列表为何必须用“游标分页”，而不是传统Pageable

Spring Data JPA 默认支持PageRequest.of(page, size)，底层生成LIMIT ?, ?语句。这在小数据量时没问题，但当某热门帖子积累 20 万条评论后，第 1000 页（offset=99900）的查询会触发全表扫描，执行计划显示type: ALL，耗时稳定在 1.2 秒以上。

我们做了三组压测对比（数据量：15 万条评论，MySQL 5.7，8C16G）：

游标分页的核心思想是：不依赖物理偏移量，而依赖数据本身的有序特征。我们约定评论按create_time降序排列，每页取 20 条，那么第一页的“游标”就是最新评论的id和create_time；请求下一页时，前端传回这两个值，SQL 改为：

SELECT * FROM comment WHERE post_id = ? AND (create_time < ? OR (create_time = ? AND id < ?)) ORDER BY create_time DESC, id DESC LIMIT 20;

这个查询能完美利用(post_id, create_time, id)复合索引，执行计划显示type: range，且rows始终稳定在 20 左右。代价是牺牲了“跳转到任意页”的能力，但用户行为数据显示：99.3% 的评论浏览集中在前 5 页，跳转第 50 页的请求占比不足 0.02%，属于可接受的体验折衷。

2.3 为什么评论状态要独立建模，而不是用status TINYINT

很多团队用一个status字段表示评论状态：0-待审核、1-已发布、2-已删除、3-用户屏蔽。这种设计在初期很省事，但很快会暴露问题：

• 状态流转逻辑分散：审核通过要改 status，用户举报要改 status，系统自动过滤敏感词也要改 status，代码里散落着十几处if (status == 0) { ... }；
• 无法记录状态变更痕迹：运营同学问“这条评论为什么没显示”，你只能查日志，而日志格式不统一，难以追溯；
• 扩展性差：新增“定时发布”“仅好友可见”等需求时，TINYINT枚举值迅速膨胀，字段语义模糊。

我们定义了CommentStatus值对象，包含code（状态码）、reason（变更原因）、operator（操作人）、timestamp（变更时间）四个属性，并建立comment_status_log表记录每次变更。状态码采用语义化命名：PENDING_REVIEW、PUBLISHED、USER_DELETED、SYSTEM_BLOCKED。所有状态变更必须通过CommentStatusService.changeStatus()方法，该方法强制校验前置条件（如“已删除的评论不能再次审核”）、写入日志、触发事件（如通知用户“您的评论已通过审核”）。

注意：这里不是过度设计。某次线上事故中，因缓存未及时更新，导致用户看到自己删除的评论仍显示在列表里。有了状态日志，我们 5 分钟内定位到是缓存清理逻辑漏掉了USER_DELETED状态，补上后问题消失。没有这层抽象，排查至少要 2 小时。

3. 核心细节解析与实操要点

3.1 帖子详情 DTO 的精准裁剪：哪些字段该传，哪些必须砍

前端同学提了个需求：“详情页要显示作者头像、昵称、粉丝数、是否关注”。乍一看，这是个简单的关联查询：SELECT p.*, u.avatar, u.nickname, u.fans_count, f.is_followed FROM post p JOIN user u ON p.author_id = u.id LEFT JOIN follow f ON u.id = f.target_id AND f.follower_id = ?。

但我们立刻否决了。原因有三：

• 数据耦合过重：帖子服务本不该感知“关注关系”，这属于社交域，强行 JOIN 会让服务边界模糊；
• 性能灾难：fans_count是实时计算字段（SELECT COUNT(*) FROM follow WHERE target_id = ?），每次查帖子都要执行一次，QPS 上去直接拖垮用户库；
• 缓存失效雪崩：一个用户新增关注，会导致所有他发布的帖子缓存全部失效。

最终方案是：帖子详情 DTO 只包含帖子自身字段（id、title、content、authorId、createTime）；头像、昵称等用户信息由前端并行请求/user/profile/{id}获取；是否关注由前端调用/follow/status?targetId={authorId}判断。

我们定义了PostDetailDto：

@Data public class PostDetailDto { private Long id; private String title; private String content; private Long authorId; private LocalDateTime createTime; // 不包含 authorName, avatar 等 }

并在 Controller 层明确标注：

@GetMapping("/posts/{id}") @ApiOperation("获取帖子详情（不含作者扩展信息）") public Result<PostDetailDto> getPostDetail(@PathVariable Long id) { ... }

这个设计带来两个好处：一是服务职责清晰，帖子服务只管帖子；二是前端可自主控制加载策略——比如在列表页只加载title+authorId+createTime，点击进入详情页再并行拉取作者信息和关注状态，首屏渲染速度提升 40%。

3.2 评论提交的防刷与幂等性：不只是加个 Redis 计数器

评论提交接口/posts/{postId}/comments是典型的高危入口。我们遇到过真实案例：某营销号用脚本 1 秒内提交 200 条相同评论，占满数据库连接，导致正常用户无法提交。单纯用@RateLimiter注解或 Nginx 限流不够，因为攻击者会换 IP、换 User-Agent。

我们构建了三层防护：

1. 前端埋点验证：在提交按钮点击时，调用/captcha/token获取一个短期有效的 token（有效期 2 分钟），token 绑定当前设备指纹（UA+屏幕分辨率+Canvas Hash）。提交评论时必须携带此 token，后端校验其有效性及绑定关系。这一步拦截了 83% 的自动化脚本，因为它们无法模拟完整浏览器环境。

2. 服务端滑动窗口计数：使用 Redis 的ZSET实现滑动窗口。以comment:rate:{userId}:{postId}为 key，将每次提交的毫秒时间戳作为 score 存入。查询时用ZCOUNT key (now-60000) +inf统计过去 1 分钟内该用户对该帖子的提交次数。限制为：1 分钟内最多 5 条，1 小时内最多 30 条。关键代码：

   public boolean isRateLimited(Long userId, Long postId) { String key = "comment:rate:" + userId + ":" + postId; long now = System.currentTimeMillis(); long count = redisTemplate.opsForZSet() .count(key, now - 60_000, Double.MAX_VALUE); if (count >= 5) return true; redisTemplate.opsForZSet().add(key, now, now); redisTemplate.expire(key, Duration.ofHours(1)); return false; }

3. 数据库唯一索引兜底：在comment表上建立联合唯一索引UNIQUE KEY uk_user_post_content (user_id, post_id, md5(content))。即使前两层被绕过，重复内容也会因唯一约束失败而被拦截。注意：md5(content)是为避免长文本索引过长，实际存储时额外增加content_md5字段。

实操心得：滑动窗口计数容易忽略“过期清理”。我们最初没设expire，导致 Redis 内存每天增长 2GB。后来改为：每次插入前先ZREMRANGEBYSCORE key 0 (now-3600000)清理 1 小时前的数据，再执行计数，内存占用回归正常。

3.3 敏感词过滤的两种模式：实时过滤 vs 异步审核

内容安全是红线。我们调研了主流方案：DFA 算法（快但内存大）、AC 自动机（平衡）、ES 分词插件（依赖重）。最终选择AC 自动机 + 异步审核双模式。

• 实时过滤（前台）：用户输入评论后，前端 JS 调用/sensitive/check接口，传入文本。后端用预加载的 AC 自动机（词库约 12 万条）进行毫秒级匹配，返回{"hasSensitive": true, "matchedWords": ["XX"]}。若存在敏感词，前端直接拦截并提示“包含不适宜内容”，不发起提交请求。这一步拦截了 92% 的违规输入，极大减轻后端压力。

• 异步审核（后台）：即使前端通过，评论仍会进入“待审核”状态（status = PENDING_REVIEW）。我们用 Kafka 发送CommentAuditEvent事件，消费端启动线程池，对每条评论执行三重检查：

  1. AC 自动机二次扫描（防止前端绕过）；
  2. 调用第三方内容安全 API（如某云盾）进行图片 OCR 和语义分析；
  3. 规则引擎匹配（如“连续 5 个感叹号”、“同一IP 10分钟内发10条相似内容”）。

只有三重检查均通过，才将状态改为PUBLISHED并推送消息。整个流程平均耗时 800ms，用户无感知。

注意：AC 自动机词库必须热更新。我们用 ZooKeeper 监听/sensitive/words节点，一旦词库文件变更，自动重新构建 AC 树。实测从更新到生效，延迟小于 200ms。

4. 实操过程与核心环节实现

4.1 数据库表结构设计：从范式到反范式的关键取舍

我们严格遵循第三范式设计初始表结构：

-- 帖子主表 CREATE TABLE `post` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `author_id` BIGINT NOT NULL, `title` VARCHAR(200) NOT NULL, `content` TEXT, `status` TINYINT DEFAULT 1, -- 1-草稿,2-已发布,3-已删除 `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_author_status (author_id, status), INDEX idx_status_ctime (status, create_time) ); -- 评论表 CREATE TABLE `comment` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `post_id` BIGINT NOT NULL, `author_id` BIGINT NOT NULL, `content` TEXT NOT NULL, `status` TINYINT DEFAULT 1, -- 1-待审,2-已发,3-已删,4-屏蔽 `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_post_status_ctime (post_id, status, create_time), INDEX idx_author_status_ctime (author_id, status, create_time) );

但上线两周后，DBA 提出警告：post表的content字段平均长度 12KB，频繁查询导致 InnoDB 缓冲池压力巨大，SELECT * FROM post WHERE id = ?的 I/O 等待时间飙升。我们意识到：详情页并不总是需要完整正文——列表页只需标题和摘要，搜索页需全文索引，详情页才需完整内容。

于是引入反范式设计：新增post_summary表，只存高频访问字段：

CREATE TABLE `post_summary` ( `post_id` BIGINT PRIMARY KEY, `title` VARCHAR(200) NOT NULL, `summary` VARCHAR(500), -- 自动截取前 500 字 `author_nickname` VARCHAR(50), `author_avatar` VARCHAR(200), `comment_count` INT DEFAULT 0, -- 冗余统计，避免实时 COUNT `like_count` INT DEFAULT 0, `view_count` INT DEFAULT 0, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_update_time (update_time) );

post_summary通过监听PostPublishedEvent事件，由异步任务更新。详情页查询时，先查post_summary获取基础信息，再按需查post.content。实测后，post表的缓冲池命中率从 63% 提升至 91%，详情页平均响应时间下降 35%。

4.2 Spring Boot 配置优化：让 MyBatis 和 Redis 各司其职

默认配置在高并发下很快成为瓶颈。我们针对三个组件做了深度调优：

MyBatis 连接池（HikariCP）：

spring: datasource: hikari: # 连接池大小：根据 DBA 建议，最大连接数 = CPU核数 * 2 + 磁盘数 maximum-pool-size: 20 # 最小空闲连接，避免频繁创建销毁 minimum-idle: 5 # 连接超时：数据库响应慢时快速失败，不阻塞线程 connection-timeout: 3000 # 空闲连接存活时间，避免被数据库主动断开 idle-timeout: 600000 # 连接最大生命周期，强制轮换，防止长连接内存泄漏 max-lifetime: 1800000

Redis 客户端（Lettuce）：

spring: redis: # 使用连接池，避免每次请求新建连接 lettuce: pool: max-active: 20 max-idle: 10 min-idle: 0 # 关键：禁用自动序列化，手动控制序列化方式 # 默认的 JdkSerializationRedisSerializer 性能差且不兼容跨语言

我们自定义RedisTemplate，使用GenericJackson2JsonRedisSerializer：

@Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); template.setHashKeySerializer(new StringRedisSerializer()); template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer()); return template; }

实测序列化耗时从 12ms（JDK）降至 0.8ms（Jackson），且 JSON 格式便于运维直接查看缓存内容。

MyBatis 二级缓存： 我们禁用了全局二级缓存（<setting name="cacheEnabled" value="true"/>），因为其基于 namespace 的缓存粒度太粗，容易导致脏读。改为手动控制缓存：

• 帖子详情：@Cacheable(value = "postDetail", key = "#id")
• 评论列表：@Cacheable(value = "commentList", key = "#postId + '_' + #cursorId + '_' + #cursorTime")
• 缓存失效：@CacheEvict(value = {"postDetail", "commentList"}, allEntries = true)仅在管理员操作时触发，避免业务逻辑误清。

4.3 评论嵌套回复的实现：用“路径枚举”替代“邻接表”

需求升级：支持“评论 A 下回复评论 B，评论 B 下再回复评论 C”。常见方案是邻接表（parent_id字段），但查询某条评论的所有子孙时，需要递归查询，MySQL 不支持 CTE 递归（8.0 才支持），性能极差。

我们采用路径枚举（Path Enumeration）：在comment表中增加path字段（VARCHAR(500)），存储祖先 ID 的路径，如1/5/12/表示该评论是 ID=1 的帖子下，ID=5 的评论的子评论，ID=12 的评论的子评论。

插入新回复时：

public Comment createReply(Long parentId, Comment reply) { Comment parent = commentMapper.selectById(parentId); String path = parent.getPath() + parentId + "/"; reply.setPath(path); commentMapper.insert(reply); return reply; }

查询某条评论的所有回复（含嵌套）：

SELECT * FROM comment WHERE path LIKE '1/5/%' ORDER BY path;

这个查询能完美利用INDEX(path)，且结果天然按树形结构排序。我们测试了 10 万条评论的嵌套查询，耗时稳定在 15ms 内。

实操心得：路径长度有限制（VARCHAR(500) 最多存约 80 层嵌套），但实际业务中，超过 5 层的嵌套几乎不存在。为防万一，我们在插入前校验path.length() < 450，超长则拒绝并提示“回复层级过深”。

5. 常见问题与排查技巧实录

5.1 问题速查表：从现象到根因的 7 类典型故障

5.2 一次真实线上事故复盘：缓存击穿引发的雪崩

现象：凌晨 2 点，监控报警：/posts/{id}接口错误率突增至 40%，数据库 CPU 持续 95%，大量请求超时。

排查过程：

1. 查看慢 SQL 日志，发现SELECT * FROM post WHERE id = ?出现大量执行时间 > 5s 的记录；
2. 登录 MySQL，执行SHOW PROCESSLIST，发现 32 个连接卡在Sending data状态，对应同一条post_id=88888；
3. 检查 Redis，GET postDetail:88888返回 nil —— 缓存已失效；
4. 追查日志，发现 1:58 分有运营同学手动将帖子 88888 的status从 2 改为 1（下架），触发了@CacheEvict清除缓存；
5. 此时恰逢某明星八卦帖爆火，大量用户同时刷新详情页，所有请求穿透缓存，直击数据库。

根本原因：缓存击穿（Cache Breakdown）—— 热点 Key 失效瞬间，海量并发请求同时打到 DB。

解决方案：

• 互斥锁（Mutex Lock）：在缓存失效时，只允许一个线程去查 DB，其他线程等待。我们用 Redis 的SETNX实现：

  public PostDetailDto getPostDetail(Long id) { String cacheKey = "postDetail:" + id; PostDetailDto dto = redisTemplate.opsForValue().get(cacheKey); if (dto != null) return dto; String lockKey = "lock:post:" + id; Boolean isLocked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(3)); if (Boolean.TRUE.equals(isLocked)) { try { dto = loadFromDb(id); // 查库 redisTemplate.opsForValue().set(cacheKey, dto, Duration.ofHours(2)); } finally { redisTemplate.delete(lockKey); } } else { // 等待 50ms 后重试 Thread.sleep(50); return getPostDetail(id); } return dto; }

• 逻辑过期（Logical Expiration）：缓存值中额外存一个expireTime字段，即使 Redis 中 key 过期，应用层仍判断逻辑时间。我们后续升级为此方案，彻底规避锁竞争。

5.3 性能压测实录：从 500 QPS 到 5000 QPS 的演进路径

我们用 JMeter 对/posts/{id}接口进行阶梯压测（4C8G 服务器，MySQL 8.0，Redis 6.2）：

关键发现：QPS 瓶颈不在代码，而在 I/O 和网络。当我们将post.content字段从详情页查询中移除（前端按需加载），QPS 直接提升 40%；当把 Redis 从本机迁移到同 VPC 的高性能集群，平均响应时间再降 25ms。这印证了一个朴素真理：在分布式系统中，减少一次网络跳转，往往比优化十行 Java 代码更有效。

6. 扩展性设计与未来演进方向

6.1 如何平滑支持“评论点赞”功能：事件驱动架构的实践

当产品提出“给评论点赞”需求时，我们没有在comment表加like_count字段，而是采用事件驱动架构（EDA）：

1. 用户点击点赞，Controller 发布CommentLikeEvent事件；
2. CommentLikeEventHandler消费事件，执行：
   • 检查用户是否已点过赞（查user_like_comment表）；
   • 更新comment表的like_count（乐观锁：UPDATE comment SET like_count = like_count + 1 WHERE id = ? AND version = ?）；
   • 写入user_like_comment(user_id, comment_id, create_time)；
   • 发布CommentLikeCountUpdatedEvent通知其他服务（如消息推送）；
3. 前端通过 WebSocket 或轮询订阅CommentLikeCountUpdatedEvent，实时更新点赞数。

这个设计的好处是：点赞逻辑与帖子、评论核心业务完全解耦。未来要增加“点赞排行榜”，只需新增一个消费者监听CommentLikeEvent，统计后写入 ES；要支持“取消点赞”，只需在事件中增加isCancel标志位，无需修改现有代码。

6.2 从单体到微服务：帖子与评论服务的拆分边界

当前项目是单体 Spring Boot 应用。当用户量突破 500 万时，我们启动了服务拆分。拆分原则是：按业务能力（Business Capability）而非技术分层。

• 帖子服务（Post Service）：只负责帖子的创建、修改、状态管理、基础统计（阅读数、评论数）。对外提供POST /posts、GET /posts/{id}、PATCH /posts/{id}/status。
• 评论服务（Comment Service）：只负责评论的增删改查、审核、敏感词过滤、嵌套回复。对外提供POST /comments、GET /comments?postId={id}、POST /comments/{id}/reply。
• 聚合服务（Aggregation Service）：不存数据，只调用前两个服务，组装PostWithCommentsDTO。前端只对接聚合服务。

拆分后，我们解决了三个痛点：

• 独立扩缩容：评论服务在活动期间扩容至 12 实例，帖子服务保持 4 实例；
• 技术栈自由：评论服务因高写入压力，后续迁移到 TiDB；帖子服务保持 MySQL；
• 故障隔离：评论服务宕机，帖子详情页仍可正常访问（评论区域降级为“服务暂不可用”）。

我个人在实际操作中的体会是：服务拆分不是越早越好，而是在单体出现明显瓶颈（如部署时间 > 30 分钟、一个 Bug 影响多个业务线）时才启动。过早拆分会带来分布式事务、网络延迟、运维复杂度等新问题。我们坚持“单体优先，拆分有据”，让架构演进真正服务于业务增长。

6.3 一个被验证有效的经验：用“影子表”做灰度发布

新功能上线前，我们总担心 SQL 变更影响线上数据。例如，要给comment表加audit_reason字段（审核不通过的原因），直接ALTER TABLE风险极高。

我们采用影子表（Shadow Table）灰度方案：

1. 创建comment_shadow表，结构与comment完全一致，但增加audit_reason字段；
2. 写入双写：所有新增评论，同时写入comment和comment_shadow（用 RocketMQ 保证最终一致性）；
3. 读取灰度：按 1% 流量比例，将GET /comments请求路由到comment_shadow表；
4. 验证无误后，将comment_shadow表重命名为comment，原表备份；
5. 清理双写逻辑。

这个方案让我们在 3 次