专家分享:京东分布式存储建设之路(JFS)

　　一拍而合，京东分布式存储起航

　　在项目中你经常会遇到，有一些图片、视频或者文本需要存储，你希望它不丢失的同时还要能提供高速读写的能力。对于京东来说，这样的需求每天都在发生着，而且要求会更高，因为这些可能是用户的订单数据，你希望即使在写的时候断电了、磁盘坏了，你的数据还在;你希望即使服务器故障了、交换机坏了甚至机房挂了，用户还能正常访问;你希望在大促来临时即使用户访问量倍级增长，它依然能提供高速读写。没错，现在很多人都会告诉你，用JFS京东文件系统，它能满足你的需求。

　　时间回到2013年，海锋哥刚来到京东，很快地他发现京东对存储有强烈的需求，既有海量小文件的在线存储，又有大量离线数据的存储，当前公司内部在这块做的并不好，各个业务部门自己做自己的，很多慢慢开始满足不了业务增长的需要了。一个想法油然而生，他决定做京东统一的分布式存储平台，满足公司各个业务线的需要。

　　有另外一个存储的小团队，成员只有6,7个人，虽然工作年限普遍不长，有几个还是刚毕业，但也都想着在存储方向做出一番业绩。同样的愿景，很快大家走到了一起。在海锋哥的领导下，系统技术部存储组正式成立，开始京东分布式存储的研发。

　　从2013年到2016年，这一做就是三年，当年的小鲜肉都成为了公司存储方向的中坚力量，成为了存储专家，而JFS也成为了京东业务核心底层存储，支撑了公司1000多个业务。一路走来，踩过很多坑，也有一些体会，给大家分享下。

　　艰难抉择，分布式存储技术选型

　　京东有各种各样的数据存储需求，有大小10KB的订单数据，每天以上亿的速度增长;有大小90k-200k的图片数据，总量超过几十亿，且每天还在以千万的速度增长;也有几十兆的App客户端文件，每次更新都伴随着巨量的用户访问;还有1GB甚至10GB以上的内部日志文件存储。各个业务部门使用的存储方式也五花八门，有用Mysql的Blob类型存储，也有用开源的FastDFS和Hdfs。诚然，这些软件在京东的快速发展中起了至关重要的作用，但随着业务规模的持续增长，也开始暴露出来了各种各样的问题。摆在我们面前的路有两条：一种是在开源系统的基础上做定制开发，还有一种是自研。两种方式各有优缺点，最终经过一轮轮调研下来，我们还是决定走自研之路。这里以大家熟知的Hdfs及其生态为例，回顾下当时抉择的过程。

　　毫无疑问，Hdfs是一个相当优秀的开源存储项目，但它毕竟是为离线大文件设计，对于京东海量的在线小文件无能为力，二次开发需要对整个架构动手术。还有一种考虑，使用Hdfs存储大文件，使用HBase存储小文件。当然，这种方案也不适合京东，主要有两点：第一、HBase读取文件时，请求先打到RegionServer上，由RegionServer去Hdfs取数据，再返回，相当于一次IO请求经过了两次网络传输，这对于追求极致速度的很多应用场景是不合适的;第二、HBase在做Split的时候会导致服务短暂的不可用，这对很多要求提供7*24小时无间断服务的业务则更是不可接受。

　　虽然自研的周期会更长，但它灵活可控，且从长期来看，也能获得技术收益。

　　日夜挑灯，JFS小文件存储

　　厨师到位，菜已洗净，接下来就是从哪里下手了。要做京东统一的分布式存储，这是一件非常困难的事情，因为即便是现在，也没有见到能同时很好的支持海量在线小文件和离线大文件的开源解决方案。很庆幸的是，当时我们并没有选择一步到位的完美解决方案，而是紧扣业务，高度定制，分期展开这条路。

　　小文件存储则被选为了桌上的第一道菜。无论是商品图片、交易订单，还是库房订单，这些电商数据都需要非常强的可靠性、可用性和一致性。在复制协议上，我们采取了三副本强一致性复制，由1Primary +2Followers构成，如下图所示。写操作时，由Client将数据发送到主上，然后由主同时发给两个从副本，三副本都写入成功后才返回给用户成功。而在读取时，优先在从上读取，来提高系统的并发能力。

　　在数据存储上，考虑到文件比较小，如果用户上传一个文件，对应在服务器上建一个文件存储数据的话，那么一块2T的盘上面将存放几千万甚至上亿个文件，给服务器带来沉重的负担。我们采取了事先建好大文件，然后不停的追加写入方式，使用偏移量和大小来访问数据。当然为了避免单个大文件集中读写造成文件锁资源竞争激烈，我们采取了多文件追加方式，如下图所示：

　　现在已记不清经过多少个日日夜夜的挑灯夜战，慢慢地加班餐的小姑娘因为熟识了，会有意给我们多舀一些菜;团队的年轻小伙伴白净的脸上多了一圈黑眼圈。终于，在4个月后的一天，我们迎来了第一个孩子，京东小文件存储系统终于正式落地。当然，它也没令大家失望，在与同类的开源软件对比测试中，性能等各项指标都占优。

　　一个新系统的推广总是很艰难的，最初我们开始推广给在一些非核心业务的数据存储上，慢慢的应用起来。当然，我们也一直在准备着一条大鱼的到来。

　　小试牛刀，京东新图片系统

　　时间回到了2014年，老一些的员工可能还有印象，随着图片数据量和访问量的暴增，老的图片服务已经达到了性能瓶颈。客服每天都会收到大量用户投诉图片访问速度慢，IO异常、多副本数据不一致的情况也时有发生，告警邮件都快塞满了相关业务部门的邮箱。

　　老的图片系统最早可以追溯到好多年前，当时也是选择了一个业内使用广泛的开源存储方案。最初的一两年一直相安无事，但随着数据量的暴增，开始暴露各种各样的问题。最开始业务部门还能通过修改配置，加一些缓存策略来解决，到了后来，这些完全不起作用了，需要从整体存储架构上优化。

　　这时候的JFS在一些非核心的业务上获得了较好口碑，于是，图片的业务部门找到我们，希望能将图片业务迁移到JFS上来。

　　时间已经到了14年的4月份，离京东上市的日期也就一个月了。我们需要在JFS存储之上开发一个新的图片系统，还需要在不影响现有的业务情况下，完成20亿历史图片的迁移，这其中蕴藏的巨大风险大家都心知肚明，但并没有经过太多复杂的权衡，我们很快应允了下来。

　　再接下来就是一段与时间赛跑的历程，团队成员快速分工，几个同事用了一周的时间完成新图片系统搭建，同时另几个同事完成了数据双写、迁移和校验方案的实现，然后再用了三个星期完成了全部20亿存量数据迁移和校验。最终在公司上市前夕，完成了新老图片系统的切换，彻底解决了图片访问慢的问题。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!