Redis进阶介绍—(3)

Redis进阶介绍

在承接前面的文章中，我们现在开始进行Redis的详细说明。

1、Redis事务管理

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

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客 户端发送来的命令请求所打断。
• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务
• 命令入队
• 执行事务

下面举一个小小的关于事务的例子。它先以MULTI开始一个事务，然后将多个命令入队到事务中，最后由EXEC命令触发事务，一并执行事务中的所有命令。

127.0.0.1:6379> multi 
OK 
127.0.0.1:6379> set bookname java 
QUEUED 
127.0.0.1:6379> set bookname c++ 
QUEUED 127.0.0.1:6379> set bookname html 
QUEUED 127.0.0.1:6379> 
exec 
1) OK 
2) OK 
3) OK

2、Redis发布订阅模式

Redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

当然，Redis客户端可以订阅任意数量的频道。当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端。

3、Jedis连接Redis

如何在Java中使用Redis，这里使用的是导入Jedis包。

3.1 通过无骨架创建Maven项目

<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.7.2</version>
</dependency>

3.2 尝试测试远程服务器端

3.2.1.确认远程服务器是否可以ping通

ping vmware的ip地址

并且确认防火墙是否关闭运行。

3.2.2 连接服务器

Jedis jedis = new Jedis("地址",port)

在进行编译的时候，容易因为配置文件没有修改好而出现问题。

修改redis.conf文件里面的 bind 连接地址,将连接地址改为自己虚拟机的ip。

bind 192.168.197.129 

重新启动服务，Jedis就可以正常连上了。

4、Redis的持久化方法

持久化方法：为防止突然断电等特殊情况的发生，需要对数据进行持久化备份。即将内存数据保存到硬盘。

简单来说，就是由于redis的值存放于我们的内存中，所以会出现断电等不确定因素。这就需要一定的备份方法来保存内存数据放置于硬盘中。

4.1 Redis持久化方法

4.1.1 RDB持久化

RDB文件在最初下载Redis后的bin目录是可以见着这个名字的。

RDB是一个二进制文件，它在某一个时间点将数据存入一个临时文件，持久化结束后用这个临时文件替换上次持久化的文件达到备份的效果。其中，某一时间点可以由自己配置。

• 优点：在于使用了单独的子进程来进行持久化，主进程不会被影响任何操作，保证了redis的高性能。
• 缺点：RDB 是间隔一段时间进行持久化，如果持久化之间redis发生故障，仍然会发生数据丢失。

RDB默认被开启，其中redis.conf具体配置如下：

#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-5.0.5/src下启动的redis-cli，则数据会存储在当前
src目录下
dir ./
##snapshot触发的时机，save
##如下为900秒后，至少有一个变更操作，才会snapshot
##对于此值的设置，需要谨慎，评估系统的变更操作密集程度
##可以通过“save”来关闭snapshot功能
#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个
key60s进行存储。
save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间
rdbcompression yes

注意:测试时使用root用户操作。

4.1.2 AOF持久化

意思就是Append-Only File，将“操作+数据”以格式化的指令方式追加到操作日志文件的尾部。当然，在append操作返回后才进行实际的数据变更。“日志文件”保存了历史所有的操作过程。

当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，AOF 文件内容是字符串，非常容易阅读和解析。

• 优点：可以保持更加高的数据完整性。
• 缺点：AOF文件比RDB文件大，且恢复速度较慢。

##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能
##只有在“yes”下，aof重写/文件同步等特性才会生效
appendonly yes

##指定aof文件名称
appendfilename appendonly.aof

##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec
appendfsync everysec

##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不缓”，“yes”表示“暂缓”，默认为“no”
no-appendfsync-on-rewrite no

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建
议“512mb”
auto-aof-rewrite-min-size 64mb

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100

AOF是文件操作对于变更操作比较密集的服务器就容易造成IO的负担加重。

此外，linux对文件操作采取了**“延迟写入”手段**，即并非每次 write 操作都会触发实际磁盘操作，而是进入了 buffer 中。

