CKV+之进化历程

提示:公众号展示代码会自动折行,建议横屏阅读


一、引言

CKV是腾讯自主研发的分布式内存KV存储系统,具备高性能、高可用,低成本等特性。从2009年上线至今,先后服务了空间、游戏、QQ、视频、音乐、微信、支付等诸多业务,与此同时,也为云上的用户提供高效、稳定的服务。 CKV在近一段时间,进行了一次较大规模的重构优化,本文将从新老系统以及自研与开源等角度进行对比,呈现系统的一些设计理念与解决方案。

二、背景

在当前互联网发展迅速,新技术层出不穷的时代,任何一款产品想要保持用户亲和度,且更具竞争力,通过重构的方式完成自我进化,是性价比较高的手段之一,特别是属于基础架构范畴的底层服务,如何应对业务场景变化,以及软硬件的迭代更新,如何在技术的大潮中站稳脚跟,自身都需要持续不断的提升。

系统重构的主要缘由通常分为两部分:解决业务遇到的实际问题;以及拓宽支撑的业务场景,服务更多用户。前者主要针对系统的可用性、可运维性、成本等诸多方面进行考量,从架构层面更加适应业务的高标准,高要求,同时,适应软硬件环境的变化,提升系统的可扩展性。后者则主要针对目前大多数用户使用习惯及业务形态的变化,提升系统易用性,可靠性及性能,同时兼容普及度较高的开源协议,从业务角度出发,解决社区版存在的一些问题,降低用户的运维成本与使用门槛。

三、架构进化

系统重构中,最直观的表现就是架构层面的演进,如何精简原有繁杂的各类模块,将耦合度高的流程进行整合,缩短数据流的关键路径,以及让整个系统管理更加精细化。

图1 系统模块组成,蓝色为新架构模块

如图1所示,系统在发展过程中,运维体系会越来越繁杂,其中包括各种不同功能的服务,对于系统的部署和维护造成了诸多不便,在重构过程中,我们将若干模块进行了精简与收敛。

图2 架构图

同时,CKV+从传统的三层架构,转为两层架构,如图2所示,将接入层的逻辑与存储层合并,有效降低了成本。同时,我们引入了可选的Proxy组件,能灵活兼容更多协议(如Memcached,ASN等)的同时,也使系统在一些特殊业务场景中(如业务链接数量较大,对接入层的平行扩展能力有较强需求等)更加游刃有余。 另一个较大变化则是线程模型,原CKV系统使用了网络IO与核心流程解耦的多进程模型,逻辑处理部分使用进程间加锁访问的方式,这种模型在性能、吞吐方面都有不俗的表现,但也存在两个较明显的缺点:1. 在硬件发展极快的前提下,为了提升硬件资源的利用率,逻辑处理模块需进行平行扩展,但加锁访问的模式会让用户请求的处理过程中出现较严重的毛刺现象;2. 由于网络处理与数据操作进行了解耦,对于一些基于网络的策略与流控,实现时的复杂度较高,且对性能有较大影响,而这部分功能的欠缺,会导致无法有效的提升系统隔离性。

图3 线程模型

重构后的CKV+则使用了单进程多线程的模型,将IO、内存引擎等逻辑模块聚合到同一个进程中,方便在多租户的环境中支持更多纬度的监控统计,以及订制更加细化的网络、CPU、磁盘等资源的管理策略。 当然,多线程也可能会带来一些潜在的问题,比如对于单条记录并行读写时,加锁仍会存在毛刺现象,IO是否会对核心引擎处理产生影响等。针对上述场景,我们也进行了调整,将同一个实例数据的读写操作进行收敛,让其在单个核上串行,其他CPU资源则负责IO,编解码等任务,让整个处理流程无锁,如图3所示。同时,引入了异步编程模型,利用异步IO等操作,将原本CPU消耗型的指令进行拆分,尽量减少毛刺,提升系统吞吐。 与原有系统相比,在功能场景方面,CKV+也有诸多改变。比如,在数据同步方面,新系统采用了流式传输,解决了原来同步流程容易产生瓶颈的问题;在跨地域方面,我们支持了主备分片的隔离策略可配置,以便支持业务跨机房容灾的场景;并开发了秒级回档,只读实例等提升用户数据安全的特性等。

