LevelDB 中，内存表中的键值对在到达一定大小后，会落到磁盘文件 SSTable 中。并且磁盘文件也是分层的，每层包含多个 SSTable 文件，在运行时，LevelDB 会在适当时机，合并、重整 SSTable 文件，将数据不断往下层沉淀。这里 SSTable 有一套组织数据的格式，目的就是保证数据有序，并且能快速查找。那么 SSTable 内部是怎么存储这些键值对的，又是怎么提高数据的读、写性能的。以及整个 SSTable 文件的实现中有哪些优化点？本文接下来我们会仔细分析 SSTable 文件的创建过程，一步步拆解来看看这里到底怎么实现的。在开始之前，我先给一个大的图，大家可以先留个印象。SSTable 文件格式设计原因在开始之前，我们要先搞明白一个关键问题，文件格式该如何设计，才能兼顾高效写入和快速读取？下面我们从几个基本问题出发，来推测作者是如何设计这里的数据格式。问题一：键值对该如何存放？首先，最核心的数据，也就是用户的键值对，得有个地方放。最简单的方法，把所有键值对按顺序放进 SSTable 这整个大文件。这样有什么问题呢？首先读的时候，如果要找一个 key，需要遍历整个大文件。然后写入过程中，每次添加一个键值对就要写磁盘的话，写 IO 压力会很大，吞吐上不去。既然太大了不行，那就分块吧。计算机科学中的”分而治之”思想，在 LevelDB 中得到了很好的体现。我 ...继续阅读 (2)

计算机系统中，缓存无处不在。从 CPU 缓存到内存缓存，从磁盘缓存到网络缓存，缓存无处不在。缓存的核心思想就是空间换时间，通过将热点数据缓存到高性能的存储中，从而提高性能。因为缓存设备比较贵，所以存储大小有限，就需要淘汰掉一些缓存数据。这里淘汰的策略就非常重要了，因为如果淘汰的策略不合理，把接下来要访问的数据淘汰掉了，那么缓存命中率就会非常低。缓存淘汰策略有很多种，比如 LRU、LFU、FIFO 等。其中 LRU(Least Recently Used) 就是一种很经典的缓存淘汰策略，它的核心思想是：当缓存满了的时候，淘汰掉最近最少使用的数据。这里基于的一个经验假设就是”如果数据最近被访问过，那么将来被访问的几率也更高“。只要这个假设成立，那么 LRU 就可以显著提高缓存命中率。在 LevelDB 中，实现了内存中的 LRU Cache，用于缓存热点数据，提高读写性能。默认情况下，LevelDB 会对 sstable 的索引 和 data block 进行缓存，其中 sstable 默认是支持缓存 990 (1000-10) 个，data block 则默认分配了 8MB 的缓存。LevelDB 实现的 LRU 缓存是一个分片的 LRU，在细节上做了很多优化，非常值得学习。本文将从经典的 LRU 实现思路出发，然后一步步解析 LevelDB 中LRU Cache的实现细节。经典的 ...继续阅读 (22)

在 LevelDB 中，所有的写操作首先都会被记录到一个Write-Ahead Log（WAL，预写日志）中，以确保持久性。接着数据会被存储在 MemTable 中，MemTable 的主要作用是在内存中有序存储最近写入的数据，到达一定条件后批量落磁盘。LevelDB 在内存中维护两种 MemTable，一个是可写的，接受新的写入请求。当达到一定的大小阈值后，会被转换为一个不可变的 Immutable MemTable，接着会触发一个后台过程将其写入磁盘形成 SSTable。这个过程中，会创建一个新的 MemTable 来接受新的写入操作。这样可以保证写入操作的连续性，不受到影响。在读取数据时，LevelDB 首先查询 MemTable。如果在 MemTable 中找不到，然后会依次查询不可变的 Immutable MemTable，最后是磁盘上的 SSTable 文件。在 LevelDB 的实现中，不管是 MemTable 还是 Immutable MemTable，内部其实都是用 class MemTable 来实现的。这篇文章我们来看看 memtable 的实现细节。Memtable 使用方法先来看看 LevelDB 中哪里用到了 MemTable 类。在库的核心 DB实现类 DBImpl中，可以看到有两个成员指针，12345678classDBImpl:publicDB & ...继续阅读 (20)

在数据库系统中，并发访问是一个常见的场景。多个用户同时读写数据库，如何保证每个人的读写结果都是正确的，这就是并发控制要解决的问题。考虑一个简单的转账场景，开始的时候 A 账户有 1000 元，要转 800 元给 B 账户。转账过程包括两步：从 A 扣钱，给 B 加钱。恰好在这两步中间，有人查询了 A 和 B 的余额。如果没有任何并发控制，查询者会看到一个异常现象：A 账户已经被扣除了 800 元，只剩 200 元，B 账户还没收到转账，还是原来的金额！这就是典型的数据不一致问题。为了解决这个问题，数据库系统需要某种并发控制机制。最直观的解决方案是加锁，当有人在进行写操作（如转账）时，其他人的读操作必须等待。回到前面的问题，只有在转账的两步都完成之后，才能查到正确的账户余额。但是锁机制存在明显的问题，每次只要写相关 key，所有读该 key 的操作都要排队等待，导致并发上不去，性能会比较差。现代数据库系统普遍采用 MVCC 来控制并发，LevelDB 也不例外，接下来我们结合源码来理解 LevelDB 的 MVCC 实现。通过 MVCC 控制并发MVCC(Multi-Version Concurrency Control) 是一种并发控制机制，它通过维护数据的多个版本来实现并发访问。简单来说，LevelDB 的 MVCC 实现关键点有下面几个：每个 key 可以有多个版本，每个版本都 ...继续阅读 (23)

