Redis从通俗到易懂（中）

目录

1.事务

2.实现乐观锁（Watch）

3.redis配置文件详解

4.Redis持久化

4.1.RDB方式（Redis DataBase）

4.2.AOF方式（Append Only File）

5.Redis发布订阅

6.Redis主从复制

---

1.事务

Redis事务本质：一组命令集合，一个事务中所有命令都会被序列化，在事务执行过程中，会被顺序执行

• 一次性
• 顺序性
• 排他性

Redis单条命令是保证原子性，但是Redis的事务不保证原子性的

所有的命令在事务中并不是直接执行，只有发起执行命令的时候，才会执行

redis事务：

1. 开启事务（multi）
2. 命令入队（......）
3. 执行事务（exec）

放弃事务（discard）

编译型异常（命令有错误），事务中所有命令都不会执行

运行时异常（1/0），如果事务队列中存在语法性，那么执行命令的时候，其他命令都是可以执行的，错误命令抛出异常

2.实现乐观锁（Watch）

悲观锁：

• 很悲观，什么时候都会出问题，无论做什么都会加锁，效率低下

乐观锁：

• 很乐观，什么时候都不会出现问题，所以不会上锁，在更新数据的时候去判断一下，在此期间判断是否有人修改这个数据。
• 获取version
• 更新的时候获取version

使用watch可以当做redis的乐观锁操作

正常执行

异常执行：当另一个线程修改了money值，导致事务执行失败

解决办法（发现事务执行失败，可以放弃监视 unwatch，再重新监视watch，重新开启事务）

3.redis配置文件详解

1.配置文件unit单位大小写不敏感

2.INCLUDES，可以把多个配置文件都配置过来

3.网络

bind 127.0.0.1 #绑定ip

protected-mode yes #保护模式默认开启

port 6379

4.通用GENERAL

daemonize yes #开启守护进程方式运行，挂到后台

pidfile /var/run/redis.pid #如果后台方式运行，我们就需要一个pid文件

loglevel notice #日志级别

logfile "server_log.txt" #日志路径

databases 16 #默认16个数据库

5.RDB配置（快照SNAPSHOTTING）

在规定的时候内，执行了多少次，则会持久化到文件 rdb aof

redis是内存数据库，如果没有持久化，那么数据库就断电即失

save 900 1 #如果900秒内，如果至少1个key进行修改，则进行持久化
save 300 10 #如果300秒内，如果至少10个key进行修改，则进行持久化
save 60 10000 #如果60秒内，如果至少10000个key进行修改，则进行持久化

stop-writes-on-bgsave-error yes #持久化错误了，是否还继续工作

rdbcompression yes #是否压缩rdb文件，需要消耗CPU资源

rdbchecksum yes #保存rdb文件的时候，是否进行错误检查校验

dir ./ #rdb文件的保存目录

6.REPLICATION 主从复制的配置

slaveof <masterip> <masterport>：配置master节点上redis的IP和端口

masterauth <master-password>：配置master节点redis的密码，没有的话，不用配置

7.SECURITY 设置用户名密码（默认没有密码）

requirepass {密码} #设置密码，流程如下

#设置密码
config set requirepass "123456"
#获取密码
config get requirepass
#认证密码
auth 123456

也可以在配置文件中配置

8.客户端限制LIMITS

maxclients 10000 #默认最大10000个客户端连接数

maxmemory <bytes> #最大内存量

maxmemory-policy noeviction #内存到达上限后的处理策略

1. volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
2. allkeys-lru ： 删除lru算法的key   
3. volatile-random：随机删除即将过期key   
4. allkeys-random：随机删除   
5. volatile-ttl ： 删除即将过期的   
6. noeviction ： 永不过期，返回错误

9.AOF的配置 APPEND ONLY FILE

appendonly no #默认不开启，默认使用rdb持久化的，因为大部分情况下，rdb够用了

appendfilename "appendonly.aof" #rdb持久化文件的名字

# appendfsync always    #每次修改都会同步sync，消耗性能
appendfsync everysec    #每秒执行一次sync 可能丢失1s的数据
# appendfsync no     #不执行同步

4.Redis持久化

4.1.RDB方式（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是“快照”，恢复时也是将快照文件写入到内存中。

原理：Redis会单独创建（fork）一个子进程来进行持久化，先将数据写入到一个临时文件中，待持久化过程都结束了，再将这个临时文件替换上一次持久化好的文件，整个过程中，主进程不进行任何IO操作，确保了极高的性能，RDB方式要比AOF方式更加高效，缺点就是最后一次持久化的时候可能丢失数据。

生产环境下，我们一般需要定期备份dump.rdb文件

默认配置就是RDB方式

