Redis 的简单介绍

`Redis` 特点

单线程

执行过程按顺序执行，不会同时执行多个操作，保证操作的原子性，省去了很多上下文切换线程的时间，不必考虑资源竞争和可能出现死锁。

为什么使用单线程？

官方FAQ表示：因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

性能高

官方数据：Redis 能读的速度是 110000次/s，写的速度是 81000次/s。这是因为 Redis 的命令操作都是在内存中进行，可以在纳秒级别就处理完，使用了 epoll 非阻塞 IO。epoll 是目前最好的多路复用技术，减少网络 IO 的时间消耗。

注：多路指的是多个网络连接，复用指的是复用同一个线程

丰富的数据类型

基本类型：string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）。

扩展类型：HyperLogLog、geo、bitmap。

HyperLogLog（string）：实现独立用户的统计，会用 0.81% 误差。
geo（zset）：记录地理位置信息，可以计算两个地点的距离或是某个点的周边范围。
bitmap（string）：可以实现用户签到等功能，大幅度减少内存消耗。

Bitmap 对于一些特定类型的计算非常有效。如使用 bitmap 实现用户上线次数统计

假设现在我们希望记录自己网站上的用户的上线频率，比如说，计算用户 A 上线了多少天，用户 B 上线了多少天，诸如此类，以此作为数据，从而决定让哪些用户参加 beta 测试等活动 —— 这个模式可以使用 SETBIT key offset value 和 BITCOUNT key [start] [end] 来实现。

比如说，每当用户在某一天上线的时候，我们就使用 SETBIT key offset value ，以用户名作为 key ，将那天所代表的网站的上线日作为 offset 参数，并将这个 offset 上的为设置为 1 。

举个例子，如果今天是网站上线的第 100 天，而用户 peter 在今天阅览过网站，那么执行命令 SETBIT peter 100 1 ；如果明天 peter 也继续阅览网站，那么执行命令 SETBIT peter 101 1 ，以此类推。

当要计算 peter 总共以来的上线次数时，就使用 BITCOUNT key [start] [end] 命令：执行 BITCOUNT peter ，得出的结果就是 peter 上线的总天数。

`Redis` 使用场景

热点数据缓存、秒杀、计数器、并发锁、消息队列、分布式 Session、限时/限数（验证码过期，错误次数等）、防爬虫（请求次数在单位时间内超过制定数组则可认为被爬虫采集）。除此之外，Redis 支持事务、持久化、Lua 脚本、LRU 驱动事件、多种集群方案。

事务

Redis 事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

Redis 事务可以一次执行多个命令，并且带有以下三个重要的保证：

1、批量操作在发送 EXEC 命令前被放入队列缓存。

2、收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。但出现错误时，整个事务会被取消。

3、在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

multi

incr num

incr num

exec

get num #2

# 使用 watch 可以监控某个key值发生变化时，事务会被打断

watch num # A 机器

multi num # A 机器

inrc num # A 机器

inrc num # B 机器

exec # A 机器 ，返回 nil，即操作被打断

discard # 取消事务

unwatch # 取消监视

管道 `Pipeline`

Redis 是一种基于客户端-服务端模型以及请求/响应协议的 TCP 服务，这意味着通常情况下一个请求会遵循以下步骤：

-> 客户端向服务端发送一个查询请求，并监听 Socket 返回，通常是以阻塞模式，等待服务端响应。

-> 服务端处理命令，并将结果返回给客户端。

-> Redis 管道技术可以在服务端末响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的相应。

$pipe = $redis->multi(Redis::PIPELINE);   //开启管道

for($i= 0 ; $i<  10000 ; $i++) {

       $pipe->set("key::$i",str_pad($i, 4,'0', 0));

       $pipe->get("key::$i");

}

$pipe->exec();   //提交管道里操作命令

管道和事务的区别

1、Pipeline 选择客户端缓冲，multi 选择服务端缓冲。

