Redis主从集群构建与主从复制原理分析
前言本文介绍了如何在Redis集群中构建片集群，以及片集群的性能和集群数据的迁移方法； 这消除了内存瓶颈，Redis现在可以存储10G或更大的海量数据。
Redis集群构建redis5集群构建提取代码为ch2i
在redis.conf中更改对应的端口号数据dir数据
需要启动多个集群
如果需要创建随机主从，可以直接使用--cluster-replicas命令，这里使用的3主从
如果发生散列插槽等占用情况，可以使用集群节点确定占用端口号是否被占用
使用cluster slots显示插槽分配节点分配以获取节点id，删除插槽节点，然后单击sudo redis-CLI-- cluster del-node 192.168.100.23360700000
刷新一下
官方网站上对集群的命令支持，包括自动分配hash插槽。
重新调整redis集群的命令，包含集群重置
安装过程中需要查找命令。 必须使用help命令。 一个是针对集群的
cli中的“查找节点”节点包含常用命令，如info复制集
使用以下命令，包括在运行过程中需要分配多个哈希槽时
这里注意偏移插槽的位置，只注意没有数据的移动
Cluster hash槽一些常见的问题
# 1、增加了插槽的计算。 性能不是比单体差吗？ 公开了合计16384插槽、slots插槽计算方式的是，在java客户端中，为了不需要hash_slot=CRC16(key ) mod 16384每次都进行服务器计算的重定向，而公开了良好的java客户端# 2、redis群集大小理论最多可达16384个插槽，但redis公式的建议最多为1000个实例# 3、批量操作或# 4、群集meet命令的总线端口是什么？ meet IP端口[总线端口]每个Redis群集节点都有其他TCP端口，用于接收来自其他Redis群集节点的传入连接# 5。 群集节点之间的通信方法每个节点都使用TCP连接连接到其他每个节点。 # 6、ask与moved重定向的区别重定向有两种情况。 如果确定slot不属于当前节点，则redis返回moved。 如果当前redis节点正在处理slot迁移，则代表此处请求相应的密钥暂时不在此节点上，并返回ask。 告知客户端如何解决此请求的重定向# 7、数据倾斜和访问倾斜问题，以协调key的战略slot迁移流程。 在目标节点上运行clustersetslotslotimportingnodeid命令，指定需要迁移的slot和源节点。 在源节点上运行clustersetslotslotmigratingnodeid命令，以指示需要迁移的slot和目标节点。 在源节点上运行cluster getkeysinslot以获取该slot的密钥列表。 在源节点上对每个key运行migrate命令。 此命令同时将其key迁移到目标节点。 在源节点上，重复运行cluster getkeysinslot命令，直到slot列表为空。 在源节点和目标节点上运行群集集插槽节点id，以完成迁移操作。 在#8节点之间交换信息，且发布包含时隙信息的消息以引起带宽消耗。 注意：可以避免使用大的一个集群，分为多个集群。 #9，Pub/Sub分发订阅机制注意：如果对集群中的任何一个节点运行publish分发消息，则该消息在集群中传播，而另一节点接收所分发的消息。 #10、读写分离redis-cluster所有默认从节点上的读写操作，可以在key坞站主节点上通过readonly设置当前连接的读写能力，通过readwrite解除当前连接的读写能力主从节点仍然存在数据不匹配问题的Redis Cluster 为什么要实现Redis Cluster主从复制无法提供高可用性。 随着公司的发展，用户数量增加，同时增加，业务需要更高的QPS，而主从复制无法满足业务所需数据量的考虑，现有服务器内存不能满足业务数据需求时，只需简单地在服务器上添加内存在此情况下，考虑到分布式需求，需要将数据分布式到不同服务器的网络业务需求。 业务流量已经超过服务器网卡的上限，可以考虑使用方差进行分流计算。 需要其他需求(如中间缓冲区)的默认主从复制群集完全不满足要求。
/公司的用户数为3千万人
用户基本信息缓存到redis中，需要内存10G，如何设计Redis的缓存架构？ 1. 3千万用户，各种业务场景对用户信息的访问量很大。（单台redis示例的读写瓶颈凸显）2. 单redis实例管理10G内存，必然影响处理效率。3. redis的内存需求可能超过机器的最大内存。 （一台机器不够用）引出的分片集群
概述 redis cluster是Redis的分布式集群解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求 实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制等功能。 这里去选择去那个 redis-server，根据一定的算法去找，这在持久化数据库存储海量数据是实现了的 比如mycat,但mycat做的更好的是，将分片规则更加变细了，这里是默认的 计算hash数值crc(16) 计算出hash槽的位置 预设槽slot hash值 % 16383 能快速找到数据 对于redis中采用的方式，是采用的虚拟槽，这个槽的大小是16384的大小，而每个槽，这里为什么采用这个大小，作者的意思是空间利用率是最好的，槽的作用将数据打散利用hash也好以及客户端入如果需要获取数据，根据计算出的槽，随便找一台，并且为了快速找到目标值，也就是每个机子上都维护了一所有的hash槽并对应的ip地址，因此能快速重定向还有些客户端 会自己存储 所有的hash槽和 ip地址 就能快速找到服务端客户端缓存 slot分配信息 发生命令前，客户端进行slot计算、根据slot分配信息，定位到redisserver
而什么时候进行更新 重新分配槽信息：定时刷新、收到重定向的响应。
请求的时候，本地进行更新数据。
这里在客户端中中重定向
如果需要他自动重定向，则需要添加-c命令
分片高可用在所有的集群的进行连接都是采用集群总线进行连接 (n-1)*2 个进行通信，n表示节点的个数； 从这里可以看出10000的端口号对应着集群的通信，20000的端口号对应哨兵的选取，还有客户端进行通信。
集群总线，客户端口号+10000 每个节点之间都有对应的节点的传入传出TCP连接，用于节点到节点的通信，整体形成一个网络拓扑。避免消息交换太多，用gossip协议进行一种定时传播的信息的协议。
每个节点都有进出的通信，对应着这么(n-1)*2个通信
P2P 网络核心技术：Gossip 协议
高可用达到的情况是可以把c的从节点移动，当A的主节点没有从节点时，移动到A上
这样做的好处，分片自带故障转移的功能。
分片扩容 启动新节点 加入到已经存在的集群作为master
/usr/local/redis/jmdyx/redis-cli --cluster add-node 192.168.100.242:6387 192.168.100.242:6382
本质就是发送一个新节点通过 CLUSTER MEET命令加入集群
新节点没有分配hash槽
加入到已经存在的集群作为slave
/usr/local/redis/jmdyx/redis-cli --cluster add-node 192.168.100.242:7006 192.168.100.242:7000 --cluster-slave
可以手工指定master，否则就是选择一个slave数量较少的master 这里是智能添加到少节点的master上的
/usr/local/redis/jmdyx/redis-cli --cluster add-node 192.168.100.242:7006 192.168.100.242:7000 --cluster-slave --cluster-master-id <node-id>
还可以将空master，转换为slave
cluster replicate <master-node-id>
检查集群
/usr/local/redis/jmdyx/redis-cli --cluster check 192.168.100.242:6382
这里通过cluster nodes 命令去查看集群节点的分布情况
分片缩容删除master的时候要把数据清空或者分配给其他主节点
/usr/local/redis/jmdyx/redis-cli --cluster del-node 192.168.100.242:6381 <node-id>
集群slot迁移 slot手动迁移过程 在迁移目的节点执行cluster setslot <slot> IMPORTING <node ID>命令，指明需要迁移的slot和迁移源节点。 在迁移源节点执行cluster setslot <slot> MIGRATING <node ID>命令，指明需要迁移的slot和迁移目的节点。 在迁移源节点执行 cluster getkeysinslot获取该slot的key列表. 在迁移源节点执行对每个keyy执行migrate命令，该命令会同步把该key迁移到目的节点。 在迁移源节点反复执行cluster getkeysinslot命令，直到该slot的列表为空。 在迁移源节点和目的节点执行cluster setslot <slot> NODE <node ID>，完成迁移操作。 集群从节点迁移redis 集群实现了一个叫做复制(从节点) 迁移的概念，以提高系统的可用性
假设集群有三个主节点 A，B，C。 A、B都各有一个从节点，A1 和 B1。节点C有两个从节点：C1 和 C2 迁移过程如下，大致描述如下： - 主节点 A 失效。A1 被提升为主节点。 - 节点 C2 迁移成为节点 A1 的从节点，要不然 A1 就没有任何从节点。 - 三个小时后节点 A1 也失效了。 - 节点 C2 被提升为取代 A1 的新主节点。 - 集群仍然能继续正常工作。