【Redis】Redis最佳实践/经验总结

【Redis】Redis最佳实践/经验总结

1. Redis键值设计

1.1 优雅的key结构

Redis中key的最佳实践约定：

1. 遵循格式-> [业务名称]:[数据名]:[id] -> 例：login:user:1
2. key的长度不超过44字节
3. 不包含特殊字符

这样设计的优点：

1. 可读性强
2. 避免key冲突
3. 方便管理
4. 更节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小

1.2 拒绝BigKey

BigKey通常是指占用内存空间比较大的key，例如包含大量元素的hash或zset，或者字符串类型的value比较大的key。例如：

• key本身的数据量过大：一个String类型的key，它的值为5MB。
• key中的成员数过多：一个ZSET类型的key，他的成员数量为10,000个。
• key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB。

推荐：

• 单个key的value值小于10KB
• 对于集合类型的key，建议元素数量小于1000

1.2.1 BigKey的危害

1. 网络阻塞
   • 对BigKey执行读请求时，少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢
2. 数据倾斜
   • BigKey所在的redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡
3. Redis阻塞
   • 对元素较多的hash，list，zset等做运算会耗时较久，使主线程被阻塞。
4. CPU压力
   • 对BigKey的数据序列化和反序列化都会导致CPU的使用率飙升，影响Redis实例和本机其他应用。

1.2.2 如何发现BigKey

1. redis–cli —bigkeys
   • 利用redis–cli提供的–bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key
2. scan扫描
   • 自己编程，利用scan扫描Redis中的所有key，利用strlen、hlen等命令判断key的长度（此处不建议使用MEMORY USAGE）
3. 第三方工具
   • 如 RESP客户端(类似navicat的可视化工具)分析RDB快照文件，全面分析内存使用情况
4. 网络监控
   • 自定义工具，监控进出Redis的网络数据，超出预警值时主动告警

1.2.3 如何删除BigKey

BigKey内存占用较多，即便时删除这样的key也需要耗费很长时间，导致Redis主线程阻塞，引发一系列问题。

1. Redis 3.0及以下版本
   • 如果是集合类型，则遍历BigKey的元素，先逐个删除子元素，最后删除BigKey
2. Redis 4.0以后
   • Redis在4.0后提供了异步删除的命令：unlink
   • 

1.3 恰当的数据类型

1.3.1 例1

如果要存储一个User对象，我们有三种存储方式：

1. json字符串:
   • 优点：实现简单
   • 缺点：数据耦合，不够灵活
2. 字段打散：
   • 优点：可以灵活访问对象任意字段
   • 缺点：占用空间大，没办法做统一控制
3. hash(推荐)：
   • 优点：底层使用 ziplist ，空间占用小，可以灵活访问对象的任意字段。
   • 缺点：代码相对复杂。

1.3.2 例2

假如有hash类型的key，其中有100万对字段和值，字段是自增id，这个key存在什么问题？如何优化？

方案一：使用hash存储100万对字段和值

存在问题：

1. hash的entry数量超过500时，会使用哈希表而不是ZipList，内存占用较多。
2. 可以通过hash–max–ziplist-entries配置entry上限。但是如果entry过多就会导致BigKey问题

这个方式存储的内存占用情况如下：

方案二：拆分为string类型

存在问题：

1. string结构底层没有太多内存优化，内存占用较多。
2. 想要批量获取这些数据比较麻烦。

内存占用情况如下：

方案三：拆分为小的hash，将id/100作为key，将id%100作为字段，这样每100个元素为hash

内存占用如下：

总结：方案三的内存占用最小，应该使用方案三的存储方式。

2. 批处理优化

2.1 Pipeline

2.1.1 单个命令的执行流程

一次命令的响应时间 = 1次往返的网络传输耗时 + 1次Redis执行命令耗时

2.1.2 N条命令依次执行

N次命令的响应时间 = N次往返的网络传输耗时 + N次Redis执行命令耗时

2.1.3 N条命令批量执行

N次命令的响应时间 = 1次往返的网络传输耗时 + N次Redis执行命令耗时

2.1.4 MSET和Pipeline

Redis提供了很多Mxxx这样的命令，可以实现批量插入数据，如：mset、hmset。

