【Redis 神秘大陆】005 常见性能优化方式

五、Redis 性能优化

5.1 系统层面的优化

https://github.com/sohutv/cachecloud/blob/main/redis-ecs/script/cachecloud-init.sh

initConfig() {
  # 支持虚拟内存分配
  sysctl vm.overcommit_memory=1
  # 最大排队连接数设置为 511，一般默认是 128
  echo 511 >/proc/sys/net/core/somaxconn
  # 禁用透明大页，使用传统的小页进行管理，大页可能会导致性能下降或者不稳定
  echo never >/sys/kernel/mm/transparent_hugepage/enabled
  echo never >/sys/kernel/mm/transparent_hugepage/defrag
  # 内核将尽量减少对交换分区（内存数据存储到磁盘上）的使用，提高性能避免不必要的
  echo 0 >/proc/sys/vm/swappiness &
  # 关闭系统上的交换分区，并且输出重定向到文件
  nohup swapoff -a >swap.out 2>&1
  echo -e "\033[41;36m OK: initial config done. \033[0m"
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

5.2 客户端优化

5.2.1 维度化缓存

在电商系统中，一个商品可能包含多个维度的数据，如基础属性、图片列表、上下架状态、规格参数、商品介绍等。针对这种情况，可以采用维度化缓存方案进行优化，以减少更新成本和服务压力。

方案概述

• 将商品数据按照不同维度进行拆分，并对每个维度进行缓存。
• 对于商品变更，只更新变更的部分数据，而不是整个商品数据。
• 对于频繁变更的维度，如上下架状态，通过维度化缓存可以减少服务压力。

实施方式

• 接收MQ进行更新：根据不同维度的变更，通过消息队列（MQ）接收更新消息，对相应维度的缓存进行增量更新。

5.2.2 大 Value 优化

在缓存中存在大Value的情况下，特别是在使用Redis等内存数据库时，需要注意缓存的大小限制。针对大Value的缓存，可以考虑以下方案：

• 使用多线程缓存：采用多线程实现的缓存（如Memcached）来缓存大Value，以提高并发读写能力。
• 压缩Value：对Value进行压缩，减小存储空间。
• 拆分Value：将大Value拆分为多个小Value，在客户端进行查询和聚合，以降低单个缓存项的大小。

5.2.3 热点缓存

对于访问频率非常高的热点缓存，直接从远程缓存系统中获取可能会导致系统负载过高、响应慢等问题。针对这种情况，可以考虑以下解决方案：

• 增加从缓存：增加更多地从缓存节点，通过负载均衡机制读取从缓存系统的数据，以提高并发读取能力。

• 本地缓存：在客户端所在的应用/代理层本地存储一份热点数据的副本，减少对远程缓存系统的访问，提高响应速度。

• 定期更新策略：对于不那么频繁变化的数据，可以考虑在本地缓存一段时间后，定期从远程缓存系统更新数据，以保持数据的实时性。

5.2.4 迁移过程优化

Redis Cluster 模式下集群只对 Redis 的存活负责，不对数据负责。客户端提交请求后，如果这个 key 不归属于这个服务器，会返回 MOVE 命令，客户端需要自行跳转，增加网络一跳。

5.3 服务端优化

https://github.com/eishay/jvm-serializers/wiki

5.3.1 参数优化

降低主从延迟

repl-disable-tcp-nodelay ：

• [ 默认 ] 关闭状态：主节点产生的命令数据无论大小都会及时发送给从节点，减小主从之间的延迟，但增加网络带宽消耗。适用于网络环境良好的场景，如同机架或同机房部署。
• 开启状态：主节点会合并较小的TCP数据包以节省带宽，但会增加主从之间的延迟。适用于网络环境复杂或带宽紧张的场景，如跨机房部署。

主从复制参数优化

5.3.2 架构优化

复制风暴

复制风暴是指在Redis中，大量从节点同时对同一主节点或者对同一台机器的多个主节点发起全量复制的过程。这种情况会给主节点或者机器带来大量的开销，包括CPU、内存和带宽消耗。为了规避复制风暴，可以采取以下几个解决方案：

• 单主节点复制风暴：

• 问题：

• 单主节点复制风暴通常发生在主节点挂载多个从节点的场景。当主节点重启后，从节点会发起全量复制流程，主节点为每个从节点创建RDB快照。如果在创建完毕之前有多个从节点同时尝试与主节点进行全量同步，主节点会为它们创建多个快照，导致网络带宽消耗严重，延迟增大，甚至导致主从连接断开。

• 解决方案：

• 包括减少主节点挂载从节点的数量，采用树状复制结构，加入中间层从节点用来保护主节点。树状结构可以将网络开销交给位于中间层的从节点，降低了顶层主节点的压力，但也增加了运维的复杂性。

• 多主节点复制风暴：

• 问题：

• 多主节点复制风暴发生在多个主节点同时向相同的从节点发起全量复制的情况。这可能导致从节点同时接收多份不同数据源的数据，造成数据的不一致性。

• 解决方案：

• 包括避免在同一台机器上部署多个主节点，或者采用合适的复制策略确保从节点只接收来自一个主节点的数据。

5.4 其他优化

5.4.1 提升缓存命中率

缓存场景分析：

• 缓存适合读多写少的场景，否则命中率低，意义不大。
• 业务需求决定了对时效性的要求，直接影响缓存过期时间和更新策略。
• 时效性要求越低，越适合缓存。
• 相同key和请求次数下，缓存时间越长，命中率越高。
• 大多数互联网应用场景都适合使用缓存。

命中率说明：

• 命中：可以直接通过缓存获取到需要的数据。
• 不命中：无法直接通过缓存获取到想要的数据，需要再次查询数据库或者执行其他的操作。原因可能是由于缓存中根本不存在，或者缓存已经过期。

通常来讲，缓存的命中率越高则表示使用缓存的收益越高，应用的性能越好（响应时间越短、吞吐量越高），抗并发的能力越强。

• 缓存设计：

• 缓存粒度越小，命中率越高。单个对象缓存只需在该对象数据发生变化时更新或移除。

• 缓存集合时，任何对象数据变化都需要更新或移除缓存。

• 缓存容量和基础设施：

• 缓存容量有限，易引起失效和淘汰（常采用LRU算法）。

• 缓存技术选型需考虑容量规划和扩展性，分布式缓存易扩展。

• 其他因素：

• 缓存节点故障时需避免缓存失效，可采用一致性Hash算法或节点冗余实现高可用。

• 注意事项：

• 即便缓存时间较短，也能有效利用缓存的收益，特别是在高并发情况下。

缓存命中率的查看

127.0.0.1:6379> INFO
...
# Keyspace
db0:keys=1000,expires=1000,avg_ttl=86400
db1:keys=2000,expires=2000,avg_ttl=3600
...
keyspace_hits:1000000  总的命中次数
keyspace_misses:50000  总的miss次数
...
1
2
3
4
5
6
7
8
9

在redis中可以运行info命令查看redis服务的状态信息，

其中 keyspace_hits为总的命中次数，keyspace_misses为总的miss次数

命中率 =keyspace_hits/（keyspace_hits+keyspace_misses）。

命中率的优化方式

• 应用尽可能通过缓存获取数据，避免缓存失效。

• 需要在业务需求、缓存粒度、缓存策略、技术选型等方面进行权衡。

• 聚焦于高频访问、时效性要求不高的热点业务。

• 提高命中率的方法：

• 缓存预加载（预热）。

• 增加存储容量。

• 调整缓存粒度。

• 更新缓存。

5.4.2 避免阻塞

https://redis.io/docs/management/optimization/latency/

5.4.3 内存优化

• Redis实际内存消耗主要包括：键值对象、缓冲区内存、内存碎片。

• 通过调整maxmemory控制Redis最大可用内存。当内存使用超出时， 根据maxmemory-policy控制内存回收策略。

• 内存优化的思路包括：

• 精简键值对大小，键值字面量精简，使用高效二进制序列化工具。 、

• 数据优先使用整数，比字符串类型更节省空间。

• 优化字符串使用，避免预分配造成的内存浪费。

---

当你发现这些内容对你有帮助时，为了支持我的工作，不妨给一个免费的⭐Star，这将是对我最大的鼓励！感谢你的陪伴与支持！一起在技术的路上共同成长吧！点击链接：GitHub | Gitee