秒杀学姐的MySQL消息队列

秒杀学姐的MySQL消息队列

曾经有人问我使用消息队列的典型场景有哪些，我告诉他精髓在于四个字：『秒杀学姐』。他突然一下子激动起来，接连追问我：『是哪个学姐？身材好不好?』从他的眼神中我看到了探索未知的勇气与渴望，于我郑重地告诉他：『同学，我看你也是求学上进之人，我现场在能告诉你的只有秒杀削解四个字。其它细节，不如你先去文末扫个码，回头我们加好友私下交流如何？』

秒杀，一种短时网促活动。对商家，秒杀是引流秘籍，推广利器；对服务器，秒杀即群殴，抗不住就死；对后端程序员，如何将群殴变成单挑，则是活下去的唯一希望。那什么是削解呢？让我们从年终奖说起。

年关将至，按北京老传统，公司会给大家发点儿年终奖。那么，你会当着财务的面把钱点清楚再签字嘛？当然不会！我们都是先签完字，把钱运回家，然后偷偷点钱的。要不然你在财务室点钱花了一个小时，这让门口等待的其它兄弟多尴尬。

削：即削峰填谷。当上游服务瞬时请求量很大时，为了保证服务体验，上游服务需要立即返回。特别是当下游服务的处理速度较慢时，上游服务来不及等待下游服务处理完成。这种场景现实中有很多，比如秒杀、抢购、群发短信邮件。

另外，财务关心什么？财务并不关心你点钱花了多长时间，她们只关心你是否签字画押。因此，咱们回家。。。或者找一个老婆找不到的地方偷偷点完就好（warning：此举可能有生命危险，非专业人士不建议模仿）。

解：即解耦。当上游服务并不关心下游服务处理结果的时候，如果强行等待反而会产生反向依赖。反向依赖会导致两个负面结果，一是下游代码变动可能会胁迫上游服务同步修改，二是延长上游服务的响应时长。

秒杀削解，消息队列都能给我们提供不少帮助。但为什么会有在MySQL中建消息队列需求呢？使用一个正经的消息队列不好嘛？毕竟从rabbit到rocket，都有很好的社区使用经验不是么？你要理解，并不是每个程序员天生都长着一副笑脸的，他们一定是经历某种惨绝人寰成长与思考：

程序员对MySQL更熟悉程序员造轮子是有快感的运维团队经费拮据当前经济形式下滑

好了，前戏做足，是时候脱。。详细讨论一下相关的设计要点了。先上架构装门面：

架构需要同时支持多个消费进程同时消费，各进程间可以互斥地锁定和处理不同的任务。

因而数据库表中需要有一个locked字段表示该任务是否已经被锁定。

二：并发消费

在我们的架构中，提取线程负责批量锁定并获取任务，消费线程池并发执行业务逻辑。必须平衡提取线程与消费线程池之间的速度，否则提取速度过快，同时消化费速度跟不上的话，线程池会因消化不良而撑死。

信号量Semphore是个好东西，便宜又皮实。

三：支持重试

重试是高可用的重要手段之一。当处理业务过程中发生意外时，比如服务器重启、资源获取超时、数据库链接断开等，通过重试可以增加业务处理成功的概率。

因而数据库表中需要一个retry字段记录剩余重试次数。

道路千万条，安全第一条，重试不幂等，准把盒饭领。男人要有责任心，任何没有安全措施的重试都是不负责任的。

四：超时控制

在最坏的情况下，服务器可能在处理业务的过程中意外重启，此时消费线程没有机会重置数据库表中的locked字段。为了能够恢复消费状态，需要一个独立的解锁线程，轮询长时间处于locked状态的任务，并帮助它恢复到可消费状态。

当然，使用MySQL做消息队列也是有缺点的：

首先，速度感人。相对了各家MQ拍胸脯担保的几十万的TPS，MySQL酒后也才敢号称几千，略显业余。其次，顺序消息、事务消息等特殊消息类型在MQ中算基础操作，但在MySQL中则需要更加精巧的设计。

虽然有这些缺点，然而考虑到经济形式还在下滑，仔细想想好像也没那么不容易接受，毕竟合适的才是最好的嘛～

小姿势：

想私下交流更多小姿势的学姐，赶紧扫码了。

学妹也可以

参考文献：

SUBTLE WAYS YOU'RE USING MYSQL AS A QUEUE, AND WHY IT'LL BITE YOU消息队列：秒杀时如何处理每秒上万次的下单请求？经验：一个秒杀系统的设计思考究竟什么时候该使用MQ