update sd

ch5-web/ch5-10-service-discovery.md

@@ -127,7 +127,7 @@ for _, endpoint := range endpointList {
 ```shell
 ls /platform/order-system/create-order-service-http
 
-[]
+['10.1.23.1:1023', '10.11.23.1:1023']
 ```
 
 当与 zk 断开连接时，注册在该节点下的临时节点也会消失，即实现了服务节点故障时的被动摘除。
@@ -136,16 +136,51 @@ ls /platform/order-system/create-order-service-http
 
 ## 基于 zk 的完整服务发现流程
 
-节点故障断开 zk 连接时，zk 会负责将该消息通知所有监听方。
-
 用代码来实现一下上面的几个逻辑。
 
 ### 临时节点注册
 
 ```go
+package main
+
+import (
+    "fmt"
+    "time"
+
+    "github.com/samuel/go-zookeeper/zk"
+)
+
+func main() {
+    c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second)
+    if err != nil {
+        panic(err)
+    }
+
+    res, err := c.Create("/platform/order-system/create-order-service-http/10.1.13.3:1043", []byte("1"),
+        zk.FlagEphemeral, zk.WorldACL(zk.PermAll))
+    if err != nil {
+        panic(err)
+    }
+    println(res)
+    time.Sleep(time.Second * 50)
+}
 ```
 
-### 服务节点获取
+在 sleep 的时候我们在 cli 中查看写入的临时节点数据：
+
+```shell
+ls /platform/order-system/create-order-service-http
+['10.1.13.3:1043']
+```
+
+在程序结束之后，很快这条数据也消失了：
+
+```shell
+ls /platform/order-system/create-order-service-http
+[]
+```
+
+### watch 数据变化
 
 ### 消息通知
 

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

@@ -118,4 +118,4 @@ Go 自身的 timer 就是用时间堆来实现的，不过并没有使用二叉
 
 两种方案各有优缺点，如果采用 1，那么如果消息队列出故障会导致整个系统不可用，当然，现在的消息队列一般也会有自身的高可用方案，大多数时候我们不用担心这个问题。其次一般业务流程中间走消息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成，那么采用消息队列就会有一定的风险。如果采用 2，会加重定时任务系统的负担。我们知道，单机的 timer 执行时最害怕的就是回调函数执行时间长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然是适用的。一个不负责任的业务回调可能就会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。
 
-## 幂等考量
+## rebalance 和幂等考量