PA短信通道限额方案设计

PA短信通道限额方案设计

需求背景

用户在发送短信时，如果短信走的是PA短信通道，则要对其额度进行限制。额度不足时，成功充值后才可继续使用。

设计原则

• 防止超额：对业务来说，超额可能意味着资损；对技术来说，超额意味着架构的失败。试想，短信限额10000条，但是却发出去了30000条，那么我们就会面临严重的客诉或资损；
• 防止余量过剩：与超额相对的是余量过剩，其同样不可小觑。比如，10000条的短信仅有1000条发出去，额度明明还有却已经发不出去，活动未到达预期，前期准备和推广的资金投入都打了水票，而由系统设计缺陷造成的重复扣减 就会导致这种糟糕的情况发生；
• 高性能：即高并发场景下既要精准限额又不能由于短信限额校验导致整个短信发送流程的qps骤降；
• 减缓数据库压力：允许客户查看和统计短信额度消耗明细。正常操作是本批次短信发送成功后就存储数据到短信额度消耗明细表，但此操作在高并发或者百万级精选人群包场景下需要频繁的与数据库交互，这无疑会使数据库压力剧增。

流程设计

数据库设计

t_pa_sms_inventory （短信额度总量表）

列名	数据类型	描述	默认值
id	bigint	自增主键
tenant_id	varchar	租户ID
allocated_num	bigint	预扣短信条数
available_num	bigint	可用短信条数
total_num	bigint	总计短信条数
created_at	timestamp	创建时间	CURRENT_TIMESTAMP
updated_at	timestamp	修改时间	CURRENT_TIMESTAMP
is_deleted	tinyint	是否已删除。可用值：0（否）、1（是）	0

t_pa_sms_quota_log（短信额度使用明细表）

列名	数据类型	描述	默认值
id	bigint	自增主键
tenant_id	varchar	租户ID
biz_id	varchar	预扣短信条数
task_id	varchar	可用短信条数
costed_num	bigint	计费短信条数
costed_date	varchar	计费短信日期
created_at	timestamp	创建时间	CURRENT_TIMESTAMP
updated_at	timestamp	修改时间	CURRENT_TIMESTAMP
is_deleted	tinyint	是否已删除。可用值：0（否）、1（是）	0

解决方案

既要快又要准

判断可用额度和短信发送后扣除额度这两个操作不具备原子性，在高并发场景下可能存在超额问题。采用分布式锁可以完美解决，但是分布式锁会将整个链路串行化，影响短信发送流程的程序性能。

故采用预扣额度概念，将预扣额度+当前预扣额度>可用额度*可超额系数这个操作放到一个lua脚本里面保证原子性运行。

• redis是单线程模型，天然串行化，会串行执行lua脚本，并不会产生高并发问题
• redis虽然是单线程模型，但是其吞吐量可达百万级，故不会对短信发送流程的程序性能造成过大影响

降低数据库交互压力

当前批次短信正常发送结束后，将

• 总可用额度扣除当前批次短信使用额度
• 总预扣额度释放当前批次预扣额度
• 采用滑动时间窗口存储短信额度使用明细

以上三个操作合并至一个lua脚本里面保证原子性。

启动定时任务，每五分钟从滑动时间窗口里面拉取数据落库至短信额度使用明细表中，并同步更新短信额度总量表。

注意事项

1. 当前批次短信发送失败时需要从总预扣额度里面释放掉当前批次的预扣额度

2. 若当前批次短信发送回执结果未消耗短信额度，需要从总预扣额度里面释放掉当前批次的预扣额度

3. 可能存在下述这种临界点场景。可用重试+幂等校验方案解决，但是综合考虑到程序复杂性以及影响范围，此场景允许发生。

   • 任务1进来扣除了预扣额度程序正常运转，但是程序还未流转至任务1消耗可用额度
   • 其他任务过来时判断可用额度不足导致发送失败（此时是虚拟扣除，真实可用额度还未被消耗）
   • 任务1执行过程中出现异常并未真正消耗可用额度

4. lua脚本的执行不支持事务回滚操作，执行过程中出现异常不方便定位和复原数据，综合考虑暂不处理