redis

[keyfall]

# 安装
apt-get install redis-server

#启动
redis-server

#进入redis
redis-cli

redis.conf位置在/etc/redis文件夹中

redis配置

#查询一个
config get config_setting_name

#查询全部
config get *

#编辑配置
config set config_setting_name new_value

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

string 是 redis 最基本的类型,redis 的 string 可以包含任何数据,比如jpg图片或者序列化的对象,最大能存储 512MB

hash 是一个键值(key=>value)对集合,value是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。每个 hash 可以存储 2的32次方 -1 键值对（40多亿）

hset可以设置一个也可以设置多个
hset key field value [field value ...]

hget只能取一个key中的field
hget key field

hmset可以设置一个也可以设置多个
hmset key field value [field value ...]

hmget可以取一个也可以取多个key field
hmget key field [fidld...]

hgetall可以直接通过key取出所有的键值对
hgetall key

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。列表最多可存储 2的32次方 - 1

Set 是 string 类型的无序集合，通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。集合中最大的成员数为 2的32次方 - 1

[keyfall]

redis-cli命令总结 redis键命令

#删除
del key

#设置过期（秒）
expire key

#查找符合pattern的keys(pattern为*，就是查找所有)
keys pattern

#移除过期时间
persist key

#返回key剩余时间
ttl key

#移动key到指定db（只能移动一个）
move key db

复制一个库的所有key到另一个库

[keyfall]

redis 字符串

[keyfall]

[keyfall]

[keyfall]

HyperLogLog

HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身

[keyfall]

[keyfall]

redis 事务 Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证： a.批量操作在发送 EXEC 命令前被放入队列缓存。 b.收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。 c.在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

redis 127.0.0.1:6379> MULTI
OK

redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED

redis 127.0.0.1:6379> GET book-name
QUEUED

redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis 127.0.0.1:6379> SMEMBERS tag
QUEUED

redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

[keyfall]

redis脚本 Redis 脚本使用 Lua 解释器来执行脚本。

redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second

1) "key1"
2) "key2"
3) "first"
4) "second"

numkeys意思是后面key的数量

[keyfall]

AOF文件 如图可知，redis-cli每次执行命令，服务器运行后都放进一个AOF文件中，那么时间一长，AOF中肯定有很多的重复命令或者可以合并的命令，BGREWRITEAOF命令可以使AOF文件进行重写，把里面的命令进行优化，进而节省空间，加快服务器恢复时间

bgsave命令 用于在后台异步保存当前数据库的数据到磁盘。 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。 save命令就会令其他的请求阻塞，直到完成备份才继续请求完成

config rewrite命令 因为config set 命令用于进行服务器的设置更改，但是不会重写redis.conf文件，这时进行config rewrite命令，那么就会把更改后的设置写进redis.conf

dbsize命令 返回当前数据库的key的数量

flushall命令 删除所有数据库的所有key

flushdb命令 删除当前数据库的所有key

monitor命令 把cli变成一个服务器接收装置，如果有其他的cli进行命令操作，那么就会显示出来

SLAVEOF host port 如果当前服务器是某个主服务器的从服务器，那么执行命令后，会把旧数据集删除，对新主服务器进行同步 执行slaveof no one,会使当前服务器关闭复制功能，从从服务器变成主服务器，同步的数据集不会丢掉，如果在主服务器坏掉时，可以使用slaveof no one使得当前服务器变成主服务器，从而实现无间断运行。

sync 用于同步主从服务器

[keyfall]

redis数据备份与恢复

save和bgsave进行当前数据库备份,bgsave是后台进行（fork一个子进程去执行备份数据库） 备份会在redis安装目录下创建一个dump.rdb文件 恢复只需要把dump.rdb文件放到redis安装目录下，并启动服务即可 config get dir 进行redis安装目录查看

redis性能测试

redis-benchmark [option] [option value] 命令在redis目录下执行，不是客户端中

[keyfall]

客户端连接

redis-server --maxclients 100000 服务启动时设置最大连接数为100000

Redis 通过监听一个 TCP 端口或者 Unix socket 的方式来接收来自客户端的连接，当一个连接建立后，Redis 内部会进行以下一些操作：

首先，客户端 socket 会被设置为非阻塞模式，因为 Redis 在网络事件处理上采用的是非阻塞多路复用模型。 然后为这个 socket 设置 TCP_NODELAY 属性，禁用 Nagle 算法 然后创建一个可读的文件事件用于监听这个客户端 socket 的数据发送

