后端同学组织了技术分享，交流《Unix环境高级编程》读书心得，前端同学怎能落下？

实际上，前端圈的分享会稍早前就开始组织了，只不过我没空将其中的点滴一一记录。

作为项目的技术负责人，前端本不是我的主业。目前，前端团队无论从代码质量还是技术水平，都不太令人满意。我每周合并代码时，有时会瞟一眼，有些同学的代码真的堪忧。

目前，前端团队都是初级工程师，功底较差，做出来的东西只是能用而已。他们既不会总结经验，形成最佳实践；做事又随便，总是机械地应付任务。我苦口婆心地劝他们要多看看书，思考代码要怎么写更好，但收效甚微。

既然规劝没用，我就强制他们学习！我定的第一个课题是 TypeScript ，因为他们的代码质量很差，希望引入 TypeScript 后提升代码健壮性。前后端分享频率都是每周一次，但我有点忙不过来，后续改成双周一次。

组织过好几次 TypeScript 学习后，有同学提议分享自己感兴趣的研究课题，我没反对。最近李同学在研究 Promise ，因此 Promise 便成了本周的分享主题。

我是后端出身，虽然前端项目也是我在主导，但知识盲区还有很多。Promise 之前就一直没用对，真是贻笑大方。正好趁着这次机会，好好梳理下 Promise 的来龙去脉，故有此篇。

《Unix环境高级编程》第一次读书分享会由廖同学主持，主要讲解 文件操作 。 Unix/Linux 提供了这几个系统调用来操作文件：

• open ，操作前先打开文件，获得一个 文件描述符 （ file descriptor ）；
• read ，从文件指定位置读取数据（传打开文件的描述符）；
• write ，将数据写到文件指定位置（传文件描述符）；
• lseek ，更新文件当前偏移量，偏移量决定 read 和 write 读写位置；
• close ，操作完毕后关闭文件，回收系统资源，并释放文件描述符；

Unix/Linux 文件操作很简单，无非是打开、关闭、读写和指针移动（ lseek ），对吧？尽管如此，简单的东西还是有很多需要考究的地方。

为了提高学习效果，增强每位同学的参与感，我特地安排了课前作业。既然是学习文件操作，那就模仿着开发一个 cat 命令呗。

cat 是一个非常简单的 Unix/Linux 命令，用于读取文件数据，并输出到标准输出。但就这么简单的一个作业，初学者还是很难写好。

那么，实现 cat 命令背后都有哪些门道呢？简单的表象下，又暗藏哪些玄机呢？

背景

团队内来了不少年轻人，水平参差不齐，有些干了好几个年头还不知道什么是 进程间通信（ IPC ）。

当时在讨论一个后台服务的设计，它内部由若干协程组成，协程间需要传递一些数据，他想用 Redis 来做队列……我表示不解，在同一个程序内的通信，为什么要通过一个外部的 Redis 来进行呢？

我很好奇，问他：你没学过 进程间通信（ IPC ）吗？同一台主机下的进程进行通信，当然是首选操作系统提供的进程间通信机制，除非应用进程可能跨机器协作。但他一脸懵逼，表示没听过进程间通信……

我当时有点震惊，一个干了好几年的后端，居然没听过进程间通信！这不是校招必考题吗？

想当年没读《Unix环境高级编程》都不好意思去面试，而进程间通信就是其中一个主题。但他们可能起点较低，没认真学好这些基础课，也没经历过大厂面试的洗礼，因而功底比较薄弱。

团队来了不少年轻人，水平却参差不齐，有些干了好几个年头还不知道什么是 进程间通信（ IPC ）。

最近突发奇想，准备搞一搞技术分享，带他们阅读一些经典的技术书。《Unix环境高级编程》是后端必读书目，我问了一圈竟无一人读过，因而被我选中。学习模式大致是这样的：大家轮流学习某个知识点，然后讲给其他人听，每周一次。

第一次我原本准备亲自讲，给他们吹吹水，灌灌鸡汤。无奈这周身体抱恙，有点小感冒讲话不方便，遂写成文字分享给他们，乃有此篇。

技术视野

有本叫《性能之巅》的技术书很出名，作者在前言中引用美国国防部长拉姆斯菲尔德说的一句话，很有意思。他说世界上的事物可以分为三种：

• A 已知的已知 ，比如我会 Go 语言；
• B 已知的未知 ，比如我知道有一门语言 Rust 最近很火，但我不会；
• C 未知的未知 ，……

前面我们介绍了 哈希索引 和 LSM树索引 ，它们都基于日志结构式的数据文件。虽然工程界对这种索引的认可度正与日俱增，但还远不是最受欢迎的索引技术。

