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

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《关于定时发短信业务的讨论》，介绍一下MySQL，希望对大家的知识积累有所帮助，助力实战开发！

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

事情的起因

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

备注：因为我们的业务并发不是很大，所以很多场景并没有考虑到并发情况下的一些问题，这个需求正好通过crontab执行，并且加上服务器的自动弹性伸缩，所以相当于模拟了一次并发的业务场景。

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

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

方案1

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

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

方案2

与方案1很相似，唯一的区别就是查询的时候开启事务用SELECT ... FOR UPDATE ，这种查询语句的区别就是在

SELECT

UPDATE

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

send_sms

COMMIT

总结：对于这种对实时性要求没那么高的业务场景用

Queue

Queue

Queue

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

以上就是《关于定时发短信业务的讨论》的详细内容，更多关于mysql的资料请关注golang学习网公众号！