1. 什么是 KeyDB

KeyDB 项目是从 redis fork 出来的分支。众所周知 redis 是一个单线程的 kv 内存存储系统，而 KeyDB 在 100% 兼容 redis API 的情况下将 redis 改造成多线程。

在相同的硬件上， KeyDB 每秒执行的查询数量是 Redis 的两倍，在 OpenPower 服务器上实测最大性能提升接近 4 倍。延迟降低 60 ％。

KeyDB 与 Redis 协议、模块和脚本完全兼容，包括对事务的完全支持和脚本的原子执行。

该开源程序的官方网站地址： https://keydb.dev/index.html

2. KeyDB 的工作模型

KeyDB 将 redis 原来的主线程拆分成了主线程和 worker 线程。每个 worker 线程都是 io 线程，负责监听端口， accept 请求，读取数据和解析协议。如图所示：

以当前版本为例，当前版本的 KeyDB 最多支持 4 个 worker 线程同时工作。

KeyDB 使用了 SO_REUSEPORT 特性，多个线程可以绑定监听同个端口。
每个 worker 线程做了 cpu 绑核，读取数据也使用了 SO_INCOMING_CPU 特性，指定 cpu 接收数据。
解析协议之后每个线程都会去操作内存中的数据，由一把全局锁来控制多线程访问内存数据。
主线程其实也是一个 worker 线程，包括了 worker 线程的工作内容，同时也包括只有主线程才可以完成的工作内容。在 worker 线程数组中下标为 0 的就是主线程。
主线程的主要工作在实现 serverCron ，包括：

· 处理统计

· 客户端链接管理

· db 数据的 resize 和 reshard

· 处理 aof

· replication 主备同步

· cluster 模式下的任务

另外， KeyDB 除了拥有超高的性能以外，还具有如 Flash Disk Support 这样的企业级 Redis 才具有的功能。具体功能对比如下图所示：

注：Flash Support是一种通过SSD(或NVME SSD)硬盘扩展内存容量的功能。可以在尽量不牺牲性能的前提下降低Redis数据库实例成本。

3. KeyDB on OpenPower 的编译安装

3.1 编译环境设置：

操作系统环境：
Ubuntu 18.04.03

gcc / g++编译器环境：
gcc 7.4.0

## 3.2 编译过程概述

1. 更新操作系统包到最新：
   sudo apt- get update

   2. 安装编译环境依赖包：

   sudo apt- get install build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl -dev uuid-dev

   3. 下载 KeyDB 源代码：

   sudo git clone http s: //github. com /JohnSully/KeyDB.git

   4. 源代码编译安装：
      sudo make
      sudo make install

      5. 如果想增加 Flash Support 支持，需要采用如下方式编译：

   apt- get install build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl-dev uuid-dev libtool libnuma-dev

   git clone http s: //github.com /JohnSully/KeyDB.git
   make MALLOC=memkind
   make install

4. KeyDB 的运行环境设置

由于 KeyDB 是 Redis 的一个技术分支，因此 Redis 的所有技术参数 KeyDB 均提供了技术支持。除此之外， KeyDB 还支持如下额外参数：
server-threads N (N <= 4)：
此参数用于配置 worker 线程。该参数只能在 1-4 之间设置。

server-thread-affinity [true/false]：
允许将线程绑定到物理 CPU 上。默认情况下，该参数是 disable 状态的。当这一参数被设置为 enable 时，服务进程将被绑定到 Core 0 上。

scratch-file-path /path:
如果你想使用 NVME SSD 硬盘作为 Flash 设备，这个参数将用于设置 Flash 设备的文件系统 mount 点。

active-replica yes:
当此参数被设置成 yes 时， replication 将被设置成 Active-Active 模式。

5. KeyDB 的性能测试

5.1 测试工具的选择

由于 Redis 自带的 redis-benchmark 工具及 KeyDB 自带的 keydb-benchmark 工具均为单线程测试工具。无法测试出 Redis 及 KeyDB 的全部性能。因此本次测试采用的是 Redislabs 推出并推荐使用的 redis 性能测试工具 memtier-benchmark 。

memtier_benchmark 是 Redis Labs 推出的一款命令行工具，它能够产生各种各样的流量模式，可以对 Memcached 和 Redis 实例进行基准测试。这个工具提供了丰富的自定义选项和报表功能，通过命令行界面就能够轻松地使用。这一工具有如下优点：

• 同时支持 Redis 和 Memcached （二进制和文本）协议；
• 能够启动多个工作线程（使用 -t 选项指定数量），每个线程能够驱动若干个客户端（使用 -c 选项指定数量）；
• 能够迭代运行多次基准测试（使用 -x 选项指定迭代次数），它会自动生成测试报告，包含最好和最坏的运行结果，以及聚合平均值；
• 能够控制 GET 和 SET 操作数量的比率（使用 --ratio 选项），这样便能针对各种访问模式进行基准测试；
• 能够为测试键设置相同的过期时间，也可以在指定范围之内设置不同的过期时间（使用 --expiry-range 选项）。

