订阅程序员杂志RSS CSDN首页> 程序员杂志

腾讯CKV海量分布式存储系统

发表于2014-03-11 17:32| 次阅读| 来源《程序员》| 0 条评论| 作者梁晓湛

摘要:腾讯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海量分布式存储系统架构和运营优化工作。曾从事千万亿次超级计算机管理和作业调度系统开发。

0
0

近期活动

更多

2015中国大数据技术大会

为了更好帮助企业深入了解国内外最新大数据技术,掌握更多行业大数据实践经验,进一步推进大数据技术创新、行业应用和人才培养,2015年12月10-12日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办,中国科学院计算技术研究所、北京中科天玑科技有限公司及CSDN共同协办的2015中国大数据技术大会(Big Data Technology Conference 2015,BDTC 2015)将在北京新云南皇冠假日酒店隆重举办。

微博关注

程序员移动端订阅下载

相关热门文章