redis&zookeeper集群

/article/1622784.html

disgear是笔者参考solrcloud架构基于redis实现的分布式的缓存，支持数据切分到多台机器上，支持HA，支持读写分离和主节点失效自动选举，目前把它开放到github上，开放给大家

github:https://github.com/yangbutao/disgear

总体设计

1. 系统需求

1) 性能

内存操作，读写性能要求比较高

2) 数据量

支持数据切分，分为多个Shard，每个shard负责一定范围的数据

3) 伸缩性

当单个节点的数据量比较大的时，可以对该节点进行数据切分，分离成两部分，增加新的机器即可。

4) 可用性

系统不存在单点问题，缓存节点支持HA，master节点宕掉后，自动选举一个slave为主节点，对客户端透明

2. 设计说明

首先启动好所有的redis实例，每个redis实例有一个agent负责监控，agent ping redis实例的状态，agent 连接到zookeeper上创建/collections/collection1/leader_elect/shard1/election下的节点，监控比它小的节点，变化时更新leader节点。

当agent连接zookeeper超时或者agent ping redis实例超时，会删除zookeeper上的election下的节点(agent ping redis超时，调用zookeeper api删除节点)。

当ping到redis节点起来后，若检查到zookeeper上没有对应节点，则创建相应节点。

Leader(master)是缓存负责响应的节点，replica(slave)只负责同步leader的数据，当leader宕机后，提升replica为主节点。

以下是zookeeper上节点的相关说明：

/collections

|----collection1

|----leader_elect

----shard1[0-7ffffffff] //节点启动时，一共需要分几个 分区，需要声明该节点属于哪个shard

---election //参与选举的节点列表，竞争成为leader节 点，并更新leaders节点列表和
clusterstate.json节点内容，并调用脚 本 更改redis的master slave配置

----10.1.1.21

----10.1.1.22

----shard2

---eclection

---10.1.1.23

---10.1.1.24

|---leaders

----shard1 //当前shard的leader节点

---10.1.1.21

-----shard2

----10.1.1.24

/observer //负责watch collections中节点的变化，

由leader节点更新 clusterstate.json节点的内容，observer节点需要在系统初始 化过程中最新选举出leader节点，做watch collections下的
节点的变化。

|---election //其下是供选择的节点

|----leader //这样一个好处是每个client节点无需对多个zookeeper的节点监控计算，由单独的节点对这些变化的节点做监控，
来更新集群状态，这样每个client只需要 watch 集群状态 内容zookeeper节点即可。

/live_nodes

|---10.1.1.21

|----10.1.1.22

|----10.1.1.23

|-----10.1.1.24

/clusterstate.json //集群状态，当有节点变化时，更新这个节点 内容，每个client端监听该节点内容的变化, 缓存在本地cache中。

相关内容如下：

{collection1={

"shards":{

"shard1":{

"range":"80000000-ffffffff",

“leader”:node1,

"replicas":{

"node1":{

"state":"alive", "node_name":"192.168.1.21:8983"},

"node2":{

"state":"alive",

"node_name":"192.168.1.22:8983"

}}},

"shard2":{

"range":"0-7fffffff",

"state":"active",

“leader”:node3,

"replicas":{

"node3":{

"node_name":"192.168.1.23:8983"},

"core_node4":{

"node_name":"192.168.1.24:8983"

}}},

模块设计说明

1. 数据切分、节点扩容、key hash

对于数据切分，数据的范围取Integer.MIN_VALUE, Integer.MAX_VALUE，首次初始化时，根据规划的Shard的数量，平均进行切分，每个Shard负责一个固定的数据范围，比如Shard1[0-7fffffff]，这些Shard和数据的范围会持久化到zookeeper节点上，以便于集群重启后，从zookeeper本地拉起Shard划分和数据范围的相关数据，如下图所示。

/collections

|----collection1

|----leader_elect

----shard1[0-7ffffffff]

----shard2[800000-9ffffffff]

当需要扩容缓存节点时，管理员可以对Shard进行split操作，生成两个新的Shard，每个Shard负责一部分数据，注册在zooleeper上的/collections/collection1/leader_elect节点下。比如Shard1[0-7ffffffff]经过split操作后，变成Shard1_1[0-3ffffffff]和Shard1_2[400000-7fffffffff]。

/collections

|----collection1

|----leader_elect

----shard1[0-7ffffffff]

----shard2[800000-9ffffffff]

----shard1_1[0-3ffffffff]

----shard1_2[0-3ffffffff]

新的节点加入到新的Shard分区中，完成leader选举等一系列操作后，更新集群拓扑状态，并删除老的Shard分区，这样新的Shard就处于可用状态。

对于key的hash定位，采用murmurhash3_x86_32 算法，效率比较高，然后判断该hash值落在哪个shard的数据范围内，进行数据的分区定位。

2. 缓存代理Agent

Agent作为缓存节点的代理，一方面和zookeeper进行通信，把缓存节点的状态通知给zookeeper，另外一方面对redis缓存节点做管理和监控。

1) Agent检测redis节点是否存活：

需要在Agent中调用以下脚本(monitor_redis.sh)，把返回的结果，通知给zookeeper

ALIVE=$(/opt/cache/redis-2.6.16/src/redis-cli -h 10.1.1.25 -p 6379 -a 123 PING)

echo $ALIVE

2) 变更为master节点

当节点上的agent在zookeeper上成为leader节点时，需要通知agent把它代理的redis变更为master节点，agent调用以下脚本。

主节点的脚本(redis_master.sh)：

#!/bin/bash

/opt/cache/redis-2.6.16/src/redis-cli -h 10.1.1.26 -p 6379 slaveof NO ONE

3) 变更为slave节点

