Gausst松鼠会

这个屌丝很懒，什么也没留下！

热门标签

案例：典型电商应用与缓存。_库存推送缓存聚合

作者：Gausst松鼠会 | 2024-04-23 19:53:51

踩

库存推送缓存聚合

分布式系统的CAP理论首先把分布式系统中的三个特性进行了如下归纳：

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否是同样的值（等同于所有节点访问同一份最新的数据副本）。
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备可用性）。
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达到数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

电商领域是典型的要在CAP做出权衡的业务领域。从参与者来区分有用户、商户、平台运营人员；从基础领域模型来看有商品、订单、库存、库房、营销、物流、干系人等。

用户的诉求是什么？买到好东西（正品，价格最好还便宜），支付方便，安全快捷。
商户的诉求是什么？业务模式上解决快速回款；技术上解决对账清晰，数据准确。
平台的诉求是什么？越来越多的用户，越来越多的品类，越来越好的商家。

基于以上三方的诉求，那么电商平台会面临及时响应性的用户需求（我购买成功，还是失败）；数据准确性需求（我的钱有没有多扣）；平台海量请求的诉求（营销活动、秒杀、大促等）；高可用的诉求（每一秒都是钱，每一笔成交背后都是收入，如果平台不可用，对应可以直接换算成资金损失）。

电商类应用的挑战及特点

传统的金融行业比如银行可能半年才发布一次版本，现在已与时俱进到月度了，越少变更、越少发布，自然是越稳定。这个道理不难理解，我们可以把所有的应用系统当成一个“黑匣子”，如果外部因素没有变化，内部构成没有变化，那么黑匣子就不会有变化。也就是说对于若干年前的银行而言，如果机房、专线网络、运维没有变更，基本上不会出问题。但是对于不断试错以及营销驱动的电商业务而言，三天两头搞活动、上新产品是司空见惯的事情。规模小一点还好，骂你的人少，对于大电商而言则无异于是高速公路上换轮胎，或者叫做给飞行中的飞机换引擎，可见风险非同一般。
电商类应用具有如下特点：

稳定性决定服务能力：在前几个月，某电商网站搞“买200减100”活动，才进行了2小时就卡得不行。购物车的商品无法下单结算，查看商品详情也非常慢，属于一路塞车的节奏。该网站研发团队通过限流恢复了部分能力，但是对于蜂拥而至的用户而言，大部分用户的体验很差，因为他们买不到商品。
高并发性场景：大家都知道，扩展分为Scale Out和Scale Up两种模式。

Scale Out：横向扩展，增加处理节点提高整体处理能力，俗称加机器。

Scale Up：纵向扩展，通过提升单个节点的处理能力达到提升整体处理能力的目的。

在互联网架构中，采用廉价的服务器做Scale Out已经是非常通用的手段了，但是不是所有场景扛不住都可以加机器？比如秒杀场景，除了高流量以外，压力在于秒杀商品的高并发，那么热点商品拆分，上缓存、队列等技术自然就很重要了。

业务发展性能也得发展：举一个例子，有一个系统做支付链路的规则决策，起初可能就4万行代码；后来增加到8万，现在又增加到10万。代码行增加了，该应用的职责增加了，也可能调用逻辑的运算复杂度也增加了。那么如何保持对外API的TPS不降低，RT不降低？每次release不仅要完成功能用例的构建，亦要完成性能的测试。
产品快速试错：多年前，就有人想把软件从业者变成像制造工人一样，不断流水线工作。但是这几乎没什么可能，因为要解决的问题域太复杂。虽然业界有很多规范、标准、套装软件，但是仍然未解决问题之万一。我们来看一下是如何复杂的。

以我们的一个团队为例，7个人1年做了400多个需求。大家都知道满足需求，实现业务价值是软件的天职，无论是为了更好适应未来发展的平台化能力也好、新特性也好，这些只能在业务发展的过程中做。在做这么多需求的过程中，除了技术以外，对于业务包括规则要有深度把握，包括上下游的一些问题。如有评估不到位，问题就大了。若分析到设计阶段出现缺失，到代码、测试、发布这些阶段则必然会出现缺失。早些年，某些系统已经复杂到只有1~2个人能搞懂部分了，幸好这些系统今天都完成了拆分和治理。

应用数据静态化架构高性能单页Web应用

在电商网站中，单页Web是非常常见的一种形式，比如首页、频道页、广告页等都属于单页应用。这种页面是由模板+数据组成，传统的构建方式一般通过静态化实现。而这种方式的灵活性并不是很好，比如页面模板部分变更了需要重新全部生成。因此最好能有一种实现方式是可以实时动态渲染，以支持模板的多变性。另外也要考虑好如下几个问题：

动态化模板渲染支持。
数据和模板的多版本化：生产版本、灰度版本和预发布版本。
版本回滚问题，即当前发布的生产版本出问题时如何快速的回滚到上一个版本。
异常问题，假设渲染模板时遇到了异常情况（比如获取Redis出问题了），如何处理。
灰度发布问题，比如切20%量给灰度版本。
预发布问题，目的是在正式环境测试数据和模板的正确性。

整体架构

静态化单页Web应用方案如下图所示。

