Redis 集群

你会选择使用 Redis Cluster 集群吗？如何使用 Redis 应对秒杀？极客时间《Redis 核心技术与实战》专栏学习笔记 20，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自极客时间《Redis 核心技术与实战》专栏，Redis Codis 集群

35 | Codis VS Redis Cluster：我该选择哪一个集群方案？

在阅读本文之前，我的想法是，如果条件允许，主要是 Redis 的版本，另外还有业务需要，当然是选择 Redis Cluster 官方的集群方案。

Codis 有 1024 个逻辑槽 Slot，客户端读取时，使用 CRC32 算法计算 key 的哈希值，并且对 1024 取模，余数对应 slot 编号，再通过 Slot 和 server 的对应关系，找到数据所在服务器。

数据路由表由 Codis dashboard 配置，保存在 codis proxy 上，同时也保存在 Zookeeper 中。

Redis Cluster 有 16384 个哈希槽 Hash Slot，采用 CRC16 算法计算哈希值，对 16384 取模。数据路由表通过实例间相同通信传递，每个实例上保存一份。

从老师的推荐来看，是比较偏爱 Codis 的，但是 Codis 似乎不再更新了。

对于课后题，20 万个 2KB 元素的 Hash 类型数据，应该已经算是 bigkey 了，迁移这样的 Hash 集合数据，如果采用 Codis 的异步迁移，感觉似乎问题不大。如果是读多写少的缓存应用，应该就更没有问题了。

看了课代表的提醒，才知道 Codis 是 Go 语言开发的，最近正准备入坑 Let's Go

36 | Redis 支撑秒杀场景的关键技术和实践都有哪些？

秒杀的负载特征是瞬时并发访问量大、读多写少。

秒杀前，使用 CDN 和浏览器缓存服务，不需要 Redis；

秒杀中，查询库存并发压力大，可以使用 Redis 保存库存并进行库存扣减，后台数据库处理订单操作；

秒杀后，并发量下降，不需要 Redis。

使用 Hash 数据类型，直接保存总库存量和已秒杀量，这个比较聪明，我一开始以为只保存已秒杀量即可。

使用分布式锁的方案明显更高一筹。

对于课后题，我觉得把 800 个库存分到 4 个 Redis 上不算是一个好方案，因为可能会导致有的 Redis 实例上库存没有了，而其他的还有。一个商品，800 库存，单个的 Redis 应该就能够应付了吧。

看了课后留言，分库存主要的问题一个是可能数据倾斜，另外就是对于计算剩余库存不友好。

如果采用 Codis 集群方案，那么在秒杀并发比较高的情况下，codis proxy 是否也需要扩容？

另外，出门右转，隔壁还有一个《如何设计一个秒杀系统》的专栏。