分布式缓存技术redis系列（三）——redis高级应用（主从、事务与锁、持久化）

 

 

上文《详细讲解redis数据结构（内存模型）以及经常使用命令》介绍了redis的数据类型以及经常使用命令，本文咱们来学习下redis的一些高级特性。

 

安全性设置

设置客户端操做秘密

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）功能， 该功能可让从服务器(slave server)成为主服务器(master server)的精确复制品。

 

主从复制的特色

（1）一个主服务器能够有多个从服务器。

（2）不只主服务器能够有从服务器， 从服务器也能够有本身的从服务器。

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

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

主从复制的过程

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

 

 

 

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的集群。

 

 

 

 

参考文档

http://redis.io/documentation

http://redisdoc.com/