4.提高了系统的伸缩性，比如多个slave专门用于客户端的读操作

　　5.可在master服务器上禁止数据持久化，而只在slave服务器上进行数据持久化操作

Redis主从复制的过程，分为两个阶段，第一个阶段如下：

（1）slave服务器主动连接到master服务器。
（2）slave服务器发送SYNC命令到master服务器请求同步数据。
（3）master服务器备份数据库到rdb文件。
（4）master服务器将该rdb文件传输给slave服务器。
（5）slave服务器清空数据库数据，把rdb文件数据导入数据库中。

完成第一阶段，接下来master服务器把用户所有更改数据的操作（写操作），通过命令的形式转发给slave服务器，slave服务器只需执行master服务器发送过来的命令就可以实现后续的同步效果。Redis的主从复制配置很简单，只需在slave服务器的配置文件中，添加下面的配置项：

指定master（主服务器）的ip和端口

slaveof 192.168.1.115 6379

如果主服务器设置了安全密码，还要加上这行代码进行授权

masterauth 密码

当从redis失去了与主redis的连接，或者主从同步正在进行中时，redis该如何处理外部发来的访问请求呢？这里，从redis可以有两种选择，第一种选择：如果slave-serve-stale-data设置为yes（默认），则从redis仍会继续响应客户端的读写请求。第二种选择：如果slave-serve-stale-data设置为no，则从redis会对客户端的请求返回“SYNC with master in progress”，当然也有例外，当客户端发来INFO请求和SLAVEOF请求，从redis还是会进行处理。设置从redis只读：

slave-read-only yes

配置完成后，重启redis从服务器，就已经通过主从复制实现了数据的同步。

4.安全：

我们可以要求redis客户端在向redis-server发送请求之前，先进行密码验证。由于redis性能非常高，所以每秒钟可以完成多达15万次的密码尝试，所以你最好设置一个足够复杂的密码，否则很容易被黑客破解，我们设置一个密码（芝麻开门）。
requirepass zhimakaimen

redis允许我们对redis指令进行更名，比如将一些比较危险的命令改个名字，避免被误执行。比如可以把CONFIG命令改成一个很复杂的名字，这样可以避免外部的调用，同时还可以满足内部调用的需要：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89

我们甚至可以禁用掉CONFIG命令，那就是把CONFIG的名字改成一个空字符串：

rename-command CONFIG ""

需要注意的是，如果你使用AOF方式进行数据持久化，或者需要与从redis进行通信，那么更改指令的名字可能会引起一些问题。

5.限制：

我们可以设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

maxclients 10000

我们甚至可以设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据，或者我们设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。但是对于无内存申请的指令，仍然会正常响应，比如GET等。默认设置为：

maxmemory <bytes>

需要注意的一点是，如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

对于内存移除规则来说，redis提供了多达6种的移除规则。他们是：

1.volatile-lru：使用LRU算法移除过期集合中的key
2.allkeys-lru：使用LRU算法移除key
3.volatile-random：在过期集合中移除随机的key
4.allkeys-random：移除随机的key
5.volatile-ttl：移除那些TTL值最小的key，即那些最近才过期的key。
6.noeviction：不进行移除。针对写操作，只是返回错误信息。

maxmemory-policy volatile-lru

LRU算法和最小TTL算法都并非是精确的算法，而是估算值。所以你可以设置样本的大小。假如redis默认会检查三个key并选择其中LRU的那个，那么你可以改变这个key样本的数量。

maxmemory-samples 3

6.追加模式--aof（redis持久化方法之二）：

 启用aof持久化方式

appendonly yes                     

日志追加（aof）方式比快照方式有更好的持久化性，如果启用了aof，Redis会将每一个收到的写命令通过write函数追加到文件appendonly.aof中，当Redis重启时，它会执行该文件中的所有命令，这样就可以在内存中重建整个redis数据库的内容。另外，操作系统内核的 I/O 接口可能存在缓存，所以日志追加方式不可能立即写入文件，这样就有可能丢失部分数据。幸运的是，Redis提供了解决方法，通过修改配置文件，告诉Redis应该在什么时候使用fsync函数强制操作系统把缓存中的写命令写入磁盘中的日志文件。有以下三种方法：

#appendfsync no                  是否写入磁盘完全依赖操作系统，性能最好，持久化没保证

#appendfsync always            在每次写请求后都调用fsync()。这种模式下，redis会相对较慢，但数据最安全。

appendfsync everysec          每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中，最多存在一秒钟的数据丢失情况
默认情况下为everysec