🎉如何做好营销活动红包、优惠券核心架构设计？

概述

💥美团、淘宝、京东、拼多多以及各大电商业务平台为了促进消费，很早就推出支付红包、奖励等业务，也就是在某些特定的场景给用户派发不同的红包和奖励，用户使用平台派发的红包，可抵扣相应的金额，用下次购买使用，以达到吸引客户复购的目的。

实际上，优惠券是电商常见的营销手段，具有灵活的特点，既可以作为促销活动的载体，也是重要的引流入口。一般随着商城的发展及用户量的提升，优惠券会做服务拆分，成立了独立的优惠券系统，提供通用的优惠券服务。比如：大型的优惠券系统基本上覆盖了优惠券的4个核心要点：创、发、用、计。

• “创”指优惠券的创建，包含各种券规则和使用门槛的配置。
• “发”指优惠券的发放，优惠券系统提供了多种发放优惠券的方式，满足针对不同人群的主动发放和被动发放。
• “用”指优惠券的使用，包括正向购买商品及反向退款后的优惠券回退。
• “计”指优惠券的统计，包括优惠券的发放数量、使用数量、使用商品等数据汇总。

系统要求

1.并发性

营销系统比如涉及到访问量大的问题，系统涉及所面临的第一关，即活动开始的瞬间，大批用户点击的涌入。怎样设计系统以达到如此高并发情况下的及时响应是本项目的重中之重。

2.活动扩展配置

一个优秀的营销系统必须具备一定的扩展性配置，能支撑不同业务板块的活动的设计，相关数据库表的扩展字段从一开始就应该预留和支持，优惠券、红包、奖励本身元素据信息应该以json字段的形式存储，便于扩展。

营销活动类型：

• 随机立减
• 优惠券
• 折扣券
• 超值卡
• 红包
• 会员送币

营销活动规则：

• 时间限制
• 数量限制
• 设备类型限制
• 叠加限制
• 金额门槛
• 概率

3.校验触发规则条件

（a）展示触发：C端用户扫码进入首页的活动展示触发显示，指引用户购买推荐活动。 （b）支付前触发：是否满足商品和增值商品的支付金额的校验，满足条件才允许下单支付。 （c）支付后触发：支付后满足相关设定的条件自动派发优惠券或者广告红包。

4.库存控制

优惠券或者红包面临的必然是奖品，数量控制是必须要做到精准吻合。不允许出现设置了100个优惠券，最终101人领取成功这种类似的问题出现，其中的本质是库存的控制。

5.投放策略

在活动时间段内，管理员设置好的一堆奖品如何投放？红包何时出现？什么时候可以被抽中？这些都涉及到投放策略。

6.门槛限制

（a）是否满足满减条件门槛 （b）是否满足套餐总金额上限门槛 （c）每人每日限制只能参与一次活动

7.边界控制

活动何时开始？何时结束？倒计时如何控制。这涉及到活动的边界。开始前要提防用户提前进入抽奖。结束后要及时反馈结果给用户，告知活动已结束。

8.优惠计算规则

不同的营销活动涉及的优惠计算规则不同，有可能涉及到几十或者几百种活动，十分考验活动架构拓展性，类似的优惠计算规则策略包含：

• 平台券优惠计算规则
• 广告券优惠计算规则
• 满减券优惠计算规则
• 固定金额优惠计算规则
• 限时优惠计算规则
• 新用户活动优惠计算规则

9.核销策略

• 商家活动核销
• 退款业务核销

10.其他

• 商家白名单控制
• 活动白名单控制

营销支付时序图

红包和优惠券的投放策略

广告红包、优惠券的投放有很多种方式，对市面的主流玩法做了归纳总结：

• 主动发券。商家主动给用户发券，比如常见的新人礼包，或某些用户福利活动。比如：新用户注册成功后，自动往用户账户发放一张优惠券，用于促进新用户的下单转化。
• 会员领取。类似阿里的88会员，在饿了么APP，每月都有20个金币，可以转换成4张5元无门槛优惠券。
• 手动领取。平台会提供优惠券的展示入口，比如 购物车、商品详情页等，用户主动点击领取，优惠券就成功发放了。
• 优惠码领取。活动创建后，将所有被发放的优惠券转化为优惠码，通过优惠码来进行发放。
• 消费返券。在用户消费后发券，增加买家再次购买的可能性。
• 分享发券。利用社交网络的传播条件，给用户提供优惠信息并鼓励用户进行传播和分享，比如分享红包链接到朋友圈或微信群，其他用户点击领取。如：美团、饿了么、滴滴、瑞幸咖啡，大量使用这种方式。
• 活动送券：法定节假日或特定节日，比如电商大促双11、618，以活动的形式向用户发券
• 主动触发：通过营销短信或push通知告知给用户发放优惠券，唤醒用户。注意这种方式发券会对用户造成打扰，要注意发券的频率和时间。主动触发多用于刺激留存用户、唤醒沉睡用户。
• 积分兑券。与用户的积分体系打通，刺激用户赚取积分，并有消费场景，拉动用户的活跃度。
• 任务发券。用户参与完成特定的游戏、任务、活动，可以获得优惠券奖励。当然也可能是红包、甚至现金奖励，更能激发用户的参与热情。
• 异业发券。选择与自家目标用户有重叠的平台合作，在该平台发券导流该平台用户到自家平台，实现换量拉新。
• 社交玩法。优惠券不仅仅可以自己用，还可以“共享”给朋友使用（注意是共享，而不是分享，因为优惠券只能核销一次）。支付宝之前推出过该功能。
• 邀请送券。邀请好友可得价值多少的优惠券。

