亿级商品详情页架构演进技术解密 | 高可用架构系列

亿级商品详情页架构演进技术解密 | 高可用架构系列

 

 

--http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=1&srcid=UfXZNNOVZZyZjQmp0VOh&from=groupmessage&isappinstalled=0#rd

 

此文是开涛在【三体高可用架构群】之分享内容，“三体”是为了记念三体一书对技术人的伟大影响而冠名。

 

张开涛：2014年加入京东，主要负责商品详情页、详情页统一服务架构与开发工做，设计并开发了多个亿级访问量系统。工做之余喜欢写技术博客，有《跟我学Spring》、《跟我学Spring MVC》、《跟我学Shiro》、《跟我学Nginx+Lua开发》等系列教程，博客 http://jinnianshilongnian.iteye.com/  的访问量超过500W。

 

京东618的硝烟虽已散去，可开发和备战618期间总结过的一些设计原则和遇到的一些坑还历历在目。伴随着网站业务发展，需求日趋复杂多样并随时变化；传统静态化方案会遇到业务瓶颈，不能知足瞬变的需求。所以，须要一种能高性能实时渲染的动态化模板技术来解决这些问题。

 

今夜（编者：指8/27），咱们将进行服装品类的垂直详情页的AB测试和切新库存服务的1/n流量。就此机会，和你们分享一下最近一年作的京东商品详情页的架构升级的心路历程。

 

商品详情页是什么

商品详情页是展现商品详细信息的一个页面，承载在网站的大部分流量和订单的入口。京东商城目前有通用版、全球购、闪购、易车、惠买车、服装、拼购、今日抄底等许多套详情页模板，经过一些特殊属性、商家类型和打标来区分，每套模板数据是同样的，核心逻辑基本同样，可是一些前端逻辑是有差异的。

 

目前商品详情页个性化需求很是多，数据来源也是很是多的（目前统计后端有差很少数十个依赖服务），并且许多基础服务作不了的不想作的或者说须要紧急处理的都放咱们这处理，好比一些屏蔽商品需求等。所以咱们须要一种架构能快速响应和优雅的解决这些需求问题，来了问题能在5~10分钟内搞定。咱们这边经还常收到一些紧急需求，好比工商的一些投诉等须要及时响应。以前架构是静态化的，确定没法知足这种日趋复杂和未知的需求。静态化时作屏蔽都是经过js，因此咱们从新设计了商品详情页的架构。

 

它主要包括如下三部分：

商品详情页系统
负责静的部分（整个页面）

 

商品详情页动态服务系统和商品详情页统一服务系统
统一服务系统 负责动的部分，好比实时库存。目前已经上线了几个核心服务，今晚计划切新库存服务的1/n流量。
动态服务系统 负责给内网其余系统提供一些数据服务（好比大客户系统须要商品数据），目前商品详情页系统已经稳定运行半年了，目前主要给列表页提供一些数据。

 

键值结构的异构数据集群

商品主数据由于是存储在DB中，对于一些聚合数据须要联合查询很是多，会致使查询性能差的问题，所以对于键值类型的查询，咱们这套异构数据很是有用。咱们此次架构的调整的主要目的是知足日趋复杂的业务需求，能及时开发业务方的需求。咱们的系统主要处理键值数据的逻辑，关系查询咱们有另外一套异构系统。

 

下图是咱们的模板页，核心数据都是同样的，只是展现方式和一些前端逻辑不太同样。

 

咱们详情页的前端展现主要分为这么几个维度：

• 商品维度(标题、图片、属性等)

• 主商品维度（商品介绍、规格参数）

• 分类维度

• 商家维度

• 店铺维度

另外还有一些实时性要求比较高的如实时价格、实时促销、广告词、配送至、预售等是经过异步加载。

 

咱们目前把数据按维度化存储，好比一些维度直接redis存，性能好。

京东商城还有一些特殊维度数据：好比套装、手机合约机等，这些数据是主商品数据外挂的，经过异步加载来实现的逻辑。还有一些与第三方合做的，如易车，不少数据都是没法异构的，都是直接异步加载的。目前有易车、途牛等一些公司有这种合做。

 

咱们618当天PV数亿，服务器端TOP99响应时间低于38ms（此处是第1000次中第99次排名的时间，PV具体数据不便公开，但TOP99基本在40ms以内）。

上图是咱们的一个监控图。咱们详情页流量特色是离散数据，热点少，各类爬虫、比价软件抓取；因此若是直接查库，防刷没作好，很容易被刷挂。

 

