摘要：腾讯CKV，是腾讯自主研发的高性能、低延时、持久化、分布式KV存储服务。在腾讯的微信平台、开放平台、腾讯云、腾讯游戏和电商平台广泛使用，日访问量超过万亿次。本文将全面剖析CKV的实现原理和技术挑战。

与Memcached和Redis等开源NoSQL相比，CKV具有以下优点。

• 低成本：CKV利用数据冷热自动分离技术，将热数据存储在内存，冷数据存储在SSD中，从而大幅度降低成本，且保证99%以上的访问命中内存。而Memcached和Redis的数据都存储在内存中，成本是CKV的3倍。
• 可扩展性强：CKV单表存储空间可以在1GB到1PB之间在线自动无损伸缩，业务基本无感知，适合各种规模的业务和业务的各个生命周期。而Memcached和Redis是单机的，受限于单机的性能和内存容量，虽然可以通过客户端或者Twemproxy等构建分布式集群，但是不能做到完全无损扩容，伸缩修改配置较麻烦。
•  高性能：CKV单表最大支持千万次/秒的访问，通过网络访问的延时在1ms左右，单台Cache服务器千兆网络环境支持50万/秒的访问，万兆网络环境支持超过100万/秒的访问。Memcached采用多线程，但性能比CKV Cache略低。而Redis是单线程的，性能垂直扩展性差。
• 可用性超过99.95%：CKV软硬件全冗余设计，双机热备，主备切换对业务透明，跨机架跨交换机部署。Memcached机器死机后，部分key访问就会miss。Redis有双机方案，但还不成熟。
• 数据持久性超过8个9：CKV数据在磁盘存储，多内存和磁盘副本，具有灾难时回档能力。Memcached死机后，数据就丢失了。Redis虽然数据有双机方案，但还不成熟。
• 完善的运维体系：CKV能预防并及时发现和处理故障，自动化运营。而Mem-cached和Redis缺乏专门的运维系统。

图1  CKV SET架构

CKV系统包含多个SET。SET包含多种角色的服务器，是一个独立完整可运营的单元。图1是一个完整的CKV SET架构图。本文将主要介绍CKV系统的基本原理，如何实现高性能、可扩展性强、高可用、数据持久化，以及完善的运维体系。

基本原理

每个业务都有一个唯一的tid。Master负责管理tid的路由表，路由表描述tid的key存储在Cache的位置信息。Access是无状态、全镜像的，Access启动或者业务路由表发生变化时，Master向Access推送tid路由表。

图2  CKV SET操作流程

我们以写入key-value的set操作为例，说明业务访问流程（如图2所示）：业务向L5服务获取负载和延时最佳Access地址；业务向Access发送写入数据请求；Access根据业务的tid找出相应的路由表，对key进行sharding，把key映射为一个shard ID，然后在路由表中找出key所属的shard位于的Cache地址；Access向Cache发送写入数据请求，Cache把数据写入内存并落磁盘；Cache向Access返回操作结果；Access将结果传回给业务。

对key进行sharding的方法很多，最简单的是对key进行Hash然后取余。

CKV读写访问都能做到高性能、低延时，能够解决Memcached+MySQL不能解决的海量低延时写问题。

Cache集群定期将内存中的冷数据存储到SSD中，当这些冷数据再次被访问时，数据会按一定策略从SSD迁移到内存，从而大幅度降低成本，且保证99%以上的访问命中内存。

单机高性能

CKV单台Cache机器具有极高性能，且具有垂直可扩展性，能够充分发挥高配置机器的CPU和网络性能。优化的方法主要有：充分运用Zero-copy的思想，模块间消息传递时尽量减少内存拷贝的次数；快速Hash技术；快速内存分配和回收技术；利用多队列网卡提高网络小包处理能力；多线程无锁共享技术；通过这些优化方法，单台Cache可以支撑超过100万/秒的访问。

水平可扩展性

对于单个业务表而言，CKV集群具有良好的水平可扩展性，可以通过水平扩展来提高表的容量和性能。CKV Access和Cache都具有很好的水平可扩展性。

Access水平扩展

由于Access是无状态、全镜像的，所以很容易通过L5名字服务实现水平扩容和缩容。业务只配置表的L5服务ID，而不是具体的机器IP。L5服务类似DNS，将L5服务ID映射为机器IP和端口，而且能够根据机器的负载和延时情况选择最佳的机器IP和端口，起到负载均衡和容错的作用。