大语言模型刚出来的时候，只是通过预训练的模型来生成回答内容。这个时候的模型有两个主要的缺点：有些数据它不知道，比如 2024 年 3 月训练的模型，就不知道 2024 年 5 月的事情；没法使用外部工具。这里的工具我们可以等效理解为函数调用，比如我有个发表文章的工具函数，我没法用自然语言让大模型来帮我调用这个函数。为了解决这两个问题，OpenAI 最先在模型中支持了function calling功能，他们在这篇博客:Function calling and other API updates有介绍。背景：理解 Function Calling这时候，我们就可以告诉模型，我有这么几个工具，每个工具需要什么参数，然后能做什么事情，输出什么内容。当模型收到具体任务的时候，会帮我们选择合适的工具，并解析出参数。之后我们可以执行相应的工具，拿到结果。并可以接着循环这个过程，让 AI 根据工具结果继续决定往下做什么事情。我在网上找了个动图，可以来理解下有了 function calling 后，做事情的流程：当然这里大模型只是根据我们给的工具列表，选择合适的工具，并解析出参数。它不能直接去调用工具，我们需要编程实现工具调用部分，可以参考 OpenAI 的Function calling 文档。为什么又引入了 MCP只有 function calling 已经能做很多事了，派生了不少有意思的项 ...继续阅读 (35)

读、写键值是 KV 数据库中最重要的两个操作，LevelDB 中提供了一个 Put 接口，用于写入键值对。使用方法很简单：12leveldb::Status status = leveldb::DB::Open(options,"./db", &db;);status = db->Put(leveldb::WriteOptions(), key, value);LevelDB 最大的优点就是写入速度也非常快，可以支持很高的并发随机写。官方给过一个写入压力测试结果：1234fillseq : 1.765 micros/op; 62.7 MB/sfillsync : 268.409 micros/op; 0.4 MB/s (10000 ops)fillrandom : 2.460 micros/op; 45.0 MB/soverwrite : 2.380 micros/op; 46.5 MB/s可以看到这里不强制要求刷磁盘的话，随机写入的速度达到 45.0 MB/s，每秒支持写入 40 万次。如果强制要求刷磁盘，写入速度会下降不少，也能够到 0.4 MB/s, 每秒支持写入 3700 次左右。这里 Put 接口具体做了什么？数据的写入又是如何进行的？LevelDB 又有哪些优化 ...继续阅读 (28)

LevelDB 支持写入单个键值对和批量写入多个键值对，这两种操作的处理流程本质上是相同的，都会被封装进一个 WriteBatch 对象中，这样就可以提高写操作的效率。在 LevelDB 中，WriteBatch 是通过一个简单的数据结构实现的，其中包含了一系列的写入操作。这些操作被序列化（转换为字节流）并存储在内部的一个字符串中。每个操作都包括操作类型（如插入或删除），键和值（对于插入操作）。当 WriteBatch 被提交给数据库时，其内容被解析并应用到 WAL 日志和 memtable 中。不管 WriteBatch 中包含多少操作，它们都将作为一个整体进行处理和日志记录。WriteBatch 的实现主要涉及到 4 个文件，接下来一起看看。include/leveldb/write_batch.h：对外暴露的接口文件，定义了 WriteBatch 类的接口。db/write_batch_internal.h：内部实现文件，定义了 WriteBatchInternal 类，提供了一些操作 WriteBatch 的方法。db/write_batch.cc：WriteBatch 类的实现文件，实现了 WriteBatch 类。db/write_batch_test.cc：WriteBatch 类的测试文件，用于测试 WriteBat ...继续阅读 (30)

只要你写过比较复杂的 C++ 项目，应该都或多或少遇见过进程 Coredump 的问题。Coredump 是程序运行过程中发生严重错误时，操作系统将程序当前的内存状态记录下来的一种机制。C++ 中导致进程 Coredump 的原因有很多，比如：访问非法内存地址：包括空指针解引用、访问已释放的内存、数组越界访问等；栈溢出：无限递归、大数组分配在栈上；段错误（Segmentation Fault）：试图写入只读内存、访问未映射的内存区域；异常未捕获：未处理的异常导致程序终止；遇到 Coredump 问题时，一般需要打开 core 文件，然后根据 core 文件来进行问题分析和调试。分析 core 文件有时候还是比较难的，需要对 C++ 的内存模型、异常处理机制、系统调用等有深入的理解。本文不会过多介绍分析 core 文件的方法，而是通过几个真实项目中的案例，来让大家在写代码时候，能够有意识地避免这些错误。抛异常没有捕获业务代码中最常见的导致进程 crash 的原因，就是不小心抛出异常却没有捕获。比如一个字符串转整数的函数中，用了std::stoi来转换。但是这里万一字符串没法转成数字，就会抛出std::invalid_argument异常。如果框架层或者调用方没有捕获异常，就会导致进程 crash 掉。就拿标准库来说，可能抛出异常的函数还是挺多的，常见的有：std::vector::a ...继续阅读 (32)