代码示例：

// 定义要设置的key-value对
Map<String, String> keyValueMap = new HashMap<>();
keyValueMap.put("key1", "value1");
keyValueMap.put("key2", "value2");

// 使用mset方法设置key-value对
redisTemplate.opsForValue().multiSet(keyValueMap);

MSET虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使用Pipeline功能：

List<Object> results = redisTemplate.executePipelined(new RedisCallback<Object>() {
  public Object doInRedis(RedisConnection connection) throws DataAccessException {
    connection.set("key1".getBytes(), "value1".getBytes());
    connection.get("key1".getBytes());
    connection.set("key2".getBytes(), "value2".getBytes());
    connection.get("key2".getBytes());
    return null;
  }
});

for (Object result : results) {
  System.out.println(result);
}

注意：

1. 批处理时不建议一次携带太多命令
2. Pipeline的多个命令之间不具备原子性

2.2 集群下的批处理

如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。

注：spring环境下默认使用第三种并行slot

3. 服务端优化

3.1 持久化配置

Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化要遵循以下建议：

1. 用来做缓存的Redis实例尽量不要开启持久化功能
2. 建议关闭RDB持久化功能，使用AOF持久化
3. 利用脚本定期在slave节点做RDB，实现数据备份
4. 设置合理的rewrite阈值，避免频繁的bgrewrite
5. 配置no–appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞

部署有关建议：

1. Redis实例的物理机要预存足够内存，应对fork和rewrite
2. 单个Redis实例内存上限不要太大，例如4G或8G.可以加快fork的速度，减少主从同步、数据迁移压力
3. 不要和CPU密集型应用部署在一起(例如ES)
4. 不要与高硬盘负载应用一起部署(数据库，消息队列)，单独部署得了。

3.2 慢查询

慢查询：在Redis执行中耗时超过某个阈值的命令，称为慢查询。慢读和慢写统称慢查询。

慢查询的阈值可以通过配置指定：

• lslowlog–log-slower–than：慢查询阈值，单位是微秒。默认是10000，建议1000

慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：

• lslowlog-max–len：慢查询日志（本质是一个队列）的长度。默认是128，建议1000

修改这两个配置可以使用 config set 命令：

查看慢查询日志列表：

• slowlog len：查询慢查询日志的长度
• slowlog get [n]：读取n条慢查询日志
• slowlog reset：清空慢查询列表

3.3 命令及安全配置

Redis会绑定在0.0.0.0:6379，这样将会将Redis服务暴露到公网上，而Redis如果没有做身份认证，会出现严重的安全漏洞.

漏洞重现方式：点击跳转

出现漏洞的核心原因：

1. Redis未设置密码
2. 利用了Redis的 config set 命令动态修改了Redis配置
3. 使用了Root账号权限启动Redis

为了避免这样的漏洞，这里给出一些建议：

1. Redis一定要设置密码
2. 禁止在线上使用这些命令：keys、flushall、flushdb、config set等命令。可以利用rename–command来给这些命令重命名达到禁用的目的
3. bind：限制网卡，禁止外网网卡访问
4. 开启防火墙
5. 不要使用Root账号启动Redis
6. 尽量不要使用默认端口启动(6379)

3.4 内存配置

当Redis内存不足时，可能导致Key频繁被删除、响应时间变长、QPS不稳定等问题。当内存使用率达到90%以上时就需要我们警惕，并快速定位到内存占用的原因。

Redis提供了一些命令可以查看Redis目前的内存分配状态：

• info memory

• memory xxx

3.4.1 内存缓冲区配置

内存缓冲区常见的有三种：

1. 复制缓冲区：主从复制的 repl_backlog_buf ,如果太小可能导致频繁的全量复制，影响性能。通过 repl_backlog_size 来设置，默认1mb
2. AOF缓冲区：AOF刷盘之前的缓存区域，AOF执行rewrite的缓冲区，无法设置容量上限
3. 客户端缓冲区：分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置，输出缓冲区可以设置

默认的配置如下：

4. 集群最佳实践

集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题：

1. 集群完整性问题(插槽)
2. 集群带宽问题(心跳机制)
3. 数据倾斜问题(BigKey)
4. 客户端性能问题
5. 命令的集群兼容性问题
6. lua和事务问题

