fix img

专栏/ZooKeeper源码分析与实战-完/19 Observer 的作用与 Follow 有哪些不同？.md.html

@@ -199,7 +199,7 @@ function hide_canvas() {
 <p>在 ZooKeeper 集群服务运行的过程中，Observer 服务器与 Follow 服务器具有一个相同的功能，那就是负责处理来自客户端的诸如查询数据节点等非事务性的会话请求操作。但与 Follow 服务器不同的是，<strong>Observer 不参与 Leader 服务器的选举工作，也不会被选举为 Leader 服务器</strong>。</p>
 <p>在前面的课程中，我们或多或少有涉及 Observer 服务器，当时我们把 Follow 服务器和 Observer 服务器统称为 Learner 服务器。你可能会觉得疑惑，Observer 服务器做的事情几乎和 Follow 服务器一样，那么为什么 ZooKeeper 还要创建一个 Observer 角色服务器呢？</p>
 <p>要想解释这个问题，就要从 ZooKeeper 技术的发展过程说起，最早的 ZooKeeper 框架如下图所示，可以看到，其中是不存在 Observer 服务器的。</p>
-<p><img src="assets/Ciqc1F8FnKWAQEJJAADU9xFvIIU685.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8FnKWAQEJJAADU9xFvIIU685.png" alt="png" /></p>
 <p>在早期的 ZooKeeper 集群服务运行过程中，只有 Leader 服务器和 Follow 服务器。不过随着 ZooKeeper 在分布式环境下的广泛应用，早期模式的设计缺点也随之产生，主要带来的问题有如下几点：</p>
 <ol>
 <li>随着集群规模的变大，集群处理写入的性能反而下降。</li>
@@ -209,7 +209,7 @@ function hide_canvas() {
 <p>正因如此，随着集群中 Follow 服务器的数量越来越多，一次写入等相关操作的投票也就变得越来越复杂，并且 Follow 服务器之间彼此的网络通信也变得越来越耗时，导致随着 Follow 服务器数量的逐步增加，事务性的处理性能反而变得越来越低。</p>
 <p>为了解决这一问题，在 ZooKeeper 3.6 版本后，ZooKeeper 集群中创建了一种新的服务器角色，即 Observer——观察者角色服务器。Observer 可以处理 ZooKeeper 集群中的非事务性请求，并且不参与 Leader 节点等投票相关的操作。这样既保证了 ZooKeeper 集群性能的扩展性，又避免了因为过多的服务器参与投票相关的操作而影响 ZooKeeper 集群处理事务性会话请求的能力。</p>
 <p>在引入 Observer 角色服务器后，一个 ZooKeeper 集群服务在部署的拓扑结构，如下图所示：</p>
-<p><img src="assets/Ciqc1F8FnLGAKhD0AAE5oGBLTTQ439.png" alt="image" /></p>
+<p><img src="assets/Ciqc1F8FnLGAKhD0AAE5oGBLTTQ439.png" alt="png" /></p>
 <p>在实际部署的时候，因为 Observer 不参与 Leader 节点等操作，并不会像 Follow 服务器那样频繁的与 Leader 服务器进行通信。因此，可以将 Observer 服务器部署在不同的网络区间中，这样也不会影响整个 ZooKeeper 集群的性能，也就是所谓的跨域部署。</p>
 <h3>底层实现</h3>
 <p>介绍完 Observer 的作用和原理后，接下来我们再从底层代码的角度去分析一下 ZooKeeper 是如何实现一个 Observer 服务器的。</p>