当Access整体负载过高或者过低时，通过增加或者删除Access机器，并在L5服务中增加或删除Access地址，实现Access的扩容和缩容。

Cache水平扩展

当业务表空间使用率过高或者过低时，需要对业务表进行容量扩容或者缩容。如图3所示，业务数据的key空间划分为4个shard，原来存储在2台Cache中。扩容过程如下：Master将禁止shard2数据写访问命令发送给Access；Transfer模块把Cache1属于shard2的数据搬迁到Cache3；Master将更新后的tid路由表和恢复shard数据访问命令发送给Access；搬迁其他shard，重复以上过程。缩容的过程与扩容过程类似。

图3  Cache扩容/缩容路由表变化

容量扩容除了能够增加表的容量外，将shard分散到更多的Cache机器，或者将shard迁移到负载低的Cache机器上，能够实现表的整体性能提升。

高可用

CKV所有的服务器和网络全冗余。每对Access和每对主备Cache机器位于不同的交换机和机架上，避免某台交换机故障或者机架掉电导致所有Access、主备Cache都不可用。

正常的访问流程是业务通过Access访问主Cache上的数据，主Cache将变化的数据同步到备Cache中。当某台Access出现故障时，L5服务将出现故障的Access剔除，业务通过L5服务获取正常的Access地址。当主Cache出现故障时，Master通知Access把访问切换到备Cache。当备Cache出现故障时，服务不受影响。备Cache恢复后，主Cache把数据重新同步到备Cache。通过硬件冗余和软件的容灾处理，CKV可用性超过99.95%。

数据持久化

单台Cache死机，数据不会丢失，且不影响访问。如果主备Cache都死了，只要Cache磁盘的数据正常，那么Cache重启后，通过磁盘上的备份和流水重构内存数据，就能恢复服务。即便主备Cache同时死机并且磁盘损坏，也能通过备份中心的备份和流水中心的流水回档到任意5分钟的Cache内存状态。回档功能还能减少用户自己误操作造成的损失。曾经有业务人员由于误操作，把自己的表数据写错了，最后通过CKV的备份和流水才恢复到正确的数据状态。

运维系统

云服务除了要有好的架构设计和实现外，更需要好的运营。CKV运营近万台服务器，机器故障、表容量满等问题每天都会出现几个，有时甚至几十个。因而，需要全面的监控，及时的告警，提供快速的故障处理工具，以及常见的故障自动化处理。

多维度的监控

• 软件层面。监控进程自身的资源使用率，例如TCP连接数量、存储空间使用率、进程是否死掉、数据迁移失败、信息同步失败等异常状态。
• 硬件层面。监控机器的CPU、内存、磁盘、网络的使用率、机器死机等。
• 整个系统层面。空闲的资源是否足够满足业务的增长扩容，业务调用CKV服务的成功率和延时。

告警方式多样化

• 日报。汇总系统的隐患，例如系统空闲的资源不足、互为主备的机器位于相同的机架或者交换机下、机器之间的网络延时过大、机器的负载偏高等。通过日报能够把潜在的隐患处理掉，减少故障的出现。
• 短信告警。通知处于萌芽状态的故障，例如表空间使用率超过90%、需要提前扩容和机器的负载偏高等。
• 电话告警。需要紧急处理的故障。例如表空间使用率超过95%、需要紧急扩容、机器的CPU使用率100%和机器死机等。

总结

CKV利用数据冷热分离技术大幅度降低了成本，同时保证99%以上的访问命中内存，做到与纯内存访问延时几乎无差别。内存存储的CKV集群具有高性能、性能和容量可扩展性强、高可用、数据持久化等特点。完善的运维体系保证了大规模的CKV服务高效和可靠性。

CKV已经持续稳定运营4年多，成熟可靠，根据业务增长弹性伸缩，解决业务海量存储访问的难题，业务可以更加专注于自己的领域。云的时代已经到来，CKV将会助力更多的业务发展。

作者梁晓湛，腾讯TEG（技术工程事业群）基础架构部工程师，主要负责CKV海量分布式存储系统架构和运营优化工作。曾从事千万亿次超级计算机管理和作业调度系统开发。