【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

JIMDB:一个大规模分布式内存存储的演进之路

  • 2015-12-11
  • 本文字数:3588 字

    阅读完需:约 12 分钟

写在前面 Redis 是一个 C 语言编写的开源、支持网络、基于内存、键值对存储、可持久化的高性能 NoSQL 数据库,同时提供多种语言的 API,目前最新版本为 3.0.5 。由于性能优异,已被国内外众多公司采用构建缓存集群。其中,京东对Redis 的应用实践可圈可点。

在2014 年的 QCon 上海大会上,京东云平台首席架构师刘海锋介绍了京东分布式内存存储平台(RAM store platform)。经过两年多的演进,这套系统已经支撑起京东几乎所有的在线业务。近日,InfoQ 采访了刘海锋,再探这个分布式内存存储平台的全貌。以下是采访实录:

InfoQ:你能简单介绍一下 JIMDB 这两年来的研发过程吗?

刘海峰:JIMDB 是一个以内存为中心的键值数据库,目前在我们京东多个数据中心部署了几千台机器,支撑了京东几乎所有的在线业务。JIMDB 的研发是一个逐步演进的过程,最初是从 Redis 改进而来,现在的数据模型是兼容但不仅限于 Redis,可以理解为 Redis 的一个超集。JIMDB 在京东的应用也不限于缓存,我们很多业务线已经把它当成唯一的存储。

具体来说,研发过程经历了三个阶段:

  • 第一个阶段是从 2013 年底开始。当时我们在使用 Redis 时遇到了一些问题,为了解决这些问题,我们把 Redis 这个优秀的单机软件变成一个健壮的分布式系统。比如我们要做故障的手动、自动切换;要实现横向扩展,动态分片并且不能影响网络流量;要实现灵活的异步复制、同步复制。虽然每个实例仍然是单个的 Redis,但整个的集群能够实现故障的切换、横向的扩展和比较灵活的复制。
  • 第二个阶段从 2014 年下半年开始。用一句话来概括这个阶段就是把 JIMDB 变成了一个完全托管、自管理、自运维的存储服务。因为 Redis 的引擎比较简单,为了实现这个目标,我们重写了整个内存存储的引擎,使之可以支持更细粒度的分片;复制协议部分也作了改动,不但支持全量复制、增量复制,还支持了任意局部复制。例如,我们经常遇到某个分片上的热数据过载的问题,这时候的解决方案是把这部分数据复制到其他的实例上,从而分散流量,这样我们就实现了动态的分裂、合并。在运维管理上我们引入了 Docker,部署环节实现了整体的调度。
  • 第三个阶段在 2015 年上半年启动规划,目前这个阶段还在进行中。我们已经把很多实现陆续推到了线上。即,不仅仅支持原来的哈希分片和原有的数据类型,我们还实现了在内存中支持 B+ 树、支持按范围的划分、支持排序的遍历、复制协议也更健壮、更可靠,等等。第三阶段实现的特性将比 Redis 更加强大。当一个分布式存储支持按范围分片和复制的时候,这个系统无疑是更健壮和更可靠的。当然,这个阶段也存在很多的挑战,例如,哈希的分片相对来说比较简单,但我们要实现按范围、跨数据中心的异步和同步复制时,这个挑战就大的多了。

纵观这两年的发展,JIMDB 从最初的几台服务器到现在的几千台、从单机 Redis 系统到自管理的分布式存储系统、用户只需要一个认证授权即可使用、支持京东线上一千多个业务(集群),是一个不断挑战的过程。

InfoQ:市面上已经有了大量的键值对存储数据库,并且已经在大公司的生产环境投入使用。为什么京东还要开发 JIMDB?

刘海峰:这更多的是业务的需求。公司原来的存储应用百花齐放,有人用 Redis、有人用 MongoDB、有人用 memcached 等等。但现在的情况是,数据库用 MySQL 比较多;NoSQL 几乎 99% 的都在用 JIMDB。原因在于 JIMDB 有人维护、自管理、性能稳定,俨然已成为京东内部垄断性的应用。但在项目开始的时候我们也没想到会变成今天的规模,随着业务的发展,JIMDB 一步一步演进成了今天的样子。

InfoQ:JIMDB 在京东的主要应用场景是哪些业务领域?在这些应用场景里,跟其他内存存储相比 JIMDB 有哪些优势?