2、请求次数的不一致，multi 需要每个命令都发送一次给服务端，Pipeline 最后一次性发送给服务端，请求次数相对于 multi 减少。

3、multi/exec 可以保证原子性，而 Pipeline 不保证原子性。

发布/订阅

Redis 提供的发布/订阅功能只是一个低配版的，无法对消息持久化存储。一旦消息被发送，如果没有订阅者接收，那么消息就会丢失。Redis 并没有提供消息传输保障。如果系统中已经有了Redis，并且只需要基本的发布订阅功能，对消息的安全性没有高要求，那就可以使用 Redis 的发布/订阅功能。

subscribe news

publish news hello

# unsubscribe 取消订阅

阻塞队列

使用系统提供的阻塞原语，在新元素到达时立即进行处理，而新元素还没到达时，就一直阻塞住，避免轮询占用资源。也可以实现类似于抢票的功能。

brpop ticket 30 # 0表示一直等待

lpush ticket home

Redis 持久化

`RDB` 持久化

RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，触发 RDB 持久化过程分为手动触发 save 和自动触 bgsave。

save 900 1  # 900 秒之内，如果超过 1 个 key 被修改，则发起快照保存；

save 300 10 # 300 秒内，如果超过 10 个 key 被修改，则发起快照保存；

save 60 10000  # 1 分钟之内，如果 1 万个 key 被修改，则发起快照保存；

优点：

1、RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行 bgsave 备份，并把 RDB 文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

2、Redis 加载 RDB 恢复数据远远快于 AOF 的方式。

缺点：

1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。

2、RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题。针对 RDB 不适合实时持久化的问题，Redis 提供了 AOF 持久化方式来解决。

`AOF` 持久化

AOF（append only file） 持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性，目前已经是Redis 持久化的主流方式。

AOF 工作流程：

-> 将命令转换成协议文本。

-> 所有的写入命令会追加到 aof_buf（缓冲区）中。

-> AOF 缓冲区根据对应的策略向硬盘做同步操作 everysec。

-> 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。

-> 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

重写机制：

1、REWRITE 在主线程中重写 AOF，会阻塞工作线程，在生产环境中很少使用，处于废弃状态。

2、BGREWRITE 在后台（子进程）重写 AOF, 不会阻塞工作线程，能正常服务，此方法最常用 bgrewriteaof。

开启 AOF，通过修改 redis.conf 配置文件

appendonly yes    ##默认不开启。

# appendfsync always

appendfsync everysec ## 默认每秒同步一次

# appendfsync no

AOF 文件名通过 appendfilename 配置设置，默认文件名 appendonly.aof 。保存路径同 RDB 持久化方式一致，通过 dir 配置指定。

AOF 后台 Rewrite 解决方案：

1、官方解决方案：主要思路是 AOF 重写期间，主进程跟子进程通过管道通信，主进程实时将新写入的数据发送给子进程，子进程从管道读出数据交缓存在 buffer 中，子进程等待存量数据全部写入 AOF 文件后，将缓存数据追加到 AOF 文件中，此方案只是解决阻塞工作线程问题，但占用内存过多问题并没有解决。

2、新解决方案：主要思路是 AOF 重写期间，主进程创建一个新的 aof_buf，新的 AOF 文件用于接收新写入的命令，sync 策略保持不变，在 AOF 重写期间，系统需要向两个 aof_buf，两个 AOF 文件同时追加新写入的命令。当主进程收到子进程重写 AOF 文件完成后，停止向老的 aof_buf ，AOF 文件追加命令，然后删除旧的 AOF 文件(流程跟原来保持一致)。将子进程新生成的 AOF 文件重命名为 appendonly.aof.last，具体流程如下：

-> 停止向旧的 aof_buf，AOF 文件追加命令。

-> 删除旧的的 appendonly.aof.last 文件。

-> 交换两个 aof_buf，AOF 文件指针。

-> 回收旧的 aof_buf，AOF 文件。

