2021-08-10redis基础

一、什么是redis

Redis是现在最受欢迎的NoSQL数据库之一，Redis是一个使用ANSI C编写的开源、包含多种数据结构、支持网络、基于内存、可选持久性的键值对存储数据库，其具备如下特性：

基于内存运行，性能高效

支持分布式，理论上可以无限扩展

key-value存储系统

开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API

相比于其他数据库类型，Redis具备的特点是：

C/S通讯模型

单进程单线程模型

丰富的数据类型

操作具有原子性

持久化

高并发读写

支持lua脚本

Redis 的应用场景包括：缓存系统（“热点”数据：高频读、低频写）、计数器、消息队列系统、排行榜、社交网络和实时系统。

二、redis数据结构

Redis提供的数据类型主要分为5种自有类型和一种自定义类型，这5种自有类型包括：String类型、哈希类型、列表类型、集合类型和顺序集合类型。

String类型：

它是一个二进制安全的字符串，意味着它不仅能够存储字符串、还能存储图片、视频等多种类型, 最大长度支持512M。

对每种数据类型，Redis都提供了丰富的操作命令，如：

SET key value

设置指定 key 的值

GET key

获取指定 key 的值。

GETRANGE key start end

返回 key 中字符串值的子字符

GETSET key value

将给定 key 的值设为 value ，并返回 key 的旧值(old value)。

GETBIT key offset

对 key 所储存的字符串值，获取指定偏移量上的位(bit)。

MGET key1 [key2..]

获取所有(一个或多个)给定 key 的值。

SETBIT key offset value

对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。

SETEX key seconds value

将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。

SETNX key value

只有在 key 不存在时设置 key 的值。

SETRANGE key offset value

用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。

STRLEN key

返回 key 所储存的字符串值的长度。

MSET key value [key value ...]

同时设置一个或多个 key-value 对。

MSETNX key value [key value ...]

同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。

PSETEX key milliseconds value

这个命令和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间，而不是像 SETEX 命令那样，以秒为单位。

INCR key

将 key 中储存的数字值增一。

INCRBY key increment

将 key 所储存的值加上给定的增量值（increment） 。

INCRBYFLOAT key increment

将 key 所储存的值加上给定的浮点增量值（increment） 。

DECR key

将 key 中储存的数字值减一。

DECRBY key decrement

key 所储存的值减去给定的减量值（decrement） 。

APPEND key value

如果 key 已经存在并且是一个字符串， APPEND 命令将指定的 value 追加到该 key 原来值（value）的末尾。

哈希类型：

该类型是由field和关联的value组成的map。其中，field和value都是字符串类型的。

Hash的操作命令如下：

HDEL key field1 [field2]

删除一个或多个哈希表字段

HEXISTS key field

查看哈希表 key 中，指定的字段是否存在。

HGET key field

获取存储在哈希表中指定字段的值。

HGETALL key

获取在哈希表中指定 key 的所有字段和值

HINCRBY key field increment

为哈希表 key 中的指定字段的整数值加上增量 increment 。

HINCRBYFLOAT key field increment

为哈希表 key 中的指定字段的浮点数值加上增量 increment 。

HKEYS key

获取所有哈希表中的字段

HLEN key

获取哈希表中字段的数量

HMGET key field1 [field2]

获取所有给定字段的值

HMSET key field1 value1 [field2 value2 ]

同时将多个 field-value (域-值)对设置到哈希表 key 中。

HSET key field value

将哈希表 key 中的字段 field 的值设为 value 。

HSETNX key field value

只有在字段 field 不存在时，设置哈希表字段的值。

HVALS key

获取哈希表中所有值。

HSCAN key cursor [MATCH pattern] [COUNT count]

迭代哈希表中的键值对。

列表类型：

该类型是一个插入顺序排序的字符串元素集合, 基于双链表实现。

List的操作命令如下：

BLPOP key1 [key2 ] timeout

移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

BRPOP key1 [key2 ] timeout

移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

BRPOPLPUSH source destination timeout

从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

LINDEX key index

通过索引获取列表中的元素

LINSERT key BEFORE|AFTER pivot value

在列表的元素前或者后插入元素

LLEN key

获取列表长度

LPOP key

移出并获取列表的第一个元素

LPUSH key value1 [value2]

将一个或多个值插入到列表头部

LPUSHX key value

将一个值插入到已存在的列表头部

LRANGE key start stop

获取列表指定范围内的元素

LREM key count value

移除列表元素

LSET key index value

通过索引设置列表元素的值

LTRIM key start stop

对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。

RPOP key

移除列表的最后一个元素，返回值为移除的元素。