商品详情页发展史

这是咱们的一个架构历史。

 

架构1.0

IIS+C#+Sql Server，最原始的架构，直接调用商品库获取相应的数据，扛不住时加了一层memcached来缓存数据。

 

这种方式常常受到依赖的服务不稳定而致使的性能抖动。基本发展初期都是这个样子的，扛不住加层缓存。所以咱们设计了架构2.0。

 

架构2.0

该方案使用了静态化技术，按照商品维度生成静态化HTML，这就是一个静态化方案。

主要思路：

1. 经过MQ获得变动通知；

2. 经过Java Worker调用多个依赖系统生成详情页HTML；

3. 经过rsync同步到其余机器；

4. 经过Nginx直接输出静态页；

5. 接入层负责负载均衡。

    

主要缺点：

1. 假设只有分类、面包屑变动了，那么全部相关的商品都要重刷；

2. 随着商品数量的增长，rsync会成为瓶颈；

3. 没法迅速响应一些页面需求变动，大部分都是经过JavaScript动态改页面元素。

 

以前需求没那么多，所以页面变动不是很频繁，基本没什么问题。可是随着商品数量的增长这种架构的存储容量到达了瓶颈，并且按照商品维度生成整个页面会存在如分类维度变动就要所有刷一遍这个分类下全部信息的问题，所以咱们又改造了一版按照尾号路由到多台机器。这种生成整个页面的方案会存在好比只有分类信息变了，也须要把这个分类下的商品从新刷一遍。

 

架构2.1

主要思路：

1. 容量问题经过按照商品尾号作路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到11台；

2. 按维度生成HTML片断（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是一个大HTML；

3. 经过Nginx SSI合并片断输出；

4. 接入层负责负载均衡；

5. 多机房部署也没法经过rsync同步，而是使用部署多套相同的架构来实现。

 

这种方式经过尾号路由的方式分散到多台机器扩容，而后生成HTML片断，按需静态化；当时咱们作闪购的时候，须要加页头，都是经过js搞定的。但对于大的页面结构变动，须要全量生成。尤为像面包屑不同的话会很麻烦，须要生成多个版本。

 

主要缺点：

1. 碎片文件太多，致使如没法rsync；

2. 机械盘作SSI合并时，高并发时性能差，此时咱们尚未尝试使用SSD；

3. 模板若是要变动，数亿商品须要数天才能刷完；

4. 到达容量瓶颈时，咱们会删除一部分静态化商品，而后经过动态渲染输出，动态渲染系统在高峰时会致使依赖系统压力大，抗不住；

5. 仍是没法迅速响应一些业务需求。

 

当时我记得印象最深的就是碎片文件太多，咱们的inode不够了，常常要半夜去公司删文件。由于存在删除问题，每台服务器并非全量，因此咱们须要一个动态生成的服务，当静态化不存在的时候还原到动态服务；但这样双十一时压力很是大，咱们依赖的系统随时都给咱们降级。

 

架构3.0

咱们的痛点：

1. 以前架构的问题存在容量问题，很快就会出现没法全量静态化，仍是须要动态渲染；（对于全量静态化能够经过分布式文件系统解决该问题，这种方案没有尝试）

2. 最主要的问题是随着业务的发展，没法知足迅速变化、还有一些变态的需求。

 

其实最痛快的是业务来讲咱们要搞垂直，咱们要模块化，咱们要个性化；这些通通很差搞，所以咱们就考虑作一版全动态的。其实思路和静态化差很少， 数据静态化聚合、页面模板化。

 

咱们要考虑和要解决的问题：

1. 能迅速响瞬变的需求，各类变态需求；

2. 支持各类垂直化页面改版；

3. 页面模块化；

4. AB测试；

5. 高性能、水平扩容；

6. 多机房多活、异地多活。

这是咱们新的系统：三个子系统。

主要思路：

1. 数据变动仍是经过MQ通知；

2. 数据异构Worker获得通知，而后按照一些维度进行数据存储，存储到数据异构JIMDB集群（JIMDB：Redis+持久化引擎，是基于Redis改造的一个加了持久化引擎的KV存储），存储的数据都是未加工的原子化数据，如商品基本信息、商品扩展属性、商品其余一些相关信息、商品规格参数、分类、商家信息等；

3. 数据异构Worker存储成功后，会发送一个MQ给数据同步 Worker，数据同步Worker也能够叫作数据聚合Worker，按照相应的维度聚合数据存储到相应的JIMDB集群；三个维度：基本信息（基本信息+扩展属性等的一个聚合）、商品介绍（PC版、移动版）、其余信息（分类、商家等维度，数据量小，直接Redis存储）；