如上图所示，直接将生成的静态页推送到相关服务器即可。使用这种方式要考虑文件操作的原子性问题，即从老版本切换到新版本如何做到文件操作原子化。
而动态方案的整体架构如下图所示，分为三大系统：CMS系统、控制系统和前端展示系统。

下面就详细介绍这三大系统。

CMS系统

在CMS系统中可以配置页面的模板和数据。模板动态在CMS系统中维护，即模板不是一个静态文件，而是存储在CMS中的一条数据，最终发布到“发布数据存储Redis”中，前端展示系统从Redis中获取该模板进行渲染，从而前端展示系统更换了模板也不需要重启，纯动态维护模板数据。
原始数据存储到“元数据存储MySQL”中即可，比如频道页一般需要前端访问的URL、分类、轮播图、商品楼层等，这些数据按照相应的维度存储在CMS系统中。
CMS系统提供发布到“发布数据存储Redis”的控制。将CMS系统中的原始数据和模板数据组装成聚合数据（JSON存储）同步到“发布数据存储Redis”，以便前端展示系统获取进行展示。此外提供三个发布按钮：正式版本、灰度版本和预发布版本。
CMS系统目前存在如下几个问题：

用户如访问http://channel.jd.com/fashion.html怎么定位到对应的聚合数据呢？我们可以在CMS元数据中定义URL作为KEY，如果没有URL，则使用ID作为KEY，或者自动生成一个URL。
多版本如何存储呢？使用Redis的Hash结构存储即可，KEY为URL（比如http://channel.jd.com/fashion.html），自动按照维度存储：正式版本使用当前时间戳存储（这样前端系统可以根据时间戳排序然后获取最新的版本）、预发布版本使用“predeploy”作为字段，灰度版本使用“abVersion”作为字段即可，这样就区分开了多版本。
灰度版本如何控制呢？可以通过控制系统的开关来控制如何灰度。
如何访问预发布版本呢？比如在URL参数总带上predeploy=true，另外可以限定只有内网可以访问或者访问时带上访问密码，比如pwd=absdfedwqdqw。
模板变更的历史数据校验问题？比如模板变更了，但是使用历史数据渲染该模板会出现问题，即模板是要兼容历史数据的；此外的方案不存在这个问题，因为每次存储的是当时的模板快照，即数据快照和模板快照推送到“发布数据存储Redis”中。

前端展示系统

前端展示系统可获取当前URL，使用URL作为KEY首先从本机“发布数据存储Redis”获取数据。如果没有数据或者异常则从主“发布数据存储Redis”获取。如果主“发布数据存储Redis”也发生了异常，那么会直接调用CMS系统暴露的API直接从元数据存储MySQL中获取数据进行处理。
前端展示系统的伪代码（Java代码）如下：


--1、加载Lua模块库
local template = require("resty.template")
template.load = function(s) return s end
 
--2、动态获取模板
local myTemplate = "<html>{* title *}</html>"
--3、动态获取数据
local data = {title = "iphone6s"}
 
--4、渲染模板
local func = template.compile(myTemplate)
local content = func(data)
 
--5、通过ngx API输出内容
ngx.say(content)

由上述代码可知，模板和数据都是动态获取的，然后使用动态获取的模板和数据进行渲染。
由此假设最新版本的模板或数据有问题怎么办？这个可以从流程上避免：

首先进行预发布版本发布，测试人员验证没问题后进行下一步。
接着发布灰度版本，在灰度时自动去掉CDN功能（即不设置页面的缓存时间），发布验证。
最后发布正式版本，正式版本发布的前5分钟内是不设置页面缓存的，这样就可以防止发版时遇到问题，但是若问题版本已经在CDN上，问题会影响到全部用户，且无法快速回滚。不过这个流程比较麻烦，可以按照自己的场景进行简化。

控制系统

控制系统是用于版本降级和灰度发布的，当然也可以把这个功能放在CMS系统中实现。

版本降级：假设当前线上的版本遇到问题了，想要快速切换回上一个版本，可以使用控制系统实现，选中其中一个历史版本然后通知给前端展示系统，使用URL和当前版本的字段即可，这样前端展示系统就可以自动切换到选中的那个版本；当问题修复后，再删除该降级配置即切换回最新版本。
灰度发布：在控制系统控制哪些URL需要灰度发布和灰度发布的比例，与版本降级类似，将相关的数据推送到前端展示系统即可，当不想灰度发布时则删除相关数据。

数据和模板动态化

我们将数据和模板都进行动态化存储，这样可以在CMS进行数据和模板的变更；实现了前端和后端开发人员的分离；前端开发人员进行CMS数据配置和模板开发，而后端开发人员只进行系统的维护。另外，因为模板的动态化存储，每次发布新的模板不需要重启前端展示系统，后端开发人员更好的得到了解放。
模板和数据可以是一对多的关系，即一个模板可以被多个数据使用。假设模板发生变更后，我们可以批量推送模板关联的数据，首先进行预发布版本的发布，由测试人员进行验证，验证没问题即可发布正式版本。

多版本机制

我们将数据和模板分为多版本后，可以实现：

预发布版本：更容易让测试人员在实际环境进行验证。
灰度版本：只需要简单的开关控制，就可以进行A/B测试。
正式版本：存储多个历史正式版本，假设最新的正式版本出现问题，可以非常快速的切换回之前的版本。