[keyfall]

redis分区

范围分区：映射一定范围的对象到特定redis实例中 比如id从0到10000保存到实例R0

哈希分区:用hash函数(比如crc32 hash函数)将key转化为一个数字，然后对数字进行取模，将其转化为0-3的数字，对应映射到r0到r3的实例中。

[keyfall]

redis是啥 redis 是 C 语言开发的一个开源的（遵从 BSD 协议）高性能键值对（key-value）的内存数据库，可以用作数据库、缓存、消息中间件等,是一种no-sql数据库。

性能优秀，数据在内存中，读写速度非常快，支持并发 10W QPS。单进程单线程，是线程安全的，采用 IO 多路复用机制。丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。支持数据持久化。可以将内存中数据保存在磁盘中，重启时加载。主从复制，哨兵，高可用。可以用作分布式锁。可以作为消息中间件使用，支持发布订阅。

[keyfall]

缓存雪崩，缓存穿透，缓存击穿 缓存雪崩就是缓存同一时间全部失效，这时有大量请求进入，全部由数据库处理，数据库扛不住，重启，又有新的大量请求，接着还是崩了。 解决方法：处理缓存雪崩简单，在批量往 Redis 存数据的时候，把每个 Key 的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效。

缓存穿透是指缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。 解决方法：在接口层增加校验，比如用户鉴权，参数做校验，不合法的校验直接 return，比如 id 做基础校验，id<=0 直接拦截。Redis 里还有一个高级用法布隆过滤器，利用高效的数据结构和算法快速判断出你这个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。

缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。 解决方法：设置热点数据永不过期，或者加上互斥锁

[keyfall]

redis单线程还快 Redis 完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度是 O(1)。 数据结构简单，对数据操作也简单。 采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的 CPU 切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。 使用多路复用 IO 模型，非阻塞 IO。

[keyfall]

Redis 和 Memcached 的区别 Memcache 会把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis 有部分数据存在硬盘上，这样能保证数据的持久性。 数据支持类型上：Memcache 对数据类型的支持简单，只支持简单的 key-value，，而 Redis 支持五种数据类型。 使用底层模型不同：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis 直接自己构建了 VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。 Value 的大小：Redis 可以达到 1GB，而 Memcache 只有 1MB。

[keyfall]

redis淘汰策略 Redis 4.0 加入了 LFU（least frequency use）淘汰策略，包括 volatile-lfu 和 allkeys-lfu，通过统计访问频率，将访问频率最少，即最不经常使用的 KV 淘汰。

[keyfall]

redis持久化 Redis 为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。 redis持久化策略： RDB：快照形式是直接把内存中的数据保存到一个 dump 的文件中，定时保存，保存策略。 AOF：把所有的对 Redis 的服务器进行修改的命令都存到一个文件里，命令的集合。Redis 默认是快照 RDB 的持久化方式。

默认 Redis 是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件 dump.rdb。当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处是可以 copy-on-write。

RDB 的优点是：非常适用备份，你可以在最近的 24 小时内，每小时备份一次，并且在每个月的每一天也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适合灾难恢复。 RDB 的缺点是：如果你需要在服务器故障时不丢失数据(一点数据都不丢失)，那么RDB不合适你。

使用 AOF 做持久化，每一个写命令都通过 write 函数追加到 appendonly.aof 中。AOF 可以做到全程持久化，只需要在配置中开启 appendonly yes。这样 Redis 每执行一个修改数据的命令，都会把它添加到 AOF 文件中，当 Redis 重启时，将会读取 AOF 文件进行重放，恢复到 Redis 关闭前的最后时刻。 AOF 的优点是会让 Redis 变得非常耐久。可以设置不同的 Fsync 策略，AOF的默认策略是每秒钟 Fsync 一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。 AOF的缺点是对于相同的数据集来说，AOF 的文件体积通常要大于 RDB 文件的体积。根据所使用的 Fsync 策略，AOF 的速度可能会慢于 RDB。

主从复制 从节点执行 slaveof[masterIP][masterPort]，保存主节点信息。从节点中的定时任务发现主节点信息，建立和主节点的 Socket 连接。从节点发送 Ping 信号，主节点返回 Pong，两边能互相通信。连接建立后，主节点将所有数据发送给从节点（数据同步）。主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