4. 前端展现分为两个：商品详情页和商品介绍，使用Nginx+Lua技术获取数据并渲染模板输出。

 

思路差很少： MQ获得变动通知，Worker刷元数据到JIMDB，前端展现系统取数据渲染模板。另外咱们当时架构的目标是详情页上有的数据，咱们均可以提供服务出去，主要提供单个商品的查询服务，因此咱们把这个系统叫作动态服务系统。

该动态服务分为前端和后端，即公网仍是内网，如目前该动态服务为列表页、商品对比、微信单品页、总代等提供相应的数据来知足和支持其业务。

 

目前天天为列表页提供增量数据服务。微信上京东入口看到的详情页 也是咱们这个服务提供的数据。APP的数据暂时没走咱们的系统，不过咱们目前系统实现的是日常流量的50倍左右，性能和流量基本不是问题。咱们详情页架构设计的一些原则：

1. 数据闭环

2. 数据维度化

3. 拆分系统

4. Worker无状态化+任务化

5. 异步化+并发化

6. 多级缓存化

7. 动态化

8. 弹性化

9. 降级开关

10. 多机房多活

11. 多种压测方案

 

由于咱们这边主要是读服务，所以咱们架构可能偏读为主的设计；目前我设计的几个系统都遵循这些原则去设计：

 

数据闭环：

数据闭环，即数据的自我管理，或者说是数据都在本身系统里维护，不依赖于任何其余系统，去依赖化，这样获得的好处就是别人抖动跟我不要紧。所以咱们要先数据异构。

 

数据异构，是数据闭环的第一步，将各个依赖系统的数据拿过来，按照本身的要求存储起来；咱们把不少数据划分为三个主要维度进行异构：商品信息、商品介绍和其余信息（分类、商家、店铺等）。

 

数据原子化处理，数据异构的数据是原子化数据，这样将来咱们能够对这些数据再加工再处理而响应变化的需求。咱们有了一份原子化异构数据虽然方便处理新需求，但偏偏由于第一份数据是原子化的，那么它会很分散，前端读取时mget的话 性能不是很好，所以咱们又作了数据聚合。

 

数据聚合，是将多个原子数据聚合为一个大JSON数据，这样前端展现只须要一次get，固然要考虑系统架构，好比咱们使用的Redis改造，Redis又是单线程系统，咱们须要部署更多的Redis来支持更高的并发，另外存储的值要尽量的小。

 

数据存储，咱们使用JIMDB，Redis加持久化存储引擎，能够存储超过内存N倍的数据量，咱们目前一些系统是Redis+LMDB引擎的存储，目前是配合SSD进行存储；另外咱们使用Hash Tag机制把相关的数据哈希到同一个分片，这样mget时不须要跨分片合并。分片逻辑使用的是Twemproxy，和应用端混合部署在一块儿；减小了一层中间层，也节约一部分机器。

 

咱们目前的异构数据是键值结构的，用于按照商品维度查询，还有一套异构时关系结构的用于关系查询使用。

 

数据维度化
对于数据应该按照维度和做用进行维度化，这样能够分离存储，进行更有效的存储和使用。咱们数据的维度比较简单：

1. 商品基本信息，标题、扩展属性、特殊属性、图片、颜色尺码、规格参数等；
   这些信息都是商品维度的。

2. 商品介绍信息，商品维度商家模板、商品介绍等；
   京东的商品比较特殊：自营和第三方。
   自营的商品能够任意组合，选择其中一个做为主商品，所以他的商品介绍是商品维度。
   第三方的组合是固定的，有一个固定的主商品，商品介绍是主商品维度。

3. 非商品维度其余信息，分类信息、商家信息、店铺信息、店铺头、品牌信息等；
   这些数据量不是很大，一个redis实例就能存储。

4. 商品维度其余信息（异步加载），价格、促销、配送至、广告词、推荐配件、最佳组合等。

 

这些数据不少部门在维护，只能异步加载；目前这些服务比较稳定，性能也不错，咱们在把这些服务在服务端聚合，而后一次性吐出去。如今已经这么作了几个，好比下面这个就是在服务端聚合吐出去的状况。

