Redis3.0的主从、集群高可用
1. 安装Redis3.0
yum -y install cpp binutils glibc glibc-kernheaders glibc-common glibc-devel gcc make gcc-c++ libstdc++-devel tclnode
mkdir -p /usr/local/src/redisc++
cd /usr/local/src/redisredis
wget http://download.redis.io/releases/redis-3.0.2.tar.gz 或者 rz 上传算法
tar -xvf redis-3.0.2.tar.gz数据库
cd redis-3.0.2vim
make缓存
make test #这个就不要执行了，须要很长时间ruby
make install服务器
cp redis.conf /etc/网络
vi /etc/redis.conf
# 修改以下，默认为no
daemonize yes
#启动
redis-server /etc/redis.conf
#测试
redis-cli
2. 主从复制（读写分离）
主从复制的好处有2点：
一、 避免redis单点故障
二、 构建读写分离架构，知足读多写少的应用场景
2.1. 主从架构
2.1.1. 启动实例
建立6379、6380、6381目录，分别将安装目录下的redis.conf拷贝到这三个目录下。
分别进入这三个目录，分别修改配置文件，将端口分别设置为：6379（Master）、6380（Slave）、6381（Slave）。同时要设置pidfile文件为不一样的路径。
分别启动三个redis实例：
2.1.2. 设置主从
在redis中设置主从有2种方式：
一、 在redis.conf中设置slaveof
a) slaveof <masterip> <masterport>
二、 使用redis-cli客户端链接到redis服务，执行slaveof命令
a) slaveof <masterip> <masterport>
第二种方式在重启后将失去主从复制关系。
查看主从信息：INFO replication
主：
role：角色
connected_slaves：从库数量
slave0：从库信息
从：
2.1.3. 测试
在主库写入数据：
在从库读取数据：
2.2. 主从从架构
2.2.1. 启动实例
设置主从：
设置从从：
2.2.2. 测试
在主库设置数据：
在6380获取数据：
在6381获取数据：
2.3. 从库只读
默认状况下redis数据库充当slave角色时是只读的不能进行写操做。
能够在配置文件中开启非只读：slave-read-only no
2.4. 复制的过程原理
一、 当从库和主库创建MS关系后，会向主数据库发送SYNC命令；
二、 主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；
三、 当快照完成后，主Redis会将快照文件和全部缓存的写命令发送给从Redis；
四、 从Redis接收到后，会载入快照文件而且执行收到的缓存的命令；
五、 以后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；
2.5. 无磁盘复制
经过前面的复制过程咱们了解到，主库接收到SYNC的命令时会执行RDB过程，即便在配置文件中禁用RDB持久化也会生成，那么若是主库所在的服务器磁盘IO性能较差，那么这个复制过程就会出现瓶颈，庆幸的是，Redis在2.8.18版本开始实现了无磁盘复制功能（不过该功能仍是处于试验阶段）。
原理：
Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接经过网络发送给从数据库，避免了IO性能差问题。
开启无磁盘复制：repl-diskless-sync yes
2.6. 复制架构中出现宕机状况，怎么办？
若是在主从复制架构中出现宕机的状况，须要分状况看：
一、 从Redis宕机
a) 这个相对而言比较简单，在Redis中从库从新启动后会自动加入到主从架构中，自动完成同步数据；
b) 问题？ 若是从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将全部的数据作RDB操做吗？仍是增量更新？（从库有作持久化的前提下）
i. 不会的，由于在Redis2.8版本后就实现了，主从断线后恢复的状况下实现增量复制。
二、 主Redis宕机
a) 这个相对而言就会复杂一些，须要如下2步才能完成
i. 第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系而且提高为主库继续服务；
ii. 第二步，将主库从新启动后，执行SLAVEOF命令，将其设置为其余库的从库，这时数据就能更新回来；
b) 这个手动完成恢复的过程实际上是比较麻烦的而且容易出错，有没有好办法解决呢？当前有的，Redis提升的哨兵（sentinel）的功能。
3. 哨兵（sentinel）
3.1. 什么是哨兵
顾名思义，哨兵的做用就是对Redis的系统的运行状况的监控，它是一个独立进程。它的功能有2个：
一、 监控主数据库和从数据库是否运行正常；
二、 主数据出现故障后自动将从数据库转化为主数据库；
3.2. 原理
单个哨兵的架构：
多个哨兵的架构：
多个哨兵，不只同时监控主从数据库，并且哨兵之间互为监控。
3.3. 环境
当前处于一主多从的环境中：
3.4. 配置哨兵
启动哨兵进程首先须要建立哨兵配置文件：
vim sentinel.conf
输入内容：
sentinel monitor taotaoMaster 127.0.0.1 6379 1
说明：
taotaoMaster：监控主数据的名称，自定义便可，可使用大小写字母和“.-_”符号
127.0.0.1：监控的主数据库的IP
6379：监控的主数据库的端口
1：最低经过票数
启动哨兵进程：
redis-sentinel ./sentinel.conf
由上图能够看到：
一、 哨兵已经启动，它的id为9059917216012421e8e89a4aa02f15b75346d2b7
二、 为master数据库添加了一个监控
三、 发现了2个slave（由此能够看出，哨兵无需配置slave，只须要指定master，哨兵会自动发现slave）
3.5. 从数据库宕机
kill掉2826进程后，30秒后哨兵的控制台输出：
2989:X 05 Jun 20:09:33.509 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
说明已经监控到slave宕机了，那么，若是咱们将3380端口的redis实例启动后，会自动加入到主从复制吗？
2989:X 05 Jun 20:13:22.716 * +reboot slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
2989:X 05 Jun 20:13:22.788 # -sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
能够看出，slave重新加入到了主从复制中。-sdown：说明是恢复服务。
3.6. 主库宕机
哨兵控制台打印出以下信息：
2989:X 05 Jun 20:16:50.300 # +sdown master taotaoMaster 127.0.0.1 6379 说明master服务已经宕机
2989:X 05 Jun 20:16:50.300 # +odown master taotaoMaster 127.0.0.1 6379 #quorum 1/1
2989:X 05 Jun 20:16:50.300 # +new-epoch 1
2989:X 05 Jun 20:16:50.300 # +try-failover master taotaoMaster 127.0.0.1 6379 开始恢复故障
2989:X 05 Jun 20:16:50.304 # +vote-for-leader 9059917216012421e8e89a4aa02f15b75346d2b7 1 投票选举哨兵leader，如今就一个哨兵因此leader就本身
2989:X 05 Jun 20:16:50.304 # +elected-leader master taotaoMaster 127.0.0.1 6379 选中leader
2989:X 05 Jun 20:16:50.304 # +failover-state-select-slave master taotaoMaster 127.0.0.1 6379 选中其中的一个slave当作master
2989:X 05 Jun 20:16:50.357 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379 选中6381
2989:X 05 Jun 20:16:50.357 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379 发送slaveof no one命令
2989:X 05 Jun 20:16:50.420 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379 等待升级master
2989:X 05 Jun 20:16:50.515 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster 127.0.0.1 6379 升级6381为master
2989:X 05 Jun 20:16:50.515 # +failover-state-reconf-slaves master taotaoMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:50.566 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:51.333 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:52.382 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:52.438 # +failover-end master taotaoMaster 127.0.0.1 6379 故障恢复完成
2989:X 05 Jun 20:16:52.438 # +switch-master taotaoMaster 127.0.0.1 6379 127.0.0.1 6381 主数据库从6379转变为6381
2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6381 添加6380为6381的从库
2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 添加6379为6381的从库
2989:X 05 Jun 20:17:22.463 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 发现6379已经宕机，等待6379的恢复
能够看出，目前，6381位master，拥有一个slave为6380.
接下来，咱们恢复6379查看状态：
2989:X 05 Jun 20:35:32.172 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 6379已经恢复服务
2989:X 05 Jun 20:35:42.137 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 将6379设置为6381的slave
3.7. 配置多个哨兵
vim sentinel.conf
输入内容：
sentinel monitor taotaoMaster 127.0.0.1 6381 2
sentinel monitor taotaoMaster2 127.0.0.1 6381 1
3451:X 05 Jun 21:05:56.083 # +sdown master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.083 # +odown master taotaoMaster2 127.0.0.1 6381 #quorum 1/1
3451:X 05 Jun 21:05:56.083 # +new-epoch 1
3451:X 05 Jun 21:05:56.083 # +try-failover master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.086 # +vote-for-leader 3f020a35c9878a12d2b44904f570dc0d4015c2ba 1
3451:X 05 Jun 21:05:56.086 # +elected-leader master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.086 # +failover-state-select-slave master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.087 # +sdown master taotaoMaster 127.0.0.1 6381
3451:X 05 Jun 21:05:56.189 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.189 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:56.252 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:57.145 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:57.145 # +failover-state-reconf-slaves master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:57.234 * +slave-reconf-sent slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:58.149 * +slave-reconf-inprog slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:58.149 * +slave-reconf-done slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:58.203 # +failover-end master taotaoMaster2 127.0.0.1 6381
3451:X 05 Jun 21:05:58.203 # +switch-master taotaoMaster2 127.0.0.1 6381 127.0.0.1 6380
3451:X 05 Jun 21:05:58.203 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster2 127.0.0.1 6380
3451:X 05 Jun 21:05:58.203 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ taotaoMaster2 127.0.0.1 6380
4. 集群
即便有了主从复制，每一个数据库都要保存整个集群中的全部数据，容易造成木桶效应。
使用Jedis实现了分片集群，是由客户端控制哪些key数据保存到哪一个数据库中，若是在水平扩容时就必须手动进行数据迁移，并且须要将整个集群中止服务，这样作很是很差的。
Redis3.0版本的一大特性就是集群（Cluster），接下来咱们一块儿学习集群。
4.1. 架构
(1)全部的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
(2)节点的fail是经过集群中超过半数的节点检测失效时才生效.
(3)客户端与redis节点直连,不须要中间proxy层.客户端不须要链接集群全部节点,链接集群中任何一个可用节点便可
(4)redis-cluster把全部的物理节点映射到[0-16383]slot（插槽）上,cluster 负责维护node<->slot<->value
4.2. 修改配置文件
一、 设置不一样的端口，6379、6380、6381
二、 开启集群，cluster-enabled yes
三、 指定集群的配置文件，cluster-config-file "nodes-xxxx.conf"
4.3. 建立集群
4.3.1. 安装ruby环境
由于redis-trib.rb是有ruby语言编写的因此须要安装ruby环境。
yum -y install zlib ruby rubygems
gem install redis
手动安装：
rz上传redis-3.2.1.gem
gem install -l redis-3.2.1.gem
4.3.2. 建立集群
首先，进入redis的安装包路径下：
cd /usr/local/src/redis/redis-3.0.1/src/
执行命令：
./redis-trib.rb create --replicas 0 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381
--replicas 0：指定了从数据的数量为0
注意：这里不能使用127.0.0.1，不然在Jedis客户端使用时没法链接到！
redis-trib用法：
4.3.3. 测试
什么状况？？(error) MOVED 7638 127.0.0.1:6380
由于abc的hash槽信息是在6380上，如今使用redis-cli链接的6379，没法完成set操做，须要客户端跟踪重定向。
redis-cli -c
看到由6379跳转到了6380，而后再进入6379看可否get到数据
仍是被重定向到了6380，不过已经能够获取到数据了。
4.4. 使用Jedis链接到集群
添加依赖，要注意jedis的版本为2.7.2
说明：这里的jc不须要关闭，由于内部已经关闭链接了。
4.5. 插槽的分配
经过cluster nodes命令能够查看当前集群的信息：
该信息反映出了集群中的每一个节点的id、身份、链接数、插槽数等。
当咱们执行set abc 123命令时，redis是如何将数据保存到集群中的呢？执行步骤：
一、 接收命令set abc 123
二、 经过key（abc）计算出插槽值，而后根据插槽值找到对应的节点。（abc的插槽值为：7638）
三、 重定向到该节点执行命令
整个Redis提供了16384个插槽，也就是说集群中的每一个节点分得的插槽数总和为16384。
./redis-trib.rb 脚本实现了是将16384个插槽平均分配给了N个节点。
注意：若是插槽数有部分是没有指定到节点的，那么这部分插槽所对应的key将不能使用。
4.6. 插槽和key的关系
计算key的插槽值：
key的有效部分使用CRC16算法计算出哈希值，再将哈希值对16384取余，获得插槽值。
什么是有效部分？
一、 若是key中包含了{符号，且在{符号后存在}符号，而且{和}之间至少有一个字符，则有效部分是指{和}之间的部分；
a) key={hello}_tatao的有效部分是hello
二、 若是不知足上一条状况，整个key都是有效部分；
a) key=hello_taotao的有效部分是所有
4.7. 新增集群节点
再开启一个实例的端口为6382
执行脚本：
./redis-trib.rb add-node 192.168.56.102:6382 192.168.56.102:6379
已经添加成功！查看集群信息：
发现没有插槽数。
接下来须要给6382这个服务分配插槽，将6379的一部分（1000个）插槽分配给6382：
查看节点状况：
4.8. 删除集群节点
想要删除集群节点中的某一个节点，须要严格执行2步：
一、 将这个节点上的全部插槽转移到其余节点上；
a) 假设咱们想要删除6380这个节点
b) 执行脚本：./redis-trib.rb reshard 192.168.56.102:6380
c) 选择须要转移的插槽的数量，由于6380有5128个，因此转移5128个
d) 输入转移的节点的id，咱们转移到6382节点：82ed0d63cfa6d19956dca833930977a87d6ddf7
e) 输入插槽来源id，也就是6380的id
f) 输入done，开始转移
g) 查看集群信息，能够看到6380节点已经没有插槽了。
二、 使用redis-trib.rb删除节点
a) ./redis-trib.rb del-node 192.168.56.102:6380 4a9b8886ba5261e82597f5590fcdb49ea47c4c6c
b) del-node host:port node_id
c)
d) 查看集群信息，能够看到已经没有6380这个节点了。
4.9. 故障转移
若是集群中的某一节点宕机会出现什么情况？咱们这里假设6381宕机。
咱们尝试链接下集群，而且查看集群信息，发现6381的节点断开链接：
咱们尝试执行set命令，结果发现没法执行：
什么状况？集群不可用了？？ 这集群也太弱了吧？？
4.9.1. 故障机制
一、 集群中的每一个节点都会按期的向其它节点发送PING命令，而且经过有没有收到回复判断目标节点是否下线；
二、 集群中每一秒就会随机选择5个节点，而后选择其中最久没有响应的节点放PING命令；
三、 若是必定时间内目标节点都没有响应，那么该节点就认为目标节点疑似下线；
四、 当集群中的节点超过半数认为该目标节点疑似下线，那么该节点就会被标记为下线；
五、 当集群中的任何一个节点下线，就会致使插槽区有空档，不完整，那么该集群将不可用；
六、 如何解决上述问题？
a) 在Redis集群中可使用主从模式实现某一个节点的高可用
b) 当该节点（master）宕机后，集群会将该节点的从数据库（slave）转变为（master）继续完成集群服务；
4.9.2. 集群中的主从复制架构
架构：
出现故障：
4.9.3. 建立主从集群
须要启动6个redis实例，分别是：
6379（主） 6479（从）
6380（主） 6480（从）
6381（主） 6481（从）
启动redis实例：
cd 6379/ && redis-server ./redis.conf && cd ..
cd 6380/ && redis-server ./redis.conf && cd ..
cd 6381/ && redis-server ./redis.conf && cd ..
cd 6479/ && redis-server ./redis.conf && cd ..
cd 6480/ && redis-server ./redis.conf && cd ..
cd 6481/ && redis-server ./redis.conf && cd ..
建立集群，指定了从库数量为1，建立顺序为主库（3个）、从库（3个）：
./redis-trib.rb create --replicas 1 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381 192.168.56.102:6479 192.168.56.102:6480 192.168.56.102:6481
建立成功！查看集群信息：
4.9.4. 测试
保存、读取数据OK！
查看下6480的从库数据：
看到从6480查看数据也是被重定向到6380.
说明集群一切运行OK！
4.9.5. 测试集群中slave节点宕机
咱们将6480节点kill掉，查看状况。
查看集群状况：
发现6480节点不可用。
那么整个集群可用吗？
发现集群可用，可见从数据库宕机不会影响集群正常服务。
恢复6480服务：
测试6480中的数据：
看到已经更新成最新数据。
4.9.6. 测试集群中master宕机
假设6381宕机：
查看集群状况：
发现：
1、6381节点失效不可用
2、6481节点从slave转换为master
测试集群是否可用：
集群可用。
恢复6381：
发现：
1、6381节点可用
2、6481依然是主节点
3、6381成为6481的从数据库
4.10. 使用集群须要注意的事项
一、 多键的命令操做（如MGET、MSET），若是每一个键都位于同一个节点，则能够正常支持，不然会提示错误。
二、 集群中的节点只能使用0号数据库，若是执行SELECT切换数据库会提示错误。