redis关键知识点总结

redis中的值不仅可以是字符串，而且还可以是具体的数据结构，这不仅能便于在许多应用场景的开发，同事也能够提高开发效率。
redis主要提供5中数据结构：字符串、哈希、列表、集合、有序集合。同时在字符串的基础之上演变出了位图（Bitmaps）和HyperLogLog两种神奇的“数据结构”，并且随着LBS（Location Based Service，基于位置服务）的不断发展，Redis3.2版本中加入有关GEO（地理信息定位）的功能。

（3）丰富的功能

键过期功能，可以用来实现缓存
发布订阅功能，可以用来实现消息系统
支持Lua脚本功能，可以利用Lua创造出新的Redis命令
提供了简单的事务功能，能在一定程度上保证事务特性
提供了流水线（Pipeline）功能，这样客户端能将一批命令一次性传到redis，减少网络的开销

（4）简单稳定

redis的源码很少，早期版本的代码只有2万行左右，3.0版本以后由于添加了集群特性，代码增至5万行左右；
redis使用单线程模型，这样不仅使得Redis服务端处理模型变得简单，而且也使得客户端开发变得简单；
redis不需要依赖于操作系统中的类库（例如Memcache需要依赖libevent这样的系统类库）。Redis自己实现了事件处理的相关功能。

（5）客户端语言多

Redis提供了简单的TCP通信协议，很多编程语言可以很方便地接入到Redis，支持Redis的客户端语言也非常多，几乎涵盖了主流的编程语言，例如Java、PHP、Python、C、C++、Nodejs等。

（6）支持数据持久化

（7）主从复制

Redis提供了复制功能，实现了多个相同数据的Redis副本，复制功能是分布式Redis的基础。

（8）高可用和分布式

Redis从2.8版本正式提供了高可用实现Redis Sentinel，它能够保证Redis节点的故障发现和故障自动转移。Redis从3.0版本正式提供了分布式实现Redis Cluster，它是Redis真正的分布式实现，提供了高可用、读写和容量的扩展性。

3、redis应用场景

（1）缓存

缓存机制几乎在所有的大型网站都有使用，合理地使用缓存不仅可以加快数据的访问速度，而且能够有效地降低后端数据源的压力。Redis提供了键值过期时间设置，并且也提供了灵活控制最大内存和内存溢出后的淘汰策略。

（2）排行榜系统

排行榜系统几乎存在于所有的网站，例如按照热度排名的排行榜，按照发布时间的排行榜，按照各种复杂维度计算出的排行榜，Redis提供了列表和有序集合数据结构，合理地使用这些数据结构可以很方便地构建各种排行榜系统。

（3）计数器应用

计数器在网站中的作用至关重要，例如视频网站有播放数、电商网站有浏览数，为了保证数据的实时性，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。

（4）消息队列系统

消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。

（5）分布式Session

3、使用redis的缺点

(1)缓存和数据库双写一致性问题

(2)缓存雪崩问题

(3)缓存击穿问题

(4)缓存的并发竞争问题

4、redis 和 Memcached 的区别

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

5、redis版本特性

2.8：主从断线重连后采取部分复制（Psync），Redis Sentinel Stable

3.0：Redis Cluster

3.2：GEO

4.0：提供模块系统方便第三方拓展

非阻塞del和flushall/flushdb功能

RDB和AOF混合持久化模式

Redis Cluster 兼容NAT和Docker

二、数据结构与过期淘汰策略

1、数据类型

（1）基本数据类型

字符串（String）

这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

列表（List）

使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适---取行情信息。就也是个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。

哈希（Hash）

这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

集合（Set）

因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。

另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

有序集合（sortedset【zset】）

sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。

（2）其它数据类型

位图类型（bitMap）
地理位置类型（geo）
HyperLogLog
Redis5.0新增一种：stream类型

2、缓存过期和淘汰策略

（1）缓存过期

Redis长期使用，key会不断增加，Redis作为缓存使用，物理内存也会满内存与硬盘交换（swap）虚拟内存，频繁IO 性能急剧下降

不设置场景

Redis的key是固定的，不会增加
Redis作为DB使用，保证数据的完整性，不能淘汰，可以做集群，横向扩展
缓存淘汰策略：禁止驱逐（默认）

设置场景

Redis是作为缓存使用，不断增加Key

maxmemory ：默认为0 不限制

maxmemory配置

在redis.conf中

maxmemory 1024mb