4.1 集群完整性问题

在Redis的默认配置中，如果发现任意一个插槽不可用，则整个集群都会停止对外服务：

为了保证高可用特性，这里建议将 cluster-require-full-coverage 配置为false。

4.2 集群带宽问题

集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息至少包括：

• 插槽信息
• 集群状态信息

集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高。如果单机部署多个节点，那么带宽就会倍增。

解决途径：

1. 避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群。
2. 避免在单个物理机中运行太多redis实例
3. 配置合适的 cluster-node-timeout :节点心跳失败的超时时间
4. 提高带宽：可以通过添加更多的带宽或升级网络设备来提高Redis集群的带宽，以满足高并发场景下的需求。

4.3 数据倾斜问题

在 Redis 集群模式下，数据倾斜问题往往是由以下几个原因导致的：

1. 哈希槽分配不均：Redis 将所有的键映射到哈希槽中，然后将哈希槽分布到各个节点上。如果某些节点上的哈希槽分配过多，就会导致某些节点存储的数据比其他节点多很多。
2. 热点键集中在某些节点上：在 Redis 集群模式下，如果一些热点键被频繁地访问，它们很可能会被存储在同一个节点上，从而导致该节点的负载较大。
3. 新节点加入不平衡：当新节点加入 Redis 集群时，Redis 会自动将部分哈希槽分配到新节点上。如果新节点的加入不均衡，就会导致数据倾斜的问题。
4. 节点故障恢复不平衡：当某个节点故障时，Redis 会自动将该节点上的哈希槽重新分配给其他节点。如果故障节点的负载很高，重新分配的哈希槽就会集中到少数几个节点上，从而导致数据倾斜的问题。

综上所述，Redis 集群模式下的数据倾斜问题主要是由于节点间负载不平衡、热点键集中、新节点加入和节点故障恢复等原因导致的。为了解决数据倾斜的问题，需要采取一些措施来优化 Redis 集群的配置和管理。

以下是一些解决 Redis 集群数据倾斜问题的方法：

1. 调整哈希槽分配：Redis 将所有的键映射到哈希槽中，然后将哈希槽分布到各个节点上。如果某些节点上的哈希槽分配过多，可以通过手动调整哈希槽分配来解决数据倾斜的问题。可以使用 redis-cli 工具的 reshard 命令或者第三方工具 Redis-trib 来进行哈希槽的迁移。
2. 增加节点数量：增加节点数量可以扩容 Redis 集群，从而解决数据倾斜的问题。在增加节点时，Redis 会自动将部分哈希槽分配到新节点上。
3. 使用虚拟节点：虚拟节点是指将一个物理节点划分为多个虚拟节点，每个虚拟节点负责一部分哈希槽。这样可以避免某个物理节点上的哈希槽分配过多的情况发生。
4. 优化键的设计：Redis 集群中的数据倾斜往往是由于一些热点键导致的。可以优化热点键的设计，比如将一个热点键拆分成多个键或者使用哈希表来存储数据，从而减少某些节点上的负载。

4.4 客户端性能问题

在Redis集群下，客户端的性能问题通常包括以下几个方面：

1. 集群路由性能：Redis集群使用了一种基于哈希槽（hash slot）的分片策略来保证数据的高可用和扩展性。这意味着每个节点只负责部分数据，而客户端需要通过集群路由机制将请求发送到正确的节点上。如果集群路由机制的性能不足或者存在瓶颈，就会影响整个系统的吞吐量和延迟。
2. 集群节点负载均衡：在一个Redis集群中，节点的数量和配置可能是不同的，因此节点之间的负载也可能不平衡。如果某个节点的负载过高，就会导致该节点的性能下降，进而影响整个系统的性能表现。
3. 读写分离性能：在Redis集群中，通常会采用读写分离的方式来优化系统的性能。但是，如果读写分离的实现不够优秀，就可能会出现读写不一致、负载不均衡等问题，从而影响系统的性能和稳定性。
4. 网络通信性能：在Redis集群中，节点之间需要进行频繁的网络通信，以便共同维护整个集群的状态和数据。因此，网络通信性能也是影响Redis集群客户端性能的重要因素之一。

