1.1：安全性
下面我们做一个实验，说明 redis 的安全性是如何实现的。
# requirepass foobared
requirepass 123456
我们设置了连接的口令是 123456
那么们启动一个客户端试一下:
[root@localhost redis-2.2.12]# src/redis-cli
redis 127.0.0.1:6379> keys *
(error) ERR operation not permitted
redis 127.0.0.1:6379>
说明权限太小，我们可以当前的这个窗口中设置口令
redis 127.0.0.1:6379> auth 123456
OK
redis 127.0.0.1:6379> keys *
1) "name"
redis 127.0.0.1:6379>
我们还可以在连接到服务器期间就指定一个口令，如下:
[root@localhost redis-2.2.12]# src/redis-cli -a 123456
redis 127.0.0.1:6379> keys *
1) "name"
redis 127.0.0.1:6379>
可以看到我们在连接的时候就可以指定一个口令。
1.2：主从复制
1.2.1 redis 主从复制特点:
(1)、master 可以拥有多个 slave
(2)、多个 slave 可以连接同一个 master 外，还可以连接到其他 slave
(3)、主从复制不会阻塞 master，在同步数据时，master 可以继续处理 client 请求
(4)、提高系统的伸缩性
1.2.2 redis 主从复制过程:
当配置好 slave 后，slave 与 master 建立连接，然后发送 sync 命令。无论是第一次连接还是重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，同时 master 主进程会开始收集新的写命令并缓存。后台进程完成写文件后，master 就发送文件给 slave，slave将文件保存到硬盘上，再加载到内存中，接着 master 就会把缓存的命令转发给 slave，后续master 将收到的写命令发送给 slave。如果 master 同时收到多个 slave 发来的同步连接命令，master 只会启动一个进程来写数据库镜像，然后发送给所有的 slave。
1.2.3 如何配置配置
slave 服务器很简单，只需要在 slave 的配置文件中加入如下配置
slaveof 192.168.136.128 6379 #指定 master 的 ip 和端口
注意：如果主从复制失败，可能原因
centOS7主从复制失败，解决方法之一：
在redis主服务器上的redis.conf中修改bind字段
bind 127.0.0.1
修改为
bind 0.0.0.0
又或者直接注释掉bind字段
# bind 127.0.0.1
原因：如果redis主服务器绑定了127.0.0.1，那么跨服务器IP的访问就会失败，从服务器用IP和端口访问主的时候，主服务器发现本机6379端口绑在了127.0.0.1上，也就是只能本机才能访问，外部请求会被过滤，这是Linux的网络安全策略管理的。如果bind的IP地址是172.168.10.70，那么本机通过localhost和127.0.0.1、或者直接输入命令redis-cli登录本机redis也就会失败了。只能加上本机ip才能访问到。
所以，在研发、测试环境可以考虑bind 0.0.0.0，线上生产环境建议绑定IP地址。
1.3 事务控制
一般情况下 redis 在接受到一个 client 发来的命令后会立即处理并 返回处理结果，但是当一个 client 在一个连接中发出 multi 命令有，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到 exec 命令后，redis 会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给 client.然后此连接就 结束事务上下文。
1.3.1 简单事务控制
下面可以看一个例子
redis 127.0.0.1:6379> get age
"33"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set age 10
QUEUED
redis 127.0.0.1:6379> set age 20
QUEUED
redis 127.0.0.1:6379> exec
1) OK
2) OK
redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379>
从这个例子我们可以看到 2 个 set age 命令发出后并没执行而是被放到了队列中。调用 exec
后 2 个命令才被连续的执行，最后返回的是两条命令执行后的结果。
1.3.2 如何取消一个事务
我们可以调用 discard 命令来取消一个事务，让事务回滚。接着上面例子
redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set age 30
QUEUED
redis 127.0.0.1:6379> set age 40
QUEUED
redis 127.0.0.1:6379> discard
OK
redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379>
可以发现这次 2 个 set age 命令都没被执行。discard 命令其实就是清空事务的命令队列并退
出事务上下文，也就是我们常说的事务回滚。
1.3.3 乐观锁复杂事务控制
redis 127.0.0.1:6379> get age
"10"
redis 127.0.0.1:6379> watch age
OK
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379>
1.4 持久化机制
redis 支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另
一种是 Append-only file（缩写 aof）的方式。下面分别介绍:
1.4.1 snapshotting 方式
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,
默认的文件名为 dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis
在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置
save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存
save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存
save 60 10000 #10000 秒内容如超过 60 个 key 被修改，则发起快照保存
1.4.2 aof 方式
另外由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢
失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化
方式。
appendonly yes //启用 aof 持久化方式
# appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
# appendfsync no //完全依赖 os，性能最好,持久化没保证
