写点什么

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))。

2015-12-11 17:1814103
用户头像

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

关注

评论

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

【模块五】设计微博系统中”微博评论“的高性能高可用计算架构

yhjhero

架构 #架构训练营

python pandas loc布尔索引(指定条件下的索引),你花了多久弄明白架构设计

程序媛可鸥

Python 程序员 面试

315权益日解读:“幸运”大牌和巨头,“挡枪”作坊和“小弟”?

易观分析

315晚会 央视315晚会 消费者权益

Cloud RedTeam视角下元数据服务攻防实践

火线安全

云原生 云安全

一眼定位问题,函数计算发布日志关键词秒检索功能

阿里巴巴云原生

踏雪痕项目管理学习笔记

踏雪痕

项目管理 PMP Certification 3月程序媛福利 3月月更

golang并发控制设计中的“流式模型”

不登山的小鲁

golang

腾讯云COS对象存储攻防

火线安全

云原生 云安全 云原生应用

欧拉的奇异之旅·共赴开源时代

脑极体

【网络安全】记一次网站站点渗透

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

python Excel数据表格转为HTML网页数据表格,阿里快手拼多多等7家大厂Python面试真题

程序媛可鸥

Python 程序员 面试

python sorted()函数及sort()方法,零基础Python开发

程序媛可鸥

Python 程序员 面试

档案管理系统平台:助力实现档案管理现代化

小炮

Python 下载的9种方法,Python开发技巧

程序媛可鸥

Python 程序员 面试

Python 实现七大排序算法,面试竟然被这31道Python基础题难倒了

程序媛可鸥

Python 程序员 面试

网络安全 kali Web安全之CSRF攻击

学神来啦

网络安全 CSRF WEB安全 kali kali Linux

企业CICD规模化落地浅析

阿里云云效

云计算 阿里云 云原生 CI/CD 持续交付

阿里云 OSS对象存储攻防

火线安全

云安全 阿里云;

微软云对象存储攻防

火线安全

云原生 云原生应用 云安全攻防 云安全研究

使用APICloud平台实现朋友圈功能

YonBuilder低代码开发平台

html5 css3 APP开发 APICloud JavaScrip

攻击面管理(ASM)技术详解和实现

风向标

网络安全 asm 安全419 零零信安

python 列表 remove()函数使用详解,最新手淘Python高级面试题及答案

程序媛可鸥

Python 程序员 面试

低代码如何助力化学材料行业数字化升级?

TOBESOFT特碧软件

低代码 数字化转型 MES系统 制造业 TOBESOFT

2022年,人工智能和数据发展呈现哪五大趋势?

澳鹏Appen

人工智能 机器学习 深度学习 训练数据

Python 实现 ZeroMQ 的三种基本工作模式,贼好用的Python学习路线集合

程序媛可鸥

Python 程序员 面试

关于帮助中心,你需要知道的一切

小炮

Nebula Graph 在企查查的应用

NebulaGraph

数据库 开源 图数据库 知识图谱

网站被DDOS攻击了怎么办?

源字节1号

开源 前端开发 后端开发

案例研究:亚马逊广告使用 PyTorch 和 Amazon Inferentia 扩展广告处理模型

亚马逊云科技 (Amazon Web Services)

模型 PyTorch

自从用了这个APP,我的身体状况....

IT蜗壳-Tango

极客时间 IT蜗壳

红黑树的原理以及实现

Linux服务器开发

数据结构 B+树 红黑树 Linux服务器开发 Linux后台开发

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