thinkphp-queue解析

Author: coolseven

thinkphp-queue/README.md

@@ -11,7 +11,7 @@
 - **允许延后|异步|并行处理** （相对于传统的 **即时|同步|串行** 的执行方式）
   - **允许延后**：
 
-    抢购活动时，先缓冲有限的参与人数到消息队列，后续再异步处理实际的活动业务；
+    抢购活动时，先快速缓冲有限的参与人数到消息队列，后续再排队处理实际的抢购业务；
 
   - **允许异步**：
 
@@ -36,7 +36,7 @@ thinkphp-queue 内置了 **Redis**，**Database**，**Topthink** ，**Sync**这
 
 注1：如无特殊说明，下文中的 ‘消息’ 和 ‘任务’两个词指代的是同一个概念，即队列中的一个成员。该成员对消息队列而言是其内部保存的消息； 对业务应用而言是一个待执行的任务。请根据语境区分。
 
-注2：本文编写时(2017-02-15)使用的 thinkphp-queue 的版本号是 v1.1.2 。该版本中部分功能并未全部完成，如 subscribe 模式，以及存在某些小bug(稍后会提及)。如有变更，请以官方最新版为准。
+注2：本文编写时(2017-02-15)使用的 thinkphp-queue 的版本号是 v1.1.2 。该版本中部分功能并未全部完成，如 subscribe 模式，以及存在几个bug(稍后会提及)。如有变更，请以官方最新版为准。
 
 
 
@@ -392,13 +392,13 @@ php think queue:work --queue helloJobQueue
   - 任务数量较多
   - 性能要求较高
   - 任务的执行时间较短
-  - 消费者类中不存在死循环，sleep() ，exit() ,die() 等容易导致bug的逻辑
+- 消费者类中不存在死循环，sleep() ，exit() ,die() 等容易导致bug的逻辑
 
   listen命令的适用场景是：
 
-  - 任务数量较少
-  - 任务的执行时间较长(如生成大型的excel报表等)，
-  - 任务的执行时间需要有严格限制
+- 任务数量较少
+- 任务的执行时间较长(如生成大型的excel报表等)，
+    - 任务的执行时间需要有严格限制
 
 
 #### 2.4 消息队列的开始，停止与重启
@@ -863,7 +863,7 @@ public function failed($jobData){
 
 -   **3.6.2** 使用了 `queue:work --daemon` ，但更新代码后没有使用 `queue:restart` 重启 work 进程, 使得 work  进程中的代码与最新的代码不同，出现各种问题。
 
--   **3.6.3** 使用了 `queue:work --daemon` ，但是消费者类的 fire() 方法中存在死循环，或 `sleep(n)` 等逻辑，导致消息队列被堵塞；或者使用了 `exit()` , `die()` 这样的逻辑，导致work进程直接终止 。
+-   **3.6.3** 使用了 `queue:work --daemon` ，但是消费者类的 fire() 方法中存在死循环，或 `sleep(n)` 等逻辑，导致消息队列被堵塞；或者使用了 `exit()` , `die()` 这样的逻辑，导致work进程直接终止 。
 
 -   **3.6.4** 配置的 expire 为 `null` ，这时如果采用的是 Redis 驱动且使用了延迟功能，如 `later(n)`  ， `release(n)` 方法或者 `--delay` 参数不为0 ， 那么将导致被延迟的任务永远无法处理。(这个可能属于框架的[Bug](https://github.com/top-think/think-queue/issues/12))
 
@@ -873,7 +873,6 @@ public function failed($jobData){
 
 -   **3.6.7** 使用 `Queue::push($jobHandlerClassName , $jobData, $jobQueueName );` 推送任务时，`$jobData` 中包含未序列化的对象。这时，在消费者端拿到的 `$jobData ` 中拿到的是该对象的public 属性的键值对数组。因此，需要在推送前手动序列化对象，在消费者端再手动反序列化还原为对象。
 
-    
 
 ### 四 拓展