相信大家对优惠券都不陌生，特别是在现在这个互联网特别发达的时代，优惠券是运营推广营销的一种工具，它可以降低产品的价格，是一种常见的消费者营业推广工具， 作为一种信息的载体，它不仅仅是一种表现的手段，其背后是运营策略的有效实现。
业务架构
从优惠券的业务属性上来说，每个平台都离不开优惠券，优惠券又分为平台券和店铺券，在此之上券类型分为折扣券、满减券以及立减券。当然，优惠券的领取和使用同样具有限制，详情如下：
下方的业务架构图全面描述了项目的服务集合、组件库列表和基础设置层等要素
技术架构
基于 Spring Boot 3 和 JDK17 进行底层建设，同时组件库的版本大多也是最新的。这样做既能享受新技术带来的性能提升，也能体验到新特性带来的惊喜。如果用一张图来概括牛券的技术架构，其展现形态如下图所示。
技术架构涵盖了 SpringBoot 3、SpringCloudAlibaba、Nacos、Sentinel、Skywalking、RocketMQ 5.x、ElasticSearch、Redis、MySQL、EasyExcel、XXL-Job、Redisson 等技术。
框架技术和版本号关系如下表格所示。
优惠券秒杀
1、全局唯一ID
场景一分析：id如果增长规律归于明显，容易被用户或者商业对手猜测出一些敏感信息，比如早上出的第一个单子的id是1，晚上再查看出的单子的id是1001，那别人就很容易猜测出你这一天的销售情况。
场景二分析：Mysql数据库的由于查询性能的考虑，单表数据量不建议超过500W。数据量更大时，需要进行分库分表，但从逻辑上来讲这两张表是同一个表，需要保证id的唯一性，增添了一定的维护成本。
2、实现优惠券秒杀下单
秒杀需要思考的点：秒杀活动是否开始或结束 库存是否足够
3、超卖问题
超卖问题原因分析：假设线程1过来查询库存，判断出来库存大于1，正准备去扣减库存，但是还没有来得及去扣减，此时线程2过来，线程2也去查询库存，发现这个数量一定也大于1，那么这两个线程都会去扣减库存，最终多个线程相当于一起去扣减库存，此时就会出现库存的超卖问题。
4、一人一单
需求：要求一个用户只能购买一张秒杀券
目前存在的问题：一个用户可以无限制次数的抢优惠券。应当加一层判断逻辑，当用户成功下完单后，不允许其再次抢优惠券。
判断逻辑：查询该用户和优惠券在订单表里是否已经存在，如果存在，说明其之前已经抢过优惠券了
创建优惠券模板
以创建优惠券模板举例，这是商家用户在后管平台里简单的一个创建流程，基本上算不上并发，但是会涉及到责任链设计模式、优雅记录操作日志、缓存预热等逻辑。
分库分表
现阶段但凡上点体量的公司，都得在分库分表和分布式数据库上进行抉择。相对于分布式数据库而言，我个人认为可能会有以下的不足，以下说法谨代表我个人看法：
兼容性：部分分布式数据库并不能 100%兼容 MySQL，导致业务无法平滑迁移。
技术储备：需要有这方面的分布式数据库专家，平常使用谁都可以，线上出现了问题不知道怎么解决才是致命。
使用成本：阿里云和腾讯云没有开源版本，付费版本相对于 MySQL 成本偏高。TiDB 开源版本 Issue BUG 较多，商业未知。
所以，类似于以 ShardingSphere 为代表的分库分表框架依然抗打。
防重复提交
如果涉及到多场景通用代码，写到业务里只是第一步，更重要的是能够掌握抽象的能力，SpringAOP 和注解相关的知识就必不可少。
项目结构
采用标准基于 Maven 的 SpringBoot 多 Modules 项目，并拆分通用基础组件避免技术类重复定义。定义的包结构是适用于绝大部分场景
总结
优惠券是个非常有效的引流工具，不仅能够提高老用户拉新的传播能力，也能一定程度地提高转化率，它自带的优点就是领取了优惠券后，券后的价格使得商品更加的便宜，所以，作为优惠券自身就是对推广很有帮助的，我们可以利用这些看得见的便宜，将商品推广出去，让用户看到，激发用户购买的欲望
Thank you for reading.
推荐阅读
• 前端埋点
欢迎关注我的公众号“全栈开发ck”，原创技术文章第一时间推送。