应用多级缓存模式支撑海量读服务

本节不涉及缓存数据结构优化、缓存空间利用率跟业务数据相关的细节问题，主要从架构和提升命中率等层面来探讨缓存方案；本节也不讨论写服务，而是聚焦在读服务。这里将基于多级缓存模式来介绍应用缓存时需要注意的问题和一些解决方案，其中一些方案已经在业务中实施。

多级缓存介绍

所谓多级缓存，即在整个系统架构的不同系统层级进行数据缓存，以提升访问效率，这也是应用最广的方案之一。我们应用的整体架构如下图所示。

整体流程分析如下：

首先接入Nginx将请求负载均衡到应用Nginx，此处常用的负载均衡算法是轮询或者一致性哈希，轮询可以使服务器的请求更加均衡，而一致性哈希可以提升应用Nginx的缓存命中率，相对于轮询，一致性哈希会存在单机热点问题，一种解决办法是热点直接推送到接入层Nginx，另一种办法是设置一个阈值，当超过阈值，改为轮询算法。
接着应用Nginx读取本地缓存，如果本地缓存命中则直接返回。应用Nginx本地缓存可以提升整体的吞吐量，降低后端的压力，尤其应对热点问题非常有效。本地缓存可以使用Lua Shared Dict、Nginx Proxy Cache（磁盘/内存）、Local Redis实现。
如果Nginx本地缓存没命中，则会读取相应的分布式缓存（如Redis缓存，另外可以考虑使用主从架构来提升性能和吞吐量），如果分布式缓存命中则直接返回相应数据（并回写到Nginx本地缓存）。
如果分布式缓存也没有命中，则会回源到Tomcat集群，在回源到Tomcat集群时也可以使用轮询和一致性哈希作为负载均衡算法。
在Tomcat应用中，首先读取本地堆缓存，如果有则直接返回（并回写到主Redis集群）。
作为可选部分，如果步骤4没有命中可以再尝试一次读主Redis集群操作，目的是防止当从Redis集群有问题时的流量冲击。
如果所有缓存都没有命中，只能查询DB或相关服务获取相关数据并返回。
步骤7返回的数据异步写到主Redis集群，此处可能有多个Tomcat实例同时写主Redis集群，造成数据错乱。

应用整体分了三部分缓存：应用Nginx本地缓存、分布式缓存、Tomcat堆缓存，每一层缓存都用来解决相关的问题，如应用Nginx本地缓存用来解决热点缓存问题，分布式缓存用来减少访问回源率、Tomcat堆缓存用于防止相关缓存失效/崩溃之后的冲击。
虽然都是加缓存，但是怎么加、怎么用，细想下来还是有很多问题需要权衡和考量的，接下来我们就详细来讨论一些缓存相关的问题。

如何缓存数据

下面将从缓存过期、维度化缓存、增量缓存、大Value缓存、热点缓存几个方面来详细介绍如何缓存数据。

过期与不过期

对于缓存的数据我们可以考虑不过期缓存和带过期时间缓存，什么场景应该选择哪种模式则需要根据业务和数据量等因素来决定。

不过期缓存场景一般思路如下图所示。

使用Cache-Aside模式，首先写数据库，如果成功，则写缓存。这种场景下存在事务成功、缓存写失败但无法回滚事务的情况。另外，不要把写缓存放在事务中，尤其写分布式缓存，因为网络抖动可能导致写缓存响应时间很慢，引起数据库事务阻塞。如果对缓存数据一致性要求不是那么高，数据量也不是很大，则可以考虑定期全量同步缓存。

也有提到如下思路：先删缓存，然后执行数据库事务；不过这种操作对于如商品这种查询非常频繁的业务不适用，因为在你删除缓存的同时，已经有另一个系统来读缓存了，此时事务还没有提交。当然对于如用户维度的业务是可以考虑的。
不过为了更好的解决以上多个事务的问题，可以考虑使用订阅数据库日志的架构，如使用canal订阅MySQL的binlog实现缓存同步。

对于长尾访问的数据，大多数数据访问频率都很高的场景，若缓存空间足够则可以考虑不过期缓存，比如用户、分类、商品、价格、订单等，当缓存满了可以考虑LRU机制驱逐老的缓存数据。

过期缓存机制，即采用懒加载，一般用于缓存其他系统的数据（无法订阅变更消息，或者成本很高）、缓存空间有限、低频热点缓存等场景。常见步骤是：首先读取缓存，如果不命中则查询数据，然后异步写入缓存并过期缓存，设置过期时间，下次读取将命中缓存。热点数据经常使用，即在应用系统上缓存比较短的时间。这种缓存可能存在一段时间的数据不一致情况，需要根据场景来决定如何设置过期时间。如库存数据可以在前端应用上缓存几秒钟，短时间的不一致是可以忍受的。

维度化缓存与增量缓存

对于电商系统，一个商品可能拆成如基础属性、图片列表、上下架、规格参数、商品介绍等；如果商品变更了，要把这些数据都更新一边，那么整个更新成本（接口调用量和带宽）很高。因此最好将数据进行维度化并增量更新（只更新变更的部分）。尤其如上下架这种只是一个状态变更，但是每天频繁调用的，维度化后能减少服务很大的压力。维度化缓存方案如下图所示。