http://c.3.cn/recommend?callback=jQuery4132621&methods=accessories%2Csuit&p=103003&sku=1217499&cat=9987%2C653%2C655&lid=1&uuid=1156941855&pin=zhangkaitao1987&ck=pin%2CipLocation%2Catw%2Caview&lim=6&cuuid=1156941855&csid=122270672.4.1156941855%7C91.1440679162&c1=9987&c2=653&c3=655&_=1440679196326

这是咱们url的一些规则，methods指定聚合的服务。咱们还对系统按照其做用作了拆分。

 

拆分系统

将系统拆分为多个子系统虽然增长了复杂性，可是能够获得更多的好处。好比，数据异构系统存储的数据是原子化数据，这样能够按照一些维度对外提供服务；而数据同步系统存储的是聚合数据，能够为前端展现提供高性能的读取。而前端展现系统分离为商品详情页和商品介绍，能够减小相互影响；目前商品介绍系统还提供其余的一些服务，好比全站异步页脚服务。咱们后端仍是一个任务系统。

 

Worker无状态化+任务化

1. 数据异构和数据同步Worker无状态化设计，这样能够水平扩展；

2. 应用虽然是无状态化的，可是配置文件仍是有状态的，每一个机房一套配置，这样每一个机房只读取当前机房数据；

3. 任务多队列化，等待队列、排重队列、本地执行队列、失败队列；

4. 队列优先级化，分为：普通队列、刷数据队列、高优先级队列；
   例如，一些秒杀商品会走高优先级队列保证快速执行。

5. 副本队列，当上线后业务出现问题时，修正逻辑能够回放，从而修复数据；能够按照好比固定大小队列或者小时队列设计；

6. 在设计消息时，按照维度更新，好比商品信息变动和商品上下架分离，减小每次变动接口的调用量，经过聚合Worker去作聚合。

 

异步化+并发化

咱们系统大量使用异步化，经过异步化机制提高并发能力。首先咱们使用了消息异步化进行系统解耦合，经过消息通知我变动，而后我再调用相应接口获取相关数据；以前老系统使用同步推送机制，这种方式系统是紧耦合的，出问题须要联系各个负责人从新推送还要考虑失败重试机制。数据更新异步化，更新缓存时，同步调用服务，而后异步更新缓存。

可并行任务并发化，商品数据系统来源有多处，可是能够并发调用聚合，这样原本串行须要1s的通过这种方式咱们提高到300ms以内。异步请求合并，异步请求作合并，而后一次请求调用就能拿到全部数据。前端服务异步化/聚合，实时价格、实时库存异步化，使用如线程或协程机制将多个可并发的服务聚合。异步化还一个好处就是能够对异步请求作合并，原来N次调用能够合并为一次，还能够作请求的排重。

 

多级缓存化
因以前的消息粒度较粗，咱们目前在按照一些维度拆分消息，所以读服务确定须要大量缓存设计,因此咱们是一个多级缓存的系统。

 

浏览器缓存，当页面之间来回跳转时走local cache，或者打开页面时拿着Last-Modified去CDN验证是否过时，减小来回传输的数据量；

 

CDN缓存，用户去离本身最近的CDN节点拿数据，而不是都回源到北京机房获取数据，提高访问性能；

 

服务端应用本地缓存，咱们使用Nginx+Lua架构，使用HttpLuaModule模块的shared dict作本地缓存（ reload不丢失）或内存级Proxy Cache，从而减小带宽。

 

咱们的应用就是经过Nginx+Lua写的，每次重启共享缓存不丢，这点咱们受益颇多，重启没有抖动，另外咱们还使用使用一致性哈希（如商品编号/分类）作负载均衡内部对URL重写提高命中率；咱们对mget作了优化，如去商品其余维度数据，分类、面包屑、商家等差很少8个维度数据，若是每次mget获取性能差并且数据量很大，30KB以上；而这些数据缓存半小时也是没有问题的，所以咱们设计为先读local cache，而后把不命中的再回源到remote cache获取，这个优化减小了一半以上的remote cache流量；这个优化减小了这个数据获取的一半流量；

 

服务端分布式缓存，咱们使用内存+SSD+JIMDB持久化存储。

 

动态化
咱们整个页面是动态化渲染，输出的数据获取动态化，商品详情页：按维度获取数据，商品基本数据、其余数据（分类、商家信息等）；并且能够根据数据属性，按需作逻辑，好比虚拟商品须要本身定制的详情页，那么咱们就能够跳转走，好比全球购的须要走jd.hk域名，那么也是没有问题的；将来好比医药的也要走单独域名。

 

