基于一致性哈希的分布式内存键值存储——CHKV

时间 2019-12-09

标签基于一致性哈希分布式内存键值存储 chkv 栏目 Zookeeper 繁體版

原文原文链接

Consistent Hashing based Key-Value Memory Storage

基于一致性哈希的分布式内存键值存储——CHKV。
目前的定位就是做为 Cache，DataBase 的功能先不考虑。java

系统设计

NameNode : 维护 DataNode节点 列表，用心跳检测 DataNode（通常被动，被动失效时主动询问三次），节点增减等系统信息变化时调整数据并通知 Client；
DataNode : 存储具体的数据，向 NameNode 主动发起心跳并采用请求响应的方式来实现上下线，便于 NameNode 发起挪动数据指令，实际挪动操做由 DataNode 自行完成；
Client : 负责向 NameNode 请求 DataNode 相关信息并监听其变化，操纵数据时直接向对应 DataNode 发起请求就行，

目前支持set,get,delete,keys,expire几个操做；git

NameNode 失效则整个系统不可用。github

若当成内存数据库使用，则要注意持久化，并且只要有一个 DataNode 失效（未经请求与数据转移就下线了）整个系统就不可对外服务；
若当成内存缓存使用，则 DataNode 失效只是失去了一部分缓存，系统仍然可用。
redis

DataNode 失效（未经请求与数据转移就断开了和 NameNode 的链接）则 NameNode 须要及时通知 Client。数据库

客户要使用 CHKV 就必须使用 Client 库或者本身依据协议（兼容redis）实现，能够是多种语言的API。
固然也能够把 Client 当作 Proxy，使得 CHKV 内部结构对客户透明，亦即有以下两种方式：缓存

方式1：安全

用户直接使用Client库
              ||
        ||          ||
    ||                      ||
NameNode        ||      ||      ||      ||
            DataNode DataNode DataNode DataNode ......

方式2：网络

用户经过Proxy访问    
              ||  
         Client库构建的Proxy
              ||
        ||          ||
    ||                      ||
NameNode        ||      ||      ||      ||
            DataNode DataNode DataNode DataNode ......

分析

要想实现高可用有两点： NameNode 要主从双机热备，避免单点失效；每一个 DataNode 能够作成主从复制甚至集群。多线程

各个组件之间的链接状况：并发

NameNode 要保持和 N 个 Client 的TCP长链接，可是只有在集群发生变化时才有交互，因此使用IO多路复用负载就不大
NameNode 要和 M 个 DataNode 保持心跳，TCP请求响应式，负载与 M 和心跳间隔秒数 interval 有关
DataNode 与 Client 是TCP请求响应式操做，Client 请求完毕后保留与该 DataNode TCP链接一段时间，以备后续访问复用链接，链接采起自动过时策略，相似于LRU
DataNode 与 NameNode 保持心跳
Client 与 NameNode 保持TCP长链接
Client 与 DataNode TCP请求响应式操做

以下图所示，有4个链接：其中一、2要主动心跳来保持链接；3保持链接以备复用并能够自动超时断开，再次使用时重连；4完成数据转移后就断开链接。

NameNode
                   ||       ||     
  一、心跳请求响应||              ||二、监听长链接 
             ||   三、数据请求响应   ||     
          DataNodes  ==========  Clients
           ||    ||
              ||
      四、数据转移，可复用3

开发优先级：三、一、四、2

代码结构

NameNode : 实现 NameNode 功能
- handler : handler
- res : 资源，如常量，命令工厂
- service : 服务，含Client管理，DataNode管理
DataNode : 实现 DataNode 功能
- command : 处理客户端各个命令的具体命令对象
- job : 一些的任务如心跳、数据迁移
- handler : 处理链接的handler
- service : 服务，含定时任务管理，数据请求管理
Client : 实现 Client 功能
- handler : handler
- Client : 暴露给用户的命令管理
- Connection : 发出网络请求
Common : 实现一些公共的功能，上面三个模块依赖于此模块
- command : 命令抽象类
- model : 一些公用的pojo，如请求响应对象
- util : 一些工具类
- helper : 辅助脚本

使用方法

DataNode 运行起来就能够直接使用 redis-cli 链接，如redis-cli -h 127.0.0.1 -p 10100，并进行set、get、del等操做；

注意：要首先运行 NameNode，而后能够经过JVM参数的方式调整端口，在同一台机器上运行多个 DataNode，
若要在不一样机器上运行 DataNode 也能够直接修改配置文件。

新的 DataNode 能够直接上线，NameNode 会自动通知下一个节点转移相应数据给新节点；DataNode 若要下线，
则能够经过 telnet DataNode 节点的下线监听端口（TCP监听）如 telnet 127.0.0.1 6666 ，
并发送 k 字符便可，待下线的DataNode收到命令 k 后会自动把数据所有转移给下一个 DataNode
而后提示进程pid，用户就能够关闭该DataNode进程了，如 Linux： kill -s 9 23456，Windows:taskkill /pid 23456

NameNode 和 DataNode 启动后就可使用 Client 了，代码示例以下：

Client 代码示例在此，关键以下：

try(Client client = new Client("192.168.0.136","10102")){// 支持自动关闭
        logger.debug(client.set("192.168.0.136:10099","123456")+"");
        logger.debug(client.get("192.168.0.136:10099")+"");
        logger.debug(client.set("112","23")+"");
        logger.debug(client.del("1321")+"");
        logger.debug(client.del("112")+"");
    }

压力测试

在本机开启1个 NameNode 和1个 DataNode 直接压测，4次

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 5006.76 requests per second
SET: 5056.43 requests per second
SET: 5063.55 requests per second
SET: 5123.74.55 requests per second