命令：获得maxmemory数

CONFIG GET maxmemory

设置maxmemory后，当趋近maxmemory时，通过缓存淘汰策略，从内存中删除对象

（2）淘汰策略

Redis的数据删除有定时删除、惰性删除和主动删除三种方式。

Redis目前采用惰性删除+主动删除的方式。

定时删除:

在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作。

惰性删除

在key被访问时如果发现它已经失效，那么就删除它。调用expireIfNeeded函数，该函数的意义是：读取数据之前先检查一下它有没有失效，如果失效了就删除它。

int expireIfNeeded(redisDb *db, robj *key) {
//获取主键的失效时间
long long when = getExpire(db,key);
//假如失效时间为负数，说明该主键未设置失效时间（失效时间默认为-1），直接返回0
if (when < 0) return 0;
//假如Redis服务器正在从RDB文件中加载数据，暂时不进行失效主键的删除，直接返回0
if (server.loading) return 0;
...
//如果以上条件都不满足，就将主键的失效时间与当前时间进行对比，如果发现指定的主键
//还未失效就直接返回0
if (mstime() <= when) return 0;
//如果发现主键确实已经失效了，那么首先更新关于失效主键的统计个数，然后将该主键失
//效的信息进行广播，最后将该主键从数据库中删除
server.stat_expiredkeys++;
propagateExpire(db,key);
return dbDelete(db,key);
}

主动删除

在redis.conf文件中可以配置主动删除策略,默认是no-enviction（不删除）

maxmemory-policy allkeys-lru

LRU

LRU (Least recently used) 最近最少使用，算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。最常见的实现是使用一个链表保存缓存数据，详细算法实现如下：

新数据插入到链表头部；
每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
当链表满的时候，将链表尾部的数据丢弃。
在Java中可以使用LinkHashMap（哈希链表）去实现LRU

Redis的LRU 数据淘汰机制

在服务器配置中保存了 lru 计数器 server.lrulock，会定时（redis 定时程序 serverCorn()）更新， server.lrulock 的值是根据 server.unixtime 计算出来的。

另外，从 struct redisObject 中可以发现，每一个 redis 对象都会设置相应的 lru。可以想象的是，每一次访问数据的时候，会更新 redisObject.lru。

LRU 数据淘汰机制是这样的：在数据集中随机挑选几个键值对，取出其中 lru 最大的键值对淘汰。不可能遍历key 用当前时间-最近访问越大说明访问间隔时间越长

volatile-lru:从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

allkeys-lru:从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

LFU

LFU (Least frequently used) 最不经常使用，如果一个数据在最近一段时间内使用次数很少，那么在将来一段时间内被使用的可能性也很小。

volatile-lfu:在设置了过期时间的key中使用LFU算法淘汰key

allkeys-lfu:在所有的key中使用LFU算法淘汰数据

random

随机

volatile-random 从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-random 从数据集（server.db[i].dict）中任意选择数据淘汰

ttl

volatile-ttl

从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰 redis 数据集数据结构中保存了键值对过期时间的表，即 redisDb.expires。 TTL 数据淘汰机制：从过期时间的表中随机挑选几个键值对，取出其中 ttl 最小的键值对淘汰

noenviction

禁止驱逐数据，不删除默认

（3）缓存淘汰策略的选择

allkeys-lru ：在不确定时一般采用策略。
volatile-lru ：比allkeys-lru性能差存 : 过期时间
allkeys-random ：希望请求符合平均分布(每个元素以相同的概率被访问)
自己控制：volatile-ttl 缓存穿透

三、持久化

1、为什么要持久化

Redis是内存数据库，宕机后数据会消失。
Redis重启后快速恢复数据，要提供持久化机制
注意：Redis持久化不保证数据的完整性。

2、RDB（快照）持久化：保存某个时间点的全量数据快照

（1）RDB执行流程（原理）

Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（aof文件重写命令）的子进程，如果在执行则bgsave命令直接返回。
父进程执行fork（调用OS函数复制主进程）操作创建子进程，这个过程中父进程是阻塞的，Redis 不能执行来自客户端的任何命令。
父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令。
子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换。（RDB始终完整）
子进程发送信号给父进程表示完成，父进程更新统计信息。
父进程fork子进程后，继续工作。

（2）RDB的优缺点

优点：RDB是二进制压缩文件，占用空间小，便于传输（传给slaver）主进程fork子进程，可以最大化Redis性能，主进程不能太大，复制过程中主进程阻塞

