update dj

ch6-cloud/ch6-10-delay-job.md

@@ -119,3 +119,7 @@ Go 自身的 timer 就是用时间堆来实现的，不过并没有使用二叉
 两种方案各有优缺点，如果采用 1，那么如果消息队列出故障会导致整个系统不可用，当然，现在的消息队列一般也会有自身的高可用方案，大多数时候我们不用担心这个问题。其次一般业务流程中间走消息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成，那么采用消息队列就会有一定的风险。如果采用 2，会加重定时任务系统的负担。我们知道，单机的 timer 执行时最害怕的就是回调函数执行时间长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然是适用的。一个不负责任的业务回调可能就会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。
 
 ## rebalance 和幂等考量
+
+当我们的任务执行集群有机器故障时，需要对任务进行重新分配。按照之前的求模策略，对这台机器还没有处理的任务进行重新分配就比较麻烦了。如果是实际运行的线上系统，还要在故障时的任务平衡方面花更多的心思。比如将节点划分为协调节点和任务执行节点。由协调节点负责故障时的丢失任务平衡工作。
+
+之前提到我们会用 MQ 触发对用户的通知，在使用 MQ 时，很多 MQ 是不支持 exactly once 的语义的，这种情况下我们需要让用户自己来负责消息的去重或者消费的幂等处理。