runId：每个 Redis 节点启动都会生成唯一的 uuid，每次 Redis 重启后，runId 都会发生变化。offset：主节点和从节点都各自维护自己的主从复制偏移量 offset，当主节点有写入命令时，offset=offset+命令的字节长度。 从节点在收到主节点发送的命令后，也会增加自己的 offset，并把自己的 offset 发送给主节点。这样，主节点同时保存自己的 offset 和从节点的 offset，通过对比 offset 来判断主从节点数据是否一致。 repl_backlog_size：保存在主节点上的一个固定长度的先进先出队列，默认大小是 1MB。

主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。 从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。 主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。

全量复制和部分复制的过程 从节点发送 psync ? -1 命令（因为第一次发送，不知道主节点的 runId，所以为?，因为是第一次复制，所以 offset=-1）。主节点发现从节点是第一次复制，返回 FULLRESYNC {runId} {offset}，runId 是主节点的 runId，offset 是主节点目前的 offset。从节点接收主节点信息后，保存到 info 中。主节点在发送 FULLRESYNC 后，启动 bgsave 命令，生成 RDB 文件（数据持久化）。主节点发送 RDB 文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。从节点清理自己的数据库数据。从节点加载 RDB 文件，将数据保存到自己的数据库中。如果从节点开启了 AOF，从节点会异步重写 AOF 文件。

关于部分复制有以下几点说明： ①部分复制主要是 Redis 针对全量复制的过高开销做出的一种优化措施，使用 psync[runId][offset] 命令实现。

当从节点正在复制主节点时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区将这部分数据直接发送给从节点。 这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据。

②主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内的复制积压缓冲区依然可以保存最近一段时间的写命令数据。

③当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行 ID。因此会把它们当做 psync 参数发送给主节点，要求进行部分复制。

④主节点接收到 psync 命令后首先核对参数 runId 是否与自身一致，如果一致，说明之前复制的是当前主节点。

之后根据参数 offset 在复制积压缓冲区中查找，如果 offset 之后的数据存在，则对从节点发送+COUTINUE 命令，表示可以进行部分复制。因为缓冲区大小固定，若发生缓冲溢出，则进行全量复制。

⑤主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

哨兵 主从复制可能出现的问题： 一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。 主节点的写能力受到单机的限制。 主节点的存储能力受到单机的限制。 原生复制的弊端在早期的版本中也会比较突出，比如：Redis 复制中断后，从节点会发起 psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

使用哨兵解决

Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。Redis Sentinel 最小配置是一主一从。Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器。 可进行以下4个任务： 监控：不断检查主服务器和从服务器是否正常运行。 通知：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。 自动故障转移：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。 配置提供者：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。

哨兵工作原理： 每个 Sentinel 节点都需要定期执行以下任务：每个 Sentinel 以每秒一次的频率，向它所知的主服务器、从服务器以及其他的 Sentinel 实例发送一个 PING 命令。 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为主观下线。那么正在监视这个服务器的所有 Sentinel 节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。 如果有足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。

一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。
当一个主服务器被标记为客观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率，会从 10 秒一次改为每秒一次。

Sentinel 和其他 Sentinel 协商客观下线的主节点的状态，如果处于 SDOWN 状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。

当没有足够数量的 Sentinel 同意主服务器下线时，主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时，主服务器的主观下线状态就会被移除。

[keyfall]

redis文档

[keyfall]

redis主从模式例子

建立3个文件夹zhu,6380,6381 里面分别放入redis.conf

修改6380中的redis.conf

pidfile /var/run/redis6380.pid
//配置端口信息
port 6380
//配置master服务器
slaveof localhost 6379
//修改生成的rdb的文件名
dbfilename dump6380.rdb
//rdb文件的路径 可以不修改   本文章只是演示
dir ./
//屏蔽aof
appendonly no
appendfilename "appendonly.aof" 

配置6381中的redis.conf

#save 900 1
#save 300 10
#save 60 10000

//配置pid文件
pidfile /var/run/redis6381.pid
//配置端口信息
port 6381
//配置master服务器
slaveof localhost 6379
//不生成aof文件
appendonly no
appendfilename "appendonly.aof"

配置zhu中的redis.conf

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
//标志从服务器只能读操作
slave-read-only yes

