fix img

专栏/分布式中间件实践之路（完）/06 Redis 实际应用中的异常场景及其根因分析和解决方案.md.html

@@ -455,9 +455,9 @@ if (!del && server.cluster->slots[slot])
 </ol>
 <p>故障点找到了，那么，既然存在故障，为何集群状态显示正常，只有部分读写操作失败呢？有必要解释一下，为了便于阐明问题，我以 3 主 3 备集群为例。</p>
 <p>在前面的章节中，已经介绍了 Redis 集群混合路由查询的原理，在此，直接引用原理示意图，客户端与主节点 A 直连，进行读写操作时，Key 对应的 Slot 可能并不在当前直连的节点上，经过“重定向”才能转发到正确的节点，如下图所示：</p>
-<p><img src="assets/a9a50eb0-3fb4-11e8-9e37-a924cb695a5d" alt="enter image description here" /></p>
+<p><img src="assets/a9a50eb0-3fb4-11e8-9e37-a924cb695a5d" alt="png" /></p>
 <p>如果 A、C 节点之间通信被阻断，上述混合路由查询自然就不能成功了，如下图所示：</p>
-<p><img src="assets/9073dc30-3fb6-11e8-9e37-a924cb695a5d" alt="enter image description here" /></p>
+<p><img src="assets/9073dc30-3fb6-11e8-9e37-a924cb695a5d" alt="png" /></p>
 <p>如上图所示，节点 1 与节点 3 互相不可访问，这种情况下，节点 1 和节点 3 相互认为对方下线，因此会将对方标记为 PFAIL 状态，但由于持有这一观点（认为节点 1、3 下线）的主节点数量少于主节点总数的一半，不会发起故障倒换，集群状态正常。</p>
 <p>虽然集群显示状态正常，但存在潜在问题，比如节点 1 上的客户端进行读写操作的 Key 位于节点 3 主节点的 Slot 中，这时进行读写操作，由于互不可达，必然失败。读写操作的目标节点是由 Key 决定的，CRC16 算法计算出 Key 对应的 Slot 编号，根据 Slot 编号确定目标节点。同时，不同的 Key 对应的 Slot 不尽相同，从节点 1 的视角来看，那些匹配节点 2 所属 Slot 位的 Key，读写操作都可以正常进行，而匹配节点 3 所属 Slot 位的 Key 则会报错，这样就解释了为何只有部分读写操作失败。</p>
 <h4>5.3 解决方案</h4>
@@ -480,7 +480,7 @@ if (!del &amp;&amp; server.cluster-&gt;slots[slot])
 <li>通过 <code>telnet ip port</code> 命令检测节点间通信情况，发现其中一个主节点与备节点无法联通，进一步定位为交换机故障。</li>
 </ol>
 <p>上述故障场景示意图如下：</p>
-<p><img src="assets/92a19d60-3fd1-11e8-9e37-a924cb695a5d" alt="enter image description here" /></p>
+<p><img src="assets/92a19d60-3fd1-11e8-9e37-a924cb695a5d" alt="png" /></p>
 <p>故障主节点 A-M 的备节点 A-S 升主需要获得超过半数的主节点投票，故障场景下，存活的两个主节点中，C-M 与备节点 A-S 内部通信被阻断，导致备节点 A-S 只能获得 1 张票，没有超过集群规模的半数（3 节点集群，至少需要 2 张票），从而无法升主，进而导致故障主节点故障倒换失败，集群无法恢复。</p>
 <h4>6.3 解决方案及改进措施</h4>
 <p>本节所述故障场景，基于 3 主 3 备的架构，Redis 集群不具备自愈的硬性条件，没有解决方案。不过，如果扩大集群的规模，比如 5 主 5 备，出现同样故障则是可以自愈的。</p>