那么，目前应用最广的索引技术又是什么呢？

您可能早就有所耳闻——这就是本文要探讨的 B树（ b-tree ）索引。B树可以说是数据库索引技术中的武林盟主，能够几十年长盛不衰，必定有它自己的独门秘诀。

索引结构

跟我们在 LSM树 一节中提到的 SSTable 一样，B树也是将数据组织成有序形式，因此支持范围查询。尽管如此，它们的底层结构却完全不同，B树有自己独特的设计哲学。

上次我们分享了采用哈希索引实现的存储引擎，它总是将写操作不断追加到数据文件，就跟写日志一样。这种日志结构式的存储引擎，数据记录顺序由写入时间决定，同一键的旧记录由新记录取代。

SSTable

由于数据在写入时，自动切分成一个个文件。数据库需要在后台对文件进行合并，以减少文件数，进而加快查询。如果待合并文件里的数据是有序的，我们就可以采用归并排序算法来提高合并效率。

虽然这看起来会违背顺序写的原则，但也有办法解决，我们稍后介绍。

现在，我们将数据文件格式改成这样：①文件中的所有记录，按照 键（ key ）来排序；②排序保证了每个键只在文件中出现一次，不会有重复的旧记录。姑且将这种格式叫做 排序字符串表（ sorted string table ）简称 SSTable 。

我们介绍过一个用几行 Shell 代码实现的简陋数据库，它的插入性能很好，但查询性能很差。

我们都知道，想要提升数据库的查询速度，索引必不可少 。那么，索引的底层结构都是怎样的呢？它们又是如何工作的呢？

实际上，数据库索引技术因底层数据结构不同，可以分为好几种：

• 哈希索引（ hash index ）
• LSM树（ log structured merge tree ）
• B树（ b-tree ）

其中，哈希索引的结构最为简单，但也很常用。今天我们就先将它一举拿下！

哈希索引结构

键值对存储引擎其实跟编程语言中的 字典 （ dictionary ）类型很像，而字典底层通常是用 哈希表（ hash table ）实现的。既然哈希表可以用来索引内存中的数据，应该也可以用来索引磁盘数据吧？

最近重读《数据密集型应用系统设计》这本书，看到第三章《数据存储与检索》，主要讲数据库内部的索引技术。

从本质上讲，数据库主要是做两件事情：

1. 当你给它数据时，它帮你保存数据（存储）；
2. 当你查询数据时，它帮你取回数据（检索）；

这两件事情看似简单，背后却暗含玄机。那么，数据库内部到底是如何存储数据的呢？又是如何检索数据的呢？

你可能会有这样的疑问：我作为一个开发人员，为什么需要知道数据库内部是怎么工作的呢？

公司项目基本都用 gitlab-ci 实现自动集成部署，代码提交后自动触发 代码编译 、 容器构建 和 K8S部署 。

最近将 gitlab-ci 权限开放给开发同学，自主将代码部署上测试环境，以便快速验证新功能。我们约定好通过 标签 （ tag ）来触发部署，只要推送了格式形如 cicd-x-nnn-MMddHHmm 的标签，就会触发自动部署。其中， nnn 代表开发者姓名拼音首字母，其后跟着日期时间。

如果我想部署当前的代码 提交点 （ commit ），我只需按照约定打一个部署标签，然后推送到服务器：

1
2

git tag cicd-x-cyf-07171430
git push origin cicd-x-cyf-07171430

很方便不是？

但可能是我太懒了，还是觉得远远不够。首先，我感受到记忆标签格式的负担，记不住就得查；其次，我得大致看下时间，然后还得手工输入，这绝对不能忍……

用过 MySQL 的童鞋一定对那个非常好看的字符表格印象深刻吧！

在 Python 中，使用 tabulate 库，可轻松实现一模一样的字符表格。

快速上手

废话不多说，先来看看效果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

    >>> from tabulate import tabulate

    >>> table_header = ['Name', 'Chinese', 'Math', 'English']
    >>> table_data = [
    ...     ('Tom', '90', '80', '85'),
    ...     ('Jim', '70', '90', '80'),
    ...     ('Lucy', '90', '70', '90'),
    ... ]

    >>> print(tabulate(table_data, headers=table_header, tablefmt='grid'))
    +--------+-----------+--------+-----------+
    | Name   |   Chinese |   Math |   English |
    +========+===========+========+===========+
    | Tom    |        90 |     80 |        85 |
    +--------+-----------+--------+-----------+
    | Jim    |        70 |     90 |        80 |
    +--------+-----------+--------+-----------+
    | Lucy   |        90 |     70 |        90 |
    +--------+-----------+--------+-----------+