-> 重命令子进程生成的 AOF 文件为 appendonly.aof.last。

系统运行期间同时存在两个 AOF 文件，一个是当前正在写的 AOF，另一个是存量的 AOF 数据文件。因此需要修改数据库恢复相关逻辑，加载 AOF 时先要加载存量数据 appendonly.aof.last，再加载 appendonly.aof。

混合持久化

AOF 持久化方式在重启加载数据的时候，效率远不如 RDB 方式。因此，Redis 官方在 4.0 版本之后，引入了混合持久化的方式。配置选项是 aof-use-rdb-preamble，yes 表示开启。策略是在生成或者写入 AOF 文件时，将 RDB 数据写在前面。AOF 数据追加在后面。在每次重新启动的时候，先加载 RDB，再加载 AOF。

具体的配置如下：

# When rewriting the AOF file, Redis is able to use an RDB preamble in the

# AOF file for faster rewrites and recoveries. When this option is turned

# on the rewritten AOF file is composed of two different stanzas:

#

#   [RDB file][AOF tail]

#

# When loading Redis recognizes that the AOF file starts with the "REDIS"

# string and loads the prefixed RDB file, and continues loading the AOF

# tail.

aof-use-rdb-preamble yes

主从复制

在主从复制的概念中，数据库分为两类，一类是主数据库 master，另一类是从数据库[1] slave。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

优点：

1、实现了对 Master 数据的备份，一旦 Master 出现故障，Slave 节点可以提升为新的 Master，顶替旧的 Master 继续提供服务（需要手动切换）。

2、实现读扩展，使用主从复制架，一般都是为了实现读扩展。Master 主要实现写功能， Slave 实现读的功能。

缺点：

1、当 Maser 宕机后，需要人工参与。

-> 在 Slave1 上执slaveof no one 命令提升 Slave1 为新的 Master 节点。

-> 在 Slave1 上配置为可写，这是因为大多数情况下，都将 Slave 配置只读。

-> 告诉 Client 端(也就是连接 Redis 的程序)新的 Master 节点的连接地址(改代码)。

-> 配置 Slave2 从新的 Master 进行数据复制。

2、虽然实现了读写分离，但是主节点的性能会成为主要瓶颈。

Sentinel 哨兵机制

Redis Sentinel 为 Redis 提供了高可用方案。从实践方面来说，使用 Redis Sentinel 可以创建一个无需人为干预就可以预防某些故障的 Redis 环境。实现自动切换。在部署 Sentinel 的时候，建议使用奇数个 Sentinel 节点，最少三个 Sentinel 节点。

功能：

1、监控，Sentinel 会不断的检查 master 和 slave 是否像预期那样正常运行。

2、通知，通过 API，Sentinel 能够通知系统管理员、程序监控的 Redis 实例出现了故障。

3、自动故障转移，如果 Master 不像预想中那样正常运行，Sentinel 可以启动故障转移过程，其中的一个 Slave 会提成为 Master，其它 Slave 会重新配置来使用新的 Master，使用Redis 服务的应用程序，当连接时，也会被通知使用新的地址。

4、配置提供者，Sentinel 可以做为客户端服务发现的认证源：客户端连接 Sentinel 来获取目前负责给定服务的 Redis master 地址。如果发生故障转移，Sentinel 会报告新的地址。

三个定时任务

每 10 秒每个 sentinel 对 master 和 slave 执行 info replication，以发现新的 slave 节点并确认主从关系。
每 2 秒每个 sentinel 通过 master 节点的 channel（__sentinel__:hello）交换信息，以交换对节点的”看法“和自身信息。
每 1 秒每个 sentinel 对其他 sentinel 和主、从节点发送 ping 命令来做心跳检测。

故障切换实现原理

