优惠券商城怎么建设 第1篇
使用之前，需要根据优惠券创建时的规则来判断，商品是否能使用？是否能与其他优惠叠加使用？由此来算出商品的最终价格，这是使用中最复杂的阶段，尤其是平台本身有很多优惠形式时，各种优惠的优先级，是否互斥，具体规则要穷尽出来。
像我负责的业务，优惠形式有折扣、满减、积分抵扣，折扣形式有七八个，折扣之间可叠加或不叠加，优惠券的优先级，能跟哪些叠加和互斥，计算起来都是比较复杂的。涉及到钱的地方，都需要认真再认真啊！
优惠券商城怎么建设 第2篇
用户下单时使用优惠券，下单后未付款超时、未支付取消，支持退还优惠券。而已付款退货涉及到价格计算和分摊，较为复杂，一般是不支持退还的。
五、数据记录和统计
数据主要是为了观察优惠券的发放、领取、使用情况，便于后期根据数据情况复盘运营动作，一般有以下几个统计维度：
已领取、已使用的优惠券还要记录领取用户的相关字段，如uid、手机号、订单号、下单时间、购买商品id、订单金额等，原型实例：
原型示例
六、总结
优惠券系统的功能点不算复杂，难点在于要结合业务考虑的尽可能全面，完整考虑好创建-投放-使用-统计
的闭环。因为优惠券会用于非常多的业务场景，所以需要在后台优惠券系统搭建时，将其与业务解耦，否则会导致后期拓展性不强。
题图来自 Unsplash，基于 CC0 协议
优惠券商城怎么建设 第3篇
除了上述的几个设定，还有一个很复杂的设定是“适用范围”的设定，这个设定也是最考验技术团队的，会极大影响后期的性能。由于我负责的这个项目是自营的，所以范围这里控制的比较简单，如果项目更复杂的话，这里可以适当变化。
由于我目前负责的商城还在起步阶段，商品没有太多，所以暂时提供了如图的范围选择。
适用商品的设定思路如下，仅供参考：
优惠券商城怎么建设 第4篇
瓜分优惠券方案有两种，一种是按领取顺序排列，第N个领取获得最大优惠。比如800元的优惠额度，按领取顺序优惠额度为200、100、300、100、100。第二种是将整体额度拆成几种面额的优惠，用户领取时按一定的概率领取相应的优惠券。
使用优惠券这种促销形式时需要注意的点如下：
就像新鲜的苹果不吃就会过期，优惠券不使用也会过期，这一部分，我们来聊一聊优惠券的管理。首先是优惠券的核销，我们分别分析京东、淘宝、拼多多的优惠券核销逻辑 京东优惠券使用逻辑：
1） 京东优惠券可以下单使用，支付时使用，同时也支持分享赠送，这些操作都称为核销
2）优惠券需要提前领取，只可选择已有的优惠券
3）京东优惠券在结算页时，会自动推荐优惠券，逻辑是：
1）淘宝优惠券只能下单使用并核销
2）优惠券不需要提前领取，进入结算页后，系统自动领取符合条件的优惠券，如订单金额是50元，系统会领取50元以内最高额度的优惠券
3）淘宝优惠券在结算页时，不会展示具体的优惠券，是以打包优惠的形式展现
拼多多优惠券使用逻辑：
首先是售前取消的逻辑： 售前取消分用户主动取消、被动取消（如商家发货前取消订单等特殊情况），但是处理逻辑是一样的。订单是否拆单也会对券的逆向流程产生影响，未拆单下券全额返还，已拆单的情况下根据是否全部取消情况也不同。注意部分取消的情况，返拆分券的情况不常用，返等值代币和不返的情况比较多，需要注意的是不返的情况需要提前在优惠券的使用规则中说明。 另一种是售后取消，售后只能用户主动取消了，商家或系统不能未经用户同意擅自取消其订单。其余逻辑判断与售前取消一致。在订单使用优惠券后产生售后，其优惠分摊是按商品价格加权按比例分摊的，公式为：（商品金额/订单总金额）*优惠券金额。如订单金额1000元，商品A和B的价格分别为800元和200元，使用一种满100-50的优惠券。那么A分摊40元的优惠，B分摊10元的优惠。
接下来我们根据一个实际案例来看优惠券的逆向流程：
小明购买了一台1499元的手机和一个99元的充电宝，下单时使用一张满500-50的优惠券，两个商品分属不同商家，订单拆单发货。
场景1：小明发现更好的充电宝需将原充电宝退掉，券如何退？
我们首先根据价格计算出充电宝的优惠金额=（99/1548）*50=元
场景2：小明不想要了，整单退款，则原优惠券全额返还。
优惠券和订单一样，也会有不同状态之间的流转变化，总结如下： 最后是对优惠券的数据监控，主要的监控发放数据、转化数据、计算数据：
至此，我们总结一下本章内容，分为四个部分：
优惠券商城怎么建设 第5篇
保存的时候分两种情况：
当优惠券处于“草稿”的时候，可以提交审核。然后状态变成“待审核”。
如果优惠券正在进行中的时候，我们发现了一些异常现象，此时我们可以用“强制停止”功能将该优惠券停掉。用户就无法继续领取了。此时状态会处于“已停止”。
后端的设定和基本操作差不多就是这些，该设定参考了一些其他商城后台的设定，应该是比较全面并且简洁的。希望这些经验能够帮助到大家，同时欢迎留言和交流~
欢迎大家来体验、来提建议，来一起让CRMEB开源商城系统更强大，让更多开发者受益！虽然是开源，但我们该有的功能全都有！拼团、秒杀、优惠券、抽奖、积分、直播、分销、页面DIY... 常用商城系统功能，都是全开源，直接用！
题图来自 Unsplash，基于CC0协议
优惠券商城怎么建设 第6篇
优惠券的使用需要和商品关联，可关联所有商品，也可以关联部分商品。为了灵活性地满足运营对于券关联商品的配置，优惠券系统有两种关联方式：
a. 黑名单。
可用商品 = 全部商品 - 黑名单商品。
黑名单适用于券的可使用商品范围比较广这种情况，全部商品排除掉黑名单商品就是券的可使用范围。
b. 白名单。
可用商品 = 白名单商品。
白名单适用于券的可使用商品范围比较小这种情况，直接配置券的可使用商品。
除此以外，还有超级黑名单的配置，黑名单和白名单只对单个券有效，超级黑名单对所有券有效。当前优惠券系统提供商品级的关联，后续优惠券会支持商品分类维度的关联，分类维度 + 商品维度可以更灵活地关联优惠券和商品。
优惠券对接系统多，存在高流量场景，优惠券对外提供接口需保证高性能和高稳定性。
多级缓存
为了提升查询速度，减轻数据库的压力，同时为了应对瞬时高流量带来热点 key 的场景（比如发布会直播结束切换流量至特定商品商详页、热点活动商品商详页都会给优惠券系统带来瞬时高流量），优惠券采用了多级缓存的方式。
数据库读写分离
优惠券除了上述所说的分库分表外，在此基础上还做了读写分离操作。主库负责执行数据更新请求，然后将数据变更实时同步到所有从库，用从库来分担查询请求，解决数据库写入影响查询的问题。主从同步存在延迟，正常情况下延迟不超过 1ms，优惠券的领取或状态变更存在一个耗时的过程，主从延迟对于用户来说无感知。
依赖外部接口隔离熔断
优惠券内部依赖了第三方的系统，为了防止因为依赖方服务不可用，产生连锁效应，最终导致优惠券服务雪崩的事情发生，优惠券对依赖外部接口做了隔离和熔断。
用户维度优惠券字段冗余
查询用户相关的优惠券数据是优惠券最频繁的查询操作之一，用户优惠券数据做了分库分表，在查询时无法关联券规则表进行查询，为了减少 IO 次数，用户优惠券表中冗余了部分券规则的字段。优惠券规则表字段较多，冗余的字段不能很多，要在性能和字段数之间做好平衡。
最后对优惠券系统进行一个总结：
不停机迁移，平稳过渡。自独立后已稳定运行 2 年，性能足以支撑 vivo 商城未来 3-5 年的高速发展。
系统解耦，迭代效率大幅提升。
针对业务问题，原则是选择合适实用的方案。
具备完善的优惠券业务能力。
展望：目前优惠券系统主要服务于 vivo 商城，未来我们希望将优惠券能力开放，为内部其他业务方提供通用一体化的优惠券平台。
优惠券商城怎么建设 第7篇
对应的优惠券产品应该具备的功能有：
需要注意的点有：
首先我们来梳理一下优惠券从创建到使用的业务流程： 接下来看下后台创建优惠券这一流程： 来看一下在手机端创建精简版优惠券与后台创建复杂版优惠券的字段: 上图是微信小店后台创建的满减优惠券，可以看到创建优惠券所需的基本信息有：券名称、起始与结束时间、有效期、限领张数、使用门槛、券金额、发行张数。接下来我们看一下在后台创建复杂版本优惠券所需的信息： 上图只截取了部分字段，实际可配置的字段还要多很多，除了简单版本优惠券所需的信息，还可配置的信息有：适用渠道、适用商品、领取人限制、使用人限制、分享设置、转赠设置、过期提醒等等。接下来我们探讨一下优惠券前台手机端展示的信息。原则上，优惠券前台展示原则有三点：肉眼可见、不影响主干、顺从交易流程。接下来我们具体看一下商品详情页、购物车、个人中心三处页面的优惠券的展示逻辑。
优惠券商城怎么建设 第8篇
为满足各种不同场景的发券需求，优惠券系统提供三种发券方式：统一领券接口、后台定向发券、券码兑换发放。
保证领券校验的准确性
领券时，需要严格校验优惠券的各种属性是否满足：比如领取对象、各种限制条件等。其中，比较关键的是库存和领取数量的校验。因为在高并发的情况下，需保证数量校验的准确性，不然很容易造成用户超领。
存在这样的场景：A 用户连续发起两次领取券 C 的请求，券 C 限制每个用户领取一张。第一次请求通过了领券数量的校验，在用户优惠券未落库的情况下，如果不做限制，第二次请求也会通过领券数量的校验。这样 A 用户会成功领取两张券 C，造成超领。
为了解决这个问题，优惠券采用的是分布式锁方案，分布式锁的实现依赖于 Redis。在校验用户领券数量前先尝试获取分布式锁，优惠券发放成功后释放锁，保证用户领取同一张券时不会出现超领。上面这种场景，用户第一次请求成功获取分布式锁后，直至第一次请求成功释放已获取的分布式锁或超时释放，不然用户第二次请求会获取分布式锁失败，这样保证 A 用户只会成功领取一张。
库存扣减
领券要进行库存扣减，常见库存扣减方案有两种：
方案一：数据库扣减。
扣减库存时，直接更新数据库中库存字段。
该方案的优点是简单便捷，查验库存时直接查库即可获取到实时库存。且有数据库事务保证，不用考虑数据丢失和不一致的问题。
缺点也很明显，主要有两点：
1）库存是数据库中的单个字段，在更新库存时，所有的请求需要等待行锁。一旦并发量大了，就会有很多请求阻塞在这里，导致请求超时，进而系统雪崩。
2）频繁请求数据库，比较耗时，且会大量占用数据库连接资源。
方案二：基于 redis 实现库存扣减操作。
将库存放到缓存中，利用 redis 的 incrby 特性来扣减库存。
该方案的优点是突破数据库的瓶颈，速度快，性能高。
缺点是系统流程会比较复杂，而且需要考虑缓存丢失或宕机数据恢复的问题，容易造成库存数据不一致。
从优惠券系统当前及可预见未来的流量峰值、系统维护性、实用性上综合考虑，优惠券系统采用了方案一的改进方案。改进方案是将单库存字段分散成多库存字段，分散数据库的行锁，减少并发量大的情况数据库的行锁瓶颈。
库存数更新后，会将库存平均分配成 M 份，初始化更新到库存记录表中。用户领券，随机选取库存记录表中已分配的某一库存字段（共 M 个）进行更新，更新成功即为库存扣减成功。同时，定时任务会定期同步已领取的库存数。相比方案一，该方案突破了数据库单行锁的瓶颈限制，且实现简单，不用考虑数据丢失和不一致的问题。
一键领取多张券
在对接的业务方的领券场景中，存在用户一键领取多张券的情形。因此统一领券接口需要支持用户一键领券，除了领取同一券模板的多张，也支持领取不同券模板的多张。一般来说，一键领取多张券指领取不同券模板的多张。在实现过程中，需要注意以下几点：
1）如何保证性能
领取多张券，如果每张券分别进行校验、库存扣减、入库，那么接口性能的瓶颈卡在券的数量上，数量越多，性能直线下降。那么在券数量多的情况下，怎么保证高性能呢？主要采取两个措施：
a. 批量操作。
从发券流程来看，瓶颈在于券的入库。领券是实时的（异步的话，不能实时将券发到用户账户下，影响到用户的体验还有券的转化率），券越多，入库时与数据库的 IO 次数越多，性能越差。批量入库可以保证与数据库的 IO 的次数只有一次，不受券的数量影响。如上所述，用户优惠券数据做了分库分表，同一用户的优惠券资产保存在同一库表中，因此同一用户可实现批量入库。
b. 限制单次领券数量。
设置阀值，超出数量后，直接返回，保证系统在安全范围内。
2）保证高并发情况下，用户不会超领
假如用户在商城发起请求，一键领取 A/B/C/D 四张券，同时活动系统给用户发放券 A，这两个领券请求是同时的。其中，券 A 限制了每个用户只能领取一张。按照前述采用分布式锁保证校验的准确性，两次请求的分布式锁的 key 分别为：
用户 id+A_id+B_id+C_id+D_id
用户 id+A_id
这种情况下，两次请求的分布式锁并没有发挥作用，因为锁 key 是不同，数量校验依旧存在错误的可能性。为避免批量领券过程中用户超领现象的发生，在批量领券过程中，对分布锁的获取进行了改造。上例一键领取 A/B/C/D 四张券，需要批量获取 4 个分布式锁，锁 key 为：
用户 id+A_id
用户 id+B_id
用户 id+C_id
用户 id+D_id
获取其中任何一个锁失败，即表明此时该用户正在领取其中某一张券，需要自旋等待（在超时时间内）。获取所有的分布式锁成功，才可以进行下一步。
接口幂等性
统一领券接口需保证幂等性（幂等性：用户对于同一操作发起的一次请求或者多次请求的结果是一致的）。在网络超时、异常情况下，领券结果没有及时返回，业务方会进行领券重试。如果接口不保证幂等性，会造成超发。幂等性的实现有多种方案，优惠券系统利用数据库的唯一索引来保证幂等。
领券最早是不支持幂等性的，表设计没有考虑幂等性。
那么第一个需要考虑的问题：在哪个表来添加唯一索引呢？
无非两种方案：现有的表或者新建表。
采用现有的表，不需要增加表的关联。但如上所述，因为做了分库分表，大量的表需要添加唯一字段，并且需要兼容历史数据，需要保证历史数据新增字段的唯一性。
采用新建表这种方式，不需要兼容历史数据，但缺陷也很明显，增加了一层表的关联，对性能和现有逻辑都有很大影响。综合考虑，我们选取了在现有表添加唯一字段这种方式，这样更利于保证性能和后续的维护性。
第二个考虑的问题：怎么兼容历史数据和业务方？历史数据增加了唯一字段，需要填入唯一值，不然无法添加唯一索引。我们采用脚本刷数据的方式，构造唯一值并刷新到每一行历史数据中。优惠券已对接的业务方没有传入唯一编码，针对这种情况，优惠券侧生成唯一编码作为替代，保证兼容性。
定向发券用于运营在后台针对特定人群进行发券。定向发券可以弥补用户主动领券，人群覆盖不精准、覆盖面不广的问题。通过定向发券，可以精准覆盖特定人群，提高下单转化率。在大促期间，大范围人群的定向发券还可以承载活动 push 和降价促销双重任务。
定向发券主要在于人群的圈选和发券流程的设计，整体流程如下：
定向发券不同于用户主动领券，定向发券的量通常会很大（亿级）。为了支撑大批量的定向发券，定向发券做了一些优化：
1）去除事务。事务逻辑过重，对于定向发券来说没必要。发券失败，记录失败的券，保证失败可以重试。
2）轻量化校验。定向发券限制了券类型，通过限制配置的方式规避需严格校验属性的配置。不同于用户主动领券校验逻辑的冗长，定向发券的校验非常轻量，大大提升发券性能。
3）批量插入。批量券插入减少数据库 IO 次数，消除数据库瓶颈，提升发券速度。定向发券是针对不同的用户，用户优惠券做了分库分表，为了实现批量插入，需要在内存中先计算出不同用户对应的库表后缀，数据归集后再批量插入，最多插入 M 次，M 为库表总个数。
4）核心参数可动态配置。比如单次发券数量，单次读库数量，发给消息中心的消息体包含的用户数量等，可以控制定向发券的峰值速度和平均速度。
站外营销券的发放方式与其他券不同，通过券码进行兑换。券码由后台导出，通过短信或者活动的方式发放到用户，用户根据券码兑换后获取相应的券。券码的组成有一定的规则，在规则的基础上要保证安全性，这种安全性主要是券码校验的准确性，防止已兑换券码的再次兑换和无效券码的恶意兑换。
优惠券商城怎么建设 第9篇
系统默认使用面额最大的优惠券，若金额相同，则先使用先过期的。需要列出用户拥有的所有优惠券，用户可自由选择可适用的券，不能用的券置灰不可选，靠后展示。
优惠券商城怎么建设 第10篇
一般是在店铺主页、商品详情页、促销活动页中展示，用户需要领取才能到账，形式可以是在详情页无成本领取，也可以是将优惠券与活动相关联，如抽奖活动、签到活动等，利用大额优惠券吸引用户活跃，通过任务和优惠券促进用户转化，并且这类优惠券的感知和触达率会更高。
需要考虑的是，系统发放的优惠券，要通过不同形式的消息提醒来告诉用户——“你做什么可以获得优惠券”“你已经有优惠券了，快去使用吧”，提醒手段有两种：
优惠券使用涉及到前后台，前台主要是下单流程的展示、后台主要是订单系统。
优惠券商城怎么建设 第11篇
在核心支付链路上，列表页、商详页、购物车、收银台、支付完成页、评价页，均可以展现优惠券领取入口，提高优惠券的曝光量。
4）活动领取—定时抢券
我们来讲一个案例：双11大促，老板给你定了几个KPI，分别是
遇到这种情况你该怎么办？方法之一是引入定时抢券的玩法，其好处有下： 5）活动领取—瓜分优惠券
相信小伙伴们经常会看见饿了么与美团的外卖红包，第X个人领取最大的红包。我们称这种形式为瓜优惠券，其领取流程见下 产品逻辑：