电商不仅仅是大数据驱动的，京东用大数据为用户、商品等带来运营效率的提升。同时，从在线的数据访问来讲，电商业务需要非常快速的数据访问。大家可以看到，京东随便打开京东首页或类似的电商首页，图片是京东的资产，是商品形象的描述，可以用CDN加速。除了图片之外，其他几乎都是动态内容，量很大，且是频繁被改写的，它们需要非常快速的访问，比如说商品的详情、价格、品类下推荐的结果等许多内容，打开个商品详情页面或列表页，后台逻辑是很复杂的，需要非常多的数据去展现。

这个过程中，一个是快速的数据访问对终端用户的体验有非常关键的影响。另外，从京东产品工程师开发的产品角度出发，另一个诉求就是关注业务逻辑，而不应该花时间优化后台在线存储的性能。Jim Gray是数据库领域的泰斗级人物，他其中一句话我记得很清楚，即“Memory is the new disk（内存是新的磁盘）”。07、08年时京东买的内存大小标准配置是4G左右，很快4G、8G、16G一路下来，很多公司都会采购158、265G内存，估计明年都会用1T内存。京东都用265G内存加万兆网卡来做，单机内存在快速变大，整体很多在线的小结构和半结构化数据存放在内存里，这个问题是不大的，也是非常合理的。而且用内存做在线存储确实有弊端，就是成本在一个时间段内有些偏高，但是除此之外却带来很多性能、管理等各方面的便捷性，两相权衡下，在一定程度上，成本的升高对有一定规模和业务比较重要的公司可以接受，而且京东可以用技术手段降低这个成本。

JIMDB的全称为The Jingdong In-Memory Database，这个系统的名字是大概2014年初起的，它并不是严格的关系型数据库，而是一种新型的，以内存为中心的全部托管、全管理服务化的数据库。它是以内存为中心的数据存储，主要针对在线的结构或半结构化的数据，过去两年一直在持续建设。从目前的业务价值角度，它支撑了京东几乎所有的在线业务。除图片之外，几乎所有的动态内容都被它所服务，或者严格来说，图片的有些信息也用它来存储。越来越呈现一个趋势，就是京东更多地用它来做主存储，MySQL或者DataBase会进行归档。

接下来从技术角度做个简单介绍。JIMDB基于redis，redis是一个非常优秀的开源软件，它做对了两个事情。之一，它是基于内存的，简单且高性能；第二，也是基于内存，它提供了非常丰富的数据类型和数据结构。对许多互联网公司来说非常方便，比如商品的详情、属性等，非常便捷。两年前，京东为了解决它的痛点，因为之前的监控系统已不能满足京东的业务需求，便不断演进，一路做下来。

它是相对分散的分布式系统，有许多分支、模块，不同模块做不同的事情。从用户（业务的开发人员）的角度，给他们提供Java、C driver，其他小众语言是给他们提供 *** ，完全兼容但是不限于RAM servers 。对于任何一个业务都给它集群，所有集群都在京东的物理资源池上。京东这个团队的核心任务是做一套复杂的平台，一套健壮的分布式系统，管理目前大概四五千台大内存机器，为众多业务提供可靠的、性能稳定的、数据有持久性保证的高可用服务。

这个系统从部署结构来讲，是单个物理服务器、多实力的结构，任何大内存物理servers上都会部署多个内存，好处是便于流量监控等，但是给业务和监控带来很多复杂性。对行业来说目前还是比较合理，故障的检测与切换，扩容的管理、升级、监控等都是独立的模块。存储的servers是复用原来redis *** 编程的框架，但是复制的协议、存储的引擎等各方面都是自己来开发。

在此列举几个技术点。之一，怎么做故障切换？分布式系统要解决的之一个问题是怎么处理故障。故障是个很严肃的事情，并不能简单说有一个进程有一个servers不通了就是故障，会发生 *** 不稳定等等，各个方面都有可能。在一个或多个数据中心有若干个故障检测器，当多数人认为它故障并且没有人认为它健康时，才能定位确实故障。发给故障的控制器做下一步事情，重新触发新的配置，改变集群的拓扑。所以故障的检测和自动的Failover是2014年做的之一个事情，把故障自动化，这个事情说起来简单，其实是最基础和最重要的，因为整个过程分很多步骤，前一段时间还出现过Bug。