模板渲染实时化，支持随时变动模板需求；咱们目前模板变动很是频繁，需求很是多，一个页面8个开发。

 

重启应用秒级化， 使用Nginx+Lua架构，重启速度快，重启不丢共享字典缓存数据；其实咱们有一些是Tomcat应用，咱们也在考虑使用如Tomcat+Local Redis 或 Tomcat+Nginx Local Shared Dict 作一些本地缓存，防止重启堆缓存失效的问题。

 

需求上线速度化，由于咱们使用了Nginx+Lua架构，能够快速上线和重启应用，不会产生抖动；另外Lua自己是一种脚本语言，咱们也在尝试把代码如何版本化存储，直接内部驱动Lua代码更新上线而不须要重启Nginx。

 

弹性化
咱们全部应用业务都接入了Docker容器，存储仍是物理机；咱们会制做一些基础镜像，把须要的软件打成镜像，这样不用每次去运维那安装部署软件了；将来能够支持自动扩容，好比按照CPU或带宽自动扩容机器，目前京东一些业务支持一分钟自动扩容，下个月会进行弹性调度尝试。

 

降级开关
一个前端提供服务的系统必须考虑降级，推送服务器推送降级开关，开关集中化维护，而后经过推送机制推送到各个服务器；

 

可降级的多级读服务，前端数据集群—->数据异构集群—->动态服务(调用依赖系统)；这样能够保证服务质量，假设前端数据集群坏了一个磁盘，还能够回源到数据异构集群获取数据；基本不怕磁盘坏或一些机器故障、或者机架故障。

 

开关前置化，如Nginx代替Tomcat，在Nginx上作开关，请求就到不了后端，减小后端压力；咱们目前不少开关都是在Nginx上。

 

可降级的业务线程池隔离，从Servlet3开始支持异步模型，Tomcat7/Jetty8开始支持，相同的概念是Jetty6的Continuations。咱们能够把处理过程分解为一个个的事件。

 

经过这种将请求划分为事件方式咱们能够进行更多的控制。如，咱们能够为不一样的业务再创建不一样的线程池进行控制：即咱们只依赖tomcat线程池进行请求的解析，对于请求的处理咱们交给咱们本身的线程池去完成；这样tomcat线程池就不是咱们的瓶颈，形成如今没法优化的情况。经过使用这种异步化事件模型，咱们能够提升总体的吞吐量，不让慢速的A业务处理影响到其余业务处理。慢的仍是慢，可是不影响其余的业务。咱们经过这种机制还能够把tomcat线程池的监控拿出来，出问题时能够直接清空业务线程池，另外还能够自定义任务队列来支持一些特殊的业务。

 

去年使用的是JDK7+Tomcat7 最近一个月咱们升级到了JDK8+Tomcat8+G1。

 

多机房多活
对于咱们这种核心系统，咱们须要考虑多机房多活的问题。目前是应用无状态，经过在配置文件中配置各自机房的数据集群来完成数据读取。

其实咱们系统只要存储多机房就多活了，由于系统自然就是。数据集群采用一主三从结构，防止当一个机房挂了，另外一个机房压力大产生抖动。

各个机房都是读本机房的从另外每一个机房都是俩份数据，不怕由于机房忽然中断恢复后的影响。

 

多种压测方案
咱们在验证系统时须要进行压测。
线下压测，Apache ab，Apache Jmeter，这种方式是固定url压测，通常经过访问日志收集一些url进行压测，能够简单压测单机峰值吞吐量，可是不能做为最终的压测结果，由于这种压测会存在热点问题；

 

线上压测，可使用Tcpcopy直接把线上流量导入到压测服务器，这种方式能够压测出机器的性能，并且能够把流量放大，也可使用Nginx+Lua协程机制把流量分发到多台压测服务器，或者直接在页面埋点，让用户压测，此种压测方式能够不给用户返回内容。服务刚开始的时候大量使用tcpcopy作验证，对于一些 新服务，若是没法使用tcpcopy咱们就在页面埋url让用户来压。

 

另外压测时，要考虑读、写、读或写同时压。只压某一种场景可能都会不真实。

 

遇到的一些问题和解决方案

SSD性能差

使用SSD作KV存储时发现磁盘IO很是低。配置成RAID10的性能只有3_{6MB/s；配置成RAID0的性能有}130MB/s，系统中没有发现CPU，MEM，中断等瓶颈。一台服务器从RAID1改为RAID0后，性能只有~60MB/s。这说明咱们用的SSD盘性能不稳定。

 

据以上现象，初步怀疑如下几点：SSD盘，线上系统用的三星840Pro是消费级硬盘；RAID卡设置，Write back和Write through策略（后来测试验证，有影响，但不是关键）；RAID卡类型，线上系统用的是LSI 2008，比较陈旧。

 

下面是使用dd作的简单测试。

咱们现实居然使用的是民用级盘， 一个月坏几块很正常。后来咱们所有申请换成了INTEL企业级盘，线上用3500型号。

 

键值存储选型压测

在系统设计初期最头痛的就是存储选型，咱们对于存储选型时尝试过LevelDB、RocksDB、BeansDB、LMDB、Riak等，最终根据咱们的需求选择了LMDB。

 

机器：2台
配置：32核CPU、32GB内存、SSD（(512GB)三星840Pro—> (600GB)Intel 3500 /Intel S3610）
数据：1.7亿数据（800多G数据）、大小5~30KB左右
KV存储引擎：LevelDB、RocksDB、LMDB，每台启动2个实例
压测工具：tcpcopy直接线上导流
压测用例：随机写+随机读

 

LevelDB压测时，随机读+随机写会产生抖动（咱们的数据出自本身的监控平台，分钟级采样）。

咱们线上一些顺序写的服务在使用leveldb，RocksDB是改造自LevelDB，对SSD作了优化，咱们压测时单独写或读，性能很是好，可是读写混合时就会由于归并产生抖动。

在归并时基本达到了咱们磁盘的瓶颈，LMDB引擎没有大的抖动，基本知足咱们的需求。

咱们目前一些线上服务器使用的是LMDB，新机房正在尝试公司自主研发的CycleDB引擎。目前我看到的应该不多使用LMDB引擎的。

 

数据量大时Jimdb同步不动

Jimdb数据同步时要dump数据，SSD盘容量用了50%以上，dump到同一块磁盘容量不足。
解决方案：

1. 一台物理机挂2块SSD(512GB)，单挂raid0；启动8个jimdb实例；这样每实例差很少125GB左右；目前是挂4块，raid0；新机房计划8块raid10；

2. 目前是千兆网卡同步，同步峰值在100MB/s左右；

3. dump和sync数据时是顺序读写，所以挂一块SAS盘专门来同步数据；

4. 使用文件锁保证一台物理机多个实例同时只有一个dump；

5. 后续计划改造为直接内存转发而不作dump。

 

切换主从

由于是基于Redis的，目前是先作数据RDB dump而后同步。后续计划改造为直接内存复制，以前存储架构是一主二从（主机房一主一从，备机房一从）切换到备机房时，只有一个主服务，读写压力大时有抖动，所以咱们改造为以前架构图中的一主三从。

 

分片配置

以前的架构是存储集群的分片逻辑分散到多个子系统的配置文件中，切换时须要操做不少系统。

解决方案：

1. 引入Twemproxy中间件，咱们使用本地部署的Twemproxy来维护分片逻辑；

2. 使用自动部署系统推送配置和重启应用，重启以前暂停mq消费保证数据一致性；

3. 用unix domain socket减小链接数和端口占用不释放启动不了服务的问题。

 

咱们都是在应用本地部署的Twemproxy，而后经过中间系统对外提供数据。

 

模板元数据存储HTML

咱们前端应用使用的是Nginx+Lua，起初不肯定Lua作逻辑和渲染模板性能如何，就尽可能减小for、if/else之类的逻辑；经过java worker组装html片断存储到jimdb，html片断会存储诸多问题，假设将来变了也是须要全量刷出的，所以存储的内容最好就是元数据。

 

所以经过线上不断压测，最终jimdb只存储元数据，lua作逻辑和渲染；逻辑代码在3000行以上；模板代码1500行以上，其中大量for、if/else，目前渲染性能够接受。

 

线上真实流量，总体性能从TOP99 53ms降到32ms。

绑定8 CPU测试的，渲染模板的性能能够接受。

 

 

库存接口访问量600W/分钟

商品详情页库存接口2014年被恶意刷，每分钟超过600w访问量，tomcat机器只能定时重启；由于是详情页展现的数据，缓存几秒钟是能够接受的，所以开启nginx proxy cache来解决该问题，开启后降到正常水平；咱们目前正在使用Nginx+Lua架构改造服务，数据过滤、URL重写等在Nginx层完成，经过URL重写+一致性哈希负载均衡，不怕随机URL，一些服务提高了10%+的缓存命中率。

 

