凯叔解密京东千亿商品系统核心架构

商品，黄金交易流程最基础、最核心的环节，无商品不电商。商品数据无处不在，商家(采销、供应商)发布管理、供应商下采购单、仓储配送、促销、搜索、商详页展现、购物支付、财务结算、售后服务等，都离不开商品。商品信息要准确传导于京东整个供应链的各节点，必须要有一套稳健、可靠的商品服务体系支撑。

原本并没有统一的商品服务及存储。DBA搭建了一套包含若干层级的SqlServer数据库复制结构，各系统从各级从库读取数据。复制延迟严重的时候，超过12小时，从库还没有更新，严重影响用户体验。写入口不止一个，获取到写账号就可以写入。erp商品管理系统、POP商品系统、BIP甚至也开发了一个商品管理系统，都在写同一个库的同一套表，数据一致性无法得到保障。在那个阶段京东的订单量、用户量相对较少，基于数据库的架构一定程度上也能支撑日常流量，但是无法应对大型促销活动。

在此背景下，2012年3月商品组从网站组独立出来，孙歌临危受命组建团队，启动商品技术架构升级项目。京东618年中狂欢购物节，系统(特别是0点)会承受平时无法比拟的压力。2012年之前的大促都会出现系统问题系统经常出现问题，甚至图书抢购活动时直接系统宕机。基于数据库提供读服务的架构，显然已经无法支撑业务前行，升级改造势在必行。12年初NoSQL还是新鲜事物，交易架构师龚杰开始实践Redis，他在一封邮件中介绍自主封装的客户端以及API。商品团队开始基于redis内存数据库搭建商品读服务，并对开源Jedis做了深度封装，扩展了ShardedJedisPool，实现了更加细粒度的多分片连接池管理，并且将一个请求中命中到同一个分片的redis命令由串行改成pipeline并行执行，性能提升较大。

架构1.0 读服务化

由Redis存储全量商品数据，作为内存数据库使用。商品信息变动时增量更新，一主多备模式容灾，同时全量刷新程序作为最后保障，一旦Redis中数据全部丢失，可以将商品库中数据恢复到Redis。

交易系统直面用户，为保证用户选品、下单结算的顺畅，提升用户体验。交易系统对高性能、高可用的商品读服务需求最迫切。此时架构升级采取了一种“轻模式”，所谓轻是指尽量减少外部系统的改造，这样更利于工作的快速推进。首先在通知模式上，各种商品系统写入Sqlserver主库后，通过HttpHTTP服务通知Rcat -server(采取尽量做的策略，能通知就通知到，有异常也不去重试，这种策略对相关系统的改造最小)。Rcat-server的职责就是接收通知，之后查询主库中的商品信息，将其更新到Redis中。因为写入系统是尽量做，不保证成功的模式，因此需要补偿机制去弥补遗漏。异步Worker会定期扫描数据库，把当日更新的，从刷新到Redis中。整体架构如图1-1所示：

图1-1 商品架构V1.0

V1.0版架构非常不完美，只是读服务这个点进行了改造，但是却在当年618中完美的完成了任务。618当天像往年一样，研发工程师售后守候在运维同学周围，时刻准备着!整个过程波澜不惊，只有过个别应用过载重启，整体非常顺利扛过了大流量的考验。有了这个经验，研发工程师们开始将Rcat(应用名称，商品读服务)推广，依赖Sqlserver从库的系统都逐步切换到读服务上。

架构2.0 全面服务化

POP商品系统和自营商品系统都是写入Oracle，在通过异步worker将数据写会Sqlserver。京东商品的独特之处在于最初是自采自销的自营类商品，有自己的商品模型和对应的erp管理系统。后续有了POP开放平台，该平台的商品模型和系统是独立搭建的，适应于第三方商家的商品发布管理。而所有下游的系统(单品、搜索、订单生产、仓库等)都是基于最初Sqlserver自营skuSKU模型做的系统设计。所以POP商品有自己的Oracle存储，也必须京东经过一步异步程序转化，写到Sqlserver商品库中。而自营商品系统在2011年架构升级时，计划由.Net+Sqlserver的技术体系升级外Java+Oracle技术体系。

孙歌作为研发负责人，基于技术前瞻性和成本考虑，果断决策放弃既昂贵又没有DBA团队良好支持的Oracle数据库。转而直接基于SqlServer实现商品的全面服务化，相比其他系统的去O足足早了一年。当时的整体思路是先实现服务化，再进行存储升级(Mysql集群)，最终完成彻底的技术架构升级。全面服务化过程：

(1) 全面读服务体系: