Redis集群

1.主从复制（读写分离）主从复制的好处有2点：1、避免redis单点故障2、构建读写分离架构，满足读多写少的应用场景1.1.主从架构1.1.1.启动实例创建6379、6380、6381目录，分别将安装目录下的redis.conf拷贝到这三个目录下。分别进入这三个目录，分别修改配置文件，将端口分别设置为：6379（Master）、6380（Slave）、6381（Slave）。同时要设置pidfile文件为不同的路径。分别启动三个redis实例：1.1.2.设置主从在redis中设置主从有2种方式：1、在redis.conf中设置slaveofa)slaveofmasteripmasterport2、使用redis-cli客户端连接到redis服务，执行slaveof命令a)slaveofmasteripmasterport第二种方式在重启后将失去主从复制关系。查看主从信息：INFOreplication主：role：角色connected_slaves：从库数量slave0：从库信息从：1.1.3.测试在主库写入数据：在从库读取数据：1.2.主从从架构1.2.1.启动实例设置主从：设置从从：1.2.2.测试在主库设置数据：在6380获取数据：在6381获取数据：1.3.从库只读默认情况下redis数据库充当slave角色时是只读的不能进行写操作。可以在配置文件中开启非只读：slave-read-onlyno1.4.复制的过程原理1、当从库和主库建立MS关系后，会向主数据库发送SYNC命令；2、主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的命令缓存起来；3、当快照完成后，主Redis会将快照文件和所有缓存的命令发送给从Redis；4、从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；5、之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；1.5.复制架构中出现宕机情况，怎么办？如果在主从复制架构中出现宕机的情况，需要分情况看：1、从Redis宕机a)这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；b)问题？如果从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将所有的数据做RDB操作吗？还是增量更新？（从库有做持久化的前提下）i.不会的，因为在Redis2.8版本后就实现了，主从断线后恢复的情况下实现增量复制。2、主Redis宕机a)这个相对而言就会复杂一些，需要以下2步才能完成i.第一步，在从数据库中执行SLAVEOFNOONE命令，断开主从关系并且提升为主库继续服务；ii.第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；b)这个手动完成恢复的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，Redis提高的哨兵（sentinel）的功能。1.6.无磁盘复制通过前面的复制过程我们了解到，主库接收到SYNC的命令时会执行RDB过程，即使在配置文件中禁用RDB持久化也会生成，那么如果主库所在的服务器磁盘IO性能较差，那么这个复制过程就会出现瓶颈，庆幸的是，Redis在2.8.18版本开始实现了无磁盘复制功能（不过该功能还是处于试验阶段）。原理：Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接通过网络发送给从数据库，避免了IO性能差问题。开启无磁盘复制：repl-diskless-syncyes2.哨兵（sentinel）2.1.什么是哨兵顾名思义，哨兵的作用就是对Redis的系统的运行情况的监控，它是一个独立进程。它的功能有2个：1、监控主数据库和从数据库是否运行正常；2、主数据出现故障后自动将从数据库转化为主数据库；2.2.原理单个哨兵的架构：多个哨兵的架构：多个哨兵，不仅同时监控主从数据库，而且哨兵之间互为监控。2.3.环境当前处于一主多从的环境中：2.4.配置哨兵启动哨兵进程首先需要创建哨兵配置文件：vimsentinel.conf输入内容：sentinelmonitortaotaoMaster127.0.0.163791说明：taotaoMaster：监控主数据的名称，自定义即可，可以使用大小写字母和“.-_”符号127.0.0.1：监控的主数据库的IP6379：监控的主数据库的端口1：最低通过票数启动哨兵进程：redis-sentinel./sentinel.conf由上图可以看到：1、哨兵已经启动，它的id为9059917216012421e8e89a4aa02f15b75346d2b72、为master数据库添加了一个监控3、发现了2个slave（由此可以看出，哨兵无需配置slave，只需要指定master，哨兵会自动发现slave）2.5.从数据库宕机kill掉2826进程后，30秒后哨兵的控制台输出：2989:X05Jun20:09:33.509#+sdownslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.16379说明已经监控到slave宕机了，那么，如果我们将3380端口的redis实例启动后，会自动加入到主从复制吗？2989:X05Jun20:13:22.716*+rebootslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.163792989:X05Jun20:13:22.788#-sdownslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.16379可以看出，slave从新加入到了主从复制中。-sdown：说明是恢复服务。2.6.主库宕机哨兵控制台打印出如下信息：2989:X05Jun20:16:50.300#+sdownmastertaotaoMaster127.0.0.16379说明master服务已经宕机2989:X05Jun20:16:50.300#+odownmastertaotaoMaster127.0.0.16379#quorum1/12989:X05Jun20:16:50.300#+new-epoch12989:X05Jun20:16:50.300#+try-failovermastertaotaoMaster127.0.0.16379开始恢复故障2989:X05Jun20:16:50.304#+vote-for-leader9059917216012421e8e89a4aa02f15b75346d2b71投票选举哨兵leader，现在就一个哨兵所以leader就自己2989:X05Jun20:16:50.304#+elected-leadermastertaotaoMaster127.0.0.16379选中leader2989:X05Jun20:16:50.304#+failover-state-select-slavemastertaotaoMaster127.0.0.16379选中其中的一个slave当做master2989:X05Jun20:16:50.357#+selected-slaveslave127.0.0.1:6381127.0.0.16381@taotaoMaster127.0.0.16379选中63812989:X05Jun20:16:50.357*+failover-state-send-slaveof-nooneslave127.0.0.1:6381127.0.0.16381@taotaoMaster127.0.0.16379发送slaveofnoone命令2989:X05Jun20:16:50.420*+failover-state-wait-promotionslave127.0.0.1:6381127.0.0.16381@taotaoMaster127.0.0.16379等待升级master2989:X05Jun20:16:50.515#+promoted-slaveslave127.0.0.1:6381127.0.0.16381@taotaoMaster127.0.0.16379升级6381为master2989:X05Jun20:16:50.515#+failover-state-reconf-slavesmastertaotaoMaster127.0.0.163792989:X05Jun20:16:50.566*+slave-reconf-sentslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.163792989:X05Jun20:16:51.333*+slave-reconf-inprogslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.163792989:X05Jun20:16:52.382*+slave-reconf-doneslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.163792989:X05Jun20:16:52.438#+failover-endmastertaotaoMaster127.0.0.16379故障恢复完成2989:X05Jun20:16:52.438#+switch-mastertaotaoMaster127.0.0.16379127.0.0.16381主数据库从6379转变为63812989:X05Jun20:16:52.438*+slaveslave127.0.0.1:6380127.0.0.16380@taotaoMaster127.0.0.16381添加6380为6381的从库2989:X05Jun20:16:52.438*+slaveslave127.0.0.1:6379127.0.0.16379@taotaoMaster127.0.0.16381添加6379为6381的从库2989:X05Jun20:17:22.463#+sdownslave127.0.0.1:6379127.0.0.16379@taotaoMaster127.0.0.16381发现6379已经宕机，等待6379的恢复可以看出，目前，6381位master，拥有一个slave为6380.接下来，我们恢复6379查看状态：2989:X05Jun20:35:32.172#-sdownslave127.0.0.1:6379127.0.0.16379@taotaoMaster127.0.0.163816379已经恢复服务2989:X05Jun20:35:42.137*+convert-to-slaveslave127.0.0.1:6379127.0.0.16379@taotaoMaster127.0.0.16381将6379设置为6381的slave2.7.配置多个哨兵vimsentinel.conf输入内容：sentinelmonitortaotaoMaster127.0.0.163812sentinelmonitortaotaoMaster2127.0.0.1638113451:X05Jun21:05:56.083#+sdownmastertaotaoMaster2127.0.0.163813451:X05Jun21:05:56.083#+odownmastertaotaoMaster2127.0.0.16381#quorum1/13451:X05Jun21:05:56.083#+new-epoch13451:X05Jun21:05:56.083#+try-failovermastertaotaoMaster2127.0.0.163813451:X05Jun21:05:56.086#+vote-for-leader3f020a35c9878a12d2b44904f5