四、自研与开源

在系统设计阶段,我们充分考虑到了当前各类用户的需求,以及业界的发展趋势,决定对Redis协议进行深度兼容。而选择Redis,主要因其作为KV系统,兼具协议简单易懂、功能用法丰富、核心功能稳定、应用场景广泛等优势。当然,Redis本身也存在一些缺陷和不足。因此,在充分发挥自研系统贴近应用场景,迭代快速等优势的前提下,我们希望为用户提供更强大,更好用的服务。 作为自研数据库,与原生Redis及一些基于原生的解决方案存在很多差异。对于很多Redis用户来说,CKV+最大的不同是多租户,即CKV+本身是一个分布式存储系统,且每个集群中存储了若干不同的业务数据,如图4所示。

图4 多租户模式

多租户可以更好的利用空闲资源,大大减少了重复的运维操作,也降低了单独维护大量进程实例的配置信息的人力成本,同时,可以更方便的对监控告警及统计信息进行收敛。 但部分云上的用户对此模式却存在一些疑惑,比如原生Redis单进程维护单实例的场景中,每个用户都可以订制自己服务的维护/升级时间,而多租户则无法做到业务纬度的独立升级;同时,用户对于不同实例间是否会相互影响,甚至产生资源争抢也存在疑问。

图5 热升级

我们在开发的过程中,也充分考虑到了用户的这些担忧,针对这些场景进行了优化改造。对于维护/升级,我们给出了更加彻底的解决方案,开发了热升级功能,如图5所示,在进程升级(替换)过程中,对于用户完全透明,无论长连接还是短链接,请求均可正常处理。这样不仅无需让用户再关注后台服务维护/升级的事宜,也解决了升级过程中,由于存量链接的中断,造成业务短时间受损的现状。 至于不同业务间相互影响的潜在风险,我们也做了大量工作。我们将一些利用内核实现的进程级别隔离方案(如cgroups等),在自身服务内部进行了实现,针对链接数、流量、内存使用量、磁盘容量、CPU使用率等都进行了隔离限制,同时支持实时的动态配置。 CKV+与原生Redis的另一个差异在于数据一致性。CKV+在最终一致的数据同步基础上,引入了基于Raft协议的强一致同步逻辑,为部分对于数据可靠性要求极高的业务提供更有保障的服务。 除此之外,在内存引擎方面,CKV+沿用了基于共享内存的数据管理方式,支持进程启动时,毫秒级的数据加载,避免服务异常恢复时对快照或流水的读写及解析。同时,我们对Redis通过Fork子进程生成快照的机制进行了优化,无需为每个实例预留一倍内存,从而避免了内存资源的浪费。

图6 内存引擎 在内存引擎方面,我们设计了一套具备自身特点的动态内存分配机制,避免初始化时系统预留过多资源,导致用户数据空间被占用等问题。同时,在共享内存中实现了Redis的复杂数据结构及各类语义。在内存使用率方面,较之原生也有更好的变现,如表1所示。

表1  1G内存实例中,随机样本存储对比

在引擎核心算法方面,我们也将会持续优化,做到在各种数据样本中,都能最大化利用内存资源,从而进一步降低用户成本。 除此之外,CKV+也继承了上一代系统的一些颇受好评的功能,如混合存储,将长时间没有访问的数据,转存到价格更低廉的介质上,数据的上浮下沉由系统基于既定规则自行触发,可极大的降低存储成本;以及CAS(Compare And Swap),在并发访问环境下,满足多客户端协同的需求等。 同时,我们在兼容Redis的各类功能时,也对齐进行了一定的优化和扩展,如集群版支持多DB,MGET/MSET不再受Slot限制等。未来,我们会持续推出更多更好用的功能,支持更多场景,也会对原生Redis欠缺的部分进行补充。 最后,开源与自研其实并非矛盾对立的两面,而是协同发展的关系,自研系统在借鉴、兼容开源的同时,也会推出许多更加方便,更贴近业务场景的功能,希望这些功能未来有机会被开源社区消化吸收,让更多用户受益。

五、效果

