redis集群如何同步

redis集群如何同步；

Redis 复制与集群

复制

同步方式

全同步

全同步是第一次从机连主机是进行的同步，主机会生成一个RDB文件给从机，然后从机加载该文件。

并且如果从机掉线时间很长时也会触发这个同步，掉线时间短时使用另外的策略

部分同步

当主机收到修改命令之后会把命令发给从机进行部分同步。

这里会有一个缓存区，主要是用来，如果有从机掉线，再次连接的时候会优先使用缓存区中的数据进行同步，是在不行才使用全同步

同步过程

问题

主从切换

监控

监控服务器节点

提醒

当监控的节点出现问题时，可以通过api通知其他应用等

故障转移

当主挂掉时会选举新的从服务器为主服务器，代替原来主服务器的地位

集群

public void sync(String syncCommond){

if(valid(masterid, offset)){

// 表示能够通过部分同步找回

sendCommandCache();

}else{

// 进行全同步

generateRDB();

transferRDB();

}

}对于集群的情况，经常会涉及一个key存在哪个节点中去。

一般有hash/mod的方式，但是有着增删节点重算的致命问题。

另外还有一致性hash算法，memcache客户端的算法就是这种算法，分成一个2^31的槽圆环，对节点进行hash,对key进行hash,选择顺时针离key最近的节点保存key-value，这

样可以最少的影响原数据，还可以具有hash的平衡性等好的优点。

Redis使用的是另外一种：

内置16384 个hash槽，把这些槽大致均匀的分到节点中，每个节点都记录哪些槽给了自己以及给了别人。然后对key算hash/16384, 放到对应的节点中，如果新的节点来了，那

么重新分割他一些槽同时更新各个节点中的记录，并且把槽中的记录同时也发给新的节点。

节点信息的结构

size为0， 则state为集群下线。

握手就是节点加入到已有集群的一种方式，主要是为了丰富nodeList。握手的过程如下：

当集群接收到请求之后：

不知道有没有人思考过redis是如何把数据分配到集群中的每一个节点的，可能有人会说，把集群中的每一个节点编号，先放第一个节点，放满了就放第二个节点，以此类推。。

如果真的是这样的话，服务器的利用率和性能就太低了，因为先放第一个，其他的服务器节点就闲置下来了，单个节点的压力就会非常的大，其实就相当于退化成为了单机服务

器，从而违背了集群发挥每一个节点的性能的初衷。

在redis官方给出的集群方案中，数据的分配是按照槽位来进行分配的，每一个数据的键被哈希函数映射到一个槽位，redis-3.0.0规定一共有16384个槽位，当然这个可以根据用

户的喜好进行配置。当用户put或者是get一个数据的时候，首先会查找这个数据对应的槽位是多少，然后查找对应的节点，然后才把数据放入这个节点。这样就做到了把数据均

匀的分配到集群中的每一个节点上，从而做到了每一个节点的负载均衡，充分发挥了集群的威力。

在redis中，把一个key-value键值对放入的最简单的方式就是set key value，如下所示：

可以看出，当我们把key的值设置成为value的时候，客户端被重定向到了另一个节点192.168.39.153:7002，这是因为key对应的槽位是12359，所以我们的key-value就被放到了

槽12359对应的节点，192.168.39.153:7002了。接下来，我们来看看redis是怎么把一个key-value键值对映射成槽，然后又如何存放进集群中的。

首先在redis.c文件里定义了客户端命令和函数的对应关系，

key映射到节点的算法

握手

B向A发送CLUSTER MEET

A为B创建Node结构，并且加到clusterState.nodes中

A向B发送MEET消息，B再未A创建Node,加入自己

然后B向A发送PONG,A向B返回PING完成握手

集群行为

一个节点接收到了请求，会检查是否自己的槽，不是则返回MOVED，告诉客户端去哪个槽

重新分片是由客户端去做的， 把一个槽的所有键值转到另外的槽

如果正在进行转移，客户请求没有命中，则会返回ask消息，让客户端去另外的节点去找

集群中如果有主从，那么从节点复制主节点，主几点下线之后，从节点升级代替主节点