关于数据库:技术配图的一些心得

写过不少技术文章，以及给不少技术思路手绘示例配图之后，在这方面有了一些心得，本文给出一些对于配图的见解，仅供大家参考。

对于理工科出身的同学，对于能够量化的事件，总是很习惯依据量化差别来做出判断，比方一个程序性能优化之后，比照优化之前快出多少，都能很容易的通过一个量化的数字来阐明。

然而对于那些不能量化的货色，就很难说出具体好在哪里了。

本文主题要探讨的“技术配图”就属于这种很难量化的畛域，很难有一个规范来量化阐明两幅图之间差异在哪里。我也是画了很多图，以及看了他人的很多配图之后，才缓缓有一些心得，本文权当集体的一些的总结，抛砖引玉，欢送交换探讨。

本文并不是一个画图工具的比照阐明，只管当初各种绘图工具曾经很多，也各有本人的优缺点，然而在这里并不探讨具体工具的应用，会把更多的文字放在配图的一些 注意事项 上。然而，也总有人问我文章的配图是用什么工具做的，在这里再答复一次：OmniGraffle，一款目前仅有 Mac 版本的工具软件。

在开始交代具体的配图注意事项之前，有必要先说说配图的重要性。

绘图，某种程度来说也是辅助本人思考某个技术点的伎俩之一，以我集体的领会来说，有时候讲不分明一个技术点的时候，就手绘图进去，比奢侈的文字更容易阐明问题。其中的起因，有可能是：图片能够有多维的信息，而文字通常只有一维，遇到文字表达能力不太好的人，这仅有的一维能力可能还不好施展进去。

所以，在交代技术细节、沟通交流的时候，尽量多画图。反向的，图画多了，也天然缓缓会找到感觉，更好的通过图示表白思路。

顺便一提，还有比奢侈的文字表白更差的技术沟通形式，就是简略粗犷的贴一大段代码下来。这种做法，其实更多时候是对作者的思路没有太多集体的整顿，纯正偷懒的形式，往往最初回头再看写过的文字，可能连本人都看不懂了。

如果产出某些内容的时候，能假如本人将来就是这些输入的读者、维护者，那么输入起来会更欠缺一些。比方写的代码、文章、甚至于提交代码时候的信息，如果能思考是写给将来的本人看的，会更清晰、尽可能留下更多的信息。我最开始要在文章里大量配图，也是为了未来本人回看的时候能看懂。

总之，尽可能多画图来表白技术思路。

上面开始正题，以下会以简略的几个准则及示例来阐明。

配图中，应该尽量将不同的模块、组件等辨别开来，“辨别”的形式有很多，常见的有：

应用不同的色彩。
应用不同的形态。
应用箭头、曲线等示意数据的走向、趋势。

等等，所有的这些伎俩，概括起来就是尽量在图中，将不同的元素辨别开来，“有辨别”意味着至多有一个维度的不同，这样能给读者更加清晰的观感。能够联合上面的例子来了解辨别、分割和组合的绘图表白。

分组

一个模块里，可能由多个组件形成，能够把这些组件分组到一个更大的模块中。

分组是十分常见的一种伎俩，这里多举几个例子。

上图中，每个 CPU Core 中有 L1、L2 缓存，于是把这些组件合并在一起放在 Core 组件中，四周应用一个正方形包裹起来，同时这个正方形左上角有一个 Core 的阐明文字，这样高深莫测：Core 模块，由 L1、L2 缓存形成。

上图出自 Raft 论文，整体上划分为了 Client、Server 这两大部分。而每个 Server 又有以下三局部组成：

一致性算法模块。
状态机。
长久化的日志。

所以，图示中将这三局部合在一起放在同一个矩形里，示意一个 Server 有这三个组件。

另外还需注意的是，个别这种分组中外围的矩形，有这样的考究：

个别应用斜面矩形，即四个角是圆角的矩形，这样圆润一些的边角看起来会更难受一些，如上图。
如果这个组合，是一种逻辑上的组合，那么线的形态个别用虚线；否则就个别用的实线。

在分组时，有时候能够将雷同类型的模块层叠起来，这样会更加简洁，如下图：