rdb触发机制？

• 配置文件中save的规则满足情况下，会自动触发rdb规则
• 执行flushall命令后，也会触发rdb规则
• 退出redis（shuttdown），也会自动备份一个rdb文件

如何恢复rdb文件？

只需要把rdb文件拷贝到redis启动目录下，redis启动的时候就会自动检查dump.rdb，恢复其中的数据

查看需要存放的位置（config get dir）

D:\redis\Redis-x64-5.0.10下放入dump.rdb文件，启动就会自动恢复其中的数据

优点

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高

缺点

1. 需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了
2. fork进程的时候，会占用一定的内存空间

4.2.AOF方式（Append Only File）

也叫追加文件，将我们的所有命令都记录下来，恢复的时候把这个文件全部再执行一遍（写指令）！类似linux中的history命令

原理：以日志的方式来记录每个写操作，将Redis执行过的所有指令都记录下来（读操作不记录），只是追加文件不是改写文件，redis启动之初会读取改文件重新构建数据，换而言之，redis重启的过程就是根据日志文件内容将写指令从前到后执行一次，完成数据的回复工作

AOF保存的是appendonly.aof文件

默认不开启，要开启需要手动进行配置appendonly yes，重启redis服务即可生效

如果这个aof文件有错误，这个时候 redis是启动不起来的，需要我们去修复这个aof文件，redis给了我们一个修复工具redis-check-aof.exe 

redis-check-aof.exe --fix appendonly.aof

优点

1. appendfsync always，每一次修改都执行sync，文件的完整性会更好
2. （默认）appendfsync everysec，每秒执行一次sync，可能会丢失一秒的数据
3. appendfsync no，不执行同步sync，系统自己执行同步，效率是最高的

缺点

1. 相对于数据文件大小来说，aof远远大于rdb，恢复速度也比rdb慢
2. aof运行效率也比rdb慢，所以redis默认的配置是rdb持久化

5.Redis发布订阅

Redis发布订阅（pub/sub）是一种消息通信机制，发送者（pub）发送消息，订阅者（sub）接收消息，微博，微信，关注系统。

常用命令，先订阅后发布

订阅一个频道：subscribe {频道channel}

发布消息：publish {频道channel} {message}

场景：

• 实时消息系统
• 实时聊天室，将消息回显给所有人
• 订阅，关注系统都可以

稍微复杂的场景会使用消息中间件MQ

6.Redis主从复制

概念

指将一台redis服务器的数据，复制到其他redis服务器，前者称为master，后者称为从节点slave

数据时单向的，只能主节点到从节点，master以写为主，slave以读为主

主从复制的作用

• 数据热备份：是持久化之外的数据冗余方式
• 故障恢复：主节点出现问题，可以从节点提供服务，实现快速的故障恢复
• 负载均衡：主从复制+读写分离，从节点提供读服务，分担服务器负载，提高redis服务器并发量
• 高可用集群的基础：是哨兵模式的基础，一般标准的最低配置（一主二从），单台redis最大使用内存不应该超过20G。

真实的项目中不可能使用单机redis，一旦宕机就凉凉了。

环境配置

每一个redis都是主节点，所以只配置从库，不配置主库

查询主从信息：info replication

一主二从

1.复制3个配置文件redis.conf，修改对应的信息（配置文件名字，端口，pid名字，log文件名字，dump.rdb名字）

分别启动3个redis服务器

2.启动3个redis服务命令

redis-server redis79.conf
redis-server redis80.conf
redis-server redis81.conf

3.只配置从库，简称认老大

假如redis79是master，redis80和redis81是slave，那么redis79.conf配置文件不用修改

分别在redis80和redis81上执行：slaveof 127.0.0.1 6379

slaveof <masterIp> <masterPort>

如果两个都配置完，可以在master上（info replication）看到2个slave节点

以上1，2，3步骤都是命令方式配置，只是临时的

测试细节

主机可以写，从机不能写只能读！主机中所有的数据和信息，都会自动被从机保存

主机断开，从机依旧可以连接到主机，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接从主机获取写的信息

复制原理

Slave启动成功连接到Master后，发送一个sync同步命令。

Master接到命令后，启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕之后，Master将整个数据文件传送给slave，并完成一次完全同步。

全量复制：而Slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master继续将新的所有收集到的修改命令依次传递给Slave，完成同步。

层层链路

主从复制的另一种配置形式，79是master，80连接79是slave，81连接80，这样80也是master

只要是slave，就不能进行写操作

如果79宕机了，那么80手动执行slaveof no none 即可由原来的的slave变成master，取代之前宕机的79，就算79重启了，80依旧是master，跟80和81没有关系了。