关于这一软件的更加详细的介绍请参见 Redislabs 官方网站上的介绍内容： https://redislabs.com/blog/memtier_benchmark-a-high-throughput-benchmarking-tool-for-redis-memcached/#.UxgGr_S1a-B

5.2 测试工具的安装

本次编译安装 memtier-benchmark 工具所使用的操作系统环境为 Ubuntu 18.04
具体编译方法如下：
sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev libssl-dev
$ autoreconf –ivf
$ ./configure --disable-tls
$ make
$ make install

## 5.3 测试方法
测试硬件环境介绍：
本次测试计划采用 OpenPower FP5280G2 服务器与 X86 服务器两个平台同时进行测试。
两个平台的配置情况大致如下 :
OpenPower : Sforza 2.2-3.8GHz 20Core / 512GB 内存 ;
X86 : Intel Silver 4114 20Core / 96GB 内存

本次计划分别进行两组测试：

第一组测试在同一个 OpenPower 服务器上分别运行 KeyDB 及 Redis 5.0 软件，并通过 memtier-benchmark 取得性能指标。目的是通过这一方法来评价在相同服务器环境下采用 KeyDB 比原始 Redis 的性能差异。
第二组测试的目标是通过分别在 OpenPower 服务器及 X86 服务器上运行 KeyDB 软件，并通过 memtier-benchmark 取得性能指标。目的是通过这一方法来评价不同的服务器架构在运行 KeyDB 软件的性能差异。
为了实现公平对比，测试指标的取得将采用同样的 memtier-benchmark 脚本。脚本内容如下：
memtier_benchmark --hide-histogram -c 50 -d **N** --threads=10 --select-db=10 

其中 N 表示测试的 data size 。本次测试中我们一共选择了 5 组 data size 。分别是： 8 、 32 、 128 、 512 、 1024

为了保证测试结果不会受到个别测试结果的概率便宜影响，我们计划每一个场景测试 3 次，然后去的这三次结果的平均值。

5.4 测试性能结果

通过测试我们得出如下结论：

结论 1 ：在相同的 OpenPower 硬件条件下 KeyDB 的平均 QPS 性能指标是同等配置条件加 Redis v5.0 的 3.72 倍。具体指标如下图所示：

结论 2 ：在相同的 OpenPower 硬件条件下 KeyDB 的平均延迟性能指标是同等配置条件加 Redis v5.0 的 3.2 倍。具体指标如下图所示：

在 OpenPower 与 X86 的对比测试中，我们可以得到如下结论：
结论 3 ：在相同软件版本条件下， OpenPower 环境的 QPS 指标比 X86 环境的性能指标好 20% 。

结论 4 ：在相同软件版本条件下， OpenPower 环境的延迟指标比 X86 环境的性能指标好 21.68% 。

6. 下一步的改进方向

6.1 编译工具的改进

本次测试的 KeyDB 是采用 GCC 进行编译的。这一点在 Power9 的处理器上并不是最佳实践。下一步如果采用 XLC 编译器对源代码进行编译可能会有更好的性能表现。

6.2 集群部署对性能的改进

为了得到 KeyDB 与 Redis 的准确性能对比，在本次测试时只启用了 1 个服务进程实例。在实际测试中我们发现， KeyDB 最多可以用到 4 个线程的 CPU 计算资源， Redis 只能用到 1 个 CPU 的计算资源。因此，对于测试服务器来说，无论是 OpenPower 服务器还是 X86 服务器都有大量的计算资源没有参与到测试中。

因此，如果采用集群方式部署 Redis 集群或 KeyDB 集群，可以得到很好的服务性能。特别是对于 OpenPower 服务器而言，每个物理核心有 4 个物理线程，在相同内核情况下，线程数量是 X86 的一倍。因此可以推论在相同物理内核场景下， OpenPower 服务器可以提供的 KeyDB 服务性能可以达到 X86 服务器的 2.4 倍。

6.3 Flash Support 方面改进

由于时间原因，本次测试没有加入针对 NVME SSD 硬盘的 Flash Support 技术的性能测试内容。这一功能在后期，如果有机会还是非常值得期待的。

6.4 NUMA 绑定方面的改进

在 OpenPower 测试中发现测试结果的跳跃性非常强，在一组测试中最好结果与最坏结果的差值竟然可以达到近 20% 。通过对操作系统监控发现内存远程访问可能是造成这一结果的原因。

因此，在第二轮采集性能结果时，将 keydb-server 进程根据 CPU 和对应的内存进行了绑定，以达到更好的 CPU 与内存的亲和性。改进后不仅每次结果的误差范围明显收窄，而且测试指标也有了近 5% 的增长。