上图是出自 Raft 论文中的状态机模型，其中想要表白的一个点是：

有多个 client 向 server 发动申请。
server 要达成统一，须要将日志在 server 之间同步。

然而上图中，并没有把这些同类型的组件离开表白，而是奇妙的应用层叠的形式，简洁得表白了有多个 client、多个 server 的状况。

趋势

下图是形容不同档次存储的访问速度，于是用了两个形式来表白访问速度的变化趋势：

右边的箭头表白速度和老本的变动。
不同大小的多边形表白了这些存储空间的变动：越往上访问速度越快，然而对应的存储空间也更小。

再比方，下图中，是阐明 sqlite 中 btree 页面的数据组织的。其中的两局部内容，Cell 地址数组 以及 Cell 内容区 为变长大小，前者从地址低位向高位成长，后者反之，于是在图中，就用箭头示例出地址的高下位区别，以及两者的增长方向：

（出自 sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志[1]）

分割

这在波及：

状态切换。
数据流向。

等场景下是十分常见的伎俩，比方经典的 TCP 状态机切换：

以及 TCP 三次握手流程，也是典型的“状态切换”：

须要阐明的是，以上的图示中：

箭头代表的状态切换走向中，同时也配以文字说明是什么动作导致的状态切换，这样这个图示就更清晰了。
箭头也分为实线和虚线，一般而言，虚线示意数据的走向，实线示意状态的走向。

禁止

须要禁止或者谬误的行为，能够用非凡的符号，如带色彩的“×”符号示意进去；反之，能够用带色彩的“√”符号示意进去，而且示意禁止的时候，个别用红色会更显眼，下图就是一个示例：

（出自 Memory Barriers in .NET · Nadeem Afana’s Blog[2]）

阐明

如果不好阐明问题，能够在图示中搭配简短的阐明文字。留神：这类型文字肯定要足够的简短，否则可能会喧宾夺主。

比方下图中，有两局部蓝色注解的文字来阐明不同的表类型：

（出自 sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志[3]）

再比方下图中，应用注解文字来阐明查找数据的两步流程：

（出自 sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志[4]）

分类

有时候须要应用相似“{”这样的符号，对一类元素做一些阐明，例如：

下图中，是阐明 sqlite 中 btree 页面的数据组织的，最左边的以“{”包起来的文字，对每局部做了简要的阐明。

（出自 sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志[5]）

下图中，将页面划分为不同的局部，这些不同的组成部分，既应用了色彩进行辨别，也应用了向下的“{”辅以文字说明。

（出自 sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志[6]）

步骤

如果配图是须要解说某个操作的步骤的，能够配以数字来辅助了解整个流程。

下图中，表白的是依据帧数查找页面编号的两个步骤：

（出自 sqlite3.36 版本 btree 实现（四）- WAL 的实现 – codedump 的网络日志[7]）

下图中的步骤就更多了，并没有显得很乱，大略起因在于：

最右边表白了每一步的步骤。
每一步写入数据之后，显示 WAL 文件在写入之后的内容。
最左边应用“{”表白批改之后的数据。

（出自 sqlite3.36 版本 btree 实现（四）- WAL 的实现 – codedump 的网络日志[8]）

开展

如下图中，是用于展现 wal index 索引文件格式的：

右边示例每局部内容的大小，想阐明的是，那个索引块大小为 32 KB，而第一块的头 136 字节为索引文件头。
于是，在左边图中，将右边不同模块的具体格局持续开展阐明。

（出自 sqlite3.36 版本 btree 实现（四）- WAL 的实现 – codedump 的网络日志[9]）

以上简略总结了一下集体技术配图的一些心得，总的大准则是：

辨别：将组件、流程、趋势等之间的“辨别”尽可能在图示中通过各种伎俩（如不同的色彩、形态、箭头）表达出来。
分割：组件之间的数据流动、状态切换等，都是它们之间的分割，也须要通过各种伎俩表达出来。
阐明：可能的话，要在图中加上一些阐明文字，如步骤阐明、分类阐明，等等。

[1] sqlite3.36 版本 btree 实现（五）- Btree 的实现 – codedump 的网络日志: