峰值时刻怎么用Redis搞高并发同步，性能还能稳住吗？

要搞清楚这个问题，我们得先想象一个场景，比如双十一零点，或者热门演唱会抢票，成千上万的人同时点击“购买”或“下单”按钮，这时候，后台系统最怕的是什么？超卖”，比如库存只有100件商品，结果因为网络延迟、服务器处理速度不同，系统错误地判断库存充足，一下子卖出去120件,这就出大问题了。

Redis之所以能成为解决这个问题的利器，核心在于它的两个特点：一是速度快，因为它把数据都存在内存里；二是它提供了一些“原子操作”，原子操作的意思就是这个操作一旦开始，就不会被其他请求打断，一定会一口气做完，中间不会有别的请求插进来捣乱，这就好比只有一个收银台的超市，大家必须排队，一个一个结账,不会出现两个人同时结账算错钱的情况。

具体怎么用Redis来搞定高并发下的库存同步呢？一个最经典、最直接的办法就是利用Redis的DECR命令，这个命令的作用是把一个键（key）对应的数字值减去1，它的原子性保证了即使在 peak time，成千上万个请求同时发来这个命令，Redis也会排着队一个一个地执行，绝对不会出现两个请求都读到库存是10，然后都减去1,最后库存变成9而不是8的尴尬情况。

操作流程大致是这样的（引用自常见的电商秒杀方案设计）：在活动开始前，我们提前把商品的库存数量，比如100件，设置到Redis中的一个键值对里，key 是 seckill:stock:商品ID，value 是 100，当用户抢购时，后台系统不是直接去复杂的数据库里查库存、算库存、更新库存，而是直接向Redis发送一个 DECR seckill:stock:商品ID 命令，Redis执行这个命令后，会返回一个结果值，如果这个结果值大于等于0，恭喜你，说明扣减成功，抢到了购买资格，如果返回的是一个小于0的数，1，那就说明库存已经扣减到零了，晚来一步，抢购失败，通过这种方式，库存判断和扣减这个最关键的步骤，就在Redis这个“超级高速收费口”完成了,又快又准。

光有这一步还不够，因为抢购资格只是第一步，后面还有生成订单、扣减其他权益、支付等一系列操作，如果用户抢到了资格，但后续因为网络问题或者自己不想买了，这个库存可不能就这么没了，我们还需要一个“回滚”或“恢复”的机制，这时候可以用Redis的 INCR 命令，它的作用正相反，是给数值加1，也是原子性的，我们可以给抢购资格设置一个短暂的“有效期”，比如15分钟，如果用户在规定时间内没有完成支付，系统就自动执行一个 INCR 命令，把库存再加回去，这样既保证了公平性,又避免了资源浪费。

第二个问题来了：这么搞,Redis的性能能稳住吗？

答案是：能，但需要做很多“保养”工作，Redis本身单线程处理命令的模式，天然避免了锁的竞争，效率极高，理论上每秒处理十万甚至百万级别的简单命令（如DECR）都不是问题（引用自Redis官方文档关于性能的说明），但前提是，我们不能把它用残了,以下是几个保证性能稳得住的关键点：

第一，别让Redis干重活，Redis是缓存，不是关系型数据库，它的强项是读和写简单的键值对，像抢购这种场景，我们只让它做最核心的库存扣减判断，至于生成详细订单、记录复杂日志这些耗时操作，应该放在抢购成功之后，通过消息队列异步慢慢地交给下游的数据库和应用去处理，这叫“削峰填谷”，把一瞬间的海浪变成一条平稳的河流，减轻数据库的压力,也解放了Redis。

第二，做好部署和架构，单机的Redis再快也有极限，而且一旦宕机就全完了，所以对于超大规模的场景，需要考虑Redis的集群模式（Cluster模式），把数据分片存储在多个Redis节点上，这样性能可以水平扩展，容量也更大，并且具备了高可用性，即使坏掉一两个节点,服务也不会中断。

第三，预防“缓存穿透”和“缓存击穿”，如果有人恶意攻击，不断请求一个根本不存在的商品ID的库存，每次请求都会穿透Redis打到数据库上，这就是缓存穿透，解决办法可以是，在Redis里也缓存一个“空值”，或者提前把参与活动的商品ID加载到Redis里，快速判断请求是否合法，而缓存击穿是指一个热点key在失效的瞬间，大量请求同时涌来，直接打垮数据库，对于库存这种关键数据，我们可以设置它永不过期，或者使用互斥锁（Redis的SETNX命令）来保证只有一个请求去重建缓存。

第四，连接管理，高并发下，频繁地创建和关闭连接会耗光资源，所以一定要使用连接池，预先建立好一批连接，需要的时候直接从池子里取，用完了放回去,避免频繁的开销。

用Redis应对峰值时刻的高并发同步，核心思路是：利用其原子操作保证数据准确性，将核心校验逻辑前置并高速化，同时通过异步、集群、防攻击等多种手段为Redis“减负”和“护航”，只要设计得当，Redis完全有能力在惊涛骇浪般的并发请求中，成为一个坚不可摧的“定海神针”，既稳住数据,也稳住性能。