CentOS 6.5 -- Redis 4.0.2读写分离☞主从架构
讲之前，我先来随性的扯一扯什么是redis，大多说法是缓存数据库，但是如果只说是缓存，给人的感觉就是数据放在内存中随时会因为系统断电而造成数据的丢失，如果说是数据库，又给人感觉这和MSSQL、Mysql以及Oracle又有什么区别呢？事实上，redis也不能单独的作为数据库来使用，因为它支持的数据类型有限，想向常规数据库那样存放表结构的数据，显得有些无力，当然不是不行，但我们为什么要用redis做这些事情呢？
能和数据库沾边的，redis肯定具有存储数据的能力（持久化），和缓存沾边，说明redis读写数据快，你想想，你直接从内存中取出数据快啊，还是，先进行I/O操作，将数据加载到内存，再从内存中读取快呢？当然，是前者，没错，redis就是这么干的，它就好比多一个多功能的冰箱，假如我们把常用的变化不是很频繁的数据比作是美味的话，我们需要的时候，从redis中直接get key（'美味'）就行，而且取出来我们发现还是热的。但是如果是MSSql或者是Mysql数据库的话，同样我们也能取出来美味，但是我们发现，美味是凉的，然后我们还要拿去加热一下，随后才能享用，这就不划算了；
而且，在redis中，我们可以设置持久化数据的方式，选择对美味进行保鲜（冷冻），怎么理解这种保鲜功能呢？就是，防止美味变质，留到下次或者下下次或者下下下次我们再享用，用redis的话说就是，数据我先持久化到磁盘文件（默认快照Snapshotting持久化方式，将内存中的数据以快照的方式写入到二进制文件中，默认文件名为dump.rdb），等下次redis服务启动的时候，再把这些持久化到磁盘文件里面的数据再加载到内存中，这就使得，数据达到一种复用的效果，有人会想，我怎么知道哪些数据我想复用，哪些数据我不想复用呢？万一，持久化的数据文件太大了影响redis性能怎么办？ 不用担心好吧，这些都是可以配置的，大不了，你直接将redis持久化到本地磁盘的数据文件直接干掉，哈哈，那你可真是厉害了。
以上纯粹就是个人观点，浅显的理解了一下redis，我觉得，要想学好（可不是精通啊）一门技术，首先，就是要理解，不管你理解的官方不官方，起码，你拿到 了开启这门技术的钥匙，至于，打开的是哪一扇门，看个人造化了！
看一下官方的redis词条:
另一个数据架构是主从从架构，这个比主从架构复杂一点，博文里，我就不讲了，可以作为兴趣自行进行配置和测试。
主从架构关系图（从库还可以有更多，但是开多了，一方便会影响redis性能另一方面会增加服务器的开销）
（1）redis单点故障
A.如果只使用一台服务器，作为redis的部署节点的话，万一这台机子挂掉了，是不是我们的redis就瘫痪了，这种显然不够友好；
B.因此，redis给我们提供了主--从关系，主库用master表示，从库用slave表示，当然，主从架构中，主库master只能有一个，从库可以有多个，主库和从库之间通过相互通信，进行数据同步，并且做RDB持久化操作；
C.主库节点如果挂掉了，redis有个哨兵（sentinel）配置，可以监控整个主-从架构中的故障节点，并从剩下的从库中选举出一个节点来当主库，并调整架构中的主从关系，最后，哨兵会等待发生故障的主库节点恢复，当然，如果这个宕机的主库节点恢复过来了，那么，它将会被哨兵重新分配成从库，而不是主库！
D.如果是从库节点挂掉了，不用担心好吧，一方面这不会影响架构中的主从关系，另一方面，等这个从库故障点恢复的时候，直接又连接上了主库节点，同时从主库获得同步数据，所以这种情况，是比较友好的！
（2）redis的读写分离
A.如果redis实例是主库master性质的，那么它具有读和写的权限
B.如果redis实例是从库slave性质的， 那么它默认是不具有写权限的，当然你可以设置从库slave具有写权限，一般不推荐这样做！
根据上一篇，Redis 4.0.2实例启动 继续讲
一、我们目前只建立了一个redis实例，端口6379，我们将这个实例设为master节点
我们还需要两个slave节点（两个演示主---从架构足够了）
二、我们直接将6379目录整体copy成两个新的目录，一个是6380，一个是6381
（还记得上一篇说的吗，目录的名称代表了当前redis实例使用的端口号，因为，使用的是一台虚拟机，只能从Port上区别不同的实例）
A.创建6380实例
cp -R 6379 6380/
修改6380对应的redis.conf,只需替换里面的 6379 ---> 6380 就行，指定主从关系，我们稍后再讲
vim redis.conf
:%s/6379/6380/g -----> 做全局字符串替换
保存并退出后，启动6380实例
B.创建6381实例
cd .. (注意目录的切换)
和创建6380实例的步骤一样，这里就不细说了，配置好后，启动6381实例如下
C.常看所有后台运行的redis实例
ps -ef | grep redis
三、建立主从关系
我们一开始说了，6379实例作为master主库节点，6380和6381分别作为从库节点，而redis.conf是根据
slaveof
masterip ：主库IP，本篇就是一台机子上，bind 就是 127.0.0.1，因此，所有IP都是127.0.0.1
masterport：主库的端口号，比如，从库是6380，则配置它的主库节点应该这样写：slaveof 127.0.0.1 6379
我们不采用直接改conf文件的方式指定主从关系，我们通过，redis-cli连接对应的实例，直接在实例中通过slaveof指定主从关系
A.没有指定主从关系之前
实例6379中，查看实例 INFO属性
redis-cli
INFO replication
在当前实例下，创建一个数据（key-value）
set abc 123
然后退出，再切换到6380实例
设置6380的主从属性，指定主库为 实例6379
slaveof 127.0.0.1 6379
这时候，是否可以在从库6380实例里面查询到主库实例6379里面的数据吗（假设不知道主从数据是否已经同步过来了）？试一试
注意：这个同步是有时间间隔的，如果你建立了主从关系后，立马在从库里面进行key查询，可能查不到数据，不要慌，这时候，只是主从库之间还没有完成数据同步而已。
我们再尝试着，在从库6380实例里面写入一个数据试试
set name appleyk
显然，从库默认是不能写的，如果你非要写，可以修改对应实例的redis.conf，里面有个只读属性可以进行设置
这不是重点，重点是，主从进行同步数据的时候，会进行数据的持久化操作吗？
我们退出当前实例的连接，进入主库6379实例的目录ll一下
咦，怎么会有个dump.rdb文件呢？我们在上一篇中不是已经关闭了默认的持久化方式吗，怎么在实例6379的目录下会有这个文件呢？当然，这个文件在从库实例6380的目录下面也是有的，因为主从之间有数据同步
为什么会这样呢？
我们看一下 主从数据复制过程的原理
1、 当从库和主库建立M-S关系后，会向主数据库发送SYNC命令；
2、 主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；
3、 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；
4、 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；
5、 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；
剩下的那个6381实例，道理和6380是一样的，这里就不再继续做说明了。
未完待续！