高并发写入场景下，用NoSQL缓解关系库的行锁竞争是成熟且高效的方案，核心思路是把热点写入从关系库中剥离，交给NoSQL扛峰值，再异步回写。
高并发写入场景用NoSQL缓解关系库的行锁竞争，到底怎么操作？
如果你维护过一个秒杀系统或者抢购页面，大概率见过这种报错：Deadlock found when trying to get lock，这不是代码逻辑出错了，而是关系库的行锁被几十上百个事务同时争抢，最后谁都拿不到锁，行业共识认为，关系库在读多写少的场景下很稳，但在写多读少的高并发写入场景里,行锁竞争会直接拖垮数据库性能。
关系库行锁竞争怎么解决？先看锁是怎么“堵”上的
以MySQL InnoDB为例，默认隔离级别是REPEATABLE READ，你写一条UPDATE语句，所有命中的行都会被加上排他锁，如果两个事务同时更新同一行，后到的那个必须等前一个提交或回滚，在高并发写入场景下，比如库存扣减、积分累加、订单状态流转，大量线程在同一个热点行上排队,吞吐量瞬间跳水。
业内专家指出,典型的堵点有三个：
- 热点行集中在少数几条记录上,例如爆款商品的库存记录。
- 事务内执行了慢查询,锁持有时间被无限拉长。
- 应用层重试机制过于激进,反而加剧了锁竞争和死锁概率。
一个真实的库存扣减场景
假设商品库存只有100件，用户同时发起200个请求,每个请求都执行：
UPDATE inventory SET stock = stock - 1 WHERE product_id = 123 AND stock > 0;
在关系库里，这200个请求会按顺序获得行锁，即使每条更新只需要0.1毫秒，加上网络开销和事务提交耗时，总处理时间可能超过200毫秒，更麻烦的是，如果每个请求还伴随插入订单表、日志表,锁就扣得更久。
高并发写入场景用什么数据库？对比几种NoSQL的写入优势
NoSQL之所以能缓解行锁竞争，是因为它压根没有“行锁”这个概念，多数NoSQL以单记录原子操作为基础，写同一条数据时走的是内存操作或LSM树追加写,不会因为并发更新同一行而互相阻塞。
| 数据库 | 写入模型 | 高并发写入表现 | 典型适用场景 |
|---|---|---|---|
| Redis | 单线程事件循环 + 内存操作 | 极高，单机可达十万级QPS | 计数器、库存、热点数据 |
| MongoDB | WiredTiger引擎，文档级锁粒度 | 较高，支持并发写入 | 日志、订单快照、用户行为 |
| Cassandra | LSM树 + 分布式一致性哈希 | 高，线性扩展 | 时序数据、消息队列、IoT写入 |
从写放大和锁粒度两个维度看，NoSQL更适合追加型写入和热点计数型写入，关系库的行锁竞争在NoSQL这里变成了天然的顺序写或分片写,竞争被物理隔离。
NoSQL缓解行锁竞争，具体怎么落地？
你不能直接把MySQL的表扔给Redis，然后期望一切正常，真正合理的做法是分层设计，让NoSQL承担第一波写入压力,关系库只做最终落盘。
第一步：识别热点写入类型
不是所有写操作都适合迁移到NoSQL，你需要先分析业务，找出那些高频率、低一致性要求、单行更新的操作,典型可迁移场景：
- 商品浏览量、点赞数、收藏数。
- 用户登录次数、积分增减。
- 购物车中的商品数量变更。
- 秒杀活动的库存扣减。
这些操作的特点非常一致：每次只改一条记录的某个字段，不需要跨表事务,允许短期不在关系库里体现。
第二步：用Redis接住热点计数
以库存扣减为例,改造后的流程如下：
- 请求到达应用层，直接调用Redis的
DECR命令,判断返回值是否大于等于0。 - 如果
DECR成功，把本次扣减事件写入消息队列,比如Kafka或RocketMQ。 - 消费者异步从消息队列取出事件,再去更新MySQL的库存表。
- MySQL侧的更新可以合并批量执行，比如每100条扣减合并成一次
UPDATE ... SET stock = stock - 100。
这套流程的核心是把行锁竞争从关系库移走，Redis的单线程模型天然避免了锁竞争，即使是几十万QPS的扣减请求,也能在毫秒级返回结果。
关键命令示例
# 先设置初始库存 SET product:stock:123 100 # 扣减并返回剩余库存 DECR product:stock:123 # 如果剩余值小于0，说明已超卖，需要做补偿
注意，DECR是原子操作，不会有超卖问题，如果用了GET再SET,那就又回到竞态条件了。
第三步：选择MongoDB处理写多读少的详细记录
对于订单流水、操作日志这类写多读少且不涉及跨文档事务的场景，MongoDB比关系库更合适，MongoDB的文档模型允许你直接把整个订单快照存成一条JSON，不用拆表拆字段，写入时WiredTiger引擎按文档加锁,不同文档之间完全无锁竞争。
实际迁移时，你可以保留MySQL作为主库，MongoDB作为写入的影子库，应用层先写MongoDB，然后用定时任务批量同步到MySQL，这样MySQL端的行锁竞争从“每秒几千次”降为“每秒几十次批量插入”。
第四步：批量回写关系库，降低锁频率
回写是很多团队容易忽略的环节，如果依然一条一条地UPDATE，那NoSQL只是延后了问题，正确做法是合并写入：
- 每10秒或积攒50条记录，一次性执行
INSERT ... ON DUPLICATE KEY UPDATE。 - 使用
LOAD DATA LOCAL INFILE批量导入日志数据。 - 在MySQL端开启
innodb_autoinc_lock_mode=2,减少自增主键的锁竞争。
这样关系库实际触发的行锁次数大幅减少,锁等待自然消失。
哪些业务适合用NoSQL缓解行锁，哪些坚决不行？
并非所有高并发写入场景都适合这套方案，你需要分清业务的“一致性边界”。
适合迁移的业务特征
- 允许短暂不一致：比如点赞数延迟几秒显示,用户不会察觉。
- 单行独立更新：每次只改一条记录,不涉及多表联动。
- 写入量远超读取量：比如埋点日志，读很少,写极多。
典型迁移案例包括：电商秒杀库存、直播间人气计数、社交平台的帖子点赞数，这类业务用Redis或MongoDB后,关系库的行锁竞争几乎消失。
不适合的业务特征
- 强事务要求：比如转账扣款,A账户减少必须和B账户增加保持原子性。
- 复杂关联查询：需要
JOIN多张表聚合统计,NoSQL存起来很别扭。 - 回滚需求：在写入过程中可能进行的业务冒烟测试,需要即时回滚。
遇到以上情况，老老实实留在关系库，用分库分表或乐观锁来缓解竞争，NoSQL不能替代事务,只能把竞争移走。
NoSQL和关系库对比，该选哪个？
不要非此即彼，多数高并发系统是混合存储，关系库负责核心资产,NoSQL负责热点冲击。
| 维度 | 关系库 | NoSQL |
|---|---|---|
| 行锁 | InnoDB行锁，高并发下冲突明显 | 无行锁，或锁粒度极小 |
| 事务 | ACID完整支持 | 多数放弃ACID或只支持单文档事务 |
| 扩展 | 垂直扩展为主，分库分表复杂 | 水平扩展天然强 |
| 写入吞吐 | 受锁和磁盘fsync限制 | 内存写或顺序写，吞吐更高 |
比如你用MySQL存订单主表，同时用Redis存订单的实时状态变化，前端查询状态走Redis，后台结算走MySQL，这样既保证了结算事务的一致性,又扛住了用户频繁刷新订单状态带来的写入压力。
高并发写入用NoSQL缓解行锁竞争，常见问题有哪些
使用Redis扣库存，丢了数据怎么办？
Redis如果未开启AOF或配置了不合理的持久化策略，宕机可能丢数据，因此不能把Redis作为库存的唯一真相源，正确做法是Redis只做准入控制，消息队列里的扣减事件必须持久化到磁盘，MySQL最终从MQ消费恢复，Redis宕机后,重启时从MySQL加载剩余库存到Redis即可。
NoSQL写成功了，关系库回写失败怎么处理？
要保证最终一致，必须引入消息表或MQ的ACK机制，消费者拉取事件后，先写一张本地消息表（在关系库中），再更新业务表，如果更新失败，定时任务扫描消息表进行重试，这里不建议试图用NoSQL做分布式事务，而是用“本地消息表+重试”这一最稳妥的落地方案。
分库分表是不是也能解决行锁竞争？
分库分表能把热点行分散到不同库表，间接降低锁竞争，但分库分表对业务侵入非常大，查询和事务都得改造，而NoSQL缓冲方案则对原关系库透明，主库保持原样，只在前面加一层，如果你的业务允许最终一致性，优先考虑NoSQL缓冲,而不是一上来就分库分表。