RPOPLPUSH source destination

移除列表的最后一个元素，并将该元素添加到另一个列表并返回

RPUSH key value1 [value2]

在列表中添加一个或多个值

RPUSHX key value

为已存在的列表添加值

集合类型：

Set类型是一种无顺序集合, 它和List类型最大的区别是：集合中的元素没有顺序, 且元素是唯一的。

Set类型的底层是通过哈希表实现的，其操作命令为：

SADD key member1 [member2]

向集合添加一个或多个成员

SCARD key

获取集合的成员数

SDIFF key1 [key2]

返回第一个集合与其他集合之间的差异。

SDIFFSTORE destination key1 [key2]

返回给定所有集合的差集并存储在 destination 中

SINTER key1 [key2]

返回给定所有集合的交集

SINTERSTORE destination key1 [key2]

返回给定所有集合的交集并存储在 destination 中

SISMEMBER key member

判断 member 元素是否是集合 key 的成员

SMEMBERS key

返回集合中的所有成员

SMOVE source destination member

将 member 元素从 source 集合移动到 destination 集合

SPOP key

移除并返回集合中的一个随机元素

SRANDMEMBER key [count]

返回集合中一个或多个随机数

SREM key member1 [member2]

移除集合中一个或多个成员

SUNION key1 [key2]

返回所有给定集合的并集

SUNIONSTORE destination key1 [key2]

所有给定集合的并集存储在 destination 集合中

SSCAN key cursor [MATCH pattern] [COUNT count]

迭代集合中的元素

Set类型主要应用于：在某些场景，如社交场景中，通过交集、并集和差集运算，通过Set类型可以非常方便地查找共同好友、共同关注和共同偏好等社交关系。

顺序集合类型：

ZSet是一种有序集合类型，每个元素都会关联一个double类型的分数权值，通过这个权值来为集合中的成员进行从小到大的排序。与Set类型一样，其底层也是通过哈希表实现的。

ZSet命令：

ZADD key score1 member1 [score2 member2]

向有序集合添加一个或多个成员，或者更新已存在成员的分数

ZCARD key

获取有序集合的成员数

ZCOUNT key min max

计算在有序集合中指定区间分数的成员数

ZINCRBY key increment member

有序集合中对指定成员的分数加上增量 increment

ZINTERSTORE destination numkeys key [key ...]

计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 destination 中

ZLEXCOUNT key min max

在有序集合中计算指定字典区间内成员数量

ZRANGE key start stop [WITHSCORES]

通过索引区间返回有序集合指定区间内的成员

ZRANGEBYLEX key min max [LIMIT offset count]

通过字典区间返回有序集合的成员

ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT]

通过分数返回有序集合指定区间内的成员

ZRANK key member

返回有序集合中指定成员的索引

ZREM key member [member ...]

移除有序集合中的一个或多个成员

ZREMRANGEBYLEX key min max

移除有序集合中给定的字典区间的所有成员

ZREMRANGEBYRANK key start stop

移除有序集合中给定的排名区间的所有成员

ZREMRANGEBYSCORE key min max

移除有序集合中给定的分数区间的所有成员

ZREVRANGE key start stop [WITHSCORES]

返回有序集中指定区间内的成员，通过索引，分数从高到低

ZREVRANGEBYSCORE key max min [WITHSCORES]

返回有序集中指定分数区间内的成员，分数从高到低排序

ZREVRANK key member

返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序

ZSCORE key member

返回有序集中，成员的分数值

ZUNIONSTORE destination numkeys key [key ...]

计算给定的一个或多个有序集的并集，并存储在新的 key 中

ZSCAN key cursor [MATCH pattern] [COUNT count]

迭代有序集合中的元素（包括元素成员和元素分值）

三、redis基础特性

①为什么单线程Redis能那么快

日常写程序时，我们经常会听到一种说法：“使用多线程，可以增加系统吞吐率，或是可以增加系统扩展性。”的确，对于一个多线程的系统来说，在有合理的资源分配的情况下，可以增加系统中处理请求操作的资源实体，进而提升系统能够同时处理的请求数，即吞吐率。下面的左图是我们采用多线程时所期待的结果。但是，请你注意，通常情况下，在我们采用多线程后，如果没有良好的系统设计，实际得到的结果，其实是右图所展示的那样。我们刚开始增加线程数时，系统吞吐率会增加，但是，再进一步增加线程时，系统吞吐率就增长迟缓了，有时甚至还会出现下降的情况。

