Redis键值设计
优雅的key结构
Redis的Key虽然可以自定义，但最好遵循下面的几个最佳实践约定：
- 遵循基本格式：[业务名称]:[数据名]:[id]
- 长度不超过44字节
- 不包含特殊字符
例如：我们的登录业务，保存用户信息，其key是这样的：
优点：
①可读性强
②避免key冲突
③方便管理
④更节省内存： key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小
可能我们对第四点不是很了解, 这里简单说一下, 其实核心是 Redis 为了更省内存，对不同长度的字符串做了编码区分, 因为Redis 作为内存数据库，极致节省内存 是关键设计目标。String 类型是最常用的键值类型，所以对它的底层存储做优化，能显著降低内存开销。
下面我们来说说这 3 种编码格式
Redis 里 String 类型的底层编码，会根据字符串长度、内容自动切换，目的是用更高效的方式存数据
int 编码
触发条件：字符串内容是纯数字（可转成 64 位有符号整数，范围约 -9e18 ~ 9e18 ）。
存储方式：直接存成整数，不用存字符串结构，内存占用极小（类似 Java 里 long 类型占 8 字节）。
例子：key:123 会用 int 编码，存的是数字 123，而不是字符 '1','2','3' 。
embstr 编码
触发条件：字符串长度 ≤44 字节（Redis 不同版本可能微调，核心是短字符串），且非纯数字（或虽然是数字但没走 int 编码，比如超长数字串）。
存储方式：用 连续内存块 存字符串元数据（如长度、编码标识）+ 实际字符。因为内存连续，分配/访问更快，且额外开销（如指针、元数据）更小。
优势：比 raw 编码更省内存、更快，适合短字符串（比如缓存的键、小文本值 ）。
raw 编码
触发条件：字符串长度 ＞44 字节，或虽然短但因某些特殊情况（如包含特殊字符，无法用 embstr 优化 ）。
存储方式：用 离散内存块 存元数据和字符（比如元数据一块内存，字符串内容另一块 ）。相比 embstr，多了内存碎片、指针跳转的开销，内存占用更大。
拒绝BigKey
是什么?
BigKey通常以Key的大小和Key中成员的数量来综合判定，例如：
Key本身的数据量过大：一个String类型的Key，它的值为5 MB。
Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个。
Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB。
推荐值：
单个key的value小于10KB
对于集合类型的key，建议元素数量小于1000
为什么说要拒绝?
- 网络阻塞
对BigKey执行读请求时，少量的QPS(指服务器（或系统、服务）每秒能处理的查询请求数量)就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢
- 数据倾斜
BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡
- Redis阻塞
对元素较多的hash、list、zset等做运算会耗时较旧，使主线程被阻塞
- CPU压力
对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用
那我们如何发现是否存在BigKey呢?
- redis-cli --bigkeys
利用redis-cli提供的--bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key
- scan扫描
自己编程，利用scan扫描Redis中的所有key，利用strlen、hlen等命令判断key的长度（此处不建议使用MEMORY USAGE）
这里说不建议使用是因为MEMORY USAGE不是直接返回简单的长度，而是要递归解析数据结构（比如哈希、列表等复杂类型），计算实际内存占用包括元数据、指针、编码额外开销等 ）,涉及复杂的内存计算, 需要遍历内部元素才能统计内存，这会带来明显的 CPU 消耗和时间开销
- 第三方工具
利用第三方工具，如 Redis-Rdb-Tools分析RDB快照文件，全面分析内存使用情况
- 网络监控
自定义工具，监控进出Redis的网络数据，超出预警值时主动告警
那么如何删除发现的BigKey呢?
BigKey内存占用较多，即便时删除这样的key也需要耗费很长时间，导致Redis主线程阻塞，引发一系列问题。
- redis 3.0 及以下版本
如果是集合类型，则遍历BigKey的元素，先逐个删除子元素，最后删除BigKey
- Redis 4.0以后
Redis在4.0后提供了异步删除的命令：unlink
恰当的数据类型
举几个例子
例1：比如存储一个User对象，我们有三种存储方式：
方式一：json字符串
优点：实现简单粗暴
缺点：数据耦合，不够灵活
方式二：字段打散
优点：可以灵活访问对象任意字段
缺点：占用空间大、没办法做统一控制
方式三：hash
优点：底层使用ziplist，空间占用小，可以灵活访问对象的任意字段
缺点：代码相对复杂
所以比较之下,我们选择hash更好
但是这里可能会有人产生疑问: 刚刚上面不是说要拒绝BigKey吗,怎么还说选这个更好呢?
注意, 不是让你用 Hash 去存 BigKey，而是用 Hash 的合理设计（控制字段数量、大小 ），替代其他更差的方案（如 String 存大对象 ），同时避开 BigKey 问题
Hash 是 Redis 的数据类型：可以存多个字段（如 user:1 存 name、age ），底层用 ziplist（或 dict ）编码，设计合理时能高效、省内存。
BigKey 是 “Key 的值过大” 的问题：不管用 String、Hash、List 哪种类型，只要单个 Key 的值（或内部元素）过大（比如 Hash 存了 10 万个字段 ），就会变成 BigKey，引发网络、内存、性能问题。
例2：假如有hash类型的key，其中有100万对field和value，field是自增id，这个key存在什么问题？如何优化？
存在的问题：
①hash的entry数量超过500时，会使用哈希表而不是ZipList，内存占用较多。
②可以通过hash-max-ziplist-entries配置entry上限。但是如果entry过多就会导致BigKey问题
我们先说说存在的第一个问题
ziplist （压缩列表）：是 Redis 为了节省内存而设计的一种紧凑存储结构 。当 hash 类型数据的 entry（也就是 field - value 对）数量少、单个元素也比较小时，Redis 会用 ziplist 来存储，它把多个元素紧凑地存放在一块连续内存区域，能有效减少内存开销，访问时是按顺序遍历。
哈希表：当 hash 的 entry 数量超过配置的阈值（默认hash - max - ziplist - entries ，默认值通常是 512 ，不同版本可能有差异，这里说 500 是类似情况 ），Redis 就会把存储结构转换成哈希表（dict）。哈希表虽然查询效率高（平均 O (1)），但它的存储结构相对 “松散”，有更多额外的元数据（比如哈希桶、指针等），相比 ziplist，相同数据量下会占用更多内存。
这个时候我们可能会想到可以拆分成String来避免存储结构的转换
但是会存在两个问题：
①string结构底层没有太多内存优化，内存占用较多。
②想要批量获取这些数据比较麻烦
我们再来看看存在的第二个问题
BigKey 问题：Redis 中 “BigKey” 指的是存储了大量数据的键。这里 hash 类型 key 里有 100 万 entry，不管是用 ziplist（当调整配置让它能存这么多，但实际 ziplist 存这么多遍历、操作也慢）还是哈希表存储，这个 key 本身会非常 “庞大”。
那我们可能就需要结合这些问题, 想到一个新的方案:
拆分为小的hash，将 id / 100 作为key， 将id % 100 作为field，这样每100个元素为一个Hash
这样可以解决存储结构的转换, 也可以避免引发BigKey问题
设置合理的超时时间
核心作用
释放内存：比如存储用户登录态的 key ，用户登录一段时间后，相关数据就没用了，设超时自动删除，能把内存腾出来给其他有用数据，避免 Redis 内存被无用数据占满。
保证数据时效性：像缓存的热点新闻、促销活动信息，过了时效（比如活动结束）就该失效，设超时能让旧数据自动清理，新请求再去拉最新数据，保证业务逻辑里数据是“新鲜”的。
怎么合理设置
看业务场景：
短信验证码：几分钟就失效，超时设 3 - 5 分钟就行，避免被恶意利用，也及时释放内存。
用户登录态：设几小时到几天（比如 7 天），用户不用频繁重新登录，又能定期清理老旧登录态数据。
缓存数据库查询结果：根据数据更新频率来，更新频繁的（比如商品库存实时变），超时设短点（几秒、几分钟）；更新少的（比如商品分类），可以设几小时、几天。
别搞极端：
超时设太短，业务还在用数据就被删了，会频繁重新生成数据（比如重新查库、重新生成验证码），增加系统压力，也影响用户体验。
设太长，没用数据占着内存，Redis 内存容易不够用，拖慢整体性能。
批处理优化
Pipeline
我们先简单回顾一下:
单个命令执行流程: 一次命令的响应时间 = 1次往返的网络传输耗时 + 1次Redis执行命令耗时
N条命令执行流程: N次命令的响应时间 = N次往返的网络传输耗时 + N次Redis执行命令耗时
N条命令批量执行: N次命令的响应时间 = 1次往返的网络传输耗时 + N次Redis执行命令耗时
在Redis中提供了很多Mxxx这样的命令，可以实现批量插入数据，例如：mset, hmset
注意: 不要在一次批处理中传输太多命令，否则单次命令占用带宽过多，会导致网络阻塞
但是, MSET虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使用Pipeline功能：
注意事项：
①批处理时不建议一次携带太多命令
②Pipeline的多个命令之间不具备原子性
集群下的批处理
如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。
串行执行: 执行起来就简单，缺点就是耗时过久
串行slot: 简单来说，就是执行前，客户端先计算一下对应的key的slot（就是插槽），一样slot的key就放到一个组里边；不同的，就放到不同的组里。然后对每个组执行pipeline的批处理，他就能串行执行各个组的命令，这种做法比第一种方法耗时要少。但是相对来说复杂一点，所以这种方案还需要优化一下
并行slot: 相较于第二种方案，在分组完成后串行执行，第三种方案，就变成了并行执行各个命令，所以该方案的耗时就非常短，但是实现也更加复杂
hash_tag: Redis计算key的slot的时候，其实是根据key的有效部分来计算的，通过这种方式就能一次处理所有的key，这种方式耗时最短，实现也简单，但是如果通过操作key的有效部分，那么就会导致所有的key都落在同一个节点上，产生数据倾斜的问题
所以推荐使用第三种方式
服务端优化
持久化配置
Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：
1.用来做缓存的Redis实例尽量不要开启持久化功能
缓存数据通常可从源头（如数据库）重新获取，开启持久化会增加磁盘 IO、内存等开销。若缓存数据无需持久化保存（丢了能重建），关闭可提升性能，降低资源消耗。
2.建议关闭RDB持久化功能，使用AOF持久化
RDB 缺点：按快照方式持久化，若触发条件（如 save 60 10000 ）未满足时宕机，会丢失中间数据；且 fork 子进程做快照时，可能因内存拷贝等暂阻塞主线程，大数据量下影响更明显 。
AOF 优势：记录写命令，数据丢失风险更低（可配 everysec 每秒刷盘，最多丢 1 秒数据 ）；还能通过重写机制压缩日志，一定程度缓解文件过大问题，对数据安全性要求高的场景更合适。
3.利用脚本定期在slave节点做RDB，实现数据备份
slave（从节点）做 RDB 备份，不影响 master（主节点）性能。RDB 文件紧凑、恢复快，定期生成可作为数据冷备份，遇到 AOF 损坏等极端情况，能用 RDB 恢复基础数据，保障数据可恢复性。
4.设置合理的rewrite阈值，避免频繁的bgrewrite(就是bgrewriteaof )
AOF 重写（bgrewriteaof ）会 fork 子进程整理日志、压缩体积。阈值（如 auto - aof - rewrite - percentage 和 auto - aof - rewrite - min - size ）设得太松，AOF 文件易过大，恢复慢；设太紧，会频繁触发重写，fork 操作频繁占用资源（CPU、内存），影响 Redis 正常服务。需结合业务写频率、数据量，找平衡值（如文件增大 100% 且达 64MB 时重写 ）。
5.配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞
AOF 重写时，若同时执行 appendfsync（刷盘），磁盘 IO 压力会陡增，可能阻塞 Redis 主线程（无法及时处理客户端命令 ）。开启该配置，重写期间暂停刷盘，优先完成重写，减少对正常业务的影响，后续再补偿刷盘，平衡重写和 IO 开销。
部署有关建议：
1.Redis实例的物理机要预留足够内存，应对fork和rewrite
fork 子进程（RDB 快照、AOF 重写时）会复制父进程内存页表，虽用写时复制（写数据才实际拷贝内存），但仍需预留内存防止内存不足；重写 AOF 也需额外内存暂存新日志，预留内存可避免因内存不够触发交换（swap），导致 Redis 性能急剧下降。
2.单个Redis实例内存上限不要太大，例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
内存越大，fork 子进程耗时越久（遍历、复制内存页表耗时增加 ），阻塞主线程时间长；主从同步时，大内存实例传输数据多，网络、时间成本高；数据迁移（如扩容、迁移实例）也更麻烦。控制在 4G/8G 等小规格，能降低这些操作的压力，提升运维效率。
3.不要与CPU密集型应用部署在一起
Redis 本身依赖 CPU 处理命令、做持久化等操作。若和 CPU 密集型（如大数据计算、视频编码）应用共存，会争抢 CPU 资源，导致 Redis 处理命令延迟增加，降低响应速度，影响业务使用体验。
4.不要与高硬盘负载应用一起部署。例如：数据库、消息队列
数据库（如 MySQL）、消息队列（如 Kafka ）本身读写磁盘频繁，会占满磁盘 IO 带宽。Redis 持久化（尤其是 AOF 实时刷盘）、重写也依赖磁盘，共存会让磁盘 IO 竞争激烈，加剧延迟，使 Redis 持久化变慢、命令执行卡顿，破坏服务稳定性 。
慢查询
在Redis执行时耗时超过某个阈值的命令，称为慢查询。
慢查询的阈值可以通过配置指定：
- slowlog-log-slower-than：慢查询阈值，单位是微秒。默认是10000，建议1000
慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：
- slowlog-max-len：慢查询日志（本质是一个队列）的长度。默认是128，建议1000
修改这两个配置可以使用：config set命令：
查看慢查询日志列表：
- slowloglen：查询慢查询日志长度
- slowlog get [n]：读取n条慢查询日志
- slowlog reset：清空慢查询列表
命令及安全配置
Redis会绑定在0.0.0.0:6379，这样将会将Redis服务暴露到公网上，而Redis如果没有做身份认证，会出现严重的安全漏洞.
漏洞重现方式：Redis未授权访问配合SSH key文件利用分析-腾讯云开发者社区-腾讯云
漏洞出现的核心的原因有以下几点：
- Redis未设置密码
- 利用了Redis的config set命令动态修改Redis配置
- 使用了Root账号权限启动Redis
为了避免这样的漏洞，这里给出一些建议：
①Redis一定要设置密码
②禁止线上使用下面命令：keys、flushall、flushdb、config set等命令。可以利用rename-command禁用。
③bind：限制网卡，禁止外网网卡访问
④开启防火墙
⑤不要使用Root账户启动Redis
⑥尽量不是有默认的端口
内存配置
当Redis内存不足时，会出现很多问题, 可能导致Key频繁被删除、响应时间变长、QPS不稳定等。当内存使用率达到90%以上时就需要我们警惕，并快速定位到内存占用的原因并解决
数据内存问题
Redis提供了一些命令，可以查看到Redis目前的内存分配状态：
- linfo memory
- lmemory xxx
内存缓冲区配置
内存缓冲区常见的有三种：
复制缓冲区：主从复制的repl_backlog_buf，如果太小可能导致频繁的全量复制，影响性能。通过repl-backlog-size来设置，默认1mb
AOF缓冲区：AOF刷盘之前的缓存区域，AOF执行rewrite的缓冲区。无法设置容量上限
客户端缓冲区：分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置。输出缓冲区可以设置
以上的复制缓冲区和AOF缓冲区不会有问题，最关键就是客户端缓冲区的问题；
客户端缓冲区指的就是我们发送命令时，客户端用来缓存命令的一个缓冲区，也就是我们向Redis输入数据的输入端缓冲区和Redis向客户端返回数据的响应缓存区，输入缓冲区最大1G且不能设置，所以这一块我们根本不用担心，如果超过了这个空间，Redis会直接断开，因为本来此时此刻就代表着Redis处理不过来了，我们需要担心的就是输出端缓冲区；
默认的配置如下：
我们在使用Redis过程中，如果需要处理大量的big value，那么会导致输出结果过多，进而导致输出缓存区压力过大；如果输出缓存区压力过大，会导致Redis直接断开，而默认配置的情况下， 其实它是没有大小的，这就比较坑了，内存可能一下子被占满，会直接导致redis断开，所以解决方案有两个：
- 设置一个大小
- 增加带宽的大小，避免出现大量数据从而直接超过了Redis的承受能力
集群
问题
集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题：
①集群完整性问题
②集群带宽问题
③数据倾斜问题
④客户端性能问题
⑤命令的集群兼容性问题
⑥lua和事务问题
集群完整性问题
在Redis的默认配置中，如果发现任意一个插槽不可用，则整个集群都会停止对外服务
含义：指集群因部分节点故障、网络分区等，无法维持完整服务能力，数据或槽位管理出现异常。
场景举例：比如网络分区，集群被分成 “主节点多数派” 和 “少数派”，少数派里的主节点因判断不到多数节点，可能被标记为故障，其负责的槽位无法正常提供服务；或者节点故障后，从节点没能及时完成故障转移，导致部分槽位对应的读写请求失败，破坏集群数据访问的完整性。
为了保证高可用特性，这里建议将 cluster-require-full-coverage配置为false
集群带宽问题
含义：集群节点间（如心跳检测、数据同步、槽位信息广播等）的网络通信，占用过多带宽，影响正常业务数据传输，甚至引发网络拥堵。
场景举例：节点数量多、心跳频率高（cluster-node-timeout 配置不合理，触发频繁心跳）时，大量心跳包在节点间传输，占满内网带宽；主从节点间全量同步大体积数据（如刚扩容从节点、主节点故障切换后的数据同步 ），也会瞬间抢占带宽，导致其他节点间通信延迟、业务读写卡顿。
集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息至少包括：
- 插槽信息
- 集群状态信息
集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高。
解决途径：
①避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群。
②避免在单个物理机中运行太多Redis实例
③配置合适的cluster-node-timeout值(这是用于判断节点心跳状态、决定故障转移的超时配置)
数据倾斜问题
含义：集群中不同节点存储的键值对数量、数据量差异悬殊，部分节点负载过高，部分节点资源闲置，破坏集群负载均衡。
场景举例：若业务 key 设计没做好哈希分散（比如 key 前缀固定、哈希算法选得不好 ），会导致大量 key 集中映射到少数槽位，对应节点存储的数据量远超过其他节点。比如一个节点存了 80% 的数据，其他节点只存 20% ，读写时该节点会成为性能瓶颈，拖慢整个集群。
解决方法(其实在上面的批处理已经说过了):
- Key 设计优化：采用合理哈希算法（如 Redis 集群默认的 CRC16 哈希），让 Key 均匀映射到槽位。避免 Key 前缀固定（如用随机后缀、哈希打散 Key ）；对批量操作的多 Key，确保它们在同一槽（可通过
{hash_tag}语法，如{user}:1、{user}:2让相同hash_tag的 Key 落在同槽 ）。 - 监控与迁移：通过
redis-cli --cluster info等命令监控各节点 Key 数量、内存占用，发现倾斜及时处理。若因历史数据导致倾斜，可使用CLUSTER SETSLOT手动迁移槽位数据，或借助 Redis 集群的reshard功能（如redis-cli --cluster reshard）自动均衡槽位分布。
客户端性能问题
含义：因客户端对集群特性不了解、配置不当，或集群本身状态异常，导致客户端读写延迟高、连接失败、重试频繁等性能劣化。
场景举例：客户端没正确处理 “MOVED”“ASK” 重定向（比如重试逻辑写得不好，反复重定向增加延迟 ）；集群节点故障引发短暂不可用，客户端没合理设置超时、重试策略，出现大量超时报错；或者客户端连接池配置不合理（比如连接数太少，并发请求排队 ），都可能让客户端性能雪崩。
解决方法:
- 连接池优化：客户端合理配置连接池参数（如最大连接数、空闲连接超时），避免连接过多导致资源耗尽，或连接过少引发排队等待。例如 Java 客户端 Lettuce，可调整
maxTotal（最大连接数 ）、minIdle（最小空闲连接 ）等。 - 重定向处理：客户端完善 “MOVED”“ASK” 重定向逻辑，缓存槽位映射信息（减少重复查询集群节点的开销 ），并设置合理重试策略（如重试次数、间隔 ），避免因频繁重定向拖慢请求。
- 异步与 Pipeline：对批量操作，使用 Pipeline（管道 ）批量发送命令，减少网络往返次数；对非关键操作，采用异步调用，释放客户端线程，提升并发处理能力。
命令的集群兼容性问题
含义：Redis 集群模式下，部分命令因依赖 “键所在节点确定”“多键操作跨槽” 等特性，无法正常执行或有特殊限制。
场景举例：像 KEYS * 命令，在集群里只能扫描单个节点的键（无法跨节点全局扫描 ），若业务用它做全局键遍历，结果会不完整；MSET key1 value1 key2 value2 这类多键操作，若 key 分布在不同槽位，命令会直接报错（因为集群模式下，多键操作要求所有键在同一槽 ），业务若没做兼容处理，就会触发异常。
解决方法:
- 命令适配改造：避免使用集群不兼容命令（如
KEYS *改用SCAN迭代查询；多 Key 操作确保 Key 同槽，或拆分操作 ）。若业务依赖跨槽多 Key 操作，可在客户端先查询 Key 所在槽，再分发命令到对应节点执行，最后聚合结果。 - 工具辅助检测：迁移或上线前，用
redis-cli --cluster check等工具扫描集群命令兼容性；也可在测试环境模拟业务操作，提前发现不兼容命令并调整（如将MSET key1 key2改为单 Key 操作，或确保 Key 同槽 ）。
lua和事务问题
含义：Redis 集群对 Lua 脚本、事务操作有特殊限制，若不遵循规则，会导致脚本 / 事务执行失败，破坏业务逻辑。Lua和事务都是要保证原子性问题，如果你的key不在一个节点，那么是无法保证Lua的执行和事务的特性的，所以在集群模式是没有办法执行Lua和事务的。
场景举例：
- Lua 脚本里操作多键时，要求所有键必须在同一槽（否则执行报错 ），若业务脚本没提前规划键的分布，就会执行失败；
- 事务（
MULTI/EXEC）在集群模式下，同样要求操作的键在同一槽，且不支持跨节点事务（因为 Redis 集群的事务是 “弱事务”，依赖单节点执行 ），若业务强制跨节点用事务，数据一致性会出问题，甚至命令无法执行。
解决方法:
- Lua 脚本优化：编写 Lua 脚本时，确保操作的 Key 都在同一槽（用
{hash_tag}约束 Key 分布 ）。若需跨槽操作，拆分为多个脚本，分别在对应节点执行。同时，限制脚本复杂度和执行时间，避免阻塞 Redis 线程。 - 事务替代方案：集群模式下，避免使用跨槽事务（因无法保证原子性 ）。若业务需原子性操作，优先用 Lua 脚本（单槽内保证原子性 ）；或拆分业务逻辑，改为单 Key / 同槽 Key 操作，结合乐观锁（如
WATCH命令，需注意集群下WATCH仅在单节点生效 ）实现类似事务效果。
那到底选择集群还是主从?
单体Redis（主从Redis）已经能达到万级别的QPS，并且也具备很强的高可用特性。如果主从能满足业务需求的情况下，所以如果不是在万不得已的情况下，尽量不搭建Redis集群。