【第六讲，Redis的高并发实战：抢购系统】

讲师：浅奕，阿里云NoSQL内核工程师。
课程内容：IO模型和问题；资源竞争，与分布式锁；如何利用Redis的高并发原理做抢购系统。

答疑汇总：特感谢班委@张鹏 同学

1.      zset 和 hash 的配合使用

zset 存储主键 key 和分数，然后 key 用 hash, 这样容量和缓存占比应该是最小的。但是问题是批量查询，zset 是有一个还是很多个，如果是一个，要小心成为热点 key 。hash 有一个 mget ,可以拿一个hash 的多个字段，但是多个 hash 是没有相关 API 一次性拿的，原因是多个 hash 的 key 可能存在集群的多个分片上。

2.      用 stream 实现一个消息队列？

使用方法类似于 kafka , 需要有producer, consumer group, topic 等。

3.      缓存怎么和数据库保持强一致？

首先是很难保证的，应该尽量避免数据不一致。如果出现不一致，要以最可靠的数据库做一个兜底。要避免这个问题，主要是解决缓存在更新的时候。一种方式是只有一个线程写，定时从数据库更新数据到缓存，可以监听数据库 binlog 的修改，更新缓存。另一种方式是业务线程来更新，先持久化再删除缓存，然后读逻辑来更新缓存。缓存一般是要设置过期时间的。

4.      Set 和 Sorted Set对性能是否有影响？

Redis 的数据结构为了省内存，编码是有两种或两种以上的，在配置里边会有一个默认值，比如可以设置 set 它在成员小于多少的时候是一个列表，大于的时候是一个哈希结构。hash 结构的查询效率是O(1), 排序集合使用跳表，成员小于一定数量是使用压缩表。一般情况不要调大这个参数值，可以改小这个参数值，尽量用稀疏的数据结构，用 hash和跳表，不要使用压缩结构，压缩结构查询和插入效率一般都是O(n) 的。

5.      秒杀场景节点多少个比较好？

看业务需求了，单分片单key 的能力是 QPS 10万左右，然后对业务的预估确定分片数，理想情况，查询比较散的情况下，根据总的QPS 计算，预留 30% 的水位就可以了。

分片太多也不好，正常的访问是没问题的，只是发生变化的时候，客户端会有比较多的错误。如果是开源版，节点比较多集群Gossip 协议广播会比较厉害。

6.      Lua 的问题是不是可以使用单独集群处理？

Lua 需要慎用，但不是不用。我们要清楚正常的一个读写能达到 QPS 10万，如果在lua 里面可能就只有8万了。对性能有一定影响。不要在 lua 里写比较复杂的循环。对性能的影响就是lua 本身需要编译执行。如果 lua 都非常小，不需要单独集群处理。主要是控制好lua 执行的时间就好了。

7.      对于大 key 有什么好的方案？

大 key 一般都是指 list、hash、set 这类数据结构，list 没有什么好的解法，可以将list 拆分成多个 list ,但是对于业务来说是比较难处理的，建议尽量避免大 key。

8.      Redis 的 key 或value 用string 或 byte数组有什么区别吗？

对于服务端来说没有什么区别，主要看客户端是怎么实现的，比如看最终key 或 value 是怎么序列化的，最终发的时候肯定是一个序列化对象，发到服务端存储的时候就是一个字节数组。只是比如在执行incr 的时候，会对 value 做一个数字解析。

9.      Memcached 和 Redis 怎么选？

Memcached 只有 k-v 操作和原子计数操作，Memcached 是多线程方式，单分片性能可能优于Redis,但是数据结构支持较少。业务比较简单只用key-value结构和incr 操作的话，可以选择Memcached。memcached 数据导入导出比较困难，如果需要，建议选择Redis,而且 Redis 社区比较活跃一点。

10.  Mysql 和 Redis 的同步？

一般的方案是监听 mysql 的 binlog 的变动，然后解析出原始数据操作，去 Redis更新数据。