用Redis送礼提升性能，结果频繁赠一到底咋回事啊？

这事儿说白了,就是在一个高并发的送礼场景里，为了应对大量用户同时给主播或者别人送礼物，技术团队想了个招，用Redis这个特别快的内存数据库来先顶着，保证系统不卡顿、不崩溃，但没想到，用上之后，时不时就出现“赠一”的怪事，也就是用户明明送了一大堆礼物，比如100个“跑车”，结果系统只记录了他送了1个。

要弄懂为啥会这样,咱们得先看看他们大概是咋设计的，根据一些技术社区的讨论和案例分析，这种问题通常出在所谓的“计数逻辑”上。

第一种常见情况：Redis用错了模式，像“打卡”而不是“记账”。

想象一下,团队可能用了Redis的SET命令或者类似“设置”的思路，用户每次送礼，程序都执行一个操作：“把用户A送给主播B的礼物数量，设置成100”，这听起来没问题对吧？但坏就坏在“高并发”上。

如果同一瞬间,用户因为网络卡顿连续点了好几次“送100个礼物”，或者系统同时处理多个请求，可能会发生这样的事：

• 时刻1： 请求1到来，读取Redis，发现当前礼物数是0，然后它准备把数量设置成100。
• 时刻2： 就在请求1还没把100写回Redis的那个极短空隙里，请求2也来了，它读取Redis，读到的还是0（因为请求1的100还没存进去）。
• 时刻3： 请求1成功将数量设置成了100。
• 时刻4： 请求2基于它读到的旧数据0，也执行了“设置”操作，成功将数量覆盖成了100。

你看,两个“送100”的请求，最终结果还是100，而不是200，更极端的情况是，如果多个请求同时读到0，然后都把自己认为的数量（比如都是100）设置回去，那结果就可能变成用户送了N次，但最终只记录了1次（100个）的效果，这就好比好几个人同时在一张纸上签到，第一个人写了“张三已到”，第二个人不看前面，直接把纸抢过来也写“张三已到”，把第一个人的笔迹盖掉了，最后看起来好像张三只来了一次。

第二种情况：用了增加命令，但步骤没锁好，像“多人同时数钱数乱了”。

团队可能知道要用Redis的INCRBY命令（增加指定数值），这个比SET高级点，比如用户送100个礼物，就执行INCRBY key 100，这个命令本身是原子性的，意思是执行过程中不会被打断，保证这个“加100”的操作是安全的。

但问题可能出在更大的逻辑环节上,送礼可能不止是计数，还要检查用户余额够不够，一个常见的错误流程可能是：

1. 从数据库读取用户当前余额。
2. 判断余额是否大于等于礼物总价。
3. 如果够,就在Redis里执行INCRBY给礼物计数，同时扣减用户余额。

在高并发下,两个请求可能同时执行第一步，都读到了用户有足够的余额（比如够送10次100的礼物），然后它们都判断为“够”，接着都去执行INCRBY和扣款，结果用户可能只想送100个，但因为系统处理了多个重复请求，导致他实际被扣了多次钱，虽然Redis里的礼物数可能因为INCRBY的正确执行而累加了（比如变成了200、300），但在业务逻辑上，这依然是异常的，从用户视角看，也可能被理解为“赠一”（我的一次操作，为什么产生了多笔扣款和奇怪的礼物数量？），这就好比两个人同时清点一叠钱，都数到是1000元，然后都报告说“这是1000元”，但实际上这叠钱只应该被报告一次。

第三种情况：Redis和数据库“打架”了。

为了追求速度,礼物计数可能先写在Redis里，然后再找机会“同步”回正式的数据库（比如MySQL）做永久存储，这个同步过程可能不是立即发生的，而是定时批量处理。

如果在同步的间隙,系统发生了一些状况，比如服务器重启、Redis内存满了触发清理、或者同步程序本身出了bug，就可能导致Redis里临时存着的、正确的礼物数据丢失了一部分，当系统恢复后，从数据库里读到的还是老旧的数据，就好像用户后来的赠送行为都没发生过一样，只留下了最早的一次记录。

总结一下为啥“频繁赠一”：

核心就是“并发冲突”和“数据一致性”没处理好，Redis本身很快，但如果你用它的时候， surrounding的逻辑设计得不够严谨，没考虑到多个请求会“撞车”，那就很容易出这种鬼畜的bug，要么是几个请求互相覆盖了数据，要么是重复处理了同一个请求，要么是临时数据和持久化数据对不上账。

解决思路也围绕这些点：比如用Redis的分布式锁来保证同一时间只有一个请求能处理某个用户的送礼动作；或者设计更原子化的操作序列，避免“先读后写”这种容易出错的模式；再就是做好Redis与数据库之间的可靠同步，防止数据丢失，用好Redis这个加速器，还得配上一个缜密的“交通规则”，不然肯定要出事故。