目前咱们大量使用内存级nginx proxy cache和nginx共享字典作数据缓存。
http://c.3.cn/recommend?callback=jQuery4132621&methods=accessories%2Csuit&p=103003&sku=1217499&cat=9987%2C653%2C655&lid=1&uuid=1156941855&pin=zhangkaitao1987&ck=pin%2CipLocation%2Catw%2Caview&lim=6&cuuid=1156941855&csid=122270672.4.1156941855%7C91.1440679162&c1=9987&c2=653&c3=655&_=1440679196326

还有咱们会对这些前端的url进行重写，因此无论怎么加随机数，都不会影响咱们服务端的命中率，咱们服务端作了参数的从新拼装和验证。

 

微信接口调用量暴增

14年的一段时间微信接口调用量暴增，经过访问日志发现某IP频繁抓取；并且按照商品编号遍历，可是会有一些不存在的编号。

解决方案：

1. 读取KV存储的部分不限流；

2. 回源到服务接口的进行请求限流，保证服务质量。

3. 回源到DB的或者依赖系统的，咱们也只能经过限流保证服务质量。

 

开启Nginx Proxy Cache性能不升反降

开启Nginx Proxy Cache后，性能降低，并且过一段内存使用率到达98%。

解决方案：

1. 对于内存占用率高的问题是内核问题，内核使用LRU机制，自己不是问题，不过能够经过修改内核参数
   sysctl -w vm.extra_free_kbytes=6436787
   sysctl -w vm.vfs_cache_pressure=10000

2. 使用Proxy Cache在机械盘上性能差能够经过tmpfs缓存或nginx共享字典缓存元数据，或者使用SSD，咱们目前使用内存文件系统。

 

配送至读服务因依赖太多，响应时间偏慢

配送至服务天天有数十亿调用量，响应时间偏慢。
解决方案：

1. 串行获取变并发获取，这样一些服务能够并发调用，在咱们某个系统中能提高一倍多的性能，从原来TP99差很少1s降到500ms如下；

2. 预取依赖数据回传，这种机制还一个好处，好比咱们依赖三个下游服务，而这三个服务都须要商品数据，那么咱们能够在当前服务中取数据，而后回传给他们，这样能够减小下游系统的商品服务调用量，若是没有传，那么下游服务再本身查一下。

 

假设一个读服务是须要以下数据：

1. 数据A 10ms

2. 数据B 15ms

3. 数据C  20ms

4. 数据D  5ms

5. 数据E  10ms

 

那么若是串行获取那么须要：60ms；而若是数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C；那么咱们能够这样子来获取数据：

那么若是并发化获取那么须要：30ms；能提高一倍的性能。

 

假设数据E还依赖数据F(5ms)，而数据F是在数据E服务中获取的，此时就能够考虑在此服务中在取数据A/B/D时预取数据F，那么总体性能就变为了：25ms。

 

咱们目前大量使用并发获取和预取数据，经过这种优化咱们服务提高了差很少10ms性能。 并且能显著减小一些依赖服务的重复调用，给他们减流。

以下服务是在抖动时的性能，老服务TOP99 211ms，新服务118ms，此处咱们主要就是并发调用+超时时间限制，超时直接降级。

 

网络抖动时，返回502错误

Twemproxy配置的timeout时间太长，以前设置为5s，并且没有分别针对链接、读、写设置超时。后来咱们减小超时时间，内网设置在150ms之内，当超时时访问动态服务。对于读服务的话，应该设置合理的超时时间，好比超时了直接降级。

 

 

机器流量太大

2014年双11期间，服务器网卡流量到了400Mbps，CPU30%左右。缘由是咱们全部压缩都在接入层完成，所以接入层再也不传入相关请求头到应用，随着流量的增大，接入层压力过大，所以咱们把压缩下方到各个业务应用，添加了相应的请求头，Nginx GZIP压缩级别在2~4吞吐量最高；应用服务器流量降了差很少5倍；目前正常状况CPU在4%如下。

 

由于以前压缩都是接入层作的，后来由于接入的服务太多，所以咱们决定在各应用去作。

一些总结

• 数据闭环

• 数据维度化

• 拆分系统

• Worker无状态化+任务化

• 异步化+并发化

• 多级缓存化

• 动态化

• 弹性化

• 降级开关

• 多机房多活

• 多种压测方案

• Nginx接入层线上灰度引流

• 接入层转发时只保留有用请求头

• 使用不须要cookie的无状态域名（如c.3.cn），减小入口带宽