缺点：不保证数据完整性，会丢失最后一次快照以后更改的所有数据

2、AOF（Append -Only - File）持久化：保存写状态默认是关闭的

AOF（append only file）是Redis的另一种持久化方式。Redis默认情况下是不开启的。

开启AOF持久化后 Redis 将所有对数据库进行过写入的命令（及其参数）（RESP）记录到 AOF 文件，以此达到记录数据库状态的目的，这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。

AOF会记录过程，RDB只管结果

（1）AOF持久化配置

配置 redis.conf

# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename appendonly.aof

（2）AOF原理

AOF文件中存储的是redis的命令，同步命令到 AOF 文件的整个过程可以分为三个阶段：

命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。

缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。

文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中

命令传播 当一个 Redis 客户端需要执行命令时，它通过网络连接，将协议文本发送给 Redis 服务器。服务器在接到客户端的请求之后，它会根据协议文本的内容，选择适当的命令函数，并将各个参数从字符串文本转换为 Redis 字符串对象（ StringObject ）。每当命令函数成功执行之后，命令参数都会被传播到 AOF 程序。

缓存追加 当命令被传播到 AOF 程序之后，程序会根据命令以及命令的参数，将命令从字符串对象转换回原来的协议文本。协议文本生成之后，它会被追加到 redis.h/redisServer 结构的 aof_buf 末尾。 redisServer 结构维持着 Redis 服务器的状态， aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本（RESP）。

文件写入和保存 每当服务器常规任务函数被执行、或者事件处理器被执行时， aof.c/flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作： WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。 SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

AOF 保存模式

Redis 目前支持三种 AOF 保存模式，它们分别是： AOF_FSYNC_NO ：不保存。 AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。（默认） AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。（不推荐）

不保存在这种模式下，每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行，但 SAVE 会被略过。 # 可以通过修改redis.conf配置文件中的appendonly参数开启 appendonly yes # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。 dir ./ # 默认的文件名是appendonly.aof，可以通过appendfilename参数修改 appendfilename appendonly.aof 在这种模式下， SAVE 只会在以下任意一种情况中被执行： Redis 被关闭 AOF 功能被关闭系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。

每一秒钟保存一次 在这种模式中， SAVE 原则上每隔一秒钟就会执行一次，因为 SAVE 操作是由后台子线程（fork）调用的，所以它不会引起服务器主进程阻塞。

每执行一个命令保存一次 在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。

对于三种 AOF 保存模式，它们对服务器主进程的阻塞情况如下：

（3）AOF优缺点

优点：可读性较高，适合保存增量数据，数据不易丢失

缺点：文件体积大，恢复时间长

3、RDB-AOF 混合持久化方式

在Redis 4.0 以后RDB-AOF 混合持久化方式默认配置来使用

4、应用场景

内存数据库 rdb+aof 数据不容易丢

缓存服务器 rdb 性能高

不建议只使用 aof (性能差)

在数据还原时有rdb+aof 则还原aof，因为RDB会造成文件的丢失，AOF相对数据要完整。只有rdb，则还原rdb

总结

追求高性能：都不开 redis宕机从数据源恢复

字典库：不驱逐，保证数据完整性

用作DB 不能主从数据量小

做缓存较高性能：开rdb

一般不开aof

四、分布式高可用方案

1、主从复制

Redis支持主从复制功能，可以通过执行slaveof（Redis5以后改成replicaof）或者在配置文件中设置 slaveof(Redis5以后改成replicaof)来开启复制功能。

（1）主从复制架构与特点

主对外从对内，主可写从不可写
主挂了，从不可为主

（2）主从配置

主Redis配置:无需特殊配置

从Redis配置：修改从服务器上的 redis.conf 文件

# slaveof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。
replicaof 127.0.0.1 6379

（3）主从作用

读写分离：一主多从，主从同步主负责写，从负责读提升Redis的性能和吞吐量主从的数据一致性问题

数据容灾：从机是主机的备份主机宕机，从机可读不可写默认情况下主机宕机后，从机不可为主机利用哨兵可以实现主从切换，做到高可用

（4）原理与实现

1）复制流程

①保存主节点信息

当客户端向从服务器发送slaveof(replicaof) 主机地址（127.0.0.1）端口（6379）时：从服务器将主机ip（127.0.0.1）和端口（6379）保存到redisServer的masterhost和masterport中。