刘海峰:目前 JIMDB 的应用场景十分广泛。比如,现在依然有很多同事把 JIMDB 当 Redis 来用,很多人拿来当缓存用,也有很多人把 JIMDB 当唯一存储在用,用法不一而足。甚至,很多离线计算 MapReduce 的结果也直接存在 JIMDB 里;对京东的访问用户来说,大家看到的商品详情整个页面的所有元素、第三方 show 的广告、搜索推荐的结果等等,都是存在 JIMDB 里面。我们支撑了无线端、PC 端很多业务。但总的来说,目前用量最大的业务是搜索和推荐的集群,另外单品页的用量也很大。因此这个系统的压力也很大。

跟其他内存存储相比,首先这个系统是从 Redis 演进过来的,Redis 有的功能我都有,但是 JIMDB 在很多方面都比 Redis 更健壮、更稳定。其次,从 Redis 的视角来说,这是一个经过大规模生产环境验证的、更好的 Redis。目前我们有六、七个人在维护这个系统。

InfoQ:对冷热数据的处理以及数据持久化 JIMDB 是怎么做的?在算法和数据结构方面 JIMDB 做了哪些优化设计?

刘海峰:持久化还是采用经典的方式——记日志、定期做快照。虽然这是一个很简单的方式,但是十分的有效。对于可预测的热数据我们会预先做分片,尤其是秒杀活动的内容;而对瞬时的热数据做动态调整是 JIMDB 最优先的特性实现,这跟我们电商的特性相关。目前京东的老机房大量部署了 JIMDB,新机房也部署了很多。

算法和数据结构方面,刚才已经举过一个例子就是 B+ 树。我们实现了 KV 的有序排列和按任意范围的分割、复制。这是我们新加的数据类型,其他的支持已经十分强有力了。

InfoQ:据我所知 Redis 所在机器物理内存使用率并不高(貌似没有超过实际内存总量的 60%)。针对京东这么大规模的在线存储,内存管理方面 JIMDB 是怎么做的?

刘海峰:这一方面主要做的工作是内存分配器的优化。Redis 的内存分配器是 jemalloc ,我们依然沿用了 jemalloc,但是我们作了很多优化。此外,我们对比较大的 Value 做了特殊处理,比如我们不让大 Value 的存储占据内存,而把它写到磁盘中去。但是很多人会问 SSD 的问题,为什么不采用混合存储的架构?

其实在 2014 年的时候我们专门在线上测试过这个方案,当时大概对 10% 的集群采用了混合存储的方案。经过一段时间的测试发现:

  • 首先,虽然 SSD 的成本有一定的优势,但实施工程是有成本的。基于磁盘去写一个有丰富类型的键值数据库其实是比较复杂的,即使是简单的键值都比较复杂,在遇到 Map、List、B+ 树等等,用磁盘的方式实现起来其实更为复杂、成本更高。也就是说,其实现和维护的成本太高,并且性能也不占优,整体工程成本远远超过内存存储。
  • 第二个原因在于,内存的价格在逐渐降低,我们是能承受这个成本的。目前我们使用的内存也越来越大,预计明年我们将在单机上使用 1T 的内存。
  • 第三个原因是系统架构方面的考虑。我们的数据中心有很多的机器,很多应用服务器和私有云服务器多数时候的内存利用率并不高,我们可以利用这些机器的资源做 JIMDB 的动态资源池,只需要在相应的机器上部署一个 JIMDB 的程序就好。这也极大地提高了整个数据中心的资源利用率。

基于以上三点考虑,我们选择用内存做存储。随着京东业务的发展,未来 1~2 年我们 JIMDB 的规模将达到 1 万台机器,当然,这 1 万台机器并不是专用的,而是 JIMDB 在整个数据中心的部署量。

InfoQ:你能谈谈 JIMDB 在“双 11”大考中的表现吗?

刘海峰:JIMDB 在“双 11”的表现很好,系统稳定,性能平稳。我们的新机房启用了大量万兆网卡,以前千兆网卡被打满的情况终于得到缓解。但任何系统都不可能没有任何瑕疵,现在看来 JIMDB 的问题更多的不是技术性的,而是系统到了一定量级怎么去运维,尤其是系统预警和运维操作流程方面的工作需要加强。随着公司业务的发展,运维正变得越来越重要。