为什么会出现这种情况呢？一个关键的瓶颈在于，系统中通常会存在被多线程同时访问的共享资源，比如一个共享的数据结构。当有多个线程要修改这个共享资源时，为了保证共享资源的正确性，就需要有额外的机制进行保证，而这个额外的机制，就会带来额外的开销。拿 Redis 来说，Redis 有 List 的数据类型，并提供出队（LPOP）和入队（LPUSH）操作。假设 Redis 采用多线程设计，如下图所示，现在有两个线程 A 和 B，线程 A 对一个 List 做 LPUSH 操作，并对队列长度加 1。同时，线程 B 对该 List 执行 LPOP 操作，并对队列长度减 1。为了保证队列长度的正确性，Redis 需要让线程 A 和 B 的 LPUSH 和 LPOP 串行执行，这样一来，Redis 可以无误地记录它们对 List 长度的修改。否则，我们可能就会得到错误的长度结果。这就是多线程编程模式面临的共享资源的并发访问控制问题。

多线程并发访问Redis并发访问控制一直是多线程开发中的一个难点问题，如果没有精细的设计，比如说，只是简单地采用一个粗粒度互斥锁，就会出现不理想的结果：即使增加了线程，大部分线程也在等待获取访问共享资源的互斥锁，并行变串行，系统吞吐率并没有随着线程的增加而增加。而且，采用多线程开发一般会引入同步原语来保护共享资源的并发访问，这也会降低系统代码的易调试性和可维护性。为了避免这些问题，Redis 直接采用了单线程模式。

通常来说，单线程的处理能力要比多线程差很多，但是 Redis 却能使用单线程模型达到每秒数十万级别的处理能力，这是为什么呢？其实，这是 Redis 多方面设计选择的一个综合结果。一方面，Redis 的大部分操作在内存上完成，再加上它采用了高效的数据结构，例如哈希表和跳表，这是它实现高性能的一个重要原因。另一方面，就是 Redis 采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。接下来，我们就重点学习下多路复用机制。首先，我们要弄明白网络操作的基本 IO 模型和潜在的阻塞点。毕竟，Redis 采用单线程进行 IO，如果线程被阻塞了，就无法进行多路复用了。

基于多路复用的高性能 I/O 模型Linux 中的 IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。下图就是基于多路复用的 Redis IO 模型。图中的多个 FD 就是刚才所说的多个套接字。Redis 网络框架调用 epoll 机制，让内核监听这些套接字。此时，Redis 线程不会阻塞在某一个特定的监听或已连接套接字上，也就是说，不会阻塞在某一个特定的客户端请求处理上。正因为此，Redis 可以同时和多个客户端连接并处理请求，从而提升并发性。

基于多路复用的Redis高性能IO模型为了在请求到达时能通知到 Redis 线程，select/epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。那么，回调机制是怎么工作的呢？其实，select/epoll 一旦监测到 FD 上有请求到达时，就会触发相应的事件。

这些事件会被放进一个事件队列，Redis 单线程对该事件队列不断进行处理。这样一来，Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费。同时，Redis 在对事件队列中的事件进行处理时，会调用相应的处理函数，这就实现了基于事件的回调。因为 Redis 一直在对事件队列进行处理，所以能及时响应客户端请求，提升 Redis 的响应性能。

以连接请求和读数据请求为例，这两个请求分别对应 Accept 事件和 Read 事件，Redis 分别对这两个事件注册 accept 和 get 回调函数。当 Linux 内核监听到有连接请求或读数据请求时，就会触发 Accept 事件和 Read 事件，此时，内核就会回调 Redis 相应的 accept 和 get 函数进行处理。这就像病人去医院瞧病。在医生实际诊断前，每个病人（等同于请求）都需要先分诊、测体温、登记等。如果这些工作都由医生来完成，医生的工作效率就会很低。所以，医院都设置了分诊台，分诊台会一直处理这些诊断前的工作（类似于 Linux 内核监听请求），然后再转交给医生做实际诊断。这样即使一个医生（相当于 Redis 单线程），效率也能提升。

不过，需要注意的是，即使你的应用场景中部署了不同的操作系统，多路复用机制也是适用的。因为这个机制的实现有很多种，既有基于 Linux 系统下的 select 和 epoll 实现，也有基于 FreeBSD 的 kqueue 实现，以及基于 Solaris 的 evport 实现，这样，你可以根据 Redis 实际运行的操作系统，选择相应的多路复用实现。

②宕机了，Redis如何避免数据丢失

我们很容易想到的一个解决方案是，从后端数据库恢复这些数据，但这种方式存在两个问题：一是，需要频繁访问数据库，会给数据库带来巨大的压力；二是，这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。所以，对 Redis 来说，实现数据的持久化，避免从后端数据库中进行恢复，是至关重要的。目前，Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照。