按照不同维度接收MQ进行更新。

大Value缓存

要警惕缓存中的大Value，尤其是使用Redis时。遇到这种情况时可以考虑使用多线程实现的缓存（如Memcached）来缓存大Value；或者对Value进行压缩；或者将Value拆分为多个小Value,客户端再进行查询、聚合。

热点缓存

对于那些访问非常频繁的热点缓存，如果每次都去远程缓存系统中获取，可能会因为访问量太大导致远程缓存系统请求过多、负载过高或者带宽过高等问题，最终可能导致缓存响应慢，使客户端请求超时。一种解决方案是通过挂更多的从缓存，客户端通过负载均衡机制读取从缓存系统数据。不过也可以在客户端所在的应用/代理层本地存储一份，从而避免访问远程缓存，即使像库存这种数据，在有些应用系统中也可以进行几秒钟的本地缓存，从而降低远程系统的压力。

分布式缓存与应用负载均衡

此处说的分布式缓存一般采用分片实现，即将数据分散到多个实例或多台服务器。算法一般采用取模和一致性哈希。如之前说的做不过期缓存机制可以考虑取模机制，扩容时一般是新建一个集群；而对于可以丢失的缓存数据可以考虑一致性哈希，即使其中一个实例出问题只是丢一小部分，对于分片实现可以考虑客户端实现，或者使用如Twemproxy中间件进行代理（分片对客户端是透明的）。如果使用Redis可以考虑使用redis-cluster分布式集群方案。
应用负载均衡一般采用轮询和一致性哈希，一致性哈希可以根据应用请求的URL或者URL参数将相同的请求转发到同一个节点；而轮询即将请求均匀的转发到每个服务器，如下图所示。

整体流程如下：

首先请求进入接入层Nginx。
根据负载均衡算法将请求转发给应用Nginx。
如果应用Nginx本地缓存命中，则直接返回数据，否则读取分布式缓存或者回源到Tomcat。

轮询的优点：应用Nginx的请求更加均匀，使得每个服务器的负载基本均衡，不会因为热点问题导致其中某一台服务器负载过重。
轮询的缺点：随着应用Nginx服务器的增加，缓存的命中率会下降，比如原来10台服务器命中率为90%，再加10台服务器将可能降低到45%。
一致性哈希的优点：相同请求都会转发到同一台服务器，命中率不会因为增加服务器而降低。
一致性哈希的缺点：因为相同的请求会转发到同一台服务器，因此可能造成某台服务器负载过重，甚至因为请求太多导致服务出现问题。
那么到底选择哪种算法呢？答案就是根据实际情况动态选择：

负载较低时使用一致性哈希，比如普通商品访问。
热点请求时降级一致性哈希为轮询，比如京东首页的商品访问。

当然，某些场景是将热点数据推送到接入层Nginx，直接响应给用户，比如秒杀商品的访问。

热点数据与更新缓存

热点数据会造成服务器压力过大，导致服务器性能、吞吐量、带宽达到极限，出现响应慢或者拒绝服务的情况，这肯定是不允许的。可以用如下几个方案去解决。

单机全量缓存+主从

如下图所示，所有缓存都存储在应用本机，回源之后会把数据更新到主Redis集群，然后通过主从复制到其他从Redis集群。缓存的更新可以采用懒加载或者订阅消息进行同步。

分布式缓存+应用本地热点

对于分布式缓存，我们需要在Nginx+Lua应用中进行应用缓存来减少Redis集群的访问冲击，即首先查询应用本地缓存，如果命中则直接缓存，如果没有命中则接着查询Redis集群、回源到Tomcat，然后将数据缓存到应用本地，如下图所示。

此处到应用Nginx的负载机制采用：正常情况采用一致性哈希，如果某个请求类型访问量突破了一定的阈值，则自动降级为轮询机制。另外对于一些秒杀活动之类的热点我们是可以提前知道的，可以把相关数据预先推送到接入层Nginx并将负载均衡机制降级为轮询。
另外可以考虑建立实时热点发现系统来发现热点，如下图所示。

接入Nginx将请求转发给应用Nginx。
应用Nginx首先读取本地缓存，如果命中直接返回，不命中读取分布式缓存、回源到Tomcat进行处理。
应用Nginx会将请求上报给实时热点发现系统（如使用UDP直接上报请求，或者将请求写到本地kafka，或者使用flume订阅本地Nginx日志），上报给实时热点发现系统后，他将进行热点统计（可以考虑storm实时计算）。
根据设置的阈值将热点数据推送到应用Nginx本地缓存。

因为做了本地缓存，因此对于数据一致性需要我们去考虑，即何时失效或更新缓存：

如果可以订阅数据变更消息，那么可以订阅变更消息进行缓存更新。
如果无法订阅消息或者订阅消息成本比较高，并且对短暂的数据一致性要求不严格（比如在商品详情页看到的库存，可以短暂的不一致，只要保证下单时一致即可），那么可以设置合理的过期时间，过期后再查询新的数据。
如果是秒杀之类的，可以订阅活动开启消息，将相关数据提前推送到前端应用，并将负载均衡机制降级为轮询。
建立实时热点发现系统来对热点进行统一推送和更新。