Struct redisServer{
char *masterhost;//主服务器ip
int masterport;//主服务器端口
} ;

从服务器将向发送SLAVEOF命令的客户端返回OK，表示复制指令已经被接收，而实际上复制工作是在 OK返回之后进行。

②建立socket连接

slaver与master建立socket连接，slaver关联文件事件处理器，该处理器接收RDB文件（全量复制）、接收Master传播来的写命令（增量复制）

主服务器accept从服务器Socket连接后，创建相应的客户端状态。相当于从服务器是主服务器的Client 端。

③发送ping命令

Slaver向Master发送ping命令

1、检测socket的读写状态 Struct redisServer{ char *masterhost;//主服务器ip int masterport;//主服务器端口 } ;

2、检测Master能否正常处理

Master的响应：

1、发送“pong” , 说明正常

2、返回错误，说明Master不正常

3、timeout，说明网络超时

④权限验证

主从正常连接后，进行权限验证

主未设置密码（requirepass=“”），从也不用设置密码（masterauth=“”）

主设置密码(requirepass!=""),从需要设置密码(masterauth=主的requirepass的值) 或者从通过auth命令向主发送密码

⑤发送端口信息

在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号。

⑥同步数据

Redis 2.8之后分为全量同步和增量同步，具体的后面详细讲解。

⑦命令传播

当同步数据完成后，主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。

2）同步数据集

Redis 2.8以前使用SYNC命令同步复制，Redis 2.8之后采用PSYNC命令替代SYNC

旧版本：Redis 2.8以前实现方式

Redis的同步功能分为同步(sync)和命令传播(command propagate)。

①同步操作：

通过从服务器发送到SYNC命令给主服务器
主服务器生成RDB文件并发送给从服务器，同时发送保存所有写命令给从服务器
从服务器清空之前数据并执行解释RDB文件
保持数据一致（还需要命令传播过程才能保持一致）

②命令传播操作：

同步操作完成后，主服务器执行写命令，该命令发送给从服务器并执行，使主从保存一致。

缺陷：没有全量同步和增量同步的概念，从服务器在同步时，会清空所有数据。主从服务器断线后重复制，主服务器会重新生成RDB文件和重新记录缓冲区的所有命令，并全量同步到从服务器上。

新版：Redis 2.8以后实现方式

在Redis 2.8之后使用PSYNC命令，具备完整重同步和部分重同步模式。
Redis 的主从同步，分为全量同步和增量同步。
只有从机第一次连接上主机是全量同步。
断线重连有可能触发全量同步也有可能是增量同步（ master 判断 runid 是否一致）。

除此之外的情况都是增量同步。

全量同步

Redis 的全量同步过程主要分三个阶段：

同步快照阶段： Master 创建并发送快照RDB给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的新的写命令存储到缓冲区。

同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。

同步增量阶段： Master 向 Slave 同步写操作命令。

增量同步

Redis增量同步主要指Slave完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

3）心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送命令：

replconf ack <replication_offset>
#ack :应答
#replication_offset：从服务器当前的复制偏移量

主要作用有三个：

检测主从的连接状态 检测主从服务器的网络连接状态通过向主服务器发送INFO replication命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。

辅助实现min-slaves Redis可以通过配置防止主服务器在不安全的情况下执行写命令 min-slaves-to-write 3 （min-replicas-to-write 3 ） min-slaves-max-lag 10 （min-replicas-max-lag 10）上面的配置表示：从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10 秒时，主服务器将拒绝执行写命令。这里的延迟值就是上面INFOreplication命令的lag值。

检测命令丢失 如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送REPLCONF ACK命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。（补发）网络不断增量同步：网断了，再次连接时

2、哨兵模式（Redis Sentinel）

哨兵（sentinel）是Redis的高可用性(High Availability)的解决方案：由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。

（1）哨兵模式概述

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

（2）部署方案

①搭建配置

在一台机器上采用伪分布式的方式部署。（生产环境应该是多台机器）

根据上面的部署方案搭建如下：

Redis-Master ：127.0.0.1 6379 采用安装的方式，正常安装和配置

#1 安装redis5.0
mkdir redis-master
make install PREFIX=/var/redis-ms/redis-master
cp /var/redis-5.0.5/redis.conf /var/redis-ms/redis-master/bin
#2 修改redis.conf
# 将`daemonize`由`no`改为`yes`
daemonize yes
# 默认绑定的是回环地址，默认不能被其他机器访问
# bind 127.0.0.1
# 是否开启保护模式，由yes该为no
protected-mode no

Redis-Slaver1：127.0.0.1 6380

#安装redis-slaver1
mkdir redis-slaver1
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-slaver1
#修改配置文件
vim /var/redis-ms/redis-slaver1/redis.conf
port 6380
replicaof 127.0.0.1 6379

Redis-Slaver2：127.0.0.1 6381

#安装redis-slaver2
mkdir redis-slaver2
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-slaver2
#修改配置文件
vim /var/redis-ms/redis-slaver2/redis.conf
port 6381
replicaof 127.0.0.1 6379

Redis-Sentinel1:127.0.0.1 26379

#安装redis-sentinel1
mkdir redis-sentinel1
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-sentinel1
#拷贝sentinel.conf 配置文件并修改
cp /var/redis-5.0.5/sentinel.conf /var/redis-ms/redis-sentinel1
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 将`daemonize`由`no`改为`yes`
daemonize yes

# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提
供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒，改成3秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 3000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master
那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，
slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

Redis-Sentinel2:127.0.0.1 26380

#安装redis-sentinel2
mkdir redis-sentinel2
cp -r /var/redis-ms/redis-sentinel1/* /var/redis-ms/redis-sentinel2
#修改sentinel.conf
vim /var/redis-ms/redis-sentinel2/sentinel.conf
port 26380

Redis-Sentinel3:127.0.0.1 26381

#安装redis-sentinel3
mkdir redis-sentinel3
cp -r /var/redis-ms/redis-sentinel1/* /var/redis-ms/redis-sentinel3
#修改sentinel.conf
vim /var/redis-ms/redis-sentinel3/sentinel.conf
port 26381

配置好后依次执行 redis-master、redis-slaver1、redis-slaver2、redis-sentinel1、redis-sentinel2、redis-sentinel3

#启动redis-master和redis-slaver
在redis-master目录下 ./redis-server redis.conf
在redis-slaver1目录下 ./redis-server redis.conf
在redis-slaver2目录下 ./redis-server redis.conf
#启动redis-sentinel
在redis-sentinel1目录下 ./redis-sentinel sentinel.conf
在redis-sentinel2目录下 ./redis-sentinel sentinel.conf
在redis-sentinel3目录下 ./redis-sentinel sentinel.conf
#查看启动状态
[root@localhost bin]# ps -ef |grep redis
root 3602 1 0 01:33 ? 00:00:00 ./redis-server *:6379
root 3647 1 0 01:37 ? 00:00:00 ./redis-server *:6380
root 3717 1 0 01:40 ? 00:00:00 ./redis-server *:6381
root 3760 1 0 01:42 ? 00:00:00 ./redis-sentinel *:26379
[sentinel]
root 3765 1 0 01:42 ? 00:00:00 ./redis-sentinel *:26380
[sentinel]
root 3770 1 0 01:42 ? 00:00:00 ./redis-sentinel *:26381
[sentinel]
root 3783 2261 0 01:42 pts/0 00:00:00 grep --color=auto redis

（3）启动流程剖析

启动并初始化Sentinel

获取主服务器信息

获取从服务器信息

向主服务器和从服务器发送消息(以订阅的方式)

接收来自主服务器和从服务器的频道信息

检测主观下线状态

检查客观下线状态

选举Leader Sentinel

当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作。

Raft：Raft协议是用来解决分布式系统一致性问题的协议。Raft协议描述的节点共有三种状态：Leader, Follower, Candidate。term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。

选举流程：

Raft采用心跳机制触发Leader选举，系统启动后，全部节点初始化为Follower，term为0。节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份。节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。一旦转化为Candidate，该节点立即开始下面几件事情：

增加自己的term。
启动一个新的定时器。
给自己投一票。
向所有其他节点发送RequestVote，并等待其他节点的回复。

如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送 AppendEntries，告知自己成为了Leader。

每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己， Follower会投给第一个收到RequestVote的节点。

Raft协议的定时器采取随机超时时间，这是选举Leader的关键。在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

Sentinel的leader选举流程

某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
如果该Sentinel还没投过票，那么它就成为Candidate。
Sentinel需要完成几件事情：

更新故障转移状态为start
当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。
给自己投一票（leader、leader_epoch）

当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）
Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。

故障转移

当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤：
它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ；
当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。
Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即， Master 主服务器的 redis.conf 配置文件中会多一行 replicaof 的配置， sentinel.conf 的监控目标会随之调换。

参考文章《Redis哨兵（Sentinel）模式》

3、Redis Cluster（集群自带高可用）

Redis3.0之后，Redis官方提供了完整的集群解决方案。方案采用去中心化的方式，包括：sharding（分区）、replication（复制）、failover（故障转移）。称为RedisCluster。

Redis5.0前采用redis-trib进行集群的创建和管理，需要ruby支持 Redis5.0可以直接使用Redis-cli进行集群的创建和管理

（1）部署架构

去中心化 RedisCluster由多个Redis节点组构成，是一个P2P无中心节点的集群架构，依靠Gossip协议传播的集群。

Gossip协议：Gossip协议是一个通信协议，一种传播消息的方式。

起源于：病毒传播 Gossip协议。基本思想就是：一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。

信息会周期性的传递给N个目标节点。这个N被称为fanout（扇出）

gossip协议包含多种消息，包括meet、ping、pong、fail、publish等等。

通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能。

slot：redis-cluster把所有的物理节点映射到[0-16383]个slot上,基本上采用平均分配和连续分配的方式。

比如上图中有5个主节点，这样在RedisCluster创建时，slot槽可按下表分配：

cluster 负责维护节点和slot槽的对应关系 value------>slot-------->节点

当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

比如

set name zhaoyun。hash("name")采用crc16算法，得到值：1324203551%16384=15903，根据上表15903在13088-16383之间，所以name被存储在Redis5节点。

slot槽必须在节点上连续分配，如果出现不连续的情况，则RedisCluster不能工作，详见容错。

RedisCluster的优势

高性能

Redis Cluster 的性能与单节点部署是同级别的。多主节点、负载均衡、读写分离

高可用

Redis Cluster 支持标准的主从复制配置来保障高可用和高可靠。 failover ：Redis Cluster 也实现了一个类似 Raft 的共识方式，来保障整个集群的可用性。

易扩展

向 Redis Cluster 中添加新节点，或者移除节点，都是透明的，不需要停机。水平、垂直方向都非常容易扩展。数据分区，海量数据，数据存储

原生

部署 Redis Cluster 不需要其他的代理或者工具，而且 Redis Cluster 和单机 Redis 几乎完全兼容。

（2）集群搭建

《redis5.0.5集群安装（redis cluster三主三从）》

4、其它集群方案（Twemproxy、Codis、客户端分片）

参考文章《Redis实战（四）集群机制》

五、缓存问题隐患

待补充

六、面试题精选

1、redis的过期策略以及内存淘汰机制

分析:这个问题其实相当重要，到底redis有没用到家，这个问题就可以看出来。比如你redis只能存5G数据，可是你写了10G，那会删5G的数据。怎么删的，这个问题思考过么？还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么?

回答:redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

在redis.conf中有一行配置

# 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优先移除。不推荐

ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

2、redis和数据库双写一致性问题

分析:一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。

首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。

3、如何应对缓存穿透和缓存雪崩问题

可参考文章《缓存穿透、缓存击穿、缓存雪崩区别和解决方案》

分析:这两个问题，说句实在话，一般中小型传统软件企业，很难碰到这个问题。如果有大并发的项目，流量有几百万左右。这两个问题一定要深刻考虑。

回答:如下所示

缓存穿透，即黑客故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。

解决方案:

(一)利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试

(二)采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。

(三)提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。

缓存雪崩，即缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。

解决方案:

(一)给缓存的失效时间，加上一个随机值，避免集体失效。

(二)使用互斥锁，但是该方案吞吐量明显下降了。

(三)双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点

I 从缓存A读数据库，有则直接返回
II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。
III 更新线程同时更新缓存A和缓存B。

4、如何解决redis的并发竞争key问题

分析:这个问题大致就是，同时有多个子系统去set一个key。这个时候要注意什么呢？大家思考过么。需要说明一下，博主提前百度了一下，发现答案基本都是推荐用redis事务机制。博主不推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。
回答:如下所示
(1)如果对这个key操作，不要求顺序
这种情况下，准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可，比较简单。
(2)如果对这个key操作，要求顺序
假设有一个key1,系统A需要将key1设置为valueA,系统B需要将key1设置为valueB,系统C需要将key1设置为valueC.
期望按照key1的value值按照 valueA–>valueB–>valueC的顺序变化。这种时候我们在数据写入数据库的时候，需要保存一个时间戳。假设时间戳如下