把redis.conf中的cluster-enabled设置成no cluster是集群，我反正打开就报错，可能需要多台机子或者6个子节点开启才不报错吧

分别打开 redis-server ./redis.conf

打开后，查看redis是否运行，出现4个，3个后面端口对应就行 ps -aux |grep redis

进client检查，进入主服务器 redis-cli 设置，查看 set a 100 keys *

进入6380,ip是127.0.0.1就不用设置，默认了 redis-cli -p 6380

查看 keys * 设置就会报错，6381的也是如此

[keyfall]

cluster命令与解释

[keyfall]

redis集群例子

使用解压缩版，不使用安装版

启动redis,需要进入对应redis文件夹里面，然后调用redis-server,你从外面直接./redis/redis-server，这样启动不了 后面接的redis.conf倒是不限制是否在本文件夹下

上面的问题适用于复制的redis，直接解压的redis可以不进入redis文件夹去调用redis-server,只能调用对应文件夹下的redis.conf

其他版本没试过，请先确定版本，不过照着下面一步一步走，就没问题

集群至少需要6个节点(3主3从)

[root@localhost redis-3.2.0]# wget http://download.redis.io/releases/redis-3.2.0.tar.gz
[root@localhost redis-3.2.0]# tar xzf redis-3.2.0.tar.gz  
[root@localhost redis-3.2.0]# cd redis-3.2.0  
[root@localhost redis-3.2.0]# make  
[root@localhost redis-3.2.0]# make install PREFIX=/usr/local/redis-cluster

在redis-cluster下 修改bin文件夹为redis01,复制redis-3.2.0文件夹下的redis.conf到redis01

修改redis.conf：

daemonize yes 
port 7001 
cluster-enabled yes 
cluster-config-file nodes.conf 
cluster-node-timeout 15000
appendonly yes 

复制5份redis01,修改端口7002-7006 安装redis-trib（集群管理工具）所需的ruby脚本 复制redis-trib.rb到redis-cluster [root@localhost redis-cluster]# cp /usr/local/redis/redis-3.2.0/src/redis-trib.rb ./

安装ruby环境 apt-get install ruby apt-get install rubygems

下载运行依赖ruby包

$ gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/
$ gem sources -l
https://gems.ruby-china.com
# 确保只有 gems.ruby-china.com

下载包 安装 gem install -l redis-4.1.2.gem

启动节点 进入每个redis,启动

cd redis01  
./redis-server redis.conf  
cd ..  
cd redis02  
./redis-server redis.conf  
cd ..  
cd redis03  
./redis-server redis.conf  
cd ..  
cd redis04  
./redis-server redis.conf  
cd ..  
cd redis05  
./redis-server redis.conf  
cd ..  
cd redis06  
./redis-server redis.conf  
cd ..

权限启动 chmod 777 start-all.sh ./start-all.sh

使用redis-trib创建集群 ./redis-trib.rb create --replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006

redis-trib其他方法讲解

[keyfall]

redis缓存

redis快的原因： 单线程 内存操作 非阻塞I/O多路复用，redis命令进行存储,redis-client在操作的时候，会产生具有不同事件类型的socket。在服务端，有一段I/0多路复用程序，将其置入队列之中。然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中。 I/O多路复用机制，redis还提供了select、epoll、evport、kqueue等多路复用函数库。

redis删除机制+内存淘汰策略 redis采用定期删除+惰性删除 定期删除就是每隔100ms检查随机检查key，key过期了就删除 惰性删除是每次getkey的时候，如果key过期了，那么就删除

内存淘汰策略就是对定期和惰性删除的补全，redis会根据设置使用不同的方法 maxmemory-policy volatile-lru 1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。 2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用，目前项目在用这种。 3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。 4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐 5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐 6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐

缓存击穿和缓存雪崩

对热门的数据，可以采用redis互斥锁 缓存穿透，即黑客故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。 解决方案: (一)利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试 (二)采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。 (三)提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。 缓存雪崩，即缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。 解决方案: (一)给缓存的失效时间，加上一个随机值，避免集体失效。 (二)使用互斥锁，但是该方案吞吐量明显下降了。 (三)双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点 I 从缓存A读数据库，有则直接返回 II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。 III 更新线程同时更新缓存A和缓存B。

[keyfall]

redis配置总结

[keyfall]

redis哨兵模式详解