更新缓存与原子性

正如之前说的，如果多个应用同时操作一份数据很可能造成缓存数据是脏数据，解决办法有：

更新数据时使用更新时间戳或者版本对比，如果使用Redis可以利用其单线程机制进行原子化更新。
使用如canal订阅数据库binlog，如下图所示，此处把MySQl是发布的内容，binlog是发布的内容，canal看成消费者，canal订阅binlog然后更新到Redis。

将更新请求按照相应的规则分散到多个队列，然后每个队列进行单线程更新，更新时拉取最新的数据保存。
用分布式锁，更新之前获取相关的锁。

缓存崩溃与快速修复

当我们使用分布式缓存时，应该考虑如何应对其中一部分缓存实现宕机的情况。接下来介绍分布式缓存的常用算法。当缓存数据是可丢失的情况时，我们可以选择一致性哈希算法。

取模

对于取模机制如果其中一个实例故障，如果摘除此实例将导致大量缓存不明中，瞬间大流量可能导致后端DB/服务出现问题。对于这种情况可以采用主从机制来避免实例故障的问题，即其中一个实例故障可以用从/主顶上来。但是取模机制下如果增加了一个节点将导致大量缓存不命中，所以一般是建立另一个集群，然后把数据迁移到新集群，然后把流量迁移过去。

一致性哈希

对于一致性哈希机制如果其中一个实例故障，摘除此实例将只影响一致性哈希环上的部分缓存不命中，不会导致瞬间大量回源到后端DB/服务，但是也会产生一些影响。
另外也可能因为一些误操作导致整个缓存集群出现问题，如何快速恢复呢？

快速恢复

如果出现之前说到的一些问题，可以考虑如下方案：

主从机制，做好冗余，即其中一部分不可用，将对等的部分补上去。
如果因为缓存导致应用可用性已经下降可以考虑：部分用户降级，然后慢慢减少降级量；后台通过Worker预热缓存数据。

也就是如果整个缓存集群故障，而且没有备份，那么只能去慢慢将缓存重建。为了让部分用户还是可用的，可以根据系统承受能力，通过降级方案让一部分用户先用起来，将这些用户相关的缓存重建。另外通过后台Worker进行缓存数据的预热。

构建需求响应式亿级商品详情页

商品详情页是展示商品详细信息的一个页面，承载着网站的大部分流量和订单的入口。京东商城目前有通用版、全球购、闪购、易车、惠买车、服装、拼购、今日抄底等许多套模板。各套模板的元数据是一样的，只是展示方式不一样。目前商品详情页个性化需求非常多，数据来源也是非常多的，而且许多基础服务做不了的都放我们这，因此我们需要一种架构能快速响应和优雅的解决这些需求问题。因此我们重新设计了商品详情页的架构，主要包括三部分：商品详情页系统、商品详情页统一服务系统和商品详情页动态服务系统；商品详情页系统负责静态部分，而统一服务负责动态部分，而动态服务负责给内网其他系统提供一些数据服务。

商品详情页前端结构

前端展示可以分为这么几个维度：商品维度（标题、图片、属性等）、主商品维度（商品介绍、规格参数）、分类维度、商家维度、店铺维度等，另外还有一些实时促销、广告词、配送至、预售等是通过异步加载。

京东商城还有一些特殊维度数据，比如套装、手机合约机等，这些数据是主商品数据外挂的。

单品页技术架构发展

如下图所示，单品页技术架构发展经历了如下4个时期。下面会依然介绍这4个时期的技术方案。

架构1.0

ISS+C#+SQL Server，最原始的架构，直接调用商品库获取相应的数据，扛不住时加了一层Memcached来缓存数据，如下图所示。这种方式经常受到依赖的服务不稳定而导致的性能抖动。

架构2.0

如下图所示，该方案使用了静态化技术，按照商品维度生成静态化HTML。

主要思路：

通过MQ得到变更通知。
通过Java Worker调用多个依赖系统生成详情页HTML。
通过rsync同步到其他机器。
通过Nginx直接输出静态页。
接入层负责负载均衡。

该方案的主要缺点：

假设只有分类、面包屑变更了，那么所有相关的商品都要重刷。
随着商品数量的增加，rsyn会成为瓶颈。
无法迅速响应一些页面需求变更，大部分都是通过JavaScript动态改页面元素。

随着商品数量的增加，这种架构的存储容量达到了瓶颈，而且按照商品维度生成整个页面会存在如分类维度变更就要全部刷一遍这个分类下所有信息的问题，因此我们又改造了一版按照尾号路由到多台机器，如下图所示。

主要思路：

容量问题通过按照商品尾号做路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到11台。
按维度生成HTML片段（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是一个大HTML。
通过Nginx SSI合并片段输出。
接入层负责负载均衡。
多机房部署也无法通过rsync同步，而是使用部署多态相同的架构来实现。

该方案主要缺点：

碎片文件太多，导致如无法rsync。
机械盘做SSI合并时，高并发时性能差，此时我们还没有尝试使用SSD。
模板如果要变更，数亿商品需要数天才能刷完。
到达容量瓶颈时，我们会删除一部分静态化商品，然后通过动态渲染输出，动态渲染系统在高峰时会导致依赖系统压力大，扛不住。
还是无法迅速响应一些业务需求。

