PHP消息队列
业务系统--------（入队）--------->消息队列---------（出队）--------->队列处理系统
作用：
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存储消息队列
这里先占坑，隔日更新。