每次做大促复盘，评论区接口总是最让我心惊胆战的一环。别看电影票务这类读多写少的业务好优化，评论系统真正麻烦的地方在于——它既是高并发读，又是高并发写，流量还高度集中在少数爆款内容上。这篇文章把我们这套高性能评论系统架构设计的关键决策拆开聊：从整体分层、存储选型、异步链路，到网络层优化和故障预案，都是自己踩过坑之后沉淀下来的东西，希望能帮你少走一些弯路。
如果你正在做一个日活百万到千万级别的内容型产品，评论量级在日增几十万到几百万之间，或者你手头的评论服务已经出现了"一有爆款就报警"的情况，那这篇文章的参考价值会非常直接。
1. 评论系统的场景特殊性：为什么它比普通功能页更难伺候
1.1 读写并存且流量高度集中
大多数业务系统的瓶颈是单一的：商品页读多写少，秒杀系统写多读少，签到这种功能几乎没什么并发压力。评论系统不一样，它天生是读写并存的——用户在刷评论的同时也在不停发评论，而且这两条链路都会在爆款内容上被同时放大。
先看读。评论区流量结构基本是"一九定律"：不到10%的爆款内容吃掉了90%以上的评论流量。一条内容上了推荐位或者被大V转发，它的评论区可能在几十秒内从一个相对平稳的几千QPS冲到几万QPS。注意，这还只是"单个内容ID"维度的热，跟全站流量峰值不是一回事，但恰恰是所有缓存节点都解决不了的难题——热点是一个具体Key，而不是一群Key。
再看写。爆款视频底下经常出现"一分钟几百条评论"的现象。写操作和读操作叠加在同一批数据上，DB的连接池、MQ的生产速率、审核服务的处理能力全部要同时扛住。如果你只在读路径上做了缓存优化、写路径完全裸奔，那大促期间第一个挂掉的往往不是读接口，而是写库线程池被打满，进而拖垮整个服务实例。
1.2 社交语义让缓存设计变复杂
评论不像商品SKU，不能简单按ID缓存一个对象就完事。它有一套复杂的社交语义：
- 列表要分页，还要倒序或按热度排序；
- 内容有审核状态，用户只能看到"已通过"的评论，但作者本人要能看到自己的评论（哪怕还没审核完）；
- 有楼中楼/回复关系，一条热评底下可能还挂着一堆子回复；
- 有计数体系，评论数、点赞数都在实时变化；
- 删除和屏蔽要在很短时间内对所有人生效。
这种复杂度意味着：你不能用一个"评论列表"的粗粒度缓存去承接所有需求，更不能把一个帖子的全量评论文档直接丢给搜索引擎然后就不管了。架构设计必须把"读列表""读详情""看自己的评论""计数""子回复"这些场景拆开考虑，每一类用不同的数据结构和存储策略去接。
1.3 先定性能目标，再谈架构
我见过不少团队一上来就追求百万QPS、一开口就要上DPDK，但连自己系统的P99延迟是多少都不知道。架构设计的第一步是把性能目标量化。
以我们自己的系统为例，目标定的是：
- 读接口（拉取评论列表）：P99 < 150ms，缓存命中时P99 < 20ms；
- 写接口（发布评论）：P99 < 300ms，不含审核时间，用户发出后立刻在本人端可见；
- 评论数计数：最终一致时间 < 5秒；
- 爆款内容（单条内容QPS瞬时过万）不触发限流、不降级、不拖垮其他业务。
这些数字不是拍脑袋定的，它们来自用户行为分析：用户在评论区停留时，如果超过200ms还没有内容展示，跳出率会明显上升；发评论后如果超过1秒自己还看不到，投诉率会暴涨。先和产品对齐这些数字，后面的选型和优化才有依据。
2. 整体分层与请求全链路：从网关到存储的一次评论读取
2.1 全局拓扑怎么搭
整个系统从上到下大致是五层：
负载均衡层（F5/LVS/HAProxy） ↓ Nginx集群（TLS终结、静态拦截、基础限流） ↓ 接入网关（鉴权、参数校验、路由、限流） ↓ 评论核心服务（无状态，按内容ID哈希分片路由） ↓ 存储层（MySQL分库分表、Redis集群、MQ、ES）评论核心服务是无状态的，可以随意水平扩缩容。但无状态不代表没有数据亲和性——我们会把post_id（内容ID）做哈希路由，让同一个帖子下的所有评论请求始终落到同一组服务实例上。这样做的直接好处是本地缓存命中率大幅提升：
- 如果随机轮询分发，同一个帖子的一批请求被打散到几十个实例上，每个实例的本地缓存都只能命中一小部分；
- 如果按帖子ID路由，请求会集中到少数几个实例上，这几个实例能维持很高的本地缓存命中率。
路由可以用一致性哈希，也可以用简单的post_id % shard_count。一致性哈希的好处是扩缩容时迁移小，但实现复杂一点；业务初期用取模就够了，配合一个路由配置表也能解决单点热点问题。
数据在存储层也是按post_id分片的，原则和上面一致：一个帖子的评论必须落在同一个数据库分片里。这样查询评论列表永远只需要访问一个分片，不存在跨库聚合问题。
2.2 读路径：本地缓存、Redis、MySQL三层兜底
一次评论列表读取，实际的查询路径是这样的：
我先查本地进程内缓存（比如Caffeine或者go-cache），命中就直接返回；没命中查Redis，Redis里存的是热门帖子的前几页评论ID列表或者序列化后的首屏数据；还没有就落到MySQL，查询出结果后回填Redis和本地缓存。
三个层级的延迟差异非常明显：
| 层级 | 延迟量级 | 能扛的QPS（单机） |
|---|---|---|
| 进程内本地缓存 | 0.05~0.2ms | 几万到几十万 |
| Redis | 0.5~2ms | 单实例约6~10万读 |
| MySQL | 2~10ms | 单实例稳定也就几千 |
评论列表的缓存key设计我建议用comment:list:{post_id}:{cursor_page}的形式，value直接存序列化后的评论列表。但在实际业务里，更推荐只缓存"前3页"：
- 大多数用户翻评论区只看前几页，超过3页的深翻页流量断崖式下跌；
- 缓存前3页的成本极低，每篇帖子最多缓存3个key；
- 深翻页直查数据库，用游标分页，避免深offset的性能灾难。
分页这里有个细节：用offset做深分页在大表上是灾难，因为MySQL要扫描并丢弃前面的行。评论列表应该用游标分页（cursor-based pagination），核心SQL长这样：
SELECT id, content, user_id, create_time FROM comments WHERE post_id = #{postId} AND id < #{cursorId} -- 游标，上一页最后一条评论的ID AND status = 1 ORDER BY id DESC LIMIT #{pageSize}评论ID用发号器生成有序ID，时间顺序和ID顺序一致，游标分页天然按时间倒序。这个方案还有一个好处：翻页过程中如果有新评论进来，数据不会像offset分页那样出现"整体位移导致重复或跳行"。
2.3 写路径：主链路短，其余全部异步
发评论的路径和读完全相反，核心原则是"主链路短，副链路异步"。
用户在客户端点"发布"，请求经过接入网关、评论核心服务后，直接干几件事：鉴权（用户是否登录、是否被禁言）、参数校验（内容长度、敏感词预检）、写入MySQL主库，然后立刻返回成功。只要评论落库，作者在自己设备上刷新就能立刻看到，这个体验是最重要的。
至于后面的事——更新Redis里的最新评论列表、让评论进入审核队列、同步到ES做全文搜索、给评论者加积分、通知被回复的人——全部丢给消息队列异步处理。
这里有一个非常关键的架构选择：审核是"先审后发"还是"先发后审"？大多数内容平台采用"先发后审"——评论先展示给所有人，但服务端在写库时给这条记录打上pending状态，异步审核通过后把状态改成published；如果审核不通过，则通过消息队列再发一个"删除"指令，把缓存里的这条评论清掉。这样做是为了用户体验，但给架构带来的直接后果是：所有读评论的地方都必须过滤状态，缓存更新也必须考虑"审核不通过后怎么及时从缓存里移除"。
我们在实践中的做法是：Redis缓存里存的是评论ID列表，评论基本信息和内容放在另一个缓存key里。列表缓存按published状态过滤，内容缓存不支持状态变更后的强制失效——而是通过一个"状态变更事件"由MQ消费者主动删除内容缓存并重建列表。去掉一个中间状态变量，整个缓存一致性逻辑会简单很多。
3. 存储方案的底层选择：MySQL、Redis、搜索引擎各管哪一层
3.1 关系库：水平拆分与主键生成
评论数据是典型的"海量追加型"数据，单库单表绝对撑不住。我们选择的方案是MySQL水平分库分表，分片键就是post_id。
主表结构大致长这样：
CREATE TABLE comments ( id BIGINT NOT NULL, post_id BIGINT NOT NULL, user_id BIGINT NOT NULL, content VARCHAR(1000) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待审 1通过 2已删除 like_count INT NOT NULL DEFAULT 0, reply_count INT NOT NULL DEFAULT 0, reply_to BIGINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, PRIMARY KEY (id), KEY idx_post_status_time (post_id, status, id) ) ENGINE = InnoDB;核心索引是(post_id, status, id)，这正好覆盖了"查某个帖子的可见评论并倒序分页"的场景。主键是全局发号器生成的有序ID，生成方式可以用雪花算法变体或者美团Leaf。关键点是主键有序递增，这样评论列表天然按时间倒序，游标分页性能最好。
为什么不直接用MySQL自增ID？因为做了分库分表之后，每个库的自增ID会重复；即使通过设置不同步长解决，万一后面要扩容（比如从8个分片扩到16个），自增ID的调整极其痛苦。发号器把ID生成从存储层独立出来，扩容时完全不受影响。
分片数建议一开始就留足余量。比如你评估未来三年评论量在10亿级别，那就直接分256个分片。分片算法用post_id % 256，后续扩容只能翻倍扩（256→512），或者引入一致性哈希，但这属于大改造，能不在初期就给架构否决项就尽量避免。
有一个必须预先考虑的场景：按用户维度查"我发过的所有评论"。如果分片键是post_id，查用户评论就要扫256个分片，这是不可接受的。我们为此建了一张user_comments宽表，只存user_id, id, post_id, create_time, status几个字段，同样做分库分表但分片键是user_id。这张表只服务"个人主页-评论Tab"的场景。如果产品上还有"评论关键词搜索"之类的需求，那就交给ES，而不是让MySQL硬扛。
3.2 缓存层：列表缓存和计数缓存要分开设计
Redis在评论系统里承担两类完全不同的角色，千万别混在一起设计。
第一类是列表缓存。我们只缓存热门帖子的前3页，用ZSET存评论ID列表，score用评论ID或者热度分数（比如点赞数折算后的值）。用ZSET而不是LIST的好处是可以支持"按热度排序"和"按时间排序"两套排序视图，同时能精确删除某条被屏蔽的评论ID。
第二类是计数缓存。评论数、点赞数这种高频变更的数据，如果每次都写MySQL，性能会很差。我们用独立的Redis计数器comment:cnt:{post_id}，发布评论时INCR，删除时DECR，然后通过一个定时任务（比如每5分钟）批量把这个值刷回MySQL。
计数刷回有个坑：如果直接UPDATE 评论表 SET count = redis值 WHERE post_id = ?，在高并发下可能出现数值回跳，因为Redis的INCR和DB的UPDATE时间点有交错。稳妥的做法是让定时任务记录"当前Redis值"和"上次同步值"，只把差额同步到DB；或者干脆把计数放Redis里作为唯一数据源，MySQL里的计数只做冷备份，大促时允许DB里的计数稍微滞后。
3.3 冷数据归档：把两个月前的评论请下热库
评论和订单一样，有强烈的冷热之分。一篇帖子发布后的48小时内会产生绝大部分评论访问；一个月后，除非再次被顶上来，否则基本只有零星翻看。如果把所有历史评论都放在MySQL主库，表会膨胀到几百亿行，索引层数加深、缓冲池被冷数据占用，查询性能急剧下滑。
我们的做法是"时间分区 + 定期归档"：
- 按月建分区（
PARTITION BY RANGE (TO_DAYS(create_time))），保留最近3个月的热分区； - 3个月前到2年前的数据迁移到归档库（可以是一组低配MySQL，也可以直接扔到ODPS/对象存储）；
- 超过2年的数据按
post_id+create_time打包成序列化文件存OSS，只保留"可恢复"能力，不提供实时查询。
这里要注意产品交互的配合：用户翻评论翻到很深的页数时，客户端会触发"加载更早的评论"，这时候读归档库在线查询就够了。如果用户非要翻到2年前的历史评论，产品上一般是做一个"已进入历史归档，约N秒后加载"的中间态，由服务端异步从OSS恢复那一页数据到临时表再返回。这个降级策略需要提前和产品达成一致，不能等被用户骂了再讨论。
3.4 最终一致：用Binlog订阅而不是业务双写
前面提过，评论写入主库后，需要同步更新Redis缓存、ES索引、计数器。很多团队会直接在业务代码里"双写"——写完DB再写Redis，再发MQ。这个方案最大的问题是：任何一步失败都可能造成Redis和DB不一致。删消息队列重放的时候又可能重复写。业务代码越是到处发MQ，出问题的概率就越高。
更可靠的方案是引入Binlog订阅组件（Canal或者Debezium）。评论数据落库后，MySQL的Binlog会记录这次变更，订阅组件拿到变更事件，统一由一套消费者逻辑去更新Redis缓存的评论列表、同步ES索引、发送通知。这样做的好处：
- 业务代码只关注写主库，其他事情一概不管；
- 同步逻辑收敛到一个消费端，出了故障只需要重放Binlog，不会出现业务代码里"漏发了"的情况；
- 天然具备"数据库为准"的一致性语义，缓存和索引永远有机会从Binlog恢复。
Binlog订阅对运维有要求，Canal要单独部署且依赖MQ，初期如果团队没有这个基础设施，可以先用"本地消息表+定时任务回扫"过渡。但过渡方案一定要控制好扫描对DB的压力，不然每天半夜跑批扫全表，评论库会被扫出性能事故。
4. 异步化改造：消息队列在这里的价值不只是解耦
4.1 削峰：把突刺流量变成平坦流量
爆款内容带来的流量是典型的突刺曲线，几秒钟内评论发布量可能是平时的50倍。如果让所有流量直接砸向数据库，连接池会瞬间被打满，CPU和磁盘IO也会被拖垮，解决方式根本不是加机器能搞定的——数据库的写入能力受限于单分片的主从复制延迟和磁盘刷盘速度。
消息队列在这里扮演的是"缓冲大坝"角色。评论写入MySQL后，后续一切操作（审核、索引、同步、通知）都放到MQ里，消费者按恒定的速率去拉取处理。这么说吧：上游可以短暂地在一秒内塞进来几千条消息，但消费端每秒只处理几百条，剩下的自然积压。只要消费者处理速度能跟上"平均流入速率"，积压最终会清空。大促期间的预期就是允许队列积压一段时间，但绝对不能超过消费者幂等处理的容忍极限。
选型上，如果团队已经用了Kafka，直接用Kafka就够了；如果你更看重事务消息和延迟消息，RocketMQ会更顺手。Kafka的吞吐量更高，RocketMQ在消息可靠性上更灵活。评论系统的消息量其实到不了需要极致吞吐的程度，我更看重的是"消息不丢"和"消费端幂等"，这两点哪个MQ都能做，关键是你的配置和代码要正确。
4.2 最终一致：从主库到索引的可靠路径
"评论数+1""ES索引更新""通知被回复人"这些动作，本质上都在追求最终一致。要保证可靠性，核心在于两点：消息不能丢，消费不能重复处理产生脏数据。
消息不能丢，靠的是生产端的确认机制和重试。在Kafka里就是acks=all，在RocketMQ里就是事务消息。这里有一个容易忽略的坑：如果业务代码是先写库，再发MQ，那么写库成功但发MQ失败，这条评论就永远不会被同步到ES里。用RocketMQ的事务消息，或者用前面说的Canal Binlog订阅，可以完美规避这个问题——因为消息的"产生"和"数据落库"是同一件事。
消费端不能重复处理，靠的是幂等。最实用的一套路是：在消费端用消息里的comment_id建一张去重表，或者直接在目标数据上做"只在不存在时插入"的操作。比如更新ES索引，ID相同就直接覆盖，天然幂等；但"通知用户"这种动作必须做去重，不然重复消费会导致用户被轰炸。
4.3 顺序与幂等：评论场景的取舍
评论系统有一个天然幸运的地方：它不需要严格的全局顺序。同一个帖子下的评论列表排序靠的是score（评论ID或者热度分数），这个消息是乱序到达还是有序到达都不影响最终结果，因为列表的顺序是查询时计算出来的。这大大简化了MQ分区的设计，不需要像订单系统那样按订单ID哈希保证同单消息顺序。
唯一需要注意顺序的是"状态变更事件"。比如一条评论先创建（pending），然后审核通过（published），如果这两个事件在消费端被乱序处理，先处理了published再处理pending，缓存里就看不到这条评论了。解决方案很简单：消息里带上comment_id，消费者按comment_id哈希到固定的分区，保证同一条评论的消息一定被同一个消费者线程顺序消费。Kafka里就是key = comment_id作为分区键，RocketMQ里是消息的sharding key。
另一个要注意的幂等细节是"删除评论"。如果用户删评论，写库标记status=2，消息队列里发一个删除事件。但删除事件如果重复消费，第一次删除缓存成功，第二次可能又触发一次全量列表重建，导致短暂把已删除评论带回列表。我们处理的方式是在重建列表时带上状态过滤，只要DB里状态是已删除，重建一百次也不会把这条评论带进来。
5. 高并发链路上的性能极限：线程模型与网络层优化
5.1 高并发C++和高性能C++：语言层面的两件事不是一回事
这个话题我们在团队内部聊过很多次。很多人把"高并发C++"和"高性能C++"混为一谈，其实它们关注的东西完全不同。
- 高并发C++关心的是：系统同时承载大量连接和大量请求时，调度和资源管理还能不能稳定。典型的关注点是IO多路复用（epoll）、线程模型（Reactor还是Proactor）、无锁队列、连接生命周期管理、
SO_REUSEPORT多核负载均衡。 - 高性能C++关心的是：单个请求的处理路径能不能做到极致快。关注点是分支预测、CPU缓存命中率、减少动态内存分配、零拷贝、将热路径变量放到同一个缓存行。
两者都会踩坑的类型完全不同。高并发系统死掉通常是因为连接数上来了，线程调度开销爆炸，或者某个锁在临界区里被死死占着；高性能系统出问题往往是慢查询被放大到整个进程卡顿。
评论系统里，C++最常见的位置是接入网关和短链路核心组件。网关用C++写可以同时拿到高并发和高性能，单机扛几万QPS很简单。但这里必须说一句大实话：如果你还在用Java/Kotlin/Go，先把缓存、异步、分片这些架构层手段用到位，系统的QPS已经能到很高水平了。业务代码层面的优化ROI远高于纠结用C++重新实现网关。
5.2 连接与线程的工程陷阱
这些坑是无论用什么语言都会踩的。
第一坑是连接数内存估算。每个TCP连接在内核态有发送缓冲和接收缓冲，默认值可能是几十KB到几百KB不等。10万个连接光是内核缓冲就能吃掉几个GB内存。所以评论服务一定要做连接池复用，不要每次请求都新建连接；客户端要开HTTP Keep-Alive，服务端要设置合理的空闲超时。
第二坑是连接池大小不是越大越好。MySQL连接池如果开了200个连接，而机器只有8核CPU，200个连接在争抢线程和锁时性能反而不如50个连接。一个比较通用的经验值是：连接池大小 = CPU核数 x 2 + 后台IO任务数。这个公式用在评论这种短小快速的链路场景下，基本能让CPU跑满而不被锁拖死。
第三坑是线程模型。如果你的网络层用同步阻塞模型，每个请求占一个线程，线程上下文切换会在高并发下暴涨。换成IO多路复用（epoll）+ 少量工作线程的模型，同样的机器能多扛10倍以上的并发连接。像Netty、Go的goroutine都是已经帮你把这一层做好的，真正需要手写epoll的场景主要是C++网关这种极致要求。
5.3 DPDK、RDMA、XDP这些名字离业务有多远
热搜词里频繁出现DPDK、RDMA、XDP，说明很多人在关注Linux高性能网络。这几个东西确实都是真实存在的网络层优化手段，但要用对地方。
- XDP挂在网卡驱动层，可以在内核协议栈处理之前拿到包做过滤，非常适合DDoS防护、流量清洗、粗粒度分流。一个评论网关如果经常被恶意刷流量，把"同IP高频访问"的拦截逻辑下沉到XDP，可以大大降低CPU压力。
- DPDK是用户态网卡驱动加轮询模型，完全绕过内核协议栈，处理包的速度能做到几百万PPS级别。它适合构建高性能负载均衡器或网关转发层——如果你需要一台机器扛几十万QPS的转发，DPDK是选项之一。
- RDMA是绕过内核直接访问远端机器内存，延迟能压到微秒级。它主要用在存储集群和数据库主从同步这种场景，评论系统的业务数据链路很少直接用。
说句实在话：评论系统99%的团队完全不需要碰DPDK和RDMA。先把epoll模型用好，把应用层连接池、本地缓存、异步链路做好，P99延迟已经很好看。只有当你遇到"单机网关转发QPS到了物理极限"和"DDoS攻击打满网卡"这类问题时，再考虑把网络层优化提上日程。架构层优化永远优先于底层性能优化，这是排过太多坑之后的教训。
6. 热点评论与故障预案：从缓存穿透到流量突刺
6.1 热点内容的读放大怎么扛
高性能评论系统最难的问题不是平均流量，而是热点流量。一条热帖的评论区可能被上万个用户同时高频刷新，同一个Redis key每秒被读几万次。Redis单实例虽然能扛到这个量级，但你的网关节点和Redis之间多了大量网络RTT，性能并不好看。
解决热点读放大的最优解是进程内本地缓存。每个评论服务节点把最近访问量最大的几百个帖子的前3页评论列表直接缓存在本地内存里，并设置强制的短过期时间（比如30秒）。由于我们前面做过post_id哈希路由，同一个帖子的请求会集中到同一小批节点上，这批节点本地缓存命中率能到80%以上。
本地缓存有一个需要警惕的副作用：数据一致性窗口变长。一个帖子下新发了一条审核通过的评论，Redis里可能已经更新了，但本地缓存30秒内还是旧数据。对策是订阅MQ中的"评论变更事件"，在本地缓存也删除对应key，让下次查询重新加载；如果做不到，那就接受30秒以内的短时不一致，在评论区提示"最新评论"靠客户端下拉刷新来触发。
6.2 缓存三个经典故障的兜底
缓存穿透、缓存击穿、缓存雪崩这三个词大家都听过，但在评论系统里每个都有具体的变形。
缓存穿透：恶意用户构造大量不存在的post_id来刷评论接口，缓存里查不到，每次都打到DB。我们的解法是双层布隆过滤器（第一层全局限流器，第二层按业务维度）加空值缓存。一个不存在的帖子ID，如果DB查不到，就在Redis里缓存一个空列表并设置短过期时间（30~60秒），让重复刷的请求直接打到空缓存上。
缓存击穿：某个爆款帖子的缓存key在同一时刻失效，一瞬间所有请求全打到MySQL。解法是"互斥锁重建缓存"——当发现缓存未命中时，不直接查DB，而是先尝试加锁（比如Redis SETNX），只有拿到锁的请求才去查DB并重建缓存，其他请求短暂等待后读缓存。为了不阻塞太久，可以在锁等待时设置一个几十毫秒的重试循环。
缓存雪崩：大量key在同一时间过期，DB瞬时压力暴涨。解法是给缓存过期时间加随机扰动，比如30秒 + random(0, 30)，让过期时间打散分布。对爆款帖子的评论缓存，甚至可以设置"热点不过期"——缓存里不设过期时间，靠MQ事件去主动更新和删除。
6.3 限流、熔断与应用隔离
评论服务在大的技术体系里往往不是最核心的业务（核心是支付、登录、资讯流），但它很容易成为被流量攻击的首选对象。所以评论系统必须有完善的限流、熔断和隔离机制。
限流分两个维度：一个是全局限流，按API维度设置QPS上限，超出直接返回"系统繁忙"；另一个是业务维度限流，按用户维度限制每分钟发布评论次数，按内容维度限制评论读取频率。写接口的限流尤其重要——免费注册的机器人账号会通过脚本疯狂刷评论，这部分流量不进核心链路就要在这里被拦掉。
熔断是针对下游依赖的。如果Redis或者MySQL出现大量超时，评论服务不能无脑继续重试，否则会让下游雪上加霜。我们用Hystrix或者Sentinel那一套（如果团队是Java的话）：错误率超过阈值就开熔断，直接快速失败返回降级内容（比如返回空列表，或者用户界面展示"评论加载失败，请下拉重试"），等下游恢复后自动半开重试。
应用隔离是最容易忽略但最关键的：评论服务和主站业务接口一定要分开部署，使用独立的数据库线程池、独立的Redis实例、独立的线程池。这是为了避免一个大促把评论服务打爆了之后，因为共享线程池而把主站的接口也拖挂。我们内部称之为"泳道隔离"，评论这套子系统有自己的资源池，不许和任何其他业务共享关键资源。
针对大促，我们还维护了一张"红黑榜"检查清单：大促前确认所有热点帖子已经预加载到本地缓存、确认Redis集群水位正常、确认限流阈值配置已经更新、确认消息队列表积压清空、确认降级开关可一键触发。下次大促如果你还睡不踏实，照着这个清单过一遍，至少能规避80%的常见问题。
我自己在经历了这么多次大促之后最大的体会是：高性能评论系统架构设计里，60%的功夫在架构之前的业务理解和数据模型，30%在缓存和异步的合理运用，只有剩下10%才是语言和底层网络层面的极致优化。先跑通一条读链路和一条写链路，把缓存命中率和P99延迟的监控做起来，再谈复杂方案——因为真正的问题永远是流量上来之后才看得清楚的。
