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

事情的起因

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

备注：因为我们的业务并发不是很大，所以很多场景并没有考虑到并发情况下的一些问题，这个需求正好通过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的应用呢？欢迎留言，一起讨论！

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

原文地址：https://www.cnblogs.com/techcoder/p/11327113.html