• Nginx Proxy Cache只缓存有效数据，如托底数据不缓存

• 使用非阻塞锁应对local cache失效时突发请求到后端应用(lua-resty-lock/proxy_cache_lock)

• 使用Twemproxy减小Redis链接数

• 使用unix domain socket套接字减小本机TCP链接数

• 设置合理的超时时间（链接、读、写）

• 使用长链接减小内部服务的链接数

• 去数据库依赖（协调部门迁移数据库是很痛苦的，目前内部使用机房域名而不是ip），服务化

• 客户端同域链接限制，进行域名分区：c0.3.cn c1.3.cn，若是将来支持HTTP/2.0的话，就再也不适用了。

   

Q&A

Q1：对于依赖服务的波动，致使咱们系统的不稳定，咱们是怎么设计的？
咱们的数据源有三套：前端数据集群 该数据每一个机房有两套，目前两个机房。数据异构集群同上动态服务(调用依赖系统)。

1. 设置好超时时间，尤为链接超时，内网咱们通常100ms左右；

2. 每一个机房读从、若是从挂了降级读主；

3. 若是前端集群挂了，咱们会读取动态服务（一、先mget原子数据异构集群；二、失败了读依赖系统）。

 

Q2：静态化屏蔽经过js是怎么作的？

1. 紧急上线js，作跳转；

2. 上线走流程须要差很少10分钟，而后还有清理CDN缓存，用户端还有本地缓存没法清理；

3. 咱们目前文件都放到咱们的自动部署上，出问题直接修改，而后同步上去，重启nginx搞定。

 

Q3：内网的服务经过什么方式提供？
我偏好使用HTTP，目前也在学习HTTP2.0，有一些服务使用咱们本身开发相似于DUBBO的服务化框架，以前的版本就是DUBBO改造的。

 

Q4：对于mq 的处理若是出现异常是怎么发现和处理的？

1. MQ，咱们目前是接收下来存Redis，而后会写一份到本地磁盘文件；

2. 咱们会把消息存一天的；

3. 通常出问题是投诉，咱们会紧急回滚消息到一天中的某个时间点。

 

Q5：对于模板这块，有作预编译处理？或者直接使用Lua写模板吗？

1. luajit，相似于java jit；

2. lua直接写模板。

 

Q6： jimdb可否介绍下，特性是什么，为何选用?

1. jimdb就是咱们起的一个名字，以前版本就是redis+lmdb持久化引擎，作了持久化；

2. 咱们根据当时的压测结果选择的，按照对比结果选择的，咱们当时也测了豆瓣的beansdb，性能很是好，就是须要按期人工归并。

 

Q7：咨询下对于价格这类敏感数据，前端有缓存么？仍是都靠价格服务扛？

1. 价格前端不缓存；

2. 价格实时同步到Nginx+Lua本地的redis集群（大内存）；

3. 不命中的才回源到tomcat查主redis/DB。

价格数据也是经过MQ获得变动存储到本地redis的，nginx+lua直接读本机redis，性能没的说。

 

Q8：库存和价格同样的模式处理吗？
前端展现库存不是，咱们作了几秒的服务端缓存。

 

Q9：github里有一个开源的基于lmdb的redis 大家用的这个吗?
咱们内部本身写的，有一版基于LevelDB的，我记得github上叫ardb。

 

Q10：看测试条件说测试的是大小5~30KB左右的数据，有没有测试过更大文件lmdb的表现？
这个没有，咱们的数据都是真实数据，最大的有50KB左右的，可是分布比较均匀；当时还考虑压缩，可是发现没什么性能问题，就没有压缩作存储了。

 

Q11：关于redis缓存，是每一个子系统拥有本身的一套缓存；仍是使用统一的缓存服务？是否有进行过对比测试？（看到又说使用单机缓存防止服务挂掉，影响总体服务）

1. 咱们公司有统一的缓存服务接入并提供运维；

2. 咱们的服务本身运维，由于咱们是多机房从，每机房读本身的从，目前不支持这种方式；

3. （看到又说使用单机缓存防止服务挂掉，影响总体服务）这个主要是降级+备份+回源解决。

 

Q12： “咱们目前一些线上服务器使用的是LMDB，其余一些正在尝试公司自主研发的CycleDB引擎”。 开始自主研发，这个是因为lmdb有坑仍是处于别的考虑？

1. 写放大问题；

2. 挂主从须要dump整个文件进行同步。

 

想和群内专家继续交流电商高可用架构，请关注公众号后，回复arch，申请进群。