KeeWiDB 的架构由代理层和服务层两个部分构成

一、整体架构

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

图：KeeWiDB 整体架构图

代理层

客户端通过 Proxy 连接来进行访问，由于 Proxy 内部维护了后端集群的路由信息，所以 Proxy 可以将客户端的请求转发到正确的节点进行处理，从而客户端无需关心集群的路由变化，用户可以像使用 Redis 单机版一样来使用 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 采取了单进程多线程的方案，一方面可以更好的利用整机资源来提升单节点的性能，另一方面也能降低运维门槛。

多线程方案引入的核心思想是通过提高并行度来提升单节点的吞吐量，但是在处理用户写请求期间可能会涉及到不同线程操作同一份共享资源的情况，比如存储引擎内部为了保证事务的原子性和持久性需要写 WAL，主从之间进行同步需要写 Binlog，这些日志文件在写入的过程中通常会涉及到持久化操作，相对较慢。虽然我们也采取了一系列的优化措施，例如使用组提交策略来降低持久化的频率，但是优化效果有限。

同时为了保证线程安全，在这类日志的写入期间通常都要进行加锁，这样一来，一方面虽然上层可以多线程并行的处理用户请求，但是到了写日志期间却退化成了串行执行；另一方面，申请和释放锁通常会涉及到用户态和内核态的切换，频繁的申请释放操作会给 CPU 带来额外的开销，显然会导致性能问题。

 图：线程模型

正是由于进程内不同线程访问同一份共享资源需要加锁，而大量的锁冲突无法将多线程的性能发挥到极致，所以我们将节点内部负责的 Slot 区间进行进一步的拆分，每个工作线程负责特定一组 Slot 子区间的读写请求，互不冲突；此外每个工作线程都拥有自己独立的事务模块以及存储引擎等重要组件，不再跨线程共享。

通过对共享资源进行线程级别的拆分，各个线程在处理用户请求时都可以快速的获得所需要的资源，不发生等待事件，这无论是对单个请求延迟的降低还是多个请求并发的提升，都有巨大的好处；此外由于处理用户请求所需的资源都在线程内部，KeeWiDB 无需再为了线程安全而上锁，有效规避了由于频繁上锁带来的额外性能开销。