当 buffer 数据达到阀值时触发实际写入(也有其他时机)，这是 linux 对文件系统的优化，但是这却有可能带来隐患，如果 buffer 没有刷新到磁盘，此时物理机器失效(比如断电)，那么有可能导致最后一条或者多条 aof 记录的丢失。

基于如上buffer数据存在的问题，我们看上面的配置文件（第8行）：

always：每一条 aof 记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，但是 IO 开支较大。
everysec：每秒同步一次，性能和安全都比较中庸的方式，也是 redis 推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内 aof 记录丢失(可能为部分丢失)。
no：redis 并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据 buffer 填充情况 / 通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因 OS 配置有关。

一般而言，everysec是redis更加推荐的选择。当然如果每一个数据都弥足珍贵，建议还是考虑其他关系型数据库。

4.2 AOF和RDB的区别

前面在各自介绍时都有明确点到过。

RDB是一个二进制文件，它在某一个时间点将数据存入一个临时文件，持久化结束后用这个临时文件替换上次持久化的文件达到备份的效果。其中，某一时间点可以由自己配置。

• 优点：在于使用了单独的子进程来进行持久化，主进程不会被影响任何操作，保证了redis的高性能。
• 缺点：RDB 是间隔一段时间进行持久化，如果持久化之间redis发生故障，仍然会发生数据丢失。

AOF将“操作+数据”以格式化的指令方式追加到操作日志文件的尾部。当然，在append操作返回后才进行实际的数据变更。“日志文件”保存了历史所有的操作过程。当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，AOF 文件内容是字符串，非常容易阅读和解析。

• 优点：可以保持更加高的数据完整性。
• 缺点：AOF文件比RDB文件大，且恢复速度较慢。

5、Redis主从复制

持久化保证了redis服务器重启也不会丢失数据。但是，如果硬盘被偷袭了就可能会导致数据丢失。这里对于硬盘的偷袭而言，通过redis的主从复制机制能够避免这个单点故障的发生。（如果同时被偷家那只能怪自己运气够衰的呵呵）

对于主从复制而言，工作中一般以一个主子+若干个仆从构成。

数据会同步到服务器中，并且这个集群中的几台服务器也会有同样的数据。

5.1 主从复制搭建步骤

对于主从搭建而言，主机并不需要配置。需要配置的仅仅只是从机，从slave配置。

5.1.1 复制一个从机

首先使用root用户。

[root@localhost myapps]# cp redis/ redis1 -r
[root@localhost myapps]# ll

5.1.2 修改从机的redis.conf

语法：replicaof // replicaof 主机ip 主机端口号

5.1.3 修改从机的port地址为6380

因为前期有复制操作，所以conf配置文件内容大致一致。

这里跟主机的port地址不一样，切记！！

5.1.4 清除从机中的持久化文件

5.1.5 启动从机

[root@localhost redis1]# ./bin/redis-server ./redis.conf

5.1.6 启动端口号为6380的客户端

[root@localhost redis1]# ./bin/redis-cli -p 6380

停止客户端：./bin/redis-cli -p 6380 shutdown

注意：

• 主机一旦发生增删改操作，那么从机会自动将数据同步到从机中。
• 从机不能执行写操作，只能读。

6、Redis哨兵模式（介绍）

本文暂时对哨兵模式进行简单的介绍，并不展示其配置。

哨兵模式：给集群分配一个站岗。

哨兵的作用就是对Redis系统的运行情况进行监测，是一个独立的进程。其功能如下：

1. 监控主数据库和从数据库是否正常运行
2. 主数据出现故障后自动将从数据库转化成主数据库

以上是Redis的进一步介绍。后续会为大家讲解redis关于进阶甚至是升级到面试上的问题。谢谢大家。
中**。

• 从机不能执行写操作，只能读。

6、Redis哨兵模式（介绍）

本文暂时对哨兵模式进行简单的介绍，并不展示其配置。

哨兵模式：给集群分配一个站岗。

哨兵的作用就是对Redis系统的运行情况进行监测，是一个独立的进程。其功能如下：

1. 监控主数据库和从数据库是否正常运行
2. 主数据出现故障后自动将从数据库转化成主数据库

以上是Redis的进一步介绍。后续会为大家讲解redis关于进阶甚至是升级到面试上的问题。谢谢大家。