早些时候，一直有个疑问，就是比如你从前端发一个操作之后，后台为什么能够及时处理你的东西呢？当然了，我说的不是，服务器为什么能够立即接收到你的请求之类高大上的东西。而是，假设你用异步去做一个事情，而后台有一个处理程序在处理你的申请，你的目的自然是不想让操作阻塞，所以处理肯定是处理程序主动触发的过程。那么怎样做能够让其能够及时处理问题呢？ 确实也困惑了我许久。（我相信也有不少同学会有类似疑问）
所以我觉得有必要解解惑。
需求示例1： 用户请求某操作时，需要与此同时给用户发个邮件，但是这个邮件可能会很耗时，在不使用异步线程的情况下（事实上不是所有的语言都支持多线程），怎么样让用户得到快速响应，且邮件稍后即可送达？
需求示例2：在高并发情况下，需要对某数据进行减操作（比如商品库存，如果超出了库存值，则将无货可发），怎样保证用户先到先得，后到就没有？
针对这两个问题，解决办法自然是多的。但是本文只说一个思路，那就是主题，消息队列！
当需要给用户发送邮件时，只需将该请求发送到后台进程中，后台进程进行逐个发送即可。
当大量用户进来抢商品时，将该请求放入队列中，后台进程逐个相减，减到0时，后续用户将提示抢不到了。（当然，这有很多后续问题要处理，也看起来不一定是个好方案，但并不影响咱们发挥）
看起来，前面的解决方案很合理。但是，具体怎么样做呢？前台申请，与后台处理之间，总得有个什么东西联系起来吧。没错，就是消息队列了。消息队列自然需要消息中间件，简单的，咱们就使用redis做中间件吧，简单快速搞得定。
具体实施方案就是：1. 各处的用户进行相应的操作请求，然后顺便将消息写入redis，（以list形式写入，天然的队列）； 2. 后台进程依次从redis中读取消息，进行相应数据处理（注意如何依次处理是关键）。 3. 将结果通知给用户或者不通知。（本处将不通知）
示例代码如下（php实现）：
<?php
// send 请求方，写入消息
$redis = new Redis();
$redis->connect("127.0.0.1", "6379", 3); $msgKey = "my.test.msgKey";
$value = "hello,world." . rand(0, 99999999);
$redis->lPush($msgKey, $value); // 将请求送入队列中，等后台消费
echo "lPush {$msgKey} -> {$value}";
后台进程进行依次处理，一般来说有两个方案： 1. 通过系统进行定时调度，每次调度，则执行一段消息处理（此种方案的缺点明显，需依赖系统处理，且将会是不及时的）； 2. 通过自身调度，使自己一直处理运行中状态，当发现有新消息到来时，立即进行处理（本处讨论的是此种方案）。处理代码如下：
<?php
// recieve 处理程序
$redis = new Redis();
$redis->connect("127.0.0.1", "6379", 3); $msgKey = "my.test.msgKey"; while(true) {
$stackTop = $redis->rPop($msgKey);
if($stackTop) {
// do sth useful
echo $stackTop . "\r\n";
} else {
usleep(200000); // 如果没有消息需要处理，则睡眠0.2秒等待
}
}
写好后，只要在命令行将该脚本跑起来即可：
php recieve.php &
其实原理很简单，就是一个while死循环，然后一直在查询 消息状态，有就处理，没有就稍微等一下再查。
如果启动多个后台程序，那么，就相当于有多个消费者了，从而加快了处理速度。（生产者 -> 消费者 简单模型）
那么，问题在哪里？为什么刚开始的时候没想到这样处理呢？
我有两个疑问：
1. 用户while死循环不会导致死机吗？
2. 我想修改代码里的东西，怎样才能生效？
针对第一个问题，如果是没有 sleep 限制的话，机器是有可能死机的。在调用 sleep后，cpu会转到其他进程上进行事务处理，从而不会有问题。sleep时间过长，则会有明显的时间停顿现象，即用户操作无法得到及时响应。sleep时间过短，则会导致cpu占用过高，从而引发其他一系列问题。因此设置一个合适的sleep时间是有必要的。本处设置的0.2秒，经查看cpu状态，占用为0%，所以没问题。而且0.2秒在用户看来，是没有什么影响的。
第二个问题，修改了代码，如何生效？重启就好了嘛。
ps -ef | grep php # 找出运行代码的pid
kill - # 将进程kill掉
php recieve.php # 重新运行代码即可
通过该种自身轮询的方式，从而达到了及时处理任务的方式。
死循环广泛应用于各服务中，只是我们都没发现。
这也换一个现实的问题角度理解，只有自己一直活着，才有可能服务于别人。
那么，假如每个程序跑起来后，都一直存活着，CPU不就完蛋了？ 是的，这就是计算机所能运行的服务有限的原因。CPU可以调度各进程的执行，当然进程数是有限的，只要在这有限有量以内，提供几个死循环还是可以的。（注意，死循环是保持自身活跃的一种方式，但并非所有的服务都是靠死循环来保持自身的活跃的）
信号量？是一种有效地处理本机通知的一种机制，且听下回分解。