AOF-说到日志，我们比较熟悉的是数据库的写前日志，也就是说，在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。不过，AOF 日志正好相反，它是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志，如下图所示：

传统数据库的日志，例如 redo log（重做日志），记录的是修改后的数据，而 AOF 里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的。

但是，为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。

而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。

除此之外，AOF 还有一个好处：它是在命令执行后才记录日志，所以不会阻塞当前的写操作。

不过，AOF 也有两个潜在的风险。首先，如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时 Redis 是用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果 Redis 是直接用作数据库的话，此时，因为命令没有记入日志，所以就无法用日志进行恢复了。其次，AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。仔细分析的话，你就会发现，这两个风险都是和 AOF 写回磁盘的时机相关的。这也就意味着，如果我们能够控制一个写命令执行完后 AOF 日志写回磁盘的时机，这两个风险就解除了。

RDB-对 Redis 来说，它实现类似照片记录效果的方式，就是把某一时刻的状态以文件的形式写到磁盘上，也就是快照。这样一来，即使宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为 RDB 文件，其中，RDB 就是 Redis DataBase 的缩写。和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。听起来好像很不错，但内存快照也并不是最优选项。

内存快照也有它的局限性。它拍的是一张内存的“大合影”，不可避免地会耗时耗力。虽然，Redis 设计了 bgsave 和写时复制方式，尽可能减少了内存快照对正常读写的影响，但是，频繁快照仍然是不太能接受的。而混合使用 RDB 和 AOF，正好可以取两者之长，避两者之短，以较小的性能开销保证数据可靠性和性能。最后，关于 AOF 和 RDB 的选择问题，建议：数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；如果允许分钟级别的数据丢失，可以只使用 RDB；如果只用 AOF，优先使用 everysec 的配置选项（每秒写回），因为它在可靠性和性能之间取了一个平衡。

③哨兵机制

Redis 的哨兵机制自动完成了以下三大功能，从而实现了主从库的自动切换，可以降低 Redis 集群的运维开销：

监控主库运行状态，并判断主库是否客观下线；

在主库客观下线后，选取新主库；

选出新主库后，通知从库和客户端。为了降低误判率，在实际应用时，哨兵机制通常采用多实例的方式进行部署，多个哨兵实例通过“少数服从多数”的原则，来判断主库是否客观下线。

一般来说，我们可以部署三个哨兵，如果有两个哨兵认定主库“主观下线”，就可以开始切换过程。当然，如果你希望进一步提升判断准确率，也可以再适当增加哨兵个数，比如说使用五个哨兵。但是，使用多个哨兵实例来降低误判率，其实相当于组成了一个哨兵集群。

④ Redis的下一步：基于NVM内存的实践

这几年新型非易失存储（Non-Volatile Memory，NVM）器件发展得非常快。NVM 器件具有容量大、性能快、能持久化保存数据的特性，这些刚好就是 Redis 追求的目标。同时，NVM 器件像 DRAM 一样，可以让软件以字节粒度进行寻址访问，所以，在实际应用中，NVM 可以作为内存来使用，我们称为 NVM 内存。你肯定会想到，Redis 作为内存键值数据库，如果能和 NVM 内存结合起来使用，就可以充分享受到这些特性。

Redis 发展的下一步，就可以基于 NVM 内存来实现大容量实例，或者是实现快速持久化数据和恢复。我们先来学习下 NVM 内存的特性，以及软件使用 NVM 内存的两种模式。在不同的使用模式下，软件能用到的 NVM 特性是不一样的，所以，掌握这部分知识，可以帮助我们更好地根据业务需求选择适合的模式。

NVM 内存的特性与使用模式

Redis 是基于 DRAM 内存的键值数据库，而跟传统的 DRAM 内存相比，NVM 有三个显著的特点。

首先，NVM 内存最大的优势是可以直接持久化保存数据。也就是说，数据保存在 NVM 内存上后，即使发生了宕机或是掉电，数据仍然存在 NVM 内存上。但如果数据是保存在 DRAM 上，那么，掉电后数据就会丢失。

其次，NVM 内存的访问速度接近 DRAM 的速度。实际测试过 NVM 内存的访问速度，结果显示，它的读延迟大约是 200~300ns，而写延迟大约是 100ns。在读写带宽方面，单根 NVM 内存条的写带宽大约是 1~2GB/s，而读带宽约是 5~6GB/s。当软件系统把数据保存在 NVM 内存上时，系统仍然可以快速地存取数据。最后，NVM 内存的容量很大。这是因为，NVM 器件的密度大，单个 NVM 的存储单元可以保存更多数据。例如，单根 NVM 内存条就能达到 128GB 的容量，最大可以达到 512GB，而单根 DRAM 内存条通常是 16GB 或 32GB。所以，我们可以很轻松地用 NVM 内存构建 TB 级别的内存。