可扩展性

为了面对复杂多变的促销策略，红包、优惠券的铁架玩法，如何让系统具备可扩展性，我总结了一下几点：

• 活动、活动配置支持扩展配置，预留相关的可扩展字段，一个活动针对不同的业务场景可以有多个活动配置，以此来满足不同的促销限制条件。
• 优惠券模版的定义，对所有优惠活动抽象出统一的优惠模型和配置管理界面。
• 红包、优惠券的类型配置。
• 促销优惠价格计算规则引擎定义，计价模型策略建立，不同类型的优惠券走不同的计价规则。
• 核销策略、风控模型的建立。
• 支持不同的触达方式，

高性能&高并发

缓存

缓存几乎就是解决性能问题的“利剑”，在促销系统中也大量使用缓存进行性能提升，包括使用redis缓存与本地缓存。而使用缓存就需要关注数据一致性问题，redis缓存还好解决，但本地缓存不就好处理了。因此本地缓存的使用要看业务场景，尽量是数据不经常变更且业务上能接受一定不一致的场景。

异步化

将非核心任务进行异步化改造。如活动编辑后的缓存处理、资源预占后的消息同步、拼团状态流转的消息通知，支付后发放广告红包、优惠券等操作异步化，结合池化技术、kafka、RocketMq消息队列等，异步化可以大大提高整体链路的RT。

批量化

促销系统的业务场景属于典型的读多写少场景，而读的过程中对性能影响最大的就是IO操作，包括db、redis以及第三方远程调用。而对这些IO操作进行批量化改造，以空间换时间，减少IO交互次数也是性能优化的一大方案。

冷热分离

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

幂等性

相关的接口应该具备幂等性，比如：券在下单时候的使用幂等、消息推送触达的幂等，避免业务方的网络超时重试造成的系统异常或者数据的异常。

限流降级

基于公司的限流组件，对非核心的服务功能进行流量限制与服务降级，高并发场景下全力保障整体系统的核心服务。

熔断

使用Hystrix组件对外部系统的调用添加熔断保护，防止外部系统的故障造成整个促销系统的服务崩溃。

监控和告警

通过配置日志平台的错误日志报警、调用链的服务分析告警，再加上公司各中间件和基础组件的监控告警功能，让我们能够第一时间发现系统异常。

技术挑战

作为类似中台能力系统，营销服务面临的技术挑战我主要总结为以下几点：

• 系统的高扩展性，面对复杂多变的业务营销玩法，优惠券、红包叠加等计算规则，如何让系统具备高可扩展，满足日益多变的优惠促销需求，是系统的重中之重，不然，不同的业务线不同的营销活动配置又得重新重构甚至另外开发一套，就是得不偿失，大大提高了开发的工作效率。
• 优惠券也有相较与其它促销优惠的业务特殊性，如有发券、领券能力。在考虑设计改造成本就未将优惠券包括在促销系统能力范畴，但优惠券毕竟也是商品价格优惠的一部分，因此促销计价需要依赖优惠券系统提供券优惠的能力。
• 面对一些大流量的场景，如何满足高并发下的高性能要求。
• 风控如何接入，领券接口的QPS会比较高，对风控接口性能有较高要求。
• 券或者红包缓存如何设计。一般会按变化的频率做拆分。券模板本身内容可以封装一个缓存模型。其中的券库存由于经常变化，需要单独剥离处理，采用缓存+数据库。但如何保证两者的数据一致性需要我们特别关注。
• 海量优惠券的发放，达到优惠券单库单表的存储瓶颈，领取、发放、使用记录同样校验如何保证高性能，数据量庞大的情况下如何考虑采用缓存+数据库去优化。
• 用户标签。由于不用的优惠券会限制发放给不用的用户人群，所以我们会根据券模板设置的用户标，采用策略模式，调用外部服务，实时查询用户是否满足领取条件。

总结

🎉实际上，不同公司的营销策略不同，因此营销系统的架构设计也有所不同，促销是电商领域非常重要的营销手段，有效提高订单转化率、客单价、网站的GMV交易额，因此也是我们在互联网技术大厂都应该具备的技术能力之一，本文只是记录我个人的经验和技术看法，我是：👨‍🎓IT_sunshine，如果文章对你有所帮助，欢迎点赞👍+关注✔+收藏❤，我们下期见！