atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://blog.shunzi.tech</id>
    <title>YouDieInADream</title>
    <updated>2023-01-15T08:13:52.540Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <link rel="alternate" href="https://blog.shunzi.tech"/>
    <link rel="self" href="https://blog.shunzi.tech/atom.xml"/>
    <subtitle>The easy way or the right way.</subtitle>
    <logo>https://blog.shunzi.tech/images/avatar.png</logo>
    <icon>https://blog.shunzi.tech/favicon.ico</icon>
    <rights>All rights reserved 2023, YouDieInADream</rights>
    <entry>
        <title type="html"><![CDATA[OSDI’22 ListDB: Union of Write-Ahead Logs and Persistent SkipLists for Incremental Checkpointing on Persistent Memory]]></title>
        <id>https://blog.shunzi.tech/post/ListDB/</id>
        <link href="https://blog.shunzi.tech/post/ListDB/">
        </link>
        <updated>2022-07-13T03:40:00.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>OSDI’22 ListDB: Union of Write-Ahead Logs and Persistent SkipLists for Incremental Checkpointing on Persistent Memory</li>
</ul>
</blockquote>
<h1 id="osdi22-listdb-union-of-write-ahead-logs-and-persistent-skiplists-for-incremental-checkpointing-on-persistent-memory">OSDI’22 ListDB: Union of Write-Ahead Logs and Persistent SkipLists for Incremental Checkpointing on Persistent Memory</h1>
<h1 id="abstract">Abstract</h1>
<ul>
<li>由于 DRAM 和非易失性主存(NVMM)之间的延迟差异以及 DRAM 的有限容量，传入的写操作经常在基于 LSM 树的键值存储中停顿 stal。本文提出了一种为 NVMM 进行写优化的键值存储 ListDB，以克服 DRAM 和 NVMM 写延迟之间的差距，从而解决写停顿问题。L</li>
<li>istDB 的贡献包括三种新的技术:
<ul>
<li>(i) 字节寻址的 IndexUnified Logging，它增量地将预写日志转换为 SkipList;</li>
<li>(ii) Braided SkipList，一个简单的 NUMA-aware SkipList，它有效地减少了 NVMM 的 NUMA 影响;</li>
<li>(iii) Zipper Compaction，它不复制键值对象向下移动 LSM 树 levels，但是通过就地合并 SkipList 而不阻塞并发读取。</li>
</ul>
</li>
<li>通过使用这三种技术，ListDB 使后台压缩足够快，足以解决臭名昭著的写停顿问题，并显示出比 PACTree 和 Intel Pmem-RocksDB 分别高 1.6 倍和 25 倍的写吞吐量。</li>
</ul>
<h1 id="introduction">Introduction</h1>
<ul>
<li>NVM 延迟和 DRAM 相当，非易失，字节寻址，以内存总线速度来操作。</li>
<li>NVM 中大数据集的定位和检索往往采用一个高效的持久化索引结构，并考虑 NVM 的器件特征。
<ul>
<li>NVMM-only 的持久性索引：[11,13,24,35,45,49,56,63]
<ul>
<li>VLDB’15 Persistent B+-Trees in Non-Volatile Main Memory</li>
<li>ATC’20 Lock-free Concurrent Level Hashing for Persistent Memory</li>
<li>FAST’18 Endurable Transient Inconsistency in Byte-Addressable Persistent B+-Tree
<ul>
<li><strong>aka. FAST and FAIR B+tree</strong></li>
</ul>
</li>
<li>FAST’17 WORT: Write Optimal Radix Tree for Persistent Memory Storage Systems.</li>
<li>FAST’19 Write-Optimized Dynamic Hashing for Persistent Memory.
<ul>
<li><strong>aka. CCEH</strong></li>
</ul>
</li>
<li>SIGMOD’16 FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory</li>
<li>FAST’11 Consistent and Durable Data Structures for Non-Volatile Byte-Addressable Memory.</li>
<li>FAST’15 NV-Tree: Reducing Consistency Cost for NVM-based Single Level Systems.</li>
</ul>
</li>
<li>混和 DRAM+NVM 持久性索引：[38, 40, 49, 63]
<ul>
<li>VLDB’20 LB+Trees: Optimizing Persistent Index Performance on 3DXPoint Memory.</li>
<li>VLDB’20 Dash: Scalable Hashing on Persistent Memory</li>
<li>SIGMOD’16 FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory.</li>
<li>FAST’15 NV-Tree: Reducing Consistency Const for NVM-based Single Level Systems.</li>
</ul>
</li>
<li>还开发了一些使用这种持久索引和后台工作线程管理大型数据集的键值存储 [12, 29, 30, 57, 60]
<ul>
<li>ASPLOS’20 FlatStore: An Efficient LogStructured Key-Value Storage Engine for Persistent Memory</li>
<li>FAST’19 SLM-DB: SingleLevel Key-Value Store with Persistent Memory</li>
<li>ATC’18 Redesigning LSMs for Nonvolatile Memory with NoveLSM</li>
<li>OSDI’21 Nap: A Black-Box Approach to NUMA-Aware Persistent Memory Indexes</li>
<li>ATC’17 HiKV: A Hybrid Index Key-Value Store for DRAMNVM Memory Systems</li>
</ul>
</li>
</ul>
</li>
<li>针对 NVM 设计的索引结构，比如 FAST and FAIR, CCEH, PACTree，提供比基于磁盘的同类产品高数量级的性能。性能仍然低于 DRAM 索引。
<ul>
<li>因为 NVM 比 DRAM 性能要差，更高的延迟，更低的带宽，NUMA 效应更敏感，以及需要更大的数据访问粒度（256B XPLine）.</li>
</ul>
</li>
<li>混和 DRAM+NVM 索引以及键值存储，目的是为了发挥 DRAM 的优势，避免 NVM 的短板，所以把索引的复杂度给丢给了 DRAM。在这项工作中，我们质疑这种忽略字节寻址性、将整个索引保存在 DRAM 中、仅将 NVMM 用作日志空间的混合方法是否可取，因为它有两个主要限制：
<ul>
<li>DRAM 容量比较小，如果数据集索引比较大，或者 DRAM 空间和其他进程共享，导致 DRAM 需要进行内存 Swapping，索引性能就会受到影响</li>
<li>易失的 DRAM 索引需要故障恢复之后重建，恢复时间很关键。周期性做 checkpoint 可以节省恢复时间，但是导致更高的写延迟，因为会阻塞并发写入</li>
</ul>
</li>
<li>作者提出了一个异步增量 checkpoint 机制，后台合并小的、高性能的 DRAM 索引到一个持久性索引来加速数据恢复。ListDB 是一个写优化的 LSM 键值存储，实现了类似于 DRAM 索引的性能，并通过把 DRAM 索引刷回到 NVM 的方式来避免 DRAM 索引无限增长，同时实现了类似于 DRAM 索引的高性能。ListDB 缓冲了批量的插入到一个小的 DRAM 索引中，并运行后台压缩任务来增量地 Checkpointing 对于 NVMM 的缓冲写入，而不需要进行数据拷贝。ListDB 将日志条目重组为 SkipList，而不是将整个 volatile 索引刷新到 NVMM。同时，这样的 SkipLists 就地合并，减少了 NUMA 影响，而不会阻塞并发的读查询。</li>
<li>三个关键技术：
<ul>
<li>快速写缓冲刷回：ListDB 统一了 WAL 和跳表，使用 Index-Unified Logging (IUL)，ListDB 只将每个键值对象作为日志条目写入 NVMM 一次。利用 NVMM 的字节可寻址性，IUL 以一种惰性的方式将日志条目转换为 SkipList 元素，这掩盖了日志记录和 MemTable flush 开销。因此，它使MemTable flush 吞吐量高于 DRAM 索引的写吞吐量，从而解决了写停顿问题。</li>
<li>减小 NUMA 效应：通过使上层指针只指向同一个 NUMA 节点上的 SkipList 元素，Braided SkipList 有效地减少了远程 NUMA 节点访问的数量</li>
<li>就地合并排序的快速 Compaction：Zippers Compaction 合并两个 Skiplist，不会阻塞读取操作。通过避免复制，Zipper Compaction 缓解了写放大的问题，并快速有效地减少 SkipLists 的数量，以提高读和恢复性能</li>
</ul>
</li>
<li>我们的性能研究表明，ListDB 的写性能优于最先进的基于 NVMM 的键值存储。对于读性能，ListDB 依赖于经典的缓存技术。</li>
</ul>
<h1 id="background-and-motivation">Background and Motivation</h1>
<h2 id="hybrid-dramnvmm-key-value-store">Hybrid DRAM+NVMM Key-Value Store</h2>
<ul>
<li>基于 NVMM 的索引常常因为需要使用 memory fence 的相关指令来保证 cacheline 持久化，引入了较大的开销。为了避免这，NVTree 和 FPTree 在 DRAM 上存储内部节点，在 NVM 上存储叶子节点，内部节点在系统故障之后可以恢复出来，但是可以从持久的叶子节点中重建。基于此，对于内部节点的写入不需要保证 failure-atomic</li>
<li>FlatStore 采用了一种相当激进的方法，即 NVMM 仅用作日志空间，其中键值对象以插入顺序而不是键顺序添加，而索引驻留在 DRAM 中。因此，FlatStore 必须在系统崩溃后从持久的日志条目重建一个不稳定的索引。为了减轻昂贵的恢复开销，FlatStore 建议定期在 NVMM 上 checkpoint DRAM索引。然而，一个简单的同步检查点(如FlatStore)在阻塞写入时获取全局快照，导致不可接受的高尾延迟。</li>
</ul>
<h2 id="lsm">LSM</h2>
<ul>
<li>更好的方法是异步增量 checkpoint，它只 checkpoints 当前检查点和最后一个检查点状态之间的差异。Log Structured Merge (LSM)树是一个经典的索引，它随着时间的推移合并检查点数据 [10, 17, 20, 33, 36, 48, 54].</li>
</ul>
<h3 id="基本操作">基本操作</h3>
<ul>
<li>写过程不做介绍</li>
<li>Compaction 不做介绍 [2, 9, 21, 29, 37, 41–43, 46, 53, 55]</li>
<li>读操作不做介绍，LSM 读比较慢，但是 LSM 比 B+tree 应用更广泛，因为读性能可以通过缓存很有效提升</li>
</ul>
<h3 id="side-effect-of-write-buffer-write-stall">Side Effect of Write Buffer: Write Stall</h3>
<ul>
<li>写 buffer 处理写入很快，但是在 LSM 里有一些人工调控限制了写 Buffer，导致很高的延迟。即 compaction 比较慢的时候会阻塞前台的 imm 刷回。相似的，如果 SST 没有很快被合并排序，重叠的 SST 也会增加，读性能下降。大部分 LSM 会阻塞客户端的写入，直到 compaction 完成以及有空间容纳新的 memtable。这就是写停顿，如果写停顿出现，这时候插入吞吐就受到持久存储性能的限制，而没法从 DRAM 中获益</li>
</ul>
<h3 id="写放大">写放大</h3>
<p><strong>多层和双层压缩</strong></p>
<ul>
<li>基于拷贝的 Compaction 允许并发的读查询访问旧的 SST，同时创建新的 SSTs。但是基于拷贝的 Compaction 要求重复拷贝相同的对象到新的 SSTs。一个键值对被拷贝到一个新文件的次数即为写放大，现有研究估计可能高达 40。如果使用 leveled compaction 的话，写放大会尤其严重，而且会有大量的 levels。因为 leveled compaction 限制了每层的 SSTables 数量，并且避免了单层里的数据重叠。</li>
<li>因为 NVM 字节寻址，因此可以考虑使用单层的持久化索引来替代多层 SSTs。SLM-DB 就使用了两层，一层 Memtable 和一个在 NVM 上的单层的 B+tree，使用两层设计，Memtable 缓冲了多个 KV 键值对然后插入到一个大的持久性索引，例如，对于多次写操作只遍历一次大型持久索引，并且它比单个持久索引产生更高的写吞吐量</li>
</ul>
<figure data-type="image" tabindex="1"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled.png" alt="Untitled" loading="lazy"></figure>
<p><strong>解耦归并排序和 Flush</strong></p>
<ul>
<li>双层设计的主要问题是持久性索引的大小影响合并易失索引到持久性索引的性能，也就无法让写性能独立于 NVMM 性能。因为 Memtable 不再是 flush 到底层，而是归并排序到大的慢的持久性索引。因为 NVMM 有更高的延迟，归并排序吞吐远低于易失索引的插入吞吐，特别是持久性索引比较大的时候</li>
<li>为了缓解这个问题，大多数键值存储采用了一个中间持久化 buffer level L0。即执行 flush 而不进行归并排序，下图展示了一个三层设计，通过分离归并排序和 flush，Memtable 可以刷回到 NVMM 更快，flush 的吞吐也就和数据库的大小独立开来</li>
<li>该设计的一个缺点就是导致了更多的重叠 SSTs，影响了查询性能。鉴于其较差的索引性能，中间持久缓冲区级别似乎与预写日志没有太大区别。另外，键值数据通常写到存储上至少两次，一次 WAL，一次 Memtable flush</li>
<li>TRIAD, WiscKey, FlatStore 避免了重复写入。
<ul>
<li>TRIAD 直接把 commit log 当作未排序的 L0 SST，为了高效检索 L0，TRIAD 为每个 L0 SST 维护了一个小的索引。索引不存储键值，只按键顺序存储每个对象的偏移。虽然 TRIAD 减少了 I/O，但每个 Memtable 刷回创建一个索引文件，然后调用开销较大的 fsync 来持久化。然而，考虑到 L0 SSTables 之间的高度重叠，以及 L0 SSTables 将很快合并到 L1 SSTables 的事实，是否应该以非常高的成本为每个 L0 SSTable 创建和持久化一个单独的索引文件是值得怀疑的</li>
</ul>
</li>
</ul>
<h2 id="numa-effects">NUMA Effects</h2>
<ul>
<li>相比于 DRAM，NVM 因为其更低的带宽对 NUMA 效应更敏感。也就是因为这，CCEH, FAST and FAIR 这些索引的扩展性就比较一般，由于非常规的cacheline 访问和 NUMA 效应</li>
<li>有研究建议限制每个 Socket 的写线程为 4-6 个线程。
<ul>
<li>SIGMOD’21 Maximizing Persistent Memory Bandwidth Utilization for OLAP Workloads.</li>
</ul>
</li>
<li>Nap 通过在 NVMM 常驻索引上覆盖一个 DRAM 索引来隐藏 NUMA 效果，这样 DRAM 索引就可以吸收远程 NUMA 节点访问。但是，存储在NVMM中的数据已经在内存地址空间中，而且 NVMM 的延迟与 DRAM 相当。因此，使用 DRAM 作为 NVMM 上的快速缓存层并在 DRAM 和 NVMM 之间来回复制数据可能会造成浪费。例如，EXT4-DAX 和 NOVA[61] 等 NVMM 文件系统不使用页面缓存，而是直接访问 NVMM</li>
<li>缓解 DRAM 上的 NUMA 效应有很多种方法，包括  基于哈希分片的 Delegation 和 Node Replication
<ul>
<li>Delegation：指定的 worker 线程分配给一个具体的键范围，负责其所有操作。因此客户端线程需要和 worker 线程通信并使用消息传递来委派操作。因为消息传递的开销，Delegation 执行的性能不是最优的，特别是对于索引操作这样的轻量级任务 [4, 6, 7, 44]
<ul>
<li>ATC’11 A Case for NUMAAware Contention Management on Multicore Systems.</li>
<li>HotPar’13 Using Elimination and Delegation to Implement a Scalable NUMA-Friendly Stack</li>
<li>ASPLOS’17 Black-Box Concurrent Data Structures for NUMA Architectures.</li>
<li>PPoPP’12 CPHASH: A Cache-Partitioned Hash Table.</li>
</ul>
</li>
<li>Node Replication：实现了一个 NUMA 感知的共享日志，它用于对跨 NUMA 节点复制的数据结构重放相同的操作。但是，这将消耗内存来跨多个 NUMA 节点复制相同的数据结构。此外，由于 NUMA 节点数量增加，跨节点通信导致性能下降。考虑到 Optane DCPMM 的带宽远低于DRAM，复制会加剧低带宽问题
<ul>
<li>ASPLOS’17 Black-Box Concurrent Data Structures for NUMA Architectures</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="design">Design</h1>
<h2 id="three-level-architecture">Three-Level Architecture</h2>
<ul>
<li>三层：Memable，L0，L1 Persistent Memtables (PMTables)
<ul>
<li>Memtable 和 PMTables 本质上是相同的跳表，但是 PMTable 有额外的元数据，因为是从 WAL 转换过来的</li>
<li>ListDB使用 SkipList 作为所有级别的核心数据结构，因为它支持字节可寻址的就地合并排序，并避免了写放大问题[21,41,53]</li>
</ul>
</li>
<li>ListDB 在 NVMM 中使用一个中间持久缓冲区级别 L0 。对于 L0，MemTable 被 flush 到 NVMM 而不需要进行合并排序，这使得 flush 吞吐量与下一级持久索引大小无关。L0 积累的 MemTables (L0 PMTables)通过压缩逐渐合并到较大的 L1 PMTable 中。为了管理多个 PMTables, ListDB使用一个名为MANIFEST的元数据对象指向每个 SkipList 的开头。</li>
</ul>
<figure data-type="image" tabindex="2"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%201.png" alt="Untitled" loading="lazy"></figure>
<h2 id="index-unified-logging">Index-Unified Logging</h2>
<ul>
<li>目标就是将 Memtable 刷回到 NVMM 不需要拷贝简直对象</li>
</ul>
<h3 id="conversion-of-iul-into-skiplist">Conversion of IUL into SkipList</h3>
<ul>
<li>Index-Unified Logging (IUL) 通过按照跳表元素的形式来分配和写入日志项，实现 WAL 和跳表的统一。图 4 展示了其中 Entry 的结构，同时作为日志项和跳表元素。当插入一个键值对到 Memtable，其对象和元数据（operation 以及 LSN）是已知的，对应的日志项被写入和持久化到 NVMM 上，对应的跳表指针初始化为 NULL。之后，一个 Compaction 线程把对应的 Memtable 刷回的时候，日志项被转换成跳表元素，重用日志项中对应的键值</li>
<li>但是跳表元素需要额外的信息，即键的顺序信息，该信息以跳表指针维护在 Memtable 中。当把日志转换成 PMTable 的时候，相应的 Memtable 元素的地址被简单的转换成 NVMM 的地址（通过偏移量转换）。跳表指针转换成 NVMM 地址之后，IUL 中的项也就变成了跳表元素</li>
<li>最后更新 MANIFEST 来让新的 L0 PMTable 生效，并让 Immutable Memtable 在一个 failure-atomic 事务中失效。</li>
</ul>
<figure data-type="image" tabindex="3"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%202.png" alt="Untitled" loading="lazy"></figure>
<h3 id="memtable-flush-without-clflush">MemTable Flush without clflush</h3>
<ul>
<li>跳表指针写入到日志项时不需要 clflush，因为本身写入的只是顺序，不是数据，顺序完全可以恢复出来。</li>
<li>不需要显示 flush 也就是说利用 CPU 自己的缓存机制来管理数据的刷回，也就实现了对于相同 XPLine 的写入可以被缓冲，8B 小写也就不会转换成 256B 的 RMW，不仅延后了 RMW，也避免了后台 Compaction 线程受到 RMW 带来的延迟影响</li>
</ul>
<h3 id="walk-through-example">Walk-Through Example</h3>
<ul>
<li>流程如上图 5 所示，假设插入的数据顺序为 503，921，3。每个客户端线程在它提交之前持久化对象、元数据和 NULL 指针到日志。然后后台线程标记 Memtable 为 immutable 并创建一个新的 Memtable。客户端线程再插入了 716 和 217。</li>
<li>后台 Compaction 线程刷回 Immutable Memtable，把相应的 Memtable 元素指针转换成 IUL 偏移量，然后替换掉对应的指针，从而成为跳表。</li>
</ul>
<h3 id="checkpointing-l0-pmtable">Checkpointing L0 PMTable</h3>
<ul>
<li>虽然日志条目现在被转换为 L0 PMTable 元素，但是日志空间和 L0 PMTable 空间之间的边界(如图6(a)中的粗虚线所示)没有移动，因为它不能保证新的 L0 PMTable 的指针是持久的。只有对更新的指针显示调用了 clflush 指令才会移动边界，在我们的实现中，后台线程批量地持久化 L0 PMTables 的脏cachelines。此操作称为 checkpointing。图6(b)显示了指针显式持久化后的NVMM布局。一旦PMTable被 checkpointing，就可以移动日志空间的边界以减少需要恢复的日志条目的数量，如图6(b)所示。</li>
</ul>
<figure data-type="image" tabindex="4"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%203.png" alt="Untitled" loading="lazy"></figure>
<h3 id="lazy-group-checkpointing">Lazy Group Checkpointing</h3>
<ul>
<li>Checkpointing 目的是为了减少恢复时间。但是 ListDB 尽可能推迟 Checkpointing，因为调用 clflush 开销太大了，即便 L0 PMTables 没有被持久化，也不会影响崩溃一致性，因为会被当作日志来恢复。其顺序也可以重建</li>
<li>作者实现中，多个 L0 PMTables 被分组，脏的 cachelines 批量进行持久化。也就是所谓的 lazy group checkpointing。本身就是在日志大小、恢复时间以及 flush 吞吐量方面做妥协。checkpointing 越频繁，flush 越慢，日志大小越小，恢复越快。</li>
<li>Zipper compaction 持久化指针很快，可以避免 L0 的表数量太多。即使 IUL 不持久化任何 L0 PMTable，当将 L0 PMTable 合并到 L1 PMTable 时，Zipper 压缩持久化指针的速度很快，而且 IUL 的恢复时间比同步检查点要短得多</li>
</ul>
<h2 id="numa-effects-for-skiplist">NUMA Effects for SkipList</h2>
<ul>
<li>ListDB 采用了 NUMA 感知的数据结构，与委托和节点复制相比，该结构在最小化 NUMA 互连争用方面更具可伸缩性和有效性</li>
</ul>
<h3 id="numa-aware-braided-skiplist">NUMA-aware Braided SkipList</h3>
<ul>
<li>跳表的一个特点：每一层的 list 必然是最底层 list 的有序子集。上层的指针是概率选择出来的，不影响查询的正确性。但是，<strong>上层不需要是下一层的子列表，只要是底层的子列表即可</strong>。即使搜索没有找到更接近上层搜索键的键，搜索也会回到更低的层，最终搜索到包含所有有序键的底层。</li>
<li>Braided SkipList 就是利用这个特点来减小 NUMA 效应。上层指针忽略远程 NUMA 节点中的 SkipList 元素；例如，每个元素的上层指针指向同一个NUMA 节点中具有更大键的元素。与 NUMA-oblivious 传统的 SkipList 相比，Braided SkipList 把远程内存访问次数减少到 1/N，其中 N 是 NUMA 节点的数目</li>
<li>如下例子，为了便于显示，NUMA节点 1 中的上层颠倒了。
<ul>
<li>NUMA 0 上的元素 3 指向了相同 NUMA 节点的元素 7，但是没有指向 NUMA 1 上的元素 5（原始的跳表就会指向 5）。</li>
<li>尽管如上维护指针，查询还是正确的。
<ul>
<li>比如在 NUMA 0 上的线程查询 5。首先找到 3 和 9，因为 9 更大，向下移动找到 3 和 7，继续下移，找到了 3 和 4。因为 5 大于 4，那么继续下移动，这时候检查 4 的下一个指针。也就找到了 NUMA 1 上的 5</li>
</ul>
</li>
</ul>
</li>
<li>在作者的 Braided SkipList 实现中，NUMA ID 被嵌入到 64 位虚拟地址的额外 16 位中，类似于 pointer swizzling 的操作，这样它就可以使用 8 字节的原子指令，而不是较重的 PMDK 事务。为了直接引用，Braided SkipList 通过 masking 额外的 16 位来恢复 SkipList 元素的虚拟内存地址。</li>
</ul>
<figure data-type="image" tabindex="5"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%204.png" alt="Untitled" loading="lazy"></figure>
<h2 id="zipper-compaction">Zipper Compaction</h2>
<ul>
<li>Zipper Compaction 通过只修改指针来归并排序 L0 和 L1 的 PMTables，不会阻塞并发的读。就地归并排序避免了写放大，提升了 Compaction 吞吐</li>
<li>基于跳表的特性，部分研究提出了无锁的跳表。基于 Java 的 ConcurrentSkipListMap 在实践中表现良好。经典的无锁跳表避免对多个 Writers 加锁。相反，ListDB 不会并发写入。唯一的 writers 是 Compaction 线程，ListDB 会协调这些线程避免写写冲突。对于并行性，多个压缩线程写入不相交的分片。一个分片是 L1 PMTable 中一个高度最大的元素到下一个高度最大的元素之间的一个不相交的键范围。为了将 L0 元素合并到 L1 中，压缩线程必须获得对应分片上的锁。</li>
<li>Zipper Compaction 分为两阶段：
<ul>
<li>从头到尾的 scan</li>
<li>从尾到头的 merge</li>
</ul>
</li>
<li>为了保证正确的搜索结果而不阻塞并发读，L0 PMTable 元素由尾到头被合并到 L1 PMTable 中，同时并发读取操作从头到尾遍历它们。</li>
</ul>
<h3 id="scan-phase">Scan Phase</h3>
<ul>
<li>在前向扫描阶段，压缩线程从头到尾遍历 L0 和 L1 PMTable，并确定每个 L0 PMTable 元素应该插入 L1 PMTable 中的什么位置。但是，在这个阶段，它不会对 PMTables 进行任何更改，而是将必要的指针更新推送到堆栈上。后向合并阶段弹出堆栈以应用并持久化 L1 PMTable 中的更新。</li>
<li>扫描阶段沿着 L0 PMTable 的底层。对于每个 L0 元素，它会搜索 L1 PMTable，以找到插入 L0 元素的位置。为此，它跟踪每层中小于当前搜索键 (L0元素) 的最右边的元素，以避免重复遍历 L1 PMTable。因为两个 PMTable 中的键都是排序的，所以 L0 PMTable 中的下一个较大的键可以重用前面最右边的元素，并回溯到最右边的最顶层元素进行下一次搜索。因此，扫描阶段的复杂度为 O(n0 + logn1)，其中 n0 和 n1 分别为 L0 和 L1 PMTables 的大小。</li>
<li>对于支持 NUMA 的 Braided SkipList, Zipper 压缩需要一个最右的二维数组 [numa_id][layer] 来保持每一层中最右的元素数量与 Braided SkipList 的 NUMA 节点数量相同。但是，请注意，Braided SkipList 元素不需要比传统的 SkipList 元素更多的指针，因为它在 8 字节地址中嵌入了 NUMA 节点 ID。</li>
<li>下图 a 展示了一个例子：假设所有跳表元素都在一个 NUMA 节点
<ul>
<li>L0 的元素 A 需要放置到 L1 的第一个位置。因此 L1 头结点的 H0 和 H1 就是当前最右的指针，需要为 A 的合并来更新。压栈
<ul>
<li>A0 和 A1 需要指向 B。但是该信息没有压栈 ，因为 B 是由当前已经压入堆栈的最右边的元素（L1.H0, L1.H1）指向的。每个 L0 元素被插入到两个 L1 元素之间，每层中只有前一个(即最右边的)元素需要被推入堆栈，因为从前一个元素中可以找到下一个元素。</li>
</ul>
</li>
<li>接下来，扫描阶段访问 L0 中的第二个元素D，并搜索L1。插入D需要更新B2、C1和C0。同样，它们被压入堆栈。</li>
<li>最后，它访问L0中的最后一个元素E，并搜索L1。注意L1 PMTable没有改变，当前最右边的指针仍然是B2、C1和C0。因此，扫描阶段将C1和C0推入堆栈，使它们指向E。</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="6"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%205.png" alt="Untitled" loading="lazy"></figure>
<h3 id="merge-phase">Merge Phase</h3>
<ul>
<li>合并阶段将指针更新从尾部应用到头部。当压缩线程从栈中弹出一个更新 <span class="katex"><span class="katex-mathml"><math><semantics><mrow><msub><mi>X</mi><mi>N</mi></msub></mrow><annotation encoding="application/x-tex">X_N</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.83333em;vertical-align:-0.15em;"></span><span class="mord"><span class="mord mathdefault" style="margin-right:0.07847em;">X</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.32833099999999993em;"><span style="top:-2.5500000000000003em;margin-left:-0.07847em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathdefault mtight" style="margin-right:0.10903em;">N</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> → <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mi>Y</mi></mrow><annotation encoding="application/x-tex">Y</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.68333em;vertical-align:0em;"></span><span class="mord mathdefault" style="margin-right:0.22222em;">Y</span></span></span></span> 的指针时，将 Y 元素中的第 N 层指针更新为 <span class="katex"><span class="katex-mathml"><math><semantics><mrow><msub><mi>X</mi><mi>N</mi></msub></mrow><annotation encoding="application/x-tex">X_N</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.83333em;vertical-align:-0.15em;"></span><span class="mord"><span class="mord mathdefault" style="margin-right:0.07847em;">X</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.32833099999999993em;"><span style="top:-2.5500000000000003em;margin-left:-0.07847em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathdefault mtight" style="margin-right:0.10903em;">N</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> 的当前值，然后将<span class="katex"><span class="katex-mathml"><math><semantics><mrow><msub><mi>X</mi><mi>N</mi></msub></mrow><annotation encoding="application/x-tex">X_N</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.83333em;vertical-align:-0.15em;"></span><span class="mord"><span class="mord mathdefault" style="margin-right:0.07847em;">X</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.32833099999999993em;"><span style="top:-2.5500000000000003em;margin-left:-0.07847em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathdefault mtight" style="margin-right:0.10903em;">N</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> 设置为 Y 的地址。</li>
<li>如上图所示：
<ul>
<li>Compaction 线程出栈 C0→E
<ul>
<li>图8b，因为 C0 当前指向了 F0，所以合并的时候就需要把 E0 指向 F0。但是 E1 这时候没有指向，但无伤大雅，不影响查询的正确性。</li>
<li>图8c，把 C0 指向 E0，好结束</li>
</ul>
</li>
<li>出栈 C1→E
<ul>
<li>图 8d，设置 E1 指向原来 C1 指向的位置 F1，然后让 C1 指向 E1</li>
</ul>
</li>
<li>后续操作同理</li>
</ul>
</li>
<li>Zipper 压缩假定 8 字节指针更新是原子的。为了保证指针更新 failure-atomic，它使用内存 fence 和 cacheline 刷新指令立即持久化每个底层更新。在最后一步中，压缩线程从 MANIFEST 对象中删除 L0 PMTable 的头元素，从而完成压缩。</li>
</ul>
<h3 id="lock-free-search">Lock-Free Search</h3>
<ul>
<li>Zipper 压缩不会违反并发搜索的正确性，也就是说，一个读线程不会在不获取锁的情况下错过它的目标 SkipList 元素。这是因为读线程从头到尾、从L0到L1访问PMTables，而压缩线程则从尾到头合并它们。在 Zipper 压缩期间，每个元素都保证是指向至少一个 head（<strong>即肯定是能追溯到的</strong>）。考虑图 8 所示的示例，它显示了一个原子存储指令序列如何合并两个示例 skiplist。即使并发读线程以图 8 所示的任何状态访问 PMTables，它也会返回正确的结果。</li>
<li>即使在压缩线程修改 SkipLists 的过程中读取线程挂起，该算法仍然是正确的。例如，假设读取在访问 L0 元素时挂起。当它恢复时，元素可能已经合并到 L1 中。当读线程醒来时，如果没有找到搜索键，它将继续遍历到尾部。一旦到达尾部，它就结束了 L0，并开始搜索 L1，L0 的元素已经合并到 L1 中。因此，读线程可能会多次访问相同的元素，但它永远不会错过它正在搜索的元素。多次访问可能会影响搜索性能。为了避免这种情况，如果读操作检测到当前元素的级别是 L1，它将停止搜索 L0。</li>
</ul>
<h3 id="updates-and-deletes">Updates and Deletes</h3>
<ul>
<li>LSM 树中的更新会重复相同的键，因为写操作会缓冲到 MemTables 中，并逐渐刷新到最后一层。<strong>ListDB 不会主动删除 L1 中的旧版本</strong>。相反，当压缩线程扫描 L0 和 L1 级别以进行 Zipper 压缩时，它将标记 L1 中的旧版本过时。类似地，ListDB 中的删除并不会物理地删除对象，而是将一个 key-delete 对象插入到 MemTable 中。如果 LSM 树从 MemTables 或 L0 PMTables 中物理删除密钥的最新版本，则旧版本的密钥将恢复使用。Zipper 压缩将较新的键值或键删除对象放在其对应的旧对象之前。因此，读查询总是在旧对象之前访问最近的对象，从而返回正确的搜索结果。</li>
</ul>
<h3 id="fragmentation-and-garbage-collection">Fragmentation and Garbage Collection</h3>
<ul>
<li>通过使用 libpmemobj库，ListDB为PMDK的故障原子事务中的多个 IUL 条目分配和释放一个内存块(例如，8 MB)，从而可以减少对昂贵的PMDK事务的调用数量。如果一个内存块中的所有元素都被标记为过时或删除，则 ListDB 将释放该内存块。注意，ListDB 不会重新定位 SkipList 元素以进行垃圾收集。为了解决持久的碎片问题，压缩线程可以执行基于 CoW 的垃圾收集。作者把这个优化留给以后的工作。</li>
<li>无锁数据结构的内存管理是一个困难的问题，因为没有简单的方法来检测被释放的内存空间是否仍然被并发读取访问。ListDB 使用简单的基于 epoch 的回收；ListDB 不会立即释放内存块，但会等待足够长的时间，让短期的读查询完成对释放内存块的访问。如果内存块中的所有对象都被废弃或删除，后台垃圾收集线程会定期检查并回收内存块。对于过时的对象，垃圾收集线程检查其新版本的 LSN。如果它也足够老，它认为过时的对象没有被任何读取访问，从 L1 PMTable 中删除它们，并物理地释放内存块。</li>
</ul>
<h2 id="look-up-cache">Look-up Cache</h2>
<ul>
<li>ListDB 要求读查询至少访问两个索引，即一个可变的 MemTable 和 L1 PMTable。因此，ListDB 的读吞吐量明显低于高度优化的持久 B+ 树。</li>
<li>ListDB 引入了查询缓存，Flush MemTable 将每个元素散列到一个固定大小的静态散列表中。与基于磁盘的设计不同，查找缓存不会复制其中的元素，而只存储它的 NVMM 地址，因为 NVMM 中的元素已经在内存地址空间中，而且它的地址永远不会改变。因此，无论 PMTable 元素出现在哪个级别，查找缓存都可以定位到 PMTable 元素。ListDB 中的压缩线程经常更新 SkipList 指针，但是通过缓存不可变的地址，而不是可变的内容，查找缓存可以避免频繁的缓存失效。如果一个桶发生哈希冲突，旧的地址将被覆盖(即FIFO替换策略)。</li>
<li>ListDB 在 DRAM 中构造一个SkipList，作为从哈希表中移除的高元素的二级查找缓存。第二级查找缓存的目的是加速 PMTable 搜索。即使在第二级查找缓存中没有找到一个键，查询也可以从缓存中找到的最近的 PMTable 元素开始搜索。假设读操作查找键 100，但是发现元素 85 是 L1 中最近的更小的元素。然后，从 L1 PMTable 中的 85 号元素继续搜索，而不是 L1 的开头。ListDB 不使用第二级查找缓存进行 L0 搜索，因为小的 L0 PMTables 很快被合并到 L1 中，L0元素大部分缓存在查找哈希表中，第二级查找缓存使用 SIZE 替换策略[58]，即比较高度并剔除高度较短的元素。</li>
</ul>
<h2 id="recovery">Recovery</h2>
<ul>
<li>当 L0 和 L1 PMTables 被 Zipper 压缩合并时，系统可能会崩溃。为了从这样的故障中恢复，压缩线程执行微日志记录来跟踪哪个 L0 PMTable 被合并到L1 PMTable中。当系统重新启动时，ListDB 检查压缩日志以重做未完成的压缩。对于重做操作，由于 L0 PMTable 尾部的许多条目可以与 L1 PMTable 共享，因此 Zipper compaction 需要检查重复的条目。</li>
<li>ListDB的恢复算法，与传统LSM树的恢复算法类似。首先，恢复进程定位WAL的边界，该边界由压缩线程记录在压缩日志中。然后，它对日志条目进行排序并恢复L0 PMTables。此时，系统返回到正常执行模式并开始处理客户端查询。L0和L1之间的压缩将在后台正常进行。</li>
<li>对于查找缓存，ListDB 可以在不恢复缓存的情况下处理客户端查询，尽管在填充缓存之前搜索性能会很差。通过避免 DRAM 缓存和索引的重构，ListDB的恢复性能优于同步检查点</li>
</ul>
<h1 id="evaluation">Evaluation</h1>
<h2 id="测试-index-unified-logging">测试 Index-Unified Logging</h2>
<h3 id="flush-and-put">flush and put</h3>
<ul>
<li>关闭 Zipper Compaction，WAL 中 put 比 WAL 好因为内存写入比 内存拷贝到 NVMM 更快，put 的性能抖动尖刺代表的就是新的空的 Memtable 创建储来，5s 填充一个 Memtable，40s 达到 Memtable 的阈值限制，阻塞后续写。如果提高阈值，stall 也只是时间长短的问题，因为 flush 比写慢。</li>
<li>IUL 的 flush 比 写快，但是 flush 波动，每个 flush 花的时间比 put 少，但是 compaction 线程可能挂起空闲了，所以波动。flush 吞吐高因为 IUL 不从 DRAM 拷贝数据到 NVM，不调用 cacheline flush 指令，因此，写入停顿不会发生，压缩线程通常会变得空闲，从而允许 CPU 执行其他工作。</li>
</ul>
<figure data-type="image" tabindex="7"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%206.png" alt="Untitled" loading="lazy"></figure>
<h3 id="ycsb">YCSB</h3>
<ul>
<li>不同线程，后台 Compaction 线程设置为前台客户端现成的一半，开启了 Zipper Compaction。</li>
<li>80线程之前，两种 log 方式性能都有提升，但是，当客户机线程的数量超过逻辑核心的数量时，由于过高的超额使用速率，吞吐量会下降。也就是说，100 个客户机线程和 50 个后台压缩线程竞争 80 个逻辑核。然而，IUL 的吞吐量比WAL高 99%。</li>
<li>YCSB-B C D 两种方式性能差不多，有时候甚至WAL更好，因为WAL执行copy-on-write 操作以按键升序存储记录，而读操作得益于比 IUL 更高的内存访问局部性。但在工作负载 A (50:50 Read:Write) 中，IUL 的写性能优于 WAL。</li>
</ul>
<figure data-type="image" tabindex="8"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%207.png" alt="Untitled" loading="lazy"></figure>
<h2 id="测试-braided-skiplist">测试 Braided SkipList</h2>
<ul>
<li>对比 不考虑 NUMA 的 Obl, Delegating 方案 Deleg，写优化的本地跳表 Local。</li>
<li>BR 和 Obl 管理一个大的 PMTable，而 Deleg 和 Local 创建四个小的PMTable。根据散列键删除分区键值记录，但是 Local 允许写客户端在其本地 NUMA节点上插入数据到 SkipList，而不考虑键。因此，一个读查询必须搜索所有四个 skiplist。即使在本地索引中找到了一个键，它也必须搜索远程索引，因为远程索引可能有最近的更新。因此，当有 n 个NUMA节点时，本地访问的比例始终为 1/n。</li>
<li>写操作 Local 最好，因为总是写入到本地跳表，几乎消除了远程 NUMA 访问。BR 差一点，因为访问到底层的数据指针的时候需要访问远端节点，Deleg也完全删除了远程NVMM访问，但是由于委托开销，写响应时间要高得多。也就是说，线程使用缓慢的原子指令来访问共享队列，并为查询和结果复制内存。图11(b)显示，队列延迟占80个客户机线程的查询响应时间的77.1%。因为在无锁索引上的 put/get 操作是非常轻量级的，委托引起的同步开销占据了总体响应时间。</li>
<li>读操作：图12(a)显示BR对于读查询的响应时间比其他方法要低。虽然Local在写方面优于BR，但Local的读响应时间大约是BR的4倍，因为Local必须搜索所有4个pmtable。尽管BR避免了访问跟随远程元素的更有效的搜索路径，但图11(a)和12(a)表明它对遍历长度几乎没有影响。Deleg显示最少的内存访问。但是由于同步开销，它的查询响应时间比BR高出约2倍，性能甚至低于Obl。</li>
</ul>
<figure data-type="image" tabindex="9"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%208.png" alt="Untitled" loading="lazy"></figure>
<h2 id="整个系统测试">整个系统测试</h2>
<ul>
<li>图13给出了ListDB的因子分析。我们启用和禁用ListDB的每个设计特性，并随着时间的推移测量写吞吐量(表示为put)、刷新吞吐量(MemTable L0 → PMTable，表示为 flush)和Compaction吞吐量(L0→L1 PMTable，表示comp)。我们为YCSB Load A运行了80个客户机线程和40个后台压缩线程，插入5亿个8字节的键和8字节的值。</li>
<li>图13(a)显示禁用所有三种优化会导致客户端线程暂停超过50秒。如图13(b)所示，启用Zipper压缩可以提高 L0→L1压缩吞吐量，但是由于刷新MemTable的内存拷贝开销，仍然会出现写停顿问题。如果使用了Braided SkipList，则可以避免在刷新MemTable时访问远程NUMA节点。因此，刷新吞吐量增加了一倍，从而降低了写停顿的频率，如图13(c)所示。同时启用Zipper压缩和Braided SkipList可以缩短写暂停时间，工作负载在120秒内完成(图13(d))</li>
<li>如果使用IUL而不是WAL，则刷新吞吐量与 PUT 吞吐量相当，如图13(e)所示。通过避免昂贵的内存拷贝，写停顿的频率比WAL要低。但是，请注意，压缩吞吐量比刷新吞吐量低得多。这会增加L0 PMTables的数量，降低搜索性能。如图13(f)所示，如果另外启用了IUL和Zipper压缩，那么NVMM带宽会通过减少内存副本的数量来提高。因此，它提高了压缩和刷新吞吐量。如图13(g)所示，启用IUL和Braided SkipList可以避免NUMA效应，从而提高压缩和刷新吞吐量。最后，启用所有三个优化后，工作负载在65秒内完成，几乎没有写入停顿(图13(h))，而图13(a)中的时间为300秒。</li>
</ul>
<figure data-type="image" tabindex="10"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%209.png" alt="Untitled" loading="lazy"></figure>
<h2 id="故障恢复">故障恢复</h2>
<ul>
<li>我们评估了针对ListDB的异步增量检查点和周期性同步检查点的恢复性能。使用Facebook基准测试，我们用1亿个对象填充数据库，并使用检查点和提前写日志条目测量恢复的时间。尽管使用相同的工作负载，同步检查点的恢复性能受检查点间隔的影响，而异步检查点只受查询到达率的影响。这是因为日志条目的数量随异步检查点而变化，而后台压缩线程还没有合并到 L1中。如果查询到达率高于 Zipper 压缩吞吐量，IUL 条目的数量会增加，恢复过程必须创建一个更大的 L0 PMTable，其中包含更多的日志条目。</li>
<li>图14显示了一个同步检查点使用Boost库中的 binary_oarchive 类序列化和刷新内存中的B+树大约需要90秒。这将导致并发查询在检查点执行期间阻塞90秒，导致不可接受的高尾延迟。为了缓解这个问题，可以降低检查点的执行频率，但是随着日志条目的增加，恢复时间会增加(即，恢复检查点索引并向其插入日志条目的时间)。</li>
<li>相反，图14 (b)显示，如果写查询到达率低于300万次/秒，ListDB就会立即恢复。如果查询到达率在700万到900万插入/秒之间变化，ListDB需要大约19秒来恢复。查询到达率越高，ListDB的恢复时间就越长。</li>
</ul>
<figure data-type="image" tabindex="11"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%2010.png" alt="Untitled" loading="lazy"></figure>
<h2 id="对比其他设计">对比其他设计</h2>
<ul>
<li>图15所示的实验比较了ListDB与最先进的持久索引的性能;即BzTree [1]， FP-tree [49]， FAST and FAIR B+tree[24]，和PACTree[32]，我们在一个双套接字机器上运行实验，因为PACTree是硬编码的两个套接字。采用Intel Xeon Gold 5215处理器(共40个逻辑核)、128gb DRAM (8 * 16GB)、1tb DCPMM (8 * 128gb)。数据库预加载了1亿条键值记录，然后40个客户端提交1000万个查询，这些查询具有不同的读写比率，分布均匀(由YCSB Workload A生成)。这些树结构索引没有针对(或不支持)大的可变长度字符串键和值进行优化。因此，我们为工作负载生成了8字节的数字键和8字节的指针值，这有利于具有较大扇出的树结构索引。</li>
<li>图 15 显示，对于写密集型工作负载，ListDB的性能优于树状结构的持久索引。对于只写工作负载，ListDB(0GB)的吞吐量分别比BzTree、FPTree、FAST和FAIR B+tree和PACTree高79倍、17倍、2.3倍和1.6倍。但是，对于只读工作负载，树结构索引受益于更快的搜索性能。特别是，FAST和FAIR B+树和PACTree显示的搜索吞吐量分别比ListDB(0GB)高3.88倍和4.61倍。在启用了查找缓存后，ListDB的性能优于树状结构的索引。图键中圆括号中的数字显示了查找缓存的大小。如果查找缓存大于768 MB, ListDB的性能优于PACTree，除非读比率高于80%。</li>
<li>这些结果证实了标准缓存技术可以很容易地提高读取性能。但是，索引键值记录位置的查找缓存不能用于PACTree、FAST FAIR B+tree、FPTree等，因为它们经常会因为树的再平衡操作而将键值记录重新定位到不同的树节点上。也就是说，为树状结构的持久索引使用DRAM缓存不像我们的仅地址查找缓存那么简单。例如，Nap[57]具有非常复杂的缓存机制。</li>
<li>虽然LSM树比树结构索引有更好的写性能，但它们有更高的写放大，这是块设备存储的一个关键限制[21,41,53]。为了比较写入放大，我们使用Intel PMwatch[25]来测量在图15所示的实验中访问的总字节数。所有的索引方法都存在写放大的问题。DCPMM的内部写合并缓冲区将一个小的写操作(8字节的键和8字节的值)转换为256字节的读-修改-写操作，导致至少16倍的写放大。在ListDB中，L0和L1 PMTables中的归并排序操作进一步放大了写操作。然而，ListDB(104.4)的写扩增比FAST和FAIR B+tree(126.789)低，与PACTree(91.5)相当，因为ListDB会对SkipLists进行合并排序。</li>
<li>图16显示了NoveLSM、SLM-DB、Pmem-RocksDB和ListDB的单线程读写吞吐量。这些实验运行一个单客户机线程(db_bench, 1亿个随机的8字节键和1 KB值)，因为当多个线程并发访问数据库时，NoveLSM会崩溃。NoveLSM和SLM-DB被设计成使用NVMM作为块设备文件系统之上的中间层，但是我们的实验将所有sstable存储在使用EXT4-DAX格式化的NVMM中，以便进行公平的比较。</li>
<li>NoveLSM表现出最差的性能，不是因为它的设计，而是因为它是在LevelDB之上实现的，众所周知，LevelDB的性能很差。SLM-DB也是在LevelDB之上实现的，但是性能更好，因为它使用FAST和FAIR B+树作为核心索引。由于SLM-DB还没有移植到使用PMDK，所以它没有运行时刷新或事务更新带来的开销，也就是说，它显示DRAM性能，并且不会在系统崩溃时存活下来。尽管如此，SLM-DB的性能并不比完全持久的键值存储Pmem-RocksDB更好。与Pmem-RocksDB相比，ListDB(0GB)的写吞吐量是Pmem-RocksDB的两倍，但读性能略差，除非启用了查找缓存。这是因为Pmem-RocksDB得益于内存位置，它以有序的顺序连续地将键存储在NVMM中，而ListDB不重新定位数据</li>
</ul>
<figure data-type="image" tabindex="12"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%2011.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>最后，我们在Facebook基准测试中使用Prefix Dist工作负载，比较ListDB和Intel的Pmem-RocksDB的性能。图17所示的实验运行了80个客户机线程，并使用基准的默认键和值大小(48字节字符串键和16字节到10 KB不等的可变长度值)。工作负载根据查询到达率(QPS参数)提交查询，该查询到达率遵循噪声因子为0.5的正弦分布。工作负载的put/get比率为3比7。</li>
<li>最后，我们在Facebook基准测试中使用Prefix Dist工作负载，比较ListDB和Intel的Pmem-RocksDB的性能。图17所示的实验运行了80个客户机线程，并使用基准的默认键和值大小(48字节字符串键和16字节到10 KB不等的可变长度值)。工作负载根据查询到达率(QPS参数)提交查询，该查询到达率遵循噪声因子为0.5的正弦分布。工作负载的put/get比率为3比7。</li>
<li>对于空闲工作负载，Pmem-RocksDB受到过多NVMM写入的影响，因此它的put吞吐量在200 Kops时饱和。对于Facebook基准测试，get查询必须等待它的前一个put查询提交。因此，实验中Pmem-RocksDB的get吞吐量在400 Kops处饱和。相反，图17(b)显示ListDB的吞吐量遵循正弦分布，即查询到达率，没有阻塞查询。</li>
<li>对于高负载，Pmem-RocksDB的吞吐量仍然处于饱和状态。另一方面，ListDB的put吞吐量比Pmem-RocksDB高25倍，即500万次。同样，ListDB的get吞吐量比Pmem-RocksDB高22倍(即1300万vs 60万)。因此，ListDB完成工作负载的速度比Pmem-RocksDB快19.4倍(即380比7400秒)。</li>
</ul>
<figure data-type="image" tabindex="13"><img src="https://blog.shunzi.tech/post-images/ListDB//Untitled%2012.png" alt="Untitled" loading="lazy"></figure>
<h1 id="conclusion">Conclusion</h1>
<ul>
<li>在这项工作中，我们设计并实现了ListDB——一个利用字节寻址的键值存储，通过就地重构数据来避免数据复制，以及NVMM的高性能来减少写放大和避免写停滞。我们展示了ListDB通过异步增量检查点和就地压缩显著提高了写性能。通过它的三层结构，ListDB在写吞吐量方面优于最先进的持久索引和基于nvmm的键值存储。标准的查找缓存可以帮助缓解具有多个级别的问题。在未来的工作中，我们正在探索通过引入另一个层次，即L2 PMTable来提高搜索性能的可能性，以机会主义地重新排列L1 PMTable元素，用于空间局部性和垃圾收集</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[p2KVS: a Portable 2-Dimensional Parallelizing Framework to Improve Scalability of Key-value Stores on SSDs]]></title>
        <id>https://blog.shunzi.tech/post/p2KVS/</id>
        <link href="https://blog.shunzi.tech/post/p2KVS/">
        </link>
        <updated>2022-07-12T03:40:00.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>p2KVS: a Portable 2-Dimensional Parallelizing Framework to Improve Scalability of Key-value Stores on SSDs</li>
</ul>
</blockquote>
<h1 id="p2kvs-a-portable-2-dimensional-parallelizing-framework-to-improve-scalability-of-key-value-stores-on-ssds">p2KVS: a Portable 2-Dimensional Parallelizing Framework to Improve Scalability of Key-value Stores on SSDs</h1>
<h1 id="abstract">Abstract</h1>
<ul>
<li>通过将速度较慢的硬盘驱动器(hdd)替换为速度更快的固态硬盘驱动器(ssd)来提高键值存储(KVS)性能的尝试一直未能达到ssd和hdd之间的巨大速度差距所暗示的性能提升，特别是对于小KV项目。我们通过实验和整体探索了现有基于lsm树的 kvs 运行在具有多核处理器和快速ssd的强大现代硬件上性能低下的根本原因。我们的发现表明，在单线程和多线程执行环境下，全局预写日志(WAL)和索引更新(MemTable)可能成为与常见的lsm树压缩瓶颈一样基本和严重的瓶颈</li>
<li>为了充分利用成熟KVS和底层高性能硬件的性能潜力，我们提出了一种可移植的二维KVS并行化框架，称为p2KVS。在水平的kvs -instance维度上，p2KVS将一个全局KV空间划分为一组独立的子空间，每个子空间由一个LSM-tree实例和一个固定在一个专用核上的专用工作线程来维护，从而消除了共享数据结构上的结构性竞争。在垂直的intra-KVS-instance维度上，p2KVS将用户线程从kvs -worker中分离出来，并在每个worker上提供基于运行时队列的机会批处理机制，从而提高了进程效率。由于p2KVS被设计和实现为一个用户空间请求调度器，将WAL、MemTables和lsm树作为黑盒来查看，因此它是非侵入性的，具有高度的可移植性。在微观和宏观基准测试下，p2KVS比最先进的RocksDB提高了4.6×写和5.4×读的速度。</li>
</ul>
<h1 id="introduction">Introduction</h1>
<h2 id="动机测试">动机测试</h2>
<ul>
<li>SSD 相比于 HDD 有更高的 IO 带宽 10x，更高的 IOPS x100。图1a表明，尽管RocksDB在高级 SSD 上的读性能提高了2个数量级，但它在ssd和hdd之间的<strong>写性能几乎没有变化</strong>。</li>
<li>最近的研究[19,36]和我们的实验结果一致表明，<strong>较小KV对的写工作负载会使系统的主机 CPU 核过载，而不是受到系统IO带宽的瓶颈</strong>。</li>
</ul>
<figure data-type="image" tabindex="1"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>然而，提高处理能力的一种幼稚的方法是通过调用更多的用户线程来充分利用多核CPU的能力。图1b 显示，即使有8个用户线程，对于顺序PUT、随机PUT和UPDATE的写工作负载，每秒查询(QPS)性能也只分别提高了40%、150%和160%，远远没有达到理想的线性扩展。但是，与单线程情况相比，在写工作负载下，从基于hdd的系统到基于ssd的系统，三个8线程情况的性能提高不到10%，除了更新操作情况提高了40%。这意味着，RocksDB的设计初衷是充分利用优质SSD，最大限度地提高QPS[22]，但在小型KV工作负载下仍然存在瓶颈。</li>
</ul>
<figure data-type="image" tabindex="2"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%201.png" alt="Untitled" loading="lazy"></figure>
<h2 id="相关工作">相关工作</h2>
<ul>
<li>以前的研究表明潜在的瓶颈主要表现在 logging （SIGMOD’18 FASTER），索引（FloDB）以及 Compaction（SILK，LDC，WiscKey）阶段。</li>
<li>大量的现有 KVs 研究
<ul>
<li>提出了新的全局数据结构来代替 LSM（SplinterDB，SLM-DB，KVell）</li>
<li>提出了局部优化
<ul>
<li>缓存：LightKV，SplitKV，NoveLSM，SCM LSM，MatrixKV</li>
<li>日志：FASTER，SpanDB</li>
<li>并发索引：No Hot Spot Non-blocking Skip List，Asynchronized Concurrency，UniKV:</li>
<li>Compaction：PebblesDB，LSM-trie</li>
</ul>
</li>
<li>工业界也有利用硬件优势来进行优化，比如批量写入，并发跳表，多线程压缩</li>
<li>带有多个实例的KVS分片机制广泛用于公共数据库实践，以利用实例间的并行性
<ul>
<li>HBase</li>
<li>The RocksDB Experience</li>
<li>Column Families of RocksDB</li>
<li>RocksDB tuning guide</li>
<li>Nova-LSM</li>
<li>DocDB</li>
</ul>
</li>
</ul>
</li>
<li><strong>现有的工作不能全面有效地解释和解决高性能硬件的性能可扩展性差。</strong></li>
</ul>
<h2 id="理论分析">理论分析</h2>
<ul>
<li>前台任务首先写 WAL，然后执行写索引，然后后台任务执行 compaction。</li>
<li>为了帮助理解成熟的kvs在快速的ssd和强大的处理器上性能低下的根本原因，我们使用经过良好优化的RocksDB进行了一系列实验(详见第3节)。结果提供了三个揭示性的发现。
<ul>
<li>首先，对于单个用户线程，日志记录或索引都可能造成严重的计算瓶颈，严重限制随机的小型写操作的性能。只有当日志记录和索引不再是瓶颈时，LSM-tree压缩才会成为存储瓶颈。</li>
<li>其次，增加用户线程的数量会产生一些边际效益，因为共享日志和索引结构上的争用非常多，用户线程越多，争用就越严重。</li>
<li>第三，具有多个实例的KVS分片机制仍然受到多个用户线程争用的影响，以及低效的日志记录和索引</li>
</ul>
</li>
</ul>
<h2 id="本文贡献">本文贡献</h2>
<ul>
<li>为了克服现有 KVs 的缺陷，提出了可移植的二维并行 KVS 框架来高效利用成熟的生产环境中的 KVs 实现和底层的高性能硬件。
<ul>
<li>首先，水平维度，采用了一个调度方案来协调多个工作线程，每个线程专门绑定核心，维护自己的单独的 WAL 日志，Memtable，以及 LSM tree，来减小共享数据结构上的争用</li>
<li>其次，垂直层面，设计了一个全局的 KV 访问层来把用户线程和 KVs 工作线程区分开，访问层应用策略把进来的请求分发到工作队列中，进行负载均衡</li>
<li>第三，在每个worker中提出了一种基于运行时队列的机会批处理机制。对于队列中未完成的写请求，OBM 合并它们以分摊 kv 处理和日志记录的开销。对于未完成的读请求，OBM 调用现有的 multiget 功能，提高处理效率。</li>
</ul>
</li>
<li>与多实例KVS配置不同，p2KVS显式地消除了实例上用户线程之间的潜在争用，同时利用批处理机制来提高效率</li>
<li>本文的目标是构建一个在 RocksDB 上的基于线程的并行框架，充分利用硬件特征同时保留它们现有的功能和内部设计，因此本文的方案是互不干扰的且非侵入式的。</li>
<li>贡献
<ul>
<li>我们通过实验和整体分析并确定了运行在快速ssd和多核处理器上的kvs伸缩性差的根本原因。</li>
<li>我们提出了p2KVS，一个可移植的二维KVS并行化框架，以统一有效地利用KVS实例之间和实例内部的内部并行性。我们进一步设计了一个基于队列的机会批处理机制，以提高每个工人的处理效率。</li>
<li>我们分别在RocksDB、LevelDB和WiredTiger的[49]上实现了p2KVS原型，并在流行的宏基准和微基准下进行了大量的实验来评估它。与目前最先进的基于lsm树的RocksDB和PebblesDB相比，p2KVS对小型kv的写速度可达4.6x，读速度可达5.4x。它还优于最先进的基于非lsm树的KVell。</li>
</ul>
</li>
</ul>
<h1 id="background">Background</h1>
<ul>
<li>LSM 不做介绍</li>
</ul>
<h2 id="rocksdb-并发优化">RocksDB 并发优化</h2>
<ul>
<li>作为一个经过良好优化的基于生产级 LSM 树的KVS, RocksDB 通过利用硬件并行性实现了许多优化和配置，以提高其QPS性能。RocksDB中的并发写进程示例如图 3 所示。关键并发性优化如下：</li>
</ul>
<h3 id="group-logging">Group Logging</h3>
<ul>
<li>当多个用户线程并发提交了写请求，RocksDB 将其组织成为一个组，其中一个线程被选中作为 leader 负责聚合该组内的其他线程的日志项，然后一次写入日志文件，其他线程也就是所谓的 follower，挂起直到日志文件写入完成，减少了实际的日志 I/O，因此提升了 I/O 效率。</li>
</ul>
<figure data-type="image" tabindex="3"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%202.png" alt="Untitled" loading="lazy"></figure>
<h3 id="并发-memtable">并发 Memtable</h3>
<ul>
<li>RocksDB 支持并发跳表索引，提升 Memtable 的插入的 QPS 约 2x，像 Group Logging，在更新全局元数据时，会同步一组并发更新MemTable的用户线程</li>
</ul>
<h3 id="pipelined-write">Pipelined Write</h3>
<ul>
<li>RocksDB 把不同组的日志和索引更新步骤流水线化了来减小阻塞</li>
<li>基于 LSM 的 KVs 一般提供了请求批处理操作，也就是 WriteBatch，允许用户执行多个写类型的请求，RocksDB 将所有请求的日志记录操作合并到一个WriteBatch中，就像组日志记录机制一样。</li>
</ul>
<h1 id="root-causes-of-poor-scalability">Root Causes of Poor Scalability</h1>
<h2 id="单线程">单线程</h2>
<ul>
<li>五组实验，128B KV，10M 条，顺序和随机写，随机 UPDATE，顺序和随机读，分别在 HDD/SATA SSD/NVMe SSD 上测试。</li>
<li>写性能没变化，读性能倒是有很大提升
<ul>
<li><strong>单线程写性能表现较差，读性能较好</strong></li>
<li><strong>8 线程写性能表现类似</strong></li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="4"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%203.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>
<p>下图展示了一个用户线程插入小 KV 对应的随时间变化的性能，顺序和随机。CPU-core 利用率为 100% 的线程分别只占用 SSD IO 全带宽的 1/6 和 1/20。连续的随机写操作会触发相应的后台线程执行周期性的刷新和压缩，这些线程会消耗大约 25% 的 CPU-core 利用率。</p>
<ul>
<li>现象：<strong>无论是随机写还是顺序写，无论是小 KV 还是大 KV，都远低于 SSD 的实际带宽</strong>
<ul>
<li>顺序写的带宽低于随机写，小KV 的带宽低于大 KV</li>
<li>随机写 大 KV 的吞吐相对最接近设备带宽</li>
</ul>
</li>
<li><strong>原因</strong>：<strong>无论是随机写还是顺序写，无论是小 KV 还是大 KV，前台线程 CPU 都接近满载</strong>
<ul>
<li>除了大 KV 随机写以外，CPU 基本都是满载 ****</li>
</ul>
</li>
<li>现象：<strong>随机写因为受到 Compaction 的影响会有较大的性能波动</strong>
<ul>
<li>小 KV 随机写，后台线程大约需要使用 25% 的 CPU，前台线程 100%</li>
<li>大 KV 随机写，后台线程大约需要使用 60% 的 CPU，前台线程 70%</li>
</ul>
</li>
<li>现象：<strong>大 KV 相比于小 KV 性能表现相对更好</strong>
<ul>
<li>原因：小 KV 的 CPU 满载的现象更严重，因为常常小 KV 意味着更多的数据条数，软件栈上的执行的请求数更多</li>
</ul>
</li>
</ul>
</li>
<li>
<p>当 CPU-core 利用率约70%的用户线程连续插入随机大KV对(即1KB)时，后台线程的周期性 compaction 操作仅消耗23% IO带宽和60% CPU-core利用率，如图4b所示。</p>
</li>
<li>
<p>以往的研究大多认为LSMtree压缩是严重影响整体性能的主要因素，因为LSMtree压缩具有写停顿和写放大的高IO强度[1,3,18,41,43,46,50,54]。<strong>事实上，使用小型KV对的写工作负载会使 CPU 核过载，但IO带宽利用不足，而使用大型KV对的写工作负载则恰恰相反</strong></p>
<ul>
<li>ForestDB，TRIAD，Dostoevsky，WiscKey，SifrDB，PebblesDB，LSM-trie，MatrixKV</li>
</ul>
<figure data-type="image" tabindex="5"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%204.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
<h2 id="多线程">多线程</h2>
<ul>
<li>多核处理器和基于NVMe的ssd分别具有足够的计算能力和高并行度的IO能力。自然，利用强大的硬件增加用户线程的数量可以提高KVS的总体吞吐量。另外，在实践中，数据库从业者也可以简单地在高级硬件上配置多个独立的KVS实例，以提高整体性能。在此分析中，我们考虑由多个用户线程访问的单实例和多实例两种情况。每个KVS实例都有自己独立的日志文件、MemTable和LSM-tree。</li>
<li>下图 a 所示为扩展性，在所有并行优化的单实例情况下，写QPS的伸缩性仍然很差，在32个用户线程时只能获得微薄的 3x加速。它的吞吐量在24个线程时达到峰值，而在此之后进一步扩展则显示收益递减。与单实例情况相比，多实例情况提升80%的高吞吐量和更好的可伸缩性，其吞吐量峰值低于16个线程/实例。
<ul>
<li>现象：<strong>单实例，24线程达到峰值，绑核之后效果更好，多实例提升明显，且伸缩性更好，但 16 线程达到峰值</strong>
<ul>
<li><strong>结论：使用多实例带来的扩展性更好，绑核也能让扩展性变好</strong></li>
</ul>
</li>
</ul>
</li>
<li>图 b 则表明 compaction 不再是瓶颈。至少不是主要的瓶颈，即便是多线程情况下。在 16 线程时达到峰值，只有 1/5 的 SSD I/O 带宽，其中 compaction 占据的带宽也不足总的 3/4。和单用户线程类似，前台用户线程的利用率接近 100%，后台线程消耗的 CPU 利用率相对较低。
<ul>
<li>现象：<strong>单实例，多线程写操作的 I/O 带宽远小于实际的设备带宽，其中 Compaction 开销很小，不是主要开销。</strong>
<ul>
<li><strong>结论：随着并发增加，Compaction 占据的开销比例变化不大，即并发条件下，Compaction 不是瓶颈</strong></li>
</ul>
</li>
<li>现象：单实例，多线程写操作对应的前台线程 CPU 满载，后台线程随着并发数的增加 CPU 开销变大，但是也还没有到 CPU 极限。
<ul>
<li><strong>结论：随着并发增加，主要瓶颈是来自于前台线程的 CPU 满载</strong></li>
</ul>
</li>
</ul>
</li>
<li>图 a 还表明了绑核能带来 10%-15% 的性能收益，因为不需要切换 CPU</li>
</ul>
<figure data-type="image" tabindex="6"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%205.png" alt="Untitled" loading="lazy"></figure>
<h2 id="处理时间">处理时间</h2>
<ul>
<li>
<p>下图展示了不同线程在单个实例下的延迟分解，写流程分成五个步骤，WAL，Memtable，WAL Lock，Mmetable Lock and Others.</p>
<ul>
<li>WAL 代表写前日志的执行时间，包括 I/O 时间和其他（编码日志记录，计算校验和，以及添加到写日志的 memory buffer）</li>
<li>Memtable 代表插入键值对到 Memtable，超过 90% 都是更新跳表索引信息</li>
<li>WAL Lock 表示与组日志机制相关的锁开销，包括领导线程执行 WAL 时其他用户线程的锁获取时间，以及领导线程通知其他线程完成 WAL 执行的时间。</li>
<li>Memtable Lock 代表同一组线程并发写 MemTable 时的线程同步时间</li>
<li>其他代表其他软件开销</li>
</ul>
</li>
<li>
<p>锁开销：随着写入器数量的增加，WAL 和 MemTable 的 CPU 周期百分比从单个线程时的 90% 下降到 32 个线程时的16.3%，而总锁开销(即WAL锁和MemTable 锁)从几乎为零增加到 81.4%。更多的写入器会对共享数据结构(如日志和MemTable)引入更严重的争用。特别是，只有 8 个线程的 WAL-lock 占用了一半以上的延迟。<strong>根据 Amdahl 定律，在小型KV对的高并发工作负载下，对特定日志和索引结构的优化不再有效，因为序列化瓶颈占延迟的较大比例</strong>。</p>
</li>
<li>
<p>造成高锁开销的主要原因有三个。首先，</p>
<ul>
<li>RocksDB 的组日志策略由 leader 进行日志写入序列化的操作，并挂起follower;</li>
<li>第二，组中的线程越多，用于解锁 follwer 线程的 CPU 时间就越多;</li>
<li>最后，将多个线程插入到MemTable中会带来同步开销。</li>
</ul>
</li>
<li>
<p>现象：<strong>单实例，随着线程数增加，延迟也不断增加，其中加锁操作带来的开销比例也不断增加</strong></p>
<ul>
<li><strong>原因</strong>：<strong>因为涉及到跳表并发写的同步操作，以及 Group Logging 的同步操作，线程数增加，争用越大，延迟越高</strong></li>
</ul>
<figure data-type="image" tabindex="7"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%206.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
<h2 id="multi-threading-a-double-edged-sword">Multi-threading, a Double-edged Sword</h2>
<ul>
<li>如上所示的实验结果表明，多线程在利用并行性方面的优势可以被线程之间在共享数据结构(如日志和索引)上的争用所抵消。因此，应该找到一个谨慎的权衡，以达到最佳的整体结果。考虑到这一点，接下来，我们将研究多线程对日志记录和索引这两个关键瓶颈的影响。我们实验分析了128字节KV工作负载下WAL进程单实例和MemTable进程多实例的性能，如图8所示</li>
</ul>
<h3 id="wal">WAL</h3>
<ul>
<li>如图6所示, WAL 的平均延迟降低从一个用户线程 2.1微妙到在 32 个用户线程 0.8 微妙。这是因为分组日志策略将来自不同线程的小日志收集到更大的IOs中，从而提高了IO效率。</li>
<li>为了演示批处理机制对写性能的影响，我们在将几个128字节的键值对批处理为 256 字节到 16KB 大小的WriteBatch请求时，测量了WAL的带宽和CPU使用情况，如图7所示。<strong>在RocksDB的默认配置中，启用了RocksDB的异步日志记录方式，以消除每次小IO后由于fsync引起的写放大</strong>。结果表明，<strong>请求级批处理机制不仅可以通过IO大小提高SSD的带宽利用率，还可以通过IO栈中软件开销的减少有效降低CPU负载</strong></li>
<li>现象：<strong>更大的 writebatch，更高的 I/O 带宽利用，更高的性能，更低的 CPU 利用率</strong>
<ul>
<li><strong>原因：因为更大的 batch，节省更多的小 I/O 造成的写放大，因为 I/O 更大，也减小了 I/O 栈上的软件开销，CPU 开销也就降低</strong></li>
<li><strong>结论：使用 Batch 机制有利于改进性能，并提升 I/O 带宽利用，降低 CPU 开销</strong></li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="8"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%207.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>图8a显示，使用批处理的单实例情况下，如果有32个线程，QPS提高了 2x，而多实例情况下，如果有4个线程，QPS的峰值超过 2.5x QPS。底层SSD中有限的IO并行性在很大程度上决定了多实例情况下日志记录线程的最佳数量</li>
</ul>
<h3 id="index">Index</h3>
<ul>
<li>不同于上面的记录过程中，总体吞吐量MemTable索引更新过程中的尺度在单实例和多实例的情况下，如图8 b所示</li>
<li>虽然更新的延迟 MemTable 增加从单个线程2.9微妙到 32 线程的 5.7 微妙。而且，多实例的情况明显优于单实例的情况。具体来说，在图8b中，前者在32 线程时吞吐量增益达到 10.5xQPS，而后者在 32 线程时仅提高了 3.7xQPS。这种性能差距主要源于同步开销和后者中共享并发 skiplist 的收益递减。这表明，尽管并发的 MemTable 允许多个线程并行地插入到 skiplist 中，<strong>但其可伸缩性是有限的</strong>。</li>
<li>综上所述，单实例和多实例情况在使用高性能硬件部署到当前KVS架构时，都显示出了各自在可伸缩性方面的优势和劣势。
<ul>
<li>对于<strong>WAL日志瓶颈</strong>，虽然单实例情况可以通过利用批处理机制而始终受益于线程伸缩，但多实例情况可以获得更高的日志吞吐量性能，但实例间的并行性有限。</li>
<li>另一方面，在多实例情况下总体索引更新性能比在单实例情况下更好，因为在前者中没有<strong>锁争用。</strong></li>
<li>此外，由于WAL和MemTable位于同一个KVS写关键路径上，在进程流中，前者位于后者之前，因此总体吞吐量受到两个进程中较慢进程的限制。这些观察和分析表明，<strong>充分利用底层高性能硬件的KVS处理体系结构的设计应该全面考虑实例间和实例内并行性、日志记录和索引之间以及计算和存储开销之间的相互作用和权衡</strong></li>
</ul>
</li>
<li>现象：<strong>单实例多线程以及启用 batch 能够带来写日志的性能提升，但不如多实例。多实例下 WAL 性能也会受到器件本身的并行性的影响</strong>
<ul>
<li><strong>结论：只使用 batch 的单实例多线程方案虽然能带来 WAL 的性能提升，但不如多实例</strong></li>
<li><strong>实例内的并行性是不够的，还需要考虑实例间的并行性。</strong></li>
</ul>
</li>
<li>现象：<strong>单实例多线程以及启用 batch 能够带来写 Memtable 的性能提升，但不如多实例。多实例优势更明显</strong>
<ul>
<li><strong>结论：只使用 batch 的单实例多线程方案虽然能带来 Index 的性能提升，但不如多实例</strong></li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="9"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%208.png" alt="Untitled" loading="lazy"></figure>
<h1 id="design-and-implementation">Design and Implementation</h1>
<ul>
<li>在前几节中，我们深入的实验分析促使我们提出了一个可移植的二维并行KVS框架，称为p2KVS，以有效地利用成熟的产品KVS实现(如RocksDB)和现代硬件的力量。p2KVS采用了以下三方面的设计方法。
<ul>
<li>利用实例间并行性，在多个KVS实例之间进行水平键空间分区。p2KVS采用多个KVS-worker线程，每个线程绑定在不同的核上。每个worker运行一个KVS实例，带有自己独立的WAL日志、MemTable和LSM-tree，从而避免共享数据结构上的争用</li>
<li>使用全局KV访问层公开实例内部并行性。p2KVS设计了一个全局KV访问层，将用户线程和kvs工作线程分开。接入层将来自应用程序的所有KV请求策略性地分配到worker队列，在有限数量的worker之间实现负载均衡。</li>
<li>使用基于队列的机会批处理来缓解日志记录和索引瓶颈。p2KVS在每个worker中提供了一种基于运行时队列的机会批处理机制，以分摊kv处理和日志记录的开销。</li>
</ul>
</li>
</ul>
<h2 id="arch">Arch</h2>
<ul>
<li>垂直维度多了一个访问层，水平维度维护了一组工作线程，每个线程跑一个 LSM 实例，且有自己的请求队列，绑定核心。</li>
</ul>
<figure data-type="image" tabindex="10"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%209.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>每个<strong>用户线程</strong>处理分配给自己的请求。
<ul>
<li>每个用户线程只根据分配策略将请求提交到相应 worker 的请求队列中 (1)，</li>
<li>然后挂起自己而不会进一步消耗 CPU (2)</li>
</ul>
</li>
<li>工作线程
<ul>
<li>批量处理入队请求 【1】</li>
<li>在对应的 KV 实例中执行 【2】</li>
<li>请求处理结束【3】</li>
<li>挂起的拥有线程将被通知返回（3）</li>
</ul>
</li>
<li>请注意，请求处理会消耗worker的CPU资源。RocksDB中的主要和次要的压缩操作是由属于KVS实例的后台线程执行的。这些实例内并行性优化依赖于KVS实例的实现，而p2KVS与它们完全兼容</li>
</ul>
<figure data-type="image" tabindex="11"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2010.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>p2kv维护一个全局标准KV接口，如PUT、GET、DELETE、SCAN等，并期望对上层应用程序完全透明。但是，它将KV请求重定向到内部分片的KVS实例，提供了实例间的并行性。请注意，虽然数据库和应用程序通常利用用户特定的语义(例如，RocksDB[20]的列语义)来为底层的多个KVS实例分配键值对，但p2KVS为上层应用程序提供了标准的KV接口，而没有额外的语义。此外,p2KVS还扩展了异步写接口(例如, 𝑃𝑢𝑡 (𝐾, 𝑉 , 𝑐𝑎𝑙𝑙𝑏𝑎𝑐𝑘))), 一个用户线程不会被正在处理请求阻塞。</li>
</ul>
<h2 id="balanced-request-allocation">Balanced Request Allocation</h2>
<ul>
<li><strong>为了公平分配和调度，本文用了简单的基于取模的哈希函数来实现，对键 Hash 然后取模对应的 worker 数，的到线程 ID</strong>。worker 数的设定是根据测试的硬件的并行性来设定的，根据原文的硬件测试结果设置为了 8。基于哈希分区的优势：负载均衡，最小的开销，没有读放大（分区之间没有键重叠）</li>
<li>增加 worker 数或者调整哈希函数可能导致重新构建 KV 实例，可以考虑采用一致性哈希。我们的实验结果表明，即使在使用Zipfian分布的高度倾斜的工作负载下，散列函数仍然可以使热请求均匀地分布在各个分区上。由于实例之间存在不平衡的可能性，例如，大多数热请求偶尔会被散列到某个worker上，p2KVS 在单个实例下被降级为 RocksDB。此外，p2KVS 可以配置适当的分区策略，以很好地匹配工作负载的访问模式，例如使用多个独立的散列函数 （DistCache）或动态键范围（NovaLSM）</li>
<li>注意，这个键范围分区相当于用多个互斥子键范围扩展全局 lsm 树中每一层的容量。因此，分区可以在一定程度上减少 compaction 导致的写放大，因为多个实例增加了LSM-tree的宽度，同时降低了它的深度</li>
</ul>
<h2 id="opportunistic-request-batching">Opportunistic Request Batching</h2>
<ul>
<li>
<p>如3.4节所示，对于小的写操作，请求批处理是减少IO和CPU开销的有效方法。此外，一些kvs(如RocksDB)对读类型请求有很好的并行优化。这些特性有助于提高每个 worker 的整体表现。</p>
</li>
<li>
<p>为了提升内部并行性，<strong>引入一个基于队列的请求批处理调度技术，简称 OBM</strong>，如下图所示。</p>
</li>
<li>
<p>当工作线程处理请求时，用户线程将请求添加到请求队列中。当worker完成一个请求的处理后，它会检查请求队列。<strong>如果有两个或更多连续的相同请求类型的传入请求(例如，读类型GET或写类型PUT、UPDATE和DELETE)，它们将合并成一个批处理请求，然后作为一个整体处理</strong>，如算法1所示。</p>
<figure data-type="image" tabindex="12"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2011.png" alt="Untitled" loading="lazy"></figure>
</li>
<li>
<p>对于写类型的请求，工作者将其作为WriteBatch处理。与 IO 级别的批处理(如RocksDB组日志记录)相比，这种请求级别的批处理更有利于减少线程同步开销。</p>
</li>
<li>
<p>对于读类型的请求，工作人员在KVS上并发查询它们。RocksDB提供了一个multiget接口，这是一个非常优化的操作来处理内部并发的键搜索，我们在实现中使用这个接口来处理读类型的批处理请求。</p>
</li>
<li>
<p>注意，worker 不会主动等待来捕获传入的请求。因此，这种批处理是机会主义的</p>
</li>
</ul>
<figure data-type="image" tabindex="13"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2012.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li><strong>OBM 可以通过消除同步和等待的开销来提高高并发工作负载下的处理效率。为了防止由于非常大的批处理请求而导致的尾延迟问题，我们为每批处理的请求数设置了预定义的上限(默认为32)</strong>。虽然<strong>不同类型的请求也可以在一个实例中并行处理，但OBM只会连续地合并相同类型的请求，以避免在使用异步接口时由于无序读写请求而导致的一致性问题</strong>。当队列在较低的工作负载下通常为空时，该方法只是降级为KVS，而不需要批处理。</li>
<li>总之，p2KVS 使用 OBM 机会主义地将多个小请求聚合为一个更大的请求，这不仅减少了写进程的软件和日志 IO 开销，而且还利用了并行读优化。与RocksDB 或其他 kvs 中的IO级批处理机制不同[SpanDB, KVell]，p2KVS避免了在底层IO层合并写操作时引入额外的同步开销。</li>
</ul>
<h2 id="range-query">Range Query</h2>
<ul>
<li>像其他使用哈希索引的 KVS 一样，p2KVS 实现范围查询操作(即 range 和 SCAN )是一个挑战，因为相邻的键可能被物理分布到不同的实例。键空间分区意味着一个范围查询必须被 fork 到对应的 worker 中，覆盖指定的键范围。幸运的是，每个分片实例使用自己的 LSM-tree 结构来保持其内部键的排序，有利于范围查询。</li>
<li>RANGE和SCAN之间存在语义上的差异，导致它们在p2KVS中的实现存在一些差异。RANGE 操作指定一个开始键和一个结束键，并读出它们之间所有现有的 KV 对。不同的是，SCAN 操作指定了一个开始键和随后要读取的KV对的数量(即扫描大小)。</li>
<li>当底层IO带宽足够时，一个RANGE请求可以被分成多个子RANGE操作，由多个p2KVS实例并行执行，而无需额外的开销。</li>
<li>对于SCAN操作，请求的键在实例中的分布最初是未知的，因此每个KVS实例中的目标键的数量不是先验确定的。
<ul>
<li>保守的方法是构造一个全局迭代器，基于每个KVS实例的迭代器，串行遍历整个密钥空间中的密钥，类似RocksDB MergeIterator。</li>
<li>p2KVS还提供了另一种并行化方法，它首先在所有实例上使用相同的扫描大小执行SCAN操作，然后从所有返回值中过滤出请求的kv。这种方法会导致额外的读取，可能会影响性能。</li>
<li>然而，实现的简单性和易用性以及底层硬件提供的高带宽和并行性可以合理地证明它的使用是合理的。</li>
</ul>
</li>
</ul>
<h2 id="崩溃一致性">崩溃一致性</h2>
<ul>
<li>p2KVS 保证了与底层 KVS 实例相同级别的崩溃一致性，每个实例都可以在崩溃或失败后通过重放自己的日志文件来恢复。</li>
<li>大多数基于lsm树的 KVS 支持基于 WriteBatch 的基本事务，其中同一个事务中的更新由一个 WriteBatch 提交。当一个包含多个实例的事务被执行时，该事务被拆分为多个并行运行在这些实例上的 writebatch，如果在崩溃前只提交了其中的一部分，就会导致一致性问题。</li>
<li>为了解决这个问题，p2KVS 为每个写请求引入一个严格递增的全局序列号(GSN)，以表明其唯一的全局顺序。GSN 可以作为原始日志序列号的前缀写入KVS日志文件。从同一个事务中分离出来的 writebatch 具有相同的 GSN 号，OBM 不会将它们与其他请求合并。</li>
<li>当一个实例崩溃时，p2KVS 根据崩溃实例日志中的最大 GSN 回滚所有实例中的日志记录请求。为了确保系统崩溃后的恢复，当事务初始化或提交时，p2KVS 将事务的 GSN 持久化到 SSD 上，从而在崩溃后通过取消每个 KVS 实例上相应的 WriteBatch 来回滚整个事务。例如，在图 11 中，在崩溃之前，事务A已经返回并记录了提交，事务B已经被kvs处理但没有提交，事务C还没有完成。当系统恢复时，p2KVS首先删除事务B和事务C的日志记录，因为事务日志显示最后一个提交的事务的GSN是事务A，然后对所有KVS实例执行恢复过程。我们进行了在写数据时杀死p2KVS进程的实验，结果表明p2KVS总是可以恢复到一致的状态。</li>
</ul>
<figure data-type="image" tabindex="14"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2013.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>目前，p2KVS专注于扩展基本KVS操作的性能(例如，批写和读)，在不修改底层KVS代码的情况下，确保任何单个请求在高并发下的原子性和崩溃一致性。在未来的工作中，我们将采用现有的事务优化[37,48]，并通过进一步利用KVS代码中的功能来支持更多的事务级别。例如，p2KVS可以使用RocksDB的快照特性来实现读提交事务隔离级别。每个worker都在WriteBatch处理之前创建一个实例的快照，其他读请求将访问该快照以避免脏读。当事务提交时，快照将被删除，事务中的更新将变得可见</li>
</ul>
<h2 id="portability">Portability</h2>
<ul>
<li>p2KVS 作为一种可移植的并行化框架，可以灵活地应用于现有的 kvs。本节描述p2KVS在两个代表性的kvs上的可移植性实现，即LevelDB(基于lsm树)和WiredTiger(基于B+树)。两者都使用WAL机制和共享索引结构</li>
<li>因为所有kvs都有三个基本功能，即初始化、提交请求和关闭。p2KVS将自己的逻辑插入目标KVS的这三个函数中，保持相应的API和进程不变。
<ul>
<li>在初始化步骤中，p2KVS创建多个实例和目录，在KVS的开放函数中存储它们自己的数据。</li>
<li>在请求提交步骤中，用户线程调用KV请求(例如put和get)，并执行分配策略将请求插入到相应实例的队列中。实例 worker 从请求队列中获取头部请求，并调用相同的KVS API(例如put和get)来处理KV操作。如果KVS具有批处理请求的专用功能，如RocksDB的Writebatch和multiget，则可以相应地启用OBM机制。</li>
<li>当p2KVS关闭时，每个worker调用KVS的close API。此外，任何worker崩溃都会导致整个系统关闭</li>
</ul>
</li>
<li>p2KVS 的 OBM-write 功能可以在 LevelDB 上通过批写来执行，而在 WiredTiger 上没有批量写。尽管LevelDB和WiredTiger没有像multiget那样的批读功能，p2KVS仍然可以利用OBM并发提交多个读请求来利用内部并行性。5.6节的实验结果表明，p2KVS可以有效提高LevelDB的并行度，WiredTiger的读写速度明显加快。</li>
</ul>
<h1 id="evaluation">Evaluation</h1>
<ul>
<li>我们以最先进的kvs(包括基于LSM-Tree的RocksDB和PebblesDB，以及基于Btree的KVell)为基准，在微基准和宏基准上评估了一个基于RocksDB的p2KVS原型。PebblesDB[46]是一种典型的写优化解决方案，它减少了压缩的写放大。KVell[36]通过使用非竞争的工作线程维护多个b -树索引来利用线程级并行性(详细信息请参见5.5节)。我们还在5.6节中评估了LevelDB和WiredTiger版本的p2KVS，以证明其可移植性。</li>
</ul>
<h2 id="实验配置">实验配置</h2>
<ul>
<li>我们在使用两个Intel Xeon E5-2696 v4 cpu (2.20 GHz, 22核)、64 GB DDR4 DRAM和一个Intel Optane 905p 480 GB NVMe SSD的服务器上运行所有实验。Optane SSD具有高且稳定的读写带宽，分别为2.2 GB/s和2.6 GB/s。我们使用带有4个或8个 worker 的两种p2KVS配置，分别标记为p2KVS-4和p2KVS-8。</li>
<li>我们使用微基准来比较p2KVS和基线的峰值处理能力。我们使用<strong>带有16个用户线程的db_bench工具执行 100M 个随机PUT操作，以评估并发写性能</strong>。p2KVS的异步接口使能，显示峰值性能。我们还分别<strong>执行10M的GET操作和1M的SCAN操作来评估读性能</strong>。在macro-benchmarks,我们使用 YCSB 来生成合成工作负载,其主要特征是表1中总结。我们分别在<strong>8个和32个用户线程的2组实验中评估了强并发和弱并发的性能</strong>。在两个基准测试中，KV对的大小默认设置为<strong>128字节</strong></li>
</ul>
<h2 id="micro">Micro</h2>
<ul>
<li>写性能、IO 放大、带宽利用率</li>
<li>虽然PebblesDB优化了 Compaction，IO放大比RocksDB和 p2KVS-4 低，<strong>但由于它是基于LevelDB开发的，没有对并发写进行优化，因此IO放大比p2KVS-8高</strong>。p2KVS几乎充分利用了SSD的带宽，而<strong>RocksDB和PebblesDB的带宽利用率不到20%</strong>。这是因为<strong>p2KVS通过消除前端瓶颈更频繁地触发压缩</strong>。显然，p2KVS的性能优势来自于它对底层硬件的高效容量利用</li>
</ul>
<figure data-type="image" tabindex="15"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2014.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>
<p>在表2中，我们展示了在p2KVS和其他kvs上处理100M随机写操作时内存和cpu的使用情况。</p>
<ul>
<li>
<p>在所有kvs中，平均内存使用量小于1.5 GB。p2KVS-4和p2KVS-8的CPU消耗分别超过单核的 7x和12x。</p>
</li>
<li>
<p>p2KVS的这些较高的CPU使用率来自于4或8个工作线程和额外的后台线程。用户线程在提交请求后休眠，只消耗很少的CPU资源。</p>
</li>
<li>
<p>RocksDB中的每个用户线程都会重载几乎整个CPU核，导致16个线程时巨大的CPU占用。<strong>然而，由于频繁的线程同步和锁开销，它的吞吐量很低</strong>。因此，<strong>后台压缩线程占用的CPU资源较少。</strong></p>
</li>
<li>
<p><strong>因为PebblesDB没有针对并发写进行优化，所以大多数并发用户线程都处于等待状态，只占总CPU资源的一小部分</strong>。</p>
</li>
<li>
<p><strong>p2KVS的内存消耗来自底层RocksDB实例的内存使用总和。这是可以接受的，也是稳定的，因为RocksDB实例的内存使用量不会随着数据量的增加而增加</strong></p>
<figure data-type="image" tabindex="16"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2015.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
</li>
<li>
<p>接下来，我们评估请求延迟作为负载强度的函数。我们在RocksDB和p2KVS上以不同的请求强度进行1M随机写操作。图13a显示了p2KVS和RocksDB在轻负荷下的平均延迟非常接近。</p>
<ul>
<li>然而，由于p2KVS具有更高的处理能力，它可以在相同的延迟下支持比RocksDB更高的强度。</li>
<li>我们进一步观察了尾部延迟，这是衡量KVS用户体验质量的一个重要指标。如图13 b, RocksDB遭受剧烈的延迟当请求峰值强度超过100 KQPS,而p2KVS能保证99푡百分比小于400 KQPS延迟低于1 ms的强度。</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="17"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2016.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>
<p>下图展示了多个 workers 和  OBM 下的点查询性能。我们向RocksDB和p2kv发起10M GET请求。</p>
<ul>
<li>
<p>如图14a所示，在没有OBM的情况下，p2KVS的性能与RocksDB基本相同。</p>
</li>
<li>
<p>通过利用RocksDB和OBM p2KVS的读优化，可以实现几乎线性的可伸缩性，如图14b所示。启用OBM的p2kv -8的QPS比禁用情况高出7.5倍，RocksDB高出5.4倍。</p>
<figure data-type="image" tabindex="18"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2017.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
</li>
<li>
<p>范围查询。我们加载100M 128字节KV对对系统进行预热，然后使用单个用户线程执行不同扫描大小的1M RANGE或SCAN操作。如图15所示，在RANGE查询中，</p>
<ul>
<li>p2KVS比RocksDB高出2.9个百分点。p2KVS在小范围扫描期间将QPS提高1.5倍，因为有足够的IO带宽来补偿读放大。短扫描的性能取决于查找操作，p2KVS对随机读的并行优化也加快了查找操作，从而提高了短扫描。</li>
<li>当扫描大小大于1000时，读放大倍数较高的p2KVS会使SSD IO容量饱和，性能与RocksDB相同。综上所述，p2KVS在RocksDB读优化的基础上进一步扩展了并行性的好处</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="19"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2018.png" alt="Untitled" loading="lazy"></figure>
<h2 id="macro-benchmark">Macro-benchmark</h2>
<ul>
<li>我们评估了p2KVS相对于RocksDB在具有8或32个线程的YCSB工作负载下的有效性，如图16所示。PebblesDB的结果被排除在外，因为它填满了所有的内存，并且在写入数亿KV对时崩溃。</li>
<li>在写密集型工作负载(LOAD)下，有更多的用户线程，p2KVS表现出更高的速度。例如，p2KVS8在8个和32个用户线程的情况下，比RocksDB的性能分别高出2.4和5.2。这是因为p2KVS不仅集成了RocksDB的OBM请求级批处理优化，而且还通过多个非竞争worker提高了并行效率，特别是在高并发工作负载(如32线程)下。p2KVS-8的性能提升比p2KVS4更明显，说明worker的数量应该与硬件并行度相匹配，才能使性能最大化</li>
<li>在读密集型工作负载(B、C、D)下，p2KVS比RocksDB提高了1~2xQPS。这种读性能的提高<strong>不仅来自于使用OBM来利用RocksDB原来的读并行性，还来自于哈希分区索引和并行工作者的额外好处</strong>。在工作负载E(即95% SCAN和5% PUT)下，<strong>p2KVS的性能与RocksDB类似，因为p2KVS利用IO并行性所获得的增益被读取放大所抵消</strong>。</li>
<li>在混合工作负载(A, F)下，p2KVS的性能比RocksDB高出1.5~3.5，主要是因为对并发写过程进行了优化。</li>
</ul>
<figure data-type="image" tabindex="20"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2019.png" alt="Untitled" loading="lazy"></figure>
<h2 id="sensitivity-study">Sensitivity Study</h2>
<ul>
<li>我们进行敏感性研究，以了解不同设计参数和p2KVS的选择对整体性能的影响。我们仍然使用YCSB作为工作负载，并使用带有单个用户线程的RocksDB作为基线。</li>
</ul>
<h3 id="worker-数量和obm">worker 数量和OBM</h3>
<ul>
<li>我们改变启用和禁用OBM的 worker 数量。结果如图17所示。在写密集型工作负载LOAD下，实例间并行性可以分别用4个和8个实例提高3x和5x性能。OBM利用请求批处理进一步加快了写速度，使QPS最多提高了2x。结果表明，在小型kv的情况下，仅仅增加实例的数量并不能显著提高性能。但是，当应用OBM时，写吞吐量可以很好地扩展。
<ul>
<li>在读密集型工作负载C下，实例间并行化将性能提高了3.3x和5.8x，分别为4个和8个worker。OBM甚至在单个实例中提高了5x读性能，但在8个worker中只能提高2xQPS，因为这种级别的并行性几乎耗尽了SSD的容量，导致OBM进一步利用的带宽不足</li>
<li>在混合工作负载A和B中，如果没有OBM，在4个实例和8个实例下，总体性能分别提高了3.5x和6.5x。OBM在工作负载B下增加了2.2 ~4.2x的QPS，而在工作负载A下获得的好处较少，增加了1.8 x~3.2x的吞吐量。这是因为工作负载B有更多的混合读和写请求，限制了OBM的批处理大小，OBM只批处理相同类型的相邻请求</li>
<li>由于SSD的争用，过多的worker甚至会导致性能下降。图17的实验结果表明，8是最优 worker 数量。</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="21"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2020.png" alt="Untitled" loading="lazy"></figure>
<h3 id="key-value-size">Key-value Size</h3>
<ul>
<li>接下来，我们观察不同KV尺寸的影响。我们在三个典型的工作负载(LOAD、a和C)中测试kv大小的性能，如图18所示。计算结果表明，<strong>小KV 比大 KV 从 OBM 中获得的收益更多</strong>。</li>
</ul>
<figure data-type="image" tabindex="22"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2021.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>图19 显示了 p2kv 在1KB KV下的性能，其速度比128字节KV下的速度要慢。<strong>OBM在大KV的写密集型工作负载下效率较低，因为合并大型日志IOs的好处很小。但是，OBM对于读密集型工作负载仍然有效</strong>。</li>
</ul>
<figure data-type="image" tabindex="23"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2022.png" alt="Untitled" loading="lazy"></figure>
<h3 id="对比-kvell">对比 KVell</h3>
<ul>
<li>KVell 使用多个worker来维护多个可以并行访问的独立 b 树索引。它对所有写请求使用就地更新，以避免写放大，并在内存中维护大索引和页面缓存，以加快查询。</li>
<li>通过使用宏基准测试，我们将带有4个或8个工作线程的KVell与p2KVS-4和p2KVS-8进行比较，如图20所示。我们将KVell的页面缓存大小配置为4GB，这消耗了可接受程度的内存，比每个RocksDB实例的8MB块缓存大得多。即使使用这种配置，由于内存中索引较大，KVell的最大内存消耗是22 GB，而p2KVS的内存消耗是3 GB。</li>
<li><strong>在写密集型工作负载(LOAD、A和F)下，p2KVS 的性能高于KVell</strong>。p2KVS 的点查询性能与KVell(工作负载B和D)相似，SCAN性能高于KVell(工作负载E)，<strong>在工作负载 C 下，KVell由于具有大页面缓存和全内存索引，吞吐量高于p2KVS</strong>。</li>
</ul>
<figure data-type="image" tabindex="24"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2023.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>
<p>我们还记录并比较p2kv -8和KVell-8在连续100M随机写工作负载下的IO带宽、内存和CPU的利用率。KVell-8和p2KVS-8的吞吐量分别为2.5 MQPS和3.0 MQPS。</p>
<ul>
<li>如图21a所示，KVell虽然使用了就地更新来减少写放大，但在小型的128字节KV写操作下，只消耗约300 MB/s IO带宽。相比之下，LSM-tree更适合聚合小型IOs，使p2KVS能够充分利用IO带宽。</li>
<li>图21b显示，即使减去页面缓存的占用空间，KVell仍然比p2KVS多使用2x内存，因为它将所有索引存储在内存中，而LSM-tree则对磁盘上的数据进行排序以减少索引大小。同时，KVell的每个线程都维护一个较大的索引，导致每个核的平均CPU利用率超过80%。但是，p2KVS下的每个RocksDB实例在前台和后台运行多个线程，分别执行日志记录和压缩。因此，虽然p2KVS的总CPU利用率更高，但每个核消耗大约50%的CPU，如图21c和21d所示。这意味着p2KVS更适合于多核硬件环境，不依赖于单核性能。因此，尽管KVell使用了一个较大的内存索引和页面缓存来获得比RocksDB更高的性能，但p2KVS可以通过使用更少的硬件资源来利用快速ssd来获得比KVell更好的性能。</li>
</ul>
<figure data-type="image" tabindex="25"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2024.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
<h3 id="portability-2">Portability</h3>
<ul>
<li>如4.6节所述，除了RocksDB，我们还将p2KVS移植到另外两个KVS, LevelDB和WiredTiger。在本节中，我们将评估p2KVS对提高两个KVS的并行性的效果。</li>
<li>图22显示了微基准测试下基于LevelDB实例的p2KVS的吞吐量。结果表明，即使LevelDB没有像RocksDB那样提供实例内并行性优化(例如，流水线写和多get)， p2KVS仍然可以比单线程LevelDB分别提高 3.4x 和 5.3x 的随机写和读性能。通过多线程，p2KVS 为 LevelDB 带来了写并行性，而不会损失读性能。</li>
</ul>
<figure data-type="image" tabindex="26"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2025.png" alt="Untitled" loading="lazy"></figure>
<ul>
<li>p2KVS WiredTiger。图23显示了p2KVS在WiredTiger上的吞吐量。虽然WiredTiger不支持批写，但p2KVS仍然可以有效地将其读写吞吐量分别提高到8.4和15。在相同的线程数下，p2KVS的性能优于WiredTiger。此外，<strong>当worker的数量超过12时，写性能会下降，这意味着并行性的好处不足以弥补过多实例的开销</strong>。</li>
</ul>
<figure data-type="image" tabindex="27"><img src="https://blog.shunzi.tech/post-images/p2kvs/Untitled%2026.png" alt="Untitled" loading="lazy"></figure>
<h1 id="related-works">Related Works</h1>
<h2 id="优化-wal-和-mt">优化 WAL 和 Mt</h2>
<ul>
<li>一些研究尝试直接解决写 WAL 或 MT 步骤中的低性能问题。</li>
<li>WAL
<ul>
<li>SIGMOD’18 FASTER 提出了混和日志机制来在 DRAM 上存储日志的大部分，从而提升 WAL 的性能，但是牺牲了快速持久化</li>
<li>VLDB’10 Aether 采用了一些复杂的方法，如早期锁释放和 Flush 管道，以减少并发引起的小日志写入争用。</li>
<li>VLDB’20 Taurus: 通过使用日志序列号跟踪和编码事务，进一步优化这些技术并实现高效的并行日志记录方案。</li>
<li>FAST’21 SpanDB：通过使用异步请求接口，SPDK通过基于轮询的IO提供异步组日志记录和请求处理。</li>
</ul>
</li>
<li>Memory
<ul>
<li>FloDB, Accordion, WipDB, CruiseDB 通过修改内存组件的数据结构来提高 MemTable 的写性能。</li>
<li>FloDB 和 Accordion 在基于skiplist的MemTable顶部添加缓冲区。</li>
<li>WipDB 将 skiplist 替换为多个大型哈希表，并将 kv 对压缩到内存中而不是SSD中</li>
<li>CruiseDB 根据工作负载和 SLA 动态调整 MemTable 的大小，减少写阻塞。</li>
<li>p2KVS 兼容这些工作，并可以吸收他们的思想，同时使用高效的并行调度来避免WAL和内存结构上的争用</li>
</ul>
</li>
</ul>
<h2 id="优化-lsm-压缩">优化 LSM 压缩</h2>
<ul>
<li>为了有效利用 SSD 的带宽，许多解决方案通过修改 LSM-tree 结构来降低写放大。
<ul>
<li>PebblesDB[46]设计了一个碎片化的 lsm-树结构，它允许在树级别上重叠键范围，并减少了大部分压缩开销。</li>
<li>LSM-trie[50]、SifrDB[43]、Dostoevsky[18]、SlimDB[47] 和 ChameleonDB[58] 也设计了一些 LSM-tree 的变体，通过允许重叠键范围来减轻写放大</li>
<li>ForestDB[1]、WiscKey[41]、lwb-tree[53]、HashKV[9]、UniKV[57]、DiffKV[38]采用KV分离机制，将KV对存储在多个日志文件中，并以LSM-tree级别记录键指针对，减少了大容量KV对的写放大。</li>
<li>虽然p2KVS的共同目标是优化基于lsm树的kvs的IO效率，但作为一个用户空间调优器，它与这些解决方案是正交和互补的，并且具有高度的可移植性，可以在现有的kvs上实现。</li>
</ul>
</li>
</ul>
<h2 id="设计非-lsm">设计非 LSM</h2>
<ul>
<li>一些研究设计了新的高性能ssd结构来代替lsm树。
<ul>
<li>KVell[36]在内存中维护大型基于b树的索引和页面缓存，以确保现代快速ssd上的GET和SCAN性能。</li>
<li>uDepot[33]将数据存储在由哈希表映射的无序段中，并通过利用任务运行时系统的异步用户空间IO来充分利用ssd盘。</li>
<li>Tucana[45]使用B𝜖-tree来减少开销和压缩的IO放大。</li>
<li>SplinterDB[14]基于B𝜖-tree设计STB𝜖-tree，针对硬件并行度高的ssd进行优化。</li>
<li>虽然这些新的索引结构充分利用了现代SSD，但p2KVS采用了一种正交方法，将KVS和SSD视为黑盒，因此继承了广泛使用和优化良好的基于lsm树的KVS(如RocksDB)和SSD经过时间考验的理想特性，提供了高可移植性。</li>
</ul>
</li>
</ul>
<h2 id="分片-kvs">分片 KVS</h2>
<ul>
<li>分布式数据库将表空间分区到多个平面上，并将它们存储在节点之间的不同KVS实例中。[2,11,27,60]
<ul>
<li>HBase, Bigtable，Nova-LSM，SolarDB</li>
</ul>
</li>
<li>最近，运行在高性能硬件上的基于LSM-tree的OLTP存储引擎使用了多个LSM-tree实例，每个实例用于存储一个表、子表或索引[19,26,52]。
<ul>
<li>The RocksDB Experience， X-Engine，Revisiting the Design of LSM-tree Based OLTP Storage Engine with Persistent Memory</li>
</ul>
</li>
<li>使用特定的接口语义(例如列)或动态调度策略来确定键值对所在的实例。</li>
<li>而p2KVS采用键空间分片的方式，在不使用数据库语义的情况下，均匀地将 KVs 分配给多个 worker，加快了全局 KVs 的速度。</li>
</ul>
<h1 id="conclusion">Conclusion</h1>
<ul>
<li>在生产级键-值存储环境中，系统管理员希望通过简单地将慢速hdd替换为快的ssd来获得一致的性能提升。结果往往令人失望，特别是对于普遍存在的小型KV工作负载。我们发现，在单线程和并发的写工作负载下，KVS写进程中的前台操作(日志记录和索引)可能成为严重的性能瓶颈。我们提出了一种便携式并行引擎p2KVS，基于lsm树的KVS的多个实例，以有效和高效地执行KV操作。p2KVS旨在利用这些实例之间和实例内部固有的并行性，以充分利用现代CPU、内存和存储硬件提供的处理能力。与最先进的RocksDB相比，p2KVS的写性能和读性能分别提高了4.6x和5.4x</li>
</ul>
<h1 id="一些问题">一些问题</h1>
<h2 id="multiget-带来的性能提升和数据路由策略之间的关系">Multiget 带来的性能提升和数据路由策略之间的关系</h2>
<ul>
<li>hash 公平路由之后一定程度丢失了数据的局部性信息，为什么 multiget 性能还能带来这么多优势</li>
</ul>
<p><a href="https://github.com/facebook/rocksdb/wiki/MultiGet-Performance">MultiGet Performance · facebook/rocksdb Wiki</a></p>
<h3 id="multiget">Multiget</h3>
<ul>
<li>在底层的RocksDB实现中查找键非常复杂。这种复杂性导致了大量的计算开销，主要是由于探测布隆过滤器时缓存丢失、虚函数调用分发、键比较和IO。需要查找许多键来处理应用程序级请求最终会在一个循环中调用 Get() 来读取所需的kv。通过提供接收一批键的 MultiGet() API, RocksDB 可以通过减少虚函数调用和 pipeline cache miss 的数量来提高 CPU 查找的效率。此外，可以通过并行执行 IO 来减少延迟。</li>
</ul>
<p><strong>读路径</strong></p>
<ul>
<li>一个典型的 RocksDB 数据库实例有多个级别，每个级别包含几十到数百个SST文件。点查找经过以下几个阶段(为了简单起见，我们忽略合并操作数并假设所有操作都是Put)
<ol>
<li>可变memtable被查找。如果为memtable配置了bloom过滤器，则使用整个键或前缀探测该过滤器。如果结果为正，则执行memtable rep查找。</li>
<li>如果没有找到键，将使用与#1相同的进程查找 0 个或多个不可变memtables</li>
<li>接下来，逐级查找SST文件如下-
<ol>
<li>在L0中，每个SST文件都是按倒序查询的 （因为倒序顺序即为新到旧）</li>
<li>对于L1及以上，每一层都有一个SST文件元数据对象的 vector，每个元数据对象包括文件中的最高键和最低键。在这个向量中执行二进制搜索，以确定与所需键重叠的文件。有一个辅助索引，它使用关于 LSM 中文件范围的预计算信息来确定下一层中与给定文件重叠的文件集。在 L1 中执行完整的二分搜索，该索引用于缩小后续级别的二分搜索边界。这就是所谓的分数级联。fractional cascading</li>
<li>一旦找到候选文件，就加载该文件的 bloom filter 块(从块缓存或磁盘)，并探测 key。这个探测很可能会导致 CPU cache miss。在很多情况下，最底层不会有 bloom filter。</li>
<li>如果探测结果为阳性，则加载SST文件索引块并进行二进制查找，找到目标数据块。筛选器和索引块可能必须从磁盘读取，但通常它们要么固定在内存中，要么被频繁地访问，以便在块缓存中找到它们。</li>
<li>加载数据块并进行二进制搜索以找到密钥。数据块查找更有可能在块缓存中丢失，从而导致IO。需要注意的是，<strong>每个块缓存查找也可能导致CPU缓存丢失，因为块缓存是由哈希表索引的</strong>。</li>
</ol>
</li>
<li>对每一层重复步骤 #3，L2和更高一级的惟一区别是SST文件查找的部分级联。</li>
</ol>
</li>
</ul>
<p><strong>MultiGet 性能优化</strong></p>
<ul>
<li>让我们考虑具有良好参考局部性的工作量的情况。在这种工作负载中连续的点查找可能会重复访问相同的 SST 文件和索引/数据块。对于这样的工作负载，MultiGet提供了以下优化-
<ul>
<li>当选择。设置 cache_index_and_filter_blocks=true 时，SST文件的过滤块和索引块将在每次键查找时从块缓存中提取。在有多个线程执行读操作的系统上，这将导致 LRU 互斥锁上的严重锁争用。对于与 SST 文件密钥范围重叠的整批密钥，MultiGet 只在块缓存中查找过滤器和索引块一次，从而大大减少了LRU互斥锁争用。</li>
<li>在步骤1、2和3c中，由于bloom filter探针，CPU cache miss会发生。假设一个数据库有6个级别，大多数键都在最底层找到，平均有2个L0文件，我们将有~6次缓存丢失，因为在SST文件中查找过滤器。如果配置了memtable bloom过滤器，可能会有额外的1-2个缓存丢失。通过对每个阶段的查找进行批处理，过滤器缓存行访问可以流水线化，从而隐藏了缓存 miss 延迟。</li>
<li>在大型数据库中，读取数据块很可能需要IO。这引入了延迟。MultiGet能够并行地对同一个SST文件中的多个数据块发出IO请求，从而减少延迟。这依赖于底层Env实现在同一线程中对并行读取的支持。在Linux上，PosixEnv 具有使用IO Uring接口为MultiGet()做并行IO的能力。IO Uring 是从5.1开始在Linux内核中引入的一种新的异步IO实现。注意，MultiGet有多种实现。只有返回void的方法执行并行IO。</li>
</ul>
</li>
</ul>
<h2 id="对比为什么不和多实例-rocksdb-对比">对比为什么不和多实例 RocksDB 对比</h2>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[InfiniFS: An Efficient Metadata Service for Large-Scale Distributed Filesystems]]></title>
        <id>https://blog.shunzi.tech/post/InifniFS/</id>
        <link href="https://blog.shunzi.tech/post/InifniFS/">
        </link>
        <updated>2022-04-05T03:40:00.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>InfiniFS: An Efficient Metadata Service for Large-Scale Distributed Filesystems</li>
</ul>
</blockquote>
<h1 id="infinifs-an-efficient-metadata-service-for-large-scale-distributed-filesystems">InfiniFS: An Efficient Metadata Service for Large-Scale Distributed Filesystems</h1>
<h1 id="摘要">摘要</h1>
<ul>
<li>现代数据中心更喜欢一个文件系统实例，它跨越整个数据中心并支持数十亿个文件。在这样的场景中，文件系统元数据的维护面临着独特的挑战，包括在保持局部性的同时实现负载平衡、长路径解析和接近根的热点。</li>
<li>为了解决这些挑战，我们提出了INFINIFS，这是一种针对大规模分布式文件系统的高效元数据服务。它包括三个关键技术。
<ul>
<li>首先，INFINIFS 解耦了目录的访问和内容元数据，因此可以通过元数据位置和负载均衡对目录树进行分区。</li>
<li>其次，INFINIFS 设计了预测路径解析，以并行遍历路径，这大大减少了元数据操作的延迟。</li>
<li>第三，INFINIFS 在客户端引入乐观访问元数据缓存，缓解了近根热点问题，有效提高了元数据操作的吞吐量。</li>
</ul>
</li>
<li>广泛的评估表明，INFINIFS在延迟和吞吐量方面都优于最先进的分布式文件系统元数据服务，并为多达1000亿个文件的大规模目录树提供稳定的性能。</li>
</ul>
<h1 id="introduction">Introduction</h1>
<ul>
<li>数据中心文件数量很多，很容易达到当前分布式文件系统单个实例的容量，所以一个数据中心一般分成很多个集群，每个集群跑一个分布式文件系统实例。但是如果整个数据中心只跑一个文件系统实例，这样做是比较理想的，因为提供了全局的数据共享，提高了资源利用，以及很低的操作复杂度。
<ul>
<li>例如，Facebook 引入了 Tectonic 分布式文件系统，将小型存储集群整合到一个包含数十亿个文件的单一实例中</li>
</ul>
</li>
<li>现代数据中心元数据量很大， 数以百亿甚至数千亿的文件，用一个大规模的文件系统来管理所有的文件元数据就会遇到挑战
<ul>
<li>目录树分区很难实现局部性和负载均衡的 tradeoff</li>
<li>路径解析的延迟可能很高，因为文件深度可能很深</li>
<li>客户端元数据缓存一致性的开销将因为并发客户端数目较多变得很大</li>
</ul>
</li>
<li>本文的方案
<ul>
<li>访问数据和内容数据解耦的元数据分区方法，来兼顾局部性和负载均衡
<ul>
<li>访问信息 name, ID, and permissions</li>
<li>内容信息 entry list and timestamps</li>
<li>细粒度分区
<ul>
<li>内部分区（高局部性）
<ul>
<li>访问元数据和其父目录 分区在一起</li>
<li>内容元数据和孩子节点数据分布在一起</li>
</ul>
</li>
<li>细粒度分组使用对于 directory id 的一致性哈希来分布（负载均衡）</li>
</ul>
</li>
</ul>
</li>
<li>预测路径解析来并行遍历目录树，减小了元数据操作的延迟
<ul>
<li>每个目录分配一个 predictable id，客户端可以通过计算预测出中间目录的 ID</li>
<li>多个组件的路径执行并行查询</li>
</ul>
</li>
<li>乐观访问元数据缓存来缓解近根节点的热点问题，实现可扩展的路径解析
<ul>
<li>客户端缓存目录的访问元数据信息，来吸收近根节点的查询压力</li>
<li>低开销的惰性缓存失效策略。
<ul>
<li>即针对访问元数据信息的修改操作，将发送一个失效通知给元数据服务器，而不是通知客户端</li>
<li>每个服务器可以在处理客户端请求的时候验证对应的缓存的状态（惰性）</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="background">Background</h1>
<h2 id="large-scale-filesystem">Large-Scale Filesystem</h2>
<ul>
<li>文件系统一般都是用的层级结构，也就是目录树来组织文件
<ul>
<li>每个文件/目录都有元数据信息</li>
<li>元数据操作包含两步：
<ul>
<li>路径解析：定位对应的目标文件，检查用户是否有权限访问</li>
<li>元数据处理：文件系统执行元数据处理操作来原子更新对应的元数据对象</li>
</ul>
</li>
</ul>
</li>
<li>元数据服务可扩展性是大规模分布式存储系统的瓶颈，即单个实例相对的元数据处理能力有限，所以很多公司数据中心都使用了多个集群（实例）来实现</li>
<li>但是其实使用一个集群实例比使用多个更好
<ul>
<li>全局数据共享：
<ul>
<li>全局的namespace，跨数据中心的数据共享更好实现</li>
<li>对比：专门的数据防止策略，数据迁移策略，计算服务逻辑也变复杂，因为需要进行数据的切分</li>
</ul>
</li>
<li>高资源利用
<ul>
<li>消除多个集群的重复数据，提升磁盘空间利用，实现更好的资源共享</li>
<li>对比：单个集群的空闲资源没法释放给其他集群</li>
</ul>
</li>
<li>操作符复杂度低：
<ul>
<li>只需要维护一个系统和维护多个系统的区别，劳动密集，出错概率高</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="challenges-of-scalable-metadata">Challenges of Scalable Metadata</h2>
<h3 id="目录树分区">目录树分区</h3>
<ul>
<li>目录树分区很难同时实现高元数据局部性和负载均衡，特别是在目录树扩张以及负载变化的情况下
<ul>
<li>局部性：文件系统操作经常都需要同时处理多个元数据对象。分布式文件系统中有了局部性，就可以避免分布式锁和分布式事务，从而实现低延迟和高吞吐
<ul>
<li>文件创建操作首先加锁父目录，以保证和目录 list 的串行，然后原子更新三个元数据对象（目录的 entry list，新建的文件元数据，目录时间戳）</li>
</ul>
</li>
<li>负载均衡：目录树中的元数据操作通常导致不均衡。
<ul>
<li>真实的数据中心负载经常把相关文件分组到一个子树，连续子树中的文件和目录可能在短时间内被大量访问，导致存储该子树的元数据服务器出现性能瓶颈</li>
</ul>
</li>
</ul>
</li>
<li>现有分区方案很难兼顾两个特性。管理数据中心中的所有文件可以使目录树在深度和广度上迅速扩展。而且文件系统面对的负载特征经常变化
<ul>
<li>细粒度的分区策略
<ul>
<li>哈希分区，虽然可以实现负载均衡，但是局部性缺失了，造成频繁的分布式锁和事务，引入了开销较大的协调操作，高延迟低性能</li>
</ul>
</li>
<li>粗粒度的分区策略
<ul>
<li>子树分区，将一个连续的子树分组到同一个服务器上，保持局部性并避免跨服务器操作。但易受负载偏置的影响，导致负载不平衡。</li>
</ul>
</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="1"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled.png" alt="Untitled" loading="lazy"></figure>
<h3 id="路径解析延迟">路径解析延迟</h3>
<ul>
<li>路径解析的延迟可能很高，因为在极其大规模的文件系统中，文件深度非常深</li>
<li>超过一半的访问对应的深度大于了 10</li>
<li>基于 Tectonic 的机制实现了原生的路径解析，发现随着深度增加，延迟也几乎线性增加
<ul>
<li>Tectonic 将目录分区到不同元数据服务器，基于对应的目录 ID，解析深度为 N 的路径需要解析 N−1 个中间目录，从而导致 N−1 个顺序的网络请求</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="2"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%201.png" alt="Untitled" loading="lazy"></figure>
<figure data-type="image" tabindex="3"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%202.png" alt="Untitled" loading="lazy"></figure>
<h3 id="客户端元数据缓存开销">客户端元数据缓存开销</h3>
<ul>
<li>
<p>客户端元数据缓存一致性维护的开销变得非常大，因为非常大规模的文件系统通常需要为大量并发的客户端服务</p>
</li>
<li>
<p>路径解析需要从根遍历目录树，并依次检查路径中所有中间目录的权限。这将导致大量读取接近根目录，即使是为了平衡元数据操作工作负载。文件系统的吞吐量将受到存储近根目录的服务器的限制。在本文中，我们称之为近根热点。许多分布式文件系统依赖于客户端元数据缓存来缓解接近根的热点</p>
</li>
<li>
<p>我们发现，以前的客户端缓存机制在大量客户端的大规模场景中不能很好地工作。</p>
<ul>
<li>例如，基于租约的机制为每个在固定期限后将过期的缓存条目授予租约。当租期到期时，相应的缓存条目将自动失效。在NFS v4、PVFS、LocoFS和IndexFS中广泛使用。</li>
<li>然而，由于近根目录的缓存更新，<strong>租约机制存在负载失衡的问题</strong>。</li>
<li>这是因为所有客户端都必须反复更新它们的近根目录的缓存条目，以进行路径解析。随着客户端数量的增加，这种近根目录上的负载不平衡最终将成为性能瓶颈，并削弱总体吞吐量</li>
</ul>
<p><a href="https://www.jianshu.com/p/e7f1cb23ce0d">分布式租约机制</a></p>
<p><a href="https://developer.aliyun.com/article/368269">分布式系统理论之租约机制学习-阿里云开发者社区</a></p>
</li>
</ul>
<figure data-type="image" tabindex="4"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%203.png" alt="Untitled" loading="lazy"></figure>
<h2 id="负载特征">负载特征</h2>
<ul>
<li>阿里云负载，Pangu 文件系统</li>
</ul>
<figure data-type="image" tabindex="5"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%204.png" alt="Untitled" loading="lazy"></figure>
<h1 id="design-and-implementation">Design And Implementation</h1>
<h2 id="overview">Overview</h2>
<ul>
<li>客户端：
<ul>
<li>全局文件系统目录树视图，客户端用用户态的库或者 FUSE 来通信</li>
<li>通过使用预测路径解析来遍历目录树</li>
<li>路径解析过程中使用乐观元数据缓存来减少近根热点读</li>
</ul>
</li>
<li>元数据服务器：
<ul>
<li>目录树分布在多个元数据服务节点</li>
<li>使用 访问信息和内容信息解耦的方式，同时实现高局部性和负载均衡</li>
<li>每个服务器在本地管理 KV 存储中存储元数据对象，在内存会缓存元数据，也会在 NVMe SSD 中使用日志记录更新操作</li>
<li>元数据服务器使用 失效列表 来惰性验证客户端元数据请求</li>
</ul>
</li>
<li>重命名协调器
<ul>
<li>中心化的 rename 协调器，处理目录 rename 和 目录的 set_premission 操作</li>
<li>使用 renaming graph 检查并发的目录 rename 操作避免循环</li>
<li>广播修改信息到元数据服务器的失效列表</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="6"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%205.png" alt="Untitled" loading="lazy"></figure>
<h2 id="access-content-decoupled-partitioning">Access-Content Decoupled Partitioning</h2>
<h3 id="问题理论分析">问题理论分析</h3>
<ul>
<li>以前方案无法兼顾局部性和负载均衡的根本原因：<strong>把目录元数据当作了一个整体</strong></li>
<li>使用分区目录树的时候，不得不把目录和他们的父节点或者子节点给分区到不同的服务器，也就不经意地打破了相关元数据的局部性</li>
</ul>
<h3 id="元数据原机制分析">元数据原机制分析</h3>
<ul>
<li>元数据的组成：
<ul>
<li>访问元数据：包含目录名，ID，权限。用于访问目录树的信息</li>
<li>内容元数据：entry list，时间戳等，和子节点更相关的数据信息</li>
</ul>
</li>
<li>元数据操作分类：
<ul>
<li>仅处理目标文件/目录元数据的操作，如 open、close、stat 等。
<ul>
<li>文件 stat 将只读取目标文件的元数据</li>
</ul>
</li>
<li>处理目标文件/目录及其父文件/目录元数据的操作，如 create、delete、readdir等。
<ul>
<li>例如，文件创建将首先插入文件元数据，然后锁定和更新父目录的 entry list 和时间戳。</li>
</ul>
</li>
<li>rename 操作是特殊的，因为它处理两个文件/目录及其父文件的元数据。</li>
</ul>
</li>
<li>第一类和第二类为大部分操作，需要在元数据处理过程中获取对应目标文件/目录的元数据。</li>
</ul>
<h3 id="解决思路">解决思路</h3>
<p><strong>局部性的考虑</strong></p>
<ul>
<li>所以我们就是如下图 c 所示的，<strong>把每个目录的内容元数据（蓝色）和对应子目录的访问元数据（红色）分组在一起</strong>。</li>
<li>这样目录树就被分成独立的每个目录组。同时保证了目录操作 readdire 以及文件操作 create/delete/open/close/stat/ set_permission 的局部性</li>
</ul>
<figure data-type="image" tabindex="7"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%206.png" alt="Untitled" loading="lazy"></figure>
<p><strong>负载均衡的考虑</strong></p>
<ul>
<li>根据局部性进行了分组以后，得到了很多个独立的 per-directory groups。</li>
<li>使用基于 directory id 的哈希，把这些分组分区到不同的元数据服务器，从而实现负载均衡
<ul>
<li>还是上图 c 所示，得到了四个组，包含了 C 的内容元数据和 f1 f2 的组被分区到服务器 1，那么在 C 目录下的文件创建操作就只需要在 MS1 上进行，因为只需要创建一个新的文件元数据，然后更新对应 C 的时间戳和 entry list</li>
<li>对于目录 C 的 readdir 操作也只涉及到 MS1，首先出于隔离性的考虑加锁 entry list，然后从 entry list 中读取到对应的文件名</li>
</ul>
</li>
<li>INFINIFS 利用了一致性哈希 GIGA+ 来映射细粒度的元数据分组到服务器，从而减小集群规模变化过程中的数据迁移</li>
</ul>
<p><strong>数据的存储</strong></p>
<ul>
<li>KV 存储来存储元数据，存储格式如下表所示，包含了三种类型的数据
<ul>
<li>目录访问元数据</li>
<li>目录内容元数据</li>
<li>文件元数据</li>
</ul>
</li>
<li>例子：访问 /A/B/file，假设 / A B对应的 ID 分别为 0，1，2
<ul>
<li>首先查询 &lt;0, A&gt; 得到 A 的访问信息，然后知道了 A 的 ID 为 1</li>
<li>查询 &lt;1, B&gt; 得到 B 的访问信息，知道了 B 的 ID 为 2</li>
<li>查询 &lt;2&gt; 得到了 B 的内容元数据信息，以及 &lt;2, file&gt; 得到了目标文件的元数据</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="8"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%207.png" alt="Untitled" loading="lazy"></figure>
<h2 id="speculative-path-resolution">Speculative Path Resolution</h2>
<h3 id="predictable-directory-id">Predictable Directory ID</h3>
<ul>
<li>
<p>INFINIFS 如何生成并维护 可以在未来根据 pathname 预测的目录 ID</p>
</li>
<li>
<p>Creating：</p>
<ul>
<li>创建一个新目录，生成对应目录 ID（<strong>根据 parentID, directory name，以及 name version</strong>），如下图 a 所示</li>
<li>创建目录的父目录被称为目录的 birth parent，用一个版本号来保证 birth triple 的唯一性</li>
</ul>
</li>
<li>
<p>Renaming：</p>
<ul>
<li>更改一个目录名称只需要修改对应的访问元数据信息，内容元数据和对应的 ID 是不会变得，因此，目录下的所有后代元数据都保持不变</li>
<li>当一个目录自创建以来第一次被重命名时，
<ul>
<li>它的父目录将记录一个重命名列表(RL)：每一项就是一个二元组 &lt;directory name, name version&gt;</li>
<li>然后目录本身会记录一个 back-pointer，&lt;birth parent’s ID, name version&gt;，目录的 RL 记录的就是其对应原生子目录的，但是可能现在已经迁移到了别处了</li>
<li>重命名目录的 BP 指向的是原来他所在的父节点 birth parent 目录，我们在创建目录时使用父目录的 RL 确定 name version</li>
</ul>
</li>
<li>举个例子：下图 b 所示即为 /A/B  rename 到 /B
<ul>
<li>如果 B 是第一次 rename，
<ul>
<li>那么 B 的访问元数据信息将从 2:B 改成 1:B （2和1分别为父目录的 ID），B 的 ID 是不会发生改变的</li>
<li>A 将记录从其中迁出的数据在 RL 中，记录一条 &lt;B, 0&gt;，作为 A 的内容元数据</li>
<li>B 会记录一条 BP 信息 &lt;2, 0&gt; 在 B 的访问元数据中，因为其原生父目录为 2</li>
<li>这时候如果在 /A 下创建一个新的 B
<ul>
<li>那么对应的 name version 就变成了 1，因为 RL 表明了以前这儿有一个 B 目录被 rename 了</li>
<li><strong>为什么需要更新版本号，因为 hash 计算如果不变版本号，就会算出一个相同的 directory id，就无法区分两个目录 B 了</strong></li>
</ul>
</li>
</ul>
</li>
<li>如果 B 不是第一次 rename 了
<ul>
<li>那么只需要更新对应的访问元数据，对应的内容元数据 BP，以及原生父目录的 RL 都不会变化</li>
</ul>
</li>
<li>当删除一个 renamed 目录的 birth parent 目录时，对应的访问信息和内容信息都会被擦除，但是其 RL 会被保留，只有当重命名的目录被删除时，RL 才会通过 BP 删除</li>
</ul>
</li>
<li>Deleting
<ul>
<li>删除一个重命名目录，使用对应的 BP 定位到原来的父目录，然后擦除对应的 RL</li>
<li>这时候创建一个新的该目录下的 /B，版本号就可以重置回 0 了</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="9"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%208.png" alt="Untitled" loading="lazy"></figure>
</li>
</ul>
<p><strong>ID 唯一性</strong></p>
<ul>
<li>目录 ID 是根据对应的三元组算出来的，三元组只要一个不同，那么算出来的 directory id 也就不同，除非哈希冲突</li>
<li>文件系统语义要求同一父目录中的两个目录在任何时候都不能有相同的名称。如果没有 rename 操作，那么二元组 &lt;<strong>birth parent’s ID, directory name</strong>&gt; 就够了，但是因为 rename 存在 ，所以一个目录下可能在 rename 前后拥有相同 name 的但是两个完全不同的目录，所以得用三元组</li>
<li>用加密哈希来生成 ID，比如 SHA-256，冲突的概率比较低，在目录创建的过程中也很容易检测到哈希冲突，直接使用版本号，RL，BP 来解决冲突</li>
<li>在 INFINIFS 中，冲突和重命名情况对后续的目录创建具有相同的影响，可以通过 RL 条目格式进行区分</li>
</ul>
<h3 id="并行路径解析">并行路径解析</h3>
<ul>
<li>基于前面可预测的目录 ID，客户端可以并行执行路径解析，如下两步
<ul>
<li>预测目录 IDs
<ul>
<li>客户端根据对应的路径的 rootID 预测所有中间目录的 IDs，它首先以 0 作为版本号重建 birth 三元组，然后重新计算哈希结果。</li>
<li>使用推测的目录 id，客户端为所有路径组成部分重建键。</li>
</ul>
</li>
<li>并行查询：
<ul>
<li>客户端并行发送查询请求查询中间目录，每个查询请求首先检查访问权限</li>
<li>然后比较推测的 ID 和存储在元数据服务器中的 ID</li>
<li>如果推测的 ID 不匹配，查询请求将返回真实的 ID 给客户端</li>
</ul>
</li>
<li>上面两个步骤不断重复直到解析完成</li>
</ul>
</li>
<li>下图展示了预测路径解析的机制
<ul>
<li>如果一个中间目录一旦被 rename 了，rename 的预测 ID 就会出错，即计算 /A/X 的 ID 的时候，发现 h(2,X,0) ≠ 12，<strong>因为</strong> h(1,X,0) = 12，12 是根据原来的父节点算出来的。</li>
<li>但是查询请求可以使用 &lt;2:X&gt; 找到 X 的访问信息，然后得到正确的 ID 返回给客户端，有了正确的 ID，就可以继续解析 X 的子路径了。</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="10"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%209.png" alt="Untitled" loading="lazy"></figure>
<h2 id="optimistic-access-metadata-cache">Optimistic Access Metadata Cache</h2>
<h3 id="缓存机制">缓存机制</h3>
<ul>
<li>本文的客户端缓存只缓存访问元数据，缓存命中将消除对近根目录的查找请求，从而避免根目录附近的热点，并确保可伸缩的路径解析。</li>
<li>缓存项还是基于文件系统的层次来组织，把叶子节点链接在了一起组成一个 LRU，来进行叶子节点的淘汰，近根目录将一直被缓存</li>
</ul>
<figure data-type="image" tabindex="11"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%2010.png" alt="Untitled" loading="lazy"></figure>
<h3 id="惰性缓存失效">惰性缓存失效</h3>
<ul>
<li>rename 操作以及 set_permission 操作可能让大量客户端缓存失效，在每个目录重命名操作期间，使所有关联客户端的陈旧缓存条目无效是不切实际的。因为客户端的成员很难管理，而且客户端的数量可能非常大，远远超过元数据服务器的数量。所以有了惰性缓存失效机制</li>
<li>该机制广播失效信息给元数据服务器，每个元数据服务器可以在执行对应的元数据请求的时候惰性地检查数据的有效性</li>
<li>rename 操作会联系中心化的 rename 协调器，避免陷入循环，然后广播对应的 rename 信息，一个中心化的 rename 协调器就够了，因为 rename 操作很少</li>
<li>所以 rename 的完整步骤如下：如下图 a 所示
<ul>
<li>发送 rename 操作给协调器，检查这个目录的 rename 是否和当前已有的操作发生 orphaned loops，然后协调器给每个 rename 操作分配一个自增的版本号</li>
<li>将 rename 操作和其他操作通过锁定目标目录来是进行串行化，所以新的访问需要阻塞等待 rename 结束。然后并行广播带版本号的 rename 信息给元数据服务器，等待确认。
<ul>
<li>元数据服务器维护一个失效队列并根据版本号排序来记录 rename 信息</li>
</ul>
</li>
<li>然后把目录的访问信息从 source server 移动到 dest server，并更新对应的 RL，BP 信息。</li>
</ul>
</li>
<li>惰性检查缓存是否失效的步骤如下：下图b
<ul>
<li>客户端不知道是否过时，并在路径解析期间乐观地利用本地缓存条目。
<ul>
<li>每个客户端都有一个本地版本，这表明在此版本之前，它的缓存已经通过重命名操作进行了更新。</li>
<li>当客户端与元数据服务器联系时，它会将请求连同路径名和版本一起发送出去</li>
</ul>
</li>
<li>元数据服务器通过比较无效列表中的路径名和重命名操作来验证是否过时。
<ul>
<li>只需要比较请求版本和失效列表中的最新版本之间的操作。如果服务器发现请求的路径名是有效的，则请求被成功处理并返回。</li>
</ul>
</li>
<li>如果服务器发现请求无效，它将中止请求并返回这些新的重命名操作的信息。然后客户机更新缓存和版本</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="12"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%2011.png" alt="Untitled" loading="lazy"></figure>
<h1 id="一致性">一致性</h1>
<h2 id="orphaned-loop">Orphaned Loop</h2>
<ul>
<li>什么是 Orphaned Loop？
<ul>
<li>并发的 rename 操作可能导致该现象</li>
<li>下图展示了由两个 rename 操作造成的 Orphaned Loop
<ul>
<li>图 a 表明了正常的文件目录树应该是一个有向无环图</li>
<li>图 b 的客户端 1 尝试 rename E 到 C 目录下，即 /D/E 变成 /A/B/C/E，修改的元数据 DEC</li>
<li>图 c 的客户端 2 尝试 rename B 到 F 目录下，即 /A/B 到 /D/E/F/B，修改的元数据 ABF</li>
<li>两个重命名所需的元数据对象彼此完全独立，因此允许并行执行。
<ul>
<li>但是它们会导致 Orphaned Loop，破坏目录树，如图8(d)所示。没有客户端可以访问 Orphaned Loop 中的任何文件</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>如何解决？
<ul>
<li>中心化的 rename 协调器，来在 rename 执行前检查</li>
<li>协调器维护了一个 rename graph，它跟踪正在运行的目录 rename 的源路径和目标路径。</li>
<li>在允许进行新的目录 rename 操作之前，协调器首先验证它是否会导致带有正在进行中的操作的 Orphaned Loop</li>
<li>在整个 rename 过程中，目录 rename 操作的源路径和目标路径都保存在重命名图中，并在重命名操作完成后删除</li>
</ul>
</li>
</ul>
<figure data-type="image" tabindex="13"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%2012.png" alt="Untitled" loading="lazy"></figure>
<h2 id="事务性的元数据操作">事务性的元数据操作</h2>
<ul>
<li>操作可以进行如下分类
<ul>
<li>单个服务器上的操作：readdir，create/delete/open/close/stat/ set_permission。直接利用 KV 的事务机制来实现
<ul>
<li>当元数据服务器在崩溃后重新启动时，它恢复元数据操作的事务，并告诉重命名协调器以更新其无效列表</li>
</ul>
</li>
<li>两个服务器上的操作：mkdir/rmdir/statdir，文件 rename
<ul>
<li>两阶段提交协议的分布式事务</li>
<li>由于客户机不可靠且难以跟踪，因此选择两个元数据服务器中的一个作为事务中的协调器。</li>
<li>为了从失败中恢复，协调器和参与者都使用预写日志记录事务的部分状态</li>
</ul>
</li>
<li>目录 rename: 目录重命名和目录set_permission
<ul>
<li>很少发生。</li>
<li>这些操作被委托给 rename 协调器，它检测 Orphaned Loop，将修改广播到所有元数据服务器，并跨两个服务器处理目标目录元数据。</li>
<li>这些操作是通过类似于双服务器操作的分布式事务来实现的，不同之处在于它们在事务中选择 rename 协调器作为协调器，并在提交阶段开始时广播修改。如果 rename 协调器在广播期间崩溃，它将重新启动并恢复事务，方法是重新启动广播，以确保修改至少被发送到所有服务器一次。</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="测试">测试</h1>
<ul>
<li>注意用的是 RAMDisk 测试，因为元数据大多都是缓存在内存里的</li>
<li>实现：
<ul>
<li>RPC： Thrift</li>
<li>KV Store: RocksDB</li>
</ul>
</li>
</ul>
<h2 id="整体性能">整体性能</h2>
<ul>
<li>INFINIFS在 mkdir、create、stat和delete元数据操作中呈现近乎线性的吞吐量可伸缩性，元数据服务器的数量从1扩展到32
<ul>
<li>对于路径解析，INFINIFS在客户端缓存近根访问元数据，以吸收近根目录上的读负载，因此路径解析导致的近根热点不会影响可伸缩性。此外，INFINIFS通过散列目录id在元数据服务器上划分文件/目录元数据。细粒度哈希分区策略有效地平衡了元数据访问，实现了高可伸缩性</li>
<li>对于元数据处理，INFINIFS解耦目录元数据，然后将目录访问元数据与父节点分组，将目录内容元数据与子节点分组。通过这种方式，<strong>create、stat 和 delete 的元数据处理只访问单个服务器，不需要跨服务器协调</strong>，因此具有可伸缩性。<strong>目录 mkdir 的元数据处理需要与两台服务器协调原子性</strong>，这也可以很好地扩展到更多的服务器。</li>
</ul>
</li>
<li>mkdir 操作的吞吐量远低于 INFINIFS 中create操作的吞吐量。这是因为文件创建是使用本地事务协议实现的，不需要跨服务器协调，而目录创建需要两阶段锁定和两阶段提交协议。这些分布式协议需要在服务器之间进行昂贵的协调，从而降低了吞吐量。</li>
</ul>
<figure data-type="image" tabindex="14"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%2013.png" alt="Untitled" loading="lazy"></figure>
<h2 id="优化分解">优化分解</h2>
<figure data-type="image" tabindex="15"><img src="https://blog.shunzi.tech/post-images/InfiniFS/Untitled%2014.png" alt="Untitled" loading="lazy"></figure>
<h2 id="其他测试">其他测试</h2>
<ul>
<li>参见原文</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[Modern CMake]]></title>
        <id>https://blog.shunzi.tech/post/6.NULL-1-ModernCMake/</id>
        <link href="https://blog.shunzi.tech/post/6.NULL-1-ModernCMake/">
        </link>
        <updated>2021-12-31T08:37:41.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>个人认为也可以包含在 6.NULL 系列的 CMake 教程</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>个人认为也可以包含在 6.NULL 系列的 CMake 教程</li>
</ul>
</blockquote>
<!--more-->
<h2 id="参考链接">参考链接</h2>
<ul>
<li><a href="./cmake.md">之前的 CMake 基础教程</a></li>
<li><a href="https://github.com/richardchien/modern-cmake-by-example">Modern CMake By Example</a></li>
<li><a href="https://www.bilibili.com/video/BV14h41187FZ/?spm_id_from=333.788">B站：IPADS新人培训第二讲：CMake</a></li>
<li><a href="http://c.biancheng.net/view/7097.html">Makefile 教程</a></li>
<li><a href="https://seisman.github.io/how-to-write-makefile/introduction.html">跟我一起写 Makefle</a></li>
<li><a href="https://cmake.org/cmake/help/v3.14/">CMake 官方文档</a></li>
</ul>
<h2 id="cmake-and-make">CMake and Make</h2>
<ul>
<li>CMake 最终实现的是帮助编译成 Makefile</li>
<li>本文参考了上述链接，重点是 B站 IPADS 的新人培训教程，对 Makefile 和 CMake 进行了讲解，然后个人再做一些补充。</li>
</ul>
<h2 id="示例">示例</h2>
<h3 id="step0-hello-world">step0. Hello world</h3>
<ul>
<li><strong>了解 Makefile 最基本的格式</strong>
<ul>
<li>CXX 是 Make 的内置变量，还有一些 <a href="http://www.gnu.org/software/make/manual/make.html#Implicit-Variables">其他的内置变量</a>
<ul>
<li>普通变量：
<ul>
<li>简单赋值 ( := )</li>
<li>递归赋值 ( = )</li>
<li>条件赋值 ( ?= )</li>
<li>追加赋值 ( += )</li>
</ul>
</li>
<li>自动化变量</li>
</ul>
</li>
<li>targets：规则的目标，可以是 Object File（一般称它为中间文件），也可以是可执行文件，还可以是一个标签；</li>
<li>prerequisites：是我们的依赖文件，要生成 targets 需要的文件或者是目标。可以是多个，也可以是没有；</li>
<li>command：make 需要执行的命令（任意的 shell 命令）。可以有多条命令，每一条命令占一行。</li>
<li>
<blockquote>
<p>注意：我们的目标和依赖文件之间要使用冒号分隔开，命令的开始一定要使用Tab键。</p>
</blockquote>
</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">name: dependencies
	commands

# or
targets : prerequisites
    commands

# or
targets : prerequisites; command
    command
</code></pre>
<ul>
<li>源代码程序 main.cpp</li>
</ul>
<pre><code class="language-C++">#include &lt;iostream&gt;

int main(int argc, const char *argv[])
{
    std::cout &lt;&lt; &quot;Hello world!&quot; &lt;&lt; std::endl;
    return 0;
}
</code></pre>
<ul>
<li>Makefile</li>
</ul>
<pre><code class="language-Makefile">hello: main.cpp
	$(CXX) -o hello main.cpp
	echo &quot;OK&quot;
</code></pre>
<ul>
<li>执行
<ul>
<li>这里 make 后的 hello 就对应了前面 Makefile 里定义的 hello</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">$ make hello
$ ./hello
</code></pre>
<h3 id="step1-优化前面的-makefile">step1. 优化前面的 Makefile</h3>
<ul>
<li>虽然前面的 Makefile 足够简单，但是还不够优雅，特别是需要添加新的源代码文件时候可能需要修改的地方过多，所以将其优化。</li>
<li>Makefile
<ul>
<li>定义了全局变量 CC, CXX</li>
<li>定义了伪目标 all 和 clean</li>
<li>定义了中间文件变量（编译是需要首先将源文件编译成 .o 的文件，再编译成可执行文件）<strong>此处定义的是汇编过后的机器码作为中间文件变量</strong>
<ul>
<li>预处理：C 编译器对各种预处理命令进行处理，包括头文件包含、宏定义的扩展、条件编译的选择等；</li>
<li>编译，将预处理得到的源代码文件，进行“翻译转换”，产生出机器语言的目标程序，得到机器语言的汇编文件；</li>
<li>汇编，将汇编代码翻译成了机器码，但是还不可以运行；</li>
<li>链接，处理可重定位文件，把各种符号引用和符号定义转换成为可执行文件中的合适信息，通常是虚拟地址。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220209101007.png" alt="20220209101007" loading="lazy"></li>
</ul>
</li>
<li>执行 <code>make all</code> 时对应跳转到执行 <code>make hello</code>，再跳转到执行 <code>make main.o</code>，相应地将 <code>main.cpp</code> 编译成了 <code>main.o</code>，然后 hello 的 command 将对应的目标文件链接起来构成对应的可执行文件 hello</li>
<li><code>make clean</code> 删除对应的编译的中间文件和可执行文件</li>
</ul>
</li>
<li><strong>注意</strong>：
<ul>
<li><strong>全局变量定义的部分可通过 make CXX=g++ 形式覆盖</strong></li>
<li><strong>链接到目标文件过程中的 $@ 是自动变量，表示 target 名</strong></li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">#
# := 用于给变量赋值，除此之外还有 =、?=、+= 等不同的赋值方式。
#
# 一般全大写变量用来表示允许调用 make 的时候传入的变量，
# 全小写变量表示仅内部使用的变量。
#
# 这里 CC 和 CXX 指定了要使用的 C 和 C++ 编译器。
#
CC := clang
CXX := clang++

#
# Makefile 中的核心概念是 target（目标），定义 target 的基本
# 格式是（注意每一行 command 是必须用 tab 缩进的）：
#
#   name: dependencies
#   	commands
#
# 要构建某个 target 时，使用如下命令：
#
#   make target_name
#
# 下面 all 是一个 target，它依赖另一个 target：hello，
# 意味着要构建 all，首先需要构建 hello。而 all 的 commands
# 部分为空，表示构建 all 不需要额外命令。
#
# .PHONY 表示 all 不是一个真实会生成的文件，而是一个“伪目标”。
#
.PHONY: all
all: hello

#
# 由于后面需要多次使用 main.o 等目标文件列表，这里赋值给变量
# objects。
#
objects := main.o

#
# hello 是我们最终要生成的可执行文件名，它依赖 objects 中的
# 所有目标文件。
#
# 它的 commands 部分使用 CXX 指定的编译器将所有目标文件链接
# 成 hello 可执行文件。
#
hello: $(objects)
	$(CXX) -o $@ $(objects)

# main.o 目标文件依赖 main.cpp 源文件。
main.o: main.cpp
	$(CXX) -c main.cpp

#
# clean 用于清除构建生成的临时文件、目标文件和可执行文件。
# 和 all 类似，它是一个“伪目标”。
#
.PHONY: clean
clean:
	rm -f hello $(objects)

</code></pre>
<h3 id="step2-引入新的头文件和源码">step2. 引入新的头文件和源码</h3>
<ul>
<li>新添加了一个头文件和源代码文件</li>
<li>answer.hpp</li>
</ul>
<pre><code class="language-C++">#pragma once

namespace answer {
    int find_the_ultimate_answer();
} // namespace answer
</code></pre>
<ul>
<li>answer.cpp</li>
</ul>
<pre><code class="language-C++">#include &quot;answer.hpp&quot;

namespace answer {
    int find_the_ultimate_answer() {
        return 42;
    }
} // namespace answer
</code></pre>
<ul>
<li>main.cpp</li>
</ul>
<pre><code class="language-C++">#include &lt;iostream&gt;

#include &quot;answer.hpp&quot;

int main(int argc, const char *argv[]) {
    int expected_answer = answer::find_the_ultimate_answer();
    for (;;) {
        std::cout &lt;&lt; &quot;What is the ultimate answer?&quot; &lt;&lt; std::endl;
        int answer;
        std::cin &gt;&gt; answer;
        if (answer == expected_answer) {
            std::cout &lt;&lt; &quot;Correct!&quot; &lt;&lt; std::endl;
            break;
        }
    }
    return 0;
}

</code></pre>
<ul>
<li>此时的 Makefile
<ul>
<li>因为新引入了 answer 源码，所以多了一个目标文件 answer.o</li>
<li>相应的目标文件 <code>make answer.o</code> 需要添加对应的步骤，因为有对应的规范，所以 Make 其实可以通过对应的目标名推断出同名的 .cpp 文件，<strong>只需要指定目标文件所依赖的头文件，使头文件变动时可以重新编译对应目标文件</strong>。</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">CC := clang
CXX := clang++

.PHONY: all
all: answer

# 在这里添加了 answer.o 目标文件。
objects := main.o answer.o

answer: $(objects)
	$(CXX) -o $@ $(objects)

#
# Make 可以自动推断 .o 目标文件需要依赖同名的 .cpp 文件，
# 所以其实不需要在依赖中指定 main.cpp 和 answer.cpp，
# 也不需要写编译 commands，它知道要用 CXX 变量制定的命令
# 作为 C++ 编译器。
#
# 这里只需要指定目标文件所依赖的头文件，使头文件变动时可以
# 重新编译对应目标文件。
#
main.o: answer.hpp
answer.o: answer.hpp

.PHONY: clean
clean:
	rm -f answer $(objects)

</code></pre>
<h4 id="makefile-其他规则">Makefile 其他规则</h4>
<h5 id="通配符">通配符</h5>
<ul>
<li>Makefile 是可以使用 shell 命令的，所以 shell 支持的通配符在 Makefile 中也是同样适用的。<strong>不能通过引用变量的方式来使用</strong>
<ul>
<li>*	匹配0个或者是任意个字符</li>
<li>？	匹配任意一个字符</li>
<li>[]	我们可以指定匹配的字符放在 &quot;[]&quot; 中</li>
<li>&quot;%&quot; 和通配符 &quot;*&quot; 相类似的字符，也是匹配任意个字符</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">.PHONY:clean
clean:
    rm -rf *.o test

test:*.c
    gcc -o $@ $^

# 不能使用 OBJ=*.c
# 要使用一个函数 &quot;wildcard&quot;，这个函数在我们引用变量的时候，会帮我们展开
OBJ=$(wildcard *.c)
test:$(OBJ)
    gcc -o $@ $^

# &quot;%.o&quot; 把我们需要的所有的 &quot;.o&quot; 文件组合成为一个列表，
# 从列表中挨个取出的每一个文件，&quot;%&quot; 表示取出来文件的文件名（不包含后缀）
# 然后找到文件中和 &quot;%&quot;名称相同的 &quot;.c&quot; 文件
# 然后执行下面的命令，直到列表中的文件全部被取出来为止
test:test.o test1.o
    gcc -o $@ $^
%.o:%.c
    gcc -o $@ $^
</code></pre>
<h5 id="自动化变量">自动化变量</h5>
<ul>
<li>http://c.biancheng.net/view/7094.html</li>
<li><strong>执行 make 的时候，make 会自动识别命令中的自动化变量，并自动实现自动化变量中的值的替换，这个类似于编译C语言文件的时候的预处理的作用。</strong>
<ul>
<li>$@：表示规则的目标文件名。如果目标是一个文档文件（Linux 中，一般成 .a文件为文档文件，也成为静态的库文件），那么它代表这个文档的文件名。在多目模式规则中，它代表的是触发规则被执行的文件名。</li>
<li>$%：当目标文件是一个静态库文件时，代表静态库的一个成员名。</li>
<li>$&lt;：规则的第一个依赖的文件名。如果是一个目标文件使用隐含的规则来重建，它代表由隐含规则加入的第一个依赖文件。</li>
<li>$?：所有比目标文件更新的依赖文件列表，空格分隔。如果目标文件时静态库件，代表的是库文件（.o 文件）。</li>
<li>$^：代表的是所有依赖文件列表，使用空格分隔。如果目标是静态库文件，它代表的只能是所有的库成员（.o 文件）名。一个文件可重复的出现在目标的依中，变量“$^”只记录它的第一次引用的情况。就是说变量“$^”会去掉重复的赖文件。</li>
<li>$+：类似“$^”，但是它保留了依赖文件中重复出现的文件。主要用在程序链时库的交叉引用场合。</li>
<li>$*：在模式规则和静态模式规则中，代表“茎”。“茎”是目标模式中“%”所代表的分（当文件名中存在目录时，“茎”也包含目录部分）。</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">#  &quot;$@&quot; 代表的是目标文件test
#  “$^” 代表的是依赖的文件
test:test.o test1.o test2.o
         gcc -o $@ $^
#  “$&lt;” 代表的是依赖文件中的第一个
test.o:test.c test.h
         gcc -o $@ $&lt;
test1.o:test1.c test1.h
         gcc -o $@ $&lt;
test2.o:test2.c test2.h
         gcc -o $@ $&lt;

# 库文件的制作依赖于这三个文件。当修改了其中的某个依赖文件，
# 在命令行执行 make 命令，库文件 &quot;lib&quot; 就会自动更新。
# &quot;$?&quot; 表示修改的文件
lib:test.o test1.o test2.o
    ar r $?
</code></pre>
<h4 id="其他规则">其他规则</h4>
<ul>
<li>http://c.biancheng.net/view/7153.html</li>
<li><strong>未来使用时再补充</strong></li>
<li>主要包括：<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220209214815.png" alt="20220209214815" loading="lazy"></li>
</ul>
<h3 id="step3-okokok">step3. okokok</h3>
<ul>
<li>Makefile - no</li>
<li>CMake    - yes<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220209215103.png" alt="20220209215103" loading="lazy"></li>
</ul>
<h3 id="step4-使用-cmake-来编译">step4. 使用 CMake 来编译</h3>
<ul>
<li>CMake 本身可以支持不同的底层，如 Makefile, Ninja 等，例如要产生Ninja，加上 -G Ninja 即可：<code>cmake -G Ninja</code></li>
<li><code>CMakeLists.txt</code> 基本格式：</li>
</ul>
<pre><code class="language-Makefile">cmake_minimum_required(VERSION 3.9)
project(answer)

add_executable(answer main.cpp answer.cpp)
</code></pre>
<ul>
<li>还是使用上面的源码 answer 和 main</li>
</ul>
<pre><code class="language-Makefile"># 指定最小 CMake 版本要求
cmake_minimum_required(VERSION 3.9)
# 设置项目名称
project(answer)

#[[
添加可执行文件 target，类似于原来 Makefile 的：

    answer: main.o answer.o
    main.o: main.cpp answer.hpp
    answer.o: answer.cpp answer.hpp

CMake 会自动找到依赖的头文件，因此不需要特别指定，
当头文件修改的时候，会重新编译依赖它的目标文件。
#]]
# 当前头文件就在当前目录，所以无需特别指定
# 如需指定，可以使用 include_directories
# 格式 add_executable(target srcfiles)
add_executable(answer main.cpp answer.cpp)

#[[
使用如下命令构建本项目：

    cmake -B build      # 生成构建目录
    cmake --build build # 执行构建
    ./build/answer      # 运行 answer 程序
#]]
</code></pre>
<ul>
<li>执行命令
<ul>
<li><code>cmake -B &lt;buildPath&gt;</code> 使用&quot;-B&quot;参数指定生成目录，这样CMake生成的文件都会集中在这个文件</li>
<li><code>cmake --build &lt;buildPath&gt;</code> 执行类似于 Makefile 中的 make 的效果，同时支持底层为 Ninja 时的 build 操作，类似于一个封装</li>
<li><code>./build/answer</code> 执行对应的目标程序</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">cmake -B build      # 生成构建目录，-B 指定生成的构建系统代码放在 build 目录
cmake --build build # 执行构建
./build/answer      # 运行 answer 程序
</code></pre>
<h3 id="step5-cmake-拆分库-库复用">step5. CMake 拆分库 (库复用)</h3>
<ul>
<li>项目中可以复用的部分可以拆成 library，然后在后面的其他可执行程序中引用该库</li>
</ul>
<pre><code class="language-Makefile"># 添加一个 libanswer 的静态库
add_library(libanswer STATIC answer.cpp)

# 依然指定可执行文件
add_executable(answer main.cpp)
# 链接对应的库
target_link_libraries(answer libanswer)
</code></pre>
<ul>
<li>CMakeLists.txt</li>
</ul>
<pre><code class="language-Makelist">cmake_minimum_required(VERSION 3.9)
project(answer)

# 添加 libanswer 库目标，STATIC 指定为静态库
add_library(libanswer STATIC answer.cpp)

add_executable(answer main.cpp)

# 为 answer 可执行目标链接 libanswer
target_link_libraries(answer libanswer)

#[[
使用如下命令构建本项目：

    cmake -B build      # 生成构建目录
    cmake --build build # 执行构建
    ./build/answer      # 运行 answer 程序
#]]

</code></pre>
<h3 id="step6-使用子目录来编译">step6. 使用子目录来编译</h3>
<ul>
<li>功能独立的模块可以放到单独的子目录：
<ul>
<li>与之对应的即为也需要对应的 CMakeLists.txt 在对应的子目录下</li>
</ul>
</li>
</ul>
<pre><code>.
├── answer
│  ├── answer.cpp
│  ├── CMakeLists.txt
│  └── include
│     └── answer
│        └── answer.hpp
├── CMakeLists.txt
└── main.cpp
</code></pre>
<ul>
<li>原来的 CMakeLists.txt
<ul>
<li><code>add_subdirectory</code> 添加 answer 子目录</li>
<li>然后对应的依赖的的 libanswer 会去子目录中寻找</li>
</ul>
</li>
</ul>
<pre><code>cmake_minimum_required(VERSION 3.9)
project(answer)

# 添加 answer 子目录
add_subdirectory(answer)

add_executable(answer_app main.cpp)
target_link_libraries(answer_app libanswer)

#[[
使用如下命令构建本项目：

    cmake -B build      # 生成构建目录
    cmake --build build # 执行构建
    ./build/answer_app  # 运行 answer_app 程序
#]]

</code></pre>
<ul>
<li>子目录中的 CMakeLists.txt
<ul>
<li><code>CMAKE_CURRENT_SOURCE_DIR </code> 是 CMake 内置变量，表示当前 CMakeLists.txt 文件所在目录，此处其实可以省略</li>
<li><code>target_include_directories</code> PUBLIC 参数表示这个包含目录是 libanswer 的公开接口一部分，链接 libanswer 的 target 可以 #include 该目录中的文件。
<ul>
<li>从而使得 main.cpp 可以直接 <code>#include &lt;answer/answer.hpp&gt;</code></li>
</ul>
</li>
</ul>
</li>
</ul>
<pre><code>add_library(libanswer STATIC answer.cpp)

#[[
message 可用于打印调试信息或错误信息，除了 STATUS
外还有 DEBUG WARNING SEND_ERROR FATAL_ERROR 等。
#]]
message(STATUS &quot;Current source dir: ${CMAKE_CURRENT_SOURCE_DIR}&quot;)

#[[
给 libanswer 库目标添加 include 目录，PUBLIC 使
这个 include 目录能被外部使用者看到。

当链接 libanswer 库时，这里指定的 include 目录会被
自动添加到使用此库的 target 的 include 路径中。
#]]
target_include_directories(libanswer PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
</code></pre>
<h3 id="step7-使用其他已有的动态库">step7. 使用其他已有的动态库</h3>
<ul>
<li>此时假设我们的 answer.cpp 需要发起网络请求来获取数据</li>
<li><code>answer.hpp</code></li>
</ul>
<pre><code class="language-C++">#pragma once

#include &lt;string&gt;

namespace answer {
    namespace v1 {
        int find_the_ultimate_answer();
    } // namespace v1

    namespace v2 {
        std::string find_the_ultimate_answer();
    } // namespace v2

    using namespace v2;
} // namespace answer
</code></pre>
<ul>
<li><code>answer.cpp</code></li>
</ul>
<pre><code class="language-C++">#include &quot;answer/answer.hpp&quot;

#include &lt;curl/curl.h&gt;

namespace answer {
    namespace v1 {
        int find_the_ultimate_answer() {
            return 42;
        }
    } // namespace v1

    namespace v2 {
        std::string find_the_ultimate_answer() {
            // 使用 CURL 调用 WolframAlpha API 获得答案
            // 注：这里的 appid 是演示用的，只有免费的 2000 次/天调用额度，如有实际需要请自行申请
            const auto url = &quot;https://api.wolframalpha.com/v1/result?appid=YAPKJY-8XT9VEYPX9&amp;i=what+is+ultimate+answer&quot;;
            const auto curl = curl_easy_init();
            curl_easy_setopt(curl, CURLOPT_URL, url);
            curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
            const auto write_func = [](char *ptr, size_t size, size_t nmemb, void *userdata) {
                auto &amp;result = *static_cast&lt;std::string *&gt;(userdata);
                result.append(ptr, size * nmemb);
                return size * nmemb;
            };
            using WriteFunction = size_t (*)(char *, size_t, size_t, void *);
            curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, static_cast&lt;WriteFunction&gt;(write_func));
            std::string result = &quot;&quot;;
            curl_easy_setopt(curl, CURLOPT_WRITEDATA, &amp;result);
            curl_easy_perform(curl); // 暂时不考虑 API 请求失败的情况
            curl_easy_cleanup(curl);
            return result;
        }
    } // namespace v2
} // namespace answer

</code></pre>
<ul>
<li>虽然我们在代码中制定了对应的头文件，并编写了相关代码，但是本质是没有依赖对应的 libcurl 库的。所以我们需要在子目录下对应修改 CMakeLists.txt
<ul>
<li><code>find_package</code> 寻找已经安装的第三方库的头文件和库文件的位置，参数 REQUIRED 要求必须找到，没找到就报错。</li>
<li><code>target_link_libraries</code> 相应地链接 libcurl，使用了 PRIVATE 表明只有当前子模块 answer 能使用对应的接口。</li>
<li><strong>注意</strong>：CURL 和 CURL::libcurl 是约定的名字，其它第三方库的包名和 library 名可在网上查。</li>
</ul>
</li>
</ul>
<pre><code class="language-Makelist">#[[
find_package 用于在系统中寻找已经安装的第三方库的头文件和库文件
的位置，并创建一个名为 CURL::libcurl 的库目标，以供链接。
#]]
find_package(CURL REQUIRED)

add_library(libanswer STATIC answer.cpp)

target_include_directories(libanswer PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)

#[[
为 libanswer 库链接 libcurl，这里 PRIVATE 和 PUBLIC 的区别是：
CURL::libcurl 库只会被 libanswer 看到，根级别的 main.cpp 中
无法 include curl 的头文件。
#]]
target_link_libraries(libanswer PRIVATE CURL::libcurl)

</code></pre>
<h3 id="step8-继续解耦">step8. 继续解耦</h3>
<ul>
<li>此时的文件目录</li>
</ul>
<pre><code>.
├── answer
│   ├── answer.cpp
│   ├── CMakeLists.txt
│   └── include
│       └── answer
│           └── answer.hpp
├── CMakeLists.txt
├── curl_wrapper
│   ├── CMakeLists.txt
│   ├── curl_wrapper.cpp
│   └── include
│       └── curl_wrapper
│           └── curl_wrapper.hpp
├── main.cpp
├── wolfram
│   ├── alpha.cpp
│   ├── CMakeLists.txt
│   └── include
│       └── wolfram
│           └── alpha.hpp
</code></pre>
<ul>
<li>对应的依赖关系如下：answer -&gt; wolffram -&gt; curl_wapper -&gt; libcurl （代码此处不再粘贴）
<ul>
<li>curl_wapper: 对外提供两个接口
<ul>
<li>std::string http_get_string(const std::string &amp;url);</li>
<li>std::string url_encode(const std::string &amp;s);</li>
</ul>
</li>
<li>wolffram: 对外提供一个接口
<ul>
<li>std::string simple_query(const std::string &amp;appid, const std::string &amp;query);</li>
</ul>
</li>
<li>answer 还是和之前一样：
<ul>
<li>find_the_ultimate_answer();<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220209225506.png" alt="20220209225506" loading="lazy"></li>
</ul>
</li>
</ul>
</li>
<li>此时各个目录下的 CMakeLists.txt 如下：</li>
</ul>
<pre><code># CMakeLists.txt
add_subdirectory(answer)
add_subdirectory(curl_wrapper)
add_subdirectory(wolfram)
add_executable(answer_app main.cpp)
target_link_libraries(answer_app libanswer)

# answer/CMakeLists.txt
add_library(libanswer STATIC answer.cpp)
target_include_directories(libanswer PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_link_libraries(libanswer PRIVATE wolfram)

# wolfram/CMakeLists.txt
add_library(wolfram STATIC alpha.cpp)
target_include_directories(wolfram PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_link_libraries(wolfram PRIVATE curl_wrapper)

# curl_wrapper/CMakeLists.txt
find_package(CURL REQUIRED)
add_library(curl_wrapper STATIC curl_wrapper.cpp)
target_include_directories(curl_wrapper
                           PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_link_libraries(curl_wrapper PRIVATE CURL::libcurl)

</code></pre>
<h3 id="step9-cmake-参数传递">step9. CMake 参数传递</h3>
<ul>
<li>上文所述使用的公开的 API 常常因为用户的不同而需要不同的设置，那么可以在 CMake 编译时指定相应的参数进行传递 <code>-D&lt;para_name&gt;</code>，但是需要在 CMakeLists.txt 中添加相应的支持。</li>
<li>因为 AppID 在原来的程序中只有 answer 模块才使用到，所以只需修改该模块的 CMakeLists.txt
<ul>
<li><code>set(WOLFRAM_APPID &quot;&quot; CACHE STRING &quot;WolframAlpha APPID&quot;)</code> 注意各个字段的含义</li>
<li><code>target_compile_definitions</code>：要让 C++ 代码能够拿到 CMake 中的变量，可添加编译时宏定义</li>
<li><code>cmake -B build -DWOLFRAM_APPID=xxx</code>：命令行参数传递</li>
<li><code>ccmake</code>：直接 TUI 修改变量传递参数</li>
</ul>
</li>
</ul>
<pre><code class="language-MakeList">#[[
创建一个可配置的变量，可以由上级 CMakeLists 或 cmake 命令指定变量值。

这里由于 APPID 是一个应该藏好、不应该放在代码里的值，所以建议在 cmake
命令中通过 -D 参数传入。
#]]
# 格式 参数名
# 默认值
# 变量类型 CACHE 
# 数据类型 STRING
# 参数描述
set(WOLFRAM_APPID
    &quot;&quot;
    CACHE STRING &quot;WolframAlpha APPID&quot;)

if(WOLFRAM_APPID STREQUAL &quot;&quot;)
    message(SEND_ERROR &quot;WOLFRAM_APPID must not be empty&quot;)
endif()

add_library(libanswer STATIC answer.cpp)
target_include_directories(libanswer PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)

#[[
将 WOLFRAM_APPID 添加到编译 .cpp 文件时的 definition 列表，从而
可在 C++ 代码中使用。宏定义名 WOLFRAM_APPID
#]]
target_compile_definitions(libanswer PRIVATE WOLFRAM_APPID=&quot;${WOLFRAM_APPID}&quot;)

target_link_libraries(libanswer PRIVATE wolfram)
</code></pre>
<h3 id="step10-cmake-编译不同类型的库">step10. CMake 编译不同类型的库</h3>
<ul>
<li>上面的例子中因为经过充分的解耦，answer 模块的代码已经足够简单了，Modern C++ 可以直接在头文件中实现代码来省略源文件，这种情况被称之为 header-only</li>
</ul>
<pre><code class="language-C++">#pragma once

#include &lt;string&gt;

#include &lt;wolfram/alpha.hpp&gt;

// header-only 库的所有实现代码均在头文件中

namespace answer {
    namespace v1 {
        int find_the_ultimate_answer() {
            return 42;
        }
    } // namespace v1

    namespace v2 {
        std::string find_the_ultimate_answer() {
            return wolfram::simple_query(WOLFRAM_APPID, &quot;what is the ultimate answer?&quot;);
        }
    } // namespace v2

    using namespace v2;
} // namespace answer

</code></pre>
<ul>
<li>针对这种库的编译可以使用特殊的库类型 INTERFACE，相应地也需要修改其他语句
<ul>
<li>通过 <code>target_xxx</code> 给 INTERFACE library 添加属性都要用 INTERFACE。</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">add_library(libanswer INTERFACE)
target_include_directories(libanswer
                           INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_compile_definitions(libanswer INTERFACE WOLFRAM_APPID=&quot;${WOLFRAM_APPID}&quot;)
target_link_libraries(libanswer INTERFACE wolfram)
</code></pre>
<h3 id="step11-指定-c-标准">step11. 指定 C++ 标准</h3>
<ul>
<li>上文使用的 auto 关键字源于 C++ 11，需要在 CMakeLists.txt 相应地进行指定和约束</li>
<li>但也可以针对 target 要求编译 feature（即指定要使用 C/C++ 的什么特性）<code>target_compile_features</code></li>
<li>注意两者的区别：
<ul>
<li><code>CMAKE_CXX_STANDARD</code> 会应用于所有能看到这个变量的 target，而 <code>target_compile_features</code> 只应用于单个 target</li>
<li><code>target_compile_features</code> 可以指定更细粒度的 C++ 特性，例如 <code>cxx_auto_type</code>、<code>cxx_lambda</code> 等。这里使用了 cxx20 的标准是为了使用 require 的关键字</li>
</ul>
</li>
</ul>
<pre><code># CMakeLists.txt
set(CMAKE_CXX_STANDARD 11)

# answer/CMakeLists.txt
#[[
指明 libanswer 要求 C++20。

这里和直接设置 CMAKE_CXX_STANDARD 的区别是：

    1. 设置 CMAKE_CXX_STANDARD 之后，从设置它的那一级开始
       include 的 subdirectory 都会继承这个变量，且应用于
       所有能看到这个变量的 target；而 target_compile_features
       只应用于单个 target。
    2. target_compile_features 可以指定更细粒度的 C++ 特性，
       例如 cxx_auto_type、cxx_lambda 等。
#]]
target_compile_features(libanswer INTERFACE cxx_std_20)
</code></pre>
<ul>
<li>C++20 在本例中的使用，重点 <code>answer::check_the_answer</code></li>
</ul>
<pre><code class="language-C++">// main.cpp
int main(int argc, const char *argv[]) {
    for (;;) {
        std::cout &lt;&lt; &quot;What is the ultimate answer?&quot; &lt;&lt; std::endl;
        std::string answer;
        std::cin &gt;&gt; answer;
        auto expected_answer = answer::find_the_ultimate_answer();
        if (answer::check_the_answer(answer, expected_answer)) {
            std::cout &lt;&lt; &quot;Correct!&quot; &lt;&lt; std::endl;
            break;
        }
    }
    return 0;
}
</code></pre>
<ul>
<li>具体的 <code>answer::check_the_answer</code> 实现</li>
</ul>
<pre><code class="language-C++">    namespace v2 {
        std::string find_the_ultimate_answer() {
            return wolfram::simple_query(WOLFRAM_APPID, &quot;what is the ultimate answer?&quot;);
        }

        // 下面是非常 fancy 的两个函数，使用了 C++14 的 auto 返回类型、
        // C++17 的 if constexpr 和 C++20 的 constraints。

        namespace impl {
            template &lt;typename T&gt;
            auto to_string(T &amp;&amp;t) {
                if constexpr (requires { std::to_string(t); }) {
                    return std::to_string(std::forward&lt;T&gt;(t));
                } else if constexpr (requires { std::string(t); }) {
                    return std::string(std::forward&lt;T&gt;(t));
                }
            }
        } // namespace impl

        template &lt;typename T, typename U&gt;
        requires requires(T &amp;&amp;t, U &amp;&amp;u) {
            impl::to_string(std::forward&lt;T&gt;(t));
            impl::to_string(std::forward&lt;U&gt;(u));
        }
        auto check_the_answer(T &amp;&amp;given, U &amp;&amp;expected) {
            return impl::to_string(std::forward&lt;T&gt;(given)) == impl::to_string(std::forward&lt;U&gt;(expected));
        }
    } // namespace v2

    using namespace v2;
</code></pre>
<h3 id="step12-ctest">step12. CTest</h3>
<ul>
<li>现在的目录结构<pre><code>root@aep-shunzi:/shunzi/modern-cmake-by-example# tree
.
├── answer
│   ├── CMakeLists.txt
│   ├── include
│   │   └── answer
│   │       └── answer.hpp
│   └── tests
│       ├── CMakeLists.txt
│       └── test_check_the_answer.cpp
├── CMakeLists.txt
├── curl_wrapper
│   ├── CMakeLists.txt
│   ├── curl_wrapper.cpp
│   └── include
│       └── curl_wrapper
│           └── curl_wrapper.hpp
├── main.cpp
├── wolfram
│   ├── alpha.cpp
│   ├── CMakeLists.txt
│   └── include
│       └── wolfram
│           └── alpha.hpp
</code></pre>
</li>
<li>要使用 CTest 运行 CMake 项目的测试程序，需要在 CMakeLists.txt 添加一些内容：
<ul>
<li><code>include(CTest)</code> 主 CMakeLists 需要添加对 ctest 的支持</li>
<li><code>BUILD_TESTING</code> 在引入 CTest 之后将会引入一个默认的 CACHE 变量来标识是否编译 Test，默认值为 ON，也可以通过 <code>-D</code> 参数传递来修改</li>
<li><code>add_subdirectory(tests)</code> 在 answer 模块中添加新的测试目录作为子目录，此时的文件结构</li>
<li><code>add_test</code> 添加相应的测试用例
<ul>
<li><code>&lt;name&gt;</code> 指定本测试的名称</li>
<li><code>Debug/Release</code> 选项可以控制在不同的编译版本下是否进行测试</li>
<li><code>WORKING_DIRECTORY</code> 设置工作路径</li>
<li><code>command</code> 表示可运行程序</li>
</ul>
<pre><code class="language-MakeList">add_test(NAME &lt;name&gt; [CONFIGURATIONS [Debug|Release|...]]
       [WORKING_DIRECTORY dir]
       COMMAND &lt;command&gt; [arg1 [arg2 ...]])
</code></pre>
</li>
</ul>
</li>
<li>使用 CTest 的大体结构</li>
</ul>
<pre><code class="language-MakeList"># CMakeLists.txt
cmake_minimum_required(VERSION 3.14) # 提高了 CMake 版本要求
project(answer)
#[[
判断当前目录是否是 CMake 调用的 top-level，如果是，
引入 CTest 支持。

这会引入一个 BUILD_TESTING 选项（类似之前的 CACHE
STRING，这是一个 CACHE BOOL），默认值为 ON，可以在
之后的 CMake 脚本中通过该选项判断是否需要 include
测试用例子目录。
#]]
if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
    include(CTest)
endif()

# answer/CMakeLists.txt
if(BUILD_TESTING)
    add_subdirectory(tests)
endif()

# answer/tests/CMakeLists.txt
#[[
add_test 添加 CTest 可以识别到的测试程序，建议使用项目名前缀，
方便在运行测试时和别的第三方库的测试区分。
#]]
add_executable(test_some_func test_some_func.cpp)
add_test(NAME answer.test_some_func COMMAND test_some_func)
</code></pre>
<ul>
<li>answer 模块添加的测试代码 <code>answer/tests/test_check_the_answer.cpp</code>
<ul>
<li>这里使用了 Catch2 框架来进行单元测试，相应地需要添加 Catch2 的依赖</li>
</ul>
</li>
</ul>
<pre><code class="language-C++">#include &lt;catch2/catch_test_macros.hpp&gt;

#include &lt;answer/answer.hpp&gt;

using namespace answer;

// 使用 Catch2 编写测试用例

TEST_CASE(&quot;Can compare string and string&quot;, &quot;[check_the_answer]&quot;) {
    REQUIRE(check_the_answer(&quot;Hello&quot;, &quot;Hello&quot;) == true);
    REQUIRE(check_the_answer(&quot;Hello&quot;, &quot;world&quot;) == false);
    REQUIRE(check_the_answer(&quot;13&quot;, std::string(&quot;13&quot;)) == true);
}

TEST_CASE(&quot;Can compare string and integer&quot;, &quot;[check_the_answer]&quot;) {
    REQUIRE(check_the_answer(&quot;13&quot;, 13) == true);
    REQUIRE(check_the_answer(&quot;13&quot;, 14) == false);
    REQUIRE(check_the_answer(13, &quot;13&quot;) == true);
    REQUIRE(check_the_answer(13, std::string(&quot;13&quot;)) == true);
    REQUIRE(check_the_answer(13, std::string(&quot;14&quot;)) == false);
}

</code></pre>
<ul>
<li>具体的 answer/test 模块的 CMakeLists.txt
<ul>
<li>除了使用 <code>find_package</code> 找到系统中安装的第三方库，也可通过 CMake 3.11 新增的 <strong>FetchContent</strong> 功能下载使用第三方库，<strong>使用步骤</strong>如下
<ul>
<li><code>include(FetchContent)</code> 首先导入该功能</li>
<li><code>FetchContent_Declare</code> 定义依赖的库对应的信息
<ul>
<li><code>SOURCE_DIR</code> Declare 中可以指定要安装的目录</li>
</ul>
</li>
<li><code>FetchContent_MakeAvailable</code> 根据定义信息对应下载构建库并进行依赖
<ul>
<li><code>FetchContent_MakeAvailable</code> 要求 CMake 3.14，如果要支持更旧版本，或者需要更细粒度的控制，可以使用如下替代：<pre><code>FetchContent_GetProperties(catch2)
if(NOT catch2_POPULATED)
    FetchContent_Populate(catch2)
    add_subdirectory(${catch2_SOURCE_DIR} ${catch2_BINARY_DIR})
endif()
</code></pre>
</li>
</ul>
</li>
<li><code>target_link_libraries(${TEST_NAME} PRIVATE Catch2::Catch2WithMain)</code> 相应地在后面依赖该库</li>
</ul>
</li>
</ul>
</li>
</ul>
<pre><code class="language-CMakeLists.txt"># 导入 FetchContent 相关命令
include(FetchContent)

# 描述如何获取 Catch2
FetchContent_Declare(
    catch2 # 建议使用全小写
    GIT_REPOSITORY https://github.com/catchorg/Catch2.git
    GIT_TAG v3.0.0-preview3)

# 一条龙地下载、构建 Catch2
FetchContent_MakeAvailable(catch2)

#[[
FetchContent 要求 CMake 3.11 或更高版本，在此之间
可以使用 Git submodule + add_subdirectory 的方式
使用没有安装在系统中的第三方库。即使支持 FetchContent
也可以选择使用 Git submodule，各有优劣。

FetchContent_MakeAvailable 要求 CMake 3.14，如果
要支持更旧版本，或者需要更细粒度的控制，可以使用如下替代：

    FetchContent_GetProperties(catch2)
    if(NOT catch2_POPULATED)
        FetchContent_Populate(catch2)
        add_subdirectory(${catch2_SOURCE_DIR} ${catch2_BINARY_DIR})
    endif()
#]]

# macro（宏）类似于 C/C++ 中的宏
macro(answer_add_test TEST_NAME)
    add_executable(${TEST_NAME} ${ARGN}) # ${ARGN} 类似于 C/C++ 中的 __VA_ARGS__
    #[[
    add_test 添加 CTest 可以识别到的测试程序，建议使用项目名前缀，
    方便在运行测试时和别的第三方库的测试区分。
    #]]
    add_test(NAME answer.${TEST_NAME} COMMAND ${TEST_NAME})
    target_link_libraries(${TEST_NAME} PRIVATE libanswer)
    #[[
    链接 Catch2::Catch2WithMain 以使用 Catch2 提供的宏，链接
    Catch2WithMain 时，测试程序中不需要手动编写 main 函数。
    #]]
    target_link_libraries(${TEST_NAME} PRIVATE Catch2::Catch2WithMain)
endmacro()

# 调用上面的 macro 添加测试程序
answer_add_test(test_check_the_answer test_check_the_answer.cpp)

</code></pre>
<ul>
<li>原 CMakeLists.txt 中使用了一种相对特殊的语法。<code>macro</code> 类似于定义了一个宏。
<ul>
<li><code>macro(answer_add_test TEST_NAME)</code> 对应定义了函数名 <code>answer_add_test</code> 和函数参数 <code>TEST_NAME</code></li>
<li><code>add_executable(${TEST_NAME} ${ARGN})</code> 本例中相应地使用对应的参数创建了对应的测试程序，其中 <code>${ARGN}</code> 类似于 C/C++ 中的 <code>__VA_ARGS__</code>，即可变数量的参数数组</li>
<li><code>add_test(NAME answer.${TEST_NAME} COMMAND ${TEST_NAME})</code> 添加 CTest 可以识别到的测试程序</li>
<li><code>target_link_libraries(${TEST_NAME} PRIVATE libanswer)</code> 给相应的测试程序链接对应的库</li>
<li><code>answer_add_test(test_check_the_answer test_check_the_answer.cpp)</code> 相应地调用对应的宏定义，本例中对应了一个测试程序，test_check_the_answer 以及其其所依赖的源文件 test_check_the_answer.cpp</li>
</ul>
</li>
<li>格式</li>
</ul>
<pre><code>macro(answer_add_test TEST_NAME)
    add_executable(${TEST_NAME} ${ARGN}) # ${ARGN} 类似于 C/C++ 中的 __VA_ARGS__
    add_test(NAME answer.${TEST_NAME} COMMAND ${TEST_NAME})
    target_link_libraries(${TEST_NAME} PRIVATE libanswer)
    target_link_libraries(${TEST_NAME} PRIVATE Catch2::Catch2WithMain)
endmacro()

answer_add_test(test_check_the_answer test_check_the_answer.cpp)
answer_add_test(test_another_function test_another_function.cpp)
</code></pre>
<ul>
<li><code>ctest --test-dir build -R &quot;^answer.&quot;</code> 运行 ctest，制定相应的目录和对应的 test 名称</li>
</ul>
<h4 id="macro-和-function-的区别">macro 和 function 的区别</h4>
<ul>
<li><a href="https://www.cnblogs.com/Braveliu/p/15621973.html">CMake语法—宏和函数（macro vs function） </a></li>
<li>在 CMake 中也可以定义 function，那么 CMake 中的 function 和 macro 的区别其实是和 C/C++ 中的宏定义与函数的区别是一致的。
<ul>
<li>函数会产生新作用域；宏是把执行代码替换到调用位置</li>
<li>函数内可以使用return；宏中不建议使用return</li>
<li>在函数中可以调用宏</li>
<li>函数中有一些特有的默认变量
<ul>
<li><code>${CMAKE_CURRENT_FUNCTION}</code> 当前函数名称</li>
<li><code>${CMAKE_CURRENT_FUNCTION_LIST_DIR}</code> 当前函数路径</li>
<li><code>${CMAKE_CURRENT_FUNCTION_LIST_FILE}</code> 当前函数所属文件</li>
<li><code>${CMAKE_CURRENT_FUNCTION_LIST_LINE}</code> 当前函数定义的起始行数</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 id="step13-重新使用-makefile-来提升效率">step13. 重新使用 Makefile 来提升效率</h3>
<ul>
<li>使用 Makefile 的简单特性来简化编译运行过程
<ul>
<li><code>make build WOLFRAM_APPID=xxx</code> 简化 build 过程，并传递相关参数</li>
<li><code>make test</code> 简化 test 运行，执行 CTest</li>
<li><code>make run</code>  简化运行过程，直接执行</li>
<li><code>make clean</code> 简化重编译的过程，删除 build 目录</li>
</ul>
</li>
</ul>
<pre><code class="language-Makefile">WOLFRAM_APPID :=

.PHONY: build
build: configure
	cmake --build build

.PHONY: configure
configure:
	cmake -B build -DWOLFRAM_APPID=${WOLFRAM_APPID}

.PHONY: run
run:
	./build/answer_app

.PHONY: test
test:
	ctest --test-dir build -R &quot;^answer.&quot;

.PHONY: clean
clean:
	rm -rf build

#
# 可以使用 Make 来更方便地调用 CMake 命令：
#
#     make build WOLFRAM_APPID=xxx
#     make test
#     make run
#     make clean
#
</code></pre>
<h3 id="other">Other</h3>
<ul>
<li>CMake 本质也是代码，应该格式化，格式化工具：https://github.com/cheshirekow/cmake_format</li>
<li>Linux 内核是可以修改并替换的，只需要下载内核源码，然后：</li>
</ul>
<pre><code class="language-bash">$ make defconfig # 有各种 xxxconfig
$ make menuconfig # TUI 界面修改 config
$ make # 构建 Linux 内核
$ make modules_install # 安装内核模块
$ make install # 安装内核
</code></pre>
<h2 id="一个具体的示例-rocksdb">一个具体的示例 RocksDB</h2>
<ul>
<li>命令介绍
<ul>
<li><code>list (subcommand &lt;list&gt; [args...])</code>：<code>subcommand</code> 为具体的列表操作子命令，<code>GET/APPEND/INSERT/REMOVE_ITEM/REMOVE_AT/REMOVE_DUPLICATES/REVERSE/SORT</code>。<code>&lt;list&gt;</code> 为待操作的列表变量，<code>[args...]</code> 为对列表变量操作需要使用的参数表，不同的子命令对应的参数也不一致。
<ul>
<li><code>CMAKE_MODULE_PATH</code> 默认情况下为空，它是由项目设置的。</li>
</ul>
</li>
<li><code>include</code>: 用来载入并运行来自于文件或模块的 CMake 代码。即引入其他的 cmake 配置代码，这里主要是承接上一个命令对应的其他 cmake 模块<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220212215043.png" alt="20220212215043" loading="lazy">
<ul>
<li><code>include(ReadVersion)</code> 对应了上图中的 ReadVersion 模块，该模块定义了获取当前 RocksDB 版本的 function get_rocksdb_version，该函数将从 <code>&quot;${CMAKE_CURRENT_SOURCE_DIR}/include/rocksdb/version.h</code> 文件中读取对应的版本号，使用正则表达式去匹配，然后得到相应的返回值 version_var</li>
<li><code>include(GoogleTest)</code> 对应了 CMake 中自带的 GoogleTest 模块，https://cmake.org/cmake/help/latest/module/GoogleTest.html</li>
</ul>
</li>
<li><code>project</code> 描述项目基本信息，名称，版本，语言</li>
<li><code>CMP0042</code> https://cmake.org/cmake/help/v3.0/policy/CMP0042.html</li>
<li><code>CMAKE_BUILD_TYPE</code> CMake 编译的相关配置，根据时候被作为参数传递进来以及是否包含 git 目录来采取不同的设置，可能的配置如下。设置完后 set cache string 变量 <code>CMAKE_BUILD_TYPE</code>
<ul>
<li>Debug：Adds the -g flag</li>
<li>Release：Adds the -O3 -DNDEBUG flags to the compiler</li>
<li>RelWithDebInfo：Adds -O2 -g -DNDEBUG flags</li>
<li>MinSizeRel：Adds -Os -DNDEBUG</li>
</ul>
</li>
<li><code>find_program</code> 寻找相应的程序，并将结果存储在变量中。</li>
<li><code>option</code> 定义编译选项，可以在编译时指定参数 -Dxxx 传递</li>
<li><code>add_definitions</code> 为源文件的编译添加由-D定义的标志</li>
<li><code>$ENV{NAME}</code> 调用系统的环境变量</li>
<li><code>CMAKE_SYSTEM_NAME</code>：CMake 要构建的操作系统的名称</li>
<li><code>CMAKE_CXX_STANDARD</code>：CXX 标准设置</li>
<li><code>include(CMakeDependentOption)</code>：引入 CMAKE_DEPENDENT_OPTION 对应的模块</li>
<li><code>string</code> cmake 中的字符串操作 https://cmake.org/cmake/help/latest/command/string.html</li>
<li><code>execute_process</code> 执行对应的系统命令。注意几个变量的设置
<ul>
<li>RESULT_VARIABLE：变量被设置为包含子进程的运行结果。返回码将是一个来自于最后一个子进程的整数或者一个错误描述字符串。</li>
<li>OUTPUT_VARIABLE, ERROR_VARIABLE：命名的变量将被分别设置为标准输出和标准错误管道的内容。如果为2个管道命名了相同的名字，他们的输出将按照产生顺序被合并</li>
</ul>
</li>
</ul>
</li>
<li>CMakeLists.txt</li>
</ul>
<pre><code># Linux:
#
# 1. Install a recent toolchain if you're on a older distro. C++17 required (GCC &gt;= 7, Clang &gt;= 5)
# 2. mkdir build; cd build
# 3. cmake ..
# 4. make -j

cmake_minimum_required(VERSION 3.10)
# 添加模块目录到 CMAKE_MODULE_PATH
list(APPEND CMAKE_MODULE_PATH &quot;${CMAKE_CURRENT_LIST_DIR}/cmake/modules/&quot;)
# 引入 ReadVersion 对应的 function
include(ReadVersion)
# 引入 CMake 自带的 GoogleTest
include(GoogleTest)
# 获取对应的 RocksDB 版本信息，rocksdb_VERSION
get_rocksdb_version(rocksdb_VERSION)
# 描述项目的基础信息
project(rocksdb
  VERSION ${rocksdb_VERSION}
  LANGUAGES CXX C ASM)

# MACOSX_RPATH 默认启用 
if(POLICY CMP0042)
  cmake_policy(SET CMP0042 NEW)
endif()

# 如果没有指定 CMAKE_BUILD_TYPE
if(NOT CMAKE_BUILD_TYPE)
  # 判断是否包含 git 目录，包含的话开启 debug 模式，否则开启 RelWithDebInfo
  if(EXISTS &quot;${CMAKE_SOURCE_DIR}/.git&quot;)
    set(default_build_type &quot;Debug&quot;)
  else()
    set(default_build_type &quot;RelWithDebInfo&quot;)
  endif()
  # 设置相应的参数
  set(CMAKE_BUILD_TYPE &quot;${default_build_type}&quot; CACHE STRING
    &quot;Default BUILD_TYPE is ${default_build_type}&quot; FORCE)
endif()

# 查找编译器程序 ccache 编译器缓存
find_program(CCACHE_FOUND ccache)
# 如果找到了该程序，设置属性，将 ccache 作为编译命令和链接命令的启动器
if(CCACHE_FOUND)
  set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
  set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
endif(CCACHE_FOUND)

# 定义几个依赖库的编译选型，并设置默认值
option(WITH_JEMALLOC &quot;build with JeMalloc&quot; OFF)
option(WITH_LIBURING &quot;build with liburing&quot; ON)
option(WITH_SNAPPY &quot;build with SNAPPY&quot; OFF)
option(WITH_LZ4 &quot;build with lz4&quot; OFF)
option(WITH_ZLIB &quot;build with zlib&quot; OFF)
option(WITH_ZSTD &quot;build with zstd&quot; OFF)
option(WITH_WINDOWS_UTF8_FILENAMES &quot;use UTF8 as characterset for opening files, regardles of the system code page&quot; OFF)
if (WITH_WINDOWS_UTF8_FILENAMES)
  add_definitions(-DROCKSDB_WINDOWS_UTF8_FILENAMES)
endif()

# 如果环境变量中配置了 CIRCLECI，一款持续集成的工具
if ($ENV{CIRCLECI})
  message(STATUS &quot;Build for CircieCI env, a few tests may be disabled&quot;)
  add_definitions(-DCIRCLECI)
endif()

# 如果操作系统是 Linux 或者 win
# third-party/folly is only validated to work on Linux and Windows for now.
# So only turn it on there by default.
if(CMAKE_SYSTEM_NAME MATCHES &quot;Linux|Windows&quot;)
  # 判断 MSVC 版本，并对 Folly 进行配置（folly, Facebook Open-source Library）
  if(MSVC AND MSVC_VERSION LESS 1910)
    # Folly does not compile with MSVC older than VS2017
    option(WITH_FOLLY_DISTRIBUTED_MUTEX &quot;build with folly::DistributedMutex&quot; OFF)
  else()
    option(WITH_FOLLY_DISTRIBUTED_MUTEX &quot;build with folly::DistributedMutex&quot; ON)
  endif()
else()
  option(WITH_FOLLY_DISTRIBUTED_MUTEX &quot;build with folly::DistributedMutex&quot; OFF)
endif()

# 如果没制定 CXX 标准，指定 C++17
if( NOT DEFINED CMAKE_CXX_STANDARD )
  set(CMAKE_CXX_STANDARD 17)
endif()

# 引入专门的条件 Option 模块，CMAKE_DEPENDENT_OPTION
include(CMakeDependentOption)

# 根据不同的操作系统/不同的编译器为 option 赋值
if(MSVC)
  option(WITH_GFLAGS &quot;build with GFlags&quot; OFF)
  option(WITH_XPRESS &quot;build with windows built in compression&quot; OFF)
  include(${CMAKE_CURRENT_SOURCE_DIR}/thirdparty.inc)
else()
  if(CMAKE_SYSTEM_NAME MATCHES &quot;FreeBSD&quot; AND NOT CMAKE_SYSTEM_NAME MATCHES &quot;kFreeBSD&quot;)
    # FreeBSD has jemalloc as default malloc
    # but it does not have all the jemalloc files in include/...
    set(WITH_JEMALLOC ON)
  else()
    if(WITH_JEMALLOC)
      # 查询 Jemalloc 的库
      find_package(JeMalloc REQUIRED)
      # 为源文件的编译添加由-D定义的标志。
      add_definitions(-DROCKSDB_JEMALLOC -DJEMALLOC_NO_DEMANGLE)
      # 将对应的依赖库名称追加到变量 THIRDPARTY_LIBS
      list(APPEND THIRDPARTY_LIBS JeMalloc::JeMalloc)
    endif()
  endif()

  if(MINGW)
    option(WITH_GFLAGS &quot;build with GFlags&quot; OFF)
  else()
    option(WITH_GFLAGS &quot;build with GFlags&quot; ON)
  endif()
  set(GFLAGS_LIB)
  if(WITH_GFLAGS)
    # Config with namespace available since gflags 2.2.2
    option(GFLAGS_USE_TARGET_NAMESPACE &quot;Use gflags import target with namespace.&quot; ON)
    find_package(gflags CONFIG)
    if(gflags_FOUND)
      if(TARGET ${GFLAGS_TARGET})
        # Config with GFLAGS_TARGET available since gflags 2.2.0
        set(GFLAGS_LIB ${GFLAGS_TARGET})
      else()
        # Config with GFLAGS_LIBRARIES available since gflags 2.1.0
        set(GFLAGS_LIB ${gflags_LIBRARIES})
      endif()
    else()
      find_package(gflags REQUIRED)
      set(GFLAGS_LIB gflags::gflags)
    endif()
    include_directories(${GFLAGS_INCLUDE_DIR})
    list(APPEND THIRDPARTY_LIBS ${GFLAGS_LIB})
    add_definitions(-DGFLAGS=1)
  endif()

  # 如果开启了 WITH_SNAPPY
  if(WITH_SNAPPY)
    find_package(Snappy CONFIG)
    if(NOT Snappy_FOUND)
      find_package(Snappy REQUIRED)
    endif()
    add_definitions(-DSNAPPY)
    list(APPEND THIRDPARTY_LIBS Snappy::snappy)
  endif()

  if(WITH_ZLIB)
    find_package(ZLIB REQUIRED)
    add_definitions(-DZLIB)
    list(APPEND THIRDPARTY_LIBS ZLIB::ZLIB)
  endif()

  option(WITH_BZ2 &quot;build with bzip2&quot; OFF)
  if(WITH_BZ2)
    find_package(BZip2 REQUIRED)
    add_definitions(-DBZIP2)
    if(BZIP2_INCLUDE_DIRS)
      include_directories(${BZIP2_INCLUDE_DIRS})
    else()
      include_directories(${BZIP2_INCLUDE_DIR})
    endif()
    list(APPEND THIRDPARTY_LIBS ${BZIP2_LIBRARIES})
  endif()

  if(WITH_LZ4)
    find_package(lz4 REQUIRED)
    add_definitions(-DLZ4)
    list(APPEND THIRDPARTY_LIBS lz4::lz4)
  endif()

  if(WITH_ZSTD)
    find_package(zstd REQUIRED)
    add_definitions(-DZSTD)
    include_directories(${ZSTD_INCLUDE_DIR})
    list(APPEND THIRDPARTY_LIBS zstd::zstd)
  endif()
endif()

# 生成对应的时间戳 TS
string(TIMESTAMP TS &quot;%Y-%m-%d %H:%M:%S&quot; UTC)
# 设置相应的参数
set(BUILD_DATE &quot;${TS}&quot; CACHE STRING &quot;the time we first built rocksdb&quot;)

# 搜索依赖 Git
find_package(Git)

# 如果找到了 Git 并且当且目录包含 Git 目录
if(GIT_FOUND AND EXISTS &quot;${CMAKE_CURRENT_SOURCE_DIR}/.git&quot;)
  # 执行系统命令 git rev-parse HEAD，得到了对应的 CommitID 保存到了 GIT_SHA  （标准输出）
  execute_process(WORKING_DIRECTORY &quot;${CMAKE_CURRENT_SOURCE_DIR}&quot; OUTPUT_VARIABLE GIT_SHA COMMAND &quot;${GIT_EXECUTABLE}&quot; rev-parse HEAD )
  # 执行命令 git diff-index HEAD --quiet 比较树与工作树或索引并禁止输出，保存命令执行结果到 GIT_MOD
  execute_process(WORKING_DIRECTORY &quot;${CMAKE_CURRENT_SOURCE_DIR}&quot; RESULT_VARIABLE GIT_MOD COMMAND &quot;${GIT_EXECUTABLE}&quot; diff-index HEAD --quiet)
  # 执行命令 git log -1 --date=format:&quot;%Y-%m-%d %T&quot; --format=&quot;%ad&quot; 输出最近的 git 提交的时间到 GIT_DATE
  execute_process(WORKING_DIRECTORY &quot;${CMAKE_CURRENT_SOURCE_DIR}&quot; OUTPUT_VARIABLE GIT_DATE COMMAND &quot;${GIT_EXECUTABLE}&quot; log -1 --date=format:&quot;%Y-%m-%d %T&quot; --format=&quot;%ad&quot;)
  # 执行命令 git symbolic-ref -q --short HEAD OUTPUT_STRIP_TRAILING_WHITESPACE
  # 输出对应的 tag 到 GIT_TAG 和命令执行结果 rv
  execute_process(WORKING_DIRECTORY &quot;${CMAKE_CURRENT_SOURCE_DIR}&quot; OUTPUT_VARIABLE GIT_TAG RESULT_VARIABLE rv COMMAND &quot;${GIT_EXECUTABLE}&quot; symbolic-ref -q --short HEAD OUTPUT_STRIP_TRAILING_WHITESPACE)
  # 如果 rv != 0
  if (rv AND NOT rv EQUAL 0)
    # git describe --tags --exact-match OUTPUT_STRIP_TRAILING_WHITESPACE
    # 结果输出到 GIT_TAG 
    execute_process(WORKING_DIRECTORY &quot;${CMAKE_CURRENT_SOURCE_DIR}&quot; OUTPUT_VARIABLE GIT_TAG COMMAND &quot;${GIT_EXECUTABLE}&quot; describe --tags --exact-match OUTPUT_STRIP_TRAILING_WHITESPACE)
  endif()
else()
  set(GIT_SHA 0)
  set(GIT_MOD 1)
endif()
# 使用正则表达式格式化对应的 GIT_SHA 和 GIT_DATE
string(REGEX REPLACE &quot;[^0-9a-fA-F]+&quot; &quot;&quot; GIT_SHA &quot;${GIT_SHA}&quot;)
string(REGEX REPLACE &quot;[^0-9: /-]+&quot; &quot;&quot; GIT_DATE &quot;${GIT_DATE}&quot;)

option(WITH_MD_LIBRARY &quot;build with MD&quot; ON)
if(WIN32 AND MSVC)
  if(WITH_MD_LIBRARY)
    set(RUNTIME_LIBRARY &quot;MD&quot;)
  else()
    set(RUNTIME_LIBRARY &quot;MT&quot;)
  endif()
endif()

set(BUILD_VERSION_CC ${CMAKE_BINARY_DIR}/build_version.cc)
configure_file(util/build_version.cc.in ${BUILD_VERSION_CC} @ONLY)

if(MSVC)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /Zi /nologo /EHsc /GS /Gd /GR /GF /fp:precise /Zc:wchar_t /Zc:forScope /errorReport:queue&quot;)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /FC /d2Zi+ /W4 /wd4127 /wd4800 /wd4996 /wd4351 /wd4100 /wd4204 /wd4324&quot;)
else()
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -W -Wextra -Wall -pthread&quot;)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -Wsign-compare -Wshadow -Wno-unused-parameter -Wno-unused-variable -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-strict-aliasing&quot;)
  if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;x86_64&quot;)
    set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -Wstrict-prototypes&quot;)
  endif()
  if(MINGW)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -Wno-format -fno-asynchronous-unwind-tables&quot;)
    add_definitions(-D_POSIX_C_SOURCE=1)
  endif()
  if(NOT CMAKE_BUILD_TYPE STREQUAL &quot;Debug&quot;)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fno-omit-frame-pointer&quot;)
    include(CheckCXXCompilerFlag)
    CHECK_CXX_COMPILER_FLAG(&quot;-momit-leaf-frame-pointer&quot; HAVE_OMIT_LEAF_FRAME_POINTER)
    if(HAVE_OMIT_LEAF_FRAME_POINTER)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -momit-leaf-frame-pointer&quot;)
    endif()
  endif()
endif()

include(CheckCCompilerFlag)
if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^(powerpc|ppc)64&quot;)
  CHECK_C_COMPILER_FLAG(&quot;-mcpu=power9&quot; HAS_POWER9)
  if(HAS_POWER9)
    set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -mcpu=power9 -mtune=power9&quot;)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -mcpu=power9 -mtune=power9&quot;)
  else()
    CHECK_C_COMPILER_FLAG(&quot;-mcpu=power8&quot; HAS_POWER8)
    if(HAS_POWER8)
      set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -mcpu=power8 -mtune=power8&quot;)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -mcpu=power8 -mtune=power8&quot;)
    endif(HAS_POWER8)
  endif(HAS_POWER9)
  CHECK_C_COMPILER_FLAG(&quot;-maltivec&quot; HAS_ALTIVEC)
  if(HAS_ALTIVEC)
    message(STATUS &quot; HAS_ALTIVEC yes&quot;)
    set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -maltivec&quot;)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -maltivec&quot;)
  endif(HAS_ALTIVEC)
endif(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^(powerpc|ppc)64&quot;)

if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;arm64|aarch64|AARCH64&quot;)
        CHECK_C_COMPILER_FLAG(&quot;-march=armv8-a+crc+crypto&quot; HAS_ARMV8_CRC)
  if(HAS_ARMV8_CRC)
    message(STATUS &quot; HAS_ARMV8_CRC yes&quot;)
    set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -march=armv8-a+crc+crypto -Wno-unused-function&quot;)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -march=armv8-a+crc+crypto -Wno-unused-function&quot;)
  endif(HAS_ARMV8_CRC)
endif(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;arm64|aarch64|AARCH64&quot;)

if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;s390x&quot;)
  CHECK_C_COMPILER_FLAG(&quot;-march=native&quot; HAS_S390X_MARCH_NATIVE)
  if(HAS_S390X_MARCH_NATIVE)
    message(STATUS &quot; HAS_S390X_MARCH_NATIVE yes&quot;)
  endif(HAS_S390X_MARCH_NATIVE)
endif(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;s390x&quot;)

option(PORTABLE &quot;build a portable binary&quot; OFF)
option(FORCE_SSE42 &quot;force building with SSE4.2, even when PORTABLE=ON&quot; OFF)
option(FORCE_AVX &quot;force building with AVX, even when PORTABLE=ON&quot; OFF)
option(FORCE_AVX2 &quot;force building with AVX2, even when PORTABLE=ON&quot; OFF)
if(PORTABLE)
  # MSVC does not need a separate compiler flag to enable SSE4.2; if nmmintrin.h
  # is available, it is available by default.
  if(FORCE_SSE42 AND NOT MSVC)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -msse4.2 -mpclmul&quot;)
  endif()
  if(MSVC)
    if(FORCE_AVX)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /arch:AVX&quot;)
    endif()
    # MSVC automatically enables BMI / lzcnt with AVX2.
    if(FORCE_AVX2)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /arch:AVX2&quot;)
    endif()
  else()
    if(FORCE_AVX)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -mavx&quot;)
    endif()
    if(FORCE_AVX2)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -mavx2 -mbmi -mlzcnt&quot;)
    endif()
    if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^s390x&quot;)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -march=z196&quot;)
    endif()
  endif()
else()
  if(MSVC)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /arch:AVX2&quot;)
  else()
    if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^s390x&quot; AND NOT HAS_S390X_MARCH_NATIVE)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -march=z196&quot;)
    elseif(NOT CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^(powerpc|ppc)64&quot; AND NOT HAS_ARMV8_CRC)
      set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -march=native&quot;)
    endif()
  endif()
endif()

include(CheckCXXSourceCompiles)
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
if(NOT MSVC)
  set(CMAKE_REQUIRED_FLAGS &quot;-msse4.2 -mpclmul&quot;)
endif()

CHECK_CXX_SOURCE_COMPILES(&quot;
#include &lt;cstdint&gt;
#include &lt;nmmintrin.h&gt;
#include &lt;wmmintrin.h&gt;
int main() {
  volatile uint32_t x = _mm_crc32_u32(0, 0);
  const auto a = _mm_set_epi64x(0, 0);
  const auto b = _mm_set_epi64x(0, 0);
  const auto c = _mm_clmulepi64_si128(a, b, 0x00);
  auto d = _mm_cvtsi128_si64(c);
}
&quot; HAVE_SSE42)
if(HAVE_SSE42)
  add_definitions(-DHAVE_SSE42)
  add_definitions(-DHAVE_PCLMUL)
elseif(FORCE_SSE42)
  message(FATAL_ERROR &quot;FORCE_SSE42=ON but unable to compile with SSE4.2 enabled&quot;)
endif()

# Check if -latomic is required or not
if (NOT MSVC)
  set(CMAKE_REQUIRED_FLAGS &quot;--std=c++17&quot;)
  CHECK_CXX_SOURCE_COMPILES(&quot;
#include &lt;atomic&gt;
std::atomic&lt;uint64_t&gt; x(0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  bool b = x.is_lock_free();
  return 0;
}
&quot; BUILTIN_ATOMIC)
  if (NOT BUILTIN_ATOMIC)
    #TODO: Check if -latomic exists
    list(APPEND THIRDPARTY_LIBS atomic)
  endif()
endif()

if (WITH_LIBURING)
  find_package(uring)
  if (uring_FOUND)
    add_definitions(-DROCKSDB_IOURING_PRESENT)
    list(APPEND THIRDPARTY_LIBS uring::uring)
  endif()
endif()

# Reset the required flags
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})

# thread_local is part of C++11 and later (TODO: clean up this define)
add_definitions(-DROCKSDB_SUPPORT_THREAD_LOCAL)

option(WITH_IOSTATS_CONTEXT &quot;Enable IO stats context&quot; ON)
if (NOT WITH_IOSTATS_CONTEXT)
  add_definitions(-DNIOSTATS_CONTEXT)
endif()

option(WITH_PERF_CONTEXT &quot;Enable perf context&quot; ON)
if (NOT WITH_PERF_CONTEXT)
  add_definitions(-DNPERF_CONTEXT)
endif()

option(FAIL_ON_WARNINGS &quot;Treat compile warnings as errors&quot; ON)
if(FAIL_ON_WARNINGS)
  if(MSVC)
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} /WX&quot;)
  else() # assume GCC
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -Werror&quot;)
  endif()
endif()

option(WITH_ASAN &quot;build with ASAN&quot; OFF)
if(WITH_ASAN)
  set(CMAKE_EXE_LINKER_FLAGS &quot;${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address&quot;)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fsanitize=address&quot;)
  set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -fsanitize=address&quot;)
  if(WITH_JEMALLOC)
    message(FATAL &quot;ASAN does not work well with JeMalloc&quot;)
  endif()
endif()

option(WITH_TSAN &quot;build with TSAN&quot; OFF)
if(WITH_TSAN)
  set(CMAKE_EXE_LINKER_FLAGS &quot;${CMAKE_EXE_LINKER_FLAGS} -fsanitize=thread -pie&quot;)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fsanitize=thread -fPIC&quot;)
  set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -fsanitize=thread -fPIC&quot;)
  if(WITH_JEMALLOC)
    message(FATAL &quot;TSAN does not work well with JeMalloc&quot;)
  endif()
endif()

option(WITH_UBSAN &quot;build with UBSAN&quot; OFF)
if(WITH_UBSAN)
  add_definitions(-DROCKSDB_UBSAN_RUN)
  set(CMAKE_EXE_LINKER_FLAGS &quot;${CMAKE_EXE_LINKER_FLAGS} -fsanitize=undefined&quot;)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fsanitize=undefined&quot;)
  set(CMAKE_C_FLAGS &quot;${CMAKE_C_FLAGS} -fsanitize=undefined&quot;)
  if(WITH_JEMALLOC)
    message(FATAL &quot;UBSAN does not work well with JeMalloc&quot;)
  endif()
endif()

option(WITH_NUMA &quot;build with NUMA policy support&quot; OFF)
if(WITH_NUMA)
  find_package(NUMA REQUIRED)
  add_definitions(-DNUMA)
  include_directories(${NUMA_INCLUDE_DIR})
  list(APPEND THIRDPARTY_LIBS NUMA::NUMA)
endif()

option(WITH_TBB &quot;build with Threading Building Blocks (TBB)&quot; OFF)
if(WITH_TBB)
  find_package(TBB REQUIRED)
  add_definitions(-DTBB)
  list(APPEND THIRDPARTY_LIBS TBB::TBB)
endif()

# Stall notifications eat some performance from inserts
option(DISABLE_STALL_NOTIF &quot;Build with stall notifications&quot; OFF)
if(DISABLE_STALL_NOTIF)
  add_definitions(-DROCKSDB_DISABLE_STALL_NOTIFICATION)
endif()

option(WITH_DYNAMIC_EXTENSION &quot;build with dynamic extension support&quot; OFF)
if(NOT WITH_DYNAMIC_EXTENSION)
  add_definitions(-DROCKSDB_NO_DYNAMIC_EXTENSION)
endif()

option(ASSERT_STATUS_CHECKED &quot;build with assert status checked&quot; OFF)
if (ASSERT_STATUS_CHECKED)
  message(STATUS &quot;Build with assert status checked&quot;)
  add_definitions(-DROCKSDB_ASSERT_STATUS_CHECKED)
endif()

if(DEFINED USE_RTTI)
  if(USE_RTTI)
    message(STATUS &quot;Enabling RTTI&quot;)
    set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI&quot;)
    set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} -DROCKSDB_USE_RTTI&quot;)
  else()
    if(MSVC)
      message(STATUS &quot;Disabling RTTI in Release builds. Always on in Debug.&quot;)
      set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI&quot;)
      set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} /GR-&quot;)
    else()
      message(STATUS &quot;Disabling RTTI in Release builds&quot;)
      set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} -fno-rtti&quot;)
      set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} -fno-rtti&quot;)
    endif()
  endif()
else()
  message(STATUS &quot;Enabling RTTI in Debug builds only (default)&quot;)
  set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} -DROCKSDB_USE_RTTI&quot;)
  if(MSVC)
     set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} /GR-&quot;)
  else()
    set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} -fno-rtti&quot;)
  endif()
endif()

# Used to run CI build and tests so we can run faster
option(OPTDBG &quot;Build optimized debug build with MSVC&quot; OFF)
option(WITH_RUNTIME_DEBUG &quot;build with debug version of runtime library&quot; ON)
if(MSVC)
  if(OPTDBG)
    message(STATUS &quot;Debug optimization is enabled&quot;)
    set(CMAKE_CXX_FLAGS_DEBUG &quot;/Oxt&quot;)
  else()
    set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} /Od /RTC1&quot;)

    # Minimal Build is deprecated after MSVC 2015
    if( MSVC_VERSION GREATER 1900 )
      set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} /Gm-&quot;)
    else()
      set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} /Gm&quot;)
    endif()

  endif()
  if(WITH_RUNTIME_DEBUG)
    set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} /${RUNTIME_LIBRARY}d&quot;)
  else()
    set(CMAKE_CXX_FLAGS_DEBUG &quot;${CMAKE_CXX_FLAGS_DEBUG} /${RUNTIME_LIBRARY}&quot;)
  endif()
  set(CMAKE_CXX_FLAGS_RELEASE &quot;${CMAKE_CXX_FLAGS_RELEASE} /Oxt /Zp8 /Gm- /Gy /${RUNTIME_LIBRARY}&quot;)

  set(CMAKE_SHARED_LINKER_FLAGS &quot;${CMAKE_SHARED_LINKER_FLAGS} /DEBUG&quot;)
  set(CMAKE_EXE_LINKER_FLAGS &quot;${CMAKE_EXE_LINKER_FLAGS} /DEBUG&quot;)
endif()

if(CMAKE_COMPILER_IS_GNUCXX)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fno-builtin-memcmp&quot;)
endif()

option(ROCKSDB_LITE &quot;Build RocksDBLite version&quot; OFF)
if(ROCKSDB_LITE)
  add_definitions(-DROCKSDB_LITE)
  set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fno-exceptions -Os&quot;)
endif()

if(CMAKE_SYSTEM_NAME MATCHES &quot;Cygwin&quot;)
  add_definitions(-fno-builtin-memcmp -DCYGWIN)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;Darwin&quot;)
  add_definitions(-DOS_MACOSX)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;Linux&quot;)
  add_definitions(-DOS_LINUX)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;SunOS&quot;)
  add_definitions(-DOS_SOLARIS)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;kFreeBSD&quot;)
  add_definitions(-DOS_GNU_KFREEBSD)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;FreeBSD&quot;)
  add_definitions(-DOS_FREEBSD)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;NetBSD&quot;)
  add_definitions(-DOS_NETBSD)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;OpenBSD&quot;)
  add_definitions(-DOS_OPENBSD)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;DragonFly&quot;)
  add_definitions(-DOS_DRAGONFLYBSD)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;Android&quot;)
  add_definitions(-DOS_ANDROID)
elseif(CMAKE_SYSTEM_NAME MATCHES &quot;Windows&quot;)
  add_definitions(-DWIN32 -DOS_WIN -D_MBCS -DWIN64 -DNOMINMAX)
  if(MINGW)
    add_definitions(-D_WIN32_WINNT=_WIN32_WINNT_VISTA)
  endif()
endif()

if(NOT WIN32)
  add_definitions(-DROCKSDB_PLATFORM_POSIX -DROCKSDB_LIB_IO_POSIX)
endif()

option(WITH_FALLOCATE &quot;build with fallocate&quot; ON)
if(WITH_FALLOCATE)
  CHECK_CXX_SOURCE_COMPILES(&quot;
#include &lt;fcntl.h&gt;
#include &lt;linux/falloc.h&gt;
int main() {
 int fd = open(\&quot;/dev/null\&quot;, 0);
 fallocate(fd, FALLOC_FL_KEEP_SIZE, 0, 1024);
}
&quot; HAVE_FALLOCATE)
  if(HAVE_FALLOCATE)
    add_definitions(-DROCKSDB_FALLOCATE_PRESENT)
  endif()
endif()

CHECK_CXX_SOURCE_COMPILES(&quot;
#include &lt;fcntl.h&gt;
int main() {
  int fd = open(\&quot;/dev/null\&quot;, 0);
  sync_file_range(fd, 0, 1024, SYNC_FILE_RANGE_WRITE);
}
&quot; HAVE_SYNC_FILE_RANGE_WRITE)
if(HAVE_SYNC_FILE_RANGE_WRITE)
  add_definitions(-DROCKSDB_RANGESYNC_PRESENT)
endif()

CHECK_CXX_SOURCE_COMPILES(&quot;
#include &lt;pthread.h&gt;
int main() {
  (void) PTHREAD_MUTEX_ADAPTIVE_NP;
}
&quot; HAVE_PTHREAD_MUTEX_ADAPTIVE_NP)
if(HAVE_PTHREAD_MUTEX_ADAPTIVE_NP)
  add_definitions(-DROCKSDB_PTHREAD_ADAPTIVE_MUTEX)
endif()

include(CheckCXXSymbolExists)
if(CMAKE_SYSTEM_NAME MATCHES &quot;^FreeBSD&quot;)
  check_cxx_symbol_exists(malloc_usable_size malloc_np.h HAVE_MALLOC_USABLE_SIZE)
else()
  check_cxx_symbol_exists(malloc_usable_size malloc.h HAVE_MALLOC_USABLE_SIZE)
endif()
if(HAVE_MALLOC_USABLE_SIZE)
  add_definitions(-DROCKSDB_MALLOC_USABLE_SIZE)
endif()

check_cxx_symbol_exists(sched_getcpu sched.h HAVE_SCHED_GETCPU)
if(HAVE_SCHED_GETCPU)
  add_definitions(-DROCKSDB_SCHED_GETCPU_PRESENT)
endif()

check_cxx_symbol_exists(getauxval auvx.h HAVE_AUXV_GETAUXVAL)
if(HAVE_AUXV_GETAUXVAL)
  add_definitions(-DROCKSDB_AUXV_GETAUXVAL_PRESENT)
endif()

check_cxx_symbol_exists(F_FULLFSYNC &quot;fcntl.h&quot; HAVE_FULLFSYNC)
if(HAVE_FULLFSYNC)
  add_definitions(-DHAVE_FULLFSYNC)
endif()

include_directories(${PROJECT_SOURCE_DIR})
include_directories(${PROJECT_SOURCE_DIR}/include)
if(WITH_FOLLY_DISTRIBUTED_MUTEX)
  include_directories(${PROJECT_SOURCE_DIR}/third-party/folly)
endif()
find_package(Threads REQUIRED)

# Main library source code

set(SOURCES
        cache/cache.cc
        cache/cache_entry_roles.cc
        cache/cache_key.cc
        cache/cache_reservation_manager.cc
        cache/clock_cache.cc
        cache/lru_cache.cc
        cache/sharded_cache.cc
        db/arena_wrapped_db_iter.cc
        db/blob/blob_fetcher.cc
        db/blob/blob_file_addition.cc
        db/blob/blob_file_builder.cc
        db/blob/blob_file_cache.cc
        db/blob/blob_file_garbage.cc
        db/blob/blob_file_meta.cc
        db/blob/blob_file_reader.cc
        db/blob/blob_garbage_meter.cc
        db/blob/blob_log_format.cc
        db/blob/blob_log_sequential_reader.cc
        db/blob/blob_log_writer.cc
        db/blob/prefetch_buffer_collection.cc
        db/builder.cc
        db/c.cc
        db/column_family.cc
        db/compaction/compaction.cc
        db/compaction/compaction_iterator.cc
        db/compaction/compaction_picker.cc
        db/compaction/compaction_job.cc
        db/compaction/compaction_picker_fifo.cc
        db/compaction/compaction_picker_level.cc
        db/compaction/compaction_picker_universal.cc
        db/compaction/sst_partitioner.cc
        db/convenience.cc
        db/db_filesnapshot.cc
        db/db_impl/compacted_db_impl.cc
        db/db_impl/db_impl.cc
        db/db_impl/db_impl_write.cc
        db/db_impl/db_impl_compaction_flush.cc
        db/db_impl/db_impl_files.cc
        db/db_impl/db_impl_open.cc
        db/db_impl/db_impl_debug.cc
        db/db_impl/db_impl_experimental.cc
        db/db_impl/db_impl_readonly.cc
        db/db_impl/db_impl_secondary.cc
        db/db_info_dumper.cc
        db/db_iter.cc
        db/dbformat.cc
        db/error_handler.cc
        db/event_helpers.cc
        db/experimental.cc
        db/external_sst_file_ingestion_job.cc
        db/file_indexer.cc
        db/flush_job.cc
        db/flush_scheduler.cc
        db/forward_iterator.cc
        db/import_column_family_job.cc
        db/internal_stats.cc
        db/logs_with_prep_tracker.cc
        db/log_reader.cc
        db/log_writer.cc
        db/malloc_stats.cc
        db/memtable.cc
        db/memtable_list.cc
        db/merge_helper.cc
        db/merge_operator.cc
        db/output_validator.cc
        db/periodic_work_scheduler.cc
        db/range_del_aggregator.cc
        db/range_tombstone_fragmenter.cc
        db/repair.cc
        db/snapshot_impl.cc
        db/table_cache.cc
        db/table_properties_collector.cc
        db/transaction_log_impl.cc
        db/trim_history_scheduler.cc
        db/version_builder.cc
        db/version_edit.cc
        db/version_edit_handler.cc
        db/version_set.cc
        db/wal_edit.cc
        db/wal_manager.cc
        db/write_batch.cc
        db/write_batch_base.cc
        db/write_controller.cc
        db/write_thread.cc
        env/composite_env.cc
        env/env.cc
        env/env_chroot.cc
        env/env_encryption.cc
        env/file_system.cc
        env/file_system_tracer.cc
        env/fs_remap.cc
        env/mock_env.cc
        env/unique_id_gen.cc
        file/delete_scheduler.cc
        file/file_prefetch_buffer.cc
        file/file_util.cc
        file/filename.cc
        file/line_file_reader.cc
        file/random_access_file_reader.cc
        file/read_write_util.cc
        file/readahead_raf.cc
        file/sequence_file_reader.cc
        file/sst_file_manager_impl.cc
        file/writable_file_writer.cc
        logging/auto_roll_logger.cc
        logging/event_logger.cc
        logging/log_buffer.cc
        memory/arena.cc
        memory/concurrent_arena.cc
        memory/jemalloc_nodump_allocator.cc
        memory/memkind_kmem_allocator.cc
        memory/memory_allocator.cc
        memtable/alloc_tracker.cc
        memtable/hash_linklist_rep.cc
        memtable/hash_skiplist_rep.cc
        memtable/skiplistrep.cc
        memtable/vectorrep.cc
        memtable/write_buffer_manager.cc
        monitoring/histogram.cc
        monitoring/histogram_windowing.cc
        monitoring/in_memory_stats_history.cc
        monitoring/instrumented_mutex.cc
        monitoring/iostats_context.cc
        monitoring/perf_context.cc
        monitoring/perf_level.cc
        monitoring/persistent_stats_history.cc
        monitoring/statistics.cc
        monitoring/thread_status_impl.cc
        monitoring/thread_status_updater.cc
        monitoring/thread_status_util.cc
        monitoring/thread_status_util_debug.cc
        options/cf_options.cc
        options/configurable.cc
        options/customizable.cc
        options/db_options.cc
        options/options.cc
        options/options_helper.cc
        options/options_parser.cc
        port/stack_trace.cc
        table/adaptive/adaptive_table_factory.cc
        table/block_based/binary_search_index_reader.cc
        table/block_based/block.cc
        table/block_based/block_based_filter_block.cc
        table/block_based/block_based_table_builder.cc
        table/block_based/block_based_table_factory.cc
        table/block_based/block_based_table_iterator.cc
        table/block_based/block_based_table_reader.cc
        table/block_based/block_builder.cc
        table/block_based/block_prefetcher.cc
        table/block_based/block_prefix_index.cc
        table/block_based/data_block_hash_index.cc
        table/block_based/data_block_footer.cc
        table/block_based/filter_block_reader_common.cc
        table/block_based/filter_policy.cc
        table/block_based/flush_block_policy.cc
        table/block_based/full_filter_block.cc
        table/block_based/hash_index_reader.cc
        table/block_based/index_builder.cc
        table/block_based/index_reader_common.cc
        table/block_based/parsed_full_filter_block.cc
        table/block_based/partitioned_filter_block.cc
        table/block_based/partitioned_index_iterator.cc
        table/block_based/partitioned_index_reader.cc
        table/block_based/reader_common.cc
        table/block_based/uncompression_dict_reader.cc
        table/block_fetcher.cc
        table/cuckoo/cuckoo_table_builder.cc
        table/cuckoo/cuckoo_table_factory.cc
        table/cuckoo/cuckoo_table_reader.cc
        table/format.cc
        table/get_context.cc
        table/iterator.cc
        table/merging_iterator.cc
        table/meta_blocks.cc
        table/persistent_cache_helper.cc
        table/plain/plain_table_bloom.cc
        table/plain/plain_table_builder.cc
        table/plain/plain_table_factory.cc
        table/plain/plain_table_index.cc
        table/plain/plain_table_key_coding.cc
        table/plain/plain_table_reader.cc
        table/sst_file_dumper.cc
        table/sst_file_reader.cc
        table/sst_file_writer.cc
        table/table_factory.cc
        table/table_properties.cc
        table/two_level_iterator.cc
        table/unique_id.cc
        test_util/sync_point.cc
        test_util/sync_point_impl.cc
        test_util/testutil.cc
        test_util/transaction_test_util.cc
        tools/block_cache_analyzer/block_cache_trace_analyzer.cc
        tools/dump/db_dump_tool.cc
        tools/io_tracer_parser_tool.cc
        tools/ldb_cmd.cc
        tools/ldb_tool.cc
        tools/sst_dump_tool.cc
        tools/trace_analyzer_tool.cc
        trace_replay/block_cache_tracer.cc
        trace_replay/io_tracer.cc
        trace_replay/trace_record_handler.cc
        trace_replay/trace_record_result.cc
        trace_replay/trace_record.cc
        trace_replay/trace_replay.cc
        util/coding.cc
        util/compaction_job_stats_impl.cc
        util/comparator.cc
        util/compression_context_cache.cc
        util/concurrent_task_limiter_impl.cc
        util/crc32c.cc
        util/dynamic_bloom.cc
        util/hash.cc
        util/murmurhash.cc
        util/random.cc
        util/rate_limiter.cc
        util/ribbon_config.cc
        util/slice.cc
        util/file_checksum_helper.cc
        util/status.cc
        util/string_util.cc
        util/thread_local.cc
        util/threadpool_imp.cc
        util/xxhash.cc
        utilities/backupable/backupable_db.cc
        utilities/blob_db/blob_compaction_filter.cc
        utilities/blob_db/blob_db.cc
        utilities/blob_db/blob_db_impl.cc
        utilities/blob_db/blob_db_impl_filesnapshot.cc
        utilities/blob_db/blob_dump_tool.cc
        utilities/blob_db/blob_file.cc
        utilities/cache_dump_load.cc
        utilities/cache_dump_load_impl.cc
        utilities/cassandra/cassandra_compaction_filter.cc
        utilities/cassandra/format.cc
        utilities/cassandra/merge_operator.cc
        utilities/checkpoint/checkpoint_impl.cc
        utilities/compaction_filters.cc
        utilities/compaction_filters/remove_emptyvalue_compactionfilter.cc
        utilities/counted_fs.cc
        utilities/debug.cc
        utilities/env_mirror.cc
        utilities/env_timed.cc
        utilities/fault_injection_env.cc
        utilities/fault_injection_fs.cc
        utilities/fault_injection_secondary_cache.cc
        utilities/leveldb_options/leveldb_options.cc
        utilities/memory/memory_util.cc
        utilities/merge_operators.cc
        utilities/merge_operators/bytesxor.cc
        utilities/merge_operators/max.cc
        utilities/merge_operators/put.cc
        utilities/merge_operators/sortlist.cc
        utilities/merge_operators/string_append/stringappend.cc
        utilities/merge_operators/string_append/stringappend2.cc
        utilities/merge_operators/uint64add.cc
        utilities/object_registry.cc
        utilities/option_change_migration/option_change_migration.cc
        utilities/options/options_util.cc
        utilities/persistent_cache/block_cache_tier.cc
        utilities/persistent_cache/block_cache_tier_file.cc
        utilities/persistent_cache/block_cache_tier_metadata.cc
        utilities/persistent_cache/persistent_cache_tier.cc
        utilities/persistent_cache/volatile_tier_impl.cc
        utilities/simulator_cache/cache_simulator.cc
        utilities/simulator_cache/sim_cache.cc
        utilities/table_properties_collectors/compact_on_deletion_collector.cc
        utilities/trace/file_trace_reader_writer.cc
        utilities/trace/replayer_impl.cc
        utilities/transactions/lock/lock_manager.cc
        utilities/transactions/lock/point/point_lock_tracker.cc
        utilities/transactions/lock/point/point_lock_manager.cc
        utilities/transactions/lock/range/range_tree/range_tree_lock_manager.cc
        utilities/transactions/lock/range/range_tree/range_tree_lock_tracker.cc
        utilities/transactions/optimistic_transaction_db_impl.cc
        utilities/transactions/optimistic_transaction.cc
        utilities/transactions/pessimistic_transaction.cc
        utilities/transactions/pessimistic_transaction_db.cc
        utilities/transactions/snapshot_checker.cc
        utilities/transactions/transaction_base.cc
        utilities/transactions/transaction_db_mutex_impl.cc
        utilities/transactions/transaction_util.cc
        utilities/transactions/write_prepared_txn.cc
        utilities/transactions/write_prepared_txn_db.cc
        utilities/transactions/write_unprepared_txn.cc
        utilities/transactions/write_unprepared_txn_db.cc
        utilities/ttl/db_ttl_impl.cc
        utilities/wal_filter.cc
        utilities/write_batch_with_index/write_batch_with_index.cc
        utilities/write_batch_with_index/write_batch_with_index_internal.cc)

list(APPEND SOURCES
  utilities/transactions/lock/range/range_tree/lib/locktree/concurrent_tree.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/keyrange.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/lock_request.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/locktree.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/manager.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/range_buffer.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/treenode.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/txnid_set.cc
  utilities/transactions/lock/range/range_tree/lib/locktree/wfg.cc
  utilities/transactions/lock/range/range_tree/lib/standalone_port.cc
  utilities/transactions/lock/range/range_tree/lib/util/dbt.cc
  utilities/transactions/lock/range/range_tree/lib/util/memarena.cc)

message(STATUS &quot;ROCKSDB_PLUGINS: ${ROCKSDB_PLUGINS}&quot;)
if ( ROCKSDB_PLUGINS )
  string(REPLACE &quot; &quot; &quot;;&quot; PLUGINS ${ROCKSDB_PLUGINS})
  foreach (plugin ${PLUGINS})
    add_subdirectory(&quot;plugin/${plugin}&quot;)
    foreach (src ${${plugin}_SOURCES})
      list(APPEND SOURCES plugin/${plugin}/${src})
      set_source_files_properties(
        plugin/${plugin}/${src}
        PROPERTIES COMPILE_FLAGS &quot;${${plugin}_COMPILE_FLAGS}&quot;)
    endforeach()
    foreach (path ${${plugin}_INCLUDE_PATHS})
      include_directories(${path})
    endforeach()
    foreach (lib ${${plugin}_LIBS})
      list(APPEND THIRDPARTY_LIBS ${lib})
    endforeach()
    foreach (link_path ${${plugin}_LINK_PATHS})
      link_directories(AFTER ${link_path})
    endforeach()
    set(CMAKE_SHARED_LINKER_FLAGS &quot;${CMAKE_SHARED_LINKER_FLAGS} ${${plugin}_CMAKE_SHARED_LINKER_FLAGS}&quot;)
    set(CMAKE_EXE_LINKER_FLAGS &quot;${CMAKE_EXE_LINKER_FLAGS} ${${plugin}_CMAKE_EXE_LINKER_FLAGS}&quot;)
  endforeach()
endif()

if(HAVE_SSE42 AND NOT MSVC)
  set_source_files_properties(
    util/crc32c.cc
    PROPERTIES COMPILE_FLAGS &quot;-msse4.2 -mpclmul&quot;)
endif()

if(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^(powerpc|ppc)64&quot;)
  list(APPEND SOURCES
    util/crc32c_ppc.c
    util/crc32c_ppc_asm.S)
endif(CMAKE_SYSTEM_PROCESSOR MATCHES &quot;^(powerpc|ppc)64&quot;)

if(HAS_ARMV8_CRC)
  list(APPEND SOURCES
    util/crc32c_arm64.cc)
endif(HAS_ARMV8_CRC)

if(WIN32)
  list(APPEND SOURCES
    port/win/io_win.cc
    port/win/env_win.cc
    port/win/env_default.cc
    port/win/port_win.cc
    port/win/win_logger.cc
    port/win/win_thread.cc)
if(WITH_XPRESS)
  list(APPEND SOURCES
    port/win/xpress_win.cc)
endif()

if(WITH_JEMALLOC)
  list(APPEND SOURCES
    port/win/win_jemalloc.cc)
endif()

else()
  list(APPEND SOURCES
    port/port_posix.cc
    env/env_posix.cc
    env/fs_posix.cc
    env/io_posix.cc)
endif()

if(WITH_FOLLY_DISTRIBUTED_MUTEX)
  list(APPEND SOURCES
    third-party/folly/folly/detail/Futex.cpp
    third-party/folly/folly/synchronization/AtomicNotification.cpp
    third-party/folly/folly/synchronization/DistributedMutex.cpp
    third-party/folly/folly/synchronization/ParkingLot.cpp
    third-party/folly/folly/synchronization/WaitOptions.cpp)
endif()

set(ROCKSDB_STATIC_LIB rocksdb${ARTIFACT_SUFFIX})
set(ROCKSDB_SHARED_LIB rocksdb-shared${ARTIFACT_SUFFIX})

option(ROCKSDB_BUILD_SHARED &quot;Build shared versions of the RocksDB libraries&quot; ON)


if(WIN32)
  set(SYSTEM_LIBS ${SYSTEM_LIBS} shlwapi.lib rpcrt4.lib)
else()
  set(SYSTEM_LIBS ${CMAKE_THREAD_LIBS_INIT})
endif()

add_library(${ROCKSDB_STATIC_LIB} STATIC ${SOURCES} ${BUILD_VERSION_CC})
target_link_libraries(${ROCKSDB_STATIC_LIB} PRIVATE
  ${THIRDPARTY_LIBS} ${SYSTEM_LIBS})

if(ROCKSDB_BUILD_SHARED)
  add_library(${ROCKSDB_SHARED_LIB} SHARED ${SOURCES} ${BUILD_VERSION_CC})
  target_link_libraries(${ROCKSDB_SHARED_LIB} PRIVATE
    ${THIRDPARTY_LIBS} ${SYSTEM_LIBS})

  if(WIN32)
    set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
      COMPILE_DEFINITIONS &quot;ROCKSDB_DLL;ROCKSDB_LIBRARY_EXPORTS&quot;)
    if(MSVC)
      set_target_properties(${ROCKSDB_STATIC_LIB} PROPERTIES
        COMPILE_FLAGS &quot;/Fd${CMAKE_CFG_INTDIR}/${ROCKSDB_STATIC_LIB}.pdb&quot;)
      set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
        COMPILE_FLAGS &quot;/Fd${CMAKE_CFG_INTDIR}/${ROCKSDB_SHARED_LIB}.pdb&quot;)
    endif()
  else()
    set_target_properties(${ROCKSDB_SHARED_LIB} PROPERTIES
                          LINKER_LANGUAGE CXX
                          VERSION ${rocksdb_VERSION}
                          SOVERSION ${rocksdb_VERSION_MAJOR}
                          OUTPUT_NAME &quot;rocksdb${ARTIFACT_SUFFIX}&quot;)
  endif()
endif()

if(ROCKSDB_BUILD_SHARED AND NOT WIN32)
  set(ROCKSDB_LIB ${ROCKSDB_SHARED_LIB})
else()
  set(ROCKSDB_LIB ${ROCKSDB_STATIC_LIB})
endif()

option(WITH_JNI &quot;build with JNI&quot; OFF)
# Tests are excluded from Release builds
CMAKE_DEPENDENT_OPTION(WITH_TESTS &quot;build with tests&quot; ON
  &quot;CMAKE_BUILD_TYPE STREQUAL Debug&quot; OFF)
option(WITH_BENCHMARK_TOOLS &quot;build with benchmarks&quot; ON)
option(WITH_CORE_TOOLS &quot;build with ldb and sst_dump&quot; ON)
option(WITH_TOOLS &quot;build with tools&quot; ON)

if(WITH_TESTS OR WITH_BENCHMARK_TOOLS OR WITH_TOOLS OR WITH_JNI OR JNI)
  include_directories(SYSTEM ${PROJECT_SOURCE_DIR}/third-party/gtest-1.8.1/fused-src)
endif()
if(WITH_JNI OR JNI)
  message(STATUS &quot;JNI library is enabled&quot;)
  add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/java)
else()
  message(STATUS &quot;JNI library is disabled&quot;)
endif()

# Installation and packaging
if(WIN32)
  option(ROCKSDB_INSTALL_ON_WINDOWS &quot;Enable install target on Windows&quot; OFF)
endif()
if(NOT WIN32 OR ROCKSDB_INSTALL_ON_WINDOWS)
  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
    if(${CMAKE_SYSTEM_NAME} STREQUAL &quot;Linux&quot;)
      # Change default installation prefix on Linux to /usr
      set(CMAKE_INSTALL_PREFIX /usr CACHE PATH &quot;Install path prefix, prepended onto install directories.&quot; FORCE)
    endif()
  endif()

  include(GNUInstallDirs)
  include(CMakePackageConfigHelpers)

  set(package_config_destination ${CMAKE_INSTALL_LIBDIR}/cmake/rocksdb)

  configure_package_config_file(
    ${CMAKE_CURRENT_LIST_DIR}/cmake/RocksDBConfig.cmake.in RocksDBConfig.cmake
    INSTALL_DESTINATION ${package_config_destination}
  )

  write_basic_package_version_file(
    RocksDBConfigVersion.cmake
    VERSION ${rocksdb_VERSION}
    COMPATIBILITY SameMajorVersion
  )

  install(DIRECTORY include/rocksdb COMPONENT devel DESTINATION &quot;${CMAKE_INSTALL_INCLUDEDIR}&quot;)

  install(DIRECTORY &quot;${PROJECT_SOURCE_DIR}/cmake/modules&quot; COMPONENT devel DESTINATION ${package_config_destination})

  install(
    TARGETS ${ROCKSDB_STATIC_LIB}
    EXPORT RocksDBTargets
    COMPONENT devel
    ARCHIVE DESTINATION &quot;${CMAKE_INSTALL_LIBDIR}&quot;
    INCLUDES DESTINATION &quot;${CMAKE_INSTALL_INCLUDEDIR}&quot;
  )

  if(ROCKSDB_BUILD_SHARED)
    install(
      TARGETS ${ROCKSDB_SHARED_LIB}
      EXPORT RocksDBTargets
      COMPONENT runtime
      ARCHIVE DESTINATION &quot;${CMAKE_INSTALL_LIBDIR}&quot;
      RUNTIME DESTINATION &quot;${CMAKE_INSTALL_BINDIR}&quot;
      LIBRARY DESTINATION &quot;${CMAKE_INSTALL_LIBDIR}&quot;
      INCLUDES DESTINATION &quot;${CMAKE_INSTALL_INCLUDEDIR}&quot;
    )
  endif()

  install(
    EXPORT RocksDBTargets
    COMPONENT devel
    DESTINATION ${package_config_destination}
    NAMESPACE RocksDB::
  )

  install(
    FILES
    ${CMAKE_CURRENT_BINARY_DIR}/RocksDBConfig.cmake
    ${CMAKE_CURRENT_BINARY_DIR}/RocksDBConfigVersion.cmake
    COMPONENT devel
    DESTINATION ${package_config_destination}
  )
endif()

option(WITH_ALL_TESTS &quot;Build all test, rather than a small subset&quot; ON)

if(WITH_TESTS OR WITH_BENCHMARK_TOOLS)
  add_subdirectory(third-party/gtest-1.8.1/fused-src/gtest)
  add_library(testharness STATIC
  test_util/mock_time_env.cc
  test_util/testharness.cc)
  target_link_libraries(testharness gtest)
endif()

if(WITH_TESTS)
  set(TESTS
        db/db_basic_test.cc
        env/env_basic_test.cc
  )
  if(WITH_ALL_TESTS)
    list(APPEND TESTS
        cache/cache_reservation_manager_test.cc
        cache/cache_test.cc
        cache/lru_cache_test.cc
        db/blob/blob_counting_iterator_test.cc
        db/blob/blob_file_addition_test.cc
        db/blob/blob_file_builder_test.cc
        db/blob/blob_file_cache_test.cc
        db/blob/blob_file_garbage_test.cc
        db/blob/blob_file_reader_test.cc
        db/blob/blob_garbage_meter_test.cc
        db/blob/db_blob_basic_test.cc
        db/blob/db_blob_compaction_test.cc
        db/blob/db_blob_corruption_test.cc
        db/blob/db_blob_index_test.cc
        db/column_family_test.cc
        db/compact_files_test.cc
        db/compaction/clipping_iterator_test.cc
        db/compaction/compaction_job_stats_test.cc
        db/compaction/compaction_job_test.cc
        db/compaction/compaction_iterator_test.cc
        db/compaction/compaction_picker_test.cc
        db/compaction/compaction_service_test.cc
        db/comparator_db_test.cc
        db/corruption_test.cc
        db/cuckoo_table_db_test.cc
        db/db_with_timestamp_basic_test.cc
        db/db_block_cache_test.cc
        db/db_bloom_filter_test.cc
        db/db_compaction_filter_test.cc
        db/db_compaction_test.cc
        db/db_dynamic_level_test.cc
        db/db_flush_test.cc
        db/db_inplace_update_test.cc
        db/db_io_failure_test.cc
        db/db_iter_test.cc
        db/db_iter_stress_test.cc
        db/db_iterator_test.cc
        db/db_kv_checksum_test.cc
        db/db_log_iter_test.cc
        db/db_memtable_test.cc
        db/db_merge_operator_test.cc
        db/db_merge_operand_test.cc
        db/db_options_test.cc
        db/db_properties_test.cc
        db/db_range_del_test.cc
        db/db_secondary_test.cc
        db/db_sst_test.cc
        db/db_statistics_test.cc
        db/db_table_properties_test.cc
        db/db_tailing_iter_test.cc
        db/db_test.cc
        db/db_test2.cc
        db/db_logical_block_size_cache_test.cc
        db/db_universal_compaction_test.cc
        db/db_wal_test.cc
        db/db_with_timestamp_compaction_test.cc
        db/db_write_test.cc
        db/dbformat_test.cc
        db/deletefile_test.cc
        db/error_handler_fs_test.cc
        db/obsolete_files_test.cc
        db/external_sst_file_basic_test.cc
        db/external_sst_file_test.cc
        db/fault_injection_test.cc
        db/file_indexer_test.cc
        db/filename_test.cc
        db/flush_job_test.cc
        db/listener_test.cc
        db/log_test.cc
        db/manual_compaction_test.cc
        db/memtable_list_test.cc
        db/merge_helper_test.cc
        db/merge_test.cc
        db/options_file_test.cc
        db/perf_context_test.cc
        db/periodic_work_scheduler_test.cc
        db/plain_table_db_test.cc
        db/prefix_test.cc
        db/range_del_aggregator_test.cc
        db/range_tombstone_fragmenter_test.cc
        db/repair_test.cc
        db/table_properties_collector_test.cc
        db/version_builder_test.cc
        db/version_edit_test.cc
        db/version_set_test.cc
        db/wal_manager_test.cc
        db/wal_edit_test.cc
        db/write_batch_test.cc
        db/write_callback_test.cc
        db/write_controller_test.cc
        env/env_test.cc
        env/io_posix_test.cc
        env/mock_env_test.cc
        file/delete_scheduler_test.cc
        file/prefetch_test.cc
        file/random_access_file_reader_test.cc
        logging/auto_roll_logger_test.cc
        logging/env_logger_test.cc
        logging/event_logger_test.cc
        memory/arena_test.cc
        memory/memory_allocator_test.cc
        memtable/inlineskiplist_test.cc
        memtable/skiplist_test.cc
        memtable/write_buffer_manager_test.cc
        monitoring/histogram_test.cc
        monitoring/iostats_context_test.cc
        monitoring/statistics_test.cc
        monitoring/stats_history_test.cc
        options/configurable_test.cc
        options/customizable_test.cc
        options/options_settable_test.cc
        options/options_test.cc
        table/block_based/block_based_filter_block_test.cc
        table/block_based/block_based_table_reader_test.cc
        table/block_based/block_test.cc
        table/block_based/data_block_hash_index_test.cc
        table/block_based/full_filter_block_test.cc
        table/block_based/partitioned_filter_block_test.cc
        table/cleanable_test.cc
        table/cuckoo/cuckoo_table_builder_test.cc
        table/cuckoo/cuckoo_table_reader_test.cc
        table/merger_test.cc
        table/sst_file_reader_test.cc
        table/table_test.cc
        table/block_fetcher_test.cc
        test_util/testutil_test.cc
        trace_replay/block_cache_tracer_test.cc
        trace_replay/io_tracer_test.cc
        tools/block_cache_analyzer/block_cache_trace_analyzer_test.cc
        tools/io_tracer_parser_test.cc
        tools/ldb_cmd_test.cc
        tools/reduce_levels_test.cc
        tools/sst_dump_test.cc
        tools/trace_analyzer_test.cc
        util/autovector_test.cc
        util/bloom_test.cc
        util/coding_test.cc
        util/crc32c_test.cc
        util/defer_test.cc
        util/dynamic_bloom_test.cc
        util/file_reader_writer_test.cc
        util/filelock_test.cc
        util/hash_test.cc
        util/heap_test.cc
        util/random_test.cc
        util/rate_limiter_test.cc
        util/repeatable_thread_test.cc
        util/ribbon_test.cc
        util/slice_test.cc
        util/slice_transform_test.cc
        util/timer_queue_test.cc
        util/timer_test.cc
        util/thread_list_test.cc
        util/thread_local_test.cc
        util/work_queue_test.cc
        utilities/backupable/backupable_db_test.cc
        utilities/blob_db/blob_db_test.cc
        utilities/cassandra/cassandra_functional_test.cc
        utilities/cassandra/cassandra_format_test.cc
        utilities/cassandra/cassandra_row_merge_test.cc
        utilities/cassandra/cassandra_serialize_test.cc
        utilities/checkpoint/checkpoint_test.cc
        utilities/memory/memory_test.cc
        utilities/merge_operators/string_append/stringappend_test.cc
        utilities/object_registry_test.cc
        utilities/option_change_migration/option_change_migration_test.cc
        utilities/options/options_util_test.cc
        utilities/persistent_cache/hash_table_test.cc
        utilities/persistent_cache/persistent_cache_test.cc
        utilities/simulator_cache/cache_simulator_test.cc
        utilities/simulator_cache/sim_cache_test.cc
        utilities/table_properties_collectors/compact_on_deletion_collector_test.cc
        utilities/transactions/optimistic_transaction_test.cc
        utilities/transactions/transaction_test.cc
        utilities/transactions/lock/point/point_lock_manager_test.cc
        utilities/transactions/write_prepared_transaction_test.cc
        utilities/transactions/write_unprepared_transaction_test.cc
        utilities/transactions/lock/range/range_locking_test.cc
        utilities/ttl/ttl_test.cc
        utilities/write_batch_with_index/write_batch_with_index_test.cc
    )
  endif()

  if(WITH_FOLLY_DISTRIBUTED_MUTEX)
    list(APPEND TESTS third-party/folly/folly/synchronization/test/DistributedMutexTest.cpp)
  endif()

  set(TESTUTIL_SOURCE
      db/db_test_util.cc
      monitoring/thread_status_updater_debug.cc
      table/mock_table.cc
      utilities/cassandra/test_utils.cc
  )
  enable_testing()
  add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND})
  set(TESTUTILLIB testutillib${ARTIFACT_SUFFIX})
  add_library(${TESTUTILLIB} STATIC ${TESTUTIL_SOURCE})
  target_link_libraries(${TESTUTILLIB} ${ROCKSDB_LIB})
  if(MSVC)
    set_target_properties(${TESTUTILLIB} PROPERTIES COMPILE_FLAGS &quot;/Fd${CMAKE_CFG_INTDIR}/testutillib${ARTIFACT_SUFFIX}.pdb&quot;)
  endif()
  set_target_properties(${TESTUTILLIB}
        PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD_RELEASE 1
        EXCLUDE_FROM_DEFAULT_BUILD_MINRELEASE 1
        EXCLUDE_FROM_DEFAULT_BUILD_RELWITHDEBINFO 1
  )

  foreach(sourcefile ${TESTS})
      get_filename_component(exename ${sourcefile} NAME_WE)
      add_executable(${exename}${ARTIFACT_SUFFIX} ${sourcefile})
      set_target_properties(${exename}${ARTIFACT_SUFFIX}
        PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD_RELEASE 1
        EXCLUDE_FROM_DEFAULT_BUILD_MINRELEASE 1
        EXCLUDE_FROM_DEFAULT_BUILD_RELWITHDEBINFO 1
        OUTPUT_NAME ${exename}${ARTIFACT_SUFFIX}
      )
      target_link_libraries(${exename}${ARTIFACT_SUFFIX} testutillib${ARTIFACT_SUFFIX} testharness gtest ${THIRDPARTY_LIBS} ${ROCKSDB_LIB})
      if(NOT &quot;${exename}&quot; MATCHES &quot;db_sanity_test&quot;)
        gtest_discover_tests(${exename} DISCOVERY_TIMEOUT 120)
        add_dependencies(check ${exename}${ARTIFACT_SUFFIX})
      endif()
  endforeach(sourcefile ${TESTS})

  if(WIN32)
    # C executables must link to a shared object
    if(ROCKSDB_BUILD_SHARED)
      set(ROCKSDB_LIB_FOR_C ${ROCKSDB_SHARED_LIB})
    else()
      set(ROCKSDB_LIB_FOR_C OFF)
    endif()
  else()
    set(ROCKSDB_LIB_FOR_C ${ROCKSDB_LIB})
  endif()

  if(ROCKSDB_LIB_FOR_C)
    set(C_TESTS db/c_test.c)
    add_executable(c_test db/c_test.c)
    target_link_libraries(c_test ${ROCKSDB_LIB_FOR_C} testharness)
    add_test(NAME c_test COMMAND c_test${ARTIFACT_SUFFIX})
    add_dependencies(check c_test)
  endif()
endif()

if(WITH_BENCHMARK_TOOLS)
  add_executable(db_bench${ARTIFACT_SUFFIX}
    tools/simulated_hybrid_file_system.cc
    tools/db_bench.cc
    tools/db_bench_tool.cc)
  target_link_libraries(db_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${THIRDPARTY_LIBS})

  add_executable(cache_bench${ARTIFACT_SUFFIX}
    cache/cache_bench.cc
    cache/cache_bench_tool.cc)
  target_link_libraries(cache_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${GFLAGS_LIB})

  add_executable(memtablerep_bench${ARTIFACT_SUFFIX}
    memtable/memtablerep_bench.cc)
  target_link_libraries(memtablerep_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${GFLAGS_LIB})

  add_executable(range_del_aggregator_bench${ARTIFACT_SUFFIX}
    db/range_del_aggregator_bench.cc)
  target_link_libraries(range_del_aggregator_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${GFLAGS_LIB})

  add_executable(table_reader_bench${ARTIFACT_SUFFIX}
    table/table_reader_bench.cc)
  target_link_libraries(table_reader_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} testharness ${GFLAGS_LIB})

  add_executable(filter_bench${ARTIFACT_SUFFIX}
    util/filter_bench.cc)
  target_link_libraries(filter_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${GFLAGS_LIB})

  add_executable(hash_table_bench${ARTIFACT_SUFFIX}
    utilities/persistent_cache/hash_table_bench.cc)
  target_link_libraries(hash_table_bench${ARTIFACT_SUFFIX}
    ${ROCKSDB_LIB} ${GFLAGS_LIB})
endif()

if(WITH_CORE_TOOLS OR WITH_TOOLS)
  add_subdirectory(tools)
  add_custom_target(core_tools
    DEPENDS ${core_tool_deps})
endif()

if(WITH_TOOLS)
  add_subdirectory(db_stress_tool)
  add_custom_target(tools
    DEPENDS ${tool_deps})
endif()

option(WITH_EXAMPLES &quot;build with examples&quot; OFF)
if(WITH_EXAMPLES)
  add_subdirectory(examples)
endif()

option(WITH_BENCHMARK &quot;build benchmark tests&quot; OFF)
if(WITH_BENCHMARK)
  add_subdirectory(${PROJECT_SOURCE_DIR}/microbench/)
endif()
</code></pre>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[Shell]]></title>
        <id>https://blog.shunzi.tech/post/6.NULL-1-shell/</id>
        <link href="https://blog.shunzi.tech/post/6.NULL-1-shell/">
        </link>
        <updated>2021-12-30T08:37:41.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>6.NULL: Shell 扩展介绍</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>6.NULL: Shell 扩展介绍</li>
</ul>
</blockquote>
<!--more-->
<h2 id="gui-vs-cli">GUI vs CLI</h2>
<h3 id="gui">GUI</h3>
<ul>
<li>GUI 连接远程桌面的方式有 VNC，X11 等</li>
</ul>
<h4 id="vnc">VNC</h4>
<ul>
<li>Virtual Network Console 让用户可以远程访问服务器的桌面环境</li>
<li>VNC Server / VNC Client (Viewer)</li>
<li>VNC 是把被控制端的屏幕做成图像，经过压缩后传送到控制端，控制端的控制信息（如鼠标信息）传送到被控制端后进入消息队列。</li>
</ul>
<h5 id="和-ssh-x-的区别">和 ssh -X 的区别</h5>
<ul>
<li>VNC导出整个会话，桌面和所有，而ssh将运行一个程序，并在您的工作站上显示它的窗口。</li>
<li>ssh -X重定向X11命令到您的本地X服务器。所以这就像是你在本地运行程序，而它实际上是在另一端的计算机上运行的。它非常慢，因为它使用了大量的带宽。</li>
<li>VNC和其他远程桌面应用程序则让其他计算机处理所有的图形绘制等等，并捕捉屏幕截图，并将其发送回您的计算机。它看起来要快得多，因为显示所有内容所需的信息要少得多。然而，它也发送整个桌面，而不是单个应用程序。</li>
<li>不推荐在Internet上使用ssh -X，原因很简单:它会占用您所有的可用带宽。在我看来，它在局域网中相当有用，所以如果你只需要一个应用程序，而不想运行整个桌面，这是一个很好的方法。否则，就使用VNC。</li>
</ul>
<h3 id="cli">CLI</h3>
<ul>
<li>Shell
<ul>
<li>zsh - z shell</li>
<li>bash - Bourne Again shell</li>
<li>sh - Thompson shell</li>
<li>fish</li>
</ul>
</li>
<li>zsh（Z shell）是bash的一个替代品，他对于bash有了很多的优化，无论是使用命令，外观，体验，能够让用户更方便顺畅的使用Terminal。</li>
<li>通过使用 oh-my-zsh 扩展，</li>
</ul>
<pre><code class="language-bash">                                    sh   csh  ksh  bash tcsh zsh  rc   es
Job control                          N    Y    Y    Y    Y    Y    N    N
Aliases                              N    Y    Y    Y    Y    Y    N    N
Shell functions                      Y(1) N    Y    Y    N    Y    Y    Y
&quot;Sensible&quot; Input/Output redirection  Y    N    Y    Y    N    Y    Y    Y
Directory stack                      N    Y    Y    Y    Y    Y    F    F
Command history                      N    Y    Y    Y    Y    Y    L    L
Command line editing                 N    N    Y    Y    Y    Y    L    L
Vi Command line editing              N    N    Y    Y    Y(3) Y    L    L
Emacs Command line editing           N    N    Y    Y    Y    Y    L    L
Rebindable Command line editing      N    N    N    Y    Y    Y    L    L
User name look up                    N    Y    Y    Y    Y    Y    L    L
Login/Logout watching                N    N    N    N    Y    Y    F    F
Filename completion                  N    Y(1) Y    Y    Y    Y    L    L
Username completion                  N    Y(2) Y    Y    Y    Y    L    L
Hostname completion                  N    Y(2) Y    Y    Y    Y    L    L
History completion                   N    N    N    Y    Y    Y    L    L
Fully programmable Completion        N    N    N    N    Y    Y    N    N
Mh Mailbox completion                N    N    N    N(4) N(6) N(6) N    N
Co Processes                         N    N    Y    N    N    Y    N    N
Builtin artithmetic evaluation       N    Y    Y    Y    Y    Y    N    N
Can follow symbolic links invisibly  N    N    Y    Y    Y    Y    N    N
Periodic command execution           N    N    N    N    Y    Y    N    N
Custom Prompt (easily)               N    N    Y    Y    Y    Y    Y    Y
Sun Keyboard Hack                    N    N    N    N    N    Y    N    N
Spelling Correction                  N    N    N    N    Y    Y    N    N
Process Substitution                 N    N    N    Y(2) N    Y    Y    Y
Underlying Syntax                    sh   csh  sh   sh   csh  sh   rc   rc
Freely Available                     N    N    N(5) Y    Y    Y    Y    Y
Checks Mailbox                       N    Y    Y    Y    Y    Y    F    F
Tty Sanity Checking                  N    N    N    N    Y    Y    N    N
Can cope with large argument lists   Y    N    Y    Y    Y    Y    Y    Y
Has non-interactive startup file     N    Y    Y(7) Y(7) Y    Y    N    N
Has non-login startup file           N    Y    Y(7) Y    Y    Y    N    N
Can avoid user startup files         N    Y    N    Y    N    Y    Y    Y
Can specify startup file             N    N    Y    Y    N    N    N    N
Low level command redefinition       N    N    N    N    N    N    N    Y
Has anonymous functions              N    N    N    N    N    N    Y    Y
List Variables                       N    Y    Y    N    Y    Y    Y    Y
Full signal trap handling            Y    N    Y    Y    N    Y    Y    Y
File no clobber ability              N    Y    Y    Y    Y    Y    N    F
Local variables                      N    N    Y    Y    N    Y    Y    Y
Lexically scoped variables           N    N    N    N    N    N    N    Y
Exceptions                           N    N    N    N    N    N    N    Y
</code></pre>
<h2 id="shortcuts">shortcuts</h2>
<ul>
<li>https://www.howtogeek.com/howto/ubuntu/keyboard-shortcuts-for-bash-command-shell-for-ubuntu-debian-suse-redhat-linux-etc/</li>
</ul>
<h3 id="最常用">最常用</h3>
<ul>
<li>Ctrl-R 搜索运行的历史命令</li>
<li>Ctrl-C - SIGINT</li>
<li>Tab</li>
<li><strong>Ctrl-Z</strong> 暂停当前运行的任务，使用 fg 或者 bg 恢复 - SIGTSTP</li>
<li>Ctrl-D 关闭bash shell。这将向bash发送一个EOF(文件结束符)标记，bash在收到这个标记时退出。这类似于运行exit命令。</li>
<li>Ctrl+L: Clear the screen.</li>
<li>Ctrl+S: 停止所有输出到屏幕。当运行的命令输出很长、很冗长，但您不想用Ctrl+C停止命令本身时，这一点特别有用。</li>
<li>Ctrl+Q：用Ctrl+S停止屏幕输出后，恢复屏幕输出。</li>
</ul>
<h3 id="其他">其他</h3>
<h4 id="moving-the-cursor">Moving the Cursor</h4>
<ul>
<li>Ctrl+A or Home: Go to the beginning of the line.</li>
<li>Ctrl+E or End: Go to the end of the line.</li>
<li>Alt+B: Go left (back) one word.</li>
<li>Ctrl+B: Go left (back) one character.</li>
<li>Alt+F: Go right (forward) one word.</li>
<li>Ctrl+F: Go right (forward) one character.</li>
<li>Ctrl+XX: Move between the beginning of the line and the current position of the cursor. This allows you to press Ctrl+XX to return to the start of the line, change something, and then press Ctrl+XX to go back to your original cursor position. To use this shortcut, hold the Ctrl key and tap the X key twice.</li>
</ul>
<h4 id="deleting-text">Deleting Text</h4>
<ul>
<li>Ctrl+D or Delete: Delete the character under the cursor.</li>
<li>Alt+D: Delete all characters after the cursor on the current line.</li>
<li>Ctrl+H or Backspace: Delete the character before the cursor.</li>
</ul>
<h4 id="fixing-typos">Fixing Typos</h4>
<ul>
<li>Alt+T: Swap the current word with the previous word.</li>
<li>Ctrl+T: Swap the last two characters before the cursor with each other. You can use this to quickly fix typos when you type two characters in the wrong order.</li>
<li>Ctrl+_: Undo your last key press. You can repeat this to undo multiple times.</li>
</ul>
<h4 id="cutting-and-pasting">Cutting and Pasting</h4>
<ul>
<li>Ctrl+W: Cut the word before the cursor, adding it to the clipboard.</li>
<li>Ctrl+K: Cut the part of the line after the cursor, adding it to the clipboard.</li>
<li>Ctrl+U: Cut the part of the line before the cursor, adding it to the clipboard.</li>
<li>Ctrl+Y: Paste the last thing you cut from the clipboard. The y here stands for “yank”.</li>
</ul>
<h4 id="capitalizing-characters">Capitalizing Characters</h4>
<ul>
<li>Alt+U: Capitalize every character from the cursor to the end of the current word, converting the characters to upper case.</li>
<li>Alt+L: Uncapitalize every character from the cursor to the end of the current word, converting the characters to lower case.</li>
<li>Alt+C: Capitalize the character under the cursor. Your cursor will move to the end of the current word.</li>
</ul>
<h4 id="working-with-your-command-history">Working With Your Command History</h4>
<ul>
<li>Ctrl+P or Up Arrow: Go to the previous command in the command history. Press the shortcut multiple times to walk back through the history.</li>
<li>Ctrl+N or Down Arrow: Go to the next command in the command history. Press the shortcut multiple times to walk forward through the history.</li>
<li>Alt+R: Revert any changes to a command you’ve pulled from your history if you’ve edited it.</li>
<li>Ctrl+R: Recall the last command matching the characters you provide. Press this shortcut and start typing to search your bash history for a command.</li>
<li>Ctrl+O: Run a command you found with Ctrl+R.</li>
<li>Ctrl+G: Leave history searching mode without running a command.</li>
</ul>
<h2 id="install-software-in-cli">Install Software in CLI</h2>
<h3 id="pacakge-manager">Pacakge Manager</h3>
<ul>
<li>apt, dpkg (ubuntu, Debian) - .deb</li>
<li>brew (macOS)</li>
<li>dnf (fedora) - .rpm</li>
<li>yum (centos) - .rpm</li>
</ul>
<h3 id="install-from-source">Install from source</h3>
<ul>
<li>README/INSTALL doc</li>
<li>configure / make install</li>
</ul>
<h2 id="pipe-and-redirect">Pipe and Redirect</h2>
<ul>
<li>I/O 重定向：
<ul>
<li>&lt; file 重定向 file 到 输入</li>
<li>&gt; file 重定向输出流到文件</li>
<li>&gt;&gt; file 追加写到文件</li>
<li>| 管道重定向，链接输出和输入</li>
</ul>
</li>
<li>使用重定向过程中需要注意权限问题：</li>
</ul>
<pre><code class="language-bash">$ sudo find -L /sys/class/backlight -maxdepth 2 -name '*brightness*'
/sys/class/backlight/thinkpad_screen/brightness
$ cd /sys/class/backlight/thinkpad_screen
$ sudo echo 3 &gt; brightness
An error occurred while redirecting file 'brightness'
open: Permission denied
</code></pre>
<ul>
<li>echo 等程序并不知道 | 的存在，它们只知道从自己的输入输出流中进行读写。 对于上面这种情况， shell (权限为您的当前用户) 在设置 sudo echo 前尝试打开 brightness 文件并写入，但是系统拒绝了 shell 的操作因为此时 shell 不是根用户。所以修改为：</li>
</ul>
<pre><code class="language-shell">$ echo 3 | sudo tee brightness
</code></pre>
<ul>
<li>因为打开 /sys 文件的是 tee 这个程序，并且该程序以 root 权限在运行，因此操作可以进行。 这样您就可以在 /sys 中愉快地玩耍了，例如修改系统中各种LED的状态（路径可能会有所不同）：</li>
</ul>
<pre><code>$ echo 1 | sudo tee /sys/class/leds/input6::scrolllock/brightness
</code></pre>
<h3 id="redirect-注意">Redirect 注意</h3>
<ul>
<li>一般情况下，每个 Unix/Linux 命令运行时都会打开三个文件：
<ul>
<li>标准输入文件(stdin)：stdin的文件描述符为0，Unix程序默认从stdin读取数据。</li>
<li>标准输出文件(stdout)：stdout 的文件描述符为1，Unix程序默认向stdout输出数据。</li>
<li>标准错误文件(stderr)：stderr的文件描述符为2，Unix程序会向stderr流中写入错误信息。</li>
</ul>
</li>
<li><strong>默认情况下</strong>，command &gt; file 将 stdout 重定向到 file，command &lt; file 将stdin 重定向到 file。</li>
<li>如果希望 stderr 重定向到 file，可以这样写：
<ul>
<li><code>$ command 2&gt;file</code></li>
</ul>
</li>
<li>如果希望将 stdout 和 stderr 合并后重定向到 file，可以这样写：
<ul>
<li><code>$ command &gt; file 2&gt;&amp;1</code></li>
</ul>
</li>
<li>如果希望执行某个命令，但又不希望在屏幕上显示输出结果，那么可以将输出重定向到 /dev/null：
<ul>
<li><code>$ command &gt; /dev/null</code></li>
</ul>
</li>
</ul>
<h3 id="pipe">Pipe</h3>
<ul>
<li>管道是UNIX环境中历史最悠久的进程间通信方式。</li>
<li>管道本质上就是一个文件，前面的进程以写方式打开文件，后面的进程以读方式打开。这样前面写完后面读，于是就实现了通信。实际上管道的设计也是遵循UNIX的“一切皆文件”设计原则的，它本质上就是一个文件。</li>
<li>Linux系统直接把管道实现成了一种文件系统，借助VFS给应用程序提供操作接口。</li>
<li>虽然实现形态上是文件，但是管道本身并不占用磁盘或者其他外部存储的空间。在Linux的实现上，它占用的是内存空间。所以，Linux上的管道就是一个操作方式为文件的内存缓冲区。</li>
<li>管道一般又分为匿名管道和命名管道
<ul>
<li>匿名管道最常见的形态就是我们在shell操作中最常用的”|”。它的特点是只能在父子进程中使用，父进程在产生子进程前必须打开一个管道文件，然后fork产生子进程，这样子进程通过拷贝父进程的进程地址空间获得同一个管道文件的描述符，以达到使用同一个管道通信的目的。此时除了父子进程外，没人知道这个管道文件的描述符，所以通过这个管道中的信息无法传递给其他进程。这保证了传输数据的安全性，当然也降低了管道了通用性</li>
<li>于是系统还提供了命名管道。以使用 <code>mkfifo</code> 或 <code>mknod</code> 命令来创建一个命名管道。创建出来的文件类型比较特殊，是p类型。表示这是一个管道文件。有了这个管道文件，系统中就有了对一个管道的全局名称，于是任何两个不相关的进程都可以通过这个管道文件进行通信</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">[root@iZ8vb09drusrfas7dkou1tZ ~]# mkfifo pipe
[root@iZ8vb09drusrfas7dkou1tZ ~]# ls -l
total 8
drwxr-xr-x 8 root root 4096 Dec  8 17:58 oneinstack
prw-r--r-- 1 root root    0 Feb  8 16:12 pipe
-rw-r--r-- 1 root root  475 Dec  8 17:58 ReadMe
[root@iZ8vb09drusrfas7dkou1tZ ~]# ls -l pipe
prw-r--r-- 1 root root 0 Feb  8 16:12 pipe
[root@iZ8vb09drusrfas7dkou1tZ ~]# echo xxxx &gt; pipe

</code></pre>
<ul>
<li>此时写进程 echo 被阻塞，因为管道另一端没有人读。这是内核对管道文件定义的默认行为。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220208161259.png" alt="20220208161259" loading="lazy"></li>
<li>此时如果有进程读这个管道，那么这个写操作的阻塞才会解除。当我们cat完这个文件之后，另一端的echo命令也返回了。这就是命名管道。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220208161437.png" alt="20220208161437" loading="lazy"></li>
<li>Linux系统无论对于命名管道和匿名管道，底层都用的是同一种文件系统的操作行为，这种文件系统叫pipefs</li>
</ul>
<h4 id="编程创建管道">编程创建管道</h4>
<ul>
<li>把匿名管道和命名管道分别叫做PIPE和FIFO。这主要因为在系统编程中，创建匿名管道的系统调用是 <code>pipe()</code>，而创建命名管道的函数是 <code>mkfifo()</code>。使用 <code>mknod()</code> 系统调用并指定文件类型为为 <code>S_IFIFO</code> 也可以创建一个FIFO。</li>
<li>方法将会创建出两个文件描述符，可以使用pipefd这个数组来引用这两个描述符进行文件操作。pipefd[0]是读方式打开，作为管道的读描述符。pipefd[1]是写方式打开，作为管道的写描述符。从管道写端写入的数据会被内核缓存直到有人从另一端读取为止。我</li>
</ul>
<pre><code class="language-C">#include &lt;unistd.h&gt;
​
int pipe(int pipefd[2]);
</code></pre>
<ul>
<li>命名管道在底层的实现跟匿名管道完全一致，区别只是命名管道会有一个全局可见的文件名以供别人open打开使用。再程序中创建一个命名管道文件的方法有两种，一种是使用mkfifo函数。另一种是使用mknod系统调用</li>
</ul>
<pre><code class="language-C">#include &lt;sys/types.h&gt;
#include &lt;sys/stat.h&gt;
int mkfifo(const char *filename, mode_t mode);
int mknod(const char *filename, mode_t mode | S_IFIFO, (dev_t)0);
</code></pre>
<h5 id="参考链接">参考链接</h5>
<ul>
<li>https://www.cnblogs.com/52php/p/5840229.html</li>
<li>https://zhuanlan.zhihu.com/p/58489873</li>
</ul>
<h2 id="基础命令">基础命令</h2>
<ul>
<li>https://www.geeksforgeeks.org/basic-shell-commands-in-linux/</li>
<li>https://swcarpentry.github.io/shell-novice/reference.html</li>
<li>https://tldr.sh/</li>
<li>https://command-not-found.com/</li>
</ul>
<h3 id="示例">示例</h3>
<ul>
<li>cat/more/less/head/tail
<ul>
<li>more 读取了整个文件，less 按页读取</li>
</ul>
</li>
<li>mkdir/cp/mv/rm/touch</li>
<li>grep/sort/wc/cut</li>
<li>ls/cd/du/pwd/man/rmdir/ln/locate/echo/df/tar</li>
<li>chown/chgrp/chmod</li>
</ul>
<h3 id="ag">ag</h3>
<ul>
<li>https://command-not-found.com/ag<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220208164210.png" alt="20220208164210" loading="lazy"></li>
<li>比 grep find 更强大，更多用于查找关键字</li>
</ul>
<h3 id="awk">awk</h3>
<ul>
<li>主要用于结果处理，可以编程实现自定义功能</li>
<li>默认有触发时机，默认每行触发一次</li>
</ul>
<h3 id="sed">sed</h3>
<ul>
<li>主要用于对文字流式进行格式化处理</li>
</ul>
<h3 id="具体脚本示例">具体脚本示例</h3>
<h4 id="计算平均吞吐量">计算平均吞吐量</h4>
<ul>
<li>step1. 构造对应的吞吐量数据</li>
</ul>
<pre><code class="language-bash">root@aep-shunzi:~/tut_0# cat run_exp.sh 
echo &quot;Dummy Experiement Output&quot;
echo &quot;Throughput $RANDOM ops/s&quot;
root@aep-shunzi:~/tut_0# ./run_exp.sh 
Dummy Experiement Output
Throughput 18447 ops/s
root@aep-shunzi:~/tut_0# ./run_exp.sh 
Dummy Experiement Output
Throughput 18224 ops/s
</code></pre>
<ul>
<li>step2. 计算平均吞吐</li>
</ul>
<pre><code class="language-bash">root@aep-shunzi:~/tut_0# cat run_dummy.sh 
# 输入试验次数作为参数
exp_times=$1
# 输入最终的输出文件作为参数
result_file=$2
# 清空输出文件
echo &quot;&quot; &gt; $result_file

# 循环执行
for i in `seq 1 $exp_times`
do
  # 执行吞吐量统计
  # sed 取对应的第二行
  # awk 输出对应的第二列值，即吞吐量对应的数值
  # 重定向到输出文件
	bash ./run_exp.sh | sed -n '2 p' | awk '{print $2}' &gt;&gt; $result_file
done 

# 执行求平均值的函数
awk 'BEGIN{cnt=0} {sum+=$1;cnt++;} END {print sum/cnt}' $result_file

root@aep-shunzi:~/tut_0# ls
run_dummy.sh  run_exp.sh  test.txt
root@aep-shunzi:~/tut_0# ./run_dummy.sh 100 avg-thr.txt
16249.1

</code></pre>
<h4 id="统计尾延迟的分布">统计尾延迟的分布</h4>
<ul>
<li>step1. 构造对应的延迟记录文件 req_time</li>
</ul>
<pre><code class="language-bash">[root@iZ8vb09drusrfas7dkou1tZ ~]# cat rand_req.sh 
# 随机生成延迟
echo &quot;$RANDOM us&quot;
[root@iZ8vb09drusrfas7dkou1tZ ~]# cat run_req.sh 
# 循环执行 10001 次
for i in `seq 0 10000`
do
	bash ./rand_req.sh
done
[root@iZ8vb09drusrfas7dkou1tZ ~]# cat run_exp.sh 
# 重定向到 req_time 文件
bash ./run_req.sh &gt; req_time
</code></pre>
<ul>
<li>step2. 分析对应的延迟</li>
</ul>
<pre><code class="language-bash"># 接受输入参数作为读取的文件
resultfile=$1

# 按照数字进行排序得到对应排序后的文件

sort -g $resultfile &gt; $resultfile-sort

# 统计 总共的行数
# 提取 wordcount 的输出的第一列 得到行数
lineno=`wc -l $resultfile | awk '{print $1}'`
echo $lineno

# 计算 P99 所在的位置
p99line=$[lineno * 99 / 100]
# 输出 P99 所在的行答应对应的延迟
p99lat=`sed -n &quot;$p99line p &quot; $resultfile-sort`
echo $p99lat

# 统计 CDF 计算概率密度分布
# 读取对应的排序后的延迟文件，从第一行开始，间隔一行取样
# 输出对应的行号所对应的比例值 和 对应的延迟
# 重定向到新的文件中
awk -v total=&quot;$lineno&quot; 'BEGIN{line=0} {line++;if(line%2 == 0) print (line/total&quot; &quot;$1)}' $resultfile-sort &gt; $resultfile-cdf
</code></pre>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[6.NULL: The Missing Semester of Your CS Education]]></title>
        <id>https://blog.shunzi.tech/post/6.NULL/</id>
        <link href="https://blog.shunzi.tech/post/6.NULL/">
        </link>
        <updated>2021-12-28T08:37:41.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>6.NULL: The Missing Semester of Your CS Education 原课程总结</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>6.NULL: The Missing Semester of Your CS Education 原课程总结</li>
</ul>
</blockquote>
<!--more-->
<h2 id="参考资料">参考资料</h2>
<ul>
<li><a href="https://zhuanlan.zhihu.com/p/139361685">知乎 - 胡津铭 - 6.NULL：恨不相逢“未嫁时”</a>: 介绍 6.NULL</li>
<li><a href="https://missing.csail.mit.edu/">MIT：The Missing Semester of Your CS Education</a></li>
<li><a href="https://ipads.se.sjtu.edu.cn/zh/slides/tutorial-2021/Tutorial01_Shell.pdf">IPADS - Nian Liu - Shell Tutorial</a>
<ul>
<li><a href="https://www.bilibili.com/video/BV1y44y1v7c3?spm_id_from=333.999.0.0">B站：IPADS新人培训第一讲：Shell</a></li>
</ul>
</li>
</ul>
<h2 id="shell">Shell</h2>
<ul>
<li>GUI vs Shell</li>
<li>Shell
<ul>
<li>Bourne Again SHell (Bash)</li>
</ul>
</li>
</ul>
<h3 id="basic">basic</h3>
<ul>
<li>几个简单的命令：<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220204105112.png" alt="20220204105112" loading="lazy"></li>
<li>文件导航：Windows 和 unix-like system 之间存在一定的区别
<ul>
<li>\ 和 /</li>
<li>root_directory</li>
<li>/sys</li>
</ul>
</li>
<li>cd/cp/mv/rm/mkdir/ls</li>
<li>I/O 重定向：
<ul>
<li>&lt; file 重定向输入到 file</li>
<li>&gt; file 重定向输出流到文件</li>
<li>&gt;&gt; file 追加写到文件</li>
<li>| 管道重定向，链接输出和输入</li>
</ul>
</li>
<li>使用重定向过程中需要注意权限问题：</li>
</ul>
<pre><code class="language-bash">$ sudo find -L /sys/class/backlight -maxdepth 2 -name '*brightness*'
/sys/class/backlight/thinkpad_screen/brightness
$ cd /sys/class/backlight/thinkpad_screen
$ sudo echo 3 &gt; brightness
An error occurred while redirecting file 'brightness'
open: Permission denied
</code></pre>
<ul>
<li>echo 等程序并不知道 | 的存在，它们只知道从自己的输入输出流中进行读写。 对于上面这种情况， shell (权限为您的当前用户) 在设置 sudo echo 前尝试打开 brightness 文件并写入，但是系统拒绝了 shell 的操作因为此时 shell 不是根用户。所以修改为：</li>
</ul>
<pre><code class="language-shell">$ echo 3 | sudo tee brightness
</code></pre>
<ul>
<li>因为打开 /sys 文件的是 tee 这个程序，并且该程序以 root 权限在运行，因此操作可以进行。 这样您就可以在 /sys 中愉快地玩耍了，例如修改系统中各种LED的状态（路径可能会有所不同）：</li>
</ul>
<pre><code>$ echo 1 | sudo tee /sys/class/leds/input6::scrolllock/brightness
</code></pre>
<h3 id="scripts">scripts</h3>
<ul>
<li>shell 中几个特殊的符号
<ul>
<li>注释 #</li>
<li>分号：使用分号把多条命令放到一行</li>
<li>双分号：case 的分隔</li>
<li>空格：空格会分割参数</li>
<li>点 .
<ul>
<li>作为文件名的一部分时不会显示，隐藏文件的前缀</li>
<li>当前目录 .</li>
<li>上一级目录 ..</li>
<li>正则表达式匹配单个字符 .</li>
</ul>
</li>
<li>引号
<ul>
<li>' '：以'定义的字符串为原义字符串，其中的变量不会被转义</li>
<li>&quot; &quot;：定义的字符串会将变量值进行替换</li>
</ul>
</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">foo=bar
echo &quot;$foo&quot;
# 打印 bar
echo '$foo'
# 打印 $foo
</code></pre>
<ul>
<li>关键字
<ul>
<li>if</li>
<li>case</li>
<li>while</li>
<li>for</li>
</ul>
</li>
<li>函数和参数表
<ul>
<li>可以定义函数</li>
<li>参数表
<ul>
<li>$0 - 脚本名</li>
<li>$1 - $9 脚本的参数 第一个到第九个</li>
<li>$@ - 所有参数</li>
<li>$# - 参数个数</li>
<li>$? - 前一个命令的返回值</li>
<li>$$ - 当前脚本的进程识别码</li>
<li>!! - 完整的上一条命令，包括参数，常见用法，当你因为权限不足执行命令失败时，可以使用 sudo !!再尝试一次。</li>
<li>$_ - 上一条命令的最后一个参数，如果正在使用交互式 shell，按下 Esc 之后键入 . 来获取这个值</li>
</ul>
</li>
<li>其他操作
<ul>
<li>$(CMD) 这样的方式来执行CMD 这个命令时，它的输出结果会替换掉 $( CMD )
<ul>
<li><code>for file in $(ls)</code> l首先将调用ls ，然后遍历得到的这些返回值</li>
</ul>
</li>
<li>&lt;( CMD ) 会执行 CMD 并将结果输出到一个临时文件中，并将 &lt;( CMD ) 替换成临时文件名。这在我们希望返回值通过文件而不是STDIN传递时很有用
<ul>
<li><code>diff &lt;(ls foo) &lt;(ls bar)</code>  会显示文件夹 foo 和 bar 中文件的区别</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>标准输入输出
<ul>
<li>stdout</li>
<li>stdin</li>
<li>stderr</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">#!/bin/bash

echo &quot;Starting program at $(date)&quot; # date会被替换成日期和时间

echo &quot;Running program $0 with $# arguments with pid $$&quot;

# 遍历参数列表
for file in &quot;$@&quot;; do
    grep foobar &quot;$file&quot; &gt; /dev/null 2&gt; /dev/null
    # 如果模式没有找到，则grep退出状态为 1
    # 我们将标准输出流和标准错误流重定向到Null，因为我们并不关心这些信息
    
    # 前面的 grep 命令没有找到 foobar 的时候，追加一个 foorbar
    if [[ $? -ne 0 ]]; then
        echo &quot;File $file does not have any foobar, adding one&quot;
        echo &quot;# foobar&quot; &gt;&gt; &quot;$file&quot;
    fi
done

</code></pre>
<ul>
<li>一些规范和简便写法：
<ul>
<li>在bash中进行比较时，尽量使用双方括号 [[ ]] 而不是单方括号 [ ]</li>
<li>通配符：* 和 ?
<ul>
<li>foo* 匹配以 foo 开头的所有字符串</li>
<li>foo? 匹配以 foo+x 的字符串，如 foo1, foo2</li>
</ul>
</li>
<li>花括号：{} 自动展开 命令，类似于循环的概念
<ul>
<li><code>cp /path/to/project/{foo,bar,baz}.sh /newpath</code></li>
<li><code>mv *{.py,.sh} folder</code></li>
<li><code>touch {foo,bar}/{a..h}</code></li>
</ul>
</li>
<li>shell 错误检查工具 <code>ShellCheck</code></li>
<li>命令用法查询
<ul>
<li>man</li>
<li><a href="https://tldr.sh/">tldr</a></li>
</ul>
</li>
</ul>
</li>
<li>find 查找文件/操作文件</li>
</ul>
<pre><code class="language-bash"># 查找文件
# 查找所有名称为src的文件夹
find . -name src -type d
# 查找所有名称为src的文件夹，不区分大小写
find . -name src -iname -type d
# 查找所有文件夹路径中包含test的python文件
find . -path '*/test/*.py' -type f
# 查找前一天修改的所有文件
find . -mtime -1
# 查找所有大小在500k至10M的tar.gz文件
find . -size +500k -size -10M -name '*.tar.gz'

# 操作文件
# 删除全部扩展名为.tmp 的文件
find . -name '*.tmp' -exec rm {} \;
# 查找全部的 PNG 文件并将其转换为 JPG
find . -name '*.png' -exec convert {} {}.jpg \;
</code></pre>
<ul>
<li>其他文件查找工具
<ul>
<li>fd: https://github.com/sharkdp/fd</li>
<li>locate: 可以再执行命令之前执行 updatedb 来更新数据库</li>
</ul>
</li>
</ul>
<pre><code class="language-bash"># 查找和pwd相关的所有文件
locate pwd
# 搜索etc目录下所有以sh开头的文件
locate /etc/sh
# 搜索etc目录下，所有以i开头的文件
locate /etc/i
# 指定显示数量，限定结果个数
locate -n 3 passwd
# 查找不需要区分大小写时，使用 -i 选项
locate -i -n 5 passwd
# 正则表达式匹配
locate -r ^/var/lib/rpm
# 查看数据库统计信息
locate -S
# 查看passwd统计数量
locate -c passwd
# update相关配置文件
vim /etc/updatedb.conf 
</code></pre>
<ul>
<li>代码/文本查找 grep, ack, ag, rg</li>
</ul>
<pre><code class="language-bash"># 查找所有使用了 requests 库的文件
rg -t py 'import requests'
# 查找所有没有写 shebang 的文件（包含隐藏文件）
rg -u --files-without-match &quot;^#!&quot;
# 查找所有的foo字符串，并打印其之后的5行
rg foo -A 5
# 打印匹配的统计信息（匹配的行和文件的数量）
rg --stats PATTERN
</code></pre>
<ul>
<li>命令查找
<ul>
<li>history</li>
<li>Ctrl+R</li>
<li>fzf</li>
</ul>
</li>
<li>文件夹导航
<ul>
<li>fasd，autojump</li>
<li>tree</li>
<li>broot</li>
<li>nnn</li>
<li>ranger、</li>
</ul>
</li>
<li><a href="https://missing-semester-cn.github.io/missing-notes-and-solutions/2020/solutions/shell-tools-solution/">习题解答</a>
<ul>
<li><code>ls -ahtl --color=auto</code>
<ul>
<li><code>-a</code> 所有文件包括隐藏文件</li>
<li><code>-h</code> 文件打印以人类可以理解的格式输出 (例如，使用454M 而不是 454279954)</li>
<li><code>-t</code> 文件以最近访问顺序排序</li>
<li><code>--color=auto</code> 以彩色文本显示输出结果</li>
</ul>
</li>
<li><code>find . -type f -name &quot;*.html&quot; | xargs -d '\n'  tar -cvzf html.zip</code> # 查找 .html 文件并打包成 zip
<ul>
<li><code>xargs</code> 使用标准输入中的内容作为参数，主要用于 不接受标准输入作为参数的命令
<ul>
<li><code>-d</code> 更改分隔符来分解标准输入，默认分隔符为空格。</li>
</ul>
</li>
<li><code>tar</code> 打包
<ul>
<li>cvzf
<ul>
<li>c 建立压缩</li>
<li>v 显示所有过程</li>
<li>z 有 gzip 属性</li>
<li>f 使用后面跟随的 zip 名</li>
</ul>
</li>
<li>zxvf
<ul>
<li>x 解压</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><code>find . -type f -mmin -60 -print0 | xargs -0 ls -lt | head -10</code> # 递归的查找文件夹中最近使用的文件
<ul>
<li><code>-mmin</code> 60
<ul>
<li>文件的数据最后一次修改是在60分钟前</li>
</ul>
</li>
<li>find 后的 <code>print</code> 和 <code>print0</code>
<ul>
<li><code>-print</code> 在每一个输出后会添加一个回车换行符</li>
<li><code>-print0</code> 则不会</li>
</ul>
</li>
<li><code>-xarg 0</code> xargs 也用 NULL 字符来作为记录的分隔符</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="vim">Vim</h2>
<h3 id="basic-2">Basic</h3>
<ul>
<li>多种操作模式
<ul>
<li>正常模式：在文件中四处移动光标进行修改 （默认）</li>
<li>插入模式：插入文本 <code>i</code></li>
<li>替换模式：替换文本 <code>R</code></li>
<li>可视化（一般，行，块）模式：选中文本块 <code>v</code> 一般 <code>V</code> 行 <code>Ctrl-V</code> 块</li>
<li>命令模式：用于执行命令 <code>:</code></li>
</ul>
</li>
<li>基本概念
<ul>
<li>Vim 会维护一系列打开的文件，称为“<strong>缓存</strong>”</li>
<li>一个 Vim 会话包含一系列<strong>标签页</strong>，每个标签页包含 一系列<strong>窗口</strong>（分隔面板）每个窗口显示一个缓存</li>
<li>缓存和窗口不是一一对应的关系；窗口只是视角。一个缓存可以在_多个_窗口打开，甚至在同一 个标签页内的多个窗口打开。这个功能其实很好用，比如在查看同一个文件的不同部分的时候。</li>
<li>Vim 默认打开一个标签页，这个标签也包含一个窗口。</li>
</ul>
</li>
<li>基本命令：（命令模式下 :）
<ul>
<li>q</li>
<li>w</li>
<li>wq</li>
<li>e {文件名} 打开要编辑的文件</li>
<li>ls 显示打开的缓存</li>
<li>help {标题} 打开帮助文档
<ul>
<li>:help :w 打开 :w 命令的帮助文档</li>
<li>:help w 打开 w 移动的帮助文档</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4 id="操作">操作</h4>
<ul>
<li>
<p>移动 (正常模式下)</p>
<ul>
<li>基本移动：<code>hjkl</code> （左， 下， 上， 右）</li>
<li>词：<code>w</code> （下一个词）， <code>b</code> （词初）， <code>e</code>（词尾）</li>
<li>行：<code>0</code> （行初）， <code>^</code> （第一个非空格字符）， <code>$</code> （行尾）</li>
<li>屏幕： <code>H</code> （屏幕首行）， <code>M</code> （屏幕中间）， <code>L</code> （屏幕底部）</li>
<li>翻页： <code>Ctrl-u</code> （上翻）， <code>Ctrl-d</code> （下翻）</li>
<li>文件： <code>gg</code>（文件头）， <code>G</code> （文件尾）</li>
<li>行数： <code>:{行数}&lt;CR&gt;</code> 或者 <code>{行数}G</code> ({行数}为行数)</li>
<li>杂项： <code>%</code> （找到配对，比如括号或者 /* */ 之类的注释对）</li>
<li>查找： <code>f{字符}</code>， <code>t{字符}</code>， <code>F{字符}</code>， <code>T{字符}</code>
<ul>
<li>查找/到 向前/向后 在本行的{字符}</li>
<li><code>,</code> / <code>;</code> 用于导航匹配</li>
</ul>
</li>
<li>搜索: <code>/{正则表达式}</code>, <code>n</code> / <code>N</code> 用于导航匹配</li>
</ul>
</li>
<li>
<p>编辑</p>
<ul>
<li><code>i</code> 进入插入模式</li>
<li><code>O</code> / <code>o</code> 在之上/之下插入行</li>
<li><code>d{移动命令}</code> 删除 {移动命令}
<ul>
<li><code>dw</code> 删除词</li>
<li><code>d$</code> 删除到行尾</li>
<li><code>d0</code> 删除到行头</li>
</ul>
</li>
<li><code>c{移动命令}</code> 改变 {移动命令}
<ul>
<li>例如， <code>cw</code> 改变词</li>
</ul>
</li>
<li><code>x</code> 删除字符（等同于 <code>dl</code>）</li>
<li><code>s</code> 替换字符（等同于 <code>xi</code>）</li>
<li>可视化模式 <code>+</code> 操作
<ul>
<li>选中文字, <code>d</code> 删除 或者 <code>c</code> 改变</li>
</ul>
</li>
<li><code>u</code> 撤销, <code>&lt;C-r&gt;</code> 重做</li>
<li><code>y</code> 复制 / “yank” （其他一些命令比如 d 也会复制）</li>
<li><code>p</code> 粘贴</li>
</ul>
</li>
<li>
<p>计数：你可以用一个计数来结合“名词”和“动词”，这会执行指定操作若干次。</p>
<ul>
<li>3w 向前移动三个词</li>
<li>5j 向下移动5行</li>
<li>7dw 删除7个词</li>
</ul>
</li>
<li>
<p>修饰语：你可以用修饰语改变“名词”的意义。修饰语有 i，表示“内部”或者“在内“，和 a， 表示”周围“。</p>
<ul>
<li><code>ci(</code> 改变当前括号内的内容</li>
<li><code>ci[</code> 改变当前方括号内的内容</li>
<li><code>da'</code> 删除一个单引号字符串， 包括周围的单引号</li>
</ul>
</li>
</ul>
<h4 id="自定义-vim">自定义 Vim</h4>
<ul>
<li>Vim 由一个位于 ~/.vimrc 的文本配置文件（包含 Vim 脚本命令）。 你可能会启用很多基本 设置。</li>
</ul>
<pre><code>&quot; Comments in Vimscript start with a `&quot;`.

&quot; If you open this file in Vim, it'll be syntax highlighted for you.

&quot; Vim is based on Vi. Setting `nocompatible` switches from the default
&quot; Vi-compatibility mode and enables useful Vim functionality. This
&quot; configuration option turns out not to be necessary for the file named
&quot; '~/.vimrc', because Vim automatically enters nocompatible mode if that file
&quot; is present. But we're including it here just in case this config file is
&quot; loaded some other way (e.g. saved as `foo`, and then Vim started with
&quot; `vim -u foo`).&quot;
&quot; Vim基于Vi。设置' nocompatible '从默认的Vi兼容模式切换，并启用有用的Vim功能.
set nocompatible

&quot; 语法高亮&quot;
&quot; Turn on syntax highlighting.
syntax on

&quot; 禁用默认的Vim启动消息&quot;
&quot; Disable the default Vim startup message.
set shortmess+=I

&quot; Show line numbers.
set number

&quot; 这使得可以使用相对行编号模式。 启用number和relativenumber后，当前行显示真实的行号，而所有其他行(上面和下面)都相对于当前行编号。 这是很有用的，因为你可以通过{count}k向上或{count}j向下，一眼就能知道向上或向下跳转到特定行需要哪些计数。  &quot;
&quot; This enables relative line numbering mode. With both number and
&quot; relativenumber enabled, the current line shows the true line number, while
&quot; all other lines (above and below) are numbered relative to the current line.
&quot; This is useful because you can tell, at a glance, what count is needed to
&quot; jump up or down to a particular line, by {count}k to go up or {count}j to go
&quot; down.
set relativenumber

&quot; 总是在底部显示状态行，即使你只有一个窗口打开&quot;
&quot; Always show the status line at the bottom, even if you only have one window open.
set laststatus=2

&quot; The backspace key has slightly unintuitive behavior by default. For example,
&quot; by default, you can't backspace before the insertion point set with 'i'.
&quot; This configuration makes backspace behave more reasonably, in that you can
&quot; backspace over anything.
set backspace=indent,eol,start

&quot; By default, Vim doesn't let you hide a buffer (i.e. have a buffer that isn't
&quot; shown in any window) that has unsaved changes. This is to prevent you from &quot;
&quot; forgetting about unsaved changes and then quitting e.g. via `:qa!`. We find
&quot; hidden buffers helpful enough to disable this protection. See `:help hidden`
&quot; for more information on this.
set hidden

&quot; 默认情况下，退格键有一些不太直观的行为。 例如，在默认情况下，不能在使用'i'设置的插入点之前进行退格操作。 这个配置使退格操作更合理，因为你可以在任何东西上退格。&quot;
&quot; This setting makes search case-insensitive when all characters in the string
&quot; being searched are lowercase. However, the search becomes case-sensitive if
&quot; it contains any capital letters. This makes searching more convenient.
set ignorecase
set smartcase

&quot;在输入时启用搜索，而不是等到按回车键 &quot;
&quot; Enable searching as you type, rather than waiting till you press enter.
set incsearch

&quot; 解绑定一些无用的/恼人的默认键绑定&quot;
&quot; Unbind some useless/annoying default key bindings.
nmap Q &lt;Nop&gt; &quot; 'Q' in normal mode enters Ex mode. You almost never want this.

&quot; Disable audible bell because it's annoying.
set noerrorbells visualbell t_vb=

&quot; 禁用鼠标支持，因为它很烦人。&quot;
&quot; Enable mouse support. You should avoid relying on this too much, but it can
&quot; sometimes be convenient.
set mouse+=a

&quot;尽量避免像使用方向键移动这样的坏习惯。 这不是唯一可能的坏习惯。 例如，按住h/j/k/l键移动，而不是使用更有效的移动命令，也是一个坏习惯。 前者可以通过.vimrc执行，而我们不知道如何防止后者。 在正常模式下做这个…  &quot;
&quot; Try to prevent bad habits like using the arrow keys for movement. This is
&quot; not the only possible bad habit. For example, holding down the h/j/k/l keys
&quot; for movement, rather than using more efficient movement commands, is also a
&quot; bad habit. The former is enforceable through a .vimrc, while we don't know
&quot; how to prevent the latter.
&quot; Do this in normal mode...
nnoremap &lt;Left&gt;  :echoe &quot;Use h&quot;&lt;CR&gt;
nnoremap &lt;Right&gt; :echoe &quot;Use l&quot;&lt;CR&gt;
nnoremap &lt;Up&gt;    :echoe &quot;Use k&quot;&lt;CR&gt;
nnoremap &lt;Down&gt;  :echoe &quot;Use j&quot;&lt;CR&gt;
&quot; ...and in insert mode
inoremap &lt;Left&gt;  &lt;ESC&gt;:echoe &quot;Use h&quot;&lt;CR&gt;
inoremap &lt;Right&gt; &lt;ESC&gt;:echoe &quot;Use l&quot;&lt;CR&gt;
inoremap &lt;Up&gt;    &lt;ESC&gt;:echoe &quot;Use k&quot;&lt;CR&gt;
inoremap &lt;Down&gt;  &lt;ESC&gt;:echoe &quot;Use j&quot;&lt;CR&gt;

</code></pre>
<h4 id="扩展-vim">扩展 Vim</h4>
<ul>
<li>Vim 有很多扩展插件。跟很多互联网上已经过时的建议相反，你_不_需要在 Vim 使用一个插件 管理器（从 Vim 8.0 开始）。你可以使用内置的插件管理系统。只需要创建一个 ~/.vim/pack/vendor/start/ 的文件夹，然后把插件放到这里（比如通过 git clone）。</li>
<li>推荐插件
<ul>
<li>ctrlp.vim: 模糊文件查找</li>
<li>ack.vim: 代码搜索</li>
<li>nerdtree: 文件浏览器</li>
<li>vim-easymotion: 魔术操作</li>
<li>https://vimawesome.com/</li>
</ul>
</li>
</ul>
<h4 id="其他程序的-vim-模式">其他程序的 Vim 模式</h4>
<h5 id="shell-2">Shell</h5>
<ul>
<li>如果你是一个 Bash 用户，用 set -o vi。如果你用 Zsh：bindkey -v。Fish 用 fish_vi_key_bindings。另外，不管利用什么 shell，你可以 export EDITOR=vim。 这是一个用来决定当一个程序需要启动编辑时启动哪个的环境变量。 例如，git 会使用这个编辑器来编辑 commit 信息。</li>
</ul>
<h5 id="readline">Readline</h5>
<ul>
<li>很多程序使用 GNU Readline 库来作为 它们的命令控制行界面。Readline 也支持基本的 Vim 模式， 可以通过在 ~/.inputrc 添加如下行开启：</li>
</ul>
<pre><code>set editing-mode vi
</code></pre>
<ul>
<li>比如，在这个设置下，Python REPL 会支持 Vim 快捷键。</li>
</ul>
<h5 id="其他">其他</h5>
<ul>
<li>甚至有 Vim 的网页浏览快捷键 browsers, 受欢迎的有 用于 Google Chrome 的 Vimium 和用于 Firefox 的 Tridactyl。 你甚至可以在 Jupyter notebooks 中用 Vim 快捷键。 这个列表 中列举了支持类 vim 键位绑定的软件。https://reversed.top/2016-08-13/big-list-of-vim-like-software</li>
</ul>
<h4 id="vim-进阶">Vim 进阶</h4>
<ul>
<li>搜索和替换
<ul>
<li><code>:s</code> （替换）命令
<ul>
<li><code>%s/foo/bar/g</code> 在整个文件中将 foo 全局替换成 bar</li>
<li><code>%s/\[.*\](\(.*\))/\1/g</code> 将有命名的 Markdown 链接替换成简单 URLs</li>
</ul>
</li>
</ul>
</li>
<li>多窗口
<ul>
<li>用 <code>:sp</code> / <code>:vsp</code> 来分割窗口</li>
<li>同一个缓存可以在多个窗口中显示。</li>
</ul>
</li>
<li>宏
<ul>
<li><code>q{字符}</code> 来开始在寄存器{字符}中录制宏</li>
<li><code>q</code> 停止录制</li>
<li><code>@{字符}</code> 重放宏</li>
<li>宏的执行遇错误会停止</li>
<li><code>{计数}@{字符}</code> 执行一个宏{计数}次</li>
<li>宏可以递归
<ul>
<li>首先用 <code>q{字符}q</code> 清除宏</li>
<li>录制该宏，用 <code>@{字符}</code> 来递归调用该宏 （在录制完成之前不会有任何操作）</li>
</ul>
</li>
<li>例子：将 xml 转成 json<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220205222258.png" alt="20220205222258" loading="lazy"></li>
</ul>
</li>
</ul>
<h2 id="数据整理">数据整理</h2>
<h3 id="简单示例">简单示例</h3>
<ul>
<li>查看远程服务器上的日志信息: 查看 ssh 日志并使用 less 分页器</li>
</ul>
<pre><code class="language-bash">$ ssh -p 7777 root@localhost 'journalctl | grep sshd | grep &quot;Disconnected from&quot;' | less

$ ssh myserver 'journalctl | grep sshd | grep &quot;Disconnected from&quot;' &gt; ssh.log
$ less ssh.log
</code></pre>
<ul>
<li>使用 sed 进一步筛选数据
<ul>
<li>s 命令的语法如下：s/REGEX/SUBSTITUTION/, 其中 REGEX 部分是我们需要使用的正则表达式，而 SUBSTITUTION 是用于替换匹配结果的文本。</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed 's/.*Disconnected from //'
</code></pre>
<h3 id="其他-2">其他</h3>
<h4 id="正则表达式">正则表达式</h4>
<ul>
<li>正则表达式通常以（尽管并不总是） /开始和结束。大多数的 ASCII 字符都表示它们本来的含义，但是有一些字符确实具有表示匹配行为的“特殊”含义。不同字符所表示的含义，根据正则表达式的实现方式不同，也会有所变化，这一点确实令人沮丧。常见的模式有：
<ul>
<li><code>.</code> 除换行符之外的”任意单个字符”</li>
<li><code>*</code> 匹配前面字符零次或多次</li>
<li><code>+</code> 匹配前面字符一次或多次</li>
<li><code>[abc]</code> 匹配 a, b 和 c 中的任意一个</li>
<li><code>(RX1|RX2)</code> 任何能够匹配RX1 或 RX2的结果</li>
<li><code>^</code> 行首</li>
<li><code>$</code> 行尾</li>
</ul>
</li>
<li>sed 的正则表达式有些时候是比较奇怪的，它需要你在这些模式前添加\才能使其具有特殊含义。或者，您也可以添加-E选项来支持这些匹配。
<ul>
<li><code>/.*Disconnected from /</code> 这个正则表达式可以匹配任何以若干任意字符开头，并接着包含”Disconnected from “的字符串。</li>
<li>如果有人将 “Disconnected from” 作为自己的用户名，因为默认的 * + 贪婪模式，匹配结果将和预期不符合</li>
</ul>
<pre><code>&quot;Jan 17 03:13:00 thesquareplanet.com sshd[2631]: Disconnected from invalid user Disconnected from 46.97.239.16 port 55920 [preauth]
</code></pre>
<ul>
<li>对于某些正则表达式的实现来说，您可以给 * 或 + 增加一个? 后缀使其变成非贪婪模式，但是很可惜 sed 并不支持该后缀。不过，我们可以切换到 perl 的命令行模式，该模式支持编写这样的正则表达式：</li>
</ul>
<pre><code class="language-bash">perl -pe 's/.*?Disconnected from //'
</code></pre>
</li>
<li>假设我们还需要去掉用户名后面的后缀，想要匹配用户名后面的文本，尤其是当这里的用户名可以包含空格时，这个问题变得非常棘手！这里我们需要做的是匹配一整行：</li>
</ul>
<pre><code class="language-bash"> | sed -E 's/.*Disconnected from (invalid |authenticating )?user .* [^ ]+ port [0-9]+( \[preauth\])?$//'
</code></pre>
<ul>
<li>使用在线正则表达式在线调试工具 regex debugger 来理解这段表达式，
<ul>
<li>开始的部分和以前是一样的</li>
<li>匹配两种类型的“user”（在日志中基于两种前缀区分）</li>
<li>匹配属于用户名的所有字符</li>
<li>匹配任意一个单词（[^ ]+ 会匹配任意非空且不包含空格的序列）</li>
<li>匹配单“port”和它后面的一串数字，以及可能存在的后缀[preauth]</li>
<li>最后再匹配行尾</li>
</ul>
</li>
<li>问题还没有完全解决，日志的内容全部被替换成了空字符串，整个日志的内容因此都被删除了。我们实际上希望能够将用户名保留下来。对此，我们可以使用“捕获组（capture groups）”来完成。被圆括号内的正则表达式匹配到的文本，都会被存入一系列以编号区分的捕获组中。捕获组的内容可以在替换字符串时使用（有些正则表达式的引擎甚至支持替换表达式本身），例如\1、 \2、\3等等，因此可以使用如下命令：</li>
</ul>
<pre><code class="language-bash"> | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
</code></pre>
<h3 id="继续数据整理">继续数据整理</h3>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
</code></pre>
<ul>
<li>我们已经得到了一个包含用户名的列表，列表中的用户都曾经尝试过登陆我们的系统。但这还不够，让我们过滤出那些最常出现的用户：
<ul>
<li><code>sort</code> 排序</li>
<li><code>uniq -c</code> 把连续出现的行折叠为一行并使用出现次数作为前缀</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
 | sort | uniq -c
</code></pre>
<ul>
<li>希望按照出现次数排序，过滤出最常出现的用户名：
<ul>
<li><code>sort -n</code> 会按照数字顺序对输入进行排序（默认情况下是按照字典序排序 <code>-k1,1</code> 则表示“仅基于以空格分割的第一列进行排序”。<code>,n</code> 部分表示“仅排序到第n个部分”，默认情况是到行尾</li>
<li>如果我们希望得到登陆次数最少的用户，我们可以使用 <code>head</code> 来代替 <code>tail</code>，或者使用<code>sort -r</code> 来进行倒序排序。</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
 | sort | uniq -c
 | sort -nk1,1 | tail -n10
</code></pre>
<ul>
<li>但我们只想获取用户名，而且不要一行一个地显示。
<ul>
<li><code>awk</code> 处理文本，'{print $2}' 即为打印第二个部分</li>
<li><code>paste</code> 合并行(<code>-s</code>)，并指定一个分隔符进行分割 (<code>-d</code>)</li>
</ul>
</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
 | sort | uniq -c
 | sort -nk1,1 | tail -n10
 | awk '{print $2}' | paste -sd,
</code></pre>
<h4 id="awk">awk</h4>
<ul>
<li>也是一种文本处理工具。awk 程序接受一个模式串（可选），以及一个代码块，指定当模式匹配时应该做何种操作。默认当模式串即匹配所有行（上面命令中当用法）。 在代码块中，$0 表示整行的内容，$1 到 $n 为一行中的 n 个区域，区域的分割基于 awk 的域分隔符（默认是空格，可以通过-F来修改）。在这个例子中，我们的代码意思是：对于每一行文本，打印其第二个部分，也就是用户名。</li>
<li>统计一下所有以c 开头，以 e 结尾，并且仅尝试过一次登陆的用户。
<ul>
<li><code>$1 == 1</code> 匹配 uniq -c 计数，即只是登陆一次</li>
<li><code>$2 ~ /^c[^ ]*e$/</code> 匹配对应的正则表达式</li>
<li><code>print $2</code> 打印出该用户名</li>
<li><code>wc -l</code> 统计输出结果的行数</li>
</ul>
</li>
</ul>
<pre><code class="language-bash"> | awk '$1 == 1 &amp;&amp; $2 ~ /^c[^ ]*e$/ { print $2 }' | wc -l
</code></pre>
<ul>
<li>既然 awk 是一种编程语言，那么则可以这样：</li>
</ul>
<pre><code class="language-bash">BEGIN { rows = 0 }
$1 == 1 &amp;&amp; $2 ~ /^c[^ ]*e$/ { rows += $1 }
END { print rows }
</code></pre>
<ul>
<li>BEGIN 也是一种模式，它会匹配输入的开头（ END 则匹配结尾）。然后，对每一行第一个部分进行累加，最后将结果输出。事实上，我们完全可以抛弃 grep 和 sed ，因为 awk 就可以解决所有问题。至于怎么做，就留给读者们做课后练习吧。</li>
</ul>
<h3 id="分析数据">分析数据</h3>
<ul>
<li>讲每行的数字加起来</li>
</ul>
<pre><code class="language-bash"> | paste -sd+ | bc -l

# or
echo &quot;2*($(data | paste -sd+))&quot; | bc -l
</code></pre>
<ul>
<li>您可以通过多种方式获取统计数据。如果已经安装了R语言，st是个不错的选择：</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
 | sort | uniq -c
 | awk '{print $1}' | R --slave -e 'x &lt;- scan(file=&quot;stdin&quot;, quiet=TRUE); summary(x)'
</code></pre>
<ul>
<li>R 也是一种编程语言，它非常适合被用来进行数据分析和绘制图表。这里我们不会讲的特别详细， 您只需要知道summary 可以打印某个向量的统计结果。我们将输入的一系列数据存放在一个向量后，利用R语言就可以得到我们想要的统计数据。</li>
<li>如果您希望绘制一些简单的图表， gnuplot 可以帮助到您：</li>
</ul>
<pre><code class="language-bash">ssh myserver journalctl
 | grep sshd
 | grep &quot;Disconnected from&quot;
 | sed -E 's/.*Disconnected from (invalid |authenticating )?user (.*) [^ ]+ port [0-9]+( \[preauth\])?$/\2/'
 | sort | uniq -c
 | sort -nk1,1 | tail -n10
 | gnuplot -p -e 'set boxwidth 0.5; plot &quot;-&quot; using 1:xtic(2) with boxes'
</code></pre>
<h3 id="利用数据整理来确定参数">利用数据整理来确定参数</h3>
<ul>
<li>有时候您要利用数据整理技术从一长串列表里找出你所需要安装或移除的东西。我们之前讨论的相关技术配合 xargs 即可实现：</li>
</ul>
<pre><code class="language-bash">rustup toolchain list | grep nightly | grep -vE &quot;nightly-x86&quot; | sed 's/-x86.*//' | xargs rustup toolchain uninstall
</code></pre>
<h3 id="整理二进制数据">整理二进制数据</h3>
<ul>
<li>虽然到目前为止我们的讨论都是基于文本数据，但对于二进制文件其实同样有用。例如我们可以用 ffmpeg 从相机中捕获一张图片，将其转换成灰度图后通过SSH将压缩后的文件发送到远端服务器，并在那里解压、存档并显示。</li>
</ul>
<pre><code class="language-bash">ffmpeg -loglevel panic -i /dev/video0 -frames 1 -f image2 -
 | convert - -colorspace gray -
 | gzip
 | ssh mymachine 'gzip -d | tee copy.jpg | env DISPLAY=:0 feh -'
</code></pre>
<h2 id="命令行环境">命令行环境</h2>
<ul>
<li>学习如何同时执行多个不同的进程并追踪它们的状态、如何停止或暂停某个进程以及如何使进程在后台运行。还将学习一些能够改善您的 shell 及其他工具的工作流的方法</li>
</ul>
<h3 id="任务控制">任务控制</h3>
<h4 id="结束进程-ctrl-c">结束进程 <code>Ctrl-C</code></h4>
<ul>
<li>您的 shell 会使用 UNIX 提供的信号机制执行进程间通信。当一个进程接收到信号时，它会停止执行、处理该信号并基于信号传递的信息来改变其执行。就这一点而言，信号是一种软件中断。</li>
<li>当我们输入 Ctrl-C 时，shell 会发送一个SIGINT 信号到进程。</li>
<li>下面这个 Python 程序向您展示了捕获信号SIGINT 并忽略它的基本操作，它并不会让程序停止。为了停止这个程序，我们需要使用 SIGQUIT 信号，通过输入 <code>Ctrl-\</code> 可以发送该信号。</li>
</ul>
<pre><code class="language-python">#!/usr/bin/env python
import signal, time

def handler(signum, time):
    print(&quot;\nI got a SIGINT, but I am not stopping&quot;)

signal.signal(signal.SIGINT, handler)
i = 0
while True:
    time.sleep(.1)
    print(&quot;\r{}&quot;.format(i), end=&quot;&quot;)
    i += 1
</code></pre>
<ul>
<li>如果我们向这个程序发送两次 SIGINT ，然后再发送一次 SIGQUIT，程序会有什么反应？注意 <code>^</code> 是我们在终端输入 <code>Ctrl</code> 时的表示形式：</li>
</ul>
<pre><code class="language-python">$ python sigint.py
24^C
I got a SIGINT, but I am not stopping
26^C
I got a SIGINT, but I am not stopping
30^\[1]    39913 quit       python sigint.pyƒ
</code></pre>
<ul>
<li>尽管 SIGINT 和 SIGQUIT 都常常用来发出和终止程序相关的请求。SIGTERM 则是一个更加通用的、也更加优雅地退出信号。为了发出这个信号我们需要使用 <code>kill</code> 命令, 它的语法是： <code>kill -TERM &lt;PID&gt;</code>。</li>
</ul>
<h4 id="暂停和后台执行进程">暂停和后台执行进程</h4>
<ul>
<li>信号可以让进程做其他的事情，而不仅仅是终止它们。例如，SIGSTOP 会让进程暂停。在终端中，键入 <code>Ctrl-Z</code> 会让 shell 发送 <code>SIGTSTP</code> 信号。<code>kill -STOP</code></li>
<li>我们可以使用 <code>fg</code> 或 <code>bg</code> 命令恢复暂停的工作。它们分别表示在<strong>前台继续</strong>或在<strong>后台继续</strong>。</li>
<li><code>jobs</code> 命令会列出当前终端会话中尚未完成的全部任务。您可以使用 <code>pid</code> 引用这些任务（也可以用 <code>pgrep</code> 找出 pid）。更加符合直觉的操作是您可以使用百分号 + 任务编号（jobs 会打印任务编号）来选取该任务。如果要选择最近的一个任务，可以使用 <code>$!</code> 这一特殊参数。</li>
<li>还有一件事情需要掌握，那就是命令中的 <code>&amp;</code> 后缀可以让命令在直接在后台运行，这使得您可以直接在 shell 中继续做其他操作，不过<strong>它此时还是会使用 shell 的标准输出，这一点有时会比较恼人（这种情况可以使用 shell 重定向处理）</strong>。</li>
<li><strong>让已经在运行的进程转到后台运行，您可以键入 <code>Ctrl-Z</code> ，然后紧接着再输入 <code>bg</code></strong> 。注意，后台的进程仍然是您的终端进程的子进程，一旦您关闭终端（会发送另外一个信号 <code>SIGHUP</code>），这些后台的进程也会终止。为了防止这种情况发生，您可以使用 <strong>nohup</strong> (一个用来忽略 SIGHUP 的封装) 来运行程序。针对<strong>已经运行</strong>的程序，可以使用 <strong>disown</strong> 。除此之外，您可以使用<strong>终端多路复用器</strong>来实现，下一章节我们会进行详细地探讨。</li>
</ul>
<pre><code class="language-bash">$ sleep 1000
^Z
[1]  + 18653 suspended  sleep 1000

$ nohup sleep 2000 &amp;
[2] 18745
appending output to nohup.out

$ jobs
[1]  + suspended  sleep 1000
[2]  - running    nohup sleep 2000

$ bg %1
[1]  - 18653 continued  sleep 1000

$ jobs
[1]  - running    sleep 1000
[2]  + running    nohup sleep 2000

$ kill -STOP %1
[1]  + 18653 suspended (signal)  sleep 1000

$ jobs
[1]  + suspended (signal)  sleep 1000
[2]  - running    nohup sleep 2000

$ kill -SIGHUP %1
[1]  + 18653 hangup     sleep 1000

$ jobs
[2]  + running    nohup sleep 2000

$ kill -SIGHUP %2

$ jobs
[2]  + running    nohup sleep 2000

$ kill %2
[2]  + 18745 terminated  nohup sleep 2000

$ jobs
</code></pre>
<ul>
<li>SIGKILL 是一个特殊的信号，它不能被进程捕获并且它会马上结束该进程。不过这样做会有一些副作用，例如留下孤儿进程。</li>
</ul>
<h4 id="终端多路复用">终端多路复用</h4>
<ul>
<li>当您在使用命令行时，您通常会希望同时执行多个任务。举例来说，您可以想要同时运行您的编辑器，并在终端的另外一侧执行程序。<strong>尽管再打开一个新的终端窗口也能达到目的，使用终端多路复用器则是一种更好的办法</strong>。</li>
<li>像 <code>tmux</code> 这类的终端多路复用器可以允许我们基于面板和标签分割出多个终端窗口，这样您便可以同时与多个 shell 会话进行交互。</li>
<li>不仅如此，终端多路复用使我们可以分离当前终端会话并在将来重新连接。</li>
<li>这让您操作远端设备时的工作流大大改善，避免了 nohup 和其他类似技巧的使用。</li>
<li>现在最流行的终端多路器是 tmux。tmux 是一个高度可定制的工具，您可以使用相关快捷键创建多个标签页并在它们间导航。</li>
<li>tmux 的快捷键需要我们掌握，它们都是类似 <code>&lt;C-b&gt; x</code> 这样的组合，即需要先按下 <code>Ctrl+b</code>，松开后再按下 <code>x</code>。tmux 中对象的继承结构如下：
<ul>
<li>会话：每个会话都是一个独立的工作区，其中包含一个或多个窗口
<ul>
<li><code>tmux</code> 开始一个新的会话</li>
<li><code>tmux new -s NAME</code> 以指定名称开始一个新的会话</li>
<li><code>tmux ls</code> 列出当前所有会话</li>
<li>在 tmux 中输入 <code>&lt;C-b&gt; d</code> ，将当前会话分离</li>
<li><code>tmux a</code> 重新连接最后一个会话。您也可以通过 <code>-t</code> 来指定具体的会话</li>
</ul>
</li>
<li>窗口：相当于编辑器或是浏览器中的标签页，从视觉上将一个会话分割为多个部分
<ul>
<li><code>&lt;C-b&gt; c</code> 创建一个新的窗口，使用 <code>&lt;C-d&gt;</code>关闭</li>
<li><code>&lt;C-b&gt; N</code> 跳转到第 N 个窗口，注意每个窗口都是有编号的</li>
<li><code>&lt;C-b&gt; p</code> 切换到前一个窗口</li>
<li><code>&lt;C-b&gt; n</code> 切换到下一个窗口</li>
<li><code>&lt;C-b&gt; ,</code> 重命名当前窗口</li>
<li><code>&lt;C-b&gt; w</code> 列出当前所有窗口</li>
</ul>
</li>
<li>面板：像 vim 中的分屏一样，面板使我们可以在一个屏幕里显示多个 shell
<ul>
<li><code>&lt;C-b&gt; &quot;</code> 水平分割</li>
<li><code>&lt;C-b&gt; %</code> 垂直分割</li>
<li><code>&lt;C-b&gt; &lt;方向&gt;</code> 切换到指定方向的面板，<code>&lt;方向&gt;</code> 指的是键盘上的方向键</li>
<li><code>&lt;C-b&gt; z</code> 切换当前面板的缩放</li>
<li><code>&lt;C-b&gt; [</code> 开始往回卷动屏幕。您可以按下空格键来开始选择，回车键复制选中的部分</li>
<li><code>&lt;C-b&gt; &lt;空格&gt;</code> 在不同的面板排布间切换</li>
</ul>
</li>
</ul>
</li>
<li>其他资料
<ul>
<li><a href="https://www.hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/">A Quick and Easy Guide to tmux</a></li>
<li><a href="http://linuxcommand.org/lc3_adv_termmux.php">Terminal Multiplexers</a></li>
<li><a href="https://www.man7.org/linux/man-pages/man1/screen.1.html">man screen</a></li>
</ul>
</li>
</ul>
<h3 id="别名">别名</h3>
<ul>
<li>输入一长串包含许多选项的命令会非常麻烦。因此，大多数 shell 都支持设置别名。shell 的别名相当于一个长命令的缩写，shell 会自动将其替换成原本的命令。例如，bash 中的别名语法如下：</li>
</ul>
<pre><code class="language-bash">alias alias_name=&quot;command_to_alias arg1 arg2&quot;
</code></pre>
<ul>
<li>注意， =两边是没有空格的，因为 alias 是一个 shell 命令，它只接受一个参数。</li>
<li>别名有许多很方便的特性:</li>
</ul>
<pre><code class="language-bash"># 创建常用命令的缩写
alias ll=&quot;ls -lh&quot;

# 能够少输入很多
alias gs=&quot;git status&quot;
alias gc=&quot;git commit&quot;
alias v=&quot;vim&quot;

# 手误打错命令也没关系
alias sl=ls

# 重新定义一些命令行的默认行为
alias mv=&quot;mv -i&quot;           # -i prompts before overwrite
alias mkdir=&quot;mkdir -p&quot;     # -p make parent dirs as needed
alias df=&quot;df -h&quot;           # -h prints human readable format

# 别名可以组合使用
alias la=&quot;ls -A&quot;
alias lla=&quot;la -l&quot;

# 在忽略某个别名
\ls
# 或者禁用别名
unalias la

# 获取别名的定义
alias ll
# 会打印 ll='ls -lh'
</code></pre>
<ul>
<li>值得注意的是，在默认情况下 shell 并不会保存别名。为了让别名持续生效，您需要将配置放进 shell 的启动文件里，像是.bashrc 或 .zshrc，下一节我们就会讲到。</li>
</ul>
<h3 id="配置文件">配置文件</h3>
<ul>
<li>很多程序的配置都是通过纯文本格式的被称作点文件的配置文件来完成的（之所以称为点文件，是因为它们的文件名以 . 开头，例如 <code>~/.vimrc</code>。也正因为此，它们默认是隐藏文件，ls并不会显示它们）。</li>
<li>shell 的配置也是通过这类文件完成的。在启动时，您的 shell 程序会读取很多文件以加载其配置项。根据 shell 本身的不同，您从登录开始还是以交互的方式完成这一过程可能会有很大的不同。</li>
<li>对于 bash 来说，在大多数系统下，您可以通过编辑 <code>.bashrc</code> 或 <code>.bash_profile</code> 来进行配置。在文件中您可以添加需要在启动时执行的命令，例如上文我们讲到过的别名，或者是您的环境变量。</li>
<li>实际上，很多程序都要求您在 shell 的配置文件中包含一行类似 <code>export PATH=&quot;$PATH:/path/to/program/bin&quot;</code> 的命令，这样才能确保这些程序能够被 shell 找到。</li>
<li>还有一些其他的工具也可以通过点文件进行配置：
<ul>
<li>bash - <code>~/.bashrc</code>, <code>~/.bash_profile</code></li>
<li>git - <code>~/.gitconfig</code></li>
<li>vim - <code>~/.vimrc</code> 和 <code>~/.vim</code> 目录</li>
<li>ssh - <code>~/.ssh/config</code></li>
<li>tmux - <code>~/.tmux.conf</code></li>
</ul>
</li>
<li>我们应该如何管理这些配置文件呢，它们应该在它们的文件夹下，并使用版本控制系统进行管理，然后通过脚本将其 符号链接 到需要的地方。这么做有如下好处：
<ul>
<li>安装简单: 如果您登录了一台新的设备，在这台设备上应用您的配置只需要几分钟的时间；</li>
<li>可以执行: 您的工具在任何地方都以相同的配置工作</li>
<li>同步: 在一处更新配置文件，可以同步到其他所有地方</li>
<li>变更追踪: 您可能要在整个程序员生涯中持续维护这些配置文件，而对于长期项目而言，版本历史是非常重要的</li>
</ul>
</li>
<li>配置文件中需要放些什么？您可以通过在线文档和帮助手册了解所使用工具的设置项。另一个方法是在网上搜索有关特定程序的文章，作者们在文章中会分享他们的配置。还有一种方法就是直接浏览其他人的配置文件：您可以在这里找到无数的<a href="https://github.com/search?o=desc&amp;q=dotfiles&amp;s=stars&amp;type=Repositories">dotfiles仓库</a> —— 其中最受欢迎的那些可以在<a href="https://github.com/mathiasbynens/dotfiles">这里</a>找到（我们建议您不要直接复制别人的配置）。<a href="https://dotfiles.github.io/">这里</a> 也有一些非常有用的资源。</li>
</ul>
<h4 id="可移植性">可移植性</h4>
<ul>
<li>配置文件的一个常见的痛点是它可能并不能在多种设备上生效。例如，如果您在不同设备上使用的操作系统或者 shell 是不同的，则配置文件是无法生效的。或者，有时您仅希望特定的配置只在某些设备上生效。</li>
<li>有一些技巧可以轻松达成这些目的。如果配置文件 if 语句，则您可以借助它针对不同的设备编写不同的配置。例如，您的 shell 可以这样做：</li>
</ul>
<pre><code class="language-bash">if [[ &quot;$(uname)&quot; == &quot;Linux&quot; ]]; then {do_something}; fi

# 使用和 shell 相关的配置时先检查当前 shell 类型
if [[ &quot;$SHELL&quot; == &quot;zsh&quot; ]]; then {do_something}; fi

# 您也可以针对特定的设备进行配置
if [[ &quot;$(hostname)&quot; == &quot;myServer&quot; ]]; then {do_something}; fi
</code></pre>
<ul>
<li>如果配置文件支持 include 功能，您也可以多加利用。例如：~/.gitconfig 可以这样编写：</li>
</ul>
<pre><code class="language-bash">[include]
    path = ~/.gitconfig_local
</code></pre>
<ul>
<li>然后我们可以在日常使用的设备上创建配置文件 <code>~/.gitconfig_local</code> 来包含与该设备相关的特定配置。您甚至应该创建一个单独的代码仓库来管理这些与设备相关的配置。</li>
<li>如果您希望在不同的程序之间共享某些配置，该方法也适用。例如，如果您想要在 bash 和 zsh 中同时启用一些别名，您可以把它们写在 .aliases 里，然后在这两个 shell 里应用：</li>
</ul>
<pre><code class="language-bash"># Test if ~/.aliases exists and source it
if [ -f ~/.aliases ]; then
    source ~/.aliases
fi
</code></pre>
<h3 id="远端设备">远端设备</h3>
<h4 id="执行命令">执行命令</h4>
<ul>
<li><code>ssh</code> 的一个经常被忽视的特性是它<strong>可以直接远程执行命令</strong>。 <code>ssh foobar@server ls</code> 可以直接在用 <code>foobar</code> 的命令下执行 <code>ls</code> 命令。 想要配合管道来使用也可以， <code>ssh foobar@server ls | grep PATTERN</code> 会在本地查询远端 <code>ls</code> 的输出而 <code>ls | ssh foobar@server grep PATTERN</code> 会在远端对本地 ls 输出的结果进行查询。</li>
</ul>
<h4 id="ssh-密钥">SSH 密钥</h4>
<ul>
<li>生成：<code>ssh-keygen</code></li>
<li>可以为密钥设置密码，防止有人持有您的私钥并使用它访问您的服务器。</li>
<li>可以使用 ssh-agent 或 gpg-agent ，这样就不需要每次都输入该密码了。</li>
<li>检查您是否持有密码并验证它，您可以运行 <code>ssh-keygen -y -f /path/to/key</code>.</li>
</ul>
<h5 id="基于密钥的认证机制">基于密钥的认证机制</h5>
<ul>
<li>ssh 会查询 .ssh/authorized_keys 来确认那些用户可以被允许登录。您可以通过下面的命令将一个公钥拷贝到这里：</li>
</ul>
<pre><code class="language-bash">cat .ssh/id_ed25519.pub | ssh foobar@remote 'cat &gt;&gt; ~/.ssh/authorized_keys'

ssh-copy-id -i .ssh/id_ed25519.pub foobar@remote
</code></pre>
<h4 id="ssh-复制文件">SSH 复制文件</h4>
<ul>
<li><code>ssh+tee</code> 最简单的方法是执行 ssh 命令，然后通过这样的方法利用标准输入实现 <code>cat localfile | ssh remote_server tee serverfile</code>。回忆一下，tee 命令会将标准输出写入到一个文件;</li>
<li><code>scp</code>: 当需要拷贝大量的文件或目录时，使用scp 命令则更加方便，因为它可以方便的遍历相关路径。语法如下：<code>scp path/to/local_file remote_host:path/to/remote_file</code>；</li>
<li><code>rsync</code>：对 scp 进行了改进，它可以检测本地和远端的文件以防止重复拷贝。它还可以提供一些诸如符号连接、权限管理等精心打磨的功能。甚至还可以基于 <code>--partial</code> 标记实现断点续传。rsync 的语法和scp类似；</li>
</ul>
<h4 id="ssh-端口转发">SSH 端口转发</h4>
<ul>
<li>本地端口转发
<ul>
<li>远端设备上的服务监听一个端口，而您希望在本地设备上的一个端口建立连接并转发到远程端口上。</li>
<li>例如，我们在远端服务器上运行 Jupyter notebook 并监听 8888 端口。 然后，建立从本地端口 9999 的转发，使用 <code>ssh -L 9999:localhost:8888 foobar@remote_server</code> 。这样只需要访问本地的 localhost:9999 即可。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220206152012.png" alt="20220206152012" loading="lazy"></li>
</ul>
</li>
<li>远程端口转发</li>
<li><img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220206152120.png" alt="20220206152120" loading="lazy"></li>
</ul>
<h5 id="ssh-配置">SSH 配置</h5>
<ul>
<li>~/.ssh/config.</li>
</ul>
<pre><code>Host vm
    User foobar
    HostName 172.16.174.141
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 9999 localhost:8888

# 在配置文件中也可以使用通配符
Host *.mit.edu
    User foobaz
</code></pre>
<ul>
<li>这么做的好处是，使用 <code>~/.ssh/config</code> 文件来创建别名，类似 scp、rsync和mosh的这些命令都可以读取这个配置并将设置转换为对应的命令行选项。</li>
<li>注意，<code>~/.ssh/config</code> 文件也可以被当作配置文件，而且一般情况下也是可以被导入其他配置文件的。不过，如果您将其公开到互联网上，那么其他人都将会看到您的服务器地址、用户名、开放端口等等。这些信息可能会帮助到那些企图攻击您系统的黑客，所以请务必三思。</li>
<li>服务器侧的配置通常放在 <code>/etc/ssh/sshd_config</code>。您可以在这里配置免密认证、修改 ssh 端口、开启 X11 转发等等。 您也可以为每个用户单独指定配置。</li>
</ul>
<h4 id="其他-3">其他</h4>
<ul>
<li>连接远程服务器的一个常见痛点是遇到由关机、休眠或网络环境变化导致的掉线。如果连接的延迟很高也很让人讨厌。<a href="https://mosh.org/">Mosh</a>（即 mobile shell ）对 ssh 进行了改进，它允许连接漫游、间歇连接及智能本地回显。</li>
<li>有时将一个远端文件夹挂载到本地会比较方便， <a href="https://github.com/libfuse/sshfs">sshfs</a> 可以将远端服务器上的一个文件夹挂载到本地，然后您就可以使用本地的编辑器了。</li>
</ul>
<h3 id="shell-框架">Shell &amp; 框架</h3>
<ul>
<li>在 shell 工具和脚本那节课中我们已经介绍了 bash shell，因为它是目前最通用的 shell，大多数的系统都将其作为默认 shell。但是，它并不是唯一的选项。例如，zsh shell 是 bash 的超集并提供了一些方便的功能：
<ul>
<li>智能替换, **</li>
<li>行内替换/通配符扩展</li>
<li>拼写纠错</li>
<li>更好的 tab 补全和选择</li>
<li>路径展开 (cd /u/lo/b 会被展开为 /usr/local/bin)</li>
</ul>
</li>
<li>框架 也可以改进您的 shell。比较流行的通用框架包括prezto 或 oh-my-zsh。还有一些更精简的框架，它们往往专注于某一个特定功能，例如zsh 语法高亮 或 zsh 历史子串查询。 像 fish 这样的 shell 包含了很多用户友好的功能，其中一些特性包括：
<ul>
<li>向右对齐</li>
<li>命令语法高亮</li>
<li>历史子串查询</li>
<li>基于手册页面的选项补全</li>
<li>更智能的自动补全</li>
<li>提示符主题</li>
</ul>
</li>
<li>需要注意的是，使用这些框架可能会降低您 shell 的性能，尤其是如果这些框架的代码没有优化或者代码过多。您随时可以测试其性能或禁用某些不常用的功能来实现速度与功能的平衡。</li>
</ul>
<h3 id="终端模拟器">终端模拟器</h3>
<ul>
<li>和自定义 shell 一样，花点时间选择适合您的 终端模拟器并进行设置是很有必要的。有许多终端模拟器可供您选择</li>
</ul>
<h2 id="git">Git</h2>
<ul>
<li>自底向上理解 Git</li>
</ul>
<h3 id="git-的数据模型">Git 的数据模型</h3>
<h4 id="快照">快照</h4>
<ul>
<li>Git 将顶级目录中的文件和文件夹作为集合，并通过一系列快照来管理其历史记录。在Git的术语里，文件被称作Blob对象（数据对象），也就是一组数据。目录则被称之为“树”，它将名字与 Blob 对象或树对象进行映射（使得目录中可以包含其他目录）。快照则是被追踪的最顶层的树。例如，一个树看起来可能是这样的：</li>
</ul>
<pre><code class="language-bash">&lt;root&gt; (tree)
|
+- foo (tree)
|  |
|  + bar.txt (blob, contents = &quot;hello world&quot;)
|
+- baz.txt (blob, contents = &quot;git is wonderful&quot;)
</code></pre>
<ul>
<li>这个顶层的树包含了两个元素，一个名为 “foo” 的树（它本身包含了一个blob对象 “bar.txt”），以及一个 blob 对象 “baz.txt”。</li>
</ul>
<h4 id="历史记录建模关联快照">历史记录建模：关联快照</h4>
<ul>
<li>版本控制系统和快照有什么关系呢？线性历史记录是一种最简单的模型，它包含了一组按照时间顺序线性排列的快照。不过处于种种原因，Git 并没有采用这样的模型。</li>
<li>在 Git 中，历史记录是一个由快照组成的有向无环图。有向无环图，听上去似乎是什么高大上的数学名词。不过不要怕，您只需要知道这代表 Git 中的每个快照都有一系列的“父辈”，也就是其之前的一系列快照。注意，快照具有多个“父辈”而非一个，因为某个快照可能由多个父辈而来。例如，经过合并后的两条分支。</li>
<li>在 Git 中，这些快照被称为“提交”。通过可视化的方式来表示这些历史提交记录时，看起来差不多是这样的：</li>
</ul>
<pre><code class="language-bash">o &lt;-- o &lt;-- o &lt;-- o
            ^  
             \
              --- o &lt;-- o
</code></pre>
<ul>
<li>上面是一个 ASCII 码构成的简图，其中的 o 表示一次提交（快照）。</li>
<li>箭头指向了当前提交的父辈（这是一种“在。。。之前”，而不是“在。。。之后”的关系）。在第三次提交之后，历史记录分岔成了两条独立的分支。这可能因为此时需要同时开发两个不同的特性，它们之间是相互独立的。开发完成后，这些分支可能会被合并并创建一个新的提交，这个新的提交会同时包含这些特性。新的提交会创建一个新的历史记录，看上去像这样（最新的合并提交用粗体标记）：</li>
</ul>
<pre><code class="language-bash">o &lt;-- o &lt;-- o &lt;-- o &lt;---- o
            ^            /
             \          v
              --- o &lt;-- o
</code></pre>
<ul>
<li>Git 中的提交是不可改变的。但这并不代表错误不能被修改，只不过这种“修改”实际上是创建了一个全新的提交记录。而引用（参见下文）则被更新为指向这些新的提交。</li>
</ul>
<h4 id="数据模型及其伪代码表示">数据模型及其伪代码表示</h4>
<ul>
<li>以伪代码的形式来学习 Git 的数据模型，可能更加清晰：</li>
</ul>
<pre><code class="language-bash">// 文件就是一组数据
type blob = array&lt;byte&gt;

// 一个包含文件和目录的目录
type tree = map&lt;string, tree | blob&gt;

// 每个提交都包含一个父辈，元数据和顶层树
type commit = struct {
    parent: array&lt;commit&gt;
    author: string
    message: string
    snapshot: tree
}
</code></pre>
<h4 id="对象和内存寻址">对象和内存寻址</h4>
<ul>
<li>Git 中的对象可以是 blob、树或提交：</li>
</ul>
<pre><code class="language-bash">type object = blob | tree | commit
</code></pre>
<ul>
<li>Git 在储存数据时，所有的对象都会基于它们的 SHA-1 哈希 进行寻址。</li>
</ul>
<pre><code class="language-python">objects = map&lt;string, object&gt;

def store(object):
    id = sha1(object)
    objects[id] = object

def load(id):
    return objects[id]
</code></pre>
<ul>
<li><strong>Blobs、树和提交都一样，它们都是对象</strong>。当它们引用其他对象时，它们并没有真正的在硬盘上保存这些对象，而是仅仅保存了它们的哈希值作为引用。</li>
<li>例如，上面例子中的树（可以通过 <code>git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48d</code> 来进行可视化），看上去是这样的：</li>
</ul>
<pre><code class="language-bash">100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85    baz.txt
040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87    foo
</code></pre>
<ul>
<li>树本身会包含一些指向其他内容的指针，例如 baz.txt (blob) 和 foo (树)。如果我们用 <code>git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85</code>，即通过哈希值查看 baz.txt 的内容，会得到以下信息：</li>
</ul>
<pre><code class="language-bash">git is wonderful
</code></pre>
<h4 id="引用">引用</h4>
<ul>
<li>现在，所有的快照都可以通过它们的 SHA-1 哈希值来标记了。但这也太不方便了，谁也记不住一串 40 位的十六进制字符。</li>
<li>针对这一问题，Git 的解决方法是给这些哈希值赋予人类可读的名字，也就是引用（references）。引用是指向提交的指针。与对象不同的是，它是可变的（引用可以被更新，指向新的提交）。例如，master 引用通常会指向主分支的最新一次提交。</li>
</ul>
<pre><code class="language-python">references = map&lt;string, string&gt;

def update_reference(name, id):
    references[name] = id

def read_reference(name):
    return references[name]

def load_reference(name_or_id):
    if name_or_id in references:
        return load(references[name_or_id])
    else:
        return load(name_or_id)
</code></pre>
<ul>
<li>
<p>这样，Git 就可以使用诸如 “master” 这样人类可读的名称来表示历史记录中某个特定的提交，而不需要在使用一长串十六进制字符了。</p>
</li>
<li>
<p>有一个细节需要我们注意， 通常情况下，我们会想要知道“我们当前所在位置”，并将其标记下来。这样当我们创建新的快照的时候，我们就可以知道它的相对位置（如何设置它的“父辈”）。在 Git 中，<strong>我们当前的位置有一个特殊的索引，它就是 “HEAD”</strong>。</p>
</li>
</ul>
<h4 id="仓库">仓库</h4>
<ul>
<li>最后，我们可以粗略地给出 Git 仓库的定义了：<code>对象</code> 和 <code>引用</code>。</li>
<li>在硬盘上，Git 仅存储对象和引用：因为其数据模型仅包含这些东西。所有的 git 命令都对应着对提交树的操作，例如增加对象，增加或删除引用。</li>
<li>当您输入某个指令时，请思考一下这条命令是如何对底层的<strong>图数据结构</strong>进行操作的。另一方面，如果您希望修改提交树，例如“丢弃未提交的修改和将 ‘master’ 引用指向提交 5d83f9e 时，有什么命令可以完成该操作（针对这个具体问题，您可以使用 <code>git checkout master</code>; <code>git reset --hard 5d83f9e</code>）</li>
</ul>
<h3 id="暂存区">暂存区</h3>
<ul>
<li>Git 中还包括一个和数据模型完全不相关的概念，但它确是创建提交的接口的一部分。</li>
<li>就上面介绍的快照系统来说，您也许会期望它的实现里包括一个 “创建快照” 的命令，该命令能够基于当前工作目录的当前状态创建一个全新的快照。有些版本控制系统确实是这样工作的，但 Git 不是。我们希望简洁的快照，而且每次从当前状态创建快照可能效果并不理想。例如，考虑如下场景，您开发了两个独立的特性，然后您希望创建两个独立的提交，其中第一个提交仅包含第一个特性，而第二个提交仅包含第二个特性。或者，假设您在调试代码时添加了很多打印语句，然后您仅仅希望提交和修复 bug 相关的代码而丢弃所有的打印语句。</li>
<li>Git 处理这些场景的方法是使用一种叫做 “暂存区（staging area）”的机制，它允许您指定下次快照中要包括那些改动。</li>
</ul>
<h3 id="git-的命令行接口">Git 的命令行接口</h3>
<ul>
<li>不赘述</li>
<li>列觉几个可能用的少的
<ul>
<li><code>git log --all --graph --decorate</code> 可视化历史记录（有向无环图）</li>
<li><code>git diff &lt;revision&gt; &lt;filename&gt;</code> 显示某个文件两个版本之间的差异</li>
<li><code>git mergetool</code> 使用工具来处理合并冲突</li>
<li><code>git rebase</code> 将一系列补丁变基（rebase）为新的基线</li>
<li><code>git clone --depth=1</code> 浅克隆（shallow clone），不包括完整的版本历史信息</li>
<li><code>git add -p</code> 交互式暂存</li>
<li><code>git rebase -i</code> 交互式变基</li>
<li><code>git blame</code> 查看最后修改某行的人</li>
<li><code>git bisect</code> 通过二分查找搜索历史记录</li>
</ul>
</li>
</ul>
<h2 id="调试及性能分析">调试及性能分析</h2>
<h3 id="调试代码">调试代码</h3>
<ul>
<li>“最有效的 debug 工具就是细致的分析，配合恰当位置的打印语句” — Brian</li>
<li>调试代码的第一种方法往往是在您发现问题的地方添加一些打印语句，然后不断重复此过程直到您获取了足够的信息并找到问题的根本原因。</li>
<li>另外一个方法是使用日志，而不是临时添加打印语句。日志较普通的打印语句有如下的一些优势：
<ul>
<li>您可以将日志写入文件、socket 或者甚至是发送到远端服务器而不仅仅是标准输出；</li>
<li>日志可以支持严重等级（例如 INFO, DEBUG, WARN, ERROR等)，这使您可以根据需要过滤日志；</li>
<li>对于新发现的问题，很可能您的日志中已经包含了可以帮助您定位问题的足够的信息。</li>
</ul>
</li>
<li>有很多技巧可以使日志的可读性变得更好，我最喜欢的一个是技巧是对其进行着色。到目前为止，您应该已经知道，以彩色文本显示终端信息时可读性更好。但是应该如何设置呢？</li>
<li>ls 和 grep 这样的程序会使用 <code>ANSI escape codes</code>，它是一系列的特殊字符，可以使您的 shell 改变输出结果的颜色。例如，执行 <code>echo -e &quot;\e[38;2;255;0;0mThis is red\e[0m&quot;</code> 会打印红色的字符串：This is red 。只要您的终端支持真彩色。如果您的终端不支持真彩色（例如 MacOS 的 Terminal.app），您可以使用支持更加广泛的 16 色，例如：<code>”\e[31;1mThis is red\e[0m”</code>。</li>
<li>下面这个脚本向您展示了如何在终端中打印多种颜色（只要您的终端支持真彩色）</li>
</ul>
<pre><code class="language-bash">#!/usr/bin/env bash
for R in $(seq 0 20 255); do
    for G in $(seq 0 20 255); do
        for B in $(seq 0 20 255); do
            printf &quot;\e[38;2;${R};${G};${B}m█\e[0m&quot;;
        done
    done
done
</code></pre>
<h4 id="第三方日志系统">第三方日志系统</h4>
<ul>
<li>多数的程序都会将日志保存在您的系统中的某个地方。对于 UNIX 系统来说，程序的日志通常存放在 /var/log。例如， NGINX web 服务器就将其日志存放于/var/log/nginx。</li>
<li>目前，系统开始使用 system log，您所有的日志都会保存在这里。大多数（但不是全部的）Linux 系统都会使用 systemd，这是一个系统守护进程，它会控制您系统中的很多东西，例如哪些服务应该启动并运行。systemd 会将日志以某种特殊格式存放于/var/log/journal，您可以使用 journalctl 命令显示这些消息。</li>
<li>类似地，在 macOS 系统中是 /var/log/system.log，但是有更多的工具会使用系统日志，它的内容可以使用 log show 显示。</li>
<li>对于大多数的 UNIX 系统，您也可以使用dmesg 命令来读取内核的日志。</li>
<li>如果您希望将日志加入到系统日志中，您可以使用 logger 这个 shell 程序。下面这个例子显示了如何使用 logger并且如何找到能够将其存入系统日志的条目。</li>
<li>不仅如此，大多数的编程语言都支持向系统日志中写日志。</li>
</ul>
<pre><code class="language-bash">logger &quot;Hello Logs&quot;
# On macOS
log show --last 1m | grep Hello
# On Linux
journalctl --since &quot;1m ago&quot; | grep Hello
</code></pre>
<ul>
<li>如果您发现您需要对 journalctl 和 log show 的结果进行大量的过滤，那么此时可以考虑使用它们自带的选项对其结果先过滤一遍再输出。还有一些像 lnav 这样的工具，它为日志文件提供了更好的展现和浏览方式。</li>
</ul>
<h4 id="调试器">调试器</h4>
<ul>
<li>当通过打印已经不能满足您的调试需求时，您应该使用调试器。</li>
<li>调试器是一种可以允许我们和正在执行的程序进行交互的程序，它可以做到：
<ul>
<li>当到达某一行时将程序暂停；</li>
<li>一次一条指令地逐步执行程序；</li>
<li>程序崩溃后查看变量的值；</li>
<li>满足特定条件时暂停程序；</li>
<li>其他高级功能。</li>
</ul>
</li>
<li>很多编程语言都有自己的调试器。Python 的调试器是pdb.</li>
<li>对于更底层的编程语言，您可能需要了解一下 gdb ( 以及它的改进版 pwndbg) 和 lldb。</li>
<li>它们都对类 C 语言的调试进行了优化，它允许您探索任意进程及其机器状态：寄存器、堆栈、程序计数器等。</li>
</ul>
<h4 id="专门工具">专门工具</h4>
<ul>
<li>即使您需要调试的程序是一个二进制的黑盒程序，仍然有一些工具可以帮助到您。当您的程序需要执行一些只有操作系统内核才能完成的操作时，它需要使用 系统调用。有一些命令可以帮助您追踪您的程序执行的系统调用。在 Linux 中可以使用 <code>strace</code> ，在 macOS 和 BSD 中可以使用 dtrace。dtrace 用起来可能有些别扭，因为它使用的是它自有的 D 语言，但是我们可以使用一个叫做 dtruss 的封装使其具有和 strace (更多信息参考 这里)类似的接口</li>
<li>下面的例子展现来如何使用 <code>strace</code> 或 dtruss 来显示ls 执行时，对stat 系统调用进行追踪对结果。若需要深入了解 strace，这篇文章 值得一读。</li>
</ul>
<pre><code class="language-bash"># On Linux
sudo strace -e lstat ls -l &gt; /dev/null
4
# On macOS
sudo dtruss -t lstat64_extended ls -l &gt; /dev/null
</code></pre>
<ul>
<li>有些情况下，我们需要查看网络数据包才能定位问题。像 tcpdump 和 Wireshark 这样的网络数据包分析工具可以帮助您获取网络数据包的内容并基于不同的条件进行过滤。</li>
</ul>
<h4 id="静态分析">静态分析</h4>
<ul>
<li>有些问题是您不需要执行代码就能发现的。例如，仔细观察一段代码，您就能发现某个循环变量覆盖了某个已经存在的变量或函数名；或是有个变量在被读取之前并没有被定义。 这种情况下 静态分析 工具就可以帮我们找到问题。静态分析会将程序的源码作为输入然后基于编码规则对其进行分析并对代码的正确性进行推理。</li>
<li>下面这段 Python 代码中存在几个问题。 首先，我们的循环变量foo 覆盖了之前定义的函数foo。最后一行，我们还把 bar 错写成了baz，因此当程序完成sleep (一分钟)后，执行到这一行的时候便会崩溃。</li>
</ul>
<pre><code class="language-python">import time

def foo():
    return 42

for foo in range(5):
    print(foo)
bar = 1
bar *= 0.2
time.sleep(60)
print(baz)
</code></pre>
<ul>
<li>静态分析工具可以发现此类的问题。当我们使用pyflakes 分析代码的时候，我们会得到与这两处 bug 相关的错误信息。mypy 则是另外一个工具，它可以对代码进行类型检查。这里，mypy 会经过我们bar 起初是一个 int ，然后变成了 float。这些问题都可以在不运行代码的情况下被发现。</li>
</ul>
<pre><code class="language-python">$ pyflakes foobar.py
foobar.py:6: redefinition of unused 'foo' from line 3
foobar.py:11: undefined name 'baz'

$ mypy foobar.py
foobar.py:6: error: Incompatible types in assignment (expression has type &quot;int&quot;, variable has type &quot;Callable[[], Any]&quot;)
foobar.py:9: error: Incompatible types in assignment (expression has type &quot;float&quot;, variable has type &quot;int&quot;)
foobar.py:11: error: Name 'baz' is not defined
Found 3 errors in 1 file (checked 1 source file)
</code></pre>
<ul>
<li>在 shell 工具那一节课的时候，我们介绍了 shellcheck，这是一个类似的工具，但它是应用于 shell 脚本的。</li>
<li>大多数的编辑器和 IDE 都支持在编辑界面显示这些工具的分析结果、高亮有警告和错误的位置。 这个过程通常称为 code linting 。风格检查或安全检查的结果同样也可以进行相应的显示。</li>
<li>在 vim 中，有 ale 或 syntastic 可以帮助您做同样的事情。 在 Python 中， pylint 和 pep8 是两种用于进行风格检查的工具，而 bandit 工具则用于检查安全相关的问题。</li>
<li>对于风格检查和代码格式化，还有以下一些工具可以作为补充：用于 Python 的 black、用于 Go 语言的 gofmt、用于 Rust 的 rustfmt 或是用于 JavaScript, HTML 和 CSS 的 prettier 。这些工具可以自动格式化您的代码，这样代码风格就可以与常见的风格保持一致。 尽管您可能并不想对代码进行风格控制，标准的代码风格有助于方便别人阅读您的代码，也可以方便您阅读它的代码。</li>
</ul>
<h3 id="性能分析">性能分析</h3>
<ul>
<li>即使您的代码能够向您期望的一样运行，但是如果它消耗了您全部的 CPU 和内存，那么它显然也不是个好程序。算法课上我们通常会介绍大O标记法，但却没教给我们如何找到程序中的热点。 鉴于 过早的优化是万恶之源，您需要学习性能分析和监控工具，它们会帮助您找到程序中最耗时、最耗资源的部分，这样您就可以有针对性的进行性能优化。</li>
</ul>
<h4 id="计时">计时</h4>
<ul>
<li>和调试代码类似，大多数情况下我们只需要打印两处代码之间的时间即可发现问题。下面这个例子中，我们使用了 Python 的 time模块。</li>
</ul>
<pre><code class="language-python">import time, random
n = random.randint(1, 10) * 100

# 获取当前时间 
start = time.time()

# 执行一些操作
print(&quot;Sleeping for {} ms&quot;.format(n))
time.sleep(n/1000)

# 比较当前时间和起始时间
print(time.time() - start)

# Output
# Sleeping for 500 ms
# 0.5713930130004883
</code></pre>
<ul>
<li>不过，执行时间（wall clock time）也可能会误导您，因为您的电脑可能也在同时运行其他进程，也可能在此期间发生了等待。 对于工具来说，需要区分真实时间、用户时间和系统时间。通常来说，<strong>用户时间+系统时间代表了您的进程所消耗的实际 CPU</strong>
<ul>
<li>真实时间 - 从程序开始到结束流失掉的真实时间，包括其他进程的执行时间以及阻塞消耗的时间（例如等待 I/O或网络）；</li>
<li>User - CPU 执行用户代码所花费的时间；</li>
<li>Sys - CPU 执行系统内核代码所花费的时间</li>
</ul>
</li>
<li>例如，试着执行一个用于发起 HTTP 请求的命令并在其前面添加 time 前缀。网络不好的情况下您可能会看到下面的输出结果。请求花费了 2s 才完成，但是进程仅花费了 15ms 的 CPU 用户时间和 12ms 的 CPU 内核时间。</li>
</ul>
<pre><code class="language-bash">$ time curl https://missing.csail.mit.edu &amp;&gt; /dev/null`
real    0m2.561s
user    0m0.015s
sys     0m0.012s
</code></pre>
<h4 id="性能分析工具profilers">性能分析工具（profilers）</h4>
<h5 id="cpu">CPU</h5>
<ul>
<li>大多数情况下，当人们提及性能分析工具的时候，通常指的是 CPU 性能分析工具。 CPU 性能分析工具有两种： 追踪分析器（tracing）及采样分析器（sampling）。 追踪分析器 会记录程序的每一次函数调用，而采样分析器则只会周期性的监测（通常为每毫秒）您的程序并记录程序堆栈。它们使用这些记录来生成统计信息，显示程序在哪些事情上花费了最多的时间。如果您希望了解更多相关信息，可以参考这篇 介绍性的文章。</li>
<li>大多数的编程语言都有一些基于命令行的分析器，我们可以使用它们来分析代码。它们通常可以集成在 IDE 中，但是本节课我们会专注于这些命令行工具本身。</li>
<li>在 Python 中，我们使用 cProfile 模块来分析每次函数调用所消耗的时间。 在下面的例子中，我们实现了一个基础的 grep 命令：</li>
</ul>
<pre><code class="language-python">#!/usr/bin/env python

import sys, re

def grep(pattern, file):
    with open(file, 'r') as f:
        print(file)
        for i, line in enumerate(f.readlines()):
            pattern = re.compile(pattern)
            match = pattern.search(line)
            if match is not None:
                print(&quot;{}: {}&quot;.format(i, line), end=&quot;&quot;)

if __name__ == '__main__':
    times = int(sys.argv[1])
    pattern = sys.argv[2]
    for i in range(times):
        for file in sys.argv[3:]:
            grep(pattern, file)
</code></pre>
<ul>
<li>我们可以使用下面的命令来对这段代码进行分析。通过它的输出我们可以知道，IO 消耗了大量的时间，编译正则表达式也比较耗费时间。因为正则表达式只需要编译一次，我们可以将其移动到 for 循环外面来改进性能。</li>
</ul>
<pre><code class="language-bash">$ python -m cProfile -s tottime grep.py 1000 '^(import|\s*def)[^,]*$' *.py

[omitted program output]

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   8000    0.266    0.000    0.292    0.000 {built-in method io.open}
   8000    0.153    0.000    0.894    0.000 grep.py:5(grep)
  17000    0.101    0.000    0.101    0.000 {built-in method builtins.print}
   8000    0.100    0.000    0.129    0.000 {method 'readlines' of '_io._IOBase' objects}
  93000    0.097    0.000    0.111    0.000 re.py:286(_compile)
  93000    0.069    0.000    0.069    0.000 {method 'search' of '_sre.SRE_Pattern' objects}
  93000    0.030    0.000    0.141    0.000 re.py:231(compile)
  17000    0.019    0.000    0.029    0.000 codecs.py:318(decode)
      1    0.017    0.017    0.911    0.911 grep.py:3(&lt;module&gt;)

[omitted lines]
</code></pre>
<ul>
<li>关于 Python 的 cProfile 分析器（以及其他一些类似的分析器），需要注意的是它显示的是每次函数调用的时间。看上去可能快到反直觉，尤其是如果您在代码里面使用了第三方的函数库，因为内部函数调用也会被看作函数调用。</li>
<li>更加符合直觉的显示分析信息的方式是包括每行代码的执行时间，这也是行分析器的工作。例如，下面这段 Python 代码会向本课程的网站发起一个请求，然后解析响应返回的页面中的全部 URL：</li>
</ul>
<pre><code class="language-bash">#!/usr/bin/env python
import requests
from bs4 import BeautifulSoup

# 这个装饰器会告诉行分析器 
# 我们想要分析这个函数
@profile
def get_urls():
    response = requests.get('https://missing.csail.mit.edu')
    s = BeautifulSoup(response.content, 'lxml')
    urls = []
    for url in s.find_all('a'):
        urls.append(url['href'])

if __name__ == '__main__':
    get_urls()
</code></pre>
<ul>
<li>如果我们使用 Python 的 cProfile 分析器，我们会得到超过2500行的输出结果，即使对其进行排序，我仍然搞不懂时间到底都花在哪了。如果我们使用 line_profiler，它会基于行来显示时间：</li>
</ul>
<pre><code class="language-bash">$ kernprof -l -v a.py
Wrote profile results to urls.py.lprof
Timer unit: 1e-06 s

Total time: 0.636188 s
File: a.py
Function: get_urls at line 5

Line #  Hits         Time  Per Hit   % Time  Line Contents
==============================================================
 5                                           @profile
 6                                           def get_urls():
 7         1     613909.0 613909.0     96.5      response = requests.get('https://missing.csail.mit.edu')
 8         1      21559.0  21559.0      3.4      s = BeautifulSoup(response.content, 'lxml')
 9         1          2.0      2.0      0.0      urls = []
10        25        685.0     27.4      0.1      for url in s.find_all('a'):
11        24         33.0      1.4      0.0          urls.append(url['href'])
</code></pre>
<h5 id="内存">内存</h5>
<ul>
<li>
<p>像 C 或者 C++ 这样的语言，内存泄漏会导致您的程序在使用完内存后不去释放它。为了应对内存类的 Bug，我们可以使用类似 Valgrind 这样的工具来检查内存泄漏问题。</p>
</li>
<li>
<p>对于 Python 这类具有垃圾回收机制的语言，内存分析器也是很有用的，因为对于某个对象来说，只要有指针还指向它，那它就不会被回收。</p>
</li>
<li>
<p>下面这个例子及其输出，展示了 memory-profiler 是如何工作的（注意装饰器和 line-profiler 类似）。</p>
</li>
</ul>
<pre><code class="language-python">@profile
def my_func():
    a = [1] * (10 ** 6)
    b = [2] * (2 * 10 ** 7)
    del b
    return a

if __name__ == '__main__':
    my_func()


$ python -m memory_profiler example.py
Line #    Mem usage  Increment   Line Contents
==============================================
     3                           @profile
     4      5.97 MB    0.00 MB   def my_func():
     5     13.61 MB    7.64 MB       a = [1] * (10 ** 6)
     6    166.20 MB  152.59 MB       b = [2] * (2 * 10 ** 7)
     7     13.61 MB -152.59 MB       del b
     8     13.61 MB    0.00 MB       return a
</code></pre>
<h4 id="事件分析">事件分析</h4>
<ul>
<li>在我们使用strace调试代码的时候，您可能会希望忽略一些特殊的代码并希望在分析时将其当作黑盒处理。<code>perf</code> 命令将 CPU 的区别进行了抽象，它不会报告时间和内存的消耗，而是报告与您的程序相关的系统事件。</li>
<li>例如，perf 可以报告不佳的缓存局部性（poor cache locality）、大量的页错误（page faults）或活锁（livelocks）。下面是关于常见命令的简介：
<ul>
<li><code>perf list</code> - 列出可以被 pref 追踪的事件；</li>
<li><code>perf stat COMMAND ARG1 ARG2</code> - 收集与某个进程或指令相关的事件；</li>
<li><code>perf record COMMAND ARG1 ARG2</code> - 记录命令执行的采样信息并将统计数据储存在perf.data中；</li>
<li><code>perf report</code> - 格式化并打印 perf.data 中的数据。</li>
</ul>
</li>
</ul>
<h4 id="可视化">可视化</h4>
<ul>
<li>
<p>使用分析器来分析真实的程序时，由于软件的复杂性，其输出结果中将包含大量的信息。人类是一种视觉动物，非常不善于阅读大量的文字。因此很多工具都提供了可视化分析器输出结果的功能。</p>
</li>
<li>
<p>对于采样分析器来说，常见的显示 CPU 分析数据的形式是 火焰图，火焰图会在 Y 轴显示函数调用关系，并在 X 轴显示其耗时的比例。火焰图同时还是可交互的，您可以深入程序的某一具体部分，并查看其栈追踪（您可以尝试点击下面的图片）。</p>
</li>
<li>
<p>调用图和控制流图可以显示子程序之间的关系，它将函数作为节点并把函数调用作为边。将它们和分析器的信息（例如调用次数、耗时等）放在一起使用时，调用图会变得非常有用，它可以帮助我们分析程序的流程。 在 Python 中您可以使用 pycallgraph 来生成这些图片。</p>
</li>
</ul>
<h4 id="资源监控">资源监控</h4>
<ul>
<li>有时候，分析程序性能的第一步是搞清楚它所消耗的资源。程序变慢通常是因为它所需要的资源不够了。例如，没有足够的内存或者网络连接变慢的时候。</li>
<li>有很多很多的工具可以被用来显示不同的系统资源，例如 CPU 占用、内存使用、网络、磁盘使用等。
<ul>
<li>通用监控 - 最流行的工具要数 htop,了，它是 top的改进版。htop 可以显示当前运行进程的多种统计信息。htop 有很多选项和快捷键，常见的有：<F6> 进程排序、 t 显示树状结构和 h 打开或折叠线程。 还可以留意一下 glances ，它的实现类似但是用户界面更好。如果需要合并测量全部的进程， <strong>dstat</strong> 是也是一个非常好用的工具，它可以实时地计算不同子系统资源的度量数据，例如 I/O、网络、 CPU 利用率、上下文切换等等；</li>
<li>I/O 操作 - iotop 可以显示实时 I/O 占用信息而且可以非常方便地检查某个进程是否正在执行大量的磁盘读写操作；</li>
<li>磁盘使用 - df 可以显示每个分区的信息，而 du 则可以显示当前目录下每个文件的磁盘使用情况（ disk usage）。-h 选项可以使命令以对人类（human）更加友好的格式显示数据；ncdu 是一个交互性更好的 du ，它可以让您在不同目录下导航、删除文件和文件夹；</li>
<li>内存使用 - free 可以显示系统当前空闲的内存。内存也可以使用 htop 这样的工具来显示；</li>
<li>打开文件 - lsof 可以列出被进程打开的文件信息。 当我们需要查看某个文件是被哪个进程打开的时候，这个命令非常有用；</li>
<li>网络连接和配置 - ss 能帮助我们监控网络包的收发情况以及网络接口的显示信息。ss 常见的一个使用场景是找到端口被进程占用的信息。如果要显示路由、网络设备和接口信息，您可以使用 ip 命令。注意，netstat 和 ifconfig 这两个命令已经被前面那些工具所代替了。</li>
<li>网络使用 - nethogs 和 iftop 是非常好的用于对网络占用进行监控的交互式命令行工具。</li>
</ul>
</li>
<li>如果您希望测试一下这些工具，您可以使用 stress 命令来为系统人为地增加负载。</li>
</ul>
<h4 id="专用工具">专用工具</h4>
<ul>
<li>有时候，您只需要对黑盒程序进行基准测试，并依此对软件选择进行评估。 类似 hyperfine 这样的命令行可以帮您快速进行基准测试。例如，我们在 shell 工具和脚本那一节课中我们推荐使用 fd 来代替 find。我们这里可以用hyperfine来比较一下它们。</li>
<li>例如，下面的例子中，我们可以看到fd 比 find 要快20倍。</li>
</ul>
<pre><code class="language-bash">$ hyperfine --warmup 3 'fd -e jpg' 'find . -iname &quot;*.jpg&quot;'
Benchmark #1: fd -e jpg
  Time (mean ± σ):      51.4 ms ±   2.9 ms    [User: 121.0 ms, System: 160.5 ms]
  Range (min … max):    44.2 ms …  60.1 ms    56 runs

Benchmark #2: find . -iname &quot;*.jpg&quot;
  Time (mean ± σ):      1.126 s ±  0.101 s    [User: 141.1 ms, System: 956.1 ms]
  Range (min … max):    0.975 s …  1.287 s    10 runs

Summary
  'fd -e jpg' ran
   21.89 ± 2.33 times faster than 'find . -iname &quot;*.jpg&quot;'
</code></pre>
<ul>
<li>和 debug 一样，浏览器也包含了很多不错的性能分析工具，可以用来分析页面加载，让我们可以搞清楚时间都消耗在什么地方（加载、渲染、脚本等等）。 更多关于 Firefox 和 Chrome的信息可以点击链接。</li>
</ul>
<h2 id="安全和密码学">安全和密码学</h2>
<h3 id="熵">熵</h3>
<ul>
<li>熵(Entropy) 度量了不确定性并可以用来决定密码的强度。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20220206161025.png" alt="20220206161025" loading="lazy"></li>
<li>熵的单位是 比特。对于一个均匀分布的随机离散变量，熵等于log_2(所有可能的个数，即n)。 扔一次硬币的熵是1比特。掷一次（六面）骰子的熵大约为2.58比特。</li>
<li>一般我们认为攻击者了解密码的模型（最小长度，最大长度，可能包含的字符种类等），但是不了解某个密码是如何随机选择的—— 比如掷骰子。</li>
<li>使用多少比特的熵取决于应用的威胁模型。 上面的XKCD漫画告诉我们，大约40比特的熵足以对抗在线穷举攻击（受限于网络速度和应用认证机制）。 而对于离线穷举攻击（主要受限于计算速度）, 一般需要更强的密码 (比如80比特或更多)。</li>
</ul>
<h3 id="散列">散列</h3>
<ul>
<li>密码散列函数 (Cryptographic hash function) 可以将任意大小的数据映射为一个固定大小的输出。除此之外，还有一些其他特性。 一个散列函数的大概规范如下：</li>
</ul>
<pre><code class="language-bash">hash(value: array&lt;byte&gt;) -&gt; vector&lt;byte, N&gt;  (N对于该函数固定)
</code></pre>
<ul>
<li>SHA-1是Git中使用的一种散列函数， 它可以将任意大小的输入映射为一个160比特（可被40位十六进制数表示）的输出。 下面我们用sha1sum命令来测试SHA1对几个字符串的输出</li>
</ul>
<pre><code class="language-bash">$ printf 'hello' | sha1sum
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
$ printf 'hello' | sha1sum
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
$ printf 'Hello' | sha1sum 
f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0
</code></pre>
<ul>
<li>抽象地讲，散列函数可以被认为是一个不可逆，且看上去随机（但具确定性）的函数 （这就是散列函数的理想模型）。 一个散列函数拥有以下特性：
<ul>
<li>确定性：对于不变的输入永远有相同的输出。</li>
<li>不可逆性：对于hash(m) = h，难以通过已知的输出h来计算出原始输入m。</li>
<li>目标碰撞抵抗性/弱无碰撞：对于一个给定输入m_1，难以找到m_2 != m_1且hash(m_1) = hash(m_2)。</li>
<li>碰撞抵抗性/强无碰撞：难以找到一组满足hash(m_1) = hash(m_2)的输入m_1, m_2（该性质严格强于目标碰撞抵抗性）。</li>
</ul>
</li>
<li>注：虽然SHA-1还可以用于特定用途，但它已经不再被认为是一个强密码散列函数。 你可参照密码散列函数的生命周期这个表格了解一些散列函数是何时被发现弱点及破解的。 请注意，针对应用推荐特定的散列函数超出了本课程内容的范畴。 如果选择散列函数对于你的工作非常重要，请先系统学习信息安全及密码学。</li>
</ul>
<h4 id="密码散列函数的应用">密码散列函数的应用</h4>
<ul>
<li>Git中的内容寻址存储(Content addressed storage)：散列函数是一个宽泛的概念（存在非密码学的散列函数），那么Git为什么要特意使用密码散列函数？</li>
<li>文件的信息摘要(Message digest)：像Linux ISO这样的软件可以从非官方的（有时不太可信的）镜像站下载，所以需要设法确认下载的软件和官方一致。 官方网站一般会在（指向镜像站的）下载链接旁边备注安装文件的哈希值。 用户从镜像站下载安装文件后可以对照公布的哈希值来确定安装文件没有被篡改。</li>
<li>承诺机制(Commitment scheme)： 假设我希望承诺一个值，但之后再透露它—— 比如在没有一个可信的、双方可见的硬币的情况下在我的脑海中公平的“扔一次硬币”。 我可以选择一个值r = random()，并和你分享它的哈希值h = sha256(r)。 这时你可以开始猜硬币的正反：我们一致同意偶数r代表正面，奇数r代表反面。 你猜完了以后，我告诉你值r的内容，得出胜负。同时你可以使用sha256(r)来检查我分享的哈希值h以确认我没有作弊。</li>
</ul>
<h3 id="密钥生成函数">密钥生成函数</h3>
<ul>
<li>密钥生成函数 (Key Derivation Functions) 作为密码散列函数的相关概念，被应用于包括生成固定长度，可以使用在其他密码算法中的密钥等方面。 为了对抗穷举法攻击，密钥生成函数通常较慢。</li>
</ul>
<h4 id="密钥生成函数的应用">密钥生成函数的应用</h4>
<ul>
<li>从密码生成可以在其他加密算法中使用的密钥，比如对称加密算法（见下）。</li>
<li>存储登录凭证时不可直接存储明文密码。
<ul>
<li>正确的方法是针对每个用户随机生成一个盐 salt = random()， 并存储盐，以及密钥生成函数对连接了盐的明文密码生成的哈希值 <code>F(password + salt)</code></li>
<li>在验证登录请求时，使用输入的密码连接存储的盐重新计算哈希值 <code>KDF(input + salt)</code>，并与存储的哈希值对比。</li>
</ul>
</li>
</ul>
<h3 id="对称加密">对称加密</h3>
<ul>
<li>说到加密，可能你会首先想到隐藏明文信息。对称加密使用以下几个方法来实现这个功能：</li>
</ul>
<pre><code class="language-bash">keygen() -&gt; key  (这是一个随机方法)

encrypt(plaintext: array&lt;byte&gt;, key) -&gt; array&lt;byte&gt;  (输出密文)
decrypt(ciphertext: array&lt;byte&gt;, key) -&gt; array&lt;byte&gt;  (输出明文)
</code></pre>
<ul>
<li>加密方法 <code>encrypt()</code> 输出的密文ciphertext 很难在不知道key的情况下得出明文plaintext。</li>
<li>解密方法 <code>decrypt()</code> 有明显的正确性。因为功能要求给定密文及其密钥，解密方法必须输出明文：<code>decrypt(encrypt(m, k), k) = m</code>。</li>
<li>AES 是现在常用的一种对称加密系统。</li>
</ul>
<h4 id="对称加密的应用">对称加密的应用</h4>
<ul>
<li>加密不信任的云服务上存储的文件。对称加密和密钥生成函数配合起来，就可以使用密码加密文件： 将密码输入密钥生成函数生成密钥 <code>key = KDF(passphrase)</code>，然后存储 <code>encrypt(file, key)</code>。</li>
</ul>
<h3 id="非对称加密">非对称加密</h3>
<ul>
<li>非对称加密的“非对称”代表在其环境中，使用两个具有不同功能的密钥： 一个是<strong>私钥</strong>(private key)，不向外公布；另一个是<strong>公钥</strong>(public key)，公布公钥不像公布对称加密的共享密钥那样可能影响加密体系的安全性。</li>
<li>非对称加密使用以下几个方法来实现加密/解密(encrypt/decrypt)，以及签名/验证(sign/verify)：</li>
</ul>
<pre><code class="language-bash">keygen() -&gt; (public key, private key)  (这是一个随机方法)

encrypt(plaintext: array&lt;byte&gt;, public key) -&gt; array&lt;byte&gt;  (输出密文)
decrypt(ciphertext: array&lt;byte&gt;, private key) -&gt; array&lt;byte&gt;  (输出明文)

sign(message: array&lt;byte&gt;, private key) -&gt; array&lt;byte&gt;  (生成签名)
verify(message: array&lt;byte&gt;, signature: array&lt;byte&gt;, public key) -&gt; bool  (验证签名是否是由和这个公钥相关的私钥生成的)
</code></pre>
<ul>
<li>非对称的加密/解密方法和对称的加密/解密方法有类似的特征。</li>
<li>信息在非对称加密中使用 公钥 加密， 且输出的密文很难在不知道 私钥 的情况下得出明文。</li>
<li>解密方法decrypt()有明显的正确性。 给定密文及私钥，解密方法一定会输出明文： <code>decrypt(encrypt(m, public key), private key) = m</code>。</li>
<li>对称加密和非对称加密可以类比为机械锁。 对称加密就好比一个防盗门：只要是有钥匙的人都可以开门或者锁门。 非对称加密好比一个可以拿下来的挂锁。你可以把打开状态的挂锁（公钥）给任何一个人并保留唯一的钥匙（私钥）。这样他们将给你的信息装进盒子里并用这个挂锁锁上以后，只有你可以用保留的钥匙开锁。</li>
<li>签名/验证方法具有和书面签名类似的特征。</li>
<li>在不知道 私钥 的情况下，不管需要签名的信息为何，很难计算出一个可以使 <code>verify(message, signature, public key)</code> 返回为真的签名。</li>
<li>对于使用私钥签名的信息，验证方法验证和私钥相对应的公钥时一定返回为真： <code>verify(message, sign(message, private key), public key) = true</code>。</li>
</ul>
<h4 id="非对称加密的应用">非对称加密的应用</h4>
<ul>
<li>PGP电子邮件加密：用户可以将所使用的公钥在线发布，比如：PGP密钥服务器或 Keybase。任何人都可以向他们发送加密的电子邮件。</li>
<li>聊天加密：像 Signal 和 Keybase 使用非对称密钥来建立私密聊天。</li>
<li>软件签名：Git 支持用户对提交(commit)和标签(tag)进行GPG签名。任何人都可以使用软件开发者公布的签名公钥验证下载的已签名软件。</li>
</ul>
<h3 id="密钥分发">密钥分发</h3>
<ul>
<li>非对称加密面对的主要挑战是，如何分发公钥并对应现实世界中存在的人或组织。</li>
<li>Signal的信任模型是，信任用户第一次使用时给出的身份(trust on first use)，同时支持用户线下(out-of-band)、面对面交换公钥（Signal里的safety number）。</li>
<li>PGP使用的是信任网络。简单来说，如果我想加入一个信任网络，则必须让已经在信任网络中的成员对我进行线下验证，比如对比证件。验证无误后，信任网络的成员使用私钥对我的公钥进行签名。这样我就成为了信任网络的一部分。只要我使用签名过的公钥所对应的私钥就可以证明“我是我”。</li>
<li>Keybase主要使用社交网络证明 (social proof)，和一些别的精巧设计。</li>
<li>每个信任模型有它们各自的优点：我们更倾向于 Keybase 使用的模型。</li>
</ul>
<h3 id="案例分析">案例分析</h3>
<h4 id="密码管理器">密码管理器</h4>
<ul>
<li>每个人都应该尝试使用密码管理器，比如KeePassXC、pass 和 1Password)。</li>
<li>密码管理器会帮助你对每个网站生成随机且复杂（表现为高熵）的密码，并使用你指定的主密码配合密钥生成函数来对称加密它们。</li>
<li>你只需要记住一个复杂的主密码，密码管理器就可以生成很多复杂度高且不会重复使用的密码。密码管理器通过这种方式降低密码被猜出的可能，并减少网站信息泄露后对其他网站密码的威胁。</li>
</ul>
<h4 id="两步验证双因子验证">两步验证（双因子验证）</h4>
<ul>
<li>两步验证(2FA)要求用户同时使用密码（“你知道的信息”）和一个身份验证器（“你拥有的物品”，比如YubiKey）来消除密码泄露或者钓鱼攻击的威胁。</li>
</ul>
<h4 id="全盘加密">全盘加密</h4>
<ul>
<li>对笔记本电脑的硬盘进行全盘加密是防止因设备丢失而信息泄露的简单且有效方法。 Linux的cryptsetup + LUKS， Windows的BitLocker，或者macOS的FileVault都使用一个由密码保护的对称密钥来加密盘上的所有信息。</li>
</ul>
<h4 id="聊天加密">聊天加密</h4>
<ul>
<li>Signal和Keybase使用非对称加密对用户提供端到端(End-to-end)安全性。</li>
<li>获取联系人的公钥非常关键。为了保证安全性，应使用线下方式验证Signal或者Keybase的用户公钥，或者信任Keybase用户提供的社交网络证明。</li>
</ul>
<h4 id="ssh">SSH</h4>
<ul>
<li>当你运行ssh-keygen命令，它会生成一个非对称密钥对：公钥和私钥(public_key, private_key)。 生成过程中使用的随机数由系统提供的熵决定。这些熵可以来源于硬件事件(hardware events)等。 公钥最终会被分发，它可以直接明文存储。 但是为了防止泄露，私钥必须加密存储。ssh-keygen命令会提示用户输入一个密码，并将它输入密钥生成函数 产生一个密钥。最终，ssh-keygen使用对称加密算法和这个密钥加密私钥。</li>
<li>在实际运用中，当服务器已知用户的公钥（存储在.ssh/authorized_keys文件中，一般在用户HOME目录下），尝试连接的客户端可以使用非对称签名来证明用户的身份——这便是挑战应答方式。 简单来说，服务器选择一个随机数字发送给客户端。客户端使用用户私钥对这个数字信息签名后返回服务器。 服务器随后使用.ssh/authorized_keys文件中存储的用户公钥来验证返回的信息是否由所对应的私钥所签名。这种验证方式可以有效证明试图登录的用户持有所需的私钥。</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[ChameleonDB: a Key-value Store for Optane Persistent Memory]]></title>
        <id>https://blog.shunzi.tech/post/ChameleonDB/</id>
        <link href="https://blog.shunzi.tech/post/ChameleonDB/">
        </link>
        <updated>2021-09-28T08:37:41.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>该篇文章来自于 EuroSys2021 - ChameleonDB: a Key-value Store for Optane Persistent Memory</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>该篇文章来自于 EuroSys2021 - ChameleonDB: a Key-value Store for Optane Persistent Memory</li>
</ul>
</blockquote>
<!--more-->
<h2 id="abstract">Abstract</h2>
<ul>
<li>Optane DC PM 的出现使得利用其高带宽和低延迟构建持久性 KV 存储成为了热点。Optane Pmem 本质上是一种具有两个不同属性的混合存储设备，这是Optane Pmem面临的一个主要挑战。
<ul>
<li>一方面，是一个高速的<strong>字节寻址</strong>的设备，类似于 DRAM</li>
<li>另一方面，对 Optane 的<strong>写操作以 256bytes 进行</strong>，更像一个块设备。</li>
</ul>
</li>
<li>现有的基于持久性内存的 KV 存储设计没有考虑到后面的因素，导致出现了<strong>较高的写放大以及受限的读写吞吐量</strong>。与此同时，直接重用原有的为块设备设计的 KV 存储，如 LSM，也将因为<strong>字节寻址的特性而导致更高的读延迟</strong>。</li>
<li>本文中我们提出了 ChameleonDB，一个考虑且利用了 PM 的两个特性的基于混和 内存/存储 场景的设计。使用 LSM Tree 以低写放大率有效地接受写入，且使用了一个 DRAM 中的 HASH 表来 bypass LSM 的多层结构从而快速读。与此同时，ChameleonDB 可能选择在后台维护LSM多级结构，以在系统崩溃后实现较短的恢复时间。ChameleonDB 的混合结构被设计成能够吸收写负载的突发写入，从而避免长尾延迟。</li>
</ul>
<h2 id="introduction">Introduction</h2>
<ul>
<li>现有的 KV 存储设计在 PM 场景中面临主要三个挑战：</li>
</ul>
<h3 id="challenge-1-optane-pmem-is-a-block-device">Challenge 1: Optane Pmem is a Block Device</h3>
<ul>
<li>在 PM 发布之前就有大量研究人员提出了该设备场景下的 KV 存储。这些设计都假设 PM 是一个稍微慢一点且持久的 DRAM，相应地，这样的设计通常构建一个持久化哈希表或持久化树来索引存储日志中的 KV 项。当新的KV项目按照到达顺序批量写入日志时，索引上的相应更新(通常)在非连续的内存位置单独进行(由哈希函数或树结构确定)。
<ul>
<li>HASH:
<ul>
<li>Level hashing</li>
<li>CCEH</li>
</ul>
</li>
<li>tree-structured
<ul>
<li>WB+ Tree</li>
<li>FAST&amp;FAIR</li>
</ul>
</li>
</ul>
</li>
<li>不幸的是，这些前面的假设和最终商业 PM 相关性能特性的研究表现不一致。</li>
<li>据报道，Optane Pmem的写单元大小为256B，为了理解这种性能特征的含义，我们将特定大小的数据写入与256B单元大小对齐的随机选择的地址。在实验中，我们将写大小从8B改变为128KB，并使用不同的线程数，以便能够达到内存的峰值带宽。测试结果如下所示，当写大小小于 256B 时，写吞吐量比256B及其以上的写吞吐量要小很多，更有意思的是，256B 的吞吐量几乎是 128B 的两倍，128B 又几乎是 64B 的两倍，这强有力地证明了设备 256B 访问单元的特性。<strong>任何非连续的小于该大小的写入都要进行一个 RMW 读后写的操作来生成一个 256B 的写，从而导致写入放大和并减少了有效的内存带宽</strong>。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210428155831.png" alt="20210428155831" loading="lazy"></li>
<li>这样的特性造成之前基于假设的 KV 存储的设计遭受了写性能的损失，原则上类似于对其他块设备(如机械硬盘和 SSD)的小写操作。特别的是，利用持久性的 HASH 表以及树结构的 KV 存储，在 key 插入、rehash、rebalance等过程中每个对索引的更新都是小写操作，比如 16bytes，远小于 256byte，此时写的放大高达 16。由于没有充分考虑设备的写单元，这些设计无法提供高写性能。</li>
</ul>
<figure data-type="image" tabindex="1"><img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210629140723.png" alt="20210629140723" loading="lazy"></figure>
<h3 id="challenge-2-optane-pmem-is-of-high-speed">Challenge 2: Optane Pmem is of High Speed</h3>
<ul>
<li>有大量的工作都是在解决基于块设备的 KV 存储中的小写问题，如 LevelDB/RocksDB/Cassandra/LSM-trie/PebblesDB 都是学术界以及工业界中的例子。他们聚合了最近的更新操作并批量顺序写这些数据到磁盘，根据 key 比较的结果或者hash函数的结果。由于维护一个大的已排序列表的开销太大，所以要维护多个和指数级长的已排序列表。每个列表位于其单独的 level，从 L0 开始是最短的列表，每个 k+1 层 level 都有着 k 层的 r 倍容量。r 的值在不同的 KV 存储中不同，例如 LevelDB/RocksDB r=10，LSM-trie r=8，在 KV 项被写入到存储之后，初始在 L0，然后向下移动直到最后一层。</li>
<li>LSM 树结构有两种主要的压缩方案，它们对写放大和读性能有不同的影响。leveling 和 size-tiering。
<ul>
<li>leveling: 在相邻两层的 KV 项被归并排序然后重新插入到更下面的一层。随着下层的 Key 的个数达到了上层的很多倍之后，每个压缩的写入放大倍数可以大到10(以LevelDB为例)。</li>
<li>size-tiering: 每一层包含多个具有重叠的键范围的子 levels，在子 Level 之间进行键的归并排序操作，结果将被写入到更低一层的新的子 level 中。这样的话，该压缩的写入放大总是为 1。确实该策略可以显著减少额外的写操作，但也会显著增加子 level 的个数，然后增加了在存储中查询一个 Key 的开销。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210303230248.png" alt="20210303230248" loading="lazy"></li>
</ul>
</li>
<li>而基于 LSM 的设计似乎是在Optane Pmem上部署的一个很好的候选方案，它为块设备设计了内置的多级结构，不幸的是，<strong>它与Optane的高读性能不兼容</strong>。因为它的多层设计，读一个 Key 需要检索很多层，从 L0 开始，直到这个 Key 被找到或者找到最后一层都没找到这个 Key。我们的目标是每次搜索 Key 只有一个磁盘读取，在 DRAM 中为每个 KV 项所在的块维护了 BloomFilter，从而在从该层读取磁盘上的数据之前先判断是否该 Key 存在于这个 Block 中。<strong>相比于毫秒级别的磁盘访问时间，对于 filter 的纳秒级的操作几乎可以忽略。只要实际只发生一次磁盘读取，这样的设计就能在磁盘上的 KV 项上实现最好的读取延迟。然而，当存储设备是Optane Pmem 时，情况就大不相同了，它的读延迟本身是纳秒级的，只有 DRAM 读延迟的3倍左右</strong>。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210629140829.png" alt="20210629140829" loading="lazy"></li>
<li>为了理解 Optane 高速访问的影响，我们选择构建了一个基于 HASH 的 KV 存储， 7 层 LSM-trie，分别在 SATA SSD、PCIe SSD 和 Optane PMem 上。在不同的层级上读取 Key 并报告其读延迟，如下图所示。 从表中读取项的时间(在图中表示为“Table read”)是高度一致的，无论键驻留在哪个级别，因为只需要读取一次磁盘(或Pmem)。如图2(a)和2(b)所示，当存储在 SSD 上运行时，花费在过滤器(在图中表示为“Filter Check”)上的时间只占很小的一部分。因此，在 Bloom flters 帮助下的磁盘上的 KV 存储，使用多层次结构不会损害读性能。然而如图 c 所示，当 Optane Pmem 使用的时候，花费在过滤器上的时间就变得很长，相比于 Pmem 的读取时间。KV 对在较低的层级时，它不断增加，最终成为不可接受的。这个观察结果表明，<strong>多级结构成为实现稳定的的低读延迟的主要障碍。同时，同样的结构对于允许批写以适应块设备也是必不可少的</strong></li>
</ul>
<figure data-type="image" tabindex="2"><img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210428225223.png" alt="20210428225223" loading="lazy"></figure>
<h3 id="challenge-3-optane-pmem-is-non-volatile">Challenge 3: Optane Pmem is Non-volatile</h3>
<ul>
<li>为了避免前面提到的挑战，研究者已经提出了当 Pmem 仅用于存储KV项作为存储日志时，将索引结构移动到 DRAM 上。因为 KV 项批量写到日志中没有任何写放大，然后所有的索引的读和更新都发生在 DRAM 上，这样的设计提供了高吞吐和低延迟。（<strong>索引位于 DRAM 上</strong>）
<ul>
<li>ASPLOS’20 FlatStore</li>
<li>FAST'19 uDepot</li>
<li>SOSP'19 KVell</li>
</ul>
</li>
<li>然而，让整个索引或者绝大部分索引都在易失的内存中就一定程度上消除了 Optane Pmem 作为持久性内存的优势，Pmem 本身就是承诺快速故障恢复的介质。对于一个存储了几十亿的 KV 对的 KV 存储，DRAM 中的索引可能占据的空间超过 100GB，而且有限的 DRAM 空间本身就是被多种系统和应用共享，一旦索引数据在丢失，从存储日志中重建这么大的索引是会花费特别长的时间的。与此同时，快速的恢复和重启是很重要的，特别是在虚拟化的环境中，一个 KV 存储可能宿主在虚拟机或者容器中，这些虚拟机容器本身的启动时间就只有几秒甚至不到秒的级别。所以<strong>把最近的对于索引结构的更新周期性地保存在 PMem 中，并使Pmem上的索引有组织并可以很快使用 对于 LSM Tree 的设计是非常有用的</strong>。</li>
<li><strong>（目标：利用 PMem 进行快速故障恢复，减少 DRAM 消耗，主要是快速构建索引）</strong></li>
</ul>
<h3 id="summary">Summary</h3>
<ul>
<li><strong>in-DRAM index</strong><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210629140940.png" alt="20210629140940" loading="lazy"></li>
</ul>
<h3 id="solution">Solution</h3>
<ul>
<li>虽然现有的KV存储设计不能同时实现Optane Pmem上期望的多个目标(<strong>高写吞吐量、低读延迟、高动态工作负载下良好的读尾延迟、小DRAM占用空间、快速恢复和重启</strong>)，但我们提出了一个KV存储设计，名为ChameleonDB，可以在一个系统中实现这个目标。为了证明 ChameleonDB 的实力，下图中和基于 HASH 位于 Pmem 的索引存储以及基于 HASH 位于 DRAM 的索引存储进行了相应的四个性能维度的对比。和写吞吐高度相关的写放大，读延迟，内存占用，恢复时间。
<ul>
<li>PmemLSM 对应传统的带有 Bloom 过滤器的 LSM 树状 KV 存储设计，它有很长的读延迟。（<strong>因为 LSM 和布隆过滤器</strong>）</li>
<li>DRAM_HASH 对应内存中维护索引，PMem 中维护日志，会有比较大的内存占用和很长的恢复时间。（<strong>因为内存 HASH 表内存占用，索引重建开销大</strong>）</li>
<li>Pmem-Hash 对应了持久的 HASH 表设计，会有比较大的写放大，相应地导致较低的写吞吐。（<strong>因为 HASH 操作均为小写，基于 PMem 的特性，存在写放大</strong>）</li>
<li>相反，ChameleonDB 在四个维度都表现得很好。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210429141642.png" alt="20210429141642" loading="lazy"></li>
</ul>
</li>
</ul>
<h4 id="contribution">Contribution</h4>
<ul>
<li>我们分析了现有的在 PMem 上构建的 KV 存储设计的缺点，证明了他们中还没有方案可以同时实现低读延迟、低 DRAM 消耗、快速重启以及高吞吐。特别的，我们揭示了在Optane Pmem上部署基于LSM 的 KV 存储的困境，据我们所知，这尚未在开放文献中进行讨论。</li>
<li>我们提出了 ChameleonDB，一个新的为 PMem 设计的 KV 存储，一定程度上讲，该设计是一个混合设计。利用了其中一个存储(pmems-hash、pmems-lsm 和 dram-hash)的各自优势来解决其他存储可能存在的问题。特别的，<strong>使用了一个多层的结构来高效地持久化索引上的更新操作，使用了一个内存中的 HASH 表来加速小规模的最近更新的索引的读操作，然后使用了在 Pmem 上的哈希表来遍历存储中的大部分 Key，它还提供了一种操作模式，用于减少长读尾延迟</strong>。</li>
<li>我们实现了 ChameleonDB 并进行了测试对比，和其他几种结构的最先进的方案进行了对比。实验表明 ChameleonDB 成功地同时实现了前面提到的目标，且和其他存储相比要在一个或者多个维度上表现得更好。</li>
</ul>
<h2 id="design">Design</h2>
<ul>
<li>
<p><strong>整体结构</strong></p>
<ul>
<li>KV 分离</li>
<li>HASH 分区</li>
<li>DRAM-NVM 混合索引<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210629141059.png" alt="20210629141059" loading="lazy"></li>
</ul>
</li>
<li>
<p>ChameleonDB 是一个 <strong>Value 存储在存储日志上的 KV 存储</strong>，同时 <strong>keys（或者他们的 hash 值）以及对应值的地址信息被存储在相应的持久性索引</strong>中，如下图所示。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210429162043.png" alt="20210429162043" loading="lazy"></p>
</li>
<li>
<p>KV 项根据请求到达顺序被批量写入到 Value Log 中，持久性索引是一个有多个 shards 的高度并行的结构，每个 shard 有自己的多层结构以及自己的 compaction 操作。Keys 根据相应的 hash 值分布在这些 shards<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210629145203.png" alt="20210629145203" loading="lazy"></p>
</li>
</ul>
<h3 id="a-multi-shard-structure">A Multi-shard Structure</h3>
<ul>
<li>ChameleonDB 的索引被组织成多个 shard 的结构，每一个 shard 覆盖了相等范围的 HASH key space。一个 shard 是一个多层的类 LSM 的结构，如下图所示。</li>
<li>每一个 Level 会有很多个子 levels，被称之为 tables，<strong>每一个又被组织成固定大小的 hashtable，使用线性探测的方法来解决 HASH 冲突</strong>。和其他基于 LSM 的 KV 存储一样，每个 shard 有一个内存中的 Memtable 来聚合 KV 项。当 Memtable 满了之后，即负载因子达到了阈值，这时候执行刷回，从 DRAM 到 PMem，最终在 Pmem 上组织成持久的不可变的 L0 level 上的 Tables。每一层能够容纳的最大的 Table 数量是由层级之间的比例系数 r 来确定的，除了最后一层只包含一个 Table。下图所示的例子中的 r 为 4，因此在有四个 Memtables 被 flush 到 Level0 之后然后变满，从而触发 Compaction<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210429162627.png" alt="20210429162627" loading="lazy"></li>
<li>Leveling 和 Size-Tiering 两种策略各有优缺，ChameleonDB在不同的LSM级别上使用这两种压缩方案来提供低写放大和低读延迟。在每一个 shard，size_tiering 主要用于压缩上层，就是在 PMem 上的除了最后一层以外的层次，leveling compaction 用于压缩最底层。这种混合压缩策略在 SIGMOD’18 的 Dostoevsky 中也有应用被称之为 lazy leveling，在写放大和读延迟之间达到平衡，并且比单独使用两种方案中的任何一种性能更好</li>
<li>基于 LSM 的 KV 存储的 Compaction 的策略通常都是在两个相邻的层次之间进行的。以如下所示的图中的例子来说，L0 满了触发到 L1 的 compaction，然后级联 compaction 触发到 L2 的 compaction。</li>
<li>在 ChameleonDB 中，<strong>我们引入了 Direct Compaction 算法通过允许在多个 levels 之间进行 compaction 而减少了压缩开销</strong>。为了完成如下图 a 所示的 compaction，Direct Compaction 首先触发了一个包含 L0,L1,L2 的 compaction，如图 b 所示。同样地，最后一层的 compaction 会在 L0 满且上层 level 都有 r-1 个 tables 的时候执行。在 shard 执行了最后一层的 compaction 之后，shard 上层的所有表都被清除因为其数据项已经被移动到了最后一层。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210429163911.png" alt="20210429163911" loading="lazy"></li>
<li><strong>随着单个 shard 中每个 table 的大小（包括内存中的 Memtable）超过了 256B（PMem 的访问单元），需要按照 256B 大小进行对齐，flushing/compacting table 可以完整利用 PMem 的写带宽，解决了前面描述的第一个挑战。在此之后，每一次 flush memtable 之后，ChameleonDB 持久化 LSM 数据结构的修改，故障恢复只需要重启恢复没有持久化的 Memtable 数据，从而解决挑战三</strong>。</li>
</ul>
<h3 id="the-auxiliary-bypass-index-abi-in-a-shard">The Auxiliary Bypass Index (ABI) in a Shard</h3>
<ul>
<li>因为每一个 shard 是一个多层的结构，一个 get 操作因为需要一层一层检查 tables 直到找到目标的 Key 或者到达最后一层，会有比较严重的读延迟，如下图 a 所示。因为 ChameleonDB 在上层使用了 size-tiering 的压缩策略来减小写放大，levels（以及子 level）的数量已经显著增加，而<strong>在 LSM 中使用的比较多的布隆过滤器，没办法为这种较长的读延迟提供高效的解决方案，因为检查 filters 本身就会占据 PMem 读延迟的大约 50%</strong>，这就是我们为什么需要一个新的解决方案来减小读延迟，也就是 ChameleonDB 辅助旁路索引  Auxiliary Bypass Index（ABI）</li>
<li><strong>每个 shard 有自己的 ABI，本质是一个内存中的 HASH 表，索引了所有的上层 Keys，通过使用 ABI，在查询 Keys 的时候最多查询三个表，一个 Memtable，一个 ABI，一个最后一层的 table</strong>，如图 b 所示。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210429171653.png" alt="20210429171653" loading="lazy"></li>
<li><strong>ABI 包含且只包含存在于上层的 KV 项，当 Keys 被持久化到 L0 的时候，也需要被插入到 ABI 中，在数据项被合并到最后一层的时候，相应地需要从 ABI 中移除对应的索引</strong>。为了实现这样的效果，ChameleonDB 在执行 MemTable 到 L0 的刷回的时候把数据项添加到 ABI，在最后一层的 Compaction 执行之后删除 ABI 中所有的数据项，因为在最后一层的 Compaction 之后所有的上层数据都会被清除。PinK 也尝试着把上层以一个多层的 LSM 结构给固定住，而 ABI 将上层的 keys 组织成一个 hash table，在 DRAM 中以 O(1) 的时间复杂度进行访问。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507171610.png" alt="20210507171610" loading="lazy"></li>
<li>除了减小尾延迟以外，ABI 也能有助于加速最后一层的 Compaction，ABI 包含一个 shard 的上层的所有数据项，Direct Compaction 是把上层所有的 tables 给压缩到最后一层的 table，<strong>不再需要把所有的持久化的上层 Tables 读取出来然后压缩到最后一层，而是直接合并已经存在于 DRAM 中的数据项到最后一层，如下图所示，从而减小最后一层 Compaction 的开销。通过使用 ABI，我们避免了检查多个 levels，从而解决上述挑战2</strong><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507172253.png" alt="20210507172253" loading="lazy"></li>
<li><strong>直接合并 ABI 和 Last Level，这里的前提是 ABI 的数据和 Upper Level 的数据一致，也就是说都是存储的 索引</strong></li>
</ul>
<h3 id="trade-restart-time-for-the-put-performance">Trade Restart Time for the Put Performance</h3>
<ul>
<li>ChameleonDB shards 的多层结构帮忙减少了重启时间，因为只有 Memtable 需要在重启过程中恢复数据，同时 Memtables 只包含了非常小比例的数据，比如对于一个 4 层结构，且系数为 4 的存储大概只包含了 1/256。然而，维护一个多层 LSM 结构消耗了读带宽、CPU 时钟周期、以及写带宽，因为 Compaction 操作需要与 put 请求一起不断进行，这会降低 put 性能。对于传统的 LSM 设计，比如 LevelDB\RocksDB，多层的结构不得不总是被维护，否则，读延迟会大打折扣，因为越来越多的memtable被刷新到0，而没有被压缩就会产生很多级别，导致遍历次数变多。除此以外，DRAM 的消耗也会快速增加，因为 Memtable 变得越来越大来容纳更多的 KV 项。相反，<strong>ChameleonDB 的结构中，上层通常用于快速恢复，提供了一个不用妥协读延迟和 DRAM 消耗来维护多层结构的机遇</strong>。（加 HASH 索引）</li>
<li>在系统特别稳定以及系统很少故障的场景中，ChameleonDB 可以通过暂时暂停多级结构的维护来换取更高的 put 性能，而无需在密集的 put 工作负载期间进行上层压缩，从而降低系统崩溃时重启时间延长的风险。这样的策略我们称之为 <strong>Write-Intensive Mode</strong></li>
<li>在 Write-Intensive Mode 下，Memtables 当满了的时候不再被刷回到 L0，L0 到 L1 的压缩不会被触发，同样地，<strong>所有的压缩到其他高层也不会进行。只有当 ABI 已满时，才会触发清除 ABI 的最后一级压缩，如果这时候一个系统故障发生了，重启时间可能会很长因为 ABI 中所有的项必须从存储日志中恢复</strong>。实验表明该模式下的重启时间仍然比 DRAM-Hash 要小，DRAM-HASH 的整个索引都需要在重启过程中重建。此外，ChameleonDB 重启时间的长短可以将 Write-Intensive Mode 作为一个用户选项来进行控制。</li>
<li><strong>简而言之，Write-Intensive Mode 就是不使用上层的索引，停止维护多级结构，ABI 满了则进行合并</strong></li>
</ul>
<h3 id="handling-put-bursts">Handling Put Bursts</h3>
<ul>
<li>读操作尾延迟通常用来测量 QoS，后台压缩任务对于尾延迟有比较高的影响因为该操作消耗 Optane Pmem 读写带宽，在一个 Put 操作爆发期间，读操作的尾延迟可能显著增加，因为后台压缩任务被触发。</li>
<li>为了提供更好的服务质量，我们在 ChameleonDB 中引入了一个动态的 <strong>Get-Protect Mode</strong> 来监控读操作的尾延迟并调整 Compaction 的时机。具体而言，<strong>就是一个读操作尾延迟到达一个阈值的时候，ChameleonDB 挂起所有的上层 Compactions，包括 flush 操作，延缓最后一层压缩的执行</strong>。挂起上层压缩的影响就是重启时间可能因为不止要恢复 Memtable 还有 ABI 来扫描整个 Log 从而变得很长，和 WriteIntensive Mode 类似，当 ABI 满了之后，所有的数据项需要被压缩到最后一层，假设 DRAM 空间被限制了，且不能容纳一个二级 ABI。然而，最后一层的压缩需要读取最后一层的数据并和 ABI 中的数据进行合并，并写回 Optane Pmem，该操作的开销可能非常大，且显著影响尾延迟，因此 <strong>Get-Protect Mode  下只是将 ABI 中的内容 dump 到 Pmem 上作为一个新的级别，而没有进行合并。这将增加get 请求检查的 levels 的数量。然而，根据我们的实验结果，这种副作用相对于最后一级压缩的成本是适度的</strong>。此外，我们限制了可以转储到 Optane Pmem 的 ABI 的数量(默认为一个)。Dumped 的 tables 将在 put burst subsides 之后被合并到最后一层。当尾延迟低于预先设定的阈值时，将取消 Get-Protect Mode。</li>
<li><strong>简而言之，Get-Protect Mode 就是挂起 Compaction，ABI 满了则 dump 到 PMem</strong></li>
</ul>
<h3 id="implementation-details">Implementation Details</h3>
<h4 id="randomized-load-factors">Randomized Load Factors</h4>
<ul>
<li>哈希表通常用作一种可扩展的结构，其大小随插入的项而变化。一旦一个表被认为是满的，它将被展开，其中的项目将被重新散列到新的位置。重新散列是一个耗时的过程。因此，在ChameleonDB的一个分片中，我们为上层的键使用一个固定大小的散列表，以避免频繁地进行重散列，因为散列表的大小变化很大。</li>
<li>ChameleonDB的分片中的每个表(或子层)也是一个散列表。它通过线性探测来解决碰撞问题。确定此类哈希表是否已满的常用方法是在插入新项时探测它的次数。但是，使用探测计数来确定表是否已满可能会与 ChameleonDB 中的压缩操作发生冲突。例如，由于插入了一个探测数大于阈值的项，一个级别中的4个表中的项可能无法插入到比它大4倍的新表中。另一方面，允许无限的探测时间也不是一个可接受的选择，因为在最坏的情况下，一个 get 请求可能需要扫描整个表，导致太长的 get 延迟。</li>
<li>在ChameleonDB中，我们限制了MemTable的加载因子，从而控制所有持久性表的加载因子(因为它们的所有项都来自MemTable)。例如，当我们将MemTable的负载因子限制为不超过75%时，表的四个槽中就有一个是空的。当MemTable的负载因子达到预定义的阈值时，认为它已经满了。当到达一个空槽时，对哈希表的扫描就会停止，<strong>因此降低负载因子来增加表中的空槽可以改善获取延迟，但代价是降低空间效率和更频繁的压缩。对所有分片使用统一的负载因子阈值将导致压缩突发，因为插入通常会均匀地分布到 shards 上。在压缩爆发期间，所有shards 都需要进行上层压缩，甚至更糟的是，最后一级压缩的KV存储会经历一个显著的性能退化期。为了缓解压缩突发，ChameleonDB为 shards 使用随机加载因子，从而错开不同 shards 的压缩时间。</strong></li>
</ul>
<h4 id="dram-footprint">DRAM footprint</h4>
<ul>
<li>使用ABI改善获取延迟的一个主要问题是它的 DRAM 占用。众所周知，每个分片中的级别大小呈指数级增长。<strong>尽管ABI包含了所有上层的条目，但它只占总指数的中等比例</strong>(例如，1/r ，层次之间的比率为 r )。</li>
</ul>
<h4 id="write-amplifcation">Write Amplifcation</h4>
<ul>
<li>ChameleonDB中的写放大(不包括对存储日志的写)与级别数(表示为l)、级间比r和负载因子(表示为f)有关。写哈希表的写放大为1/f。例如，一个负载因子为75%、大小为1MB的哈希表只有0.75MB的用户数据，因此写入这个表的写入放大倍数是1/0.75。由于ChameleonDB使用大小分层(size-tiering)来进行中层压缩，使用水平分层(leveling )来进行最后一级压缩，ChameleonDB的写入放大倍数为(l−1 + r)/f。</li>
</ul>
<h4 id="kv-items-in-the-storage-log">KV items in the storage log</h4>
<ul>
<li>存储日志中的每个条目都有{key, value_size, value}的形式，其中，key 和 value_size 的大小固定在8个字节，而 value 的大小(也就是 value_size)是可变的。日志项首先在DRAM中缓冲以形成批处理。然后，当批处理的大小达到预定义的阈值(例如，4KB)时，将批处理附加到日志的尾部。</li>
</ul>
<h2 id="evaluation">Evaluation</h2>
<ul>
<li>为了观察和理解 ChameleonDB 在真实系统中的性能行为，并了解它是否实现了所有的设计目标(高写吞吐量、低读延迟、响应请求峰值对读尾延迟的影响，以及快速恢复和重新启动)，我们在英特尔Optane持久性存储器(Pmem)上开发了 ChameleonDB 原型。</li>
</ul>
<h3 id="setup">Setup</h3>
<ul>
<li>ChameleonDB以它的App Direct模式运行，通过调用Persistent的开源库中的函数，通过load和store指令访问内存，通过调用 PMDK 中开源库的函数。</li>
<li>所有实验都在两台服务器上进行8核Intel Xeon Silver 4215处理器，64GB DRAM和两个128GB Optane Pmem。两个Optane Pmem内存条连接到同一个插座，并以交错模式运行。在我们的实验中，KV存储运行在处理器上，本地访问Optane Pmem，以获得更高的访问效率。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507225125.png" alt="20210507225125" loading="lazy"></li>
<li>对比对象：
<ul>
<li>DRAM-HASH：DRAM 中维护 HASH 索引（robin-hood hash table）</li>
<li>Pmem-HASH：PMem 中的持久性 HASH 索引 CCEH</li>
<li>Pmem-LSM-F：带布隆过滤器且位于 PMem 的 LSM</li>
<li>Pmem-LSM-NF：不带布隆过滤器且位于 PMem 的 LSM</li>
<li>Pmem-LSM-PinK：除了最后一层以外所有层驻留在 DRAM 上的 LSM，且不使用布隆过滤器（<strong>该对照组是最公平的对照组，资源开销相近</strong>）</li>
</ul>
</li>
<li><strong>写性能</strong>：
<ul>
<li>PMem-hash 最差，因为在 Optane 上进行了大量的随机写，与 256B 不匹配，写放大严峻</li>
<li>ChameleonDB, Pmem-LSM-NF, and Pmem-LSM-PinK 性能相近，比 Pmem-LSM-F 好很多，这三个方案性能优势相近，因为写入都是大而顺序的，且都没有布隆过滤器的开销。其中 ChameleonDB 和 Pmem-LSM-PinK 在 Compaction 期间使用了一些 DRAM 读代替 PMem 读。三个方案的性能差距较小。因为在 compaction 中发挥了 Pmem 顺序读的优势，与更昂贵的 CPU 使用和哈希操作期间随机 dram 访问 KV 项和压缩相比，读的性能影响大大降低。DRAM-HASH 占用内存更多，恢复更慢，大规模数据场景瓶颈就越明显。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204527.png" alt="20210507204527" loading="lazy"></li>
</ul>
</li>
<li>延迟除 PMem-HASH 以外是比较接近的。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210630110740.png" alt="20210630110740" loading="lazy"></li>
<li>读方面，Pmem-LSM-NF 最差，DRAM-HASH 最高，其次为本文的方案。ChameleonDB 比 PinK 好是因为 PinK 在 DRAM 维护了多层结构 LSM 需要进行多次检查（level by level）。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204550.png" alt="20210507204550" loading="lazy"></li>
<li>延迟和吞吐的比较结果一致。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210630111312.png" alt="20210630111312" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204635.png" alt="20210507204635" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204648.png" alt="20210507204648" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204710.png" alt="20210507204710" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210507204752.png" alt="20210507204752" loading="lazy"></li>
</ul>
<h2 id="related-work">Related Work</h2>
<h3 id="persistent-hashing">Persistent Hashing</h3>
<ul>
<li><strong>PFHT</strong>：是一种布谷鸟哈希变体，它通过在一次写操作中最多允许一次 displacement 来优化以减少在服务写请求期间的内存写操作</li>
<li><strong>Level Hashing</strong>：应用两级散列方案，以便每个键可以有三个桶作为插入的候选桶，这有助于提高负载因子，来代替双重哈希</li>
<li><strong>CCEH</strong>：CCEH是一种可扩展的散列，它使用线性探测策略，因此成功的插入只需要一次内存写操作</li>
<li>这些工作设计的写优化的 HASH 都是试图减少 PM 上的写入，但是现阶段在 Optane 上的就地更新会有严峻写放大，ChameleonDB 则聚合了数据。</li>
</ul>
<h3 id="key-value-stores-for-persistent-memory">Key-value stores for Persistent Memory</h3>
<ul>
<li><strong>SLM-DB</strong>：使用一个全局 B+tree 作为索引，数据追加写日志。因为全局索引所以只能存在 PM 上，但又造成小写。而本文的方案使用 HASH 表，占用更小，可以放在内存中</li>
<li><strong>FlatStore</strong>：维护一个易失的全局索引，数据丢 PM，故障恢复时间长。本文只需要恢复一小部分。</li>
<li>准确理解存储设备的性能特征对于在设备上进行有效的KV-store设计至关重要。</li>
<li><strong>HiKV</strong> 假设了延迟方面 PM 写比 DRAM 差，读相近，但其实最近研究发现 PM 写延迟更接近 DRAM，读延迟更差。本文的设计通过只在 DRAM 中进行小的写操作和使用基于 DRAM 哈希表的旁路索引减少读操作来适应这些真正的性能特征。</li>
<li><strong>Bullet</strong> 使用交叉引用日志(CRLs)技术将持久内存写移出关键路径，解决了优化的持久内存和 DRAM 常驻 KV 存储之间的性能差距。本文则是使用不同的方式来消除这个性能 gap，使用内存哈希表来减少对 Optane Pmem 的访问，然后批量执行小写。</li>
<li><strong>NoveLSM</strong> 和 <strong>MatrixKV</strong> 则主要是利用 PM 来提升写性能，NoveLSM 维护更大的 Memtable 在 PM 上来直接在 PM 上执行小写，MatrixKV 则是把 L0 放在 PM 上来优化 compaction 使其更细粒度。但是本文的方案比这两个方案都要好，因为适配了 256B 访问单元避免了小写，使用了共享数据结构来减少 LSM 的层级数，从而细粒度压缩并减小放大，同时使用了 size-tiering 和 leveling compactions 来减小写放大并保证低延迟。</li>
</ul>
<h3 id="key-value-stores-for-fast-ssd">Key-Value Stores for Fast SSD</h3>
<ul>
<li><strong>KVell</strong>：利用无共享结构和异步 I/O 解决方案来充分利用磁盘 I/O 带宽，避免 CPU 瓶颈，从而提升性能</li>
<li><strong>Zhang et al.</strong>：提出了 FPGA 加速 compaction 的 LSM KV 存储来减小 CPU 瓶颈</li>
<li><strong>PinK</strong>：消除了上层的 BF 并使用基于 FPGA 的 SSD 消除了 compaction 过程中的 CPU 的开销</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing]]></title>
        <id>https://blog.shunzi.tech/post/X-Engine/</id>
        <link href="https://blog.shunzi.tech/post/X-Engine/">
        </link>
        <updated>2021-08-30T08:37:41.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>该篇文章来自于 SIGMOD19: X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>该篇文章来自于 SIGMOD19: X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing</li>
</ul>
</blockquote>
<!--more-->
<h2 id="x-engine">X-Engine</h2>
<h3 id="abstract">Abstract</h3>
<ul>
<li>X-Engine，这是在阿里巴巴构建的 POLARDB 的一个写优化存储引擎，它使用了带有 LSM 树(日志结构的合并树)的分层存储架构，利用 FPGA 加速压缩等硬件加速，以及一套优化，包括事务中的异步写、多级流水线和压缩期间的增量缓存替换。评估结果表明，X-Engine 在事务性工作负载下的性能优于其他存储引擎。</li>
<li><strong>简单概括</strong>：
<ul>
<li>大量的优化都是通过利用多核来异步并发执行一些操作，并使用流水线的相关技术来争取把 CPU 和磁盘打满，并一定程度上进行协同。<strong>但开启大量线程的代价就是极高的 CPU 占用</strong>，所以后面又提出了使用 FPGA 来加速 compaction，通过将 compaction 任务进行拆分，使得 FPGA 可以参与。</li>
<li>其他的几个优化在 RocksDB 上本身也已经得到了应用。
<ul>
<li>L0 层内 compaction 来提高 L0 的有序性加速查询和 compaction</li>
<li>细粒度缓存 KV Cache 和 Block Cache 的协同；细粒度缓存效率对点查询的优化效率更高，粗粒度缓存在 compaction 过程中进行直接替换来代替缓存失效淘汰</li>
<li>元数据索引的多版本 CoW 更新来代替直接 Update 整个元数据</li>
</ul>
</li>
<li>还有就是
<ul>
<li>并发内存跳表，跳表内热数据的多版本优化，数据按版本链式保存</li>
<li>事务的分阶段处理，流水线优化</li>
<li>compaction 过程的数据重用，结合上面的元数据 CoW</li>
<li>内部各个操作的优先级调度，主要是对 compaction 调度</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 id="introduction">Introduction</h3>
<ul>
<li>下图是双 11 负载的变化情况，概括下来就是在特定时间点请求可能呈海啸式增长。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210828173902.png" alt="20210828173902" loading="lazy"></li>
<li>以前处理这种负载的方式为使用一个共享的架构，来在多个 DB 实例中进行分布式的事务处理，然后在峰值来临之前对 DB 实例进行扩展，但是这样由于需要大量实例，它需要大量的资金和工程成本。而本文提出的方法则是 <strong>提升单机的存储引擎容量来解决该问题</strong>，从而使得需要的实例数减少，给定固定成本的可实现吞吐量增加。</li>
<li>针对这种洪泛式的负载，需要快速将数据从内存移动到持久化存储，同时还需要处理高并发的电商事务处理。这种在线促销的负载主要表现为数个小时的事务陡增，包含大量的写入。即便内存大小不断增大，但是比起负载还是小很多，所以必须在 RAM/SSD/HDD 混和存储场景下来重复利用存储资源。X-Engine 根据数据的冷热来进行数据的分层放置，甚至使用 NVM。</li>
<li>LSM 比较适合这种分层结构存储，除了 LSM 以外，还有一些加速写的数据结构，LSM、VLDB12 LogBase、以及优化的树结构，甚至混和结构 bLSM，但是对于我们的场景都不够高效；另一些则通过交换点和范围查询的性能来提高写的性能，因为写不适合混合读和写的电子商务工作负载。</li>
<li>大多数数据库负载，热记录都在一个稳定的时间内表现出了很强的空间局部性，记录的空间位置随时间变化很快。这是因为随着时间的推移，在不同的类别或记录上有不同的促销活动。例如，全天都有针对不同类别或品牌的秒杀促销活动(销售热门商品，你必须抓住它们可供购买的那一秒)，以刺激需求，吸引顾客购买随时间变化的不同商品。这意味着数据库缓存中的热记录会不断变化，任何记录的温度都可能从冷/暖到热或从热到冷/暖。如果我们将数据库缓存视为一个储存库，而将底层(大型)数据库视为海洋，则这种现象将导致当前(即热记录vs .冷记录)在非常深的海洋中快速地向任何方向移动(例如，存储在X-Engine上的巨大数据库)。存储引擎需要确保新出现的热记录能够尽可能快地从深水中检索并有效缓存。</li>
<li><strong>Contributions</strong>
<ul>
<li>利用线程级别的并行在内存中处理大量请求，从事务中解耦写请求来异步执行，将长写路径分解为流水线中的多个阶段，以增加总体吞吐量</li>
<li>利用重定义的 LSM 结构来在分层存储器件上在不同的层次之间移动数据，并优化 compaction 算法</li>
<li>把 compaction offload 到 FPGA</li>
<li>CoW 更新的多版本元数据索引来加速点查询，而不管数据的温度</li>
</ul>
</li>
</ul>
<h3 id="system-overview">System Overview</h3>
<ul>
<li>电商场景数据热度变化频繁，且包含大量的写请求，考虑使用 LSM，但是传统的 LSM 不适合该负载，所以我们做了大量的优化。X-Engine 可以部署在 POLARFS 上，POLARFS 使用了大量的新技术如 RDMA NVMe 等</li>
<li>下图展示了 X-Engine 的架构，把每个 Table 分区到了多个子表，维护了一个 LSM 树，为每个子表关联 metasnapshot 和 索引，每个数据库实例有个 REDO LOG，每个 LSM 树由驻留在内存中的热数据层和 NVM/SSD/HDD 的 温/冷 数据层组成，之后会被分区到不同层。数据的热温冷代表着理想的访问频率，然后相应地被放到对应的层。热数据层包含一个 active memetable 和多个 immutable memtable，都是跳表，存储最近插入的数据，并缓冲热记录。温冷数据层组织数据在一个类似树的结构中，每一层的树存储有序的 extents，一个 extents 打包了对应的数据块、索引块和过滤器块，我们正在探索机器学习技术来识别适当的数据温度，这在附录C中有简要的讨论，它的全部细节超出了这项工作的范围。</li>
<li>X-Engine 利用 redo logs、metasnapshots、和 index 来支持事务多版本并发控制，每一个 metasnapshot 有一个元数据索引来追踪所有的 memtables 和所有层次的 extents，树的一个或多个相邻层组成一个层，分别存储在NVM、SSD和HDD上。在X-Engine中，表被划分为几个子表。每个子表都有自己的热、热和冷数据层(即LSM树)。X-Engine 以面向行格式存储记录。我们设计了一个多版本memtables 来存储不同版本的记录，以支持MVCC(在第3.2.1节介绍)。在磁盘上，元数据索引跟踪存储在区段中的记录的所有版本。我们将在3.1节详细介绍数据结构。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830115307.png" alt="20210830115307" loading="lazy"></li>
<li><strong>The read path</strong>: 读路径是从存储器中检索记录的过程。原来的lsm树设计没有很好的读取性能。查找首先搜索memtable。在memtable中，它必须一个一个地遍历每一层。在最坏的情况下，查找必须以扫描所有级别结束，直到最大级别得出查询记录不存在的结论。为了加速这一过程，提出了一个 manifest file 来定位包含查询键的目标SST。在每个 SST 内还应用了 Bloom 过滤器，以促进早期终止</li>
<li>为了为电子商务交易中常见的点查找获得良好的响应时间，我们<strong>优化了区段的设计，引入了跟踪所有 memtable 和区段的元数据索引，以及一组缓存以促进快速查找</strong>。我们还提出了<strong>压缩中的增量缓存替换方法，以减少压缩导致的不必要的缓存迁出</strong>。我们引入快照以确保查询读取记录的正确版本</li>
<li><strong>The write path</strong>: 写路径包括物理访问路径和在存储引擎中插入或更新记录的相关过程。在lsm树KV存储中，到达的键值对被附加或插入到活动memtable中。一旦完全填充，活动memtable就会切换为不可变的，等待刷新到磁盘。同时，创建一个新的空活动memtable。为了支持高并发事务处理，存储引擎需要通过在持久存储(例如SSD)中记录新记录，并将它们高速插入memtable。在这个过程中，<strong>我们区分了长延迟的磁盘 I/O 和低延迟的内存访问，并将它们组织在一个多级流水线中，以减少每个线程的空闲状态，提高总体吞吐量</strong>(章节3.2.3)。为了实现高水平的并发性，我们进一步<strong>将写的提交与事务处理分离开来，并分别优化它们的线程级并行性</strong>。</li>
<li><strong>Flush and Compaction</strong>: LSM 树依赖于刷新和压缩操作来合并数据，这些数据可能会淹没从memtable到磁盘的主内存，并保持合并数据的有序顺序。不可变memtable被刷新到Level0，在此期间记录被排序并打包到排序序列表(SSTs)中。每个SST都独占一个 Key 范围，因此一个级别可以包含多个SST。当 Level-i 的 sst 规模达到某一阈值时，与Leveli+1键值域重叠的sst合并。这个合并过程在某些系统中称为压缩，因为它还会删除标记为要删除的记录。最初的压缩算法从这两层读取 sst，合并它们，然后将合并后的结果写回 lsm 树。<strong>这个过程有几个缺点:它消耗大量的cpu和磁盘 I/O;同一条记录从LSMtree读取和写入多次，导致写入放大;它会使正在合并的记录的缓存内容无效，即使它们的值保持不变</strong></li>
<li>在X-Engine中，我们首先<strong>优化不可变memtables的刷新</strong>。对于压缩，我们<strong>应用数据重用来减少要合并的区段数量，异步I/O与磁盘I/O重叠，以及FPGA加载来减少CPU消耗</strong>。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830152307.png" alt="20210830152307" loading="lazy"></li>
</ul>
<h3 id="detailed-design">Detailed Design</h3>
<ul>
<li>X-Engine 应用 MVCC 和两阶段锁来实现 Snapshot isolation 和 Read Commited 的隔离级别来保证 ACID，同一记录的不同版本被存储为具有自动递增版本 ID 的单独元组。X-Engine 将这些版本的最大值跟踪为 LSN (日志序列号)。每个传入事务使用它所看到的LSN 作为快照。事务只读取比它自己的 LSN 更小的最大版本的元组，并为它所写的每个元组添加行锁，以避免写冲突。</li>
<li>下图展示了事务处理的流程。这个过程包括一个读/写阶段和一个提交阶段。事务的所有读请求都是通过访问lsm树的读路径在读/写阶段提供的。在此阶段，<strong>将在事务中插入或更新的记录写入事务缓冲区</strong>。接下来，在<strong>提交阶段，将从事务缓冲区写入存储的任务记录分发到多个写任务队列。通过记录相应的记录并将它们插入到lsm树中</strong>，引入了一个多级流水线来处理所有这些写任务。下面我们将详细介绍X-Engine的数据结构、读路径、写路径、刷新和压缩<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830152521.png" alt="20210830152521" loading="lazy"></li>
</ul>
<h4 id="the-read-path">The read path</h4>
<ul>
<li>我们从数据结构的设计开始，包括区段、缓存和索引。对于每个数据结构，我们将介绍它如何促进读取路径中的快速查找。</li>
</ul>
<h5 id="extent">Extent</h5>
<ul>
<li>图4显示了区段的布局，由数据块、元数据和块索引组成。记录以面向行的样式存储在数据块中。元数据 schema 跟踪每个列的类型。块索引保留每个数据块的偏移量。在生产系统的当前部署中，我们在 LSM 树的所有级别上将区段的总大小调优为2 MB。因为许多电子商务事务以高度倾斜的方式访问记录，所以保持这种大小的区段允许在压缩期间重用许多区段(详见第3.3.2节)。这种设计还有助于压缩期间的增量缓存替换(在3.1.4节中引入的优化)<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830153138.png" alt="20210830153138" loading="lazy"></li>
<li>我们在每个区段中使用版本存储模式数据 schema，以加速 DDL(数据定义语言)操作。通过这种设计，当向表中添加新列时，我们只需要在新版本的新区段上强制执行这个新列，而不需要修改任何现有的区段。当查询读取带有不同版本模式的区段时，它将与最新版本保持一致，并将带有旧模式的记录的空属性的缺省值。这种快速 DDL 特性对于在线电子商务业务非常重要，因为在线电子商务业务经常根据需求的变化调整数据库模式的设计。</li>
</ul>
<h5 id="cache">Cache</h5>
<ul>
<li>图5说明了XEngine中的数据库缓存。我们专门为点查找优化了行缓存，点查找是阿里巴巴电子商务交易中的大多数查询。行缓存使用LRU缓存替换策略缓存记录，而不管记录在 LSM 树中的哪个级别。 因此，即使是最大级别的记录也可以被缓存，只要查询访问它。一旦点查找错过了 memtables，查询的键就被散列到行缓存中相应的匹配槽中。因此，在点查询的行缓存中检索记录只需要 O(1)时间。当随机查找访问记录时，行缓存的影响较小。</li>
<li>我们在行缓存中只保存最新版本的记录，由于时间局部性，这些记录被访问的机会最大。为了实现这一点，我们<strong>在刷新期间用行缓存中的新记录替换旧版本的记录，从而减少因刷新而导致的缓存丢失</strong></li>
<li><strong>块缓存以数据块为单位缓冲数据。它为每个没有从行缓存c查询或范围查询请求提供服务</strong>。表缓存包含子表头的元数据信息，这些子表头通向相应的区段。找到区段后，我们使用Bloom筛选器筛选不匹配的键。然后，我们搜索索引块来定位记录，并最终从它的数据块中检索它。</li>
<li>这些缓存对于温度变化后减少记录缓存丢失非常重要。由于记录的空间局部性，行缓存中出现的热记录和已有的热记录可能来自相同的区段甚至相同的数据块。因此，<strong>表和块缓存有助于提高缓存未命中后的总体缓存命中率，并可能有助于减少行缓存中替换的延迟</strong><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830153356.png" alt="20210830153356" loading="lazy"></li>
</ul>
<h5 id="multi-version-metadata-index">Multi-version Metadata Index</h5>
<ul>
<li>图 6 说明了 X-Engine 中多版本元数据索引的结构。<strong>每个子表的LSM 树都有其关联的元数据索引</strong>，该索引从表示子表的根节点开始。<strong>索引的每次修改都会创建一个新的元快照，它指向所有相关的级别和memtable，而不需要修改现有元快照的节点(即copy-on-write方法</strong>)。</li>
<li>在图6中， extent i 最初是 Level0 的一部分，且被缓存(用红色表示)。当重用此区段的压缩完成时，MetaSnapshot v 旁边会创建一个新的 MetaSnapshot v+1，链接到新合并的 Level1 (颜色较深)。Level1 的元数据只需要指向extent i，而不需要在磁盘中实际移动它(用紫色表示)，从而保持所有缓存内容的完整性。<strong>利用这种写时复制方法，事务可以以只读方式访问它们想要的任何版本，而不需要在数据访问期间锁定索引</strong>。我们使用垃圾收集来删除过时的元快照。RocksDB 等其他存储引擎也探索过类似的设计。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830154135.png" alt="20210830154135" loading="lazy"></li>
</ul>
<h5 id="incremental-cache-replacement">Incremental cache replacement</h5>
<ul>
<li>在lsm树中，由于压缩合并了磁盘中的许多区段，它通常会导致大量缓存驱逐，降低了查找时的缓存命中率，并导致明显的性能下降和不稳定的响应时间。即使缓存记录的值没有改变，如果它们的区段与压缩中涉及的其他区段共享重叠的键范围，则它们可能已经在磁盘中移动了。</li>
<li>为了解决这个问题，我们建议在块缓存中进行增量替换，而不是从缓存中删除所有 compacted 区段。在压缩期间，我们检查要合并的区段的数据块是否被缓存。如果是这样，我们<strong>将缓存中的旧块替换为相同位置的新合并块，而不是简单地清除所有旧块。这种方法通过保持块缓存中一些块的更新和不移动来减少缓存丢失</strong>。</li>
</ul>
<h4 id="the-write-path">The write path</h4>
<ul>
<li>在本节中，我们从优化接收每个子表的 LSM 树的传入记录的memtable结构开始。接下来，我们介绍如何设计写任务队列和写路径中的多阶段流水线，它们由X-Engine中所有子表的 LSM 树共享。</li>
</ul>
<h5 id="multi-version-memtable">Multi-version memtable</h5>
<ul>
<li>我们实现 memtable 作为一个无锁的skiplist，像许多其他系统一样，以实现良好的查找和插入性能[9]。然而，在查询热记录时，基于skiplist的memtable的最先进实现存在性能问题。对单个记录的频繁更新会生成多个版本。如果一个热记录与只关注最新版本的查询的谓词匹配，则查询可能必须扫描许多旧版本来定位所请求的版本。电子商务平台上的在线促销活动，在消费者下单购买热门商品时，放大了这些多余的访问。</li>
<li>在X-Engine中，我们<strong>垂直地将相同记录的新版本附加到原始节点旁，形成一个新的链表</strong>。图7显示了提议的结构，其中蓝色节点存储具有不同键的记录，黄色节点存储同一记录的多个版本。<strong>不同的键被组织在一个跳表中，而每个键的多个版本存储在一个链表中。热记录上的更新会增加相应的链表节点</strong>。此外，通常被传入事务引用的新版本被保持在唯一键的skiplist的底层，如图7所示，其中版本99是最新的版本。<strong>该设计减少了扫描不必要的老版本的数据造成的开销</strong>。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830160234.png" alt="20210830160234" loading="lazy"></li>
</ul>
<h5 id="asynchronous-writes-in-transactions">Asynchronous writes in transactions</h5>
<ul>
<li>在InnoDB这样的存储引擎中，传统的一线程一事务方法在写效率上有很大的缺陷。在这种方法中，用户线程从头到尾执行事务。虽然这种方法很容易实现写的执行和事务的并发控制，而用户线程自己不写日志，线程必须等待磁盘IOs写日志的长延迟完成</li>
<li>在X-Engine中，我们选择了另一种方法，将<strong>写的提交与相应的事务解耦，并将它们分组以进行批处理</strong>。如图3所示，我们首先将写任务分配到多个无锁写任务队列中。在此之后，大多数线程可以异步返回来处理其他事务，这样在多级流水线(将在下面介绍)中，每个队列只留下一个线程来参与提交写任务。通过这种方式，事务中的写入是异步的。在高并发工作负载中，这种方法允许更多的线程处理来自并发事务的写任务。队列的最佳数量取决于机器中可用的I/O带宽，以及每个无锁队列上方的多个线程之间的争用。我们发现，在32核机器中，每个队列中有8个线程会使I/O带宽饱和，由于竞争，为每个队列分配更多的线程会降低吞吐量。此外，在解耦过程之后，我们将同一个队列中的写任务分组在一起，并批量处理它们。与单个事务提交相比，批处理提交可以显著提高I/O，从而提高吞吐量。在下面的讨论中，我们将优化批处理的效率<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830180411.png" alt="20210830180411" loading="lazy"></li>
</ul>
<h5 id="multi-staged-pipeline">Multi-staged pipeline</h5>
<ul>
<li>写路径是访问主内存和磁盘的多个操作的一个长序列，在其执行过程中计算工作负载会发生变化。这使得通过计算隐藏内存访问和磁盘 I/O 具有挑战性</li>
<li>为了解决这个问题，我们将写路径分解为多个阶段。图3的右半部分显示了四阶段流水线的概述，其中各个阶段交替访问主内存和磁盘。
<ul>
<li>在第一阶段，<strong>日志缓冲</strong>，线程从事务缓冲区收集每个写请求的wal (write-ahead logs)到内存日志缓冲区，并计算它们相应的CRC32错误检测代码。这个阶段涉及重要的计算和仅访问主内存。</li>
<li>在第二阶段，<strong>日志刷回</strong>，线程将缓冲区中的日志刷新到磁盘。刷新日志后，日志序列号在日志文件中向前移动。然后，这些线程将已经写完日志的写任务推入下一阶段</li>
<li><strong>写 memtable</strong>。在这里，多个线程并行地在活动 memtable 中追加记录。这个阶段只访问主内存。所有这样的写都可以在失败后从 WAL 中恢复。</li>
<li>最后一个阶段，<strong>提交</strong>，完成所有任务的事务最终由多个线程并行提交，并释放它们使用的资源(如锁)。</li>
</ul>
</li>
<li>在这个流水线中，<strong>我们根据每个阶段的需求，分别为每个阶段调度线程，使每个阶段的吞吐量与其他阶段的吞吐量相匹配，以达到总吞吐量的最大化</strong>。虽然前三个阶段是内存密集型的，但第一和第二阶段访问主内存中的不同数据结构，而第二阶段写入磁盘。因此，重叠它们可以提高主存储器和磁盘的利用率。</li>
<li>此外，我们还<strong>分别限制了每个阶段的线程数。由于较强的数据依赖关系在前两个阶段,每个阶段我们只安排一个线程(例如,图3的线程 a)</strong>,其他阶段,我们分配多个线程并行处理(例如,线程b, c, d,如图3所示)。所有线程从阶段拉取任务进行处理。从前两个阶段提取任务的操作是先发制人的，只允许第一个到达的线程处理该阶段。其他阶段则是理想并行，允许多个线程并行工作。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830161423.png" alt="20210830161423" loading="lazy"></li>
</ul>
<h4 id="flush-and-compaction">Flush and Compaction</h4>
<h5 id="fast-flush-of-warm-extents-in-level0">Fast flush of warm extents in Level0</h5>
<ul>
<li>依赖 flush 来避免 OOM，在即将到来的交易高峰时，风险是很大的。在 X-engine中，每个刷新操作将其不可变的memtable转换为extent，将它们追加到Level0，并离开，而不与现有记录合并。然而，这个过程会留下一组未排序的区段。查询现在必须访问所有的区段来寻找潜在的匹配。这个过程中涉及的磁盘 I/O 开销很大。尽管Level0的大小可能不到整个存储空间的1%，但它包含的记录只比最近插入到memtable中的记录稍微老一点。由于电子商务工作负载中的强大时间局部性，传入查询很可能需要这些记录。因此，我们将 Level0 中的区段称为 warm extents</li>
<li>我们<strong>引入了 Level0 内部的压缩来积极地合并 Level0 中的暖区，而不将合并的区推入下一个 Level1</strong>。这种方法将温记录保存在lsm 树的第一级，防止查询深入树中检索这些记录。另一方面，由于 Level0 与其他级别相比规模较小，Level0 内部的压缩只需要访问一小部分区段，不像其他在更深级别中广泛合并区段的压缩。由于这种对 CPU 和 I/O 的轻量级消耗，可以频繁地执行level0内部的压缩。</li>
</ul>
<h5 id="accelerating-compactions">Accelerating compactions</h5>
<ul>
<li>
<p>压缩涉及昂贵的合并操作。我们对压缩应用了三种优化: 数据重用、异步 I/O 和 FPGA 加载。</p>
</li>
<li>
<p><strong>数据重用</strong>。我们在压缩过程中重用区段和数据块，以减少合并两个相邻级别(即Leveli和Leveli+1)所需的 I/O 数量。为了增加重用的机会并使其有效，我们将区段的大小减少到 2 MB，并进一步将区段划分为多个 16 KB 的数据块。<strong>如果压缩所涉及的一个区段的键范围与其他区段的键范围不重叠，则只需更新其相应的元数据索引(如第3.1.3节所介绍的)就可以重用它，而不需要在磁盘上实际移动它</strong>。我们在图8中展示了一个示例，其中Level1的3个区段(键范围为[1,35]、[80,200]和[210,280])被压缩为来自Level2的5个区段(键范围为[1,30]、[50,70]、[100,130]、[150,170]和[190,205])。下面我们列出了不同的重用情况：</p>
<ul>
<li>Level1 的 Extent[210,280]和Level2的Extent[50,70]被直接重用</li>
<li>Level1 的 Extent[1,35] 与 Level2的extent[1,30]重叠。但前者只有一个数据块[1,25]与后者的数据块重叠。因此，数据块[32,35]被重用</li>
<li>Level1 extent[80,200]与Level2中的多个extent重叠。它的第二个数据块与Level2中的三个区段重叠。然而，这个数据块中的键是稀疏的，因为在135到180之间没有键。因此，我们将其分为两个数据块 [106,135] 和[180,200]，并分别将其与Level2的extent[100, 130]和[190,205]进行合并。Extent[150,170]被直接重用<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210830162544.png" alt="20210830162544" loading="lazy"></li>
</ul>
</li>
<li>
<p><strong>Asynchronous I/O</strong>：<strong>在区段级别，压缩操作由三个不相交的阶段组成</strong>:</p>
<ul>
<li>(1)从存储器中检索两个输入区段，</li>
<li>(2)合并它们，</li>
<li>(3)将合并的区段(一个或多个)写回存储器。</li>
</ul>
</li>
<li>
<p>第一和第三阶段是I/O阶段，而第二阶段是计算密集型阶段。我们在第一和第三阶段发出异步I/O请求。第二阶段实现为第一I/O阶段的回调函数。当多个压缩并行运行时，第二阶段的执行与其他阶段的执行重叠，以隐藏I/O</p>
</li>
<li>
<p><strong>FPGA offloading</strong>：我们引入 FPGA 来加速压缩，并减少cpu上的资源消耗。<strong>通过上面介绍的两个优化，在cpu上运行的压缩仍然会消耗多个线程。因为压缩工作在lsm树的两个连续级别的独立区段对上，所以压缩任务在这些区段对的粒度上理论上能并行的</strong>。因此，它可以被分割成多个小任务。我们把这样小的任务放到 FPGA 上，并以流的方式处理它们。每个压缩区段都被传输回磁盘。通过这样的加载，<strong>CPU 线程从合并区段的沉重负担中得到释放。因此，我们能够分配更多的线程来处理并发事务</strong>。这种基于 FPGA 的压实加速的细节超出了本文的范围，将另行探讨。</p>
</li>
</ul>
<h5 id="scheduling-compactions">Scheduling compactions</h5>
<ul>
<li>LSM 树依赖于压缩来按已排序的顺序保存记录，并从存储中删除标记为要删除的记录。如果不及时删除已删除的记录，查找查询可能不得不遍历存储中的许多无效记录，从而严重损害读性能。压缩还有助于合并Level0中的子级别，以降低该级别的查找成本。在X-Engine中，我们<strong>引入了基于规则的压缩调度</strong>，以利用这些好处。我们根据压实操作的层次来区分压实:
<ul>
<li>intra-Level0 压缩(合并Level0中的子层)</li>
<li>minor 压缩(合并两个相邻的层，除了最大的层)</li>
<li>major 压缩(合并最大的层和它上面的层)</li>
<li>self-major 压缩(合并最大的层以减少碎片和删除记录)。</li>
</ul>
</li>
<li>当一个级别的总大小或区段总数达到预定义的阈值时，就会触发压缩。<strong>所有触发的压缩作业都被放入一个优先队列</strong>。确定优先级的规则对配置是开放的，这进一步取决于数据库之上的不同应用程序的需求。</li>
<li>下面，我们将展示一个为阿里巴巴的一个在线应用程序量身定制的配置示例。在这个应用程序中，<strong>有频繁的删除。当应该删除的记录数量达到其阈值时，就会触发压缩以删除这些记录，并且这种压缩具有最高优先级，以防止存储空间的浪费。删除之后，Level0 内部的压缩被优先排序，以帮助加速查找 Level0 中最近插入的记录。Minor、major 和 self-major compaction 分别按此顺序排列</strong>:
<ul>
<li>(1) Compactions for deletions.</li>
<li>(2) Intra-Level0 compactions.</li>
<li>(3) Minor compaction.</li>
<li>(4) Major compaction.</li>
<li>(5) Self-major compactions.</li>
</ul>
</li>
<li>可以对不同子表以及不同 LSM 树的压缩进行并发执行调度。这种并行性是理想的，因为子表之间的数据独立。在每个子表中，一次只执行一个压缩。虽然可以对同一lsm -树执行多个压缩，而不会损坏数据或导致任何数据竞争，但我们有足够的机会在子表级别进行并发压缩，以提高性能。</li>
</ul>
<h2 id="related-work">Related Work</h2>
<ul>
<li></li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[Cache Replacement Policies - Fine-Grained Other]]></title>
        <id>https://blog.shunzi.tech/post/CRP-Fine-Grained-Three-Other/</id>
        <link href="https://blog.shunzi.tech/post/CRP-Fine-Grained-Three-Other/">
        </link>
        <updated>2021-08-20T09:40:00.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>Cache Replacement Policies - Fine-Grained Other</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>Cache Replacement Policies - Fine-Grained Other</li>
</ul>
</blockquote>
<!-- more -->
<h3 id="other-prediction-metrics">OTHER PREDICTION METRICS</h3>
<ul>
<li>并非所有细粒度策略都预测重用距离或二分标签，当然可以使用不同的预测目标捕获过去的行为。例如，Kharbutli 和 Solihin[2005] 死块预测器的一个组件可以<strong>预测一个缓存行在缓存中被重用的最大次数</strong>。作为这类解决方案的一个例子，我们现在详细讨论 <strong>EVA 策略</strong> [Beckmann和Sanchez, 2017]，它引入了一种新的预测目标，称为 EVA，这是少数几个使用历史信息来指导老化过程的细粒度解决方案之一。</li>
</ul>
<h4 id="economic-value-addedeva">ECONOMIC VALUE ADDED(EVA)</h4>
<ul>
<li>贝克曼和桑切斯认为，只有当我们对未来拥有完美的知识时，用预期时间最长的候选人替代重用是最优的 [Belady, 1966]，但这一策略对于面临未来固有不确定性的实际解决方案是不够的 [Beckmann和桑切斯，2017]。因此，实际的解决方案需要平衡两个相互竞争的目标:
<ul>
<li>(1) <strong>最大限度地提高给定行的命中缓存的概率</strong>，</li>
<li>(2) <strong>限制该行消耗缓存空间的持续时间</strong>。</li>
</ul>
</li>
<li>仅仅基于重用距离的解决方案只考虑了权衡的一方面。</li>
<li>为了解决这一限制，Beckmann 和 Sanchez[2017] 提出了一个称为经济附加值(EVA)的新指标，将这两个因素合并为一个单一指标。<strong>EVA 被定义为候选对象可能产生的命中数与其在缓存中的平均占用率的比值</strong>。方程 (4.1) 表明 EVA 是对给定缓存行计算的。我们看到一个缓存行的 EVA 有两个组成部分。首先，该行将因其预期的未来命中次数而获得奖励(具有较高重用概率的该行将具有较高的EVA值)。其次，这一行会因为它所消耗的缓存空间而受到惩罚。这个惩罚是通过对每个候选对象在缓存中花费的时间进行收费来计算的，收费的速率是一行的平均命中率(缓存命中率除以其大小)，这是消耗缓存空间的长期机会成本。因此，EVA 指标通过计算该行命中的几率是否值得它所消耗的缓存空间来获取缓存行的成本效益权衡。$$ EVA = Expected_hits - (Cache_hit_rate / Cache_size) * Expected_time$$</li>
<li>候选人的 EVA 是从他们的年龄推断出来的，并随着候选人的年龄进行修正。例如，左边的图4.6 显示了 EVA 是如何随着候选应用程序年龄的变化而变化的，该应用程序遍历一个小数组和一个大数组(右边显示了同一应用程序的重用距离分布)。首先，EVA 较高，因为访问很有可能来自一个小数组，这意味着替换策略可以赌候选者会很快命中。但是，当年龄超过短数组的长度时，EVA 急剧下降，因为从大数组缓存行的代价要高得多。此时，低 EVA 使大数组中的行很可能被逐出。缓存来自大数组的行所带来的代价随着行的老化和接近大数组的重用距离而降低。这种惩罚反映在年龄从 50 岁到 250 岁的 EVA 逐渐增加，在这一点上 EVA 替换策略保护缓存行免受大数组替代，即使它们是老的。因此，在面临不确定性时，EVA 替代策略会随着候选人年龄的增长而对他们有更多的了解。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821160012.png" alt="20210821160012" loading="lazy"></li>
<li>当然，<strong>另一种减少不确定性的方法是将缓存行分为不同的类别</strong>。例如，如果我们将小数组和大数组划分为不同的类别，图 4.7 显示了与年龄相关的 EVA，我们可以看到每个类别的 EVA 曲线要简单得多。理论上，可以扩展 EVA 以支持分类，但实现的复杂性将这种扩展限制在少数类。在下一节中，我们将讨论依赖于许多细粒度类的替换策略，但学习每个类的更简单的指标。相比之下，EVA 以细粒度对年龄进行排序，但这限制了 EVA 使用更少的类。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821160331.png" alt="20210821160331" loading="lazy"></li>
<li>EVA 替换策略通过记录命中和驱逐的年龄分布并使用轻量级软件运行时处理有关这些驱逐的信息来计算 EVA 曲线。为了预测一条缓存行的 EVA，将其年龄作为索引，建立一个代表 EVA 曲线的驱逐优先级数组。</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[Cache Replacement Policies - Fine-Grained Classification]]></title>
        <id>https://blog.shunzi.tech/post/CRP-Fine-Grained-Two-Classification/</id>
        <link href="https://blog.shunzi.tech/post/CRP-Fine-Grained-Two-Classification/">
        </link>
        <updated>2021-08-20T08:40:00.000Z</updated>
        <summary type="html"><![CDATA[<blockquote>
<ul>
<li>Cache Replacement Policies - Fine-Grained Classification</li>
</ul>
</blockquote>
]]></summary>
        <content type="html"><![CDATA[<blockquote>
<ul>
<li>Cache Replacement Policies - Fine-Grained Classification</li>
</ul>
</blockquote>
<!-- more -->
<h3 id="classification-based-policies">CLASSIFICATION-BASED POLICIES</h3>
<ul>
<li><strong>基于分类的策略学习了传入行的二分类：缓存访问是否可能导致未来的命中？</strong> 对缓存友好的行，预期会导致缓存命中的行以更高的优先级插入缓存，以便它们有足够的机会接收缓存命中，而不喜欢缓存的行(不期望缓存命中的行)则以较低的优先级插入，这样它们就可以在不浪费缓存资源的情况下被快速清除。</li>
<li>与其他类替换策略相比，基于分类的策略有几个优点。与混合替换策略对给定时间段内的所有行进行统一决策相比，<strong>基于分类的替换策略可以插入一些高优先级的行和一些低优先级的行</strong>。与基于重用距离的策略(目标是数值的重用距离预测)相比，<strong>基于分类的策略解决了一个更简单的二分预测问题</strong>。</li>
<li>正如我们将看到的，基于分类的政策起源于两种不同的文献。<strong>基于采样的死块预测器(SDBP)</strong> [Khan等人，2010] (章节4.2.1) 建立在死块预测文献的基础上，而<strong>基于签名的命中预测 (SHiP)</strong> [Wu等人，2011a] (章节4.2.2)则来源于缓存替换策略文献。有趣的是，这两种解决方案都得到了概念上相似的想法，而且事后看来，这两篇论文共同统一了这两个领域。</li>
<li>现在我们将讨论这些和其他最近的基于分类的策略。虽然这些政策之间存在显著差异，但它们都有两个特点。
<ul>
<li>首先，它们<strong>都包含一个二分预测器</strong>，该预测器可以学习过去的缓存行为，以指导各个行的插入优先级。</li>
<li>其次，他们<strong>都从最先进的粗粒度政策中借鉴了 Promotion、老化 和 驱逐模式，这有助于解释不准确的预测</strong>。</li>
</ul>
</li>
<li>在描述这些策略时，我们将考虑以下设计问题。
<ul>
<li>哪种缓存解决方案是策略学习？</li>
<li>预测机制是什么，预测的粒度是什么？</li>
<li>是什么老化机制确保不准确的预测最终被淘汰？</li>
</ul>
</li>
</ul>
<h4 id="sampling-based-dead-block-prediction-sdbp">SAMPLING BASED DEAD BLOCK PREDICTION (SDBP)</h4>
<ul>
<li>许多研究发现，由于LLC中的大部分块都是死块(它们在被驱逐之前不会再次重用)，<strong>死块预测可以用来指导缓存替换和死块的早期旁路（旁路即为不缓存）</strong> [Khan等人，2010,Lai和Falsafi, 2000]。Lai 和 Falsafi[2000] 引入了使用死块预测器将数据预取到 L1 中的死块的思想。他们的 reftrace 预测器预测，如果指令地址的 trace 导致最后一次访问一个块，那么同样的 trace 也会导致最后一次访问其他块。为了降低为所有缓存块维护指令跟踪的成本，Khan 等人[2010] <strong>引入了基于采样的死块预测器(SDBP)，它对程序计数器(PC)的缓存行为进行采样，以确定传入的块是否可能 dead</strong>。来自已知插入死块的 PC 的未来缓存访问被 Bypass，这样他们就不会污染缓存。来自没有插入死块的 PC 的访问将使用一些基本策略(即随机或 LRU 替换策略)插入缓存。</li>
<li>值得注意的是，<strong>SDBP 从使用一小部分缓存访问填充的解耦采样器学习</strong>(参见图4.2)。如果一个块被从采样器中移除而不被重用，则对相应的 PC 进行负向训练；否则，预测器被积极训练。解耦采样器有几个优点：
<ul>
<li>首先，只使用所有缓存访问的一小部分样本来训练预测器，这导致了功率和空间效率高的预测器设计和采样器中易管理的元数据(为每个采样器条目维护 PC)。</li>
<li>其次，采样器的替换策略不必与缓存的替换策略相匹配。Khan 等人[2010] 对采样器使用 LRU 策略，他们对主缓存使用随机替换。</li>
<li>最后，采样器的结合性独立于缓存的结合性，这允许开销更小的采样器设计。Khan 等人使用 12 路采样器作为 16 路缓存。表 4.1 总结了SDBP的关键操作。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821115233.png" alt="20210821115233" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821115325.png" alt="20210821115325" loading="lazy"></li>
</ul>
</li>
<li>因此，为了回答我们在本节开始时概述的问题:
<ul>
<li>(1) SDBP 学习基于 LRU 的采样器的缓存决策;</li>
<li>(2) 它预测死块(缓存厌恶与缓存友好) 使用一个倾斜的预测器设计，以 PC 的粒度进行这些预测;</li>
<li>(3) SDBP 绕过所有预测为缓存厌恶的传入块，使用基线替换策略管理剩余的行，因此假阳性(预测为缓存友好的缓存厌恶块)使用基线替换策略老化，而假阴性(缓存友好的块被预测为缓存厌恶)没有任何机会重用。</li>
</ul>
</li>
</ul>
<h4 id="signature-based-hit-prediction-ship">SIGNATURE BASED HIT PREDICTION (SHIP)</h4>
<ul>
<li>像 SDBP 一样，<strong>SHiP</strong> [Wu et al.， 2011a] 学习了底层替换策略的淘汰行为，但 SHiP 背后的主要观点是，<strong>重用行为与将该行插入缓存的 PC 更紧密相关，而不是与最后访问该行的 PC</strong>。因此，在缓存淘汰时，SHiP 的预测器被 PC 训练，PC 首先在缓存丢失时插入该行，预测器只在缓存 MISS 时被咨询(在命中时，行被提升到最高优先级而不咨询预测器)。</li>
<li>更具体地说，SHiP 训练一个预测器，它可以学习给定的签名是否具有近或远的重引用间隔。<strong>在缓存中采样一些集合以维护签名和训练预测器。在一个采样集中的缓存命中，与这条缓存行相关联的签名被训练为正，以指示一个近重引用，而在驱逐一条从未被重用的行时，该签名被训练为负，以指示一个远重引用</strong>。当插入新行时，将使用传入行的签名来咨询预测器，并确定传入行的重新引用间隔(对所有访问执行预测，而不仅仅是对采样集)。一旦插入到缓存中，行就使用一个简单的 RRIP 策略进行管理(参见表4.2)。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821115906.png" alt="20210821115906" loading="lazy"></li>
<li>签名的选择对 SHiP 的有效性至关重要。Jaleel 等人 [2010b] 评估了一个程序计数器签名(PC)、一个内存区域签名和一个指令序列历史签名，他们发现 <strong>PC 签名性能最好</strong>。</li>
<li>SHiP 基于 DRRIP [Jaleel et al.，2010b] 创建细粒度策略。<strong>DRRIP 对 epoch 中的所有缓存行进行统一的重新引用预测，而 SHiP 进行更细粒度的预测：它通过将每个引用与一个唯一的签名关联起来，将传入行的分类到不同的组中。</strong> 假设具有相同签名的缓存行具有相似的重引用行为，但允许具有不同签名的缓存行在同一 epoch 内具有不同的重引用行为。</li>
<li>现在我们回答本节开始时提到的问题。
<ul>
<li>(1) 最初，SHiP 从 SRRIP 中学习，但一旦 SHiP 的预测器被训练，进一步的训练更新来自 SHiP 自身的重用和驱逐行为。</li>
<li>(2) SHiP 使用基于 PC 的预测器，其中与一行相关联的 PC 就是插入一行缓存 miss 的 PC，其中每个 PC 与一个饱和计数器相关联。</li>
<li>(3) SHiP 依靠 RRIP 政策来老化所有行。</li>
</ul>
</li>
</ul>
<h4 id="hawkeye">HAWKEYE</h4>
<ul>
<li>为了避免基于启发式的解决方案(如LRU)的病态，Hawkeye [Jain和Lin, 2016] 构建了 Belady 的 MIN 解[Belady, 1966]，这是有趣的两个原因。
<ul>
<li>首先，Belady 的 MIN 对于任何引用序列都是最优的，因此基于 MIN 的解决方案可能适用于任何访问模式。</li>
<li>其次，Belady 的 MIN 算法是一种不切实际的算法，因为它替换了将来重复使用最多的行；因此，它依赖于未来的知识。</li>
</ul>
</li>
<li>Hawkeye 的核心见解是，<strong>虽然无法预测未来，但可以将 Belady 的 MIN 算法应用到过去的内存引用中。此外，如果一个程序过去的行为是它未来行为的一个很好的预测器，那么通过学习过去的最优解，Hawkeye 可以训练一个预测器，它应该在未来访问中表现良好</strong>。</li>
<li>为了理解模拟过去事件的 MIN 需要多少历史信息，Jain 和 Lin[2016] 通过限制其未来的窗口来研究 MIN 的性能。图 4.3 显示，虽然 MIN 需要一个很长的窗口到未来(SPECint 2006的 8x 缓存大小)，但它不需要一个无边界窗口。因此，要将 MIN 应用到过去的事件，我们需要一个缓存大小为 8x 的历史记录。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821124850.png" alt="20210821124850" loading="lazy"></li>
<li>由于维持缓存大小 8x 的历史信息开销巨大，Hawkeye 只计算几个抽样集的最优解，并<strong>引入 OPTgen 算法，为这些抽样集计算与 Belady 的 MIN 策略相同的答案</strong>。<strong>OPTgen 确定如果使用 MIN 策略将被缓存的行</strong>。OPTgen 背后的关键观点是，<strong>当一行再次被重用时，可以准确地确定该行的最佳缓存决策</strong>。因此，在每次重用时，OPTgen 都会回答以下问题: 这一行是否会在 MIN 情况下是缓存命中还是缓存丢失？这种洞察力使得 OPTgen 能够使用少量的硬件预算和简单的硬件操作，以 O(n) 复杂性再现 Belady 的解决方案。</li>
<li>图4.4 显示了 Hawkeye 替换策略的总体设计。OPTgen 训练 Hawkeye 预测器，这是一种基于 PC 的预测器，它可以了解 PC 插入的行是倾向于缓存友好型还是缓存反对型。当 OPTgen 确定一条行将被 MIN 命中时，该行对应的 PC 被正训练，否则被负训练。每次使用传入行的 PC 进行缓存插入和提升时，都会参考预测器。被预测为缓存友好的行将以高优先级插入，而被预测为缓存厌恶的行将以低优先级插入(参见表4.3)。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821125001.png" alt="20210821125001" loading="lazy"><br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821125202.png" alt="20210821125202" loading="lazy"></li>
<li>回答本节开头的问题:
<ul>
<li>(1) Hawkeye 从最优缓存解决方案中学习，而不是从 LRU 或 SRRIP 中学习；</li>
<li>(2) Hawkeye 使用基于 PC 的预测器学习最优解;</li>
<li>(3) Hawkeye 还依赖于 RRIP 的老化机制，以高优先级插入 age line。为了纠正不准确的预测，Hawkeye 还对预测器进行负训练，当预测到不喜欢缓存的行被取消而没有被重用时。</li>
</ul>
</li>
<li>Hawkeye 在概念上做出了一个有趣的贡献: <strong>它将缓存替换描述为一个有监督的学习问题</strong>，这令人惊讶，因为不像分支预测，程序执行最终提供每个分支的正确结果，硬件缓存不提供这样的标记数据。通过对过去事件应用最优解决方案，Hawkeye 提供了标记数据，这<strong>表明缓存替换领域可能会从监督学习的大量研究中受益</strong>。</li>
</ul>
<h4 id="perceptron-based-prediction">PERCEPTRON-BASED PREDICTION</h4>
<ul>
<li>预测性策略在很大程度上取决于预测者的准确性。<strong>SDBP、SHiP 和 Hawkeye 都使用基于 PC 的预测器，准确率约为 70 - 80%</strong>。Jiménez 和 Teran 旨在通过使用更好的特征和更好的预测模型来提高预测精度 [Jiménez和Teran, 2017, Teran等人，2016]。例如,<strong>感知器预测 [Teran et al., 2016] 使用简单的人工神经网络 [Rosenblatt, 1962]，以增加使用带有更丰富的特性的 PC</strong> ，如 (1) PCs 历史信息，(2) 来自内存地址的位，(3) 数据的压缩表示，和(4) 一个块被访问的次数。每个特征被用来索引一个不同的饱和计数器表，然后求和并与一个阈值进行比较，生成一个二分预测。一小部分的访问被采样以使用感知器更新策略更新感知器预测器：如果预测是错误的，或者如果总和没有超过某个大小，那么计数器在访问时减少，在驱逐时增加。图 4.5 对比了感知器预测器(右)和先前基于 PC 的预测器(左)。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821140306.png" alt="20210821140306" loading="lazy"></li>
<li>Multiperspective Reuse Predictor [Jiménez和Teran, 2017] 探索了一组广泛的特性，这些特性捕获了程序的各种属性，生成了一个从多个角度获得信息的预测器。特征被参数化，包含了关于每个训练输入的 LRU 堆栈位置、每个特征被哈希的 PC 位和 PC 历史的长度的更丰富的信息。这些参数一起创建了一个大的特征空间，从而导致更高的预测精度。</li>
</ul>
<h4 id="evicted-address-filtereaf">EVICTED ADDRESS FILTER(EAF)</h4>
<ul>
<li><strong>EAF 策略</strong> [Seshadri等人，2012] <strong>单独预测每个缺失块的重用行为，允许比 PC 更细粒度的差异</strong>。关键的观察是，如果一个高重用的块被过早地从缓存中逐出，那么它将在逐出后不久被访问，而低重用的块在逐出后很长一段时间内都不会被访问。因此，<strong>EAF 策略使用 bloom 过滤器</strong> [bloom, 1970] (一种概率性的、空间效率高的结构，用于确定集合中某个元素的存在或缺失) <strong>来跟踪一小组最近被驱逐的地址</strong>。在<strong>缓存丢失时，如果新行出现在 bloom 过滤器(也称为逐出地址过滤器)中，那么预测该行是重用友好的，并以高优先级插入</strong>; 否则，<strong>根据双峰插入策略 the Bimodal Insertion policy 插入新行</strong>(参见3.1.2节)。当 <strong>bloom 过滤器满时，它被重置</strong>。EAF 在概念上类似于一个小型的候选缓存，它跟踪最近从主缓存中删除的行。表 4.4 总结了 EAF 策略的操作。<br>
<img src="https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210821154831.png" alt="20210821154831" loading="lazy">
<ul>
<li><strong>回顾一下 BIP，双峰插入策略，本质是使缓存行以较低的一个概率插入到 MRU 的位置。BIP 保持 LIP 的抗抖动，因为它在大多数时间插入 LRU 位置，但它也可以通过偶尔保留较新的行来适应阶段变化。</strong></li>
</ul>
</li>
<li>从概念上讲，EAF 策略延长了缓存行的生存期，超过了淘汰时间，因此一行的生存期从它的插入开始，但当该行从 bloom 过滤器中删除时结束。随着生命周期的延长，对于具有较长重用间隔的行，EAF 观察重用变得可行，从而获得更好的抗扫描能力和抗抖动能力，从而获得更好的性能。</li>
<li><strong>重用检测器 (ReD)</strong> [crc, 2017, Albericio等人，2013] 提出了类似的想法，因为它<strong>绕过 LLC 或地址重用表中没有击中的任何缓存行，跟踪最近的缓存丢失。因此，ReD 只在第二次重用时将行插入缓存中</strong>。为了避免在第一次看到所有行时绕过它们，ReD 还使用基于 PC 的预测器来预测在第一次访问后可能被重用的行。</li>
</ul>
]]></content>
    </entry>
</feed>