把以上2个节点日志级别都调整为 info（实际上 DataNode 节点才会影响 qps），重启

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 62421.97 requests per second
SET: 87260.03 requests per second
SET: 92592.59 requests per second
SET: 94517.96 requests per second

可见日志对qps影响很大，是几k 与 几十k 的不一样数量级的概念，若把级别改为 error，平均qps还能提高几k，因此生产环境必定要注意日志级别。

此外观察，不重启而且每次压测间隔都很小的话，qps通常会从 65k 附近开始，通过一、2次的 88k 左右，最终稳定在 98k 附近，数十次测试，最低 62.4k，最高101.2k。

重启的话，qps就会重复上述变化过程，这应该是和内存分配等初始化工做有关，第1次压测有大量的初始化，然后面就没了，因此第一次qps都比较低；还可能与 JIT 有关，因此 Java 的性能测试严格上来讲要忽略掉最初的几个样本才对。

经观察，DataNode进程启动后，内存消耗在59M附近，第1次压测飙升到134M而后稳定到112M，第2次上升到133M而后稳定到116M，后面每次压测内存都是先增长几M而后减少更多，最终稳定在76M。

在本机运行一个redis-server进程，而后压测一下

redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -t set -q

SET: 129032.27 requests per second
SET: 124533.27 requests per second
SET: 130208.34 requests per second
SET: 132450.33 requests per second

经数十次测试，qps 稳定在 128k 附近，最高 132.3k ，最低 122.7k 可见CHKV的单个 DataNode 目前性能还比不过单个 redis。

DataNode 通过重构后，如今的压测结果以下

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 78554.59 requests per second
SET: 114285.71 requests per second
SET: 119047.63 requests per second
SET: 123628.14 requests per second

通过屡次测试，qps 稳定在 125k 附近，最高 131.9k ，最低 78.6k（这是启动后第一次压测的特例，后期稳定时最低是 114.3k），可见重构后
单个 DataNode 和单个 redis-server 的 qps 差距已经很小了，优化效果仍是比较明显的。

主要优化两个：去掉单独的 BusinessHandler 的单独逻辑线程，由于没有耗时操做，直接在IO线程操做反而能省掉切换时间；
DataNode 经过 public static volatile Map<String,String> DATA_POOL 共享数据池，其余相关操做类减小了这个域，省一些内存；
第一条对比明显，很容易直接测试，第二条没直接测，只是分析。

而后经过 -Xint 或者 -Djava.compiler=NONE 关闭 JIT 使用 解释模式，再压测试试。

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 16105.65 requests per second
SET: 16244.31 requests per second
SET: 16183.85 requests per second
SET: 16170.76 requests per second

可见关闭 JIT 后 qps 下降了 7倍多，并且每次差异不大（即便是第一次），这也能说明上面（默认是混合模式）第一次压测的 qps 比后面低了那么多的缘由确实和 JIT 有关。

经过 -Xcomp 使用 编译模式 ，启动会很慢。

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 83612.04 requests per second
SET: 117647.05 requests per second
SET: 121802.68 requests per second
SET: 120048.02 requests per second

可见 编译模式 并无比 混合模式 效果好，由于即便是不热点的代码也要编译，反而浪费时间，因此通常仍是选择默认的 混合模式 较好。

而后来验证线程数、客户端操做与 qps 的关系，实验机器是 4 core、8 processor，我把 DataNode 的 DataManager 中 workerGroup的线程数依次减小从 8 调到为 1 （以前的测试都是 4 ），
发现 qps 先升后降，在值为 2 的时候达到最大值，超过了redis，下面是数据

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 93283.04 requests per second
SET: 141043.05 requests per second
SET: 145560.68 requests per second
SET: 145384.02 requests per second

经数十次测试，qps 稳定在 142k 附近，最高 150.6k ，稳定后最低 137.2k。
Netty 自己使用了IO多路复用，在客户端操做都比较轻量（压测这个 set 也确实比较轻量）时选择线程数较少是合理的，
由于这时候线程切换的代价超过了多线程带来的好处，这样咱们也能理解 redis 单线程设计的初衷了，
单线程虽然有些极端，可是若是考虑 面向快速轻量操做的客户端 和 单线程的安全与简洁特性，也是最佳的选择。

可是若是客户端操做不是轻量级的，好比咱们把 set 数据大小调为500bytes，再对 CKHV 不一样的 workerGroup线程数进行压测

2 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 80450.52 requests per second
SET: 102459.02 requests per second
SET: 108813.92 requests per second
SET: 99206.34 requests per second

3 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 92592.59 requests per second
SET: 133868.81 requests per second
SET: 133868.81 requests per second
SET: 135685.22 requests per second

4 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 72046.11 requests per second
SET: 106723.59 requests per second
SET: 114810.56 requests per second
SET: 119047.63 requests per second

可见这个时候四、3个线程qps都大于2个线程，符合验证，可是4的qps又比3少，说明线程太多反而很差，
然而把数据大小调到900byte时，4个线程又比3个线程的qps大了，
因此这个参数真的要针对不一样的应用场景作出不一样的调整，总结起来就是轻量快速的操做适宜线程 适当少，重量慢速操做适宜线程 适当多。

将来工做

水平有限，目前项目的问题还不少，能够改进的地方还不少，先列个清单：

高可用性保证
~~断线重连~~
~~DataNode迁移数据的正确性保障~~
对于WeakReference的支持
更多数据类型
更多操做
完整的校验机制
等等......

所有代码在Github上，欢迎 star，欢迎 issue，欢迎 fork，欢迎 pull request......
总之就是欢迎你们和我一块儿完善这个项目，一块儿进步。

戳此看原文，来自MageekChiu