我们的痛点：

之前架构的问题存在容量问题，很快就会出现无法全量静态化问题，所以还是需要动态渲染；不过对于全量静态化可以通过分布式文件系统解决该问题，这种方案没有尝试。
最主要的问题是随着业务的发展，无法满足迅速变化的需求。

架构3.0

我们要解决的问题：
能迅速响应瞬变的需求和其他需求。
支持各种垂直化页面改版。
页面模板化。
AB测试。
高性能、水平扩容。
多机房多活、异地多活。

方案如下图所示。

主要思路是：

数据变更还是通过MQ通知。
数据异构Worker得到通知，然后按照一些维度进行数据存储，存储到数据异构JIMDB集群（JIMDB：Redis+持久化引擎），存储的数据都是未加工的原子化数据，如商品基本信息、商品扩展属性、商品其他一些相关信息、商品规模参数、分类、商家信息等。
数据异构Worker存储成功后，会发送一个MQ给数据同步Worker，数据同步Worker也可以叫做数据聚合Worker，按照相应的维度聚合数据存储到相应的JIMDB集群；三个维度：基本信息（基本信息+扩展属性等的一个聚合）、商品介绍（PC版、移动版）、其他信息（分类、商家等维度，数据量小，直接Redis存储）。
前端展示分为两个：商家详情页和商品介绍，使用Nginx+Lua技术获取数据并渲染模板输出。

另外我们目前架构的目标不仅仅是为商品详情页提供数据，只要是Key-Value结构获取而非关系结构的我们都可以提供服务，我们叫做动态服务系统，如下图所示。

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

详情页架构设计原则

总体来说，详情页架构设计要遵从如下原则：数据闭环、数据维度化、拆分系统、Worker无状态化+任务化、异步化+并发化、多级缓存化、动态化、弹性化、降级开关、多机房多活、多种压测方案。下面就详细介绍这几大原则。

数据闭环

数据闭环即数据的自我管理，或者说是数据都在自己系统里维护，不依赖于任何其他系统，去依赖化。这样得到的好处就是别人抖动跟我没关系，如下图所示。

数据异构是数据闭环的第一步，将各个依赖系统的数据拿过来，按照自己的要求存储起来。
数据原子化，数据异构的数据是原子化数据，这样未来我们可以对这些数据再加工再处理而响应变化的需求。
数据聚合，将多个原子数据聚合为一个大JSON数据，这样前端展示只需要一次get，当然要考虑系统架构，比如我们使用的Redis改造，Redis又是单线程系统，我们需要部署更多的Redis来支持更高的并发，另外存储的值要尽可能的小。
数据存储，我们使用JIMDB，Redis加持久化存储引擎，可以存储超过内存N倍的数据量，我们目前一些系统是Redis+LMDB引擎的存储，是配合SSD进行存储；另外我们使用Hash Tag机制把相关的数据哈希到同一个分片，这样mget时不需要跨分片合并。

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

数据维度化

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

商品基本信息：标题、扩展属性、特殊属性、图片、颜色尺码、规格参数等。
商品介绍信息：商品维度商家模板、商品介绍等。
非商品维度其他信息：分类信息、商家信息、店铺信息、店铺头、品牌信息等。
商品维度其他信息（异步加载）：价格、促销、配送至、广告词、推荐配件、最佳组合等。

拆分系统

将系统拆分为多个子系统虽然增加了复杂性，但是可以得到更多的好处，比如数据异构系统存储的数据是原子化数据，这样可以按照一些维度对外提供服务；而数据同步系统存储的是聚合数据，可以为前端展示提供高性能的读取。前端展示系统分离为商品详情页和商品介绍，可以减少相互影响；目前商品介绍系统还提供其他的一些服务，比如全站异步页脚本，如下图所示。

Worker无状态化+任务化

Worker无状态化+任务化，可以帮助系统做水平扩展，如下图所示。

数据异构和数据同步Worker无状态化设计，这样可以水平扩展。
应用虽然是无状态化的，但是配置文件还是有状态的，每个机房一套配置，这样每个机房只读取当前机房数据。
任务多队列化，等待队列、排重队列、本地执行队列、失败队列。
队列优先级化，分为：普通队列、刷数据队列、高优先级队列，例如一些秒杀商品会走高优先级队列保证快速执行。
副本队列，当上线后业务出现问题时，修正逻辑可以回收，从而修复数据；可以按照比如固定大小队列或者小时队列设计。
在设计消息时，按照维度更新，比如商品信息变更和商品上下架分离，减少每次变更接口的调用量，通过聚合Worker去做聚合。

异步化+并发化

我们系统大量使用异步化，通过异步化机制提升并发能力。首先我们使用了消息异步化进行系统解耦合，通过消息通知变更，然后再调用相应接口获取相关数据；之前老系统使用同步推送机制，这种方式系统是紧耦合的，出问题需要联系各个负责人重新推送还要考虑重试机制。数据更新异步化，更新缓存时同步调用服务，然后异步更新缓存。可并行任务并发化，商品数据系统来源有多处，但是可以并发调用聚合，经过这种方式我们可以把原先串行需要1s的时间提升到300ms之内。异步请求合并，异步请求做合并，一次请求调用就能拿到所有数据。前端服务异步化/聚合，实时价格、实时库存异步化，使用如线程或协程机制将多个可并发的服务聚合。异步化还有一个好处就是可以对异步请求做合并，原来N次调用可以合并为一次，还可以做请求的排重。

