业务系统--------(入队)--------->消息队列---------(出队)--------->队列处理系统
作用:
1.解耦
2.流量削峰
3.异步通信
4.扩展性
5.排序保证
队列介质:
MySQL:容易实现、可靠性高、速度慢;
Redis:速度快、单条大消息包效率低;
消息系统(RabbitMQ):专业性强、可靠、学习成本高;
触发机制:
死循环读取方式:容易实现、故障时无法恢复;
定时任务:压力均分、有处理量上限;
守护进程:类似于PHP-FPM和PHP-CG,需要Shell基础
案例
队列处理订单系统和配送系统
订单系统系统=业务系统
配送系统=消息处理系统
架构设计如下
一、使用MySQL数据库存储消息队列
简单来说,就是每产生一个订单,就把新生成的订单数据塞进事先设计好的数据表中,数据表的具体设计这里就不多说了,看业务具体需求吧。这个用于存储消息队列数据表我们这里先命名为Order_queue。
但这个Order_queue数据表有一个字段不能省略,就是订单处理的标记字段,配送系统每处理完成Order_queue数据表中的一条记录都要对这条记录做标记,说明是已经处理过的。当然,如果想对这个过程进一步细化,也可以为这个字段设定一些状态码,比如:1表示配送系统正在处理订单,2表示配送系统已经处理完成订单……
这些是基本的处理思路,但是还少了一样东西,那就是定时执行脚本,配送系统每隔多长时间从消息队列中取出数据?每次取出的数据条数是多少呢?这就要看定时执行脚本是怎么写的了。一般来说,如果是linux系统,这个定时执行脚本是Shell脚本,利用linux系统的定时机制来触发。
这个方式虽然实现了消息队列,但是我们都知道从磁盘中I/O数据的性能是很低的,相对于内存来说。所以,我们需要一种更为高效的工具来实现消息队列,也就是Redis服务器。
二、使用Redis缓存服务器存储消息队列
这个缓存服务器有好几种数据结构,但是这个应用场景只用到了它的List数据结构。它基于内存存储消息队列,相比于另一款缓存服务器Memcache多了很多种数据结构,更重要的是,它具备容灾性,一旦系统断电,数据在其磁盘中还有备份,用户下的订单不会突然消失。
就本例来说,上文已经介绍过了,思路是一样的。转到Redis后也只是存储介质不同,在读写数据时会快很多,其他的没啥不同。但Redis除了能够应用于以上业务场景,还能应用于MySQL队列难以应付的场景。
该缓存服务器对List数据结构的操作API这里就不多说了,网上一查到处都是。
使用Redis缓存搭建的系统可以有效实现流量削峰,什么是“流量削峰”?淘宝网的“双十一”一来,在短时间内会有大量的请求涌向服务器,这个时间点的访问量会出现一个峰值,对于服务器而言这就很危险了,随时可能出现宕机。但是如果把这些请求都先存储在Redis服务器中通过一个事先设定的时间间隔来读取这个缓存的消息队列,就可以避免出现访问量峰值。
平时很多网站搞饥饿销售,秒杀抢东西,数十万人几乎在同一时间发出了请求,万一Redis的内存也不够用了怎么办?我们先想想,既然是饥饿营销,那么供应的商品肯定是很有限的。他们的请求会先存入Redis内存中,但是我们不需要存太多的请求,因为商品有限啊,就算存了也没有意义,最后商品不会送到后面的人手上——我们只存储前一千个进入Redis服务器List中的请求,记录下他们的ID值,存入数据库表明已经秒杀成功。这就可以了。
三、使用消息队列系统RabbitMQ存储消息队列
这里先占坑,隔日更新。