Redis学习笔记之四：redis高级应用（主从、事务与锁、持久化）

曾经终败给现在 2022-05-13 13:36 130阅读 0赞

# **安全性设置** #

## **设置客户端操作秘密** ##

redis安装好后，默认情况下登陆客户端和使用命令操作时不需要密码的。某些情况下，为了安全起见，我们可以设置在客户端连接后进行任何操作之前都要进行密码验证。修改redis.conf进行配置。

> \[root@localhost ~\]\# vi /usr/local/redis/etc/redis.conf

> \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#SECURITY \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
> 
> ......
> 
> \# Warning: since Redis is pretty fast an outside user can try up to
> 
> \# 150k passwords per second against a good box. This means that you should
> 
> \# use a very strong password otherwise it will be very easy to break.
> 
> \#
> 
> \# requirepass foobared
> 
> requirepass redis129
> 
>  
> 
> \# Command renaming.

如上，找到\# requirepass foobared这一行，在下面添加“requirepass 密码”一行设置密码。设置好密码后，有两种方式授权客户端进行操作。

## **客户端授权方式** ##

（1）登录时使用-a参数指定客户端密码，如下

> \[root@localhost ~\]\# /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379 \-a redis129
> 
> 192.168.2.129:6379> keys \*
> 
> 1) "myzset"
> 
> 192.168.2.129:6379>

（2）登录客户端后使用auth命令进行授权，如下

> \[root@localhost ~\]\# /usr/local/redis/bin/redis-cli -h 192.168.2.129 -p 6379
> 
> 192.168.2.129:6379> keys \*
> 
> (error) NOAUTH Authentication required.
> 
> 192.168.2.129:6379> auth redis129
> 
> OK
> 
> 192.168.2.129:6379> keys \*
> 
> 1) "myzset"
> 
> 192.168.2.129:6379>

# **主从复制** #

主从复制，即主服务器与从服务器之间数据备份的问题。Redis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器(slaveserver)成为主服务器(master server)的精确复制品。

## **主从复制的特点** ##

（1）一个主服务器可以有多个从服务器。

（2）不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器。

（3）Redis 支持异步复制和部分复制（这两个特性从Redis 2.8开始），主从复制过程不会阻塞主服务器和从服务器。

（4）主从复制功能可以提升系统的伸缩性和功能，如让多个从服务器处理只读命令，使用复制功能来让主服务器免于频繁的执行持久化操作。

## **主从复制的过程** ##

下面我们用一个图来讲解redis主从复制的过程。

[![wpsEB10.tmp][]][wpsEB10.tmp 1]

Redis主从复制过程示意图

从上面的示意图可以看出，主服务器与从服务器建立连接之后，Redis主从复制过程主要有下面几步：

（1）从服务器都将向主服务器发送一个 SYNC 命令。

（2）主服务器接到 SYNC 命令后开启一个后台子进程并开始执行 BGSAVE，并在保存操作执行期间， 将所有新执行的写入命令都保存到一个缓冲区里面。

（3）当 BGSAVE 执行完毕后， 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器， 从服务器接收这个 .rdb 文件， 并将文件中的数据载入到内存中。

（4）主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器。

## **配置从服务器** ##

redis配置一个从服务器非常简单， 只要在从服务器的配置文件redis.conf中增加主服务器的IP地址和端口号就可以，如果主服务器设置了客户端密码，还需要在从服务器中配置主服务器的密码，如下

> \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#REPLICATION \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
> 
>  
> 
> \# Master-Slave replication. Use slaveof to make a Redis instance a copy of
> 
> \# another Redis server. A few things to understand ASAP about Redis replication.
> 
> \#
> 
> ......
> 
> \# slaveof <masterip> <masterport>
> 
> slaveof 192.168.2.129 6379
> 
> \# If the master is password protected (using the "requirepass" configuration
> 
> \# directive below) it is possible to tell the slave to authenticate before
> 
> \# starting the replication synchronization process, otherwise the master will
> 
> \# refuse the slave request.
> 
> \#
> 
> \# masterauth <master-password>
> 
> masterauth redis129

# **事务与锁** #

Redis 的事务支持相对简单，MULTI 、 EXEC 、 DISCARD 和 WATCH 这四个命令是 Redis 事务的基础。

## **事务开启与取消** ##

l MULTI 开启一个事务。当客户端发出了MULTI 命令时，客户端和服务端的连接就进入了一个事务上下文的状态。MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。

l EXEC 顺序执行事务队列中的命令。

> 192.168.2.129:6379> multi
> 
> OK
> 
> 192.168.2.129:6379> set name "zhangsan"
> 
> QUEUED
> 
> 192.168.2.129:6379> set age 20
> 
> QUEUED
> 
> 192.168.2.129:6379> exec
> 
> 1) OK
> 
> 2) OK
> 
> 192.168.2.129:6379> keys \*
> 
> 1) "age"
> 
> 2) "name"
> 
> 192.168.2.129:6379>

l DISCARD 取消事务。当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出。

> 192.168.2.129:6379> multi
> 
> OK
> 
> 192.168.2.129:6379> set name2 "lisi"
> 
> QUEUED
> 
> 192.168.2.129:6379> set age 22
> 
> QUEUED
> 
> 192.168.2.129:6379> discard
> 
> OK
> 
> 192.168.2.129:6379> exec
> 
> (error) ERR EXEC without MULTI
> 
> 192.168.2.129:6379>

## **乐观锁** ##

l WATCH 对key值进行锁操作。 在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 key 的值， 那么当前客户端的事务就会失败。如下：

Client1开启watch name并在事务中修改name，但是没有执行exec

