关于定时发短信业务的讨论

事情的原由

需求：在每次线下活动的开始的前一天晚上七点给报名参加价值研习社的用户发一条通知短信用户记得准时参加活动。

备注：由于咱们的业务并发不是很大，因此不少场景并无考虑到并发状况下的一些问题，这个需求正好经过crontab执行，而且加上服务器的自动弹性伸缩，因此至关于模拟了一次并发的业务场景。

先简单介绍一下数据库的表结构：

这几个方案都依赖天天晚上七点执行一次corntab。

方案1

根据开讲时间查询活动表是否有知足条件的线下活动，若是有的话，再经过活动id关联到签到表过滤出send_sms字段为0的uid并关联用户表拿出手机号等信息。发送完成后再统一更新send_sms字段。

缺点：在并发业务场景下，可能会产生脏读的状况，形成发送屡次短信的状况。

方案2

与方案1很类似，惟一的区别就是查询的时候开启事务用SELECT ... FOR UPDATE ，这种查询语句的区别就是在SELECT的时候把结果行上锁，从而就能避免脏读，而后再同一个事务中UPDATE send_sms字段，最后commit 。

缺点：因为发短信不是数据库操做，不可回滚。因此若是执行的过程当中发生回滚，就会出现短信已经发出去了，可是数据库发生回滚，send_sms字段置为了0，这就产生了矛盾。并且若是是个耗时的任务可能会出现死锁的问题。

如下就是执行的逻辑

BEGIN;
SELECT ... FOR UPDATE;
UPDATE ... SET send_sms = 1;
COMMIT;
复制代码

方案3

与方案2很类似，惟一的区别就是一条一条的取数据上锁，而后更新send_sms字段。

缺点：要写一个循环一直去查询知足条件但还未发送短信的用户。处理很差容易产生死循环以及死锁的问题。

方案4

这是我目前能想到的最佳方案，直接用SELECT语句选出全部知足条件的手机号码以及短信内容，放入Queue中，而后实现对Queue的处理。处理以下：先用SELECT ... FOR UPDATE 判断send_sms字段的值，若是为0，那就执行发短信，而后更新send_sms字段为1，最后COMMIT 。这样就能够避免屡次执行发短信。

总结：对于这种对实时性要求没那么高的业务场景用Queue 仍是很是便利的，让Queue 一条一条的处理，在复杂的系统中还起到了削峰和解耦的做用。你们在工做中有哪些对Queue的应用呢？欢迎留言，一块儿讨论！

你们对上面的这些方案有什么建议呢？欢迎留言讨论！