Redis秒杀 + 数据倾斜

一、秒杀

秒杀活动主要分为三个阶段：

• 秒杀前：尽量将活动页面静态化，因为此时用户会频繁刷新页面，使用CDN以及浏览器缓存进行加速；

• 秒杀时：查询库存 — 扣减库存 — 支付订单（只有查到库存数据的人才能进行后两步操纵）
  Redis主要支持原子性的查询库存和扣减库存操作（Lua脚本或者分布式锁），因为并发访问量大，不能交给后端数据库处理，而且上述原子性操作可以保证不会出现库存信息更新延迟导致实际用户查到超额的库存量并完成下单操作（避免超额销售）

• 秒杀后：用户刷新频率变低，并发压力小。

建议：

1. 用单独的Redis实例保存秒杀商品的库存
2. 使用拦截器拦截恶意访问请求，避免缓存穿透
3. 对库存信息的缓存信息不设置过期时间，避免失效导致的缓存击穿

二、数据倾斜：数据量倾斜 + 数据访问倾斜

参考软件架构发展，分布式，集群，负载均衡，消息队列都是为了将集中的访问请求分散开

总结Redis数据倾斜的成因以及解决方法

• 数据量倾斜：

1. slot没有平均分配到每个Redis实例（建议将每个Redis实例分配有相同的配置以及相同数量的slot）
2. 某个slot上存放了bigkey，bigkey导致虽然数据平均分配到了每个slot，但是一个bigkey占有的内存远大于其他一般的key（出现bigkey时考虑将一个value分成多个小的value存储，避免都放到一个key上形成bigkey）
3. 使用了hash tag进行key的手动分配，导致大量key集中到了同一个slot上；比如abc:{1001}，asd:{1001}，原本abc和asd会映射到两个不同的slot上，由于用了hash tag{}，只会对{}里面的内容求CRC16，然后对16384取模，所以两者最终映射到同一个slot，可以人为的将某些数据放到一起（比如同一个业务的或者要范围查找的数据，但一般不建议使用hash tag）

• 数据访问倾斜：

1. 读请求热点数据时：
   Redis实例上存放有热点数据key-value（解决方法是复制该value，然后在复制的key前面加一个随机数，这样会导致对key求CRC16时得到不一样的值，备份的数据就会被分配到不同的slot中，那么客户端想要访问原数据key-value时也加上这么一个随机数，就可以访问不同的Redis实例，但得到的值都是一样的）

2. 读写请求热点数据：
   以上随机数的方法不适用于有写请求的操作，会造成数据不一致，这种情况只能选择提高Redis实例的配置。

参考文章：

https://time.geekbang.org/column/article/308393