【Redis】Redis使用规范

针对线上Redis出过的一些问题，写一篇博客总结一下Redis使用规范，在发版本前需仔细阅读。

一、明确Redis产品定位

1. 仅适用于缓存场景：Redis定位于高性能缓存服务，强调快速读写和低延迟的特性，主要用于数据的快速存取，提升系统的响应速度。Redis本身不具备持久化能力，因此不建议用于大规模冷数据、持久化的存储场景。
2. 避免共用Redis集群：为避免相互影响和增加问题排查成本，不同业务不能共用Redis集群，确保业务间的隔离性，以便更容易定位和解决潜在的问题，提高系统的稳定性和可维护性。

二、合理利用Redis容灾能力

1. 多副本容灾：Redis基于分片内多副本进行数据容灾。当分片内只包含一个副本，发生Failover时将自动拉起空分片，此时分片可用性得到恢复，但原有数据将会丢失。如果您希望在Failover场景下能够保留数据，需要在申请集群时在默认主副本的基础上添加至少一组从副本。
2. 多机房容灾：Redis支持同地域内的跨机房部署，以保障机房级别容灾；但是跨机房部署架构中，主实例故障Failover后，还需要多一次迁移恢复原来的部署拓扑（迁移的过程会有性能抖动）。因此，建议您根据业务需求选择合适的部署方式。此外，对于特别核心的业务建议申请两个不同机房的Redis集群，通过双写的形式满足更高的高可用需求。

三、正确设计和存储数据

1、规范对Key的命名：

业务在设计Key的名称时，长度应控制在1024字节以内，过大的Key名称意味着更多的缓存空间占用。同时，禁止使用不可打印字符作为Key名称，避免会对后期缓存数据的维护、问题排查带来额外的负担。

2、避免存储大Value：

为优化性能和避免数据倾斜问题，Redis应避免存储大Value（集合类型元素数量<5000，字符串类型<10KB）。大Value不仅导致分片数据量和流量不均衡，还直接影响访问性能，增加延迟和资源消耗，因此合理控制Value大小对于提升系统效率和稳定性至关重要。

3、设计业务逻辑避免引入热Key：

热Key意味着业务流量会集中访问集群特定分片，导致单个分片压力过大，不能发挥集群多分片的优势。热key导致的单分片性能瓶颈，也无法通过扩容解决。（存在热Key风险的业务建议开启热Key缓存功能）。

4、合理设置Key过期时间：

建议为每个Key设置适当的过期时间，以避免浪费缓存资源。同时，尽可能打散Key的过期时间，避免大量Key集中过期，从而降低对集群性能的影响。通过合理设置过期时间和分散过期时间，可以提高缓存的利用率，保持系统的性能和可用性。

5、选择合适的淘汰策略：

创建Redis集群时结合业务场景选择合适的淘汰策略，如volatile-lru（设置了过期时间的Key按照lru进行逐出）、allkeys-lru（所有Key按照lru进行逐出）、noeviction（不淘汰数据，但写入会失败）等，确保高效利用有限资源，同时提高缓存命中率。

四、优化读写请求

1、避免过度复杂的命令：

在执行复杂度为O(n)的命令（如HGETALL、SMEMBERS、LRANGE、DEL等）时，需要特别注意参数n的大小。如果n过大，将导致Redis服务阻塞，影响其他操作的执行和系统的性能。因此，合理控制n的大小，避免复杂度过高的操作，是保持Redis服务的稳定性和可用性的重要考虑因素。

2、合理使用异步/pipline：

在异步操作或使用pipeline场景中，需要谨慎控制读操作的频率或单批次操作的Key数量。频繁的读操作、大批量操作可能导致缓存实例输出缓冲区的数据积压，进而触发OOM（Out of Memory）kill机制，造成数据丢失。

综上，我们从四个方面明确了Redis的产品定位和使用规范，需要在使用Redis时能够遵循以上原则，并根据自身业务需求做出合理的技术选型。通过合理配置和优化读写请求，可以充分发挥Redis的性能优势，提升系统的响应速度和可用性，减少潜在的问题和风险。

五、实际应用说明

1、什么是大KEY：

• 单个String类型的Key大小达到20KB并且OPS高
• 单个String达到100KB
• 集合类型的Key总大小达到1MB
• 集合类型的Key中元素超过5000个

2、大KEY带来的影响：

• 严重影响 QPS 、TP99 等指标，对大Key进行的慢操作会导致后续的命令被阻塞，从而导致一系列慢查询。
• hgetall 、 smembers 等时间复杂度O(N)的命令使用不当，容易造成使用率过高。
• 大Key发生热点，大 String，value大于 20K。当OPS为 10000，流量即为 200M, 达到单实例的流量配额. 导致 Redis无法正常提供服务。
• 集群各分片内存使用不均。某个分片占用内存较高或OOM，发送缓存区增大等，导致该分片其他Key被逐出，同时也会造成其他分片的资源浪费。
• 集群各分片的带宽使用不均。某个分片被流控，其他分片则没有这种情况，且影响宿主机上的其它应用。
• 数据迁移失败过大的Key（如超过1G），在迁移、缩容、扩容，主从全量同步在序列化过程中，内存上涨，数据同步失败，且存在 OOM 风险。

3、大KEY扫描在日常运营中的实际案例：

某业务反馈性能突然下降，值班同学对集群的检查怀疑有大Key，使用SCAN命令进行循序渐进式删除大Key。对集群进行大KEY扫描，发现业务存在大量超过1MB的大Key。将大Key反馈给业务方，业务处理掉大Key后，性能得到恢复。发现大KEY后的处理建议：

• String类型的大Key：可以尝试将对象分拆成几个Key-Value， 使用MGET或者多个GET组成的pipeline获取值，分拆单次操作的压力，对于集群来说可以将操作压力平摊到多个分片上，降低对单个分片的影响。
• 集合类型的大Key，并且需要整存整取要在设计上严格禁止这种场景的出现，如无法拆分，有效的方法是将该大Key从Redis去除，单独放到其他存储介质上。
• 集合类型的大Key，每次只需操作部分元素：将集合类型中的元素分拆。以Hash类型为例，可以在客户端定义一个分拆Key的数量N，每次对HGET和HSET操作的field计算哈希值并取模N，确定该field落在哪个Key上。
• 禁止使用DEL直接删除大Key，可能会造成Redis阻塞,建议使用SCAN的方式进行循序渐进式删除。
• 有些大Key是累积产生的，建议合理设置过期时间并对过期数据定期清理。

4、什么是热Key

热 Key 指的是那些在一段时间内访问频次比较高的Key。也就是说以接收到的Key的请求频率来判定，例如：

1. QPS集中在特定的Key:Redis实例的总QPS(每秒查询率)为20000，而其中一个Key的每秒访问量达到了10000(如上图a-b阶段)。
2. 带宽使用率集中在特定的Key:对一个拥有上千个成员且总大小为1 MB的HASH Key每秒发送大量的HGETALL操作请求。

5、热Key的危害

热Key发生会对系统稳定性产生巨大危害，特别是电商秒杀与抢购等业务场景中，热key会导致流量集中，Redis和数据库被击穿，从而引发系统雪崩，此外还会:

1. 占用大量的Redis实例CPU资源，影响其他请求并导致整体性能降低。
2. 会影响在同一个 Redis实例上其他Key的读写请求操作。
3. 集群架构下产生访问倾斜，即某个数据分片被大量访问，而其他数据分片处于空闲状态，可能引起该数据分片的连接数被耗尽，新的连接建立请求被拒绝等问题。

创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️