diff --git a/ch6-cloud/ch6-10-delay-job.md b/ch6-cloud/ch6-10-delay-job.md
index 1162e49..523857b 100644
--- a/ch6-cloud/ch6-10-delay-job.md
+++ b/ch6-cloud/ch6-10-delay-job.md
@@ -102,3 +102,18 @@ Go 自身的 timer 就是用时间堆来实现的，不过并没有使用二叉
 除了这种单层时间轮，业界也有一些时间轮采用多层实现，这里就不再赘述了。
 
 ## 任务分发
+
+有了基本的 timer 实现方案，如果我们开发的是单机系统，那么就可以撸起袖子开干了，不过本章我们讨论的是分布式，距离“分布式”还稍微有一些距离。
+
+我们还需要把这些“定时”或是“延时”(本质也是定时)任务分发出去。下面是一种思路：
+
+![task-dist](../images/ch6-task-sched.png)
+
+每一个实例每隔一小时，会去数据库里把下一个小时需要处理的定时任务捞出来，捞取的时候只要取那些 task_id % shard_count = shard_id 的那些 task 即可。
+
+当这些定时任务被触发之后需要通知用户侧，有两种思路：
+
+1. 将任务被触发的信息封装为一条 event 消息，发往消息队列，由用户侧对消息队列进行监听。
+2. 对用户预先配置的回调函数进行调用。
+
+两种方案各有优缺点，如果采用 1，那么如果消息队列出故障会导致整个系统不可用，当然，现在的消息队列一般也会有自身的高可用方案，大多数时候我们不用担心这个问题。其次一般业务流程中间走消息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成，那么采用消息队列就会有一定的风险。如果采用 2，会加重定时任务系统的负担。我们知道，单机的 timer 执行时最害怕的就是回调函数执行时间长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然是适用的。一个不负责任的业务回调可能就会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。
diff --git a/images/ch6-task-sched.png b/images/ch6-task-sched.png
new file mode 100644
index 0000000..948123a
Binary files /dev/null and b/images/ch6-task-sched.png differ