> 192.168.2.129:6379> get name
> 
> "huangliu"
> 
> 192.168.2.129:6379> watch name
> 
> OK
> 
> 192.168.2.129:6379> multi
> 
> OK
> 
> 192.168.2.129:6379> set name lisi
> 
> QUEUED

Client2 修改name

> 192.168.2.129:6379> get name
> 
> "huangliu"
> 
> 192.168.2.129:6379> set name "wangwu"
> 
> OK
> 
> 192.168.2.129:6379> get name
> 
> "wangwu"
> 
> 192.168.2.129:6379>

Client1执行exec

> 192.168.2.129:6379> exec
> 
> (nil)
> 
> 192.168.2.129:6379>

可见，由于被watch的name已经被Client2 修改，所以Client1的事务执行失败，程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞（Crash）为止。对key进行加锁监视的机制类似Java多线程中的锁（synchronized中的监视器对象），被称作乐观锁。乐观是一种非常强大的锁机制，后面我们会进一步学习redis的分布式锁。

# **持久化机制** #

前面我们已经说过，既可以把redis理解为缓存技术，也可以理解为数据库，因为redis支持将内存中的数据周期性的写入磁盘或者把操作追加到记录文件中，这个过程称为redis的持久化。redis支持两种方式的持久化，一种是快照方式（snapshotting）,也称RDB方式；两一种是追加文件方式（append-only file），也称AOF方式。RDB方式是redis默认的持久化方式。

## **RDB方式** ##

RDB方式是将内存中的数据的快照以二进制的方式写入名字为 dump.rdb的文件中。我们对 Redis 进行设置， 让它根据设置周期性自动保存数据集。修改redis.conf文件，如下

> \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\# SNAPSHOTTING  \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
> 
> \#
> 
> \# Save the DB on disk:
> 
> ......
> 
> \#   In the example below the behaviour will be to save:
> 
> \#   after 900 sec (15 min) if at least 1 key changed
> 
> \#   after 300 sec (5 min) if at least 10 keys changed
> 
> \#   after 60 sec if at least 10000 keys changed
> 
> \#
> 
> \#   Note: you can disable saving completely by commenting out all "save" lines.
> 
> \#
> 
> \#   It is also possible to remove all the previously configured save
> 
> \#   points by adding a save directive with a single empty string argument
> 
> \#   like in the following example:
> 
> \#
> 
> \#   save ""
> 
> \#900秒内如果有超过1个key被修改则发起保存快照
> 
> save 900 1
> 
> \#300秒内如果有超过10个key被修改则发起保存快照
> 
> save 300 10
> 
> \#60秒内如果有超过1000个key被修改则发起保存快照
> 
> save 60 10000

dump.rdb文件默认生成在%REDIS\_HOME%etc目录下（如/usr/local/redis/etc/），可以修改redis.conf文件中的dir指定dump.rdb的保存路径

> \# The filename where to dump the DB
> 
> dbfilename dump.rdb
> 
>  
> 
> \# The working directory.
> 
> \#
> 
> \# The DB will be written inside this directory, with the filename specified
> 
> \# above using the 'dbfilename' configuration directive.
> 
> \#
> 
> \# The Append Only File will also be created inside this directory.
> 
> \#
> 
> \# Note that you must specify a directory here, not a file name.
> 
> dir ./

## **AOF方式** ##

RDB方式是周期性的持久化数据， 如果未到持久化时间点，Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。所以从redis 1.1开始引入了AOF方式，AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。

AOF方式仍然有丢失数据的可能，因为收到写命令后可能并不会马上将写命令写入磁盘，因此我们可以修改redis.conf，配置redis调用write函数写入命令到文件中的时机。如下

> \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#APPEND ONLY MODE \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
> 
> ......
> 
> \# AOF and RDB persistence can be enabled at the same time without problems.
> 
> \# If the AOF is enabled on startup Redis will load the AOF, that is the file
> 
> \# with the better durability guarantees.
> 
> \#
> 
> \# Please check http://redis.io/topics/persistence for more information.
> 
> \#启用AOF方式
> 
> appendonly yes
> 
> \#每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
> 
> appendfsync always
> 
> \#每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据
> 
> appendfsync everysec
> 
> \#从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择
> 
> appendfsync no

从上面三种AOF持久化时机来看，为了保证不丢失数据，appendfsync always是最安全的。

# **发布以及订阅消息** #

Redis的发布以及订阅有点类似于聊天，是一种消息通信模式。在这个模式中，发送者（发送信息的客户端）不是将信息直接发送给特定的接收者（接收信息的客户端）， 而是将信息发送给频道（channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三个命令实现了消息的发布与订阅。如下

Client1发布频道mychannel与消息

> 192.168.2.129:6379> publish mychannel "message from channel1"
> 
> (integer) 1
> 
> 192.168.2.129:6379>

Client2 订阅频道mychannel并接受Client1通过频道发过来的消息

> 192.168.2.129:6379> subscribe mychannel
> 
> Reading messages... (press Ctrl-C to quit)
> 
> 1) "subscribe"
> 
> 2) "mychannel"
> 
> 3) (integer) 1
> 
> 1) "message"
> 
> 2) "mychannel"
> 
> 3) "message from channel1"

至此，redis的客户端安全性设置、主从复制、事务与锁、持久化机制以及发布与订阅消息主要内容介绍完毕。下一篇我们将继续学习redis的集群。

[wpsEB10.tmp]: /images/20220504/1118c9f908ec4e19abc3450f3bc31d11.png
[wpsEB10.tmp 1]: http://images2015.cnblogs.com/blog/783994/201607/783994-20160711160410326-1705321436.jpg