多级缓存化

浏览器缓存，当页面之间来回跳转时走local cache，或者打开页面时拿着LastModified去CDN验证是否过期，减少来回传输的数据量。
CDN缓存，用户去离自己最近的CDN节点拿数据，而不是全部会员到北京机房获取数据，提升访问性能。
服务端应用本地缓存，我们使用Nginx+Lua架构，使用HttpLuaModule模块的shared dict做本地缓存（reload不丢失）或内存级Proxy Cache，从而减少带宽。

另外我们还可以使用一致性哈希（如商品编号/分类）做负载均衡内部对URL重新提升命中率。

我们对mget做了优化，如取商品其他维度数据，分类、面包屑、商家等差不多8个维度数据，如果每次mget获取性能差而且数据量很大，30KB以上；而这些数据缓存半小时也是没有问题，那么我们可以设计为先读local cache，然后把不命中的再回源到remote cache获取，这个优化减少了一半以上的remote cache流量。

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

动态化

数据获取动态化，商品详情页：按维度获取数据，如商品基本数据、其他数据（分类、商家信息等）；而且可以根据数据属性，按需做逻辑，比如虚拟商品需要自己定制的详情页，那么我们就可以跳转走，比如全球购的需要走jd,hk域名，那么也是没有问题的；

模板渲染实时化，支持随时变更模板需求；
重启应用秒级化，使用Nginx+Lua架构，重启速度快，重启不丢共享字典缓存数据；
需求上线速度化，因为我们使用了Nginx+Lua架构，可以快速上线和重启应用，不会产生抖动；另外Lua本身是一种脚本语言，我们也在尝试把代码如何版本化存储，直接内部驱动Lua代码更新上线而不需要重启Nginx。

弹性化

我们所有应用业务都接入了Docker容器，存储还是物理机。我们会制作一些基础镜像，把需要的软件打成镜像，这样不用每次去运维那安装部署软件了。未来可以支持自动扩容，比如按照CPU或带宽自动扩容机器，目前京东一些业务支持一分钟自动扩容。

降级开关

推送服务器推送降级开关，开关集中化维护，然后通过推送机制推送到各个服务器。可降级的多级读服务为：前端数据集群→数据异构集群→动态服务（调用依赖系统），这样可以保证服务质量，假设前端数据集群坏了一个磁盘，还可以回源到数据异构集群获取数据。开关前置化，如Nginx→Tomcat，在Nginx上做开关，请求就到不了后端，减少后端压力。

将可降级的业务线程池隔离，从Servlet3开始支持异步模型，Tomcat7/Jetty8开始支持，相同的概念是Jetty6的Continuations。我们可以把处理过程分解为一个个的事件。通过这种将请求划分为事件的方式我们可以进行更多的控制。如，我们可以为不同的业务再建立不同的线程池进行控制：即我们只依赖Tomcat线程池进行请求的解析，对于请求的处理可以交给我们自己的线程池去完成，如下图所示。这样Tomcat线程池就不是我们的瓶颈，造成现在无法优化的情况。通过使用这种异步化事件模型，我们可以提高整体的吞吐量，不让慢速的A业务处理影响到其他业务处理。慢的还是慢，但是不影响其他的业务。我们通过这种机制还可以把Tomat线程池的监控拿出来，出问题时可以直接清空业务线程池，另外还可以自定义任务队列来支持一些特殊的业务。

多机房多活

应用无状态，通过在配置文件中配置各自机房的数据集群来完成数据读取，如下图所示。

数据集群采用一主三从结构，防止当一个机房挂了，另一个机房压力大产生抖动，如下图所示。

多种压测方案

线下压测使用Apache ab、Apache Jmeter，这种方式是固定url压测，一般通过访问日志收集一些url进行压测，可以简单压测单机峰值吞吐量，但是不能作为最终的压测结果，因为这种压测会存在热点问题。

线上压测，可以使用Tcpcopy直接把线上流量导入到压测服务器，这种方式可以压测出机器的性能，而且可以把流量放大，也可以使用Nginx+Lua协程机制把流量分发到多台压测服务器，或者直接在页面埋点，让用户压测，此种压测方式可以不给用户返回内容。

遇到一些问题

SSD性能差

使用SSD做KY存储时发现磁盘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顺序写操作简单压测，严格测试需要用FIO等工具。

键值存储选型压测

对于存储选型，我们尝试过LevelDB、RocksDB、BeansDB、LMDB、Riak等，最终根据需求选择了LMDB。

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

LevelDB压测时，随机读+随机写会产生抖动（我们的数据出自自己的监控平台，分钟级采样），如下图所示。

RocksDB是改造自LevelDB，对SSD做了优化，我们压测时单独写或读，性能非常好，但是读写混合时就会因为归并产生抖动，如下图所示。

LMDB引擎没有大的抖动，基本满足我们的需求，如下图所示。

我们目前一些线上服务器使用的是LMDB，其他一些正在尝试公司自主研发的CycleDB引擎。

