redis集群数据迁移方式、宕机

数据迁移方式

转载：https://blog.csdn.net/tianpeng341204/article/details/78963850

Redis Cluster数据分片机制

基础概念

集群：是一个提供多个Redis（分布式）节点间共享数据的程序集。

集群部署：Redis 集群的键空间被分割为 16384 hash个槽（slot），集群的最大节点数量也是 16384 个

关系：cluster>node>slot>key

分片：
Redis Cluster在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现；

一个 Redis Cluster包含16384（0~16383）个哈希槽，存储在Redis Cluster中的所有键都会被映射到这些slot中，

集群中的每个键都属于这16384个哈希槽中的一个，集群使用公式slot=CRC16（key）/16384来计算key属于哪个槽，其中CRC16(key)语句用于计算key的CRC16 校验和。

按照槽来进行分片，通过为每个节点指派不同数量的槽，可以控制不同节点负责的数据量和请求数.

当前集群有3个节点,槽默认是平均分的:
节点 A （6381）包含 0 到 5499号哈希槽.
节点 B （6382）包含5500 到 10999 号哈希槽.
节点 C （6383）包含11000 到 16383号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我像移除节点A,需要将A中得槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

数据迁移

数据迁移可以理解为slot(槽)和key的迁移，这个功能很重要，极大地方便了集群做线性扩展，以及实现平滑的扩容或缩容。

现在要将Master A节点中编号为1、2、3的slot迁移到Master B节点中，在slot迁移的中间状态下，slot 1、2、3在Master A节点的状态表现为MIGRATING（迁移）,在Master B节点的状态表现为IMPORTING（入口）。

数据迁移时，客户端的影响

当 slot 数据从源节点迁移到目标节点时，期间可能出现一部分数据在源节点，而另一部分在目标节点。

客户端命令执行流程如下所示：

客户端根据本地 slot 缓存发送命令到源节点，如果存在键对应则直接执行并返回结果给客户端。
如果节点返回 MOVED 错误，更新本地的 slot 到 Redis 节点的映射关系，然后重新发起请求。
如果数据正在迁移中，节点会回复 ASK 重定向异常。格式如下: ( error ) ASK { slot } { targetIP } : { targetPort }

客户端从 ASK 重定向异常提取出目标节点信息，发送 asking 命令到目标节点打开客户端连接标识，再执行键命令。

ASK 和 MOVED 虽然都是对客户端的重定向控制，但是有着本质区别。ASK 重定向说明集群正在进行 slot 数据迁移，客户端无法知道什么时候迁移完成，因此只能是临时性的重定向，客户端不会更新 slot 到 Redis 节点的映射缓存。但是 MOVED 重定向说明键对应的槽已经明确指定到新的节点，因此需要更新 slot 到 Redis 节点的映射缓存。

为什么不直接在redis集群节点重定向？

由于请求重定向会增加 IO 开销，这不是 Redis 集群高效的使用方式，而是要使用 Smart 集群客户端。Smart 客户端通过在内部维护 slot 到 Redis 节点的映射关系，本地就可以实现键到节点的查找，从而保证 IO 效率的最大化，而 MOVED 重定向负责协助客户端更新映射关系。

单节点数据扩容

Redis的字典采用的是一种‘’单线程渐进式rehash‘’，这里的单线程是指只有一个线程在扩容，而在扩容的同时其他的线程可以并发的进行读写。

Redis系统后台会定时给予扩容的那个线程足够的运行时间，这样不会导致它饿死。

大致过程：

dictht[0]，是存放数据的table，作为非扩容时容器。

dictht[1]，只有正在进行扩容时才会使用，它也是存放数据的table，长度为ht[0]的两倍。

扩容时，单线程A负责把数据从ht[0] copy到ht[1] 中。如果这时有其他线程

进行读操作：会先去ht[0]中找，找不到再去ht[1]中找。

进行写操作：直接写在ht[1]中。

进行删除操作：与读类似。

当然这过程中会设计到一系列的锁来保证同步性，不过这并不是本文的重点。

而ConcurrentHashMap采用的扩容策略为： “多线程协同式rehash“。

这里的多线程指的是，有多个线程并发的把数据从旧的容器搬运到新的容器中。

扩容时大致过程如下：

线程A在扩容把数据从oldTable搬到到newTable，这时其他线程

进行get操作：这个线程知道数据存放在oldTable或是newTable中，直接取即可。

进行写操作：如果要写的桶位，已经被线程A搬运到了newTable。

那么这个线程知道正在扩容，它也一起帮着扩容，扩容完成后才进行put操作。

进行删除操作：与写一致。

特点

1、节点自动发现
2、slave->master 选举,集群容错
3、Hot resharding:在线分片
4、基于配置(nodes-port.conf)的集群管理
5、客户端与redis节点直连、不需要中间proxy层.
6、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

宕机

转载：https://www.cnblogs.com/dadonggg/p/8628735.html

redis集群是有很多个redis一起工作，那么就需要这个集群不是那么容易挂掉，所以呢，理论上就应该给集群中的每个节点至少一个备用的redis服务。这个备用的redis称为从节点（slave）。

1、集群是如何判断是否有某个节点挂掉

　　首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。

2、集群进入fail状态的必要条件

A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。

B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态

3、redis的投票机制

具体原理如下图所示：

投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉。

选举的依据依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。

通过slaveof ip port命令让其他从服务器复制该信主服务器。

最后当旧主重新连接后将其变为新主的从服务器。注意如果客户端与旧主服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

4、集群中的主从复制
集群中的每个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点继续工作，这样集群就不会因为一个主节点的下线而无法正常工作。
注意：
1、如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令。
2、使用异步复制（asynchronous replication）是redis 集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。