然后马小云和马果果收到 UPTODATE 之后会再回复一个 ACK 给马果果，但是这次马果果收到这次的 ACK 之后不会做处理，所以在 UPTODATE 之后，各个办事处就已经算可以正式对外提供服务了。
上面说了这么多，但是马小云和马小腾都是 Follower，如果是 Observer 呢？怎么用上面的步骤同步呢？
区别就在第一步，Follower 发送的是 FOLLOWERINFO，而 Observer 发送的是 OBSERVERINFO 除此之外没有任何区别，和 Follower 是一样的步骤进行数据同步。
二、继续深挖现在把其中的一些细节再用猿话说明一下，三种不同的数据同步策略，Leader 在发送 Follower 的时候采用的具体方法是不太相同的
2.1 三种策略发送方式如果采用的是 DIFF 或者 TRUNC 的同步方法的话，Leader 其实不是在找到有差异数据的时候发送过去的，而是按照顺序先放入一个队列，最后再统一启动一个线程去一个个发送的
DIFF :
TRUNC:
但是以 SNAP 方式同步的话就不会放入该队列，无论是 SNAP 消息还是之后整个序列化后的内存快照 snapshot 都会直接通过服务端间的 socket 直接写入。
2.2 上帝视角让我们把三种策略消息交互的全过程再看一遍，这里就以马小云举例了
2.2.1 DIFF可以看到首尾是一样的，就是中间的请求根据不同的策略会有不同的请求发送。差不多到这里关于 Follower 或 Observer 是如何同 Leader 同步消息，整体的逻辑都介绍完了。
2.3 小结Follower 和 Observer 同步数据的方式一共有三种：DIFF、SNAP、TRUNC
DIFF 需要 Follower 或 Observer 和 Leader 的数据相差在 min 和 max 范围内，或者配置了允许从 log 文件中恢复
TRUNC 是当 Follower 或 Observer 的 zxid 比 Leader 还要大的时候，该节点需要主动删除多余 zxid 相关的数据，降级至 Leader 一致
SNAP 作为最后的数据同步手段，由 Leader 直接将内存数据整个序列化完并发送给 Follower 或 Observer，以达到恢复数据的目的
我看了下文章的字数还行，决定加一点料，开一个小篇讲一下 ACL，这个我拖了很久没解释的坑。
先带大家重拾记忆，之前创建节点代码片段中的 ZooDefs.Ids.OPEN_ACL_UNSAFE 就是 ACL 的参数
client.create("/更新视频/跳舞/20201101", "这是Data，既可以记录一些业务数据也可以随便写".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);首先如果配置了 zookeeper.skipACL 该参数为 yes（注意大小写），表示当前节点放弃 ACL 校验，默认是 no
那这个 ACL 是怎么规定的，有哪些权限，又是怎么在服务端体现的呢？首先 ACL 整体分为 Permission 和 Scheme 两部分，Permission 是针对操作的权限，而 Scheme 是指定使用哪一种鉴权模式，下面我们一起来了解下。
3.1 权限 Permission 介绍首先 ZK 将权限分为 5 种：
READ（以下简称 R），获取节点数据或者获取子节点列表
WRITE（以下简称 W），设置节点数据
CREATE（以下简称 C），创建节点
DELETE（以下简称 D），删除节点
ADMIN（以下简称 A），设置节点的 ACL 权限
然后该 5 种权限在代码层面就是简单的 int 数据，而判断是否有权限只需要用 & 操作即可，和目标权限 & 完结果只要不等于 0 就说明拥有该权限，细节如下：
int binary R 1 00001 W 2 00010 C 4 00100 D 8 01000 A 16 10000假设现在的客户端权限为 RWC，对应的数值就是各个权限相加 1 + 2 + 4 = 7
int binary RWC 7 00111对任意有 R、W、C 权限需求的节点，求 & 的结果都不为 0，所以就能判断该客户端是拥有 RWC 这 3 个权限的。