我们花了很多精力来做监控与运维。JIMDB 核心的部分是一个个兼容 Redis 协议的 Server,除了网络部分,我们几乎重写了整个存储引擎。还是拿一个具体的应用场景来说吧,假设我一台机器上跑了 15 个实例,但是发现其中一个实例的流量极大,把其他实例的带宽都给占了。这个时候我需要对这个有问题的实例进行分裂和迁移。但是迁移的时候存在一个问题,由于进出流量都很大,迁移有可能是迁不动的。这个时候我们有一个限流措施,保证在不影响其他实例带宽的情况下把有问题的实例迁走。

InfoQ:你怎么看待 JIMDB 未来的发展趋势?或者,你能否谈一下内存云存储(RAMCloud)的未来?

刘海峰:我非常坚信的一点是,内存是存储的未来,特别是对一些有结构化的数据来说。随着内存成本的降低,以及在内存上实现存储的简洁和高效,这个趋势势不可挡。而且我认为 JIMDB 这两年做的工作是一种更务实的 RAMCloud 实现,它是业务驱动的、经过大规模生产环境验证的。

未来随着系统的发展,在功能上我们会以内存为中心,做有序的、KeyValue 的、丰富数据类型的大表支持。JIMDB 未来有可能会加入一些 SQL 的支持。目前要先把规模、稳定和运维做好。


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2015-12-11 17:1813739
用户头像

发布了 64 篇内容, 共 22.4 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

在线 Notebook 教学实训,支持分组评审作业|ModelWhale 版本更新

ModelWhale

人工智能 机器学习 数据分析 编程建模 教学实训

对话ACE第六期:数据库上云的趋势和挑战

OceanBase 数据库

安全!稳定!可信!选OceanBase就对了

OceanBase 数据库

客如云×OceanBase:分布式云升级助力客如云降本增效

OceanBase 数据库

新能源物流车行业如何服务升级 地上铁联合火山引擎VeDI“破题”

字节跳动数据平台

大数据 数据应用

【C语言】default 关键字

謓泽

11月月更

随想 小城市的程序员该如何生存

百里丶落云

生活状态 生活杂谈 11月月更

GPU 和显卡是什么关系?

Finovy Cloud

人工智能 gpu 云渲染 GPU渲染

Linux su命令 – 切换用户、用户提权

A-刘晨阳

Linux 运维 sudo 11月月更 用户提权

开发问题记录

青柚1943

OceanBase 社区版4.0发版:一个全新的里程碑

OceanBase 数据库

抓包分析 TCP 握手和挥手

C++后台开发

网络协议 TCP/IP 后端开发 C++开发 抓包分析

【LeetCode】第 k 个数 Java 题解

Albert

算法 LeetCode 11月月更

我服了!SpringBoot升级后这服务我一个星期都没跑起来!(上)

艾小仙

Java spring 程序员 springboot spring-boot

Vue基础学习(一)

Studying_swz

Vue 11月月更

Flowable 设置流程变量的四种方式

江南一点雨

springboot flowable

华为正式发布毕昇C++编程语言,全面升级毕昇编译器

科技热闻

项目管理的精髓

PMO实践

项目管理 PMO 项目经理

Linux文件系统ln-软连接、硬链接

A-刘晨阳

Linux 运维 11月月更 软硬连接

web服务器

初学者

网络 web服务器 11月月更

易仓科技×OceanBase:打造跨境行业全生态链的新零售SaaS

OceanBase 数据库

数字化转型中的数字智能

PMO实践

数字化 科技 数智化 数智未来

python中私有成员和公有成员

乔乔

11月月更

JavaScript学习(二)

Studying_swz

JavaScript 11月月更

低代码选型应该注重哪些方面的能力?

优秀

低代码

Linux中的日志管理

A-刘晨阳

Linux 运维 日志 log 11月月更

零依赖监控解决方案:TDengine+Grafana落地实施

TDengine

数据库 tdengine 时序数据库

从ZETA无线通信技术特点出发选择合适的物联网协议

ZETA开发者

物联网 通信 通信协议 无线通信 物联网技术

OceanBase CTO杨传辉:单机分布式一体化助力企业降本增效

OceanBase 数据库

Vue基础学习(二)

Studying_swz

Vue 11月月更

深入理解Metrics(二):Counters

冰心的小屋

Java metrics Counters

JIMDB:一个大规模分布式内存存储的演进之路_服务革新_魏星_InfoQ精选文章