盘点电商大战背后技术力量支撑——京东篇
Battle one —— 换底计划
“6∙18”后即将网站页面、订单交易、仓储物流、数据库、Redis等悉数迁移到京东云，包括新数据中心交付、线上业务梳理、部署（应用程序、中间件、数据存储）、线下压力测试、线上小流量测试、切部分或全部流量稳定运行。其中业务系统迁移工作量最为繁重。
Battle two —— 多中心交易计划
新建定制化高密度机房，旨在提升业务效率的多中心交易系统一期工程交付使用，新机房60%的机器都部署了OpenStack弹性云，其余用作数据库存储和部分第三方合作业务。
Battle three—— 京东大脑计划
即早期的“千人千面”，随其在机器/深度学习方面的不断投入，基于用户画像对业务子系统产生促进作用，具体表现在从商品推荐到销售预测。
Docker实例应用数从“6∙18”之前1万到6万＋
全部业务中约8000个项目通过容器发布运行
随弹性资源池的部署，内部对一键扩展后的Docker实例预估为10万多个
90%业务从属Web层面，摆脱高密度容器性能瓶颈问题
使用约两万Docker实例运行其内存数据库JIMDB以及数千个MySQL实例
……
『移动端运营优化策略实施』
step 1：10月上旬发布双11特别版APP，该版本对双11营销需求进行了针对性升级和开发，对无线端红包流程及无线端众多双11特别活动（超级团、一分钱摇好礼、爆款提前抢等）进行了关键流程升级以及功能的开发。同步的无线端的CMS后台、消息通道、通天塔系统等运营支撑功能也在双11之前进行了优化及重要发布。
step 2: 无线产品、研发、运维测试、设计各环节对运营进行大力支撑与协作。产品端调配大量人力使APP端的各项活动体验得到了很好的保障；研发端根据移动端网络特点进行接入网络优化、持续精简内容、加载策略优化等，通过移动组件化建设、无线登录、push触达、开放化平台能力建设、无线监控测试平台、远程插件下发等数十项优化保障双11的进行。
step 3: 运营组织策划，8月开始即制定“活动营销线”、“核心频道线”、“采销联动线”三大重点运营主线齐头并进策略。从数据看，预热期通过发券及多种互动营销活动带动了APP DAU不断上升；采销联动为APP大促各主分会场、互动营销活动提供和采销的对接选品支持，除四大实物事业部之外，金融事业部、生活旅行事业部各项业务也和移动端进行了深入的整合营销。APP端的纯促销运营模块占APP的比例突破至23%，整个运营模块占APP的比例接近30%。
综上 集合产品、运营、研发、测试、运维、设计等整个无线团队的通力合作，在多个环节发力，为APP在双11期间积累优质客户。
『实时监控与安全保障策略实施』
为突发状况准备1500多个预案并且能做到60秒之内解决问题，将响应速度分为定位问题和解决问题两个部分。定位问题部分，取决于各个团队对于自己系统架构的熟悉程度，响应速度通过平日演练和线上实际故障提升；解决问题部分，各个团队线上系统都有成熟的路由降级切换开关。
以现有6万个容器监控为例，主要分为两个方面，即容器层面的CPU、内存和I/O等，业务层面的API性能指标等。各业务子系统可根据自身吞吐量和响应速度来设定阈值。
从资源层面探测容器是否可用，并触发弹性事件。对容器状态的探测主要是在物理机上连续发ping包，并在宿主机设冗余机制。众所周知，ping有丢包和延迟，所以会再从22端口加一个TCP握手，由于应用层做了无状态处理，所以即使存在一定的误判也不会有什么影响。
从状态层面探测业务是否可用，并触发弹性事件。其机制为业务监控和应用共享内存，通过业务性能数据的交换，流式读取业务性能的TP99、TP999等指标；此外还有业务URL探活措施。不论性能指标还是业务状态都能触发弹性事件。
以下为两个京东迎战此局电商之战
两个设计方案深度解读
主要功能是为涵盖亿级别商品的海量数据、支持短时超高并发查询、又有自己的业务特点：
海量的数据，亿级别的商品量；
高并发查询，日PV过亿；
请求需要快速响应。
这些共同点使商品搜索使用了与大搜索类似的技术架构，将系统分为：
离线信息处理系统；
索引系统；
搜索服务系；
反馈和排序系统。
商品搜索具有商业属性，与大搜索不同之处在于：
商品数据已经结构化，但散布在商品、库存、价格、促销、仓储等多个系统；
召回率要求高，保证每一个正常的商品均能够被搜索到；
为保证用户体验，商品信息变更（比如价格、库存的变化）实时性要求高，导致更新量大，每天的更新量为千万级别；
较强的个性化需求，由于是一个相对垂直的搜索领域，需要满足用户的个性化搜索意图，比如用户搜索“小说”有的用户希望找言情小说有的人需要找武侠小说有的人希望找到励志小说。
不同的人消费能力、性别、对配送时间的忍耐程度、对促销的偏好程度以及对属性比如“风格”、“材质”等偏好不同。以上这些需要有比较完善的用户画像系统提供支持。
『搜索服务集群』由很多个merger节点组成的集群。接收到查询query后，将请求通过qp触发有策略地下发到在线检索服务集群和其他服务集群，并对各个服务的返回结果进行合并排序，然后调用detail server包装结果，最终返回给用户。
『query processor server』 搜索query意图识别服务。
『在线检索服务集群』由很多个searcher节点组成，每个searcher列对应一个小分片索引（包含全量数据和实时增量数据）。
『detail server 』搜索结果展示服务。
『索引生产端』包含全量和增量数据生产，为在线检索服务集群提供全量索引和实时索引数据。
由于商品数据分布在不同的异构数据库当中有KV有关系型数据库，需要将这些数据抽取到京东搜索数据平台中，这分为全量抽取和实时抽取。
对于全量索引，由于商品数据散布于多个系统的库表中，为了便于索引处理，对多个系统的数据在商品维度进行合并，生成商品宽表。然后在数据平台上，使用MapReduce对商品数据进行清洗，之后进行离线业务逻辑处理，最终生成一份全量待索引数据。
对于实时索引，为了保证数据的实时性，实时调用各商品信息接口获取实时数据，将数据合并后采用与全量索引类似的方法处理数据，生成增量待索引数据。
此系统是搜索技术的核心，在进入这个系统之前，搜索信息仍然是以商品维度进行存储的。索引系统负责生成一种以关键字维度进行存储的信息，一般称之为倒排索引。
此系统对于全量和增量的处理是一致的，唯一的区别在于待处理数据量的差异。一般情况下，全量数据索引由于数据量庞大，采用hadoop进行；实时数据量小，采用单机进行索引生产。
搜索服务系统是搜索真正接受用户请求并响应的系统。这个系统最初只有1列searcher组成在线检索服务。由于用户体验的需要，首先增加Query Processor服务，负责查询意图分析，提升搜索的准确性。随着访问量的增长，接着增加缓存模块，提升请求处理性能。接着随着数据量（商品量）的增长，将包装服务从检索服务中独立出去，成为detail server服务。数据量的进一步增长，对数据进行类似数据库分库分表的分片操作。这时候，在线检索服务由多个分片的searcher列组成。自然而然，需要一个merger服务，将多个分片的结果进行合并。至此，搜索基础服务系统完备。
之后，无论是搜索量的增长或者数据量的增长，都可以通过扩容来满足。对于618、1111之类的搜索量增长，可通过增加每个searcher列服务器的数量来满足。而对于商品数据的不断增加，只需要对数据做更多的分片，相应地增加searcher列来满足。
『搜索服务系统内部的处理流程如下』
在这个流程中，缓存模块和拉取结果模块非常稳定。而排序模块和在线业务逻辑处理模块经常需要改动。架构需要稳定，高效和通用。排序业务特点是实验模型多，开发迭代速度快，讲求效果。为了解决这一冲突，需要将排序业务与架构分离，以动态链接库的方式集成到搜索整体架构中，具体包括文本策略和其他策略两个维度的相关性，文本策略相关性集成在searcher当中；其他策略相关性（包括反馈，个性化和业务调权等等）集成在merger当中。实现架构与排序业务各司其职，互不影响干扰。
『排序与架构分离』
反馈系统主要包含用户行为数据的实时收集、加工，并将数据存储到数据集市当中，并对这些数据进行特征提取，排序最主要考核的线上指标是UV价值和转化率，所以还会利用这些数据根据优化目标构建起标注数据。然后基于机器学习的排序系统会针对特征构建出模型。京东排序模型是每天更新的训练之前大概半年的数据。京东搜索在基于模型的排序基础之上，上层还会有一层规则引擎，比如保障店铺和品牌的多样性，以及京东战略扶持的品牌等都通过业务引擎来实现。一般基于机器学习的排序模型需要较长期的投入但是模型更加健壮不容易被作弊手段找到漏洞，并且可以让转化率和UV价值可持续的提升。 规则引擎主要是为了快速反应市场的变化，起到立竿见影的效果。二者一个像中药一个像西药，中西结合疗效好。
『故障秒级切换』
今年搜索集群做到了三机房部署，任何一个机房出现断网、断电等问题可以秒级将流量切换到其它机房。并且搜索的部分应用部署到了弹性云上，可以进行动态扩容。
『大促期间索引数据实时更新』
每年大促由于商品内容等信息更改频繁，涉及千万级的索引写操作，今年针对索引结构进行了调整彻底消灭掉了索引更新存在的一切锁机制，商品新增和修改操作变为链式更新。使大促期间商品的索引更新达到了妙极。
『大促期间的个性化搜索不降级』
往年大促期间由于流量在平时5倍以上，高峰流量会在平时的7倍，为了保障系统稳定，个性化搜索都进行了降级处理。今年针对搜索的缓存进行了针对性的优化，实现了三级缓存结构。从底向上分别是针对term的缓存，相关性计算缓存和翻页缓存。最上层的翻页缓存很多时候会被用户的个性化请求击穿，但是底层的相关性缓存和term缓存的结果可以起到作用，这样不至于使CPU负载过高。
『个性化搜索』
个性化之前的搜索对于同一个查询，不同用户看到的结果是完全相同的。这可能并不符合所有用户的需求。在商品搜索中，这个问题尤为特出。因为商品搜索的用户可能特别青睐某些品牌、价格、店铺的商品，为了减少用户的筛选成本，需要对搜索结果按照用户进行个性化展示。
个性化的第一步是对用户和商品分别建模，第二步是将模型服务化。有了这两步之后，在用户进行查询时，merger同时调用用户模型服务和在线检索服务，用户模型服务返回用户维度特征，在线检索服务返回商品信息，排序模块运用这两部分数据对结果进行重排序，最后给用户返回个性化结果。
『整合搜索』
用户在使用搜索时，其目的不仅仅是查找商品，还可能查询服务、活动等信息。为了满足这一类需求，首先在Query Processor中增加对应意图的识别。第二步是将服务、活动等一系列垂直搜索整合并服务化。一旦QP识别出这类查询意图，就条用整合服务，将对应的结果返回给用户。
『情感搜索』
情感搜索在于尽可能满足更多的搜索意图，这需要在后台构建一个强大的知识库体系。比如从海里评论中挖掘有意义的标签“成像效果好的相机”、“聚拢效果好的胸罩”、“适合送丈母娘”等，将这些信息一同构建到索引中去比如搜索“适合送基友的礼物”结合搜索意图分析相关的结果可以搜索出来。另外也可以从外部网站抓取有价值信息辅助构建知识库体系。
『图像检索』
很多时候用户并不知道如何描述一个商品。通过搜索意图分析、情感分析可以尽可能挖掘搜索意图，很多时候用户根本无法描述，比如在超市看到一个进口食品或者一件时尚的衣服，可以通过拍照检索迅速在网上找到并比较价格，另外看到同事穿着一件比较喜欢的衣服也可以通过拍照检索来找到。目前京东正在开始展开这方面的开发。离线方面主要通过CNN算法，对图片进行主题提取、提取相似特征、相同特征提取。引擎端主要是和搜索引擎类似的技术。图像搜索未来将可以开辟一个新的电商购物入口。京东目前正在研发新的图像检索引擎。
这是JMySQL智能管理平台的重要功能之一，对于当前MySQL数据库运行性能情况、压力情况、瓶颈、潜在的风险进行分析、汇总，风险点一目了然，让DBA知道立刻需要处理什么样的问题，这个在平时数据库管理中已发挥了重要作用，在大促前更是如此。
本次双11数据库是按照前端流量可能增加20倍进行备战的，对于“抵挡”前端流量的数据库来讲风险非常大，算法上我们为这类数据库确定了压力倍数A，负责后端处理的数据库压力倍数通常小于A，因为有中间一系列环节处理，它的压力倍数被确定为B，有些系统压力会增加的非常大，DBA从研发处得到可能增加的压力倍数，则这个系统的特定压力倍数为C，在当前性能指标的基础上，可计算出性能是否满足，需要增加多少，哪种方式增加。
对于不同类型应用对数据库的压力也不同，如IO型、CPU计算型、网络IO型、混合型等，会对数据库及服务器产生不同程度的影响。一定要避免木桶效应，并考虑峰值，举个简单例子：假设一个数据库别的指标都忽略，IO使用率均值是20%，但峰值达到30%，那这个数据库就不是能再抗4倍压力的，因为有峰值，如果确定压力真的会再增加4倍，那就要采取解决措施了。如果因为特定原因，不能进行数据库改造，则一定要制定预案，一旦压力上来，抗不住了，确保数据库不被打死。
特别强调下对于核心数据库不只是单纯的先进行指标评估分析，然后扩容改造就行了的，还要尽量进行压测，通过压测进行把关，既：要尊重指标分析，但还要注重实际情况。
现在系统设计时大都会在应用和数据库层之间加Cache层，对于“抵挡”流量的数据库一定要考虑到Cache层被打穿或者关键时刻Cache层异常的情况，DBA这里会按照一个比例预留。基于资源考虑不可能为所有风险点无限制的改造，会按个比例进行，一旦异常情况超出压力范围，马上采用预案，比如该限流的限流、该降级的降级，首先保证主要的核心服务正常，不被打死。这里并不是说只对核心服务这样处理，时间允许、资源允许的话所有重要服务、服务都需要这样做。
性能智能分析及故障自动处理技术都依赖着MySQL监控系统，这个系统会对所有MySQL数据库进行监控。另外，SQL是影响数据库性能的重要因素，系统会对慢查询SQL进行分析，分析后的慢查询自动发给相关研发和DBA进行优化。SQL优化是大促的必要准备工作，当然这个工作是平时需要持续做的。
在平时，流量上来后数据库的性能出现瓶颈时，要具体问题具体分析，不能盲目的进行扩容、拆分、硬件升级等，先要根据具体的SQL效率、性能，结合数据库本身情况分析判定，也许调整一下索引，SQL语句做一下调整即可解决并发量上来后的性能问题。数据库的扩容、拆分、硬件升级，是需要综合考虑各项性能指标、业务量变化情况来判定，否则造成人力、物力等资源浪费。研发在开发的过程中，涉及到数据库的，特别是重要系统，都会有DBA的参与，通过技术手段在上线前就确保性能情况。功夫要下在平时，不能光靠大促前的准备。
在双11阶段，因为流量突增，会有不少数据库需要提前改造。如主从库全部更换高IO硬件、增加读库、数据库水平拆分、数据库垂直拆分等情况，部分服务双11后还需要缩回到之前规模。这么多年来MySQL数据库扩容、部署系统已经比较成熟，功能也健全了，结合数据库切换系统，改造工作已没技术难度，只是量比较大，不能因为改造影响服务，往往需要在几周内就要改造完成，改造的系统众多，除了增加读库的场景外，其他的改造都会在流量低的时间段进行，DBA和研发紧密配合，自动化技术手段+改造方案。
为了防止机房毁灭性情况出现，增加了专门的机房可提供灾备切换，为几千台的数据库系统完成了跨机房同步库的部署、同步。
在大规模部署中，数据库在多个机房都会有从库，再加上多中心双活交易，会有双活的写库，场景会相对复杂。数据库宕机或网络异常后的切换是DBA一项重要工作，在MHA基础上DBA开发了自动切换程序JDSWITCH，在可接受自动切换的数据库上部署，其他的数据库因为业务原因会使用切换平台进行切换。切换平台也是JMySQL的一个重要功能，支持按单台切换、按数据库集群切换、按子系统集群切换、整个机房进行切换。在可连通情况下，切换时会自动挂同步关系，所有数据不需要重做，如连不通则切换后有程序检验数据情况，能补齐的补齐，如无法补齐用自动部署系统重做。一旦大促时机房异常，所有MySQL集群可在几分钟完成跨机房切换，防止挖土机关键时刻的绝杀。
通过对故障的统计、分析，数据库预案越来越多精细，会发生的故障都有相关的处理方案，有相关脚本、程序、平台执行，并会多次演练，经受实践的检验。
压测、军演是大促必不可少的组成部分，会进行多次军演，发现潜在性能隐患进行处理。在稳妥、准备充足的前提下，不要怕军演，现在不去真枪实弹，到了生死瞬间就只能祈祷了。好比模拟了老机房宕机，把核心数据库切到新机房运行跑着，再把这些数据库集群无缝切回去，这次军演完成后信心更加十足了。
查看电商大战专题盘点其他文章👇
ArchSummit全球架构师峰会北京站将于2015年12月18日~19日在北京国际会议中心召开，大会设置了《揭秘双十一背后的技术较量》专题来深入解读双十一背后的技术故事，欢迎关注，点击 阅读原文 进入官网了解。