表2中对一些常用特性进行了横向对比,由于CKV+继承了原系统的部分场景,同时兼容了Redis的核心用法,因此,在易用性方面表现更好。

表2 特性对比

对于大家更关注的性能,由于Redis本身仅能使用单个核,因此在并发场景下的表现并不理想,而CKV+利用了多核优势,将请求流程中的网络IO、磁盘IO、编解码等非数据处理逻辑放到了所有核上,可获得较高的吞吐量,如图7所示。

图7 与Redis性能对比

而CKV+在处理ASN及Memcached协议时,单台Proxy的QPS可达到120万/秒,比原CKV提升了30%左右。

六、总结

CKV在若干年的开发运营中,服务了公司内外的众多产品,在慢慢壮大的同时,也暴露了许多不足。我们结合线上运营过程中遇到的问题及业务场景需要,对系统进行了全面的改造,将冗余的模块精简、收敛,重新打磨存储引擎,对普及度较高的开源协议进行了深度兼容,推出了更加贴近用户特性与用法,在易用性、可用性、可靠性、性能、成本等方面都有较大提升。 接下来,我们会持续对系统进行优化,对技术进行沉淀,希望能为更多用户提供更强大、更好用的服务。


腾讯数据库技术团队对内支持微信红包,彩票、数据银行等集团内部业务,对外为腾讯云提供各种数据库产品,如CDB、CTSDB、CKV、CMongo, 腾讯数据库技术团队专注于增强数据库内核功能,提升数据库性能,保证系统稳定性并解决用户在生产过程中遇到的问题,并对生产环境中遇到的问题及知识进行分享。

本文分享自微信公众号 - 腾讯数据库技术(gh_83eebc796d5d)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-01-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • InnoDB索引物理空间使用率统计

    「引言」 为帮助用户解决何时optimize table的烦恼,CDB开发了InnoDB索引物理空间使用率统计功能。 「第一部分 背景」 InnoDB是一种数...

    腾讯数据库技术
  • 关注这些腾讯公号,助你走上人生巅峰(送价值万元的福利)

    来了?鹅厂小编们等你很久了!咱们闲话少叙,今天,10位小编携手为你奉上10份超级大礼: 书籍、技术教程、鹅厂公仔、腾讯云代金券……每位朋友都可以免!费!参与抽...

    腾讯数据库技术
  • 如何利用红黑树实现排名?

    腾讯数据库技术
  • 如何使用 Redis 实现大规模的帖子浏览计数

    满足上面四个条件,其实比想象中要复杂。为了在实时统计的情况下保持精准度,我们需要知道某一个用户之前是否浏览过一篇文章,所以我们需要为每一篇文章存储浏览过它的用户...

    芋道源码
  • 升级和游戏音效 如何在场景和声音效果之间切换

    在游戏中,您通常需要一项功能,以便在游戏进行时使游戏更难。例如,在Mario中,您需要清除每个阶段以传递到下一个区域。每次通过舞台,难度都会变得更难。在本节中,...

    iOSDevLog
  • 【中文】【吴恩达课后编程作业】Course 2 - 改善深层神经网络 - 第一周作业(1&2&3)

    上一篇:【课程2 - 第一周测验】※※※※※ 【回到目录】※※※※※下一篇:【课程2 - 第二周测验】

    Steve Wang
  • PayPal创始人《从0到1》作者彼得•蒂尔,上周宣布与他的同性男友结婚了

    大数据文摘
  • 直播平台开发中美颜、滤镜的技术要求

    直播平台开发完成采集之后得到原始数据,为了增强一些现场效果或者加上一些额外的效果,我们一般会在将其编码压缩前进行处理,比如打上时间戳或者公司 Logo 的水印,...

    布谷安妮
  • linux如何挂载windows下的共享文件

    说明: windows下有一共享文件夹APP,windows本地ip是192.168.9.155 现在需要在linux服务器上挂载这个APP文件夹,linux服...

    洗尽了浮华
  • Appium+python自动化15-Mac上环境搭建

    前言 mac上搭建appium+python的环境还是有点复杂的,需要准备的软件 1.nodejs 2.npm 3.cnpm 4.appium 5.pip 6....

    上海-悠悠

扫码关注云+社区

领取腾讯云代金券