From 0b39251dec0d5118b52ef170e82e31484db3a5db Mon Sep 17 00:00:00 2001 From: Xargin Date: Tue, 3 Jul 2018 12:11:37 +0800 Subject: [PATCH] update dj --- ch6-cloud/ch6-10-delay-job.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ch6-cloud/ch6-10-delay-job.md b/ch6-cloud/ch6-10-delay-job.md index 523857b..53101ad 100644 --- a/ch6-cloud/ch6-10-delay-job.md +++ b/ch6-cloud/ch6-10-delay-job.md @@ -117,3 +117,5 @@ Go 自身的 timer 就是用时间堆来实现的，不过并没有使用二叉 2. 对用户预先配置的回调函数进行调用。 两种方案各有优缺点，如果采用 1，那么如果消息队列出故障会导致整个系统不可用，当然，现在的消息队列一般也会有自身的高可用方案，大多数时候我们不用担心这个问题。其次一般业务流程中间走消息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成，那么采用消息队列就会有一定的风险。如果采用 2，会加重定时任务系统的负担。我们知道，单机的 timer 执行时最害怕的就是回调函数执行时间长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然是适用的。一个不负责任的业务回调可能就会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。 + +## 幂等考量