前言：随着web2.0的进一步发展，网民的生产力进一步提升，存储总量开始增加。 此时虽然仍然是读多写少的模式，但写入量已经大大提升。 原有的缓存技术不能缓解写入压力，而且原有的空间也受硬盘限制，因此开始出现分库分表，实现读写分离。 集中模式的数据库就这样开始逐渐分化：由一个集中的、稳定的、强关系的结构，朝一个分化的、容错的、弱关系的结构发展。 数据的存储空间与数据访问时间也进一步分离。 即原来是数据存在什么地方，就去什么地方访问。现在是数据还是存在老地方(硬盘)，但是访问却在另一个地方(比如内存，或另一个服务器)。其目的，就在于缩短IO路径或分离IO，实现高效访问。
Redis主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主，这样就可以减轻服务器的压力了。
Redis主从复制之配置介绍
复制的原理介绍
slave启动成功连接到master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
case 1：一主N从
（在这里我只使用了一台Linux机器，但是通过配置同样可以达到Redis集群的需求，如果有多个服务器，配置是一样的）
首先从拷贝3个redis.conf文件（拷贝两个也是可以的，这里我是为了区分Master/Slave）
那么接下来就是修改配置了
- 主机配置介绍（为了说明在主从复制的时候访问的不是同一个数据库文件，将数据库文件名也相应的修改）
- 从机配置介绍
从机6380配置
从机6381配置
OK配置完成了，那么接下来就是启动redis服务并连接，查看配置是否有效
通过info replication命令查看信息
我们可以看到，3台服务器的redis服务成功启动，角色都是master，那么接下来就是要区分主从库了，通过命令slaveof 主机IP 主机redis端口
slaveof 127.0.0.1 6379
这样就可以了，然后再次通过info replication命令查看，发现这个时候端口号为6380,6381的redis从主库变成了从库
那么这个时候在主库中执行写的操作
在set k4之前做了set k1，k2，k3操作，然后6380，6381作为从库连接主库，发现主库中所有的数据在从库中都有，而且每个从库都有数据库文件
那么在这个时候我们在从库执行write操作的时候，发现是无法正确执行的
因为有了从库之后，读写就已经分离了，所以在从库中只能执行读的操作
上面呢我是通过命令的方式实现主从库的分离的，那么大家就会发现，这样子是很麻烦的，万一从库redis服务挂了之后，再次启动redis服务之后还要执行
slaveof 127.0.0.1 6369
这样子是很不人性化的，而且也是非常的麻烦，那么接下来就通过配置文件的方式实现主从库的分离
其他的从库也是这样配置，OK，配置已经好了，那么接下来就是启动redis服务了
我们可以看到，当redis服务启动之后，角色立马变成从库了，而不要向我们之前的需要手动敲命令，这样也是挺方便的
上面的case 1呢讲到了一主N从得模式
那么redis从库是否可以让其他的redis服务连接呢？
case 2：传宗接代
传宗接代的意思呢就是说一个主库下只有一个从库，而这个从库下又有其他的redis从库跟着。一个跟着一个，而不是一个主库下有跟着N个从库，这样子呢就可以去中心化，但是这样子呢会出现数据复制的延时，因为你是一个跟着一个，在主库中有数据的变化，那么下面的从库就会立即复制，但是这个时候只有一个从库，要等当前从库复制完成才可以再次向下复制
配置
将其中一台的配置修改
启动redis服务
服务启动成功，那么中间那一台连着主库的那个redis（也就是直连主库然后下面又跟着从库的那台）是什么角色呢？
可以看到，中间的那个redis从库依然是从库的角色，但是下面又跟着小弟。但是呢这个时候还是无法执行write的操作，因为中间的那个依旧是从库的角色
redis的主从复制，读写分离就到告一段落了，下一次为大家继续讲解redis集群的哨兵模式