LevelDB 中有一些宏比较有意思，平时自己写代码的时候，还基本没用过。这些宏在thread_annotations.h中定义，可以在编译时使用 Clang 编译器的线程安全分析工具，来检测潜在的线程安全问题。比如下面这些宏，到底有什么作用呢？本文就一起来看看吧。1234GUARDED_BY(x)// 表示变量必须在持有锁x时才能访问PT_GUARDED_BY(x)// 指针类型的 GUARDED_BYACQUIRED_AFTER(...)// 指定锁的获取顺序，防止死锁// ...GUARDED_BY 锁保护在很多类的成员变量定义中，都有GUARDED_BY(mutex_)这样的注解，有什么作用呢？比如 LRU Cache 的定义：1234567891011classLRUCache{public:// ...private:// ...mutableport::Mutex mutex_;size_tusage_GUARDED_BY(mutex_);// ...HandleTable table_GUARDED_BY(mutex_);};其实这就是 Clang 的线程安全注解，编译的时候，Clang 会检查所有对usage_和table_的访问是否都在持有mutex_锁的情况下进行。另外，在函数或代码块结束时，编译器还会检查所有应该释放的锁是否都已经释放，可 ...继续阅读 (40)

哈希表(HashTable) 是一个经典的数据结构，只要写点过代码，应该都有用过哈希表。每种语言都有自己的哈希表实现，基本都是开箱即用。以至于虽然用过哈希表的人很多，但自己动手写过哈希表的人估计没多少吧。要设计一个高性能的哈希表，其实还是有不少细节需要考虑的。比如如何处理哈希冲突，如何处理哈希表扩容等。一些成熟的哈希表实现，比如 C++ 标准库中的哈希表，代码量比较大，也比较难理解。好在 LevelDB 在实现 LRU Cache 的时候，顺便实现了一个简单高效的哈希表，整体代码写的很精简，麻雀虽小五脏俱全，非常值得学习。本文以 LevelDB 的哈希表实现为例，分析下如何设计一个高性能的哈希表。LevelDB 实现哈希表的原因C++ 标准库已经有了哈希表实现，为什么 LevelDB 还要实现一个自己的哈希表呢？官方是这样说的：We provide our own simple hash table since it removes a whole bunchof porting hacks and is also faster than some of the built-in hashtable implementations in some of the compiler/runtime combinationswe have tested. E.g., read ...继续阅读 (40)

在上篇LevelDB 源码阅读：跳表的原理、实现以及可视化中，详细分析了 LevelDB 中跳表的实现。然后在LevelDB 源码阅读：如何正确测试跳表的并行读写？中，分析了 LevelDB 跳表的测试代码，最后还剩下一个问题，怎么分析跳表的时间复杂度呢？在分析完跳表的时间复杂度之后，就能明白 LevelDB 中概率值和最大高度的选择，以及 Redis 为什么选择不同的最大高度。最后本文也会提供一个简单的压测代码，来看看跳表的性能如何。本文不会有很高深的数学知识，只涉及简单的概率论，可以放心往下看。跳表的性能分析有不少思路很值得借鉴，希望本文能抛砖引玉，给大家带来一些启发。跳表性能分析拆解在知道 LevelDB 的原理和实现后，我们可以推测出来，在极端情况下，每个节点的高度都是 1，那么跳表的查找、插入、删除操作的时间复杂度都会退化到 O(n)。在这种情况下，性能比平衡树差了不少。当然，因为有随机性在里面，所以没有输入序列能始终导致性能最差。那么跳表的平均性能如何呢？前面给出过结论，和平衡树的平均性能差不多。引入一个简单的随机高度，就能保证跳表的平均性能和平衡树差不多。这背后有没有什么分析方法，能够分析跳表的性能呢？还得看论文，论文中给出了一个不错的分析方法，不过这里的思路其实有点难想到，理解起来也有点费劲。我会把问题尽量拆分，然后一步步来推导整个过程，每一步涉及到的数学推导也尽量 ...继续阅读 (78)

