一、前言

随着商城业务渠道不断扩展，促销玩法不断增多，原商城 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 互联网官方商城开发团队