一、前言

随着商城业务渠道一直扩大，促销玩法一直增多，原商城 v2.0 架构曾经无奈满足一直减少的流动玩法，须要进行促销零碎的独立建设，与商城解耦，提供纯正的商城营销流动玩法撑持能力。

咱们将分系列来介绍 vivo 商城促销零碎建设的过程中遇到的问题和解决方案，分享架构设计教训。

二、零碎框架

2.1 业务梳理

在介绍业务架构前咱们先简略理解下 vivo 商城促销零碎业务能力建设历程，对现促销能力进行梳理回顾。在商城 v2.0 中促销性能存在以下问题：

1. 促销模型不够形象，保护凌乱，没有独立的流动库存；

2. 凌乱的流动共融互斥关系治理，不足对立的促销计价能力。

商城外围交易链路中商详页、购物车、下单这三块对于计价逻辑是离开独立保护的，没有对立，如下图所示。显然随着促销优惠的减少或者玩法的变动，商城侧业务反复开发量会显著加大。

（图 2 -1. 促销计价对立前）

3. 促销性能无奈满足流动量级，往往会影响商城主站的性能。

因与商城零碎耦合，无奈提供针对性的性能优化，造成零碎无奈撑持越来越频繁的大流量场景下大促流动。

基于这些痛点问题，咱们一期实现促销零碎的独立，与商城解耦，搭建出促销系统核心能力：

优惠活动治理

对所有优惠活动形象出对立的优惠模型和配置管理界面，提供流动编辑、批改、查问及数据统计等性能。并独立出对立的流动库存治理，便于流动资源的对立把控。

促销计价

基于高度灵便、抽象化的计价引擎能力，通过定义分层计价的促销计价模型，制订对立的优惠叠加规定与计价流程，实现 vivo 商城促销计价能力的建设。推动实现 vivo 商城所有外围链路接入促销计价，实现全链路优惠价格计算的对立，如下图：

（图 2 -2. 促销计价对立后）

随着一期促销系统核心能力的实现，极大的满足了业务须要，各类优惠玩法随之增多。但随同而来的就是各种经营痛点：

• 保护的促销流动无奈提前点检，查看流动成果是否合乎预期；
• 随着优惠玩法的增多，一个商品所能享受的优惠越来越多，配置也越来越简单，极易配置谬误造成线上事变；

为此咱们开始促销零碎二期的能力建设，着重解决以上经营痛点：

• 提供时光穿梭性能，实现用户可能“穿梭”至将来某个工夫点，从而实现促销流动的提前点检；
• 提供价格监控性能，联合「商城营销价格能力矩阵」布局的能力，通过事先 / 事中 / 预先多维度监控措施，来“升高出错概率，出错能及时止损”。

2.2 促销与优惠券

促销的次要目标就是向用户传递商品的各种优惠信息，提供优惠利益，吸引用户购买，从而起到促活拉新、进步销量的目标。从这种角度来看，优惠券也属于促销的一部分。

但因一些起因 vivo 商城促销零碎独立过程中，并没有与促销零碎放一块：

• 首先，优惠券零碎在商城 v2.0 时就已独立，曾经对接很多上游业务，曾经是成熟的中台零碎；
• 再者，就是优惠券也有相较与其它促销优惠的业务特殊性，如有发券、领券能力。

在思考设计革新老本就未将优惠券包含在促销零碎能力领域，但优惠券毕竟也是商品价格优惠的一部分，因而促销计价须要依赖优惠券零碎提供券优惠的能力。

2.3 业务架构 & 流程

至此咱们也就梳理出整个促销零碎的大略能力矩阵，整体架构设计如下：

（图 2 -3. 促销零碎架构）

而随着促销零碎独立，整个商城购物流程与促销零碎的关系如下：

（图 2 -4. 最新商城购物流程）

三、技术挑战

作为中台能力零碎，促销零碎面临的技术挑战包含以下几方面：

• 面对复杂多变的促销玩法、优惠叠加规定，如何让零碎具备可扩展性，满足日益多变的优惠需要，晋升开发与经营效率。
• 面对新品公布、双 11 大为客户等大流量场景，如何满足高并发场景下的高性能要求。
• 面对来自上游业务方的不可信调用，以及上游依赖方的不牢靠服务等简单零碎环境，如何晋升零碎整体的稳定性，保障系统的高可用。

咱们联合本身业务特点，梳理出一些技术解决方案。

3.1 可扩展性

扩展性晋升次要体现在两块：

• 优惠模型的定义，对所有优惠活动形象出对立的优惠模型和配置管理界面；
• 促销计价引擎的建设，计价模型的对立。