在上篇LevelDB 源码阅读：跳表的原理、实现以及可视化中，从当前二叉搜索树和平衡树的一些缺点出发，引出了跳表这种数据结构。然后结合论文，解释了跳表的实现原理。接着详细分析了 LevelDB 的代码实现，包括迭代器实现，以及并行读的极致性能优化。最后还提供了一个可视化页面，可以直观看到跳表的构建过程。但是还有两个问题：怎么测试 LevelDB 跳表的代码，保证功能的正确性？特别是怎么保证读写并行情况下跳表实现的正确性。怎么定量分析跳表的时间复杂度？接下来通过分析 LevelDB 的测试代码，先来回答第一个问题。跳表的性能定量分析，放到另外单独一篇文章。跳表测试分析上篇文章分析了 LevelDB 跳表的实现，那么这里的实现是否正确呢？如果要写测试用例，应该怎么写？需要从哪些方面来测试跳表的正确性？我们看看 LevelDB 的测试代码skiplist_test.cc。首先是空跳表的测试，验证空跳表不包含任何元素，检查空跳表的迭代器操作 SeekToFirst, Seek, SeekToLast 等。接着是插入、查找、迭代器的测试用例，通过不断插入大量随机生成的键值对，验证跳表是否正确包含这些键，以及测试迭代器的前向和后向遍历。123456TEST(SkipTest, InsertAndLookup) {// 测试插入和查找功能// 插入随机生成的键值对// 验证跳表正确包含 ...继续阅读 (76)

OpenAI 半夜悄咪咪推出了新的模型，introducing-openai-o1-preview。放出了系列视频，展示新模型的强大，网上也是普天盖地的文章来讲新模型测评有多厉害。不过见惯了 AI 界的放卫星，怀着怀疑的态度，第一时间上手体验一把。汉语新解刚好最近李继刚有个提示词很火，可以生成很好玩的汉语新解。用 Claude3.5 试了效果特别好，下面是一些 Claude 生成的 SVG 图：这个提示词特别有意思，用经典编程语言 Lisp 来描述要执行的任务，大模型居然能理解，还能生成稳定、美观的 SVG 图。这个提示词很考验模型的理解和生成能力，试了 GLM 和 GPT-4o，都不能生成符合要求的 SVG 图。目前只有在 Claude3.5 上稳定输出，效果也很好，那么 OpenAI 的最新 o1-preview 模型如何呢？我们直接输出提示词，接着输入词语，结果如下图：这里没有输出 svg，给出了一个 markdown 格式的输出。然后新的模型有个比较有意思的地方，这里有个“思考”，会显示思考多长时间，然后点击后可以看到思考的过程。看起来模型也能理解提示词，只是输出有点问题。Claude3.5 是因为有 Artifacts 能力，所以可以直接输 SVG 格式图片。这里我们可以直接提示 o1-preview 生成 SVG 源码，于是提示词稍详细下，约束下输出格式，如下：生成 s ...继续阅读 (57)

在 LevelDB 中，内存 MemTable 中的数据存储在 SkipList(跳表) 中，用来支持快速插入。跳表是 William Pugh 在论文Skip Lists: A Probabilistic Alternative to Balanced Trees中提出的一种概率性数据结构。有点类似有序链表，但是可以有多层，通过空间换时间，允许快速的查询、插入和删除操作，平均时间复杂度为 $ O(\log n) $。和一些平衡树比起来，代码实现也比较简单，性能稳定，因此应用比较广泛。那么跳表的原理是什么？LevelDB 中跳表又是怎么实现的呢？LevelDB 的跳表实现有哪些亮点以及优化呢？如何支持单线程写，并发读跳表呢？本文将从跳表的原理、实现等方面来深入探讨。最后还提供了一个可视化页面，可以直观看到跳表的构建以及整体结构。跳表的原理跳表主要用来存储有序的数据结构，在展开跳表的原理之前，先来看看在跳表之前，人们是怎么存储有序数据的。存储有序数据为了存储有序的抽象数据类型，最简单的方法是用有序二叉树，比如二叉搜索树（Binary Search Tree, BST）。在二叉搜索树中，每个节点包含一个键值，这个键值具有可比较性，允许执行有序操作。任何一个节点的左子树只包含键值小于该节点的键值的节点，而其右子树只包含键值大于该节点的键值的节点。基于二叉搜索树的结构定义，我们很容易想到插 ...继续阅读 (82)

最近 anthropic 公布了 Claude3.5 模型的系统提示词，非常值得借鉴。整个提示词用英文写的，比较长，约束了模型的许多行为，下面一起来看看。基础约束明确定义了AI 助手 Claude 的身份和能力范围，包括知识更新时间、不能打开链接等限制。这样设计可以让用户对 AI 助手的能力有清晰的预期，避免误解和失望。同时也体现了对用户的诚实和透明度。The assistant is Claude, created by Anthropic. The current date is {}. Claude’s knowledge base was last updated on April 2024. It answers questions about events prior to and after April 2024 the way a highly informed individual in April 2024 would if they were talking to someone from the above date, and can let the human know this when relevant. Claude cannot open URLs, links, or videos. If it seems like the user is ex ...继续阅读 (95)

LevelDB 中实现了不少 utils 工具，比如定制的内存分配器 Arena，随机数生成类 Random，实现中都会考虑到具体的使用场景，做了优化以及取舍，值得好好学习。本篇文章主要聊聊下面部分的实现：内存管理 Arena，一个简单高效，适合 LevelDB 的内存分配管理器；随机数 Random，一个不错的线性同余伪随机生成算法，用位运算替代取模优化了执行效率。CRC32 循环冗余校验，用于检测数据传输或存储过程中是否发生错误；整数编、解码，用于将数字存储在字节流或者从字节流中解析数字。此外，还有些 utils 组件比较复杂些，会放在单独的文章里聊，比如：LevelDB 源码阅读：禁止对象被析构讲在 C++中如何禁止某个对象被析构，以为这样做的原因。内存管理 Arena 类LevelDB没有直接使用系统默认的 malloc 来分配内存，也没有使用 tcmalloc 等第三方库来管理内存的分配和释放，而是自己实现了一个简单的内存分配器。这里的内存分配器可以说是量身订制，主要基于下面考虑：主要在 memtable 中使用，会有大量的分配，可能有很多小内存分配；统一回收时机，在 memtable 数据落磁盘后，会一并回收；内存 memtable 的数据其实存储在 skiplist 中的。每次插入 key，就需要往 skiplist 中插入节点，这里节点使用的内存就是用 arena ...继续阅读 (76)

LevelDB 使用 WAL（Write-Ahead Logging）日志来确保数据的持久性。当写入操作发生时，LevelDB 首先将数据写入到日志文件中，然后再应用到内存中的数据结构（如 MemTable）。系统或数据库崩溃后重新启动时，LevelDB 会检查 WAL 日志文件中的记录。通过读取并重放这些日志记录，LevelDB 可以重建那些在崩溃发生时还未被完全写入磁盘的数据状态。整个 WAL 日志相关的操作流程如下：LevelDB首先将数据写入WAL日志。确保即使在系统崩溃的情况下，数据也不会丢失。数据被写入内存中的MemTable，这个是内存操作，很快。LevelDB向客户端确认写入完成。随着时间推移，当MemTable满了之后，它会被刷新到磁盘上的SSTable文件中。一旦MemTable被成功刷新到SSTable，相应的WAL日志就可以被清除了。接下来详细看看这里的实现。写 WAL 日志先来看看 LevelDB 是如何写 WAL 日志的。在 LevelDB 中，db/log_writer.h中定义了个 Writer 类，用于写入 WAL 日志文件。Writer 类的主要方法是AddRecord，用于将一个记录追加到日志文件中。主要的数据成员是WritableFile* dest_;，指向支持追加写的日志文件。这里 WritableFile 是include&# ...继续阅读 (74)

LevelDB 整体代码还是比较好懂，没有用很多 C++奇淫技巧。不过还是有部分实现，相当比较少见，比如柔性数组、链接符号导出、Pimpl 类设计等。本文会梳理这里的 C++ 高级技巧，帮助更好地理解 LevelDB 的实现。柔性数组在util/cache.cc的 LRUHandle 结构体定义中，有一个柔性数组(flexible array member)char key_data[1]，用来在 C/C++ 中实现可变长数据结构。123456789structLRUHandle{// ...charkey_data[1];// Beginning of keySlicekey()const{assert(next !=this);returnSlice(key_data, key_length);}};在这个 handle 结构体中，key_data[1]实际上只是一个占位符，真正分配给key_data的空间要比 1 字节大，它由 malloc 时计算的total_size确定。具体到 LevelDB 的实现中，在插入新的缓存条目时，会根据 key 的长度动态分配内存，然后将 key 的内容拷贝到这块内存中。如下代码：12345678910111213Cache::Handle*LRUCache::Insert(cons ...继续阅读 (80)

LevelDB 中数据存储在 SSTable 文件中，当用 Get() 来查询 key 的时候，可能需要从 SST 文件中读取多个块。为了减少磁盘读取，LevelDB 提供了 FilterPolicy 过滤策略，如果判断出来一个 Key 不在当前 SSTable 文件中，那么就可以跳过读取该文件，从而提高查询效率。LevelDB 支持用户自定义过滤策略，不过提供了一个默认的布隆过滤器实现。布隆过滤器是一种空间效率极高的数据结构，用于判断一个元素是否存在于一个集合中，有一定的误判率但没有漏判。简单说就是如果布隆过滤器判断一个元素不存在，那么这个元素一定不存在；如果布隆过滤器判断一个元素存在，那么这个元素可能不存在。在 LevelDB 中使用布隆过滤器也比较简单，如下代码：1234567leveldb::Options options;options.filter_policy =NewBloomFilterPolicy(10);leveldb::DB* db;leveldb::DB::Open(options,"/tmp/testdb", &db;);// ... use the database ...deletedb;deleteoptions.filter_policy;那么布隆过滤器的原理是什么？LevelDB 中又是怎么实现的呢？本文一起来看看。LevelDB 接口定义在开 ...继续阅读 (77)

LevelDB 是 C++ 开发的优秀的 LSM Tree 的存储组件，整体代码量不大，但是设计精巧，值得学习。在阅读源码过程中，整理了系列文章，逐步拆解 LevelDB 的实现细节。不过在阅读代码前，最好先准备好整个开发环境。本文会从最基本的拉取代码开始，记录自己准备整个环境的过程，包括配置 VSCode IDE 和 clangd 插件使用，以及如何配置编译选项等。然后会通过简单的读写代码 demo，来简单使用下 LevelDB，对这个库有个感性的认识。另外，还会介绍如何运行测试用例，LevelDB 的测试用例写的很好，在代码阅读过程中，可以借助用例更好的理解代码。源码编译首先是拉代码，这里使用的是git clone --recurse-submodules，可以一次性拉取所有的子模块。虽然 leveldb 的实现不依赖第三方库，不过压测用到了 benchmark，功能测试用到了 googletest，这两个库都是作为子模块引入的。如果拉取代码遇到网络问题，比如下面这种，需要先绕过防火墙才行，可以参考安全、快速、便宜访问 ChatGPT，最新最全实践教程！这篇文章中的方法。1234Cloning into '/root/leveldb/third_party/googletest'...fatal: unable to access 'https:/ ...继续阅读 (86)

LevelDB 支持在各种操作系统上运行，为了适配不同的操作系统，需要封装一些系统调用，比如文件操作、线程操作、时间操作等。在对外暴露的 include 文件中，env.h文件定义了 LevelDB 用到的各种接口。包括 Env 类，封装文件操作，目录操作等，还有一些文件抽象类，比如 SequentialFile、WritableFile、RandomAccessFile 3 个类，用于顺序读取，随机读取和写入文件。通过抽象接口，只需要为每个平台实现相应的 Env 子类，LevelDB 就可以在不同的操作系统上运行。这篇文章以 POSIX 系统环境为例，先来看看抽象出来的和文件操作相关的接口是怎么实现的。顺序读文件首先看看顺序读文件的抽象基类 SequentialFile，它为文件的顺序读取和跳过操作提供了一个标准的接口，可以用于 WAL 日志文件的读取。类中定义了2个主要的虚函数：Read(size_t n, Slice* result, char* scratch)：这个函数用于从文件中读取多达 n 字节的数据。result 是一个指向 Slice 类型的指针，用来存储读取的数据。scratch 是一个字符数组，用作临时缓冲区，函数可能会向这个缓冲区写入数据。Skip(uint64_t n)：这个函数用于跳过文件中的 n 字节数据。如果文件读取到末尾，跳过操作将停止在文件末尾， ...继续阅读 (98)

在当今社会，性骚扰问题引起了广泛关注，特别是高校内部的师生关系中性骚扰问题更是敏感而复杂。近期，一位来自某知名高校的教授因涉嫌对女学生进行性骚扰而被曝光，此事件迅速激发了公众对于高等教育环境中性问题的关注。这不仅是一个高校的内部问题，更触及到了社会法律对于性骚扰行为的态度与处理。性骚扰不仅侵犯了个体的人格尊严，还可能对受害者造成长期的心理阴影。我国法律对此有着严格的规定与明确的法律后果，而通过具体的法院判决书，我们可以清晰地看到法律是如何审视这一行为的。本文将结合最新的判例，详细分析关于性骚扰行为的相关法律知识～核心要点在处理性骚扰案件时，法院对证据的要求非常严格。在提出诉讼时必须具备充分、确凿的证据，以便法院能够做出公正的判断。证据的重要性：在性骚扰案件中，证据是判决的关键。原告需提供充分证据来证明被告的性骚扰行为及其对原告造成的精神和身体伤害。举证责任：侵权纠纷中，受害者必须承担起举证责任，证明被告的行为构成侵权并导致了损害后果。法律定义和界定：性骚扰的法律定义涉及身体、语言、动作、文字或图像等方式，违背他人意愿而对其实施的以性为取向的有辱其尊严的性暗示、性挑逗以及性暴力等行为。真实案例性骚扰很常见，但敢于拿起法律武器保护自己的，少之又少。从公开的裁判文书来看，最近 5 年只有 682 起性骚扰相关诉讼。撤诉性骚扰案件中有不少撤诉的，大部分是因为证据难以收集。性骚扰往往发生在没 ...继续阅读 (77)

LevelDB 源码中有一个获取 Comparator 的函数，第一次看到的时候觉得有点奇怪，看起来像是构造了一个单例，但又略复杂。完整代码如下：12345// util/comparator.ccconstComparator*BytewiseComparator(){staticNoDestructorsingleton;returnsingleton.get();}这里的NoDestructor是一个模板类，看名字是用于禁止对象析构。为什么要禁止对象析构，又是如何做到禁止析构呢？这篇文章来深入探讨下这个问题。NoDestructor 模板类我们先来看看NoDestructor模板类，它用于包装一个实例，使得其析构函数不会被调用。这个模板类用了比较多的高级特性，如模板编程、完美转发、静态断言、对齐要求、以及原地构造（placement new）等，接下来一一解释。这里先给出完整的代码实现：123456789101112131415161718192021222324252627282930// util/no_destructor.h// Wraps an instance whose destructor is never called.// This is intended for use with function-level static varia ...继续阅读 (93)

Anthropic不声不响地发布了Claude 3.5 模型，除了模型效果提升，还支持了 Artifacts。初步体验后，感觉这才是未来 AI 的样子，比之前 GPT4-o 更让我震撼。在 Artifacts 之前，如果想用 ChatGPT 等 LLM 来帮忙实现程序功能，需要先提功能需求，然后复制 AI 的代码到自己的环境中运行。如果和预期不符合，要再追问、再修改代码运行。需要重复这个过程，直到满意或者放弃（有些复杂代码目前 AI 还是写不太好）。现在有了 Artifacts，提供具体功能需求后，Claude 会创建一个工作空间，后续对话过程中，AI 可以在这个动态工作空间中实时查看、编辑代码。这样，Claude 就从普通的对话式生成 AI 变成了一个协作工作环境，或许在不久的将来，可以将 Claude 引入到我们自己的项目中，让它像普通团队成员一样参与到开发。愿景当然很美好，不过目前的 Artifacts 还只是 beta 功能，表现如何呢？下面来试试看。AI 实现五子棋游戏先试着让 Claude 实现一个 web 版五子棋游戏，我的提示词也很简单：我想写一个网页五子棋游戏，给出完整的实现代码然后，就看到了 Artifacts 的工作空间，里面已经有了一个代码文件，并且在自动生成代码。代码生成之后，直接跳到了一个预览页面，可以看到五子棋的界面。本来以为这个预览页面是静态的，没想 ...继续阅读 (89)

最近在业务中遇见一个很奇怪的服务重启问题，定位过程比较有曲折，本文来复盘下。这个问题涉及到 C++ 线程池、整数溢出、异常捕获、阻塞等多个方面，还是挺有意思的。接下来我会按照问题排查的过程来组织本文内容，会先介绍问题背景，接着列出初步的排查思路，定位异常请求的方法。然后，通过代码分析，以及复现问题的一些简单用例，来揭开服务重启的神秘面纱。问题背景我们有个模块 A 对外提供 RPC 服务，主调方 B 会调用 A 的服务。模块 A 的服务分为 2 个进程，mesh 进程和业务进程，这两个进程都是多线程的。mesh 进程类似Sidecar的作用，每当接收到主调方发来的 1 个 rpc 请求，就分配一个 worker 线程负责该请求。worker 会通过 unix socket 把请求包发给业务进程，然后等业务进程处理完后回复主调方。业务进程则专门用来做业务逻辑，拿到请求包处理完成后，把响应包给 mesh 进程里的 worker。整体如下图所示：最近，主调方 B 通过监控发现每天会有几次连不上模块 A 的服务端口，每次持续时间也不长，过一会就自动恢复了。简单看了下模块 A 的日志，发现在对应时间点，监控脚本拨测 A 服务失败，于是重启服务。这里的监控脚本每隔固定时间，会拨测模块 A 的 存活探测 rpc(就是简单回复一个 hello)，来检测服务是否正常。如果连续的几次拨测都失败，则认为服 ...继续阅读 (104)

一个晴朗的周末，你带着家人去超市购物。突然保安把你拦下来，说你偷了东西。你需要要证明你没偷东西吗？如果要证明，你又怎么证明呢？又或者，你把自己的伞忘在了茶水间，过了会去找发现不见了。通过查监控，发现是另一个同事拿走了你的伞，于是想找这个同事拿回来。结果拿伞的同事让你证明这是你的伞，问你要购物记录和发票，你需要提供吗？电影《让子弹飞》里面六子去吃饭，被诬陷说吃了两碗粉但只付了一碗粉的钱。六子为了自证清白于是刨腹，结果惨死。六子真的需要自证清白吗？生活中类似的例子数不胜数。遇到胡搅蛮缠、强词夺理的人，有时候我们可能会陷入自我怀疑，我是不是真的要自证啊？其实大可不必，记住这六个字，“谁主张谁举证”。这不仅是民事诉讼中的基本原则，也是我们应对各种纠纷时的法宝。接下来小盛律师和大家详细聊聊民事诉讼中的“谁主张谁举证”以及“举证责任倒置”，希望能帮大家理清思路，遇到类似情况时能够做到心中有数，游刃有余。谁主张谁举证“谁主张谁举证”是民事诉讼中的一项基本原则。当事人在民事诉讼中对自己所主张的事实，有责任提供证据加以证明。也就是说，如果一方提出了某个主张，那么这一方就需要承担提供证据的责任，以证明其主张的事实是真实存在的。如果这一方没有足够的证据来支持其主张，那么法院可能不会接受这个主张。这里主要依据《中华人民共和国民事诉讼法》：第六十七条　当事人对自己提出的主张，有责任提供证据。当事人及其诉讼代 ...继续阅读 (101)

如果有用过 ChatGPT 等大语言模型，可能就会发现在聊天对话中，AI 的输出文本是一批批“蹦出来”的，这就是所谓的流式输出。在浏览器上，是怎么实现这种效果呢？本篇文章会介绍 4 种常见方法来实现流式输出效果，每种方法都会结合实际例子来演示。在业务中选择哪种方法，取决于具体的需求和场景。客户端轮询：客户端定时（如每几秒）发送请求到后端服务，获取新的数据。分块传输：HTTP/1.1 支持，服务器一次可以只发送部分响应内容，客户端接收到部分数据后就可以开始处理。Server-Sent Events：服务器向浏览器推送信息，浏览器创建一个到服务器的单向连接，服务器通过这个连接可以发送多个消息。Web Socket：建立一个持久的、全双工的连接，允许服务器和客户端之间进行实时、双向的通信。简单轮询首先是最简单的轮询方法，客户端每隔一段时间向服务器发送请求，获取新的数据。实现轮询的时候，客户端和服务器需要用 HTTP 请求参数和回包约定数据更新或者结束的方式。比如简单的用一个请求字段 cnt 来约定这是第几次请求，返回中用 400 错误码来约定本次轮询结束。下面用 Python 的 FastAPI 写一个简单示例，每次带一个下标来请求一段文本中的内容，如果超过文本长度，就返回 400。12345asyncdefpolling(cnt:int=1):ifcnt >=len(mess ...继续阅读 (100)

可能不少人认为，遇到纠纷后，只要打赢了官司，就能拿到应有的赔偿。然而一个残酷的现实是，胜诉仅仅是解决纠纷的第一步，如何保证法院的判决被顺利执行，才是关键。有不少案例中，当事人赢了官司，却因对方拒绝履行判决，导致无法获得赔偿。在这种情况下，强制执行才是破解之道。但现实中不少人对强制执行有些误解，比如认为法院会主动强制执行，不用自己参与。或者是觉得被执行人把钱转移了，没办法执行到。其实这些观点都不太对，接下来小盛律师来和大家聊聊强制执行的那些事！强制执行流程强制执行是法院根据生效法律文书（如判决书、裁定书等），对拒不履行的被执行人采取的法律措施，其目的在于确保法律文书所确定的权益得以实现。强制执行的流程基本如下：申请强制执行：当债务人（被执行人）在履行期未履行法院判决等法律文书所确定的义务时，债权人（申请执行人）可以向法院申请强制执行，注意这里是要主动申请才行哦。申请的时候一般需要提交申请执行书、生效法律文书副本、身份证明等材料；法院受理与立案：法院在收到强制执行申请后，会进行审查并决定是否受理。一旦受理，将正式立案并启动强制执行程序。执行通知与财产调查：法院会向被执行人发出执行通知，责令其履行义务。同时，法院还会对被执行人的财产状况进行调查，以确定可供执行的财产。采取执行措施：根据调查情况，法院会采取相应的执行措施，如查封、扣押、拍卖等，以强制被执行人履行义务。在此过程中，如果被执行 ...继续阅读 (100)

前两天在小红书上看到一个贴子，大概情况是这样的：一个中年男人，有两个小孩子，在家里是顶梁柱，在公司是好员工。由于女儿肺炎发烧，他在 5.6 号早上发消息请了 3 天假。结果 7 号上午突发糖尿病酮中毒和心肌梗塞，没抢救过来。公司打算走工伤赔偿，但是被告知这个情况不属于工伤。哎，看到这个消息有点心酸，一个生命就这样逝去，家人的生活也会因此发生很大的变化。从感情上来说，希望能认定工伤，让家人能够得到一些补偿。但是，作为一个执业律师，我也清楚知道，这种情况不属于工伤。法律对于认定工伤有明确的规定，接下来我就来给大家科普下怎么才算是工伤。简单案例分享首先来看几个简单的案例。刘某搭乘同事的车，在去工作单位的路上发生交通事故。本案中，刘某在工作地点附近发生事故，且事故发生在合理的上下班路线上。刘某的目的是回单位上班，工作时间合理，且事故发生地点属于合理路线，因此属于工伤。易某在下班后停留两小时吃饭，之后返回居住地，途中顺道探望母亲。对于上下班合理时间的认定，除了合理路线上的往返时间外，还包括日常生活所需的短暂停留时间。在本案中，易某下班后停留两小时吃饭，超出了合理时间范围，不符合要求。因此，交通事故伤害不在“上下班途中”，也不符合认定工伤的条件。付某受聘到某环卫处工作，工作岗位是清扫员。某工作日下午16时许，在打扫卫生时，突然感到胸闷，被送到人民医院治疗，诊断为急性左心衰等疾病。虽然是在工作时 ...继续阅读 (198)

在前面Bazel 依赖缺失导致的 C++ 进程 coredump 问题分析这篇文章，因为二进制使用了不同版本的 proto 对象，对象的内存布局不一致导致读、写成员的内存地址错乱，进而导致进程 crash 掉。但是当时并没有展开细聊下面的问题：对象在内存中是怎么布局的?成员方法是如何拿到成员变量的地址？这些其实涉及 C++ 的对象模型，《深度探索 C++对象模型：Inside the C++ Object Model》这本书全面聊了这个问题，非常值得一读。不过这本书读起来并不容易，有的内容读过后如果没有加以实践，也很难完全理解。本篇文章试着从实际的例子出发，帮助大家对 C++ 类成员变量和函数在内存布局有个直观的理解，后面再读这本书也会容易理解些。简单对象内存分布首先以一个最简单的 Basic 类为例，来看看只含有基本数据类型的对象是怎么分配内存的。1234567891011121314#includeusingnamespacestd;classBasic{public:inta;doubleb;};intmain(){Basic temp;temp.a =10;return0;}编译运行后，可以用 GDB 来查看对象的内存分布。如下图：对象 temp 的起始地址是0x7fffffffe3b0，这是整个对象在内存中的位置。成员变量a的地址也 ...继续阅读 (108)