当节点上的agent在zookeeper上成为replica节点时，需要通知agent把它代理的redis变更为slave节点，agent调用以下脚本。

slave节点脚本(redis_slaves.sh)：

#!/bin/bash

/opt/cache/redis-2.6.16/src/redis-cli -h 10.1.1.26 -p 6379 slaveof 10.1.1.25 6379

3. 集群状态观察者Observer

Observer负责对整个集群collection下的Shard节点的变动进行监听，更新zookeeper上的集群状态节点cloudstate.json。

Agent节点在启动过程中，首选要做的就是Observer的选举。

Observer需要由zookeeper选举出来后，监听collections下节点的变化，若有变化则进行处理process，计算的结果设置到zookeeper的cloudstate.json节点。

当cloudstate.json节点数据变化时，负责监听该节点的所有客户端都更新本地客户端内存。

/observer

|---election

----10.1.1.21

----10.1.1.22

-----10.1.1.23

|----leader

-----10.1.1.22

4. Shard leader选举

Shard节点在zookeeper上创建完成后，缓存节点在启动的过程中，需要通过命令行-D参数或者配置文件的形式加入到集群中的某一个Shard分区下，参与leader的选举，具体实现是为每个节点生成一个数字，每个节点只需要监控比自己小的节点即可，如有变化，则进行通知，并使得数字最小的节点成为leader节点。

/collections

|----collection1

|----leader_elect

----shard1 //节点启动时，一共需要分几个分区，需要 声明该节点属于哪个shard

---eclection //参与选举的节点列表，竞争成为leader节 点，并更新leaders节点列表和
clusterstate.json节点内容，并调用脚 本 更改redis的master slave配置

----10.1.1.21

----10.1.1.22

----shard2

---eclection

---10.1.1.23

---10.1.1.24

|---leaders

----shard1 //当前shard的leader节点

---10.1.1.21

-----shard2

----10.1.1.24

5. 缓存节点的扩容

当某shard的访问压力过大或者数据量比较大时候，节点的扩展有两种方式，

一种是增加shard中的节点数量，提高读的能力，这种方式已经实现；

另外一种方式对压力大的shard做split的操作，一个shard分割为两个shard，提高shard的写数据的能力，这种节点的扩展方式目前还不支持，已纳入到后续的计划中。

使用说明

Agent的启动脚本：

MAIN="com.newcosoft.cache.agent.AgentMain"

$JAVA $JAVA_OPTS -cp "$CLASSPATH" $JVMFLAGS $MAIN -Dcol=col1 -Dshard=shard1 -Dnode=node25 \

-DbaseUrl=10.1.1.25:6379 -DscriptPath=/opt/lsmp -DshardNum=3 -Dzk_url=10.1.1.25:2181

其中-Dcol表示当前创建的collection名称，对于redis来讲，代表要存储库的逻辑名称

-Dshard表示当前的节点的shard名称

-Dnode表示当前节点的逻辑名称

-DbaseUrl表示redis的主机IP和端口号

-DscriptPath表示redis监控和操作相关的脚本的路径，脚本有monitor_redis.sh、redis_master.sh、redis_slaves.sh

-DshardNum表示当前collection中的shard数目

-Dzk_url代表zookeeper集群的地址

Client端的使用：

在使用disgear的client端启动初始化中，引用disgear相关的jar，并调用

com.newcosoft.client.ClusterStateCacheManager.INSTANCE=new ClusterStateCacheManager(zkUrl);

ClusterStateCacheManager.INSTANCE.createClusterStateWatcher();

创建clusterState的监听器。

这样后续通过com.newcosoft.client.ClusterStateCacheManager.INSTANCE.getClusterState()就可以获得当前集群的节点状态，

进而选择合适的节点进行分发数据存取请求。