为了避免这些问题，可以采取如下措施：

1. 选择合适的客户端：不同的Redis客户端在处理集群路由、读写分离等方面可能存在差异，因此需要根据实际情况选择合适的客户端。
2. 使用负载均衡器：通过使用负载均衡器来解决节点负载不均衡的问题。
3. 分布式锁：使用分布式锁来保证不同客户端并发访问同一个资源时的数据一致性问题。
4. 预热缓存：在系统启动时预热缓存，避免大量请求同时涌入导致性能问题。
5. 合理配置Redis集群：设置合适的节点数量、哈希槽数量等配置参数，以达到最佳的性能和可用性。

4.5 命令的集群兼容性问题

在Redis集群中，有一些命令是不支持的或者在使用时需要注意兼容性问题。以下是一些常见的命令和它们的集群兼容性问题：

1. KEYS命令：在Redis集群中，KEYS命令会遍历整个集群，这可能会影响整个集群的性能。
2. MIGRATE命令：MIGRATE命令需要使用迁移槽来指定目标节点，但是在Redis 3.x版本之前，迁移槽并不是动态的，所以在使用MIGRATE命令时需要特别小心。
3. FLUSHDB和FLUSHALL命令：在Redis集群中，FLUSHDB和FLUSHALL只会清空当前节点的数据，而不是整个集群。
4. SORT命令：SORT命令在Redis集群中只能用于单个节点，因为它需要对整个集合进行排序，而不是分散到多个节点。
5. PUBLISH命令：由于Redis集群中没有中心节点，因此PUBLISH命令无法直接用于广播消息。取而代之的是，可以使用Lua脚本实现广播功能。

总之，在使用Redis集群时，需要了解每个命令的集群兼容性问题，并采取相应的措施来确保集群的稳定性和性能。

4.6 lua和事务问题

在 Redis 集群模式下，由于数据被分散存储在不同的节点中，因此对于使用 Lua 脚本或事务进行操作的情况，需要注意以下几点：

1. 使用 Lua 脚本：在 Redis 集群模式下，Lua 脚本可以在任何一个节点上执行。但是，如果脚本需要访问多个键，那么这些键可能分布在不同的节点上，这时候就需要在脚本中使用 redis.call 或 redis.pcall 函数来显式地指定要访问哪个节点的键。否则，如果脚本中涉及到的键分布在不同的节点上，Redis 就会抛出 MOVED 错误。
2. 使用事务：Redis 事务的实现依赖于单个节点上的原子性和一致性。在集群模式下，由于数据被分散存储，当一个事务需要访问多个键时，这些键可能分布在不同的节点上，这就导致了事务的原子性和一致性不能得到保证。因此，Redis 集群模式下不建议使用事务。

总的来说，当 Redis 集群模式下需要使用 Lua 脚本或事务时，需要特别注意键的分布情况，以确保操作的正确性。

4.3 集群还是主从

在考虑部署多台Redis实例时，应该根据具体业务需求和架构来选择合适的部署方案。

如果您需要高可用性，并且要求Redis集群中的每个节点都持有完整数据集并能够处理客户端请求，则可以选择Redis集群部署。Redis集群部署使用分片技术将数据分散到多个节点上，并为客户端提供无缝的访问接口。Redis集群还可以自动化地进行故障转移和负载均衡，因此可以提供更高的可用性和扩展性。

另一方面，如果您只需要一个主节点和一些从节点来处理读写操作，并且不需要高可用性，则可以选择主从部署。在这种情况下，主节点负责处理所有写操作和同步数据到从节点，而从节点只能用于读取操作。这种部署方案比较简单，并且可以满足大多数基本需求。但是，如果主节点出现故障，您需要手动切换到备用节点，因此可能会导致一些停机时间。

综上所述，在选择部署方案时，您应该考虑业务需求、数据量大小、可用性需求以及系统扩展性等因素。

注意：单体Redis（主从Redis）已经能达到万级别的QPS，并且也具备很强的高可用特性。如果主从能满足业务需求的情况下，尽量不搭建Redis集群。

代码007普通

打赏 收藏 海报 链接