redis入门之高级应用（五）

Redis 的高级应用

Redis 的高级应用，包括：安全性设置，主从复制，事务处理，持久化机制，虚拟内存的使用。

安全性

涉及到客户端连接是需要指定密码的（由于 redis 速度相当的快，一秒钟可以 150K 次的密码尝试，所以需要设置一个强度很大的密码）。
设置密码的两种方式：

• config set requirepass [password] :设置密码。
• 在redis.conf文件中设置requirepass属性。

两种输入认证的方式：

• 登录时使用：redis-cli -a password。
• 登录后可以用：auth password。

guc@guc:/redis-4.0.9$ redis-cli -a 654321
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "654321"
127.0.0.1:6379> quit
guc@guc:/redis-4.0.9$ redis-cli
127.0.0.1:6379> config get requirepass
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 654321
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "654321"
127.0.0.1:6379>  

主从复制

为了分担服务器压力，会在特定情况下部署多台服务器分别用于缓存的读和写操作，用于写操作的服务器称为主服务器，用于读操作的服务器称为从服务器。
从服务器通过 psync 操作同步主服务器的写操作，并按照一定的时间间隔更新主服务器上新写入的内容。

Redis 主从复制的过程：

1. Slave与Master建立连接，发送psync同步命令。
2. Master启动一个后台进程，将数据库快照保存到文件中，同时Master主进程会开始收集新的写命令并缓存。
3. 后台完成保存后，将此文件发送给Slave。
4. Slave将此文件保存到磁盘上。

Redis主从复制的特点：

1. 可以拥有多个Slave。

2. 多个Slave可以连接同一个Master外，还可以连接到其他的Slave。（当 Master 宕机后，相连的 Slave 转变为 Master）。

3. 主从复制不会阻塞Master，在同步数据时，Master可以继续处理Client请求。（非阻塞式的同步只能应用于对读数据延迟接受度较高的场景）

4. 提高系统的可伸缩性。

主服务器设置了连接密码:

config set masterauth <password>

要建立这样一个主从关系的缓存服务器，只需要在 Slave 端执行命令:

SLAVEOF IPADDRESS:PORT  
> SLAVEOF 127.0.0.1:6379  

说明：可通过 info replication 查看主从请求信息。

事务处理

Redis 的事务处理比较简单。只能保证 client 发起的事务中的命令可以连续的执行，而且不会插入其它的 client 命令，当一个 client 在连接中发出 multi 命令时，这个连接就进入一个事务的上下文，该连接后续的命令不会执行，而是存放到一个队列中，当执行 exec 命令时，redis 会顺序的执行队列中的所有命令。

127.0.0.1:6379> multi 
OK
127.0.0.1:6379> set hi helloworld
QUEUED
127.0.0.1:6379> set hi nihaoa 
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK

注：redis 对于事务的处理方式比较特殊，它不会在事务过程中出错时恢复到之前的状态，这在实际应用中导致我们不能依赖 redis 的事务来保证数据一致性。

持久化机制

内存中的数据会在重启之后消失，持久化的作用就是要将这些数据长久存到磁盘中以支持长久使用。
Redis 是一个支持持久化的内存数据库，Redis 需要经常将内存中的数据同步到磁盘来保证持久化。
Redis支持持久化的两种方式：

1. snapshotting(快照):将数据存放到文件里，默认方式。是将内存中的数据以快照的方式写入到二进制文件中，默认文件 dump.rdb，可以通过配置设置自动做快照持久化的方式。可配置 Redis 在 n 秒内如果超过 m 个 key 被修改就自动保存快照。比如： save 900 1：900 秒内如果超过 1 个 key 被修改，则发起快照保存。 save 300 10：300 秒内如果超过 10 个 key 被修改，则快照保存。
2. Append-only file（缩写为 aof）：将读写操作存放到文件中。

注：由于快照方式在一定间隔时间做一次，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。
aof 比快照方式有更好的持久化性，是由于使用 aof 时，redis 会将每一个收到的写命令都通过 write 函数写入到文件中，当 redis 启动时会通过重新执行文件中保存的写命令来在内存中重新建立整个数据库的内容。
由于 os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上，这样 aof 方式的持久化也还是有可能会丢失一部分数据。可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。
###配置文件中可配置参数：

• appendonly yes //启用aof持久化方式
• appendfsync always //收到写命令就立即写入磁盘，慢，但保证了数据的完整性
• appendfsync everysec //每秒写入磁盘一次，在性能和持久化方面做了很好的折中
• appendfsync no //完全依赖os,性能最好，持久化没有保证。

save 命令将数据写入磁盘中

127.0.0.1:6379> save
OK

虚拟内存的使用（仅限2.6之前版本）