Redis-cluster 是近年来 Redis 架构不断改进中的绝对较好的 Redis 高可用计划。本文波及到近年来 Redis 多实例架构的演变过程，包含一般主从架构（Master、slave 可进行写读拆散）、哨兵模式下的主从架构、Redis-cluster 高可用架构（Redis 官网默认 cluster 下不进行读写拆散）的简介。同时还介绍应用Java的两大redis客户端：Jedis与Lettuce用于读写redis-cluster的数据的个别办法。再通过官网文档以及互联网的相干技术文档，给出redis-cluster架构下的读写能力的优化计划，包含官网的举荐的扩大redis-cluster下的Master数量以及非官方默认的redis-cluster的读写拆散计划，案例中应用Lettuce的特定办法进行redis-cluster架构下的数据读写拆散。
近年来redis多实例用架构的演变过程
redis是基于内存的高性能key-value数据库，若要让redis的数据更稳固平安，须要引入多实例以及相干的高可用架构。而近年来redis的高可用架构亦不断改进，先后呈现了本地长久化、主从备份、哨兵模式、redis-cluster群集高可用架构等等计划。
1、redis一般主从模式
通过长久化性能，Redis保障了即便在服务器重启的状况下也不会损失（或大量损失）数据，因为长久化会把内存中数据保留到硬盘上，重启会从硬盘上加载数据。然而因为数据是存储在一台服务器上的，如果这台服务器呈现硬盘故障等问题，也会导致数据失落。为了防止单点故障，通常的做法是将数据库复制多个正本以部署在不同的服务器上，这样即便有一台服务器呈现故障，其余服务器仍然能够持续提供服务。为此，在www.sangpi.com里退出 Redis 提供了复制（replication）性能，能够实现当一台数据库中的数据更新后，主动将更新的数据同步到其余数据库上。
在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库（slave）。主数据库能够进行读写操作，当写操作导致数据变动时会主动将数据同步给从数据库。而从数据库个别是只读的，并承受主数据库同步过去的数据。一个主数据库能够领有多个从数据库，而一个从数据库只能领有一个主数据库。
0c9ca9b3f2dfaa3c10d6e1777d4a7cb5.png
主从模式的配置，个别只须要再作为slave的redis节点的conf文件上退出“slaveof masterip masterport”， 或者作为slave的redis节点启动时应用如下参考命令：
redis-server --port 6380 --slaveof masterIp masterPort
redis的一般主从模式，能较好地防止独自故障问题，以及提出了读写拆散，升高了Master节点的压力。互联网上大多数的对redis读写拆散的教程，都是基于这一模式或架构下进行的。但实际上这一架构并非是目前最好的redis高可用架构。
2、redis哨兵模式高可用架构
当主数据库遇到异常中断服务后，开发者能够通过手动的形式抉择一个从数据库来升格为主数据库，以使得零碎可能持续提供服务。然而整个过程绝对麻烦且须要人工染指，难以实现游戏自动化。 为此，Redis 2.8开始提供了哨兵工具来实现自动化的系统监控和故障复原性能。 哨兵的作用就是监控redis主、从数据库是否失常运行，主呈现故障主动将从数据库转换为主数据库。
顾名思义，哨兵的作用就是监控Redis零碎的运行状况。它的性能包含以下两个。
（1）监控主数据库和从数据库是否失常运行。
（2）主数据库呈现故障时主动将从数据库转换为主数据库。
c3e2ab7f383c61fb5260236d18c33cc9.png
能够用info replication查看主从状况 例子： 1主2从 1哨兵,能够用命令起也能够用配置文件里 能够应用双哨兵，更平安，参考命令如下：
3e9140c3ec928e374fbb5d5777a5e7c8.png
其中，哨兵配置文件sentinel.conf参考如下：
sentinel monitor mymaster 192.168.0.167 6379 1
其中mymaster示意要监控的主数据库的名字。配置哨兵监控一个零碎时，只须要配置其监控主数据库即可，哨兵会主动发现所有复制该主数据库的从数据库。
Master与slave的切换过程：
（1）slave leader降级为master
（2）其余slave批改为新master的slave
（3）客户端批改连贯
（4）老的master如果重启胜利，变为新master的slave
3、redis-cluster群集高可用架构
即便应用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是残缺的数据，节约内存且有木桶效应。为了最大化利用内存，能够采纳cluster群集，就是分布式存储。即每台redis存储不同的内容。
采纳redis-cluster架构正是满足这种分布式存储要求的集群的一种体现。redis-cluster架构中，被设计成共有16384个hash slot。每个master分得一部分slot，其算法为：hash_slot = crc16(key) mod 16384 ，这就找到对应slot。采纳hash slot的算法，实际上是解决了redis-cluster架构下，有多个master节点的时候，数据如何散布到这些节点下来。key是可用key，如果有{}则取{}内的作为可用key，否则整个能够是可用key。群集至多须要3主3从，且每个实例应用不同的配置文件。
5047c9d4d9b6ede2c65b191f7ac3c676.jpeg
在redis-cluster架构中，redis-master节点个别用于接管读写，而redis-slave节点则个别只用于备份，其与对应的master领有雷同的slot汇合，若某个redis-master意外生效，则再将其对应的slave进行降级为长期redis-master。
在redis的官网文档中，对redis-cluster架构上，有这样的阐明：在cluster架构下，默认的，个别redis-master用于接管读写，而redis-slave则用于备份，当有申请是在向slave发动时，会间接重定向到对应key所在的master来解决。但如果不介意读取的是redis-cluster中有可能过期的数据并且对写申请不感兴趣时，则亦可通过readonly命令，将slave设置成可读，而后通过slave获取相干的key，达到读写拆散。