优惠券优化技术方案

优惠券优化技术方案

一、现状

业务背景

随着业务的不断扩展，业务计划将其与服务进行整合。在这一过程中，C端用户通过小程序租赁电动车后，很可能会产生购买意愿。为了更好地支持和促进用户的购买行为，租车业务将把用户的租赁信息实时同步至商城，商城主动向用户发放购车优惠券。为了进一步提升业务效率和用户体验，我们计划对现有的优惠券发放、核销及查询流程进行一次全面的升级和优化。
为此，我们亟需设计并优化当前商城的优惠券功能，该功能需能够稳定支持高达百级QPS的业务需求。还需要全面覆盖优惠券的整个生命周期管理，确保优惠券的发放、使用和查询等各个环节都能高效、顺畅地进行。
需求

要配置券，会涉及到券批次（券模板）创建，券模板的有效期以及券的库存信息
要发券，会涉及到券记录的创建和管理（过期时间，状态）
业务需求

要配置券，会涉及到券批次（券模板）创建，券模板的有效期以及券的库存信息
要发券，会涉及到券记录的创建和管理（过期时间，状态）

二、方案描述

系统选型及中间件
确定了基本的需求，我们根据需求，进一步分析可能会用到的中间件，以及系统整体的组织方式。

存储
由于券模板、券记录这些都是需要持久化的数据，同时还需要支持条件查询，所以我们选用通用的结构化存储 MySQL 作为存储中间件。

缓存
由于发券时需要券模板信息，大流量情况下，不可能每次都从 MySQL 获取券模板信息，因此考虑引入缓存同理，券的库存管理，或者叫库存扣减，也是一个高频、实时的操作，因此也考虑放入缓存中主流的缓存 Redis 可以满足我们的需求，因此我们选用 Redis 作为缓存中间件。

消息队列
由于券模板/券记录都需要展示状态，并且根据不同的状态进行业务逻辑处理，因此有必要引入消息队列来对券模板/券状态进行处理。RocketMQ 支持消息，因此我们选用 RocketMQ 作为消息队列。
方案
概述
从需求拆解部分我们对大致要开发的系统有了一个了解，下面给出整体的一个系统架构，包含了一些具体的功能。
详细说明
系统整体架构图

数据库设计
coupon
id
primary key
create_by
create_time
delete_flag
update_by
update_time
end_time
promotion_name
store_id
store_name
start_time
consume_thresho
coupon_discount
coupon_limit_nu
coupon_name
coupon_type
description
get_type
price
publish_num
received_num
scope_id
scope_type
store_commissio
used_num
range_day_type
effective_days
parent_id
channel_code
coupon_record
id
coupon_id
member_id
status
receive_no

核心逻辑实现

发券：

发券流程分为三部分：参数校验、幂等校验、库存扣减。
参数校验：校验优惠券状态、优惠券时间、用户优惠券领取、库存校验。
幂等操作用于保证发券请求不正确的情况下，业务方通过重试、补偿的方式再次请求，可以最终只发出一张券，防止资金损失。
券过期：
券过期是一个状态推进的过程，这里使用 RocketMQ 来实现。
库存扣减：
redis扣减-成功或库存不足
性能目标
需要根据租车用户来对商城性能做出一个评估。
性能一般来说可能包含以下部分：
日平均请求：一般来自产品人员的评估；
平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；
峰值QPS：一般可以以QPS的2~4倍计算；
性能评估
需要根据租车用户来对商城性能做出一个评估。
给出方案的基准数据，并按性能需求评估需要使用的资源数量。
单机并发量
单机容量
按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
业务流程
整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍
模块划分
商品模块：商品会关联优惠券，我们会设置不同的商品使用不同的优惠券
订单模块：订单模块需要根据金额来判断使用不同的优惠券，并在订单全流程展示优惠券。
优惠券模块：优惠券模块分为管理端、管理端主要是查看券列表、查看券领取记录，建券，设置过期时间，C端主要是查看券、领券，使用券，核销券。
会员模块：会员模块需要根据不同的会员展示不同的优惠券。
购物车模块：购物车模块主要是展示优惠券，以及判断优惠券是否失效，是否可用。
异常边界
涉及了哪些模块：优惠券优化涉及优惠券模块、订单模块、商品模块、会员模块、购物车模块、支付模块。
涉及到了哪些流程：
整个电商平台全流程，从会员领取列表，会员领券，商品列表展示，商品详情展示，下单金额限制，支付金额，购物车优惠展示，以及下单后退款，核销完提现全链路流程都需要涉及，所以测试阶段需要对每一步都进行详细的测试。
每个模块、流程出现了各种可能情况的处理是？
系统底层原因导致的异常的处理是 ？
可能会随着用户量增加，导致redis内存不够用，以及C端、consumer端内存告警，需要各种监控告警，来随时发现问题。
统计、监控
线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计
压测
压测是商城上线优惠券模块不可避免的一个环节，通过压测我们能够对服务的整体情况有个明确的了解，并且压测期间暴露的问题也会是线上可能遇到的。

三、风险评估

潜在风险
相关的改动有哪些风险点
因为此次改动在原有基础上进行改动，原数据存储在es上，和商品索引绑定在一个索引上，所以这次需要把优惠券相关信息从商品索引模块拆出来，会有原有的数据结构做一批梳理和优化，可能存在索引问题，需要在测试环境进行大量测试。
潜在有哪些问题

四、工作量评估

工作量评估也是一个重要的环节，这里需要细化到每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间。