早些时候,一直有个疑问,就是比如你从前端发一个操作之后,后台为什么能够及时处理你的东西呢?当然了,我说的不是,服务器为什么能够立即接收到你的请求之类高大上的东西。而是,假设你用异步去做一个事情,而后台有一个处理程序在处理你的申请,你的目的自然是不想让操作阻塞,所以处理肯定是处理程序主动触发的过程。那么怎样做能够让其能够及时处理问题呢? 确实也困惑了我许久。(我相信也有不少同学会有类似疑问)
所以我觉得有必要解解惑。
需求示例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 -9 123 # 将进程kill掉 php recieve.php # 重新运行代码即可
通过该种自身轮询的方式,从而达到了及时处理任务的方式。
死循环广泛应用于各服务中,只是我们都没发现。
这也换一个现实的问题角度理解,只有自己一直活着,才有可能服务于别人。
那么,假如每个程序跑起来后,都一直存活着,CPU不就完蛋了? 是的,这就是计算机所能运行的服务有限的原因。CPU可以调度各进程的执行,当然进程数是有限的,只要在这有限有量以内,提供几个死循环还是可以的。(注意,死循环是保持自身活跃的一种方式,但并非所有的服务都是靠死循环来保持自身的活跃的)
信号量?是一种有效地处理本机通知的一种机制,且听下回分解。