数据量大时JIMDB同步不动

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

一台物理机挂2块SSD（512GB），单挂raid0；启动8个jimdb实例；这样每实例差不多125GB左右；目前是挂4块raid0；新机房计划8块raid10。
目前是千兆网卡同步，同步峰值在100MB/s左右。
dump和sync数据时是顺序读写，因此挂一块SAS盘专门来同步数据。
使用文件锁保证一台物理机多个实例同时只有一个在dump。
后续计划改造为直接内存转发而不做dump。

切换主从

之前存储架构是一主二从（主机房一主一从，备机房一从）切换到备机房时，只有一个主服务，读写压力大时有抖动，因此我们改造为之前架构图中的一主三从。

分片配置

之前的架构是分片逻辑分散到多个子系统的配置文件中，切换时需要操作很多系统，解决方案：

引入Twemproxy中间件，我们使用本地部署的Twemproxy来维护分片逻辑。
使用自动部署系统推送配置和重启应用，重启之前暂停MQ消费保证数据一致性。
用unix domain socket减少连接数和端口占用不是放启动不了服务的问题。

模板元素存储HTML

起初不确定Lua做逻辑和渲染模板性能如何，就尽量减少for、if/else之类的逻辑；通过Java Worker组装HTML片段存储到jimdb，HTML片段会存储诸多问题，假设未来变了也是需要全量刷出的，因此存储的内存最好就是元数据。因此通过线上不断压测，最终jimdb只存储元数据，Lua做逻辑和渲染，逻辑代码在3000行以上，模板代码1500行以上，其中包含大量for、if/else语句，目前渲染性能也可以接受。

线上真实流量，整体TP99性能从53ms降到32ms，如下图所示。

绑定8CPU测试的结果如下图所示，渲染模板的性能可以接受。

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

商品详情页库存接口2014年被恶意刷，每分钟超过600万访问量，Tomcat机器只能定时重启；因为是详情页展示的数据，缓存几秒钟是可以接受的，因此开启Nginx Proxy Cache来解决该问题，开启后降到正常水平。我们目前正在使用Nginx+Lua架构改造服务，数据过滤、URL重写等在Nginx层完成，通过URL重写+一致性哈希负载均衡，不怕随机URL，一些服务提升了10%以上的缓存命中率。

微信接口调用量暴增

通过访问日志发现某IP频繁抓取，而且按照商品编号遍历，但是会有一些不存在的编号，解决方案是：

读取KV存储的部分不限流；
回源到服务接口的进行请求限流，保证服务质量。

开启Nginx Proxy Cache性能不升反降

开启Nginx Proxy Cache后，性能下降，而且过一段时间内存使用率到达98%，解决方案是：

对于内存占用率高的问题是内核问题，内核使用LRU机制，本身不是问题，不过可以修改内核参数：


sysctl -w vm.extra_free_kbytes=6436787
 
sysctl -w vm.vfs_cache_pressure=10000

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

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

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

串行获取变并发获取，这样一些服务可以并发调用，在我们某个系统中能提升一倍多的性能，从原来TP99差不多1s降到500ms以下；
预取依赖数据回传，这种机制还有一个好处，比如我们依赖三个下游服务，而这三个服务都需要商品数据，那么我们可以在当前服务中取数据，然后回传给他们，这样可以减少下游系统的商品服务调用量，如果没有传，那么下游服务再自己查一下。

假设一个读服务需要如下数据，如下表所示。

目标数据	数据A	数据B	数据C	数据D	数据E
获取时间	10ms	15ms	10ms	20ms	5ms

如果串行获取，那么需要60ms。

而如果数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C，那么我们可以这样来获取数据，如下图所示。

如果并发获取，则需要30ms，能提升一倍的性能。

假设数据C还依赖数据F（5ms），而数据F是在数据C服务中获取的，此时，就可以考虑在取A/B/D服务数据时，并发预取书v就F，那么整体性能就变为25ms。

商品详情页通过这种优化，我们的服务提升了差不多10ms性能，如下图所示。

如下图所示的服务，他在抖动时的性能：老服务TP99是211ms，优化后的新服务是118ms，此处我们主要就是并发调用+超时时间限制，超时直接降级。

网络抖动时，返回502错误

Twemproxy配置的timeout时间太长，之前设置为5s，而且没有分别针对连接、读、写设置超时。后来我们减少超时时间，内网设置在150ms以内，当超时时访问动态服务。

机器流量太大

2014年双11期间，服务器网卡流量到了400Mbps，CPU30%左右。原因是我们所有压缩都在接入层完成，因此接入层不再传入相关请求头到应用，随着流量的增大，接入层压力过大，因此我们把压缩下放到各个业务应用，添加了相应的请求头，Nginx GZIP压缩级别在2~4吞吐量最高，应用服务器流量降了差不多5倍，目前正常情况CPU在4%以下，如下图所示。

综上所述，在电商应用中，随着业务规模的发展，应用的和缓存相关的技术有数据静态化架构、多级缓存模式、队列异步化、并行化等。可以把电商应用架构定义为高流量、高并发、高可用类应用。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Gausst松鼠会/article/detail/475737

案例：典型电商应用与缓存。_库存推送 缓存 聚合