电商不仅仅是大数据驱动的，京东用大数据为用户、商品等带来运营效率的提升。同时，从在线的数据访问来讲，电商业务需要非常快速的数据访问。大家可以看到，京东随便打开京东首页或类似的电商首页，图片是京东的资产，是商品形象的描述，可以用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。
第二个关键问题是任何一个逻辑的集群、业务数据量会增长、变化，所以必须支持在线、动态、重新的分片，或者说重新的Sharding，这个Sharding核心思想不是简单把集群分片，中间要加一个抽象，才能进行动态的重新分片。对于这个策略来说，中间加一个bucket的抽象，然后来进行管理。迁移的过程是通过复制来做的，学术界或工程界喜欢管它叫“Partial replication”。举例来说，原来是3个分片，现在怎么变成4个分片？通过调度算法，决策把哪些分片中的bucket迁移到这里，迁移是通过复制来做的，建一个复制关系，但是这个复制关系并不是复制它原来所有的数据，所以要求复制协议的实现是要做特殊的事情，只要这一个区间的复制，复制全部完成之后更改拓扑，最后生效，这可以做并行的Partial replication做迁移。从数据的可靠性保证比较高，技术也比较简单和传统。
过去两年从底层技术研发分三个方面一步步演进做了些事情，从存储引擎的角度，用的最多的是这个，第二个存储引擎是LSM，京东用RAM+SSD做混合的两级存储，这三种不是取代的关系，而是互为补充。第二种更多应用的场景，是有些东西比较大，京东可以把这个放在SSD上，把K依然放在RAM里，这样可以适当的节省成本，目前第二类线上已经有百分之十几的用量，但是数据量要乘四五倍，因为每台机器单机容量更大。第三类是B+TREE，可以排序，可以支持按范围查找和便利，这个线上用得不是特别多，京东只支持有需要按范围、需要便利查询的场景。
复制协议更加关键，因为对于存储来说最核心的是复制，除了异步复制就是同步复制，京东上半年做了状态机的复制。分片策略京东用哈希最多，因为哈希最简单，业务更多时候需要单K去查询，有些业务需要按范围，京东支持Range。这三个方面技术可以做合理的按业务场景组合，满足不同的业务需求，比如业务更多是用Dict+异步复制+哈希分片策略，比较大的是RAM+SSD两级存储，然后配合其他的策略。
从业务使用场景角度，京东是分而治之，不同的软件、不同的集群，根据业务的需要，可以分成这么两大类。不少业务是做纯缓存，后台还有数据库和其他存储，京东更多是用异步复制或者不复制，哈希的分片，可以做LUR的淘汰。但是线上也有将近一半左右的集群，他们不仅仅用这个东西做缓存，他们做持久存储，京东有更高的可靠性保证，一般用来开启同步或者状态机的复制，然后用范围或哈希分片，而且对它的快照做定时备份，备份到内部对象存储上去。
对任何一个系统来说，底层的基础技术研发仅仅是它的一个环节，当系统达到一定规模之后，更多工作会放在监控和运维体系的建设方面。整个平台京东有比较完善的监控体系，这更多是数据驱动的，从各个方面，连接树、网络入出流量等等，产生很多时间序列进行分析、预警，并且驱动各种控制器做决策。比如有的分片存的数据因为是个华为的手机，它太热了，京东就可以把它做分列，很多时候做扩容做分列并不是因为容量，而是因为数据的热度。数据监控也存在这个系统里做快速的展现。
基于容器的自动化运维，因为我刚才说过，整个系统规模比较大，有几千台机器，而且每台机器上部署很多的存储节点，所以运维的复杂性比较高。在整个2013年更多是依靠手工的运维，怎么样选机器，怎么样部署，运维工作量极大，在2014年下半年和2015年上半年，京东花了很长时间做全自动化运维的平台，它是基于Docker，简单来说是大的Linux大内存服务器上上面有很多Docker，每个进程是Docker实例，用Docker软件管理版本，智能做机器的选择，做定期的软件升级，各个方面很多工作。这个平台通过容器技术也在这里面有所发挥。
说一说规模吧，因为对于任何一个底层系统建设来说，它核心的价值只有一定规模、真实驱动业务才能有收获力。线上京东有多个数据中心，有几千台大内存机器，都需要跨数据中心的复制，有的基于容灾的考虑，比如不同的机房有不同的规则，有可能跨机房做异步复制，有可能同步，预计明年有512G内存或者1T内存机器的采购。线上支持了1000多个线上的业务，每个应用相当于一个逻辑的集群。从运维角度来说，这么多台机器里面有大概3万多Docker的实例。
内存存储带来什么？花了很多内存片、内存条，带来了极佳的性能、非常稳定的性能，这是京东线上某一个比较重要的集群，在双十一期间可以看到它整体的QPS超过200多万，是非常稳定的，99%的请求都在2毫秒之内返回，这个让用户体验更好，让京东的业务开发起来更加简单，让公司运维团队更加省心、更加轻松。
内存存储考虑的一个主要因素是，内存可以花钱买，但是不能因为软件因素再去浪费内存，内存存储是分出来的，线上很多集群比较夸张、比较大，可能因为它使用场景比较特殊，才产生了碎片。但是整个分布来说，京东也做一些优化的工作，从内存分布器选择来看，主要的集群内存碎片率基本在1.1-1.3左右。我个人工程上的经验来说，这是非常好的内存分配器，内存分配器自行开发意义很校
正在做的事情比较多，优先级比较高的是让它更稳定更好的运维，除此之外进一步提升性能，通过软件硬件协同创新，引入更大、更便宜的内存、更快的网卡，考虑重新实现用户的网络协议加速小包的处理性能。Linux网络协议站不是为数据中心高速的网络、高速的在线应用而设计，每一次包都要中断，对于大包是合理的，对于小包是不划算的，这样的存储性能更多的是小包处理，京东在考虑重写用户协议，来加速小包处理的性能。在功能方面京东也在做个事情，这更多是工作量的事情，考虑从NoSQL支持SQL接口，因为底层有了横向扩张、灵活复制的内存里的数据结构的存储。通过JAVA等等提供，这是工作量的问题而已。
另外，希望在某种程度上降低成本，因为平台化第一步是求规模稳定，让它有很好的性能和效率的保证，第二是从整体来说能降低成本，比大家分散、自由去用更省钱。基本的想法是这样的，目前是专署集群，京东希望从专署集群过渡到聚合各个IDC的RAM资源，比如说京东私有云机器去分容器、去分虚拟机，很多时候CPU是瓶颈，分完了内存有剩余，非结构化机器磁盘是瓶颈，磁盘或SSD被分完了但内存有空余，京东聚合整个RAM资源，让数据动态流动、去降低成本。
云数据库服务是一项基础性的云服务，解决用户自己搭建数据库时需要考虑的各种问题，让用户在使用时可以按需申请数据库资源，保证整个数据库服务的稳定性及数据的可靠性，同时提供弹性伸缩等的支持，尽可能的降低用户在使用云数据库时的成本。
本主题主要是分享京东私有云分布式数据库集群的实现，包括如何支撑上亿级数据量的业务，如何保证数据高可靠、服务高可用以及在线集群扩容等机制。另外还会分享京东公有云数据库的架构与设计，如何实现一个稳定、可靠、可弹性伸缩的公有云数据库服务，涉及到备份、恢复、监控、迁移、高可用切换等一整套方案。
京东内部有大量业务的数据是存放在Oracle中的，为了完成京东内部去O的过程，京东为此打造了一套私有云分布式数据库集群，这套私有云分布式数据库集群目前支撑着京东大量拥有上百亿级数据量的业务，本主题中会重点介绍去O过程中遇到的难点同时详细介绍在内部数据库云化以及在支撑大规模业务过程中积累的经验，包括如何打造一套高性能的私有云分布式数据库集群服务，如何在支撑京东上百亿级别数据量业务正常服务的情况下做到在线无缝集群扩容，分享来自京东生产一线的经验。
云服务最重要的是要做到可弹性伸缩可按需获取资源，让用户可以尽可能的花最少的代价满足业务的需求。用户使用云数据库时面临当业务量增长时申请的资源不够，需要做到快速的扩张现有资源，当业务量降低时需要快速缩小现有资源。当数据库实例甚至整个机房发生故障时，要做到用户在云数据库中的数据是安全的可靠的，可以第一时间恢复云数据库服务，包括跨机房恢复等，保证云上的用户业务是不受影响的，这些都是云服务尤其是云数据库服务需要解决的事情，本主题也会介绍京东公有云数据库是怎么解决这些问题的以及在解决这些问题时积累的经验。
京东云数据库主要包括公有云数据库服务和私有云数据库服务两部分。公有云数据库主要是面向外部用户，定位是中小型公司；私有云数据库主要针对公司内部业务，有时候甚至会特殊业务特殊对待，会针对业务的特点来具体问题具体分析，数据量较大的业务京东会建议业务使用京东私有云分布式数据库集群，将数据进行拆分等。这两项服务在京东都是由同一个团队来提供支持，京东云数据库的总体做法是将私有云数据库中积累的经验逐步的输出到公有云数据库上。
云数据库集群服务主要是指分布式数据库集群，用户在使用这个集群的时候可以像使用单台数据库一样去使用，在业务层面不用关心集群中的数据是如何分布的，对用户来说后端的数据库实例是不可见的或者不需要关心的，在使用层面来说心智负担会大大降低。
N个数据库同时提供服务一般是指N个数据库服务多个不同的业务，或者是某个业务同时使用了N个数据库，但是业务对这些数据库是有感知的，换句话说这N个数据库对业务都是可见的。
云数据库服务其实也可以理解为将传统的数据库服务搬到云上，但是云数据库服务尤其是公有云数据库和传统的数据库确实是有区别的，最大的挑战在于不仅仅要提供数据库服务，还需要与用户的私有网络及云主机甚至包括云存储等各项云服务相互配合提供高可用的服务、保证数据的高可靠，是一整套云服务中的一项。传统的数据库技术更多关注的是数据库本身的，网络及主机等问题一般会比较简单。
京东公有云数据库的架构都是基于私有云数据库的实践经验所得，在实际输出的时候考虑到安全及弹性伸缩等的考虑，公有云上采用基于虚机部署的方式，结合云主机云存储以及云数据库系统自身相配套的信息采集系统再整合公司的监控系统等各项服务，对外提供可伸缩高可用及高可靠的公有云数据库服务。
私有云中的分布式数据库集群架构主要是采用引入中间件的方式来支撑业务，中间件本身完全兼容mysql协议，在内部业务使用的时候可以像使用原生数据库一样简单。
公司内部有一套完整的统一的监控系统，云数据库自身还有一套信息采集系统，采集系统会采集数据库实例上的相关信息包括慢查询以及机器负载等信息，这些采集的信息经分析处理以后如果如果发现有异常比如有慢查询或者机器负载较高，会通过统一的监控系统触发报警，做到及时发现问题及时处理问题。
在私有云分布式数据库集群中的性能监控主要是两部分构成，一部分是分布式数据库中间件会对查询做一些统计信息，这些统计信息中有超过某些阈值的情况就会触发报警，另外一部分是数据库本身的完善的监控系统。
京东公有云数据库目前是部署在虚拟机里的，基于虚拟机的快速创建京东可以做到公有云数据库实例的较快的创建。私有云数据库目前有很大一部分已经将数据库实例放到容器里，在创建部署方面将更加的便捷，当内部验证以后后续京东也会考虑输出到公有云上。
京东的业务发展非常的迅猛，所以在很大程度上来说京东的技术都在被业务驱动着往前跑，很多业务早期数据可能是放在Oracle或者Sqlserver中的，等到业务量比较庞大的时候再着手将数据从原来的数据库迁移到mysql里的时候就会比较痛苦，一般都需要业务方和数据库团队紧密配合才能真正的完整的迁移出来，但是也正是因为有这些实际的业务需求驱使着京东的技术不断的提升。
