fix line breaks around images

ch1.md

@@ -175,6 +175,7 @@
       JOIN follows ON follows.followee_id = users.id
       WHERE follows.follower_id = current_user
     ```
+
     ![](img/fig1-2.png)
 
     **图 1-2 推特主页时间线的关系型模式简单实现**

ch11.md

@@ -349,6 +349,7 @@ $$
 state(now) = \int_{t=0}^{now}{stream(t) \ dt} \\
 stream(t) = \frac{d\ state(t)}{dt}
 $$
+
 ![](img/fig11-6.png)
 
 **图 11-6 应用当前状态与事件流之间的关系**

ch4.md

@@ -113,7 +113,6 @@ JSON 比 XML 简洁，但与二进制格式相比还是太占空间。这一事
 
 在下面的章节中，能达到比这好得多的结果，只用 32 个字节对相同的记录进行编码。
 
-
 ![](img/fig4-1.png)
 
 **图 4-1 使用 MessagePack 编码的记录（例 4-1）**

ch5.md

@@ -37,6 +37,7 @@
 [^i]: 不同的人对 **热（hot）**、**温（warm）** 和 **冷（cold）** 备份服务器有不同的定义。例如在 PostgreSQL 中，**热备（hot standby）** 指的是能接受客户端读请求的副本。而 **温备（warm standby）** 只是追随领导者，但不处理客户端的任何查询。就本书而言，这些差异并不重要。
 
 ![](img/fig5-1.png)
+
 **图 5-1 基于领导者的（主/从）复制**
 
 这种复制模式是许多关系数据库的内置功能，如 PostgreSQL（从 9.0 版本开始）、MySQL、Oracle Data Guard【2】和 SQL Server 的 AlwaysOn 可用性组【3】。 它也被用于一些非关系数据库，包括 MongoDB、RethinkDB 和 Espresso【4】。最后，基于领导者的复制并不仅限于数据库：像 Kafka【5】和 RabbitMQ 高可用队列【6】这样的分布式消息代理也使用它。某些网络文件系统，例如 DRBD 这样的块复制设备也与之类似。
@@ -50,6 +51,7 @@
 [图 5-2](img/fig5-2.png) 显示了系统各个组件之间的通信：用户客户端、主库和两个从库。时间从左向右流动。请求或响应消息用粗箭头表示。
 
 ![](img/fig5-2.png)
+
 **图 5-2 基于领导者的复制：一个同步从库和一个异步从库**
 
 在 [图 5-2](img/fig5-2.png) 的示例中，从库 1 的复制是同步的：在向用户报告写入成功并使结果对其他用户可见之前，主库需要等待从库 1 的确认，确保从库 1 已经收到写入操作。而从库 2 的复制是异步的：主库发送消息，但不等待该从库的响应。

ch9.md

@@ -97,6 +97,7 @@
 为了使系统线性一致，我们需要添加另一个约束，如 [图 9-3](img/fig9-3.png) 所示
 
 ![](img/fig9-3.png)
+
 **图 9-3 任何一个读取返回新值后，所有后续读取（在相同或其他客户端上）也必须返回新值。**
 
 在一个线性一致的系统中，我们可以想象，在 `x` 的值从 `0` 自动翻转到 `1` 的时候（在写操作的开始和结束之间）必定有一个时间点。因此，如果一个客户端的读取返回新的值 `1`，即使写操作尚未完成，所有后续读取也必须返回新值。
@@ -180,7 +181,9 @@
 计算机系统也会出现类似的情况。例如，假设有一个网站，用户可以上传照片，一个后台进程会调整照片大小，降低分辨率以加快下载速度（缩略图）。该系统的架构和数据流如 [图 9-5](img/fig9-5.png) 所示。
 
 图像缩放器需要明确的指令来执行尺寸缩放作业，指令是 Web 服务器通过消息队列发送的（请参阅 [第十一章](ch11.md)）。 Web 服务器不会将整个照片放在队列中，因为大多数消息代理都是针对较短的消息而设计的，而一张照片的空间占用可能达到几兆字节。取而代之的是，首先将照片写入文件存储服务，写入完成后再将给缩放器的指令放入消息队列。
+
 ![](img/fig9-5.png)
+
 **图 9-5 Web 服务器和图像缩放器通过文件存储和消息队列进行通信，打开竞争条件的可能性。**
 
 如果文件存储服务是线性一致的，那么这个系统应该可以正常工作。如果它不是线性一致的，则存在竞争条件的风险：消息队列（[图 9-5](img/fig9-5.png) 中的步骤 3 和 4）可能比存储服务内部的复制（replication）更快。在这种情况下，当缩放器读取图像（步骤 5）时，可能会看到图像的旧版本，或者什么都没有。如果它处理的是旧版本的图像，则文件存储中的全尺寸图和缩略图就产生了永久性的不一致。
@@ -638,6 +641,7 @@ CAP 定理的正式定义仅限于很狭隘的范围【30】，它只考虑了
 情况如 [图 9-10](img/fig9-10.png) 所示。在这个特定的例子中，协调者实际上决定提交，数据库 2 收到提交请求。但是，协调者在将提交请求发送到数据库 1 之前发生崩溃，因此数据库 1 不知道是否提交或中止。即使 **超时** 在这里也没有帮助：如果数据库 1 在超时后单方面中止，它将最终与执行提交的数据库 2 不一致。同样，单方面提交也是不安全的，因为另一个参与者可能已经中止了。
 
 ![](img/fig9-10.png)
+
 **图 9-10 参与者投赞成票后，协调者崩溃。数据库 1 不知道是否提交或中止**
 
 没有协调者的消息，参与者无法知道是提交还是放弃。原则上参与者可以相互沟通，找出每个参与者是如何投票的，并达成一致，但这不是 2PC 协议的一部分。