Sentinel 之间进行选举，选举出一个 leader ，由选举出的 leader 进行 failover。
Sentinel leader 选取 slave 节点中的一个 slave 作为新的 Master 节点。对 slave 选举需要对 slave 进行选举的方法如下：
- 与 master 断开时间，如果与 Master 断开的时间超过 down-after-milliseconds (sentinel配置） * 10秒加上从 sentinel 判定 Master 不可用到 sentinel 开始执行故障转移之间的时间，就认为该 Slave 不适合提升为 Master。
- slave 优先级，每个 Slave 都有优先级，保存在 redis.conf 配置文件里。如果优先级相同，则继续进行。
- 复制偏移位置，复制偏移纪录着从 Master 复制数据复制到哪里，复制偏移越大表明从 Master 接受的数据越多，如果复制偏移量也一样，继续进行选举。
- Run ID，选举具有最小 Run ID 的 Slave 作为新的 Master。
Sentinel leader 会在上一步选举的新 master 上执行 slaveof no one 操作，将其提升为 master 节点。
Sentinel leader 向其它 slave 发送命令，让剩余的 slave 成为新的 master 节点的 slave。
Sentinel leader 会让原来的 master 降级为 slave，当恢复正常工作，Sentinel leader 会发送命令让其从新的 master 进行复制。

配置文件说明

daemonize yes #以后台进程模式运行

port 27000 # 哨兵的端口号，该端口号默认为26379。

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

# redis-master是主数据的别名，考虑到故障恢复后主数据库的地址和端口号会发生变化，哨兵提供了命令可以通过别名获取主数据库的地址和端口号。

# 192.168.1.51 7000为初次配置时主数据库的地址和端口号，当主数据库发生变化时，哨兵会自动更新这个配置，不需要我们去关心。

# 2，该参数用来表示执行故障恢复操作前至少需要几个哨兵节点同意，一般设置为N/2+1(N为哨兵总数)。

sentinel down-after-milliseconds redis-master 5000

#如果master在多少秒内无反应哨兵会开始进行master-slave间的切换，使用“选举”机制

sentinel failover-timeout redis-master 900000

# 如果master 在 900000 秒后恢复，则把它加入到 slave 中

logfile "/data/bd/redis/sentinel/sentinel.log" #log文件所在地

`Docker+Redis` 实例

设置配置

# redis-master.conf

port 7000

daemonize yes

pidfile /var/run/redis.pid

logfile "7000.log"

sed 's/7000/7001/g' redis-master.conf > redis-slave1.conf

sed 's/7000/7002/g' redis-master.conf > redis-slave2.conf

echo "slaveof redis-master 7000" >> redis-slave1.conf

echo "slaveof redis-master 7000" >> redis-slave2.conf

启动 `Redis-Master` 容器

# 启动 Redis-Master容器

sudo docker run -d -p 7000:7000 -v /home/summer/homework/redis/config/redis-master.conf:/etc/redis/redis.conf --name redis-master redis redis-server /etc/redis/redis.conf

启动 `Redis-Slave` 容器

# 启动 Redis-Slave1 容器

sudo docker run -d -p 7001:7001 -v /home/summer/homework/redis/config/redis-slave1.conf:/etc/redis/redis.conf --name redis-slave1 --link redis-master:master redis  redis-server /etc/redis/redis.conf

# 启动 Redis-Slave2 容器

sudo docker run -d -p 7002:7002 -v /home/summer/homework/redis/config/redis-slave2.conf:/etc/redis/redis.conf --name redis-slave2 --link redis-master:master redis redis-server /etc/redis/redis.conf

注意问题

1、禁止线上执行 keys *、mset、mget、hmget、hmset 等操作，会造成阻塞。

2、避免同一时间缓存大面积失效，造成缓存雪崩。

3、内存数据库，键名长度影响有限内存空间，所以命名应该控制长度，简短易懂。

4、大小写规范。

5、根据业务命名，相同业务统一的 Key 前缀。

常用命令

debug sleep 10

config set xx yy

config  get  xx*

info replication  # 查看主从信息

info server

info sentinel

参考资料