一、整体架构

KeeWiDB 的架构由代理层和服务层两个部分构成： 代理层：由多个无状态的 Proxy 节点组成，主要功能是负责与客户端进行交互； 服务层：由多个 Server 节点组成的集群，负责数据的存储以及在机器发生故障时可以自动进行故障切换。

图：KeeWiDB 整体架构图

代理层

Proxy 的引入，还带来了诸多优势：

客户端直接和 Proxy 进行交互，后端集群在扩缩容场景不会影响客户端请求； Proxy 内部有自己的连接池和后端 KeeWiDB 进行交互，可大大减少 KeeWiDB 上的连接数量，同时有效避免业务短连接场景下反复建连断连对内核造成性能的影响； 支持读写分离，针对读多写少的场景，通过添加副本数量可以有效分摊 KeeWiDB 的访问压力； 支持命令拦截和审计功能，针对高危命令进行拦截和日志审计，大幅度提高系统的安全性； 由于 Proxy 是无状态的，负载较高场景下可以通过增加 Proxy 数量来缓解压力，此外我们的 Proxy 支持热升级功能，后续 Proxy 添加了新功能或者性能优化，存量 KeeWiDB 实例的 Proxy 都可以进行对客户端无感知的平滑升级；

图：Proxy 上的功能

服务层

KeeWiDB 的后端采用了集群的架构，这是因为集群具有高可用、可扩展性、分布式、容错等优质特性；同时，在具体的实现上参考了 Redis 的集群模式。KeeWiDB 集群同样由若干个分片构成，而每个分片上又存在若干个节点，由这些节点共同组成一主多从的高可用架构；此外每个分片的主节点负责集群中部分 Slot 的数据，并且可以通过动态修改主节点负责 Slot 区间的形式来实现横向的扩缩容，为客户提供了容量可弹性伸缩的能力。

二、Server 内部模型

在 Server 内部存在一个集群管理模块，该模块通过 Gossip 协议与集群中的其他节点进行通信，获取集群的最新状态信息；另外 Server 内部存在多个工作线程，KeeWiDB 会将当前 Server 负责的 Slot 区间按一定的规则划分给各个工作线程进行处理， 并且每个工作线程都有自己独立的连接管理器，事务模块以及存储引擎等重要组件，线程之间不存在资源共享，做到了进程内部的 Shared-Nothing。正是这种 Shared-Nothing 的体系结构，减少了 KeeWiDB 进程内部线程之间由于竞争资源的等待时间，获得了良好并行处理能力以及可扩展的性能。

图：Server 内部模块

线程模型

KeeWiDB 的设计目的，就是为了解决 Redis 的痛点问题。所以大容量，高性能以及低延迟是 KeeWiDB 追求的目标。

和数据都存放在内存中的 Redis 不同，KeeWiDB 的数据是存储在 PMem (Persistent Memory) 和相对低价的 SSD 上。在用户执行读写访问请求期间 KeeWiDB 都有可能会涉及到跟硬盘的交互，所以如果还像 Redis 一样采用单进程单线程方案的话，单节点的性能肯定会大打折扣。因此，KeeWiDB 采取了单进程多线程的方案，一方面可以更好的利用整机资源来提升单节点的性能，另一方面也能降低运维门槛。