相干的具体设计内容，会有后续文章进行阐明。

3.2 高并发 / 高性能

缓存

缓存简直就是解决性能问题的“银弹”，在促销零碎中也大量应用缓存进行性能晋升，包含应用 redis 缓存与本地缓存。而应用缓存就须要关注数据一致性问题，redis 缓存还好解决，但本地缓存不就好解决了。因而本地缓存的应用要看业务场景，尽量是数据不常常变更且业务上能承受肯定不统一的场景。

批量化

促销零碎的业务场景属于典型的读多写少场景，而读的过程中对性能影响最大的就是 IO 操作，包含 db、redis 以及第三方近程调用。而对这些 IO 操作进行批量化革新，以空间换工夫，缩小 IO 交互次数也是性能优化的一大计划。

精简化 / 异步化

简化性能实现，将非核心工作进行异步化革新。如流动编辑后的缓存解决、资源预占后的音讯同步、拼团状态流转的音讯告诉等等。

冷热拆散

对于读多写少场景对性能影响最大的除了 IO 操作，还有就是数据量，在促销零碎中也存在一些用户态数据，如优惠资源预占记录、用户拼团信息等。这些数据都具备工夫属性，存在热尾效应，大部分状况下须要的都是最近的数据。针对这类场景对数据进行冷热拆散是最佳抉择。

3.3 零碎稳定性

限流降级

基于公司的限流组件，对非核心的服务性能进行流量限度与服务降级，高并发场景下全力保障整体零碎的外围服务

幂等性

所有接口均具备幂等性，防止业务方的网络超时重试造成的零碎异样

熔断

应用 Hystrix 组件对外部零碎的调用增加熔断爱护，避免内部零碎的故障造成整个促销零碎的服务解体

监控和告警

通过配置日志平台的谬误日志报警、调用链的服务剖析告警，再加上公司各中间件和根底组件的监控告警性能，让咱们可能第一工夫发现零碎异样

四、踩过的坑

4.1 Redis SCAN 命令应用

在 Redis 缓存数据革除的处理过程中，存在局部缓存 key 是通过含糊匹配的形式进行查找并革除操作，底层依赖 Redis SCAN 命令。

SCAN 命令是一个基于游标的迭代器，每次被调用之后都会向用户返回一个新的游标，用户在下次迭代时须要应用这个新游标作为 SCAN 命令的游标参数，以此来连续之前的迭代过程。

对于应用 KEYS 命令，SCAN 命令并不是一次性返回所有匹配后果，缩小命令操作对 Redis 零碎的阻塞危险。但并不是说 SCAN 命令就能够轻易用，其实在大数据量场景下 SCAN 存在与 KEYS 命令一样的危险问题，极易造成 Redis 负载升高，响应变慢，进而影响整个零碎的稳定性。

（图 4 -1 Redis 负载升高）

(图 4 -2 Redis 响应呈现尖刺)

而解决方案就是：

• 优化 Redis key 设计，缩小不必要的缓存 key；
• 移除 SCAN 命令应用，通过准确匹配查找进行革除操作。

4.2 热点 key 问题

在促销零碎中广泛应用 redis 缓存进行性能晋升，缓存数据很多都是 SKU 商品维度。在新品公布、特定类型手机大促等业务场景下极容易产生热点 Key 问题。

热点 Key 具备汇集效应，会导致 Redis 集群内节点负载呈现不平衡，进而造成整个零碎不稳固。该问题是一般的机器扩容无奈解决的。如下图某次线上摸排压测时 redis 负载状况：

罕用的解决方案有两种：

• 散列计划：对 Redis Key 进行散列，均匀扩散到 RedisCluster Nodes 中，解决热点 Key 的汇集效应。
• 多级缓存计划：对热点 Key 减少应用本地缓存，最大限度减速拜访性能，升高 Redis 节点负载。

咱们是采纳多级缓存计划，参照优良的开源热点缓存框架，定制化扩大出一整套热点解决方案，反对热点探测、本地缓存、集群播送以及热点预热性能，做到准实时热点探测并将热点 Key 告诉实例集群进行本地缓存，极大限度防止大量反复调用冲击分布式缓存，晋升零碎运行效率。

五、总结

本篇属于 vivo 商城促销零碎概览介绍篇，简略回顾了 vivo 商城促销零碎业务能力建设历程及零碎架构，并分享遇到的技术问题与解决方案。后续咱们会对促销零碎的外围功能模块（优惠活动治理、促销计价、价格监控和时光穿梭）的设计实际进行一一分享，敬请期待。

作者：vivo 互联网官网商城开发团