本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍。之后在性能调优等方面进行更深入的介绍和指导。
概述
Redis 是一个开源的,基于内存的结构化数据存储媒介,可以作为数据库、缓存服务或消息服务使用。
Redis 支持多种数据结构,包括字符串、哈希表、链表、集合、有序集合、位图、Hyperloglogs 等。
Redis 具备 LRU 淘汰、事务实现、以及不同级别的硬盘持久化等能力,并且支持副本集和通过 Redis Sentinel 实现的高可用方案,同时还支持通过 Redis Cluster 实现的数据自动分片能力。
Redis 的主要功能都基于单线程模型实现,也就是说 Redis 使用一个线程来服务所有的客户端请求,同时 Redis 采用了非阻塞式 IO,并精细地优化各种命令的算法时间复杂度,这些信息意味着:
本节中将介绍 Redis 支持的主要数据结构,以及相关的常用 Redis 命令。本节只对 Redis 命令进行扼要的介绍,且只列出了较常用的命令。如果想要了解完整的 Redis 命令集,或了解某个命令的详细使用方法,请参考官方文档:https://redis.io/commands
Redis 采用 Key-Value 型的基本数据结构,任何二进制序列都可以作为 Redis 的 Key 使用(例如普通的字符串或一张 JPEG 图片) 关于 Key 的一些注意事项:
不要使用过长的 Key。例如使用一个 1024 字节的 key 就不是一个好主意,不仅会消耗更多的内存,还会导致查找的效率降低
Key 短到缺失了可读性也是不好的,例如”u1000flw” 比起”user:1000:followers” 来说,节省了寥寥的存储空间,却引发了可读性和可维护性上的麻烦
最好使用统一的规范来设计 Key,比如”object-type:id:attr”,以这一规范设计出的 Key 可能是”user:1000” 或”comment:1234:reply-to”
Redis 允许的最大 Key 长度是 512MB(对 Value 的长度限制也是 512MB)
String 是 Redis 的基础数据类型,Redis 没有 Int、Float、Boolean 等数据类型的概念,所有的基本类型在 Redis 中都以 String 体现。
与 String 相关的常用命令:
上文提到过,Redis 的基本数据类型只有 String,但 Redis 可以把 String 作为整型或浮点型数字来使用,主要体现在 INCR、DECR 类的命令上:
INCR/DECR 系列命令要求操作的 value 类型为 String,并可以转换为 64 位带符号的整型数字,否则会返回错误。
也就是说,进行 INCR/DECR 系列命令的 value,必须在 [-2^63 ~ 2^63 - 1] 范围内。
前文提到过,Redis 采用单线程模型,天然是线程安全的,这使得 INCR/DECR 命令可以非常便利的实现高并发场景下的精确控制。
Redis 的 List 是链表型的数据结构,可以使用 LPUSH/RPUSH/LPOP/RPOP 等命令在 List 的两端执行插入元素和弹出元素的操作。虽然 List 也支持在特定 index 上插入和读取元素的功能,但其时间复杂度较高(O(N)),应小心使用。
与 List 相关的常用命令:
应谨慎使用的 List 相关命令:
由于 Redis 的 List 是链表结构的,上述的三个命令的算法效率较低,需要对 List 进行遍历,命令的耗时无法预估,在 List 长度大的情况下耗时会明显增加,应谨慎使用。
换句话说,Redis 的 List 实际是设计来用于实现队列,而不是用于实现类似 ArrayList 这样的列表的。如果你不是想要实现一个双端出入的队列,那么请尽量不要使用 Redis 的 List 数据结构。
为了更好支持队列的特性,Redis 还提供了一系列阻塞式的操作命令,如 BLPOP/BRPOP 等,能够实现类似于 BlockingQueue 的能力,即在 List 为空时,阻塞该连接,直到 List 中有对象可以出队时再返回。针对阻塞类的命令,此处不做详细探讨,请参考官方文档(https://redis.io/topics/data-types-intro) 中”Blocking operations on lists” 一节。
Hash 即哈希表,Redis 的 Hash 和传统的哈希表一样,是一种 field-value 型的数据结构,可以理解成将 HashMap 搬入 Redis。
Hash 非常适合用于表现对象类型的数据,用 Hash 中的 field 对应对象的 field 即可。
Hash 的优点包括:
与 Hash 相关的常用命令:
应谨慎使用的 Hash 相关命令:
上述三个命令都会对 Hash 进行完整遍历,Hash 中的 field 数量与命令的耗时线性相关,对于尺寸不可预知的 Hash,应严格避免使用上面三个命令,而改为使用 HSCAN 命令进行游标式的遍历,具体请见 https://redis.io/commands/scan
Redis Set 是无序的,不可重复的 String 集合。
与 Set 相关的常用命令:
慎用的 Set 相关命令:
上述几个命令涉及的计算量大,应谨慎使用,特别是在参与计算的 Set 尺寸不可知的情况下,应严格避免使用。可以考虑通过 SSCAN 命令遍历获取相关 Set 的全部 member(具体请见 https://redis.io/commands/scan ),如果需要做并集 / 交集 / 差集计算,可以在客户端进行,或在不服务实时查询请求的 Slave 上进行。
Redis Sorted Set 是有序的、不可重复的 String 集合。Sorted Set 中的每个元素都需要指派一个分数 (score),Sorted Set 会根据 score 对元素进行升序排序。如果多个 member 拥有相同的 score,则以字典序进行升序排序。
Sorted Set 非常适合用于实现排名。
Sorted Set 的主要命令:
慎用的 Sorted Set 相关命令:
上述几个命令,应尽量避免传递 [0 -1] 或 [-inf +inf] 这样的参数,来对 Sorted Set 做一次性的完整遍历,特别是在 Sorted Set 的尺寸不可预知的情况下。可以通过 ZSCAN 命令来进行游标式的遍历(具体请见 https://redis.io/commands/scan ),或通过 LIMIT 参数来限制返回 member 的数量(适用于 ZRANGEBYSCORE 和 ZREVRANGEBYSCORE 命令),以实现游标式的遍历。
Redis 的这两种数据结构相较之前的并不常用,在本文中只做简要介绍,如想要详细了解这两种数据结构与其相关的命令,请参考官方文档 https://redis.io/topics/data-types-intro 中的相关章节
Bitmap 在 Redis 中不是一种实际的数据类型,而是一种将 String 作为 Bitmap 使用的方法。可以理解为将 String 转换为 bit 数组。使用 Bitmap 来存储 true/false 类型的简单数据极为节省空间。
HyperLogLogs 是一种主要用于数量统计的数据结构,它和 Set 类似,维护一个不可重复的 String 集合,但是 HyperLogLogs 并不维护具体的 member 内容,只维护 member 的个数。也就是说,HyperLogLogs 只能用于计算一个集合中不重复的元素数量,所以它比 Set 要节省很多内存空间。
尽管 Redis 是一个非常快速的内存数据存储媒介,也并不代表 Redis 不会产生性能问题。 前文中提到过,Redis 采用单线程模型,所有的命令都是由一个线程串行执行的,所以当某个命令执行耗时较长时,会拖慢其后的所有命令,这使得 Redis 对每个任务的执行效率更加敏感。
针对 Redis 的性能优化,主要从下面几个层面入手:
Redis 绝大多数读写命令的时间复杂度都在 O(1) 到 O(N) 之间,在文本和官方文档中均对每个命令的时间复杂度有说明。
通常来说,O(1) 的命令是安全的,O(N) 命令在使用时需要注意,如果 N 的数量级不可预知,则应避免使用。例如对一个 field 数未知的 Hash 数据执行 HGETALL/HKEYS/HVALS 命令,通常来说这些命令执行的很快,但如果这个 Hash 中的 field 数量极多,耗时就会成倍增长。
又如使用 SUNION 对两个 Set 执行 Union 操作,或使用 SORT 对 List/Set 执行排序操作等时,都应该严加注意。
避免在使用这些 O(N) 命令时发生问题主要有几个办法:
Redis 提供了 SCAN 命令,可以对 Redis 中存储的所有 key 进行游标式的遍历,避免使用 KEYS 命令带来的性能问题。同时还有 SSCAN/HSCAN/ZSCAN 等命令,分别用于对 Set/Hash/Sorted Set 中的元素进行游标式遍历。SCAN 类命令的使用请参考官方文档:https://redis.io/commands/scan
Redis 提供了 Slow Log 功能,可以自动记录耗时较长的命令。相关的配置参数有两个:
slowlog-log-slower-than xxxms #执行时间慢于xxx毫秒的命令计入Slow Logslowlog-max-len xxx #Slow Log的长度,即最大纪录多少条Slow Log
使用 SLOWLOG GET [number] 命令,可以输出最近进入 Slow Log 的 number 条命令。 使用 SLOWLOG RESET 命令,可以重置 Slow Log
Redis 的数据持久化工作本身就会带来延迟,需要根据数据的安全级别和性能要求制定合理的持久化策略:
Redis 在 fork 子进程时需要将内存分页表拷贝至子进程,以占用了 24GB 内存的 Redis 实例为例,共需要拷贝 24GB / 4kB * 8 = 48MB 的数据。在使用单 Xeon 2.27Ghz 的物理机上,这一 fork 操作耗时 216ms。 可以通过 INFO 命令返回的 latest_fork_usec 字段查看上一次 fork 操作的耗时(微秒)
当 Linux 将 Redis 所用的内存分页移至 swap 空间时,将会阻塞 Redis 进程,导致 Redis 出现不正常的延迟。Swap 通常在物理内存不足或一些进程在进行大量 I/O 操作时发生,应尽可能避免上述两种情况的出现。
/proc//smaps 文件中会保存进程的 swap 记录,通过查看这个文件,能够判断 Redis 的延迟是否由 Swap 产生。如果这个文件中记录了较大的 Swap size,则说明延迟很有可能是 Swap 造成的。
当同一秒内有大量 key 过期时,也会引发 Redis 的延迟。在使用时应尽量将 key 的失效时间错开。
Redis 的主从复制能力可以实现一主多从的多节点架构,在这一架构下,主节点接收所有写请求,并将数据同步给多个从节点。
在这一基础上,我们可以让从节点提供对实时性要求不高的读请求服务,以减小主节点的压力。
尤其是针对一些使用了长耗时命令的统计类任务,完全可以指定在一个或多个从节点上执行,避免这些长耗时命令影响其他请求的响应。
关于读写分离的具体说明,请参见后续章节
Redis 支持一主多从的主从复制架构。一个 Master 实例负责处理所有的写请求,Master 将写操作同步至所有 Slave。
借助 Redis 的主从复制,可以实现读写分离和高可用:
启用主从复制非常简单,只需要配置多个 Redis 实例,在作为 Slave 的 Redis 实例中配置:
slaveof 192.168.1.1 6379 #指定Master的IP和端口
当 Slave 启动后,会从 Master 进行一次冷启动数据同步,由 Master 触发 BGSAVE 生成 RDB 文件推送给 Slave 进行导入,导入完成后 Master 再将增量数据通过 Redis Protocol 同步给 Slave。之后主从之间的数据便一直以 Redis Protocol 进行同步
Redis 的主从复制功能本身只是做数据同步,并不提供监控和自动 failover 能力,要通过主从复制功能来实现 Redis 的高可用,还需要引入一个组件:Redis Sentinel
Redis Sentinel 是 Redis 官方开发的监控组件,可以监控 Redis 实例的状态,通过 Master 节点自动发现 Slave 节点,并在监测到 Master 节点失效时选举出一个新的 Master,并向所有 Redis 实例推送新的主从配置。
Redis Sentinel 需要至少部署 3 个实例才能形成选举关系。
关键配置:
sentinel monitor mymaster 127.0.0.1 6379 2 #Master实例的IP、端口,以及选举需要的赞成票数sentinel down-after-milliseconds mymaster 60000 #多长时间没有响应视为Master失效sentinel failover-timeout mymaster 180000 #两次failover尝试间的间隔时长sentinel parallel-syncs mymaster 1 #如果有多个Slave,可以通过此配置指定同时从新Master进行数据同步的Slave数,避免所有Slave同时进行数据同步导致查询服务也不可用
另外需要注意的是,Redis Sentinel 实现的自动 failover 不是在同一个 IP 和端口上完成的,也就是说自动 failover 产生的新 Master 提供服务的 IP 和端口与之前的 Master 是不一样的,所以要实现 HA,还要求客户端必须支持 Sentinel,能够与 Sentinel 交互获得新 Master 的信息才行。
为何要做集群分片:
当上述两个问题出现时,就必须要对 Redis 进行分片了。
Redis 的分片方案有很多种,例如很多 Redis 的客户端都自行实现了分片功能,也有向 Twemproxy 这样的以代理方式实现的 Redis 分片方案。然而首选的方案还应该是 Redis 官方在 3.0 版本中推出的 Redis Cluster 分片方案。
本文不会对 Redis Cluster 的具体安装和部署细节进行介绍,重点介绍 Redis Cluster 带来的好处与弊端。
其中第三点是基于主从复制来实现的,Redis Cluster 的每个数据分片都采用了主从复制的结构,原理和前文所述的主从复制完全一致,唯一的区别是省去了 Redis Sentinel 这一额外的组件,由 Redis Cluster 负责进行一个分片内部的节点监控和自动 failover。
Redis Cluster 中共有 16384 个 hash slot,Redis 会计算每个 key 的 CRC16,将结果与 16384 取模,来决定该 key 存储在哪一个 hash slot 中,同时需要指定 Redis Cluster 中每个数据分片负责的 Slot 数。Slot 的分配在任何时间点都可以进行重新分配。
客户端在对 key 进行读写操作时,可以连接 Cluster 中的任意一个分片,如果操作的 key 不在此分片负责的 Slot 范围内,Redis Cluster 会自动将请求重定向到正确的分片上。
在基础的分片原则上,Redis 还支持 hash tags 功能,以 hash tags 要求的格式明明的 key,将会确保进入同一个 Slot 中。例如:{uiv}user:1000 和 {uiv}user:1001 拥有同样的 hash tag {uiv},会保存在同一个 Slot 中。
使用 Redis Cluster 时,pipelining、事务和 LUA Script 功能涉及的 key 必须在同一个数据分片上,否则将会返回错误。如要在 Redis Cluster 中使用上述功能,就必须通过 hash tags 来确保一个 pipeline 或一个事务中操作的所有 key 都位于同一个 Slot 中。
有一些客户端(如 Redisson)实现了集群化的 pipelining 操作,可以自动将一个 pipeline 里的命令按 key 所在的分片进行分组,分别发到不同的分片上执行。但是 Redis 不支持跨分片的事务,事务和 LUA Script 还是必须遵循所有 key 在一个分片上的规则要求。
在设计软件架构时,要如何在主从复制和集群分片两种部署方案中取舍呢?
从各个方面看,Redis Cluster 都是优于主从复制的方案
那是不是代表 Redis Cluster 永远是优于主从复制的选择呢?
并不是。
软件架构永远不是越复杂越好,复杂的架构在带来显著好处的同时,一定也会带来相应的弊端。采用 Redis Cluster 的弊端包括:
所以说,在主从复制和集群分片两个方案中做出选择时,应该从应用软件的功能特性、数据和访问量级、未来发展规划等方面综合考虑,只在确实有必要引入数据分片时再使用 Redis Cluster。 下面是一些建议:
需要在 Redis 中存储的数据有多大?未来 2 年内可能发展为多大?这些数据是否都需要长期保存?是否可以使用 LRU 算法进行非热点数据的淘汰?综合考虑前面几个因素,评估出 Redis 需要使用的物理内存。
用于部署 Redis 的主机物理内存有多大?有多少可以分配给 Redis 使用?对比 (1) 中的内存需求评估,是否足够用?
Redis 面临的并发写压力会有多大?在不使用 pipelining 时,Redis 的写性能可以超过 10 万次 / 秒(更多的 benchmark 可以参考 https://redis.io/topics/benchmarks )
在使用 Redis 时,是否会使用到 pipelining 和事务功能?使用的场景多不多? 综合上面几点考虑,如果单台主机的可用物理内存完全足以支撑对 Redis 的容量需求,且 Redis 面临的并发写压力距离 Benchmark 值还尚有距离,建议采用主从复制的架构,可以省去很多不必要的麻烦。同时,如果应用中大量使用 pipelining 和事务,也建议尽可能选择主从复制架构,可以减少设计和开发时的复杂度。