商品评价接口在大促期间遭遇高并发时，读写分离是最有效的解法，核心思路是让评价的“读”完全脱离主库，全部走缓存，让“写”通过消息队列异步落库，从而保证接口在任何流量冲击下都能稳定响应。
大促高并发下商品评价接口性能瓶颈在哪里
大促之前，评价接口平时看起来人畜无害，日常流量下，单库单表跑得飞快，偶尔几次慢查询也能靠索引糊弄过去，但零点一过，流量瞬间涨上去，评价接口的问题就暴露得一览无余，首当其冲的就是热点商品评价的缓存击穿，某个爆款商品的评价被大量用户同时刷新，缓存一旦过期，流量直接穿透到数据库，瞬间把连接池打满，其次是大促期间用户浏览商品频率极高，评价列表的读请求量级往往是平时的几十倍，而写请求也就是下单后那点评价提交量,两者的比例严重失衡。
行业共识认为，商品评价这个业务场景存在天然的读写不对称性，读多写少，而且评价数据对实时性要求不高，用户看评价并不是为了看到一分钟前的新内容，而是为了参考历史口碑，这种业务特征决定了它非常适合做读写分离架构，但如果只是简单把读请求分发到从库，大促期间依然扛不住，因为从库也有性能上限，数据同步延迟同样会影响用户体验，真正有效的读写分离，必须按评价业务的特性来设计，让读流量走独立的缓存链路,让写流量走异步削峰链路。
商品评价接口读写分离怎么实现
设计读写分离方案时，我们得先把评价接口的所有操作路径理出来，常规评价接口包含评价提交、评价列表查询、评价详情查询、追评、点赞、举报等动作，大促场景下，读操作占比超过九成，而且集中在列表查询上，所以方案的核心就是让列表查询走完全独立的读链路,不占用主库的任何连接资源。
写路径：评价提交走异步削峰
评价提交这个动作在用户侧的感知是“发出去就行”，并不强求立刻出现在列表里，所以写路径可以设置为用户提交评价后，接口立即返回成功，评价内容会先写入消息队列，由消费者任务批量写入MySQL主库，这个方案下，大促期间即便有瞬时提交高峰，主库也不会发生写拥堵，因为写入速度由消费端根据自己的处理能力来决定，相当于给主库装了一个缓冲阀，每条评价写入后触发一次缓存更新，把新评价追加到Redis中的评价ID列表头部,供后续读请求使用。
写路径另一个容易被忽略的点是防刷和幂等，大促期间评价接口容易成为刷单和恶意攻击的目标，需要在提交侧做令牌桶限流，每个用户ID单位时间内的提交次数需要做约束，同时要保证同一笔订单的同一用户不能重复评价，这需要在业务层用订单ID加用户ID做唯一索引,配合Redis的分布式锁做二次拦截。
读路径：Redis缓存加本地缓存二级兜底
读路径的设计需要保证大促期间评价列表的查询响应时间稳定在百毫秒以内，方案采用两级缓存架构，第一级是应用服务本地的Caffeine缓存，第二级是Redis集群缓存，查询请求先打本地缓存，命中失败再查Redis，Redis有数据就直接返回，Redis也没有才回源数据库，为了防缓存穿透，Redis里查不到的数据也要缓存一个空值，并设置短的过期时间，为了防缓存雪崩，每个评价列表的缓存过期时间要加一个随机偏移量,避免同一批商品的评价缓存同时失效。
这里要强调一个实操细节，大促期间几乎没有必要让读请求回源数据库，评价列表的Redis查询性能承受能力远高于数据库，一台8核16G的Redis节点支撑每秒数万次的读取完全没问题，而相同配置的MySQL能承受的并发查询容量远远低于这个数值，所以主库在大促期间主要的职责就是保证写入和同步数据到缓存,读请求一律不回源。
评价数据一致性和缓存更新方案
读写分离落地后，最棘手的问题就是数据一致性，评价数据的实时性要求虽然不高，但也不能出现用户刚提交的评价消失不见，或者评价内容前后不一致的情况，实际方案采用Redis缓存版本号加延迟双删的组合策略。
缓存更新流程
当消费者任务从消息队列里捞到新评价数据后，会把它写入MySQL主库，同时向Redis发送一条更新指令，将评价列表缓存中的新增ID合并进去，这里有一个坑，如果更新Redis失败，会导致缓存里数据缺失，所以需要引入重试机制，Redis更新失败就重新放入消息队列，延迟几秒后再试，同时配合延迟双删策略，更新MySQL之后先删除一次缓存，过几百毫秒再删除一次，确保并发场景下旧缓存被重新写入的概率降到最低，根据具体业务场景，也可以用Canal监听MySQL的binlog，将变更同步到Redis，这种方式更保险，binlog的增量数据不会丢，但会引入额外组件,适合对一致性要求更高的团队。
大促期间的最终兜底逻辑
哪怕有缓存方案，理论上还是存在极端情况导致缓存数据丢失，比如Redis集群大面积故障，这时候需要有兜底逻辑，方案上是用Hystrix或Sentinel做降级，当Redis不可用时，读请求直接返回热门商品评价的预置快照数据，同时记录日志，等Redis恢复后再重新构建缓存，这套兜底逻辑在大促前一定要演练,确保降级开关可以在秒级生效。
| 路径 | 核心组件 | 耗时目标 | 失败兜底 |
|---|---|---|---|
| 写提交 | MQ异步，主库落库 | 秒级返回 | 消息重试，不丢数据 |
| 读列表 | 本地缓存+Redis | 毫秒级返回 | 返回降级快照 |
| 缓存重建 | Canal或定时任务 | 分钟级完成 | 重建期间读主库临时放量 |
评价列表查询的分页与排序如何在高并发下实施
评价列表查询的排序规则直接影响缓存设计方案，大促期间用户最常看的是综合排序和按时间排序，这两种排序如果让数据库在请求时实时计算，压力会异常大，性能也难以保证，实际操作中，可以在缓存中预计算并存储评价ID序列，对每个商品维护一个有序集合（ZSet），score是评价的发布时间戳，成员是评价ID，分页时直接操作ZSet的范围查询，取出评价ID列表，再根据ID批量获取评价详情缓存，组装返回，这样就避免了数据库的排序操作,也避免了分页深翻页造成的性能损耗。
商品评价详情也要做缓存，评价详情包含评价内容、图片、追评信息、商家回复等，这些数据量大，不适合在列表接口里实时组装，方案上在缓存里为每个评价ID存一份JSON序列化数据，列表页只返回概要信息，详情页单独从缓存中取，大促期间用户流动性强，很多用户会来回切换商品对比,这种设计能有效降低无效的重复查询。
评价接口读写分离的监控与应急预案
大促期间区分技术方案好坏的标准就看监控和应急，读写分离架构上线后，必须对主库连接数、Redis命中率、本地缓存命中率、消息队列积压量、评价列表平均响应时间等指标做实时监控，其中消息队列积压量是最需要重点盯的指标，它直接反映消费者处理速度是否跟得上生产速度，一旦积压量持续增长,需要及时扩容消费者实例。
应急预案也要提前准备几个等级，一级预警是Redis命中率低于某个阈值，处理方式是强制把热点评价数据预热到本地缓存，提高本地命中率，二级预警是主库CPU使用率居高不下，处理方式是启用降级开关，关闭评价详情页的非必要字段查询，三级预警是消息队列积压超过设定阈值，处理方式是增加临时消费者实例数量,加快消费速度。
商品评价接口读写分离效果提升的实操验证路径
光有设计思路还不够，项目落地需要跟着一定的节奏走，第一步是统计当前评价接口的真实QPS和响应时间数据，借助压测工具模拟大促流量，确认瓶颈点到底在数据库还是在服务层，第二步是根据评价读写比例来规划Redis集群的节点数量和内存容量，估算时需要用评价的平均数据量乘以热点商品数量，再乘以一个冗余系数，避免大促时内存不够用，第三步是在压测环境验证两级缓存的组合效果，重点是观察缓存击穿时服务是否有保护机制,以及降级开关是否能顺利打开。
评价接口读写分离改造的最终效果，大促复盘时可以看几个核心数据：主库的QPS有没有明显下降，评价列表接口的P99响应时间是否在预算范围内，消息队列全程有没有发生过积压堆积，大促结束后，还需要再做一轮缓存清理和MySQL主从数据核对，确保异步写入过程中没有数据遗漏，整个方案虽然有一定复杂度，但对比大促期间评价接口直接崩溃造成的损失,这套架构改造的投入产出比相当可观。
商品评价接口在大促场景下的常见问题
Q：大促期间评价接口如果缓存失效，所有请求都打到数据库，有什么补救措施？
A：立即开启接口的降级开关，走预置的兜底数据返回，同时使用限流组件对入口流量进行控制，给缓存重建争取时间，缓存重建时采用分布式锁限制只有少量线程回源数据库，其余线程短暂的等待重试,防止瞬时压力打垮数据库连接池。
Q：评价数据的读写分离会不会导致用户刚提交的评价看不到，影响用户信任？
A：业务上允许评价提交后延迟几分钟出现在列表中，这是行业普遍的默认规则，在实际操作中，用户提交评价后前端页面会立即展示自己提交的内容，但其他用户看到这条评价会有一段延迟时间，这个时间段内数据通过消息队列异步同步,一般不会引起投诉。
Q：读写分离部署时要考虑地域问题吗？
A：如果商品评价接口的服务部署在多地域机房，比如同时服务华东、华北用户，需要考虑在每个地域的IDC内部署一套Redis集群，只同步该地域用户访问较多的商品评价数据，跨地域的读写延迟一般在几十毫秒以上，对大促时段的用户体验非常不友好，这属于本地化多活架构的部署方式，具体要不要做取决于业务体量和用户分布情况，大促期间，评价列表接口的稳定性直接影响转化率，读写分离改造配合降级预案,是电商后端在大促前最优先完成的事项。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/772469.html