总结来说，NVM 内存的特点可以用三句话概括：能持久化保存数据；读写速度和 DRAM 接近；容量大。

现在，业界已经有了实际的 NVM 内存产品，就是 Intel 在 2019 年 4 月份时推出的 Optane AEP 内存条（简称 AEP 内存）。我们在应用 AEP 内存时，需要注意的是，AEP 内存给软件提供了两种使用模式，分别对应着使用了 NVM 的容量大和持久化保存数据两个特性，我们来学习下这两种模式。

这款 NVM 内存产品给软件提供了两种使用模式，分别是 Memory 模式和 App Direct 模式。在 Memory 模式时，Redis 可以利用 NVM 容量大的特点，实现大容量实例，保存更多数据。在使用 App Direct 模式时，Redis 可以直接在持久化内存上进行数据读写，在这种情况下，Redis 不用再使用 RDB 或 AOF 文件了，数据在机器掉电后也不会丢失。而且，实例可以直接使用持久化内存上的数据进行恢复，恢复速度特别快。

⑤java使用redis

连接到 redis 服务

import redis.clients.jedis.Jedis;

public class RedisJava {

    public static void main(String[] args) {

    //连接本地的 Redis 服务

    Jedis jedis = new Jedis("localhost");

    // 如果 Redis 服务设置了密码，需要下面这行，没有就不需要

    // jedis.auth("123456");

    System.out.println("连接成功");

    //查看服务是否运行

    System.out.println("服务正在运行: "+jedis.ping());

    }

}

连接成功

服务正在运行: PONG

Redis Java String(字符串) 实例

import redis.clients.jedis.Jedis;

public class RedisStringJava {

    public static void main(String[] args) {

    //连接本地的 Redis 服务

    Jedis jedis = new Jedis("localhost");

    System.out.println("连接成功");

    //设置 redis 字符串数据

    jedis.set("runoobkey", "www.runoob.com");

    // 获取存储的数据并输出

    System.out.println("redis 存储的字符串为: "+ jedis.get("runoobkey"));

    }

}

连接成功

redis 存储的字符串为: www.runoob.com

Redis Java List(列表) 实例

import java.util.List;

import redis.clients.jedis.Jedis;

public class RedisListJava {

    public static void main(String[] args) {

        //连接本地的 Redis 服务

        Jedis jedis = new Jedis("localhost");

        System.out.println("连接成功");

        //存储数据到列表中

        jedis.lpush("site-list", "Runoob");

        jedis.lpush("site-list", "Google");

        jedis.lpush("site-list", "Taobao");

        // 获取存储的数据并输出

        List list = jedis.lrange("site-list", 0 ,2);

        for(int i=0; i

        System.out.println("列表项为: "+list.get(i));

        }

    }

}

连接成功

列表项为:Taobao

列表项为:Google

列表项为: Runoob

四、从学习Redis到向Redis学习

①向 Redis 单线程模式学习，专心致志做重要的事Redis 的最大特点是快，这是 Redis 在设计之初就设立的目标。

而能成为某项技术的高手、某个技术方向的大牛，通常是我们给自己设立的目标。Redis 实现“快”这个目标的关键机制就是单线程架构。单线程架构就给我们提供了一个很好的做事方式：专心致志做一件事，把事情做到极致，是达到目标的核心要素。在 Redis 的设计中，主线程专门负责处理请求，而且会以最快的速度完成。对于其他会阻碍这个目标的事情（例如生成快照、删除、AOF 重写等），就想办法用异步的方式，或者是用后台线程来完成。

②具备可扩展能力。向 Redis 集群学习可扩展能力在应用 Redis 时，我们会遇到数据量增长、负载压力增大的情况，但 Redis 都能轻松应对，这就是得益于它的可扩展集群机制：当数据容量增加时，Redis 会增加实例实现扩容；当读压力增加时，Redis 会增加从库，来分担压力。Redis 的新特性在持续推出，新的存储硬件也在快速地发展，这些最新技术的发展，很可能就会改变 Redis 的关键机制和使用方法。所以，想要应对复杂的场景变化，我们也要像 Redis 集群一样，具备可扩展能力。毕竟，技术的迭代速度如此之快，各种需求也越来越复杂。如果只是专注于学习现有的技术知识，或者是基于目前的场景去苦心钻研，很可能会被时代快速地抛弃。只有紧跟技术发展的步伐，具备解决各种突发问题的能力，才能成为真正的技术大牛。