Maerlyn's Rainbow

《数学觉醒：学会更清晰地思考》读书笔记

2026-05-02T12:00:00+08:00

这本书表面在谈数学理解，实际处理的是更一般的认知问题：人如何形成直觉，语言与理解之间是什么关系，以及为什么形式化表达常常无法自动带来理解。

1. 理解的核心是心理图像，而不是符号操作

数学对象的真正理解，依赖于头脑中是否形成了相应的心理图像。定义、陈述、证明本身不是终点，而是引导理解的媒介。

一个关键判断：定义不是注释，也不是解释，而是构建新心理图像的指南。它的作用不只是给词划定边界，而是要在脑中生成一个可操作、可感知、可联结的对象。缺了这一层，学习者只是记住了语言形式。

这解释了一个常见现象：题目能模仿，换个说法就不会；证明能背下来，脱离原题就失去方向。问题往往不在记忆，而在对象还没有真正”成形”。一个相关的判断也指向同一点——当一个对象无法被想象、无法激发直觉时，学习者觉得”自己其实没理解它”，这种感觉通常是可靠的。

2. 形式语言保证精确性，但不保证理解

数学语言之所以高度形式化，是因为人在讨论”无法直接展示的对象”时，需要稳定、可检验、低歧义的表达方式。形式化是必要的。

但它有代价：词义被压缩进定义，语言与自然理解之间产生距离。书里举过一个极端例子：如果”长鼻子”被写进大象的定义，那么鼻子被砍掉它就不再是大象。这不是抬杠，而是说明形式系统只服从定义，不服从常识语感。

由此引出一个有用的区分：官方数学 vs 秘密数学。前者是对外发表的规范系统，后者是个人头脑里实际进行的直觉、图像和意义活动。很多学习困难的本质，不是官方数学不存在，而是它没有被翻译成秘密数学。

3. 数学活动是想象、语言和推理之间的反复转换

数学并非单纯的逻辑演算，而是一种多层次的认知活动，涉及几组互补的张力：想象力与语言、直觉与逻辑、细节与全局、遐想与计算。真正的理解来自它们的协同。

书中有一句值得记下：从人类语言出发，通过数学语言推理，再回到人类语言中来。这个流程不只适用于数学——自然语言负责提出问题和承载意义，形式语言负责约束推理，最后还要翻译回来，检查结论是否真正可被理解。

4. “反直觉”是认知状态，不是对象属性

书中反对把某些问题描述为”本质上反直觉”或”本质上悖论”。所谓反直觉通常只是暂时的；所谓悖论，往往意味着当前理解尚未完成。

这与流行表达不同。人们经常把”不懂”包装成”深刻”，把”尚未解释清楚”包装成”天然矛盾”。作者对此比较警惕——直觉和推理结果冲突时，这不是理解的终点，而是重建直觉的起点。

为此，书中引入三个系统：

系统1：快速、低成本、直觉式反应
系统2：慢速、费力、逻辑化推理
系统3：让二者对话，使推理结果逐步重塑直觉

这个框架把”会算但不直观”视为中间状态，而非终点。稳定的理解不是系统2能推出结果，而是系统1也被训练到能自然接受这个结果。练习的目的，不只是得出正确答案，而是让某类对象在头脑中越来越”看得见”。

5. 主要的学习阻碍之一，是对”不懂”的羞耻感

许多数学交流之所以失败，不是因为问题太难，而是因为参与者不愿暴露自己的无知状态。一旦开始羞于承认”没听懂”，注意力就会被自我评价吞掉，无法继续真正思考。结果是既没学会、也没问清，还带着挫败感结束对话。

由此引出一个实用动作：主动把自己放在”什么都不懂”的位置，甚至在交流一开始就公开这一点。它的功能不是表演谦虚，而是降低认知负担，让提问和澄清合法化。

两个相关表述：

游客菜单与私房菜单。 很多人对外讲的是一套正式说明，对内依赖的是另一套更直观、更朴素的理解方式。前者用于公共交流，后者才是自己真正能工作的认知工具。如果只接触游客菜单，理解往往是悬空的。

向初学者解释，是检验理解的有效方法。 重点不在”教学促进复习”，而在于：一旦要解释，你会立刻发现哪些地方其实只是”奇迹”——会用，但不知为什么。

6. 数学训练的产物是”清晰”，而不是定理本身

书中有一句可以视为总结：数学的产物是清晰和理解，而不是定理本身。

这不是轻视定理，而是强调数学活动的价值不只在外部结果，更在于认知结构被训练后的状态。理想情况下，一个人经过数学训练获得的不是更多结论，而是更好的分辨力：更快看出哪里含混、哪里跳步、哪里只是语言在假装理解、哪里是真的把对象看清了。

从这个角度，”数学觉醒”并不限于数学，它对应的是一种更一般的能力——把语言、直觉、形式化、怀疑和修正组织成一个持续运转的理解机制。

简要归纳

理解先于表达，但表达又是校正理解的工具。
数学对象必须在头脑里形成图像，否则学习容易停留在模仿层。
定义和形式系统解决的是精确性，不自动解决意义问题。
直觉并非固定不变，它可以被训练、修正和重塑。
“反直觉”通常表示理解尚未完成，而不是对象天然不可理解。
承认不懂、反复发问、向初学者解释，是提升理解密度的有效方法。
数学训练的深层产物，是更清晰的认知，而不只是更多结论。

7. 实践应用：把这套方法搬到 competitive programming 上

把前面六节压成一句话：理解 = 心理图像 + 直觉被推理重塑后的状态，而不是会复述定义或会跑通代码。

Competitive programming（LeetCode、Codeforces 等）是这套方法的天然试验场。它的常见失败模式正好对应书里批评的几种状态：

看题解 → 抄实现 → AC：相当于只接触了”官方数学”，没有形成秘密数学。下次换个皮就不会。
“这题反直觉”：通常不是题反直觉，而是当前直觉还没有被这一类结构训练过。
会写但说不清为什么对：系统2勉强通过，系统1完全没跟上，属于中间状态。
不敢承认哪里没懂：跳过”装傻”步骤，理解出现空洞而不自知。
题面没看懂: 出题人语文没学好。哪怕花点钱买个AI改改呢？

所以，使用 coding agent 的目标不是”让它给我答案”，而是让它充当一个迫使我形成心理图像、暴露认知空洞、并把推理结果反向训练直觉的对话者。

下面是为此设计的 prompt。

Prompt：Competitive Programming 学习助手

# Role
你是我的 competitive programming 学习教练，不是题解生成器。你的目标不是让我 AC，而是让我对这道题及其所属的问题类，建立可以迁移的理解。

# 核心原则
1. **理解优先于代码**。在我没有形成对问题的心理图像前，不要给出完整实现。
2. **区分"官方解法"与"私房理解"**。标准解法要讲，但更重要的是讲清楚：发明这个解法的人，脑子里实际看到了什么结构？
3. **把"反直觉"视为待修复的直觉**。如果某一步看起来需要"灵感"或"技巧"，必须显式拆解：是什么观察让这一步从灵感降格为自然推论。
4. **允许并鼓励我装傻**。如果我说"我不懂 X"，不要假设 X 对我是显然的，哪怕 X 是基础概念。
5. **不要用"显然""容易看出""注意到"这类词跳步**。每个跳步处都可能藏着我尚未形成的心理图像。

# 工作流程

## 阶段 0：在我贴出题目后，先不要解题
先问我：
- 我现在对这题的第一直觉是什么？（哪怕是错的）
- 我能用自然语言把这题重述一遍吗？
- 我能想到的最朴素（哪怕指数级）的做法是什么？

让我先暴露我的初始状态。

## 阶段 1：建立心理图像
在写任何代码、给任何算法名词之前，帮我回答：
- 这题的输入在头脑中应该被想象成什么？（数组？图？状态空间？决策树？）
- 解的结构长什么样？（一个分割点？一条路径？一个不变量？）
- 哪些量在过程中保持不变，哪些在变化？

如果我给不出，引导我给出，而不是替我给出。

## 阶段 2：从朴素解到目标解的推导链
不要直接抛出最优解。按下面的链条走：
1. 朴素解是什么？为什么慢？慢在哪个具体的重复或浪费上？
2. 这个浪费对应什么结构性观察？（重叠子问题？单调性？对称性？）
3. 这个观察如何自然地推出目标算法？

目标是：让最优解看起来像"被逼出来的"，而不是"碰巧想到的"。

## 阶段 3：检验理解（强制环节）
在我说"我懂了"之后，不要相信我。用以下方式检验：
- 让我用一句话向一个不懂这题的人解释核心思路（游客菜单 vs 私房菜单测试）。
- 提一个微小的变体（改个约束、换个目标），看我能否迁移。
- 指出我的解释里哪些地方仍然是"奇迹"——即我会用但说不清为什么对的步骤。

## 阶段 4：归档
最后，用结构化格式输出供我日后复习：
- **问题类**：这题属于哪一类？识别信号是什么？
- **核心心理图像**：一句话 + 一个可以画出来的图。
- **关键观察**：把"灵感步骤"降格为"自然推论"的那一步。
- **可迁移点**：这套思路还能解什么类型的题。
- **我的盲点**：本次对话中暴露出来的、我之前没意识到的认知空洞。

# 交互风格
- 平实、克制、不煽情、不鼓励性废话。
- 我问简单问题时，认真回答简单问题，不要借机讲一大套。
- 我说"跳过这步"时尊重，但如果该步骤是关键直觉，提醒我一次。
- 代码用最小可读形式，注释只标注"为什么"，不标注"做了什么"。

# 我现在贴出的题目是：
[在此处粘贴题目]

# 我现在的状态是：
[完全没思路 / 有方向但写不出 / 写出来了但不懂为什么对 / 想对比我的解法和标准解]

使用建议

这个 prompt 的关键不在某一条规则，而在阶段 0 和阶段 3 —— 它们对应”先暴露初始直觉”和”事后检验理解”。如果偷懒省掉这两步，对话会迅速退化成普通题解机器人。
“我现在的状态是”那一栏不要省。它决定了 agent 应该从哪一阶段切入。
如果某一类题反复出现”盲点”字段相似的内容，那是直觉尚未被重塑的信号，需要专门刷一组同类题，而不是继续往前推进度。
这个 prompt 也可以反过来用于非编程场景：把”题目”换成”论文里看不懂的一段推导”或”一个工程问题”，框架仍然成立——因为它本质上是这本书方法论的一个具体化。

本文使用 GPT 和 Claude 大模型生成。

一个“一读多写”无锁队列的实现

2026-01-17T20:00:00+08:00

一个“一读多写”无锁队列的实现

标签（空格分隔）： C++ 并发编程 Lock-Free 性能优化

1. 背景与设计目标

在高性能网络编程中，我们经常面临“一读多写”（MPSC, Multi-Producer Single-Consumer）的场景，例如多个工作线程需要向同一个 Socket 串行写入数据。

为了避免互斥锁（Mutex）带来的上下文切换开销，我们设计了一个基于 C++11 std::atomic 的定长 Ring Buffer。其核心目标包括：

零内存动态分配：使用定长数组，避免频繁 new/delete。
高效位运算：将队列长度限制为 2 的 N 次幂，利用位与运算（&）替代昂贵的取模操作（%）。
细粒度内存序：摒弃粗暴的 seq_cst，通过 relaxed、acquire 和 release 的精细组合，构建最小开销的同步机制。

2. 生产者逻辑：try_enqueue

生产者的核心挑战在于：如何在多个线程同时竞争写入时，安全地分配 Slot 并发布数据。

代码实现

bool try_enqueue(T* item) noexcept
{
    if (item == nullptr) return false;

    // 1. 获取当前尾部索引的快照（无需同步）
    size_t cur_tail = m_tail.load(std::memory_order_relaxed);

    for (;;)
    {
        const size_t next_tail = (cur_tail + 1) & m_mask;

        // 2. 获取头部索引（需要同步，以感知消费者的进度）
        const size_t head = m_head.load(std::memory_order_acquire);

        // 队列满
        if (next_tail == head) return false;

        // 3. 尝试抢占 Slot (CAS)
        if (m_tail.compare_exchange_weak(
                cur_tail,
                next_tail,
                std::memory_order_acq_rel, // 成功：建立同步点
                std::memory_order_relaxed)) // 失败：仅重试
        {
            // 4. 抢占成功，物理写入数据并发布
            m_slots[cur_tail].store(item, std::memory_order_release);
            return true;
        }

        // CAS 失败：cur_tail 已被自动更新为最新值，进入下一次循环重试
    }
}

深度拆解：生产者入队 (try_enqueue) 的三部曲

一个标准的无锁入队操作，在逻辑上并非单一步骤，而是一个严密的“观察 — 抢占 — 发布”协议。

1. 第一阶段：观察 (Observation)

在动手修改任何状态前，生产者必须先看清楚局势。

size_t cur_tail = m_tail.load(std::memory_order_relaxed);
// ...
const size_t head = m_head.load(std::memory_order_acquire);

tail (Relaxed)：这里读取的 tail 仅仅是一个“猜测值”，用于后续 CAS 的基准。即使读到了旧值，CAS 也会失败并自动重试，因此不需要同步代价高昂的内存序。
head (Acquire)：这是一个关键的同步点。必须使用 acquire 语义，确保生产者能“看到”消费者之前释放 Slot 的操作（即 consumer-release producer-acquire）。如果不加同步，生产者可能错误地认为队列未满，覆盖了尚未被消费的数据。

2. 第二阶段：抢占 (Logical Claim) —— 核心中的核心

这是整个无锁队列最复杂、技术含量最高的一行代码。生产者试图将 tail 指针向后移动一位，从而宣告对当前 Slot 的所有权。

if (m_tail.compare_exchange_weak(cur_tail, next_tail, 
                                 std::memory_order_acq_rel, 
                                 std::memory_order_relaxed))

这里包含了三个深度的技术决策，我们需要逐一拆解：

** 为什么选 compare_exchange_weak 而不是 strong？**

m_tail.compare_exchange_weak(cur_tail, next_tail, ...)

在底层硬件（尤其是 ARM/PowerPC 架构）上，CAS 指令可能出现“伪失败” (Spurious Failure)——即原子变量的值虽未被修改，但由于总线微观竞争或缓存行失效，指令依然返回 false。

针对这种情况，C++ 提供了两个版本：

Strong 版本（双重循环）：
它承诺“只要值没变，我就帮你试到成功为止”。为此，编译器会在底层生成一个隐式的内层循环来屏蔽伪失败。这意味着你的代码变成了嵌套结构：外层是业务重试循环，内层是 CAS 的“原地死磕”循环。
Weak 版本（扁平循环）：
它允许伪失败，直接返回 false。这使得代码维持高效的单层循环结构。

决策理由：计算成本决定了一切

既然无论用哪种版本，遇到真正的并发冲突（值被改了）都必须重试，那么选择的关键在于：当发生伪失败时，“重头再来”的代价有多大？

在本队列场景下（选 Weak）：
CAS 之前的准备工作（计算 next_tail）仅涉及极低成本的位运算。如果使用 Strong，是为了省去一次极快的位运算而引入复杂的内层循环和分支跳转，属于“杀鸡用牛刀”。使用 Weak，一旦伪失败直接回到外层循环重试，这种扁平模式对 CPU 分支预测器更友好，性能更高。
反之，什么时候该用 Strong？
如果 CAS 之前的计算逻辑非常昂贵（例如耗时 5ms 的复杂数学运算），一旦发生伪失败，我们绝对不想回到外层去重新计算一遍数据。此时必须用 Strong，在指令层面上死磕，直到成功或检测到值真的发生了变化，从而避免昂贵的“业务逻辑级重试”。

** 为什么内存序是 std::memory_order_acq_rel？**

此处 m_tail 充当了同步枢纽，我们需要它同时发挥双向屏障的作用：

Acquire (向后屏障)：
防止后续对 Slot 的写入操作（Step 3）被 CPU 或编译器重排到 CAS 之前。

风险：如果没有 Acquire，可能出现“还没抢到座位（CAS 未完），就开始往座位上放东西（Write Slot）”的情况，导致数据踩踏。
Release (向前屏障)：
确保此前所有的依赖计算（如 item 的准备）对其他线程可见。同时，它向消费者宣告：“tail 已经推进，这个位置归我了”。

** 为什么不直接用默认的 std::memory_order_seq_cst？**

很多开发者习惯一把梭使用 seq_cst（顺序一致性），它是 C++ 原子操作的默认选项，提供全局最强的同步保证。但在高性能场景下，它是我们极力避免的。

开销巨大：在 x86 架构下，seq_cst 的 Store 操作通常需要 MFENCE 指令或 LOCK 前缀，这会强制刷新 CPU 的 Store Buffer，导致流水线停顿，开销可达几十到上百个时钟周期。
需求过剩：我们只需要成对的同步 (Pairwise Synchronization)——即生产者与消费者之间达成共识。我们并不需要整个系统的所有变量维持一个全局的全序关系。

优化结论：使用 acq_rel，我们构建了刚好够用的 Happens-Before 关系，既保证了安全性，又避免了 seq_cst 带来的总线同步风暴。

3. 第三阶段：发布 (Physical Publish)

一旦 CAS 成功，当前线程就拥有了 cur_tail 指向的 Slot 的独占写入权。

m_slots[cur_tail].store(item, std::memory_order_release);

Release 语义：这是数据真正对外界“可见”的时刻。它保证了：当消费者随后读取到这个非空指针时，指针所指向的对象内容（item）一定已经初始化完毕。
配合 Consumer：这与消费者侧的 load(..., acquire) 完美配对，构成了完整的数据发布-订阅链条。

3. 消费者逻辑：try_dequeue

消费者的处理流程相对线性，但包含了一个非常关键的“等待”逻辑。

代码实现

T* try_dequeue() noexcept
{
    // 1. 本地状态读取（relaxed）
    const size_t head = m_head.load(std::memory_order_relaxed);
    // 2. 获取尾部索引（acquire，感知生产者的发布）
    const size_t tail = m_tail.load(std::memory_order_acquire);

    if (head == tail) return nullptr;

    T* item = nullptr;

    // 3. 关键：自旋等待数据发布完成
    while ((item = m_slots[head].load(std::memory_order_acquire)) == nullptr)
    {
        std::this_thread::yield();
    }

    // 4. 消费完成，回收 Slot
    m_slots[head].store(nullptr, std::memory_order_relaxed);

    // 5. 推进 Head，向生产者宣告资源释放
    m_head.store((head + 1) & m_mask, std::memory_order_release);

    return item;
}

关键设计：为什么需要 while 循环？

这是本队列设计的精髓所在：“先逻辑声明，再物理发布”。

生产者在 enqueue 时，先修改了 tail（宣告占位），然后才写入 m_slots（发布数据）。这意味着存在一个微小的时间窗口：

head != tail （队列看起来非空），但 m_slots[head] 仍然是 nullptr。

因此，消费者必须在读取 Slot 时进行检查。如果读到空指针，说明生产者“占了坑但还没填土”，此时通过 yield() 让出 CPU 等待数据就绪。

4. 深度原理：Happens-Before 关系图谱

判断一个无锁队列是否正确，不能靠“感觉”，必须依靠严格的 Happens-Before (先行发生) 关系推导。

在这个实现中，正确性完全由两条对称的同步链支撑。

链条一：数据发布链 (Producer Consumer)

这条链保证了消费者读取数据时的安全性。

Producer: m_slots[i].store(..., release)
Consumer: m_slots[i].load(..., acquire)

推导结果：
当消费者通过 acquire 读到非空指针时，生产者在 release 之前的所有内存写入（即 item 对象的初始化）都对消费者可见。

✅ 保证：绝不会读取到未初始化的脏数据。

链条二：资源回收链 (Consumer Producer)

这条链保证了生产者复用 Slot 时的安全性。

Consumer: m_head.store(..., release)
Producer: m_head.load(..., acquire)

推导结果：
当生产者通过 acquire 观察到 head 前进时，消费者在 release 之前的所有操作（即读取并清理 Slot）都已完成。

✅ 保证：绝不会在数据未被消费前覆盖 Slot。

为什么 Relaxed 是安全的？

在代码中，relaxed 被用于：

CAS 失败后的重试路径。
Consumer 更新 m_slots 为 nullptr。
Consumer 读取自己的 head。

这些操作的共同点是：它们不承载跨线程的“通知”任务。真正的同步边界（可见性保证）完全由上述两条 Acquire-Release 链条严密把控，relaxed 仅用于降低非关键路径的 CPU 开销。

5. 总结

实现一个生产级的高性能无锁队列，难点不在于代码行数，而在于对内存模型的精准把控：

分离关注点：将“位置抢占”（修改 tail）与“数据发布”（写入 slot）解耦，虽然引入了短暂的中间态，但极大降低了竞争复杂度。
显式同步：利用 Release-Acquire 语义建立清晰的 Happens-Before 桥梁。
最小化开销：在不破坏因果关系的路径上大胆使用 Relaxed。

通过这种设计，我们实现了一个既安全又高效的 MPSC 缓冲队列，完美适配高并发网络 I/O 场景。

Full Code

Luogu P14761 - CCD 的序列【动态序列统计】（之二）

2025-12-27T21:00:00+08:00

在上一篇中，我们已经完成了整道题最关键的建模工作：
把“匹配关系发生变更”转化为区间统计问题。问题最终被化简为：在一个动态变化的序列上，支持区间查询与任意位置插入。

这一篇我们将会讨论：Splay 数据结构本身的功能与实现方式，以及它为什么适合承载这个问题。

1. Splay 是“自调整”的，而不是“显式平衡”的

在 AVL、SBT 等平衡树中，我们的核心目标是维护某种平衡条件。一旦条件被破坏，就通过旋转把树“修回来”。也就是说，平衡是目标，旋转是手段。

Splay 的思路是反过来的。它并不关心当前这棵树“是不是平衡”，而只关心一件事：把刚刚访问过的节点，拉到树的上层。

直观理解就是：
经常被访问的节点，就应该离根更近；这样后续再访问它，代价自然更小。因此在 Splay 中，访问本身，就是结构调整的理由。至于整棵树的形态是否平衡，并不是一个被显式维护的目标。

2. 什么是 splay 操作

splay(x) 的含义非常直接：
通过一系列旋转，把节点 x 拉到当前树的根节点（或某个指定节点之下）。

需要注意的是：

x 不一定是叶子；
整个过程中可能发生多次旋转；
每次旋转都只是普通的左旋或右旋。

Splay 的复杂性不在于旋转本身，而在于旋转顺序的选择。

3. Splay 中的三种经典旋转模式

设当前要 splay 的节点是 x，其父节点是 p，祖父节点是 g。根据 x、p、g 三者之间的位置关系，旋转会分为三种典型情况。

Zig（单旋）

当 p 本身就是根节点（即不存在祖父 g）时，只需要一次旋转。

此时旋转的目标非常明确：
让 x 成为新的根节点。

    p               x
   / \             / \
  x   C   ==>     A   p
 / \                 / \
A   B               B   C

旋转结束后，x 被直接提升到了根位置，这是最简单的一种情况。

Zig-Zig（同向双旋）

当 x 和 p 方向相同（同为左儿子，或同为右儿子）时，就会出现一条“歪着的链”。

这种结构如果只旋一次，无法有效把 x 提到高位。因此需要连续两次旋转：

先旋转 p 与 g；
再旋转 x 与 p。

目标并不是单纯把 x 提到根，而是整体压缩这条同向的访问路径，让常访问的节点整体靠上。

        g                 g                  x
       / \               / \                / \
      p   D   (1)       x   D    (2)       A   p
     / \       ==>     / \       ==>          / \
    x   C             A   p                  B   g
   / \                   / \                    / \
  A   B                 B   C                  C   D

Zig-Zag（反向双旋）

当 x 和 p 方向相反时，结构呈现出“拧着”的形态：

这种情况下，如果直接旋 p 和 g，结构会变得更糟。因此正确的顺序是：

先旋转 x 与 p；
再旋转 x 与 g。

目标是先把结构“拧正”，再把 x 提到更高的位置。

        g                 g                    x
       / \               / \                  / \
      p   D   (1)       x   D     (2)        p   g
     / \       ==>     / \        ==>       / \ / \
    A   x             p   C                A  B C  D
       / \           / \
      B   C         A   B

4. 为什么 Splay 不需要维护平衡条件

直观地看：

如果一棵树长期非常“歪”，
那说明你反复在访问某一侧的节点，
而 Splay 会不断把这些节点旋转到上层，
最终这条路径会被逐渐压缩。

因此，坏结构往往对应“不常用”的访问路径，而常用路径会被不断优化。这也是为什么：

单次操作的复杂度可能很高；
但在一整段操作序列上，Splay 的均摊复杂度是 O(log n)。

在竞赛环境中，这样的保证是足够可靠的。

5. 隐式 Splay 与普通 Splay 的区别

普通 Splay 是一棵标准的 BST，节点中有显式的 key，满足左小右大的性质。

而在本题中使用的是隐式 Splay。换句话说，节点本身不存 key，而是把整个序列按顺序映射到一棵 BST 的中序遍历上。

于是：

中序遍历顺序 = 序列顺序；
第 k 个元素 = 中序遍历第 k 个节点。

这样一来：

查找第 k 个位置；
在第 k 个位置插入；
查询区间 [l, r]；

都可以统一转化为基于子树大小的树操作。

6. 区间信息的维护

在每个节点中，我们维护该节点所代表区间的信息。这一点与 AVL、SBT 等平衡树在旋转中维护区间信息并无本质区别。

旋转只会改变父子关系，不会破坏区间的连续性，因此只要在旋转后正确更新受影响节点的区间信息即可。

7. 为什么 `push_up` 是“三段合并”

在隐式 Splay 中，一个节点天然代表如下区间结构：

[ 左子树 ] + [ 当前字符 ] + [ 右子树 ]

因此在更新节点信息时，只需要按顺序合并这三段区间：

info = merge( merge(left, self), right )
size = size(left) + 1 + size(right)

每一次旋转结束后，只需对被下沉和被提升的节点各执行一次 push_up，区间信息就会自动恢复正确。

8. 总结

到这里，Splay 的功能与实现已经足够清晰了。

在本题中，Splay 本身并不承担复杂的逻辑，它只是提供了一种能够支持动态序列插入与区间定位的结构。真正与题目模型直接相关的，是节点中维护的区间信息及其合并方式。

Luogu P14761 - CCD 的序列【动态序列统计】（之一）

2025-12-20T12:00:00+08:00

1. 题意概述

题目要求维护一个动态变化的合法括号序列。

初始时序列为空。接下来进行 $n$ 次操作，每次操作给定两个整数 $(l, r)$（$0 \le l \le r \le |S|$），表示：

在当前序列的第 $l$ 个插入位置插入一个左括号 '('；
在当前序列的第 $r$ 个插入位置插入一个右括号 ')'。

题目保证：每次操作完成后，整个括号序列仍然是合法的。

匹配关系与“匹配发生变更”

在一个合法括号序列中，每个括号都有且仅有一个与之匹配的括号，匹配关系由括号的嵌套结构唯一确定。

若某个括号在一次操作前匹配的是括号 $A$，在操作后匹配对象变为括号 $B$（且 $A \neq B$），则称该括号的匹配发生了变更。

本题的核心问题

在每一次插入操作完成后，需要输出：

由于本次操作导致匹配对象发生变化的旧括号数量
（不包括本次新插入的两个括号）

2. 题目分析与建模：从匹配变化到区间统计

本题的关键不在于维护“谁和谁匹配”，而在于如何刻画“哪些匹配会发生变化”。

插入操作的结构本质

一次操作在原括号序列 $S$ 上同时插入一对新括号 '(' 和 ')'，并保证新序列仍然合法。

从结构角度看，这等价于：

在原序列中，将一段连续子串整体包裹进一层新的括号中。

给定操作 $(l, r)$，被包裹的原有区间为：

$$ (l+1,\ r) $$

哪些括号的匹配会发生变化？

将原序列中的括号按其位置与匹配关系分类，可以发现：

完全位于区间 $(l+1, r)$ 外的括号，匹配关系不变；
匹配对象也完全位于区间 $(l+1, r)$ 内的括号对，匹配关系不变；
一端在区间内、另一端在区间外的匹配对，其匹配关系一定会发生变化。

因此可以得到结论：

一个旧括号的匹配发生变更，当且仅当它原本匹配的括号与它位于区间 $(l+1, r)$ 的不同侧。

转化为区间统计问题

于是，原问题可以被精确地重述为：

在原括号序列中，统计区间 $(l+1, r)$ 内，有多少括号是与区间外的括号直接匹配的。

为此，引入两个区间统计量：

$open$：区间内无法在区间内部完成匹配的左括号数量；
$close$：区间内无法在区间内部完成匹配的右括号数量。

显然：

$open$ 个左括号必然向区间右侧寻找匹配；
$close$ 个右括号必然向区间左侧寻找匹配。

因此，跨区间匹配对的数量为：

$$ open + close $$

而每一对这样的匹配，会导致两个旧括号的匹配关系发生变化。

核心公式

设区间 $(l+1, r)$ 的统计结果为 $(open, close)$，则答案为：

$$ \text{answer} = 2 \times (open + close) $$

这一步是整道题的建模核心。
问题至此被转化为：如何动态维护括号序列，并支持区间 $(open, close)$ 查询。

区间 $(open, close)$ 在动态插入下的维护方式

单个括号本身就是一个最小区间：

'(' 对应 $(1,0)$；
')' 对应 $(0,1)$。

当相邻区间合并时，唯一可能产生的新匹配是：

左区间剩余的 '('；
与右区间剩余的 ')'。

因此合并规则固定为：

$$ t = \min(open_L,, close_R) $$

$$ \begin{aligned} open &= open_L + open_R - t, \\ close &= close_L + close_R - t. \end{aligned} $$

一次插入操作，本质上只是向序列中插入新的最小区间 $(1,0)$ 或 $(0,1)$，
原有区间内部的匹配关系不会被破坏，只需在插入位置附近按上述规则重新合并区间信息。

3. 为什么需要平衡树，以及为什么选择 Splay

经过建模后，问题转化为：

动态维护一个序列，支持：

任意位置插入元素；

任意区间 $(open, close)$ 查询。

朴素与线段树方案的不足

数组或字符串模拟，中间插入为 $O(n)$，总复杂度 $O(n^2)$；
普通线段树依赖静态下标，无法处理动态插入。

因此需要一种支持动态序列维护的数据结构。

为什么选择隐式 Splay？

隐式 Splay 具备以下特性：

中序遍历顺序即为序列顺序；
通过子树大小隐式表示下标；
可以在节点中维护区间 $(open, close)$；
均摊时间复杂度为 $O(\log n)$。

区间信息如何挂在树上？

在这种序列型树结构中：

每个节点维护的是“以自身为根的一段连续区间”的统计信息；
左子树、当前节点、右子树分别对应三段连续区间；
节点的 $(open, close)$ 由这三部分按合并规则得到。

当插入新节点或树结构调整时，只需在受影响节点处重新计算区间信息，即可保证整体正确性。

4. Splay 树的基本性质（简述）

Splay 树是一种自调整二叉搜索树，通过访问后的一系列旋转操作，将常访问的节点逐渐拉近根节点。

隐式 Splay 不存储显式 key，而是通过子树大小隐式表示序列下标，因此非常适合处理“第 $k$ 个位置”“区间查询”等操作。

5. 实现思路与代码结构

整体实现可以自然分为三层：

括号段信息 $(open, close)$ 的定义与合并；
隐式 Splay 的通用实现（维护 size 与区间信息）；
题目逻辑：查询区间 $(l+1, r)$，计算答案并插入新括号。

单点与区间信息

$$ \text{info}(c)= \begin{cases} (1,0), & c='(' \\ (0,1), & c=')' \\ (0,0), & \text{哨兵} \end{cases} $$

区间合并规则同第 2 节所述。

区间查询与插入

通过两次结构调整，将目标区间隔离为一棵子树，其根节点维护的 $(open, close)$ 即为查询结果。

每次插入与查询的均摊复杂度均为 $O(\log n)$。

总体复杂度

总时间复杂度：

$$ O(n \log n) $$

结语

解决问题的第一步，一定不是写出代码，而是：

正确抽象“匹配发生变更”的含义；
找到稳定、可维护的区间结构量；
选择合适的数据结构承载这一结构。

一旦模型建立，剩下只是工程实现问题。

从字符串替换到图灵机：A=B 的完备性构造

2025-10-01T10:00:00+08:00

0. 背景：A=B 是什么

A=B 是在一款解谜游戏中引入的一种极简编程语言。它的语法只有一种形式：

A = B

含义是“在字符串中找到子串 A，并把它替换为 B”。程序运行过程如下：

从输入串开始；
逐条检查规则，从第一条规则开始，寻找第一个匹配的左部；
一旦找到，就立即执行替换；
然后从头再来（回到规则表开头）；
如果没有任何规则可用，则程序停机，并输出当前字符串。

在游戏后期，会出现扩展关键字（如 (start) 匹配开头、(end) 匹配结尾、(once) 限制只替换一次、(return) 表示立即输出并停机），它们能让表达力更强。但关键是：即使完全不依赖这些扩展，A=B 也已经足够强大，可以达到图灵完备性。

什么是“图灵完备”？

图灵完备表示该系统能模拟任意图灵机：只要时间与存储足够，任何可计算的算法都能实现。直观地，它意味着：

能够存储和操作任意量的信息；
能够分支（条件判断）；
能够循环（无限计算，直到停机）。

证明 A=B 图灵完备，就是证明它并非“替换小游戏”，而是具备通用计算能力的编程语言。

1. 理论背景：字符串重写系统为何图灵完备？

早在 20 世纪初，数学家 Axel Thue 就提出了字符串重写系统（Thue system），研究如何通过规则替换来生成和变换字符串。后来，Emil Post 进一步发展出 Post 规范系统，并证明这类系统足以表达任意可计算过程。

核心结论是：半 Thue 系统（Semi-Thue system，即字符串重写系统）能够模拟任意图灵机。其思路是将“图灵机的一个配置（状态 + 带子内容）”编码成一个字符串，再用重写规则逐步执行机器的转移函数。

下面是维基百科条目给出的一个标准构造：

用字母表中的若干符号表示带子符号（$S_k$）；
用一个唯一的状态标记（$q_i$）表示当前机内状态，并保证它在配置中恰好出现一次。其右侧符号即为当前读头所在位置的带子符号；
向右移动的转移
在图灵机里，“向右移动” 的意思是：读写头在处理完当前位置后，把读写位置移动到右边的一个格子。

$$ \delta(q_i, S_k) = (q_j, S_l, \rightarrow) $$

对应的重写规则是

$$ q_i S_k \to S_l q_j $$

解释：

$\delta$：转移函数；
$q_i$：当前状态；
$S_k$：当前读到的符号；
$S_l$：要写回去的新符号；
$q_j$：更新后的状态；
$\rightarrow$：表示读头右移；
规则的含义是：把「状态 + 符号」替换为「新符号 + 新状态」，等价于完成写入并把状态标记移动到右边。
向左移动的转移
在图灵机里，“向左移动” 的意思是：读写头在处理完当前位置后，把读写位置移动到左边的一个格子。

$$ \delta(q_i, S_k) = (q_j, S_l, \leftarrow) $$

对应一簇规则（需对左邻符号 $S_p$ 枚举）：

$$ S_p q_i S_k \to q_j S_p S_l $$

解释：

当读头左移时，必须知道左边的符号 $S_p$；
左邻符号 + 状态标记 + 当前符号，一起被替换成「新状态 + 左邻符号 + 新符号」；
这使得状态标记成功左移，同时完成写入操作。
无限带子的处理
为了模拟“无限长”的带子，需要在两端加哨兵符号 $h$，并加入特殊的延展规则，使得机器在靠近边界时可以“创造”新的空白格子，从而对应无限内存的假设。

由于每次重写都必须包含且仅包含一个 $q_i$，所以在任意时刻都只有唯一可用的匹配位置。整个替换过程严格对应图灵机的一步步执行。因此，字符串重写系统具备完整的计算能力，也就是图灵完备。

2. 核心命题与证明纲要（把任意图灵机编译成 A=B 程序）

命题. A=B（即使不用任何关键字）也是图灵完备的。

证明思路（构造式归约）
给定任意一台确定性的单带图灵机：

$$ M = (Q, \Gamma, \sqcup, \delta, q_0, q_{\text{halt}}) $$

解释：

$Q$：有限的状态集合；
$\Gamma$：带子符号集合；
$\sqcup$：空白符；
$\delta$：转移函数，定义“遇到某符号时怎么写、状态怎么变、头怎么动”；
$q_0$：初始状态；
$q_{\text{halt}}$：停机状态。

构造一组 A=B 规则，使其在任意初始输入编码上逐步等价地重写到 $M$ 的后续配置，直到停机。

编码配置
用字符串来编码一台机器的状态：

$$ h , L , q_i , R , h $$

解释：

$L$：读头左边的带内容；
$R$：读头当前位置以及右边的内容；
$q_i$：当前状态，只出现一次；
两端的 $h$ 是哨兵，确保机器永远不会“掉出带子”。

生成规则
对每条转移 $\delta(q_i,S_k) = (q_j,S_l,\text{dir})$，生成对应的 A=B 规则：

右移：

$$ q_i S_k \to S_l q_j $$
左移（对所有 $S_p \in \Gamma$）：

$$ S_p q_i S_k \to q_j S_p S_l $$
遇到带子右端（$S_0=\sqcup$）：

$$ h q_i S_k \to h q_j S_0 S_l $$

如果进入停机状态 $q_{\text{halt}}$，没有进一步规则匹配，程序就自然停机。即使没有 (return)，停机时当前字符串就是输出。

正确性
* 唯一匹配位置：每个串里只有一个 $q_i$，所以只有一个规则能触发；这与 A=B 的“从左到右、按顺序找”完全兼容。
* 一步对应：每条替换规则严格模拟图灵机的一步（写入、移动、更新状态）。
* 停机：进入 $q_{\text{halt}}$ 后没有规则匹配，A=B 程序停机。

因此，A=B 可以模拟任意图灵机，所以它是图灵完备的。 $\square$

3. 举例：计数器程序（用例证法说明完备性）

上节我们给出了严格的归约证明，这里再展示一个具体程序：

把输入的二进制数（$1 \leq n \leq 63$）转换成对应数量的 a

程序规则

0 = $X$
1 = $Y$
$$ =
YXXXXX$ = XXXXX$aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
YXXXX$ = XXXX$aaaaaaaaaaaaaaaa
YXXX$ = XXX$aaaaaaaa
YXX$ = XX$aaaa
YX$ = X$a
Y$ = X$a
$X =
$ =

与图灵机构造的对应关系

字母表（Alphabet）
- 符号集合 $\Gamma$：0,1,X,Y,$,a。
- 就像图灵机带子上的有限符号集。
状态（States）
- 在一般构造中，状态由 $q_i$ 标记。
- 在这里，「状态」由当前匹配的模式体现：
  - 匹配 YXXX$ = “状态 = 等待展开 8 个 a”；
  - 匹配 YX$ = “状态 = 等待展开 2 个 a”。
- 所以规则本身就扮演了转移函数 $\delta$。
读写头（Head）
- 在 A=B 里没有显式的“头”，但每次替换只能在一个匹配窗口里发生：
- 例如 YXXX$ → XXX$aaaaaaaa：可以看成读写头在 Y 上，读到右边 3 个 X 和 $，然后写出 a 并右移。
- 例如 YX$ → X$a：可以看成读写头在 Y 上，它左边的 X 会被保留，头位置连带移动到右边继续展开。
右移的体现
- 替换 YXXX$ → XXX$aaaaaaaa：
- 相当于图灵机在 Y 所在格写入若干 a；
- 然后状态标记（匹配窗口）自动“滑到右边的 $”处，继续执行。
- 这对应于「写入后头向右移」。
左移的体现
- 在展开尾部规则 Y$ → X$a 中：
  - 当 Y 已经贴近 $ 时，替换会把 $左边的 X 替出来，并在 Y 的左边补上 a；
  - 这等价于把读写头往左看一格，再进行展开。
- 整个效果就和「写入后头左移」一致。
带子与哨兵（Tape & Sentinel）
- 符号 $ 就是带子的边界标记；
- 末尾两条规则会逐步清理辅助符号，等价于无限带的“空白格”处理。

$X =
$ =

为什么这个例子能说明图灵完备性？

存储：输入二进制串被转写成 Y/X/$ 的带子配置。
分支：不同的规则（YXXX$, YXX$, YX$, …）体现条件分支。
循环：展开过程需要不断触发相同的规则，直到消耗完所有 Y，体现迭代。
左/右移动：匹配窗口的替换效果对应于头在带子上左右移动。
停机：当所有符号都归约成 a，再无规则可用时，程序自然停机。

所以，这个计数器程序已经在完整地模拟图灵机的运行：

字母表 → {0,1,X,Y,$,a}；
状态 → 匹配模式决定；
读写头 → 当前匹配窗口位置决定；
左右移动 → 替换结果把窗口推到左/右；
停机 → 无规则可用。

这说明 A=B 并非“看似字符串替换”，而是真正能模拟一台图灵机。

4. 顺序/左端优先会不会削弱能力？

不会。因为在构造中我们保证了唯一状态标记 $q_i$：

每条规则都包含且仅包含一个 $q_i$；
串中也只有一个 $q_i$；
因此始终只有唯一匹配。

所以，不管是左端优先还是其他策略，运行轨迹都是唯一的，能力不受影响。

5. 关系图（理论坐标系）

A=B：一个带优先级与锚点关键字的字符串替换语言。
Semi-Thue / SRS：字符串重写系统，图灵完备。
Post 规范系统：可化归为 SRS，同样图灵完备。
Thue 语言：非确定性重写为核心的怪诞语言，图灵完备。

6. 结语

形式化：任意图灵机都能编译成 A=B 规则，逐步等价执行 → 图灵完备。
直观例子：A+B 展现了进位传播，A–B 展现了借位传播；它们分别是算术电路的基石，而算术电路+控制逻辑=通用机。

因此，A=B 不只是一个小游戏，而是一个极简却图灵完备的语言。

p.s. 一些参考解法

C++ 的 `volatile`：它到底管啥、不管啥

2025-10-01T09:00:00+08:00

CppCon 2024 — What Volatile Means (and Doesn’t Mean), Ben Saks
(video, slides)

CppCon 2024 上，Ben Saks 做了一场题为 What Volatile Means (and Doesn’t Mean) 的演讲，专门澄清 C++ 中 volatile 的真实语义，以及它被长期误用的原因。

volatile 的设计目标其实非常单一：阻止编译器进行某些会破坏程序语义的优化。
但在现实工程中，它要么被滥用（不必要地关掉优化），要么被误信（以为它能解决并发或同步问题），从而导致非常隐蔽、难以复现的 bug。

这篇文章整理了演讲中的核心观点，重点放在三个问题上：

为什么 volatile 存在
它到底保证了什么、不保证什么
在现实工程中，如何正确而克制地使用它

为什么需要 volatile

volatile 几乎唯一正当、也是最重要的使用场景，是访问硬件寄存器。

在嵌入式系统中，设备通常通过内存映射寄存器与 CPU 通信。这些寄存器在语法上看起来像普通内存，但语义完全不同：

写控制寄存器会触发一次硬件动作；
读状态寄存器可能清除或设置硬件标志位；
同一个地址的值，也可能在程序控制之外随时发生变化。

问题在于：编译器并不知道这些事。
如果你不告诉它某些访问有副作用，它就会把这些地址当成普通对象，自由地进行优化。

没有 volatile，编译器会“更高效地做错事”

下面这段代码是一个典型的 UART 发送路径示例，刻意没有使用 volatile：

std::uint32_t &USTAT0  = *reinterpret_cast<std::uint32_t *>(0x03FFD008);
std::uint32_t &UTXBUF0 = *reinterpret_cast<std::uint32_t *>(0x03FFD00C);

while ((USTAT0 & TBE) == 0) { }
UTXBUF0 = '\r';
while ((USTAT0 & TBE) == 0) { }
UTXBUF0 = '\n';

从人类视角看，这段代码逻辑非常直观：
等待发送缓冲区空闲，然后依次发送 \r\n。

但在优化器眼里，情况完全不同：

循环体为空，条件看起来不会变化，busy wait 可能被折叠成一次判断，甚至直接变成死循环；
两次对状态寄存器的检查在语义上没有依赖关系，第二次检查可能被删除；
两次写发送缓冲区相邻，第二次覆盖第一次，于是第一次写被当作“无用代码”删除。

最终代码可能只剩下一次写入，甚至在某些情况下直接卡死。
这不是编译器“太聪明”，而是程序没有表达真实语义。

volatile 的真实语义

给这些寄存器加上 volatile，本质上是在向编译器传达两点信息：

第一，这些对象的值可能在程序控制之外发生变化；
第二，对它们的每一次读写都可能有副作用，不能被省略、合并或随意重排。

典型写法如下：

std::uint32_t volatile &USTAT0 =
    *reinterpret_cast<std::uint32_t *>(0x03FFD008);
std::uint32_t volatile &UTXBUF0 =
    *reinterpret_cast<std::uint32_t *>(0x03FFD00C);

有了这个声明，编译器就必须老老实实地：

在 busy wait 中反复读取状态寄存器；
保证对发送缓冲区的写不会被提前、合并或删除。

需要特别强调的是：
volatile 的约束单位是对象，而不是“一段代码”。
编译器仍然可以自由重排对非 volatile 对象的访问。

volatile 的声明位置，别修饰错对象

volatile 和 const 一样，都是类型说明符。
它既可以修饰“指向的对象”，也可以修饰“指针本身”。

寄存器访问中，几乎总是需要“所指对象是 volatile”，而不是“指针是 volatile”。

一个简单且不容易出错的经验法则是 East const / East volatile：
先写不带修饰的类型，再把 const 或 volatile 放到你想修饰的那个类型或运算符的右边。

例如，“N 个 const 指针，指向 volatile 的 uint32_t”：

uint32_t volatile *const x[N];

volatile 能做什么，不能做什么

顺序保证是有限的

volatile 能保证所有 volatile 访问之间的相对顺序不会被打乱，即使它们是不同的对象。

但它并不能阻止编译器把非 volatile 的访问重排到 volatile 之前或之后。

下面这个例子是经典反例：

bool volatile buffer_ready;
char buffer[BUF_SIZE];

void buffer_init() {
    for (int i = 0; i < BUF_SIZE; ++i)
        buffer[i] = 0;

    buffer_ready = true;
}

编译器完全可以把 buffer_ready = true 提前执行，
导致另一个线程看到“准备好了”，但数据实际上还没初始化完。

这也是为什么必须明确一点：
volatile 不是线程同步工具。
线程通信应使用 mutex、condition variable、原子类型或内存栅栏。

volatile 不提供原子性

volatile 只影响优化行为，不提供任何原子性保证。

对 volatile 对象的自增、复合赋值或普通写入，通常都会被拆成多条机器指令。在并发环境中，这可能导致数据竞争，甚至读到“撕裂”的中间值。

因此：

需要原子操作，使用 std::atomic<T>
需要建立顺序关系，使用同步原语或内存栅栏
访问硬件寄存器，使用 volatile，但不要指望它解决并发问题

const volatile 的组合很常见

对于“硬件会变，但软件只读”的状态寄存器，可以使用 const volatile：

std::uint32_t const volatile &USTAT0 =
    *reinterpret_cast<std::uint32_t *>(0x03FFD008);

这样既防止误写，又明确告诉编译器该值可能随时变化。

当编译器把 volatile 搞砸时

现实并不完美。Eide 和 Regehr 在 EMSOFT 2008 的研究中发现，多款主流编译器在某些情况下都曾错误优化 volatile，而且新版本未必更少。

工程上常见的应对方式有三种：

第一，局部关闭优化，只在问题函数中降级优化级别；
第二，更换编译器或版本；
第三，用非内联函数包裹 volatile 读写。

实践表明，第三种方法在多数工具链上都非常有效。

int vol_read_int(int volatile &v) { return v; }
int volatile &vol_id_int(int volatile &v) { return v; }

关键点在于：这些函数必须是非内联的。
函数调用本身会形成一个优化边界，迫使编译器保守处理副作用，从而避免错误合并、删除或重排访问。

实用清单

访问硬件寄存器：使用 volatile，只读寄存器使用 const volatile
声明时注意修饰对象，不要把指针和所指对象写反
不要用 volatile 做线程通信
volatile 不等于原子性
遇到工具链问题时，考虑局部关优化、换版本或非内联包裹

总结

volatile 的核心价值只有一个：
告诉编译器，这里的读写可能有副作用，不能被省略、合并或重排。

它不会解决线程可见性、顺序或原子性问题。
在硬件寄存器访问中，它不可或缺；在并发编程中，它几乎从不适合。

一旦越界使用，问题往往不会立刻爆炸，而是以最难调试的方式潜伏下来。

⚠️ 本文根据视频字幕和 slides 由 AI 生成

Deeplearning.ai 《Retrieval-Augmented Generation (RAG)》课程导读（四）

2025-09-29T10:00:00+08:00

[源视频][1]

根据视频字幕生成，是给不想看视频的人准备的速读文档

简介

本部分聚焦 如何将 RAG 系统真正投入生产。你将学习部署前的准备步骤，并回顾多种系统评估策略：既可针对单个组件，也可面向整体系统，同时需在运行过程中持续观测性能表现。课程还特别强调 日志记录 的重要性，它不仅能追踪调用，还能帮助定位低质量响应的根源。

随后，你会接触几项关键实践：

从真实流量中构建 自定义数据集，用客户数据测试系统更新。
在设计与调优中处理常见权衡，如成本、内存、存储与延迟，并学习在不显著降低质量的前提下对齐需求。
探索前沿方法，将 多模态数据（图像、PDF 等）整合进知识库，让系统具备处理非文本信息的能力。

本模块旨在帮助你掌握从原型走向生产的关键实践：建立评估与监控体系，权衡成本、延迟与质量，并通过量化、安全机制和多模态扩展不断优化 RAG 系统。

RAG 评估策略

部署 RAG 的第一步是搭建 可观测性系统，并建立系统化的评估方法。

可观测性与指标收集

系统需同时追踪：

性能指标：延迟、吞吐量、内存、计算资源。
质量指标：用户满意度、回复准确性、检索器召回率。

除聚合统计外，还应保存详细日志，以便追踪单个提示在管道中的流转，定位低效或错误响应。

评估与实验

系统应支持 A/B 测试，便于验证模型切换、提示修改或检索器调整的效果。

评估维度：

范围：
系统级评估 → 把握整体表现
组件级评估 → 定位瓶颈（如检索器或 LLM）
方法：
基于代码 → 自动化、低成本（吞吐量、单元测试）
人工反馈 → 捕捉代码遗漏的问题（用户点赞/点踩、调查问卷）
LLM 作为裁判 → 成本低于人工、灵活，但需防止偏见（如判定“相关/不相关”）

最佳做法是 多方法结合：
性能监控 + 人工标注测试集 + LLM 评估，在低/高成本间取得平衡，同时兼顾系统整体与组件质量。

日志与监控

课程推荐借助 现代可观测性平台，而非完全自建。

以 Phoenix（Arise 开源工具）为例：

追踪：记录提示在 RAG 管道中的完整路径（检索、重排、拼接提示、生成响应），并标注延迟。
指标收集：与 RaaS 库集成，计算检索相关性、验证引用准确性。
实验：支持提示迭代与 A/B 测试。
聚合监控：提供日报与趋势统计，如检索准确率、幻觉率。

但 Phoenix 不覆盖所有需求，如 GPU/内存监控，仍需 Datadog、Grafana 等传统工具。

良好的可观测性管道能形成 改进飞轮：
通过生产流量发现问题 → 在日志和自定义数据集上验证改动 → 优化 → 回到生产环境验证。

定制化评估体系

核心方法是：把 真实用户提示 整理为 自定义数据集，用于回放与对比。

数据集粒度可分：

最小集：仅包含用户输入与最终回复，适合端到端评估。
组件集：额外存储检索结果、重排前后结果、查询重写等，便于诊断具体问题。

实践案例：

在客服场景中，日志分析可能揭示“退款”问题表现良好，而“物流延迟”表现差 → 原因是检索器缺乏相关文档。
在支持文本转图像/图表的系统中，路由 LLM 错误分配任务，导致图表输出错误 → 调整系统提示后修复。

当数据量大时，可用 聚类与可视化 提炼主题（如新品发布、故障排查），再对主题单独评估，发现薄弱环节。

模型量化技术

量化是生产环境中 成本、速度、质量 权衡的关键。

主要形式

LLM 量化：将 16 位参数压缩为 8 位或 4 位，大幅降低显存占用与推理延迟，代价是轻微质量下降。
向量量化：
8 位整数量化 → 体积降至约 1/4，召回率仅下降几个百分点。
1 位（二值化）→ 规模缩小 32 倍，但检索质量损失大；常配合“粗检-重排”。
套娃嵌入：按信息密度排序维度，部分场景只用前 100–500 维快速检索，必要时再全量重排。

实践建议

优先使用 8 位整数量化（适用于 LLM 与嵌入模型）。
结合评估体系，监控延迟、吞吐、召回率、幻觉率，验证量化效果。
可采用“低精度检索 + 高精度重排”组合策略。

总的来看，量化能够在几乎不损失质量的前提下，显著降低显存和存储消耗，并提升推理与检索速度，是生产环境中最实用的优化手段之一。

成本与响应质量的平衡

RAG 的主要成本来自 LLM 推理 与 向量数据库。

LLM 成本优化

使用更小或量化后的模型。
限制令牌数量（减少 top-k，裁剪长段落，设置输出上限）。
选择合适的部署方式：
原型 → 公共推理端点
规模化 → 专用推理硬件（更划算且稳定）

向量库成本优化

分层存储：热数据放 RAM，冷数据放磁盘/对象存储。
动态迁移：根据访问模式自动调整。
多租户优化：只在 RAM 中加载当前活跃租户的索引。

核心思路：用实验与监控量化权衡，确保节省成本不以显著质量下降为代价。

时延与质量的权衡

每新增一个质量优化组件，都会增加延迟。取舍取决于场景：

电商推荐 → 极低延迟优先
医疗诊断 → 高质量优先

优化顺序：

核心 LLM：用小模型/量化模型；路由简单任务给小模型；利用缓存。
管道组件：剔除低性价比步骤（如价值有限的查询生成器）。
检索优化：使用量化嵌入，加快距离计算；或采用数据库分片。

关键原则：持续测量延迟与质量指标，找到项目可接受的平衡点。

安全防护机制

RAG 系统面临独特的安全风险，尤其是知识库中常包含敏感信息。

主要风险：

提示攻击诱导模型泄露文档。
外部调用时暴露知识片段。
向量数据库被入侵。

关键防护：

访问控制：基于身份验证与多租户隔离。
本地化部署：在安全场景中，完全自建 LLM 与数据库。
加密存储：加密文本块，检索后解密；但向量必须明文存放，存在风险。
向量攻击防护：通过加噪、变换或降维降低可逆性（会增加复杂度与性能损耗）。

核心结论：敏感信息必须有明确的边界与控制机制。

多模态RAG系统

多模态 RAG 将文本扩展到 图像（甚至音频/视频），检索与提示均可跨模态，输出仍为文本。

关键机制：

使用 多模态嵌入器 将文本与图像映射到同一向量空间。
使用 语言-视觉模型（VLM） 接收多模态输入并生成文本输出。

在检索流程中：

同模空间检索：查询可为文本或图像，统一编码后进行向量搜索。
文档格式扩展：PPT、PDF 等转为图像再分块嵌入。
PDF-RAG 技术：将页面切分成数百小块嵌入，支持细粒度检索，但会显著增加向量规模。

要点：

架构升级成本低，仅需替换嵌入器和 LLM。
检索更精准，但存储与计算开销增加（可用量化、分层存储、粗检-精排优化）。
生态正在快速发展，主流厂商已推出 VLM，多模态嵌入器逐渐成熟。

一句话总结：多模态 RAG 通过“同空间嵌入 + VLM 生成”打通文本与图像，实现更丰富的知识检索与问答。

总结

进入生产环境后，RAG 系统将面临更复杂的挑战：高流量、不确定性错误、潜在安全风险。
本模块的核心收获：

评估体系：可观测性、日志、系统级与组件级评估。
权衡策略：在质量、成本、延迟之间找到最佳平衡点。
安全防护：确保敏感信息的边界。
多模态扩展：突破文本限制，支持更广泛的知识格式。

至此，你已具备从 原型到生产 构建 RAG 系统的完整基础。课程希望你不仅掌握方法与技巧，也能带着灵感去探索更复杂、更真实的 AI 应用场景。

展望未来十年：C++ 的下一步 —— Herb Sutter @ CppCon 2024

2025-09-29T10:00:00+08:00

⚠️ 本文根据视频字幕和 slides 由 AI 生成

Keynote：Peering Forward: C++’s Next Decade（CppCon 2024）

TL;DR（官方脉络）

重大进展在路上：std::execution 并发/并行、类型与内存安全改进、反射 + 代码生成（“注入”）、Contracts；其中部分内容已进入 C++26 的初始投票/合入节奏。
主旋律：把更多工作“左移”到编译期；以 安全性对标（parity） 为目标（而非完美），逐步减少未定义行为；通过泛化带来简化，让代码直接表达“意图”。

1) 术语澄清：三种“安全”，别混了

Herb 明确区分了三个层面的“安全”，并给出行业场景示例（ISO/IEC 23643:2020 术语脉络）：

Software security（网络/信息安全）：让软件能抵御恶意攻击、保护资产（电网、医院、银行、个人数据等）。
Software safety（生命/功能安全）：避免对人、财产、环境造成不可接受的风险（如医院设备、自动驾驶/武器）。
Programming language safety（语言/内存安全）：对程序正确性的静态/动态保证，既能提升前两者，也能普遍提高质量。

Herb 把“内存安全攻击”称作一场进行中的冷战，强调这既有现实紧迫性，也影响语言设计优先级。

2) 大方向：C++26/29 的主线与“安全对标”目标

优先处理的四大类问题：类型、边界、初始化、生命周期（正好对应最严重的四类 CWE，且现代语言普遍做得更好）。
“安全 Profile” 框架（Stroustrup & Dos Reis）：把（多半已知的）静态安全规则上移到编译期，可按“代码体积/模块”选择地逐步启用，并可增量演进。给“Profile”下了明确定义：一组在编译期强制的规则，保证消除某类缺陷。
采用策略：仍旧坚持“默认性能与可控性”，同时做到“安全随处可用”，愿景是“今天：靠警惕；明天：可选择 opt-out”。

3) C++26 新武器：“erroneous behavior”（错误行为）

3.1 背景与改变

读取未初始化局部变量，传统上是 UB（未定义行为） —— 这会导致“时间旅行/泄密”等坏结果。C++26 将引入“错误行为（erroneous behavior）” 的概念：行为被明确定义为“就是错”，编译器需写入“错误值”，从而避免“UB 的魔法”破坏安全。
量化收益：预计可自动消除一大类（5%-10%） 的漏洞/缺陷，而且无需改动旧代码，只要重编译即可——这对“可采纳性”极为关键。

3.2 小例子（信息泄露不再发生）

auto f1() {
    char a[] = {'s','e','c','r','e','t'};
}

auto f2() {
    char a[6];           // 未初始化
    print(a);            // C++26: 打印“错误值”（绝不会是 "secret"）
}

int main() { f1(); f2(); }

如上示例中，旧世界里常见的“泄密”将不再发生。

为什么不“统一零初始化”？Herb 给出的理由包括：零并不总是语义正确值，且会掩盖真实问题（让静态/动态工具难以发现），还有成本因素（大对象清零）。需要时也可以显式 opt-out：int a [[indeterminate]];。

4) “初始化前置”与“边界安全”：从规范到工程可采纳

不要强行“声明即初始化”或“用模式填充”：这类“塞入无意义写入”的做法会给优化与静态分析带来困境。真正想要的是“首次使用前必然完成初始化（definite initialization）”。Herb 指出 C#、Ada 等已有实践，且在 Cpp2 中已实现原型：
局部变量默认未初始化（性能优先），但任一路径首次使用前必须完成构造；
通过直接构造或“out 形参的填充函数”均可；
这样即可组合化地表达“初始化策略”。
边界检查（Bounds）：在 Cpp2 的实证中，对连续容器的 a[b] 注入 0 <= b && b < size(a) 形式的调用点检查，违例通过契约处理（可自定义）。无需改 STL 或大多数容器实现，也适用于 C 数组（在衰变前）。这类检查可通过将来标准的 “bounds Profile” 一键启用（理念上“启用 Profile 并重编译”）。

示例（越界检测理念）：

//   int              a[] = {1,2,3};
//   std::vector<int> a   = {1,2,3};

print(a[1]);  // ok
print(a[3]);  // 触发边界违例（在 Cpp2 原型中通过契约报告）

5) “海啸将至”：反射 + 代码生成（a.k.a. 注入）

Herb 认为 反射 + 生成 将是未来十年最重要的语言能力，与 constexpr 一同构成“把更多意图抬到编译期”的关键通道；并强调 C++ 是我们想要的“编译期语言”，也是我们想要的“GPU 语言”。

5.1 P2996：以“命令行解析器”为例

struct MyOpts {
    std::string file_name = "input.txt"; // --file_name <string>
    int         count     = 1;           // --count <int>
};

int main(int argc, char* argv[]) {
    MyOpts opts = parse_options<MyOpts>(
        std::vector<std::string_view>(argv+1, argv+argc));
    std::cout << "opts.file="  << opts.file_name << '\n';
    std::cout << "opts.count=" << opts.count     << '\n';
}

parse_options 利用反射枚举数据成员、识别标识符、推导成员类型，并拼接生成解析逻辑（示例里可见 nonstatic_data_members_of, identifier_of, type_of, 以及“splices/注入语法”）。

实现进展：已有 EDG 与 Clang 原型跟进 P2996（EDG：Daveed Vandevoorde；Clang：Dan Katz/Bloomberg；另有 Lock3、Circle、cppfront 等相关探索）。

5.2 P0707（metafunctions/metaclass）：“接口”一键生成

手写接口类（纯虚 + 析构 + 禁复制）：

class IFoo {
public:
  virtual int  f() = 0;
  virtual void g(std::string) = 0;
  virtual ~IFoo() = default;
  IFoo() = default;
  IFoo(IFoo const&) = delete;
  void operator=(IFoo const&) = delete;
};

用元类表达“意图”：

class(interface) IFoo {
  int  f();
  void g(std::string);
};

底层可由 interface(...) 元函数在编译期反射原型并生成上述纯虚骨架与语义约束。

幻灯还给出了 interface 的实现片段：使用 identifier_of, members_of, return_type_of, parameter_list_of 等元函数在编译期拼接类定义。

5.3 “通过泛化获得简化”：三条“北极星”准则

源代码中所有信息都必须可反射（包括属性、默认值等）。
凡是能手写的源代码，都必须能生成（类型、自由函数、对 std:: 模板的特化等）。
所有代码（手写或生成）都必须可见（可 pretty-print、可调试、可展开）。
此处还延展到编译期产物（如 .winmd 等）也应能在编译期生成。

6) 生态/工具的“可表达性扩展”：从 Qt/COM 到物理数据模型

Herb 展示了若干“把外部代码生成/IDL/脚本收回到 C++ 源”的草案式思路：

Qt moc：用 class(Qclass) ... + property/signal/slot 的语义化声明，代替额外的 .moc 生成链路。
COM/WinRT：以 class(rt_interface<...>) 形式表达 IDL 语义（比如 property<UINT, SomeClass>），统一到编译期反射+生成。
粒子物理的 podio：将原本的 YAML 数据模型描述迁回到 class(podio::datatype) 里，用 constexpr 静态字符串与生成管线在常规 C++ 编译中完成同等产物。

7) 更多实用范例

instrumented vector：对模板实体执行 “identity+增强” 的生成（示例在 operator[] 包裹统计逻辑），说明“反射+生成”不仅能复制粘贴，还能普遍地为一类实体注入横切逻辑（计数、日志、检测等）。
编译期 regex：对比 CTRE 与 cppfront 的 @regex，均通过编译期解析/生成专用匹配器以获高效实现，体现“把意图抬到编译期”的性能与可维护性价值。

8) GPU 与 `constexpr` 的共同语言：C++ 本体

幻灯强调了一个观察：多年来 C++ 在 constexpr 的可执行性 与 GPU 编程模型 的融合路径上不断前进，“C++ 就是我们想要的编译期语言，也是 GPU 语言”，因此不要引入背离 C++ 本体的“特殊循环/方言”，而是尽可能让同一语言在不同阶段/目标上自然工作。

9) 风险与设计护栏

这类演进需要“北极星”（目标用例的前瞻清单）与“护栏”（防止底层碎片化导致拼不上整体图景）。
建议目标：P0707 元函数、Andrei 的 instrumented_vector、以及“反射+再生成任意类型（恒等变换）”。
应吸取 C#、D、Lock3、cppfront 等经验，避免“只顾底层细节而忽略端到端场景”。

10) 结语：欢迎来到 C++ 的下一个十年

Herb 的判断：反射+生成 将主导下一个十年；
它会让难事变易（如复杂 Template MetaProgramming、表达式模板），也会让“原本做不到”的事成为可能（如大规模生成式编程）。第一阶段的标准化蓝图已经在望。

Deeplearning.ai 《Retrieval-Augmented Generation (RAG)》课程导读（三）

2025-09-24T10:00:00+08:00

源视频

根据视频字幕生成，是给不想看视频的人准备的速读文档

LLM 简介

RAG 系统由检索器和 LLM 两部分组成。检索器负责找到信息，但真正决定回答效果的，是 LLM。

在这一部分，学习目标包括：

理解 LLM 的工作原理；
掌握提升性能的方法；
熟悉 Transformer 架构；
学习如何在代码中调用 LLM，并逐步改进；
探索一些高级技术和实用建议。

完成后，你将能亲手构建一个小型 RAG 系统。

Transformer 架构

起源

Transformer 架构来自 2017 年的论文 《Attention Is All You Need》。它最初用于机器翻译，由编码器和解码器组成。如今大多数语言模型使用解码器，嵌入模型使用编码器。

输入处理

分词：输入文本切分成 token；
嵌入：每个 token 转换成向量；
位置编码：加入顺序信息；
注意力机制：token 之间相互“关注”，捕捉关联；
* 多头注意力可以从不同角度建模关系；
前馈层：大量参数更新向量；
堆叠：多层重复这些步骤，逐渐提升理解。

文本生成

模型基于向量预测下一个 token 的概率分布；
按概率抽样生成 token；
将新 token 加回输入，重复处理；
直到生成结束符或达到长度限制。

与 RAG 的关系

注意力机制让模型能理解注入的检索信息；
生成存在随机性，可能与检索内容不一致；
计算开销大，是 RAG 成本的主要来源。

LLM 采样策略

LLM 每一步生成 token 都是从概率分布中随机选择。控制随机性很重要。

常见方法：

贪心解码：总选最高概率 → 稳定但僵化；
温度（Temperature）：调节分布尖锐度，低温度更确定，高温度更随机；
Top-K：从前 K 个候选中选；
Top-P（核采样）：从累计概率 ≤ P 的候选集中选；
重复惩罚：降低重复 token 的概率；
对数偏差（Logit Bias）：人为调整特定 token 的概率。

推荐默认配置：

温度 = 0.8
Top-P = 0.9
重复惩罚 = 1.2

应用场景：

低温度 + 低 Top-P：适合代码、事实类任务；
高温度 + 高 Top-P：适合写作、开放问题。

模型选择方法

选择模型会影响速度、质量和成本。

主要指标

参数规模：1–100 亿为小模型，100–500 亿为大模型；
成本：按百万 token 计价；
上下文窗口：可处理的最大输入输出长度；
延迟与速度：响应和生成速度；
知识截止日期：越新越好。

评估方式

自动化基准：如 MMLU、编程测试；
人工评估：如 LM Arena，基于 Elo 排名；
模型评估模型（LLM-as-a-judge）：需注意偏差。

方法论：先用量化指标缩小范围，再用质量评估确认。保持灵活，方便更新替换。

提示词工程（基础）

提示词通常包含：

系统提示（设定语气和规则）；
历史对话；
检索结果；
用户输入。

RAG 中常用提示模板，把这些要素固定下来，方便实验和改进。

提示词工程（高级）

常见技术：

上下文学习（ICL）：在提示中加入示例（one-shot / few-shot）；
推理导向提示：
Scratchpad：先推理再回答；
Chain-of-Thought：逐步推理；
推理模型：自带推理能力，成本更高；
上下文管理：对话过长时进行摘要或剪枝，避免占满上下文窗口。

幻觉处理

幻觉指模型生成的虚假信息。常见类型：

轻微错误（数值说错）；
否认真实事实；
编造不存在的信息。

应对方法：

在系统提示中要求模型只基于检索结果回答，并引用来源；
使用 Context Cite 等工具验证回答与文档的对应关系；
用 ALCE 基准测试幻觉率和引用质量。

性能评估

评估的目标是量化 LLM 在 RAG 中的表现。

常用指标：

相关性：回答是否满足用户需求；
可信度：回答是否由检索文档支持；
其他指标：如引用准确性、抗干扰性（Ragas 库提供）。

还可以结合：

用户反馈（点赞/点踩）；
A/B 测试（对比不同模型或参数）。

建议：结合自动化评估和人工反馈。

自主式 RAG

自主式 RAG 使用多个模型协作，而不是一个模型完成所有步骤。

常见工作流：

顺序工作流：按步骤依次完成；
条件工作流：由路由模型决定是否检索或走哪条路径；
迭代工作流：不断尝试直到合格；
并行工作流：多个模型并行处理，再合并结果。

优势：

小模型负责简单任务（高效低成本）；
大模型负责复杂生成；
专用模型负责引用或验证。

总结

这一部分课程带来的主要收获：

理解 Transformer 架构和 LLM 的工作机制；
掌握采样策略，能控制输出的稳定性与多样性；
学会如何在成本、速度、质量之间选择合适的模型；
掌握提示工程的基本与高级方法；
了解幻觉的成因与缓解方式；
学习性能评估方法；
认识多模型协作的自主式 RAG 思路。

这些内容组成了构建和优化 RAG 系统的完整知识框架，也为将原型发展为生产系统奠定了基础。

Deeplearning.ai 《Retrieval-Augmented Generation (RAG)》课程导读（二）

2025-09-22T10:00:00+08:00

课程视频

根据视频字幕生成，是给不想看视频的人准备的速读文档

简介

在实际生产环境中，信息检索理论需要与大规模数据处理结合。传统关系型数据库虽能支撑大部分基础检索，但当文档规模扩展至数百万甚至数十亿，尤其涉及语义搜索时，其性能会显著下降。

为此，我们需要向量数据库。它专为存储与检索海量向量而设计，几乎等同于 RAG（Retrieval-Augmented Generation）系统的底层设施。本模块的核心目标是：

理解为什么向量数据库在向量检索方面更优；
掌握多种搜索操作的执行方式；
学习在生产级 RAG 系统中常用的优化技术（文档分块、查询解析、结果重排序等）。

ANN 算法

在语义搜索中，关键词匹配与向量相似度是基础。但若直接进行精确向量搜索，随着数据扩展，计算资源消耗与系统延迟会急剧增加。

k近邻（kNN）：计算查询与所有文档向量的距离并排序，返回前 k 个邻居。直观但扩展性差，计算量随数据线性增长。
近似最近邻（ANN）：通过牺牲精确度换取效率，保证结果“足够接近”。

典型方法：

NSW（可导航小世界）：构建邻近图，搜索从随机起点出发逐步靠近目标。速度快但可能错过全局最优。
HNSW（分层 NSW）：构建多层邻近图，从顶层到低层逐步收敛，时间复杂度近似对数级，能在十亿级规模下将延迟保持在几百毫秒。

三大特性总结：

搜索速度远超精确 kNN；
返回近似最优解；
依赖高质量的图构建（预处理耗时但可离线完成）。

因此，ANN 是现代向量检索的核心基础。

向量数据库

向量数据库（Vector Database）专为高维向量的存储与 ANN 检索而设计，在语义搜索中优势明显。

核心优化：

高效构建邻近图（如 HNSW 索引）；
快速计算向量距离；
在大规模应用中保持高扩展性与低延迟。

典型产品：Weaviate（开源，支持本地与云端），同时市面上还有 Milvus、Pinecone 等。

操作流程：

配置数据库：连接或创建实例；
准备数据：生成稀疏向量（关键词搜索）和密集向量（语义搜索）；
创建索引：构建 ANN 所需结构；
添加数据：批量写入集合（如 article），自动生成语义向量并跟踪错误。

支持的检索类型：

向量搜索（基于向量距离）；
关键词搜索（BM25 倒排索引）；
混合搜索（按权重结合语义与关键词结果）；
过滤查询（属性条件筛选）。

流程总结：配置数据库 → 数据加载与索引 → 混合搜索 + 过滤。

文本分块技术

虽然向量数据库已对向量检索高度优化，但在生产环境中，文本分块（chunking）依然是必需步骤。

意义：

嵌入模型有输入长度限制；
分块能提升搜索相关性；
仅将最相关片段传递给 LLM，节省上下文窗口。

问题：若知识库中只有整本书的嵌入，检索相关性差且上下文占用过大。通过分块，可生成数百万片段向量，数据库能高效存储与检索。

方法：

固定大小分块：如 250 字符/块，设置 10% 重叠，避免截断语义。
递归字符切分：优先按换行等标记切分，保持结构完整。
类型感知切分：HTML 按标签，代码按函数，文本按段落等。

推荐默认方案：每块约 500 字符，重叠 50–100 字符。

高级分块技术

基础分块可能破坏语义，因此出现了高级方法：

语义分块：逐句向量化，若与前块相似度高则合并，否则切分。优点是块更符合语义转折，缺点是计算量大。
LLM 分块：用语言模型直接根据语义和主题切分，黑箱但效果好，随着模型成本下降越来越可行。
上下文感知分块（chunk enrichment）：为每块生成摘要或上下文说明并与其一同嵌入，提升检索与生成效果。

结论：多数系统使用固定或递归切分，语义/LLM 分块适合高质量场景；上下文感知分块可与任意方法叠加，常带来双重收益。

查询语句解析

用户查询往往模糊或冗余，直接送入数据库效果差，因此需做查询解析。

常见方法：

查询重写（推荐优先）：利用 LLM 将冗长自然语言转为结构化检索友好语句，常显著提升效果。
命名实体识别（NER）：抽取地点、人名、日期等实体，用于元数据过滤。
假设文档嵌入（HIDE）：生成理想搜索结果的假设文档，嵌入后与知识库匹配。

经验：多数场景下，查询重写是性价比最高的必选步骤；NER 和 HIDE 更适合特定高精度场景。

交叉编码器与 ColBERT

三类语义检索架构：

基础编码器（bi-encoder）：查询与文档分别嵌入，依赖向量数据库搜索，速度快、存储小，但语境交互有限。
交叉编码器（cross-encoder）：提示与文档拼接输入模型，直接输出相关性分数，质量最佳但极慢，仅适合重排序。
ColBERT：文档与查询逐词嵌入，评分时逐词匹配相加，兼具交互性与效率，但存储需求极大。

结论：

默认用 bi-encoder；
重排序用 cross-encoder；
高精度场景（法律、医疗）可采用 ColBERT。

检索结果重排序

重排序（reranking）是在初始检索后、送入 LLM 前进行的关键步骤。

流程：

初始检索返回 20–100 个候选；
用交叉编码器或 LLM 对候选重新打分；
最终选取 5–10 个结果。

优势：既利用 ANN 的高效性，又保证结果质量，显著提升相关性。

工程实现：在大多数框架中，只需为查询添加参数即可启用重排序，改造成本低。实践表明，这是优化 RAG 时最值得优先尝试的手段之一。

总结

本模块内容涵盖了从算法原理到生产优化的完整路径：

ANN 算法：以近似解换取高效搜索；
向量数据库：为高维向量检索而生，支撑大规模 RAG 系统；
优化技术：
文档分块：更细粒度语义捕捉 + 上下文节省；
查询解析：让自然语言提示更适配检索；
重排序：用强模型精修候选结果。

这些方法常与混合搜索组合使用，是大多数生产级系统的标准做法。进阶方法（语义分块、LLM 分块、HIDE 等）则适合在验证效果后引入。

最终，学习者将把这些知识整合进完整的 RAG 系统，掌握从基础检索到性能优化的全链路技能。下一模块将转向 RAG 的另一核心：大语言模型，探索如何在检索结果基础上生成更优答案。

Deeplearning.ai 《Retrieval-Augmented Generation (RAG)》课程导读（一）

2025-09-13T10:00:00+08:00

课程视频

根据视频字幕生成，是给不想看视频的人准备的速读文档

课程背景

核心思想与价值
RAG 将传统检索系统与大型语言模型（LLM）结合，提升回答的准确性和时效性。它能接入额外数据（文档、内部资料等），解决训练数据覆盖不到的事实性问题。常用于客服、内部知识查询、医疗、教育等，是当前最主流的 AI 应用之一。
发展趋势
随着模型输入窗口增大和新一代推理模型出现，RAG 在减少幻觉、处理复杂任务、利用长文档方面进步显著。新趋势包括：

多模型协作（不同模型分工处理环节）；
自主检索策略（模型自行决定查询方式）。

这使 RAG 更智能、更实用。

课程目标
本课程覆盖从入门到进阶的 RAG 技术：数据准备、提示设计、上下文管理、超参调优与系统评估。重点是如何构建、优化和持续改进 RAG 系统，所学方法也能迁移到更广泛的生成式 AI 应用中。
学习收获
学员将系统理解 RAG 原理，掌握构建与调优技能，并具备将其应用到复杂场景的能力。这是一项跨行业的高价值技能。

课程导览

总述

LLM 在问答、总结、改写、代码生成中表现突出，但知识仅限训练数据，缺乏最新、私有、专业信息，容易产生错误或“幻觉”。RAG 通过检索额外上下文，使输出更准确可靠，适应更多场景。

LLM 的能力与局限

LLM 本质是基于概率的“智能补全”：预测最可能的词序列，而非事实。当遇到未知知识（如企业数据或新闻）时，容易生成听似合理但错误的答案。
局限包括：

幻觉问题：模型生成了听起来合理但事实错误的内容
上下文窗口限制：提示过长会增加成本甚至溢出

RAG 架构

RAG = 检索 + 生成：

用户问题 → 检索器 → 找到相关文档；
问题 + 文档 → 增强提示 → 交给 LLM 生成回答。

三大组件：

语言模型：生成自然语言回答；
知识库：存放结构化/非结构化文档；
检索器：搜索并排序最相关的内容。

优势与挑战

优势：

接入外部信息（私有/最新/专业）；
减少幻觉；
更新知识只需替换文档，不用重新训练；
回答可带来源，便于验证；
分工明确：检索器找信息，LLM 负责生成。

挑战：

检索结果排序难以完美；
返回文档过多或过少都会影响效果；
需要持续评估和调优。
向量数据库是高效检索器的核心，但传统搜索引擎和关系型数据库的理念依然重要。

课程展望

后续将深入探讨：

LLM 的生成与训练机制；
检索器的相似度计算与优化；
知识库的设计与更新策略。
学员将掌握原理与工程实践，能在不同场景中优化 RAG 系统。

信息检索与搜索基础

现实挑战：用户提问自然语言；知识库数据多样且为“人读型”；系统需毫秒级返回高相关结果。
目标：掌握检索核心技术、混合搜索、性能评估与调优；通过实操为生产级 RAG 打基础。

检索器架构：混合搜索

流程：查询 → 并行执行关键词检索与语义检索 → 得到候选 → 元数据过滤 → 融合排序 → 返回 Top-k。

三大技术：

关键词检索：快、稳，适合术语/SKU/法条；
语义检索：覆盖同义表达；
元数据过滤：基于权限、地区、时间等硬规则。

融合方法：

RRF（Reciprocal Rank Fusion）
- $d$：一个候选结果（文档/段落/块）
- $i$：第 $i$ 个独立的检索通道（或“基排器”）
- $\operatorname{rank}_i(d)$：$d$ 在通道 $i$ 的名次（1 表示第 1 名，2 表示第 2 名……）。
若 $d$ 不在该通道的候选截断（如 top-50）里，可视为没有贡献（等价于 rank → ∞，分数趋近 0）。
- $K$：一个平滑常数，用来“压低”尾部名次的贡献、凸显头部。
- 越小的 $K$：前几名与后面名次的差距被放大（更偏爱头部）。
- 越大的 $K$：各名次之间差别被缩小（融合更温和）。
- 经验上常取 10～100；也有人把 $K$ 设成与各通道候选截断（如 50/100）同量级。

$$ \text{RRF}(d)=\sum_i \frac{1}{K+\operatorname{rank}_i(d)} $$

线性加权和分
- $\text{score}(d)$：融合后的最终分数（用于排序）
- $\text{score}_{\text{sem}}(d)$：来自语义检索的分数（如余弦相似度、内积或其变体）
- $\text{score}_{\text{kw}}(d)$：来自关键词检索的分数（如 BM25）
- $\beta\in[0,1]$：权重系数，表示语义分数所占比例；$1-\beta$ 是关键词分数比例。
- $\beta$ 大 → 更看重语义；$\beta$ 小 → 更看重关键词。

$$ \text{score}(d)=\beta\,\text{score}_{\text{sem}}(d)+(1-\beta)\,\text{score}_{\text{kw}}(d) $$

业务取舍：关键词优先 → 提高关键词权重；语义优先 → 提高语义权重。

三大技术要点

1) 元数据过滤

基于标题/作者/日期/部门/权限/地区等字段裁剪结果；
- 优点：简单、高速、可审计；能用硬规则保证“该/不该返回”；
- 局限：不考虑内容相关性，不能排序，需与其他检索结合。

2) 关键词搜索（TF-IDF / BM25）

核心思想：根据词频与重要性打分。
优缺点：快、稳、保证命中精确词，但无法处理同义改写，需语义补充。

TF-IDF

$$ \text{TF-IDF}(t,d)=\text{TF}(t,d)\times \text{IDF}(t) $$

其中，$t$ 表示一个词（term），$d$ 表示某个文档。词频（TF）刻画的是词在文档中的相对出现频率：

$$ \text{TF}(t,d)=\frac{f_{t,d}}{\sum_{t'} f_{t',d}} $$

这里 $f_{t,d}$ 是词 $t$ 在文档 $d$ 中出现的次数，分母是文档中所有词的出现总数。

逆文档频率（IDF）则衡量一个词的区分能力：

$$ \text{IDF}(t)=\log\frac{N}{1+n_t} $$

其中 $N$ 是语料库的总文档数，$n_t$ 是包含词 $t$ 的文档数。一个词在语料中越常见，它的 IDF 值就越小，因而在计算 TF-IDF 时权重越低。

BM25

$$ \text{BM25}(q,d)=\sum_{t\in q}\text{IDF}(t)\cdot \frac{f_{t,d}(k_1+1)}{f_{t,d}+k_1\left(1-b+b\frac{|d|}{\text{avgdl}}\right)} $$

这里，$q$ 表示查询，$d$ 表示候选文档，求和遍历查询中的每个词 $t$。

其中的 $\text{IDF}(t)$ 与 TF-IDF 中类似，用来衡量词的区分能力：

$$ \text{IDF}(t)=\log\frac{N-n_t+0.5}{n_t+0.5}+1 $$

公式里的 $f_{t,d}$ 是词 $t$ 在文档 $d$ 中出现的次数；$|d|$ 表示文档的长度（通常用词数计），$\text{avgdl}$ 是语料库中的平均文档长度。

分母部分的参数 $k_1$ 和 $b$ 起调节作用：

$k_1$（常取 1.2–2.0）控制词频饱和度，即当词频越来越大时，得分增加会逐渐放缓；
$b$（取值在 0–1，常设 0.75）控制文档长度归一化，防止长文档因为词数多而天然占优。

换句话说，BM25 在保留 IDF 权重的同时，对词频做了非线性饱和处理，并根据文档长度进行校正，比简单的 TF-IDF 更适合实际检索。

3) 语义搜索（向量检索）

机制：嵌入模型 → 文本 → 高维向量；语义相似 → 向量接近。
相似度度量：余弦相似度、点积、欧氏距离。
流程：建向量索引 → 查询编码 → 相似度搜索 → 返回近邻。
训练直觉：对比学习让相似语义靠近，不同语义远离。注意不同嵌入模型不可直接对比。

评估与调优

在评估检索器或 RAG 系统时，需要三类数据：一组查询、系统返回的排序列表，以及人工标注的“相关文档”基准集。基于这些数据，可以计算以下指标：

1. Precision / Recall（@k）

精确率与召回率是最常见的指标。

$$ \text{Precision@}k=\frac{\#\text{ relevant in top-}k}{k} $$

$$ \text{Recall@}k=\frac{\#\text{ relevant in top-}k}{|\text{Relevant}|} $$

Precision@k：前 k 个结果中有多少比例是相关文档；
Recall@k：前 k 个结果覆盖了多少比例的相关文档。

通常，召回率上升往往会带来精度下降，因此需要根据场景设定合适的 k 值。

2. AP / MAP（排序质量）

平均精度（AP）用于衡量排序效果，强调“相关文档排得越靠前越好”。

$$ \text{AP@}k=\frac{1}{\min(R,k)}\sum_{i=1}^{k}\big[\text{rel}(i)\cdot \text{Precision@}i\big] $$

其中 $R$ 是相关文档总数，$\text{rel}(i)$ 表示第 i 个结果是否相关。

将多个查询的 AP 取平均，就得到 MAP（Mean Average Precision）：

$$ \text{MAP@}k=\text{mean of AP@}k $$

3. MRR（Mean Reciprocal Rank）

MRR 衡量系统把第一个相关文档排在什么位置：

$$ \text{MRR}=\text{mean}\left(\frac{1}{\text{rank of first relevant}}\right) $$

相关文档越早出现，MRR 越高。

调优抓手

BM25：调整 $k_1$（词频饱和）和 $b$（长度归一化）；
语义索引：调整近邻搜索的参数；
元数据：权限、地区、时间窗等过滤策略；
融合层：RRF 的 $K$，线性加权的 $\beta$。

调优方法通常是基于 Precision\@k、Recall\@k、MAP、MRR 的 A/B 测试，验证系统是否“找得到、排得对”。虽然这些指标依赖人工标注，但可以通过抽样和滚动监控，形成持续的评估闭环。

实操与落地

设计顺序：先设定硬过滤 → 再调关键词/语义权重与候选规模 → 最后融合排序。
业务权衡：
法条/零件号/药品名 → 关键词优先；
客服问答/自然语言 → 语义优先。
工程目标：平衡延迟、吞吐与质量；用少量超参（\$k\_1,b,K,\beta\$）做精细调优。

结论

掌握“关键词 × 语义 × 元数据”的混合检索，并用可重复的评估体系迭代优化，是构建可用、可控、可维护 RAG 系统的关键。接下来可以将这些方法应用到生产级检索器和增强提示链路中。

树上启发式合并（DSU on Tree）

2025-07-13T00:00:00+08:00

什么是 DSU on Tree？

DSU on Tree（Disjoint Set Union on Tree），中文称为“树上启发式合并”，是一种用于高效处理树上子树统计类问题的算法技巧。尽管其名称中含有 “DSU（并查集）”，但本质上与并查集并无直接关联。

该方法广泛应用于以下场景：

统计每个节点子树中的某类属性（如颜色种类、频次、权重等）；
在递归过程中合并不同子树的统计信息，显著提升效率；
避免大量冗余的 insert/delete 操作所造成的性能浪费。

其核心策略结合了启发式合并（小的合并到大的）与重儿子优先保留的思想，与树链剖分中的轻重边划分具有一致性。

近年 LeetCode 也多次考察相关题目，说明该技巧即将成为面试中的高频考点（误

问题背景与动机

示例题目：树上统计颜色种类数

题目链接

给定一棵以 1 为根的树，每个节点有一个颜色。
多次询问：以某个节点为根的子树中，有多少种不同的颜色？

输出：对于每个查询，输出对应子树中的颜色种类数。

⚠️ 注意：原题中颜色 c[i] 可能为 0，代码中需进行特殊处理。

为什么不能直接使用树形 DP？

树形 DP 的典型做法是：递归处理每个子节点，将其统计结果合并到父节点。但这种策略在本问题中存在效率问题：

每次合并都需要对 map 或数组进行 insert/delete；
若对子树数据进行暴力合并，可能会产生大量重复操作；
最坏情况下，时间复杂度可能达到 O(n²)。

为解决这些问题，我们引入 DSU on Tree。通过对重儿子保留、轻儿子清除的启发式策略，可以将时间复杂度优化至 O(n log n)。

DSU on Tree 的算法流程

预处理每个节点的子树大小，确定其重儿子（子树最大的孩子）；
以 DFS 遍历整棵树，处理流程如下：

首先递归处理所有轻儿子，并在处理后清除其统计结构；
然后递归处理重儿子，保留其统计结果；
接着将所有轻儿子的统计信息合并到当前维护的结构中；
将当前节点自身的信息加入统计；
更新该节点的答案。

该策略确保：每个节点的信息最多被合并 log n 次，大幅降低了总体复杂度。

算法原理与复杂度分析

正确性说明

DSU on Tree 在整体结构上与树形 DP 一致，都是自底向上合并子树信息。不同之处在于合并顺序与数据结构管理策略更具启发性，从而降低了时间复杂度。其正确性自然继承于递归式的子树遍历结构。

重/轻儿子与边的定义

对于每个节点 $u$：

重儿子：其所有子节点中，子树大小最大的一个；
轻儿子：其余所有子节点；
重边：$u$ 与其重儿子之间的边；
轻边：$u$ 与轻儿子之间的边。

这一划分方式与树链剖分中的定义完全一致，旨在最大程度复用统计结构，减少数据迁移成本。

为什么每个节点最多被合并 $\log n$ 次？

设某节点从根开始向下，在 DFS 过程中每经过一条轻边，子树规模至多减半：

$$ \frac{n}{2^x} \geq 1 \Rightarrow x \leq \log_2 n $$

因此，一个节点作为被合并对象，最多经历 $\log n$ 次合并操作，从而将总体复杂度限制在 $O(n \log n)$ 范围内。

重边的作用

重边连接的是子树最大的孩子。在合并过程中，我们选择保留重儿子的统计结构，不清空、不重建，从而实现结构的复用和效率提升。

伪代码示例

# 全局变量说明：
# g[u]：邻接表表示的树结构
# sz[u]：以 u 为根的子树大小
# big[u]：u 的重儿子（子树最大的孩子）
# col[u]：每个节点的颜色
# L[u], R[u]：u 的 DFS 序区间
# Node[i]：DFS 序编号 i 对应的节点编号
# cnt[c]：颜色为 c 的节点出现次数
# totColor：当前颜色种类数
# ans[u]：以 u 为根的子树的答案

def dfs0(u, parent):
    global time
    time += 1
    L[u] = time
    Node[time] = u
    sz[u] = 1
    for v in g[u]:
        if v == parent:
            continue
        dfs0(v, u)
        sz[u] += sz[v]
        if big[u] is None or sz[v] > sz[big[u]]:
            big[u] = v
    R[u] = time

def add(u):
    color = col[u]
    if cnt[color] == 0:
        totColor += 1
    cnt[color] += 1

def remove(u):
    color = col[u]
    cnt[color] -= 1
    if cnt[color] == 0:
        totColor -= 1

def get_answer():
    return totColor

def dfs1(u, parent, keep):
    # 处理所有轻儿子并清除其贡献
    for v in g[u]:
        if v == parent or v == big[u]:
            continue
        dfs1(v, u, keep=False)

    # 处理重儿子，保留其统计数据
    if big[u] is not None:
        dfs1(big[u], u, keep=True)

    # 把所有轻儿子的 DFS 区间数据合并进来
    for v in g[u]:
        if v == parent or v == big[u]:
            continue
        for i in range(L[v], R[v] + 1):
            add(Node[i])

    # 加入当前节点自身
    add(u)

    # 保存当前节点答案
    ans[u] = get_answer()

    # 若不保留此子树信息，则清除
    if not keep:
        for i in range(L[u], R[u] + 1):
            remove(Node[i])

时间复杂度分析

每个节点的信息最多被合并 $\log n$ 次；
每次合并操作为 $O(1)$（若使用数组）或 $O(\log n)$（若使用 map）；
因此总复杂度为：$ O(n \log n) $

对于多数题目中，颜色值范围有限时可使用数组，使整体操作更接近线性。

例题：LeetCode3575 - Maximum Good Subtree Score

🔗 题目链接

题意简述

给定一棵以 0 为根的树，每个节点有一个整数权值 vals[i]，及其父节点 par[i]。一个子树中，若任意子集中所有节点的十进制表示中每个数字最多出现一次，该子集为“合法子集”。合法子集的得分为其节点权值之和。子集可以不连通。

定义 maxScore[u] 表示以节点 u 为根的子树中，合法子集的最大得分。求所有节点的 maxScore[u] 之和。

解法思路

这是典型的 DSU on Tree 应用场景，适用于子树统计类问题：

每个节点 DFS 时记录子树中数字出现情况（用 bitmask）；
合并时保留重儿子的统计结构，将轻儿子信息逐步合并进来；
遇到重复数字时及时剪枝；
使用“重儿子保留，轻儿子清除”策略，确保总复杂度不超限。

总复杂度控制在 $O(n \log n)$，显著优于暴力枚举或者树形DP。

小结

DSU on Tree 是解决树上子树信息统计类问题的高效工具，其主要优势包括：

避免重复统计，提升合并效率；
时间复杂度优秀，达 $O(n \log n)$；
与树链剖分的轻重边思想互补；
实用性强，广泛应用于竞赛与工程题中。

参考资料

理解 C++ 同步原语的死锁风险

2025-06-22T10:00:00+08:00

并发编程中最容易出错的地方之一，是对同步原语的误用，特别是死锁问题。使用 std::mutex、std::condition_variable 和 std::semaphore 等机制时，一些表面上看似合理的代码，可能在某些边界条件下导致程序卡死，且难以调试。

本文将列举一些典型易错模式，并提供对应的改进建议。

std::mutex 的常见误用模式

1.1 多个 mutex 锁顺序不一致导致死锁

// Thread A
std::lock_guard<std::mutex> lock1(mutex1);
std::lock_guard<std::mutex> lock2(mutex2);
// Thread B
std::lock_guard<std::mutex> lock2(mutex2);
std::lock_guard<std::mutex> lock1(mutex1); // ❌ 死锁风险

问题分析：两个线程以不同的顺序加锁，可能互相等待对方释放资源，造成死锁。
建议：
* 统一加锁顺序（如按锁的内存地址排序）
* 使用 std::scoped_lock 一次性加多个锁（C++17 起）：

std::scoped_lock lock(mutex1, mutex2);

1.2 在持锁状态下调用外部函数

std::lock_guard<std::mutex> lock(mutex);
some_external_function();  // ❌ 如果该函数内部也尝试加锁，可能死锁

建议：避免在持锁状态下调用外部函数。必要时应将调用逻辑移至锁作用域之外。

1.3 锁中递归调用自身或间接调用自己

std::mutex m;
void foo() {
    std::lock_guard<std::mutex> lock(m);
    bar();
}
void bar() {
    foo();  // ❌ 间接递归调用，重复加锁，死锁
}

建议：
* 避免递归持有 std::mutex。
* 若必须递归使用，应改用 std::recursive_mutex，但应慎用。

1.4 使用裸指针或悬空 mutex 对象

std::mutex* m = get_mutex();
std::lock_guard<std::mutex> lock(*m);  // ❌ 如果 m 已析构，行为未定义

问题分析：多个线程共享裸 mutex 指针，生命周期不可控，易造成悬空引用或崩溃。
建议：
* 使用智能指针管理 mutex 生命周期。
* 或将 mutex 作为静态变量或类成员持有。

1.5 手动加锁，异常或提前 return 导致未解锁

m.lock();
if (error)
    return;  // ❌ 忘记解锁，死锁风险
m.unlock();

建议：始终使用 RAII 风格的 std::lock_guard 或 std::unique_lock，避免忘记解锁：

std::lock_guard<std::mutex> lock(m);
if (error)
    return;  // ✅ 安全

std::recursive_mutex 的误用风险

虽然 std::recursive_mutex 允许同一线程多次加锁，但它不是死锁的万灵药，常常掩盖设计缺陷或状态混乱。

示例问题：资源未及时释放

std::recursive_mutex m;
void foo() {
    std::lock_guard<std::recursive_mutex> lock(m);
    // 很长的逻辑，期间可能递归调用自身
}

问题分析：虽然不会死锁，但锁持有时间可能过长，降低系统并发性。
建议：
* 优先重构逻辑，避免递归加锁。
* 仅在确实需要递归的少数场景使用。

std::condition_variable 的常见陷阱

3.1 忘记使用谓词检查条件

cv.wait(lock);  // ❌ 如果通知早于 wait，线程会永久阻塞

建议：始终使用谓词版本：

cv.wait(lock, [] { return condition; });

理由：防止虚假唤醒和时序问题。

3.2 误用 `notify_one()` 与 `notify_all()`

cv.notify_one();  // ❌ 多线程等待时，可能遗漏唤醒

建议：
* 多线程等待时，优先使用 notify_all()。
* 确保 notify 发生时 mutex 已持有，避免竞态。

3.3 wait 前未持有锁

cv.wait(lock);  // ❌ lock 未加锁，行为未定义

建议：必须先通过 std::unique_lock<std::mutex> 加锁，确保 wait() 调用合法：

std::unique_lock<std::mutex> lock(m);
cv.wait(lock, [] { return condition; });

std::semaphore 的使用误区（C++20 起）

4.1 忘记配对 `release()`

std::binary_semaphore sem(0);
sem.acquire();  // ❌ 若未调用 release，线程将永久阻塞

建议：
* 保证每次 acquire() 有对应的 release()。
* 使用带超时版本避免无限阻塞：

if (!sem.try_acquire_for(std::chrono::seconds(2))) {
    // 超时处理逻辑
}

4.2 信号丢失：acquire 在 release 之后调用

std::binary_semaphore sem(0);

void notify() {
    sem.release();  // ✅ 提前释放
}

void wait() {
    std::this_thread::sleep_for(std::chrono::milliseconds(10));  // ❌ 晚于 release 执行
    sem.acquire();  // ❌ 永久阻塞风险
}

问题分析：

std::binary_semaphore 类似一个布尔标志，仅记录是否被释放过一次。
如果 release() 先于 acquire() 调用，且调用之间没有明确同步关系，信号可能“被丢失”。
由于 binary_semaphore 不累加信号（只能表示 0 或 1），先发生的 release() 在没有等待者时不会保存“通知”。
此问题在“先通知、后等待”场景中尤为常见，与 condition_variable 的使用误区类似。

建议：

保证 acquire() 的调用时机在 release() 之前或两者明确同步。
如需支持先通知后等待，改用 std::counting_semaphore，它支持信号积累。
或使用超时接口避免无限阻塞：

if (!sem.try_acquire_for(std::chrono::seconds(2))) {
    // 超时处理逻辑
}

4.3 多线程共享时释放不足

std::binary_semaphore sem(0);
void worker() {
    sem.acquire();
    // 做一些工作
}
void notify() {
    sem.release();  // ❌ 仅释放一次，其余线程会永久等待
}

建议：
* 对 N 个等待线程，应调用 N 次 release()。
* 或使用 counting_semaphore 表示资源总量。

5. 总结建议

所有锁的使用都应结构化管理，优先使用 RAII（如 std::lock_guard）。
加锁逻辑应保持一致性，避免递归加锁、交叉持锁、或生命周期不一致。
条件变量使用时应始终搭配谓词检查，避免时序或虚假唤醒问题。
对 semaphore 等底层原语，应设置超时保护，防止意外永久阻塞。
尽量避免裸指针、手动 lock/unlock 以及难以维护的状态共享逻辑。

使用31mm灯片打造拓竹LED001的低配平替方案

2025-06-22T00:00:00+08:00

拓竹 LED001 套件的标准尺寸为 直径 59mm、高度 35mm（包含灯座和灯板），售价约为 28 元。虽然这是一款常见的标准件，市面上也能买到价格更便宜（约 10 元）的兼容产品，但对于一些轻量级实验或原型用途来说，这个体积可能还是偏大。

举例来说，如果我们将整个 3D 模型按某一维度缩小 50%，理论上材料使用量可以减少 75%，既降低成本，也更便于快速迭代。

幸运的是，拼多多等平台上可以找到 直径 31mm 的小尺寸灯片，带焊 USB 线的版本不到 5 元，裸灯片甚至不到 3 元。只要设计一个对应尺寸的灯板与灯座，我们就能轻松实现 LED001 的低配小型替代方案。

灯板设计

常见的 31mm 灯片实际直径略大，因此建议灯板设计的内径设为 33mm，外径 35mm 为宜。同时预留走线孔和散热孔，确保电源线可以顺利穿过，避免过热。

此外，可选择是否加入导光板：

不加导光板：亮度更集中，但可能刺眼。
加入导光板：可适当柔化光线，提升视觉舒适度。

导光板厚度建议在 0.6mm ~ 1mm 之间，厚一些会降低亮度但提升均匀度。

示意图如下：

灯座设计

在 MakerWorld 平台上可以找到许多 LED001 的灯座模型，这些模型大多采用标准的旋转卡扣设计。我们可以复用这些设计，简单调整尺寸即可适配小尺寸灯片。

推荐使用这个灯座模型：

按 60% 比例 缩小，使其内径为约 36mm，同时扩大出线孔（可以直接在模型中添加负零件。后期用锉刀加工也可以，但是不推荐）。

修改后可直接打印。
👉 缩小版模型可直接下载：点击这里

灯体适配（简单版）

对于原本就设计用于 LED001 套件的灯体，我们同样可以将其 等比例缩小至 60%，从而适配我们的小型灯板与灯座。

以 “涟漪”台灯模型为例：

按 60% 缩小后，仅需约 28.2g 材料 即可打印完成，而原模型则需约 88.7g。

灯体适配（进阶版）

有些灯体模型并非专为 LED001 卡扣设计，或者我们使用的是自己建模的结构，但仍希望引入 LED001 的灯座卡口进行标准化连接。

这时，可以利用 Bambu Lab 切片软件的布尔运算功能，快速完成“翻模”操作，而无需手动建模。

参考这个教学视频，简要步骤如下：

导入模型

导入 LED 灯座卡扣模型并缩放到合适尺寸。
创建一个略大于开孔的圆柱体模型。

2. 布尔运算 - 获取翻模件
将两个模型居中对齐。
右键组合 -> 使用布尔运算“差集”，选择“从中减去”圆柱体，“与之相减”为卡扣模型。勾选“删除输入”。

制作孔洞模型

用生成的“翻模件”再对目标底座进行一次“差集”操作，即可获得精准匹配卡扣的孔位。

小结

通过使用市售 31mm 灯片搭配自制小型灯板和灯座，我们可以：

大幅降低成本（灯片约 3 元，整体成本 <10 元）
节省打印材料（体积缩小后材料用量减少约 70%~75%）
保持模块化设计（可复用 LED001 卡口标准）

适用于快速原型开发、创意DIY灯具、小空间照明等场景。

线段树入门：一种基于不变式的理解方式

2025-06-12T00:00:00+08:00

前言

线段树是一种在算法中频繁出现的数据结构，既实用又略带挑战性。它之所以常见，是因为在涉及区间查询与修改的问题中，线段树常常能提供高效解法；而之所以“高阶”，则是因为在实现过程中需要细致处理边界和递归逻辑，否则容易出现运行时错误（RE），因此也被戏称为“RE 树”（只有我）。

市面上已有不少教程通过图解、动画等方式帮助初学者建立对线段树的直观印象。建议读者在阅读本文前，可先参考这些资料（见文末参考链接），以获得对线段树结构的整体感知。

本文将尝试采用一种更为抽象的方式，从数据结构不变式的角度，系统分析线段树的设计逻辑，并通过若干经典例题，展示如何在实践中运用这些思想来构建高效且可扩展的线段树变体。

基本原理：从递归到不变式

线段树的核心思想是：通过递归划分区间，使每个节点维护一个子区间的信息，进而高效支持查询和修改操作。

示例：求区间最大值

以求解一个长度为 $n$ 的静态数组的区间最大值为例：

设数组为 $\text{array}[1 \dots n]$，我们定义 $\text{maxi}_{i,j}$ 表示区间 $[i,j]$ 的最大值。

当 $i = j$ 时，显然有：

$$ \text{maxi}_{i,i} = \text{array}[i] $$

若 $i < j$，我们可以将其一分为二，划分为 $[i,m]$ 与 $[m+1,j]$，其中 $m = \left\lfloor \frac{i+j}{2} \right\rfloor$，进而递推：

$$ \text{maxi}_{i,j} = \max(\text{maxi}_{i,m}, \text{maxi}_{m+1,j}) $$

这就是线段树的核心不变式：

每个区间的信息完全由其左右子区间决定。

基于这个不变式，我们可以自底向上构建整棵线段树，或在查询和修改过程中维护其正确性。

查询操作

当我们查询一个区间 $[l,r]$ 的最大值时，可以递归地访问其子区间，并合并结果。

最终，查询过程会遍历一组恰好覆盖区间 $[l,r]$ 的子区间，它们的最大值即为所求。

修改操作

点修改

若数组中某个元素发生变动（如将 $\text{array}[k]$ 修改为 $v$），只需从对应的叶子节点出发，沿路径向上传播更新信息，确保不变式在修改后依旧成立。该操作的时间复杂度为 $O(log n)$。

区间修改与懒标记

对于支持区间修改的线段树，其核心操作可以抽象为：

区间更新：对 $[l, r]$ 中的所有元素执行某种操作，如加上一个常数 $c$，即：

$$ \forall i \in [l, r],\quad A[i] := A[i] + c $$

* 区间查询：查询某一子区间 $[l, r]$ 的某个聚合函数，如最小值、和、最大值等。

若直接递归修改所有受影响的节点，则时间复杂度最坏为 $O(n)$。为避免这一问题，引入**懒标记（Lazy Propagation）**机制，通过“延迟计算”优化操作效率。

不变式定义

设线段树的每个节点表示区间 $[L, R]$，维护的信息为 $S_{L,R}$。我们希望维护以下结构不变式：

对于区间加法操作：

$$ S_{L,R} = \sum_{i=L}^R A[i] $$

且满足：

$$ S_{L,R} = \text{Merge}(S_{L,M},\; S_{M+1,R}) $$

懒标记设计

为保持整体结构在多次操作下仍可高效工作，引入延迟标记变量 $\text{lazy}_{L,R}$，用于记录尚未传播的修改信息。更新操作流程如下：

打标记（Apply）：

当整个区间 $[L, R]$ 被完全覆盖时，不递归更新子区间；
只需：

$$ S_{L,R} \leftarrow S_{L,R} + (R - L + 1) \cdot c $$

$$ \text{lazy}_{L,R} \leftarrow \text{lazy}_{L,R} + c $$

下推标记（PushDown）：

当访问某节点的子节点时，将标记下传至左右子区间：

$$ \text{lazy}_{L,M} \leftarrow \text{lazy}_{L,M} + \text{lazy}_{L,R} $$

$$ S_{L,M} \leftarrow S_{L,M} + (M - L + 1) \cdot \text{lazy}_{L,R} $$

同理处理 $[M+1, R]$，然后清除父节点标记：

$$ \text{lazy}_{L,R} \leftarrow 0 $$

此时，每个节点所维护的信息可能暂不符合精确值定义，但满足以下宽松不变式：

若未访问子区间，则本节点记录的是更新后的区间值；一旦访问子区间，将立即下推以恢复精确不变式。

结构不变式对比总结

状态	不变式形式	是否立即满足	性质
普通节点	$ S_{L,R} = \text{Merge}(S_{L,M}, S_{M+1,R}) $	是	严格不变式
有懒标记	$ S_{L,R} = \text{真实值} + \delta \cdot (R - L + 1) $	暂不满足	延迟不变式
下推后	子节点恢复准确值	恢复	最终仍满足整体一致性

如需支持更多操作（如区间赋值、区间最小值+修改等），只需根据操作类型调整：

标记类型：如记录「待加数 $c$」或「待赋值为 $v$」；
Merge 函数：如 $\max$、$\min$、$\sum$；
更新函数的结合律或可交换性是否成立。

只要操作满足结合律与分配律，就可以稳定维护懒标记下的结构正确性。

例题

Luogu P3372 【模板】线段树 1：区间加法与求和查询

本题是线段树的经典模板题，支持两种操作：

区间加值：对区间 $[l, r]$ 内的每个元素加上一个常数 $c$；
区间求和：查询 $\sum_{i=l}^r A[i]$。

实现要点：

每个节点维护当前区间 $[L, R]$ 的区间和 $S_{L,R}$；
引入懒标记 $\text{lazy}_{L,R}$，用于延迟传播加值操作；
满足如下不变式（带标记时）：

$$ S_{L,R} = \sum_{i=L}^R A[i] + (R - L + 1) \cdot \text{lazy}_{L,R} $$

结合懒标记机制，可将修改与查询操作均优化至 $O(\log n)$。

Luogu P1816 忠诚：静态区间最小值查询

题目要求支持多次查询：

给定初始数组 $A[1 \dots m]$，回答若干个区间 $[a, b]$ 内的最小值 $\min_{i=a}^{b} A[i]$。

实现要点：

每个节点维护对应区间的最小值 $M_{L,R} = \min_{i=L}^{R} A[i]$；
不涉及任何更新操作，结构在初始化后保持不变；
查询过程仅需递归访问覆盖区间，合并左右子树最小值即可。

由于为静态查询问题，可选用 ST 表（稀疏表）进行预处理，查询时间降至 $O(1)$，此处不再展开。

Luogu P1558 色板游戏：区间赋值与状态统计

本题是典型的“染色问题”，操作包括：

将区间 $[l, r]$ 染为颜色 $c$；
查询区间 $[l, r]$ 中不同颜色的种类数（颜色数 ≤ 30）。

实现要点：

每个节点维护区间颜色集合 $C_{L,R}$，使用 30 位整数位运算记录状态（例如第 $k$ 位为 1 表示颜色 $k$ 存在）；
支持区间赋值，需使用懒标记 $T_{L,R}$ 表示待覆盖的颜色值；
不变式表达为：

$$ C_{L,R} = \begin{cases} \text{bitmask of color } c & \text{若整段染色为 } c \\ C_{L,M} \,|\, C_{M+1,R} & \text{否则} \end{cases} $$

查询通过统计 $C_{L,R}$ 中二进制 1 的个数来获取颜色数。

小结

线段树的设计之所以高效，是因为它通过递归划分 + 不变式维护，使得复杂的区间操作能够以对数级别的时间完成。

本文从不变式角度出发，分析了线段树的构造与操作逻辑。与常见的图解类教程相比，这种方法更强调原理和形式化思维，适合希望进一步深入理解线段树本质的读者。

参考链接

为什么我不建议你阅读《数据密集型应用系统设计》（之四）

2025-06-11T00:00:00+08:00

分布式系统中有太多可能出错的场景，而系统几乎不可能“停下来检修”。这意味着，我们必须构建更加容错的基础架构。

为此，我们需要在系统底层建立抽象和相应的技术保证，使得上层的应用程序可以安全、稳定地依赖这些机制，无需重新实现一套复杂的机制。

一致性保证

在分布式系统中，一致性是一个复杂且微妙的问题。不同的业务场景，对一致性的需求不尽相同，而所能容忍的成本与代价也各异。

在之前的文章中，我们探讨了最终一致性（Eventual Consistency）这一模型。它是众多一致性模型中最宽松的：

如果我们停止写入系统，并等待足够长的时间（这个时间无法事先确定），最终系统中所有副本将趋于一致。

最终一致性强调的是“收敛性”，即系统会最终走向一致，但不保证当前时刻的一致。

之所以无法保证当前一致，是因为复制滞后——在副本间传播写入时，网络延迟和系统异步执行都会导致各节点状态暂时不一致。而这种“暂时不一致”，并非 bug，而是架构选择。

最终一致性的系统往往隐藏了更多的分布式状态和复杂边界。它不能提供类似单线程内存模型中“变量读写”的那种直观抽象，导致调试困难、测试成本高，尤其在系统负载加剧时，容易触发一些罕见但致命的临界条件。

所以，对于只提供弱一致性的数据库，开发者必须认清它的边界与局限，不能盲目乐观。

而为了解决一致性带来的混乱，分布式系统提供了一系列“协调副本状态”的抽象，比如我们接下来要讲的线性化、因果一致性、时间戳排序、全序广播等。

可线性化 —— 最强一致性模型

线性化（Linearizability），也常被称为强一致性，是最容易被开发者理解的一致性模型：

每一个读写操作，都可以被看作在某个全局时间点原子地生效，并且整个系统的行为符合这种时间顺序。

这意味着，从用户视角看，系统就像单线程执行的一样——操作是顺序的、有先后因果的，而且结果即时可见。

可线性化的依赖条件

要满足线性化，系统通常需要：

所有读操作都返回最近一次写入的数据
不同节点对操作顺序具有一致感知
有一个隐含的“全局时钟”或其等价机制

显然，这并不容易。它需要精密的同步机制和分布式共识协议来支撑。

线性化的代价

线性化虽然语义简单、抽象强大，但它在工程实现上代价极高：

通常依赖主节点选举和日志复制
网络延迟成为性能瓶颈
可扩展性受限（横向扩展能力弱）
容错能力下降，尤其在出现网络分区时表现脆弱

这就引出了著名的 CAP 定理：一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）。线性化牺牲的是可用性，以保证在发生分区时仍维持一致性。

因果一致性（Causal Consistency）

因果一致性是介于最终一致性与线性化之间的一种“中等强度”的模型。

它的核心思想是：

如果操作 A 可能影响了操作 B，那么系统必须保证：任何观察到 B 的节点，也必然先观察到 A。

例如，在社交平台中，Alice 发了一条状态，Bob 回复了她。这时，任何用户必须先看到 Alice 的状态，才可能看到 Bob 的评论。

要实现因果一致性，系统必须追踪操作之间的因果链条。典型做法包括：

向量时钟（Vector Clocks）
会话上下文（Session Context）
客户端因果链追踪（如 CRDT）

相较于线性化，因果一致性在性能上更友好，但在编程模型上要求更高的注意力。

序列号或时间戳排序

为了协调副本之间的写入冲突，系统通常会给写操作分配一个逻辑时间戳，常用的包括：

Lamport 时间戳
递增序列号
物理/混合时钟（如 Google’s TrueTime）

这些机制的目标是为系统内所有事件建立一个“看似有序”的序列，从而为副本间的状态合并提供基础。

但问题也不少：

多个节点产生相同时间戳时如何决策？
如何确保时间戳在大规模集群中全局唯一？
混合时钟如何处理物理时间漂移与延迟？

这类机制常用于实现因果一致性、幂等写入检测或版本冲突解决，实用但远非完美。

全序关系广播（Total Order Broadcast）

全序广播的核心目标是：

所有节点对一组消息的接收顺序必须一致。

这就像是让所有节点“看到”相同的操作日志顺序，确保系统状态演化路径一致。这对如下场景至关重要：

分布式事务日志（如 Kafka、Paxos Log）
数据库复制与回放
状态机复制（如 Raft）

全序广播通常需要依赖共识算法来保证顺序的一致性，因此它和一致性协议的关系非常密切。你可以将其看作是共识协议的一种应用层实现形式。

分布式共识（Consensus）

分布式共识是分布式系统的核心。它的目标是：

即便在节点宕机、网络延迟、消息丢失等非理想环境中，仍然能保证一组节点就某个“唯一值”达成一致。

常见的应用包括：

主节点选举
复制日志的一致提交
配置与元数据协调

支持容错的共识算法

目前主流的共识协议包括：

Paxos：学术上最完整，工程上最复杂
Raft：简化版 Paxos，利于实现和理解
Zab：ZooKeeper 中使用的专用协议

它们的基本流程类似：

各节点发起提案，包含提议值和 epoch id，其他节点进行投票。当某个提案获得多数票后，该值即被“决定”。

这像一个“比大小”的游戏，epoch 越新越有可能胜出，直到系统收敛。

不过必须注意：共识协议是为容错设计的，但并不意味着可以无视网络分区和性能代价。CAP 定理再次提醒我们：一致性始终是有代价的。

成员与协调服务

由于共识协议实现复杂，很多系统选择将其“外包”给专门的协调服务，例如：

ZooKeeper
etcd
Consul

这些服务本质上就是“稳定的共识引擎”，上层系统可以通过它们来实现：

分布式锁
主节点选举
元数据同步
系统配置管理

这样做的好处是：将一致性问题封装起来，提高系统的可维护性和模块边界清晰度。

总结

分布式系统的本质，是在不确定性中构造确定性。

从最终一致性到线性化，从因果一致性到共识算法，它们本质上都是为了解决两个问题：

多个副本之间的状态同步
在出现错误时如何容错恢复

这些模型和协议提供了理解系统行为的理论基础，但也往往隐藏了巨大的实现成本与工程权衡。

《数据密集型应用系统设计》这本书内容详实、系统全面，但我不推荐所有人都去读它。你可以把它当作一本“术语手册”来看，用来厘清概念和搭建知识图谱。而理论与工程实践之间的 gap，往往需要更微观、更贴近落地的视角去补足。

这是本系列的最后一篇。在撰写过程中，我有意识地对原书的内容做了裁剪和重组，目的是为了让读者更快理解背后的核心思想，而不是陷入细节。

感谢你的阅读，我们下一个话题见。

Abel 求和公式在算法竞赛中的应用

2025-06-02T00:00:00+08:00

Leetcode 3500. Minimum Cost to Divide Array Into Subarrays

链接：英文 | 中文

题目大意

给定两个等长数组 nums 和 cost，以及一个整数 k，你可以将 nums 分割成若干个非空连续子数组。第 i 段子数组（编号从 1 开始）为 nums[l..r]，其代价计算方式如下：

$$ f(l, r, i) = \left( \sum_{j=0}^r \text{nums}[j] + k \cdot i \right) \cdot \left( \sum_{j=l}^r \text{cost}[j] \right) $$

目标是通过某种划分方式，使得总代价最小。

约束条件

$1 \leq n \leq 1000$
$1 \leq nums[i], cost[i], k \leq 1000$

直观的解法：三重循环暴力 DP

我们定义状态：

dp[i][j] 表示前 j 个元素分成 i 段的最小总代价。

转移方程为：

$$ dp[i][r] = \min_{l < r} \left\{ dp[i-1][l] + f(l+1, r, i) \right\} $$

即使使用前缀和将单次 $f(l+1, r, i)$ 的计算复杂度优化到 $O(1)$，每次仍需枚举 $n$ 次转移，总体时间复杂度仍为 $O(n^3)$，无法通过本题。

Abel 求和公式优化

Abel 求和公式简介

Abel 求和公式是一种优化形如 $\sum a_i b_i$ 的乘积和的技巧，适用于以下场景：

$a_i$ 是单调或线性变化
$b_i$ 可以预处理为前缀和

当然，根据交换率，$a_i$ 和 $b_i$ 可以互换

公式如下：

$$ \sum_{i=1}^n a_i b_i = B_n a_n - \sum_{k=1}^{n-1}B_k(a_{k + 1} - a_{k}) $$

其中：

$B_i = \sum_{j=1}^i a_j$，是从 $b_1$ 开始的前缀和；
$B_{0} = 0$。

几何意义与解释

可以将 $\sum a_i b_i$ 理解为“宽度为 $a_i$，高度为 $b_i$ 的矩形”所构成的总面积。Abel 求和的思想，相当于用一套更容易累加的方式来表达这些面积之和。

（图源：Easymath-wiki）

加法形式变体（对称结构）

还有一种对称的加法表达：

$$ \sum_{i=1}^n a_i b_i = \sum_{i=1}^{n} (B_{n} - B_{i - 1}) \cdot (a_{i} - a_{i - 1}) $$

此时，有$a_0 = 0$和$B_0 = 0$。

在 Leetcode 3500 中的应用

我们再看代价函数：

$$ f(l, r, i) = \left( \sum_{j=0}^r \text{nums}[j] + k \cdot i \right) \cdot \left( \sum_{j=l}^r \text{cost}[j] \right) $$

将其拆为两部分：

与数组值相关的部分：

$$ g(l, r) = \left( \sum_{j=0}^r \text{nums}[j] \right) \cdot \left( \sum_{j=l}^r \text{cost}[j] \right) $$

用前缀和即可在 $O(1)$ 时间内得到 $g(l, r)$。

与子数组编号 $i$ 相关的部分：

$$ h(l, r, i) = k \cdot i \cdot \left( \sum_{j=l}^r \text{cost}[j] \right) $$

这类“线性编号 × 区间和”的结构，正是 Abel 求和思想的典型应用场景。我们可以通过Abel求和将其转化为如下形式：

$$ \begin{align*} h'(l, r, i) &= k * \sum_{j=1}^{r}cost[j] * ((i + 1) - i) \\ &= k * \sum_{j=1}^{r}cost[j] \end{align*} $$

注：$h'$函数中计算的是cost数组的后辍和。并非$h$函数中的$(l, r)$区间和。

这样一来，$h'(l, r, i)$只与变量$r$相关，进而减少了DP的状态空间。

时间复杂度优化

通过将 $f(l, r, i)$ 拆解，并借助前缀和 + Abel 求和思想，我们将原本 $O(n^3)$ 的三重循环 DP 优化为：

单次状态转移：$O(1)$
空间复杂度：$O(n)$
总体复杂度：$O(n^2)$

可以通过本题的数据范围限制。

小结

Abel 求和是一种处理“数列乘编号”类结构的经典技巧，虽然起源于数学，但在很多竞赛问题中都能找到它的影子。特别是在涉及“编号 × 权重”、“位置 × 值”这种结构时，它常常提供一种结构性的优化方式。

在 Leetcode 3500 中，它帮助我们把三重循环的 DP 优化为 $O(n^2)$；在 CF1175D 中，它转化为一个“最大权重选取”问题。虽然应用方式不同，但核心思想是一样的。

参考

为什么我不建议你阅读《数据密集型应用系统设计》（之三）

2025-06-01T00:00:00+08:00

分布式存储系统的常见挑战

“不可靠”的数据复制

在上一篇文章中，我们讨论了数据的复制机制。在理想情况下，副本间的数据同步通常能在毫秒级内完成（跨地域时可能达到百毫秒级）。但实际环境远不总是理想的。由于网络抖动、链路中断、节点重启等因素，数据复制在某些情况下会出现秒级甚至分钟级的延迟；如果遇到节点长时间下线，更可能出现数据副本严重不一致的情况。

这对复制协议提出了巨大的挑战：

如果采用同步复制协议，即每条写入都要求所有副本成功确认后才能返回成功，那么只要有一个副本故障或延迟，整个写入流程就会阻塞，严重影响系统可用性；
如果采用异步复制协议，虽然可以提升可用性和写入吞吐量，但容易出现副本间状态不一致的情况。一些“快副本”已经处理完最新写入，而“慢副本”可能仍滞留在较旧的版本，导致相同的读请求在不同副本上返回不同结果，这种行为是反直觉的。

这类副本不一致的问题，通常需要借助 版本号、向量时钟、或者合并策略来解决。但在用户可见的数据上，这类差异往往会被感知为“数据不稳定”或“系统不可靠”，尤其在多地部署、跨区域访问的系统中尤为显著。

“不可靠”的时钟

在分布式系统中，时钟同步是一个长期未解的“老问题”。这是因为每台机器的硬件时钟本身就存在漂移，而借助网络同步协议（如 NTP）也会不可避免地引入延迟抖动与误差上限。虽然可以通过部署 GPS、原子钟等硬件来获取更高精度的时钟，但这会显著提高运维成本，也并不适用于所有场景。

时间不可靠，会直接影响到基于时间戳的操作决策 —— 比如选择最新版本的数据、判断操作先后顺序、设定超时等。

为了绕开对物理时间的强依赖，分布式系统通常会引入以下两种方案：

单调逻辑时钟（如 Lamport Clock）：不依赖真实时间，仅保证“事件先后”的单调性，即后来的事件时间戳总大于前一个。这在因果性判断中非常有用。
混合时钟（如 Hybrid Logical Clock）：结合物理时间和逻辑时钟，在尽量保留实际时间语义的同时，兼顾可比性和单调性，是一些新型分布式数据库（如 CockroachDB）所采用的策略。

此外，也有像 Google Spanner 那样的系统使用了更激进的手段 —— 它基于 GPS 和原子钟构建了一个全局“置信时钟窗口”（TrueTime），允许系统在已知的最大时钟误差范围内进行一致性推理。这虽然代价较高，但在需要严格全球一致性的场景中是当前最实用的路径之一。

分布式事务

在分布式数据系统中，最典型的应用场景是键值存储。对于这类系统，单次读写往往就是一个完整的业务操作。系统的可靠性此时主要依赖副本机制来保障：在多数情况下，只要数据成功写入任意副本（或写入达成多数派确认），系统即可对外返回成功，后续的副本同步则交由后台异步处理。

然而，随着业务复杂性提升，单点读写已不足以覆盖所有逻辑。此时，我们需要将多个相关的读写操作打包为一个原子性的操作单元 —— 这正是事务产生的背景。

事务的核心目标非常明确：要么全部成功，要么全部失败。这大大降低了开发者的心智负担 —— 无需再为中间状态的异常处理编写大量补偿逻辑，系统也能避免因“部分提交”造成的数据污染。

分布式事务的 ACID 与 BASE

传统数据库中的事务遵循 ACID 原则：

A（Atomicity，原子性）：事务中的所有操作必须全部完成，或全部不做；
C（Consistency，一致性）：事务完成后，系统从一个一致状态转变到另一个一致状态；
I（Isolation，隔离性）：并发执行的事务互不干扰；
D（Durability，持久性）：一旦提交的数据不能丢失，即使系统崩溃。

然而在分布式环境下，严格遵守 ACID 通常意味着高延迟、复杂的锁管理，以及对网络中断的极度敏感。在追求高可用、横向扩展、低延迟的背景下，许多系统转而采用更宽松的 BASE 理论：

Basically Available（基本可用）：系统即使出现故障，也尽量保持部分功能可用；
Soft State（软状态）：系统状态在一段时间内允许不一致；
Eventual Consistency（最终一致性）：只要不发生新的更新，所有副本最终会趋于一致。

BASE 并不是 ACID 的“反面”，而是为了解决分布式条件下“网络不可靠”“节点不可用”“复制延迟”等问题所做的一种实用妥协。ACID 更强调一致性和正确性，BASE 更强调可用性和恢复能力。

事务隔离级别：性能与一致性的权衡

在支持事务的分布式系统中，另一个核心挑战是如何处理并发读写引发的数据冲突。这决定了系统提供的隔离级别（Isolation Level）。

理想状态下，我们希望事务之间完全串行执行 —— 没有任何交叉。但这会带来严重的性能瓶颈。因此系统通常设计多个隔离等级，提供不同程度的并发控制：

读已提交（Read Committed）
每个事务只能读取到其他事务“已提交”的数据。这避免了脏读，但仍可能出现“不可重复读”（同一条记录先后读取结果不同）。
快照隔离（Snapshot Isolation）
每个事务在开始时看到的是数据库的某一时刻快照。虽然可避免脏读和不可重复读，但无法防止 写倾斜（Write Skew） —— 多个事务读取相同状态后独立写入，结果违反了业务约束。
可重复读（Repeatable Read）
每次读取相同记录得到的值不变，但对于范围查询仍可能遇到 幻读（Phantom Read） —— 第二次查询返回了新插入或删除的行。
串行化（Serializable）
最强隔离等级，要求事务执行效果等同于串行执行。能彻底消除幻读、写倾斜等问题，但开销也最大。常见实现方式有：
基于锁的两阶段锁协议（2PL），强制事务在获取锁后完成或回滚；
基于版本控制和冲突检测的 SSI（Serializable Snapshot Isolation），通过检测事务之间的读写依赖关系，在提交时回滚冲突事务。

这一系列隔离等级背后，其实是一致性、并发性与可用性三者之间的动态权衡。系统必须根据业务特点和性能要求，选取合适的隔离级别。

小结

分布式存储系统并不只是“多放几份数据”这么简单。它必须在不可靠的网络、失效的节点、漂移的时钟和冲突的写入之间，构建起一个对用户“看起来稳定可靠”的系统。而这背后，是副本同步机制、时钟模型、事务协议与一致性等级等一系列工程权衡与设计抉择。

我们无法一劳永逸地解决所有问题，只能根据具体场景选择合适的折中方案。正如你所看到的：CAP 不可兼得，ACID 与 BASE 各有利弊，串行化隔离并非银弹 —— 分布式系统的设计，从来都是一场关于“权衡”的艺术。

在接下来的文章中，我们将继续探索分布式系统中的一致性定义和常见一致性模型的适用场景 —— 如果有下一篇的话。

可控扩容与扩展中国剩余定理：NoSQL 分区实践

2025-05-28T00:00:00+08:00

在现代分布式数据库中，Hash 分区（Hash-based Partitioning） 是最常用的数据分布策略之一。系统通过对 key 取 hash，再对分区数 N 取模，将数据路由到对应分区。

当业务增长带来存储与吞吐瓶颈时，系统需要扩容 —— 将原来的 N 个分区扩展为更多的 M 个分区。但这个过程并非总是轻松，特别是当 N 与 M 无明显倍数关系时，数据迁移可能代价巨大。

本文提出一种数学结构驱动的新思路：通过构造满足一定约束的 N→M 映射，并借助扩展中国剩余定理（Extended Chinese Remainder Theorem, ExCRT），实现更可控的数据迁移方案。

常规扩容：N → 2N 或 3N 的便利与局限

在实际工程中，最常见的扩容方式是将分区数从 N 扩展为 2N、3N 等倍数。这种方式之所以流行，是因为它具备天然的结构优势：

映射关系明确：每个原始分区的数据可以均匀地映射到固定数量的新分区；
实现简洁：只需在 hash 值的基础上调整模数，或者通过位移和除法即可建立新旧分区的映射；
迁移可控：通常只需部分数据迁移，许多 key 会继续留在原本映射到的区域附近。

例如，从 N = 8 扩容到 M = 16 时，典型映射如下：

new_partition = hash(key) % 16
old_partition = new_partition // 2

原分区 0 中的数据只会被重新分布到新分区 0 和 1 中，迁移边界明确。

然而，倍数扩容也存在明显问题：

当 N 本身已经非常大（如数百或数千分区）时，倍数扩容意味着将系统容量翻倍甚至三倍，这往往会带来 资源浪费 和 分布不均衡 的风险。与此同时，维护成本和状态空间也会成倍上升。

这引出一个更具挑战性的问题：

是否有办法将 N 扩展为一个比 2N 更小、但又能满足容量需求的M，同时避免无序重分布带来的高迁移成本？

一个新思路：ExCRT 限定映射构造

如果我们将分区扩容问题抽象为一个模运算系统：

原始分区: x ≡ a₁ (mod N)
目标分区: x ≡ a₂ (mod M)

我们的目标是：给定原始分区编号 a₁，找出所有可能的目标分区编号 a₂。

利用扩展中国剩余定理（ExCRT）

将上述两个同余方程组成一个系统：

x ≡ a₁ (mod N)
x ≡ a₂ (mod M)

根据 ExCRT 的结论，这个系统有解当且仅当：

a₁ ≡ a₂ (mod d)，其中 d = gcd(N, M)

换句话说，只有满足 a₂ ≡ a₁ mod d 的目标分区编号是合法的。

因此，对于每一个原始分区 a₁，其可映射的目标分区 a₂ 并不是全部 M 个，而是受限于这个模 d 的条件。

举例说明：有限映射如何形成

假设我们要将分区数从 N = 12 扩容到 M = 20，由于：

gcd(12, 20) = 4

我们知道，每个原始分区 a₁ ∈ [0, 11] 映射到的新分区 a₂ ∈ [0, 19] 必须满足同余关系：

a₂ ≡ a₁ mod 4

例如，对于原始分区 a₁ = 5，符合条件的目标分区为：

a₂ ∈ {5, 9, 13, 17}

这意味着：

每个原始分区最多只会映射到 M / gcd(N, M) = 5 个目标分区，而不是全部 M 个，极大地压缩了数据迁移空间。

下面是完整的映射关系示例：

原分区 `a₁`	合法目标分区 `a₂ ∈ [0, 20)` 满足 `a₂ ≡ a₁ mod 4`
0	{0, 4, 8, 12, 16}
1	{1, 5, 9, 13, 17}
2	{2, 6, 10, 14, 18}
3	{3, 7, 11, 15, 19}
4	{0, 4, 8, 12, 16}
5	{1, 5, 9, 13, 17}

以此类推，每个原始分区只会映射到与自身模 d 同余的一组目标分区，构成了一个模 d 分类的稀疏映射结构。

这就是扩展中国剩余定理在扩容中的价值所在：

不仅使映射可解，而且使映射受限、有结构、可控，从而有效避免全连接映射带来的大规模数据迁移。

映射空间的压缩优势

更进一步地，我们可以对比两种映射方式的边数量：

映射方式	映射边数量	是否全连接
传统全连接	`N × M`	是
本方法（ExCRT）	`N × (M / gcd(N, M))`	否

换句话说，我们将可能的连接数压缩了一个因子 gcd(N, M)，极大减小了数据重分布带来的迁移成本。

总结与展望

本文提出了一种结合扩展中国剩余定理的 NoSQL 分区扩容方法：

通过控制扩容目标 M 与原始分区数 N 的公约数；
使用 ExCRT 构造原分区号与目标分区号之间的合法映射；
从数学上限定了数据迁移路径，避免无序重分布；
显著减少了迁移成本和系统不稳定性。

为什么我不建议你阅读《数据密集型应用系统设计》（之二）

2025-05-26T00:00:00+08:00

分布式数据系统：从“加机器”说起

当单台机器再也扛不住不断增长的存储和计算需求时，我们别无选择，只能走上“加机器”的道路——也就是将系统横向扩展成分布式架构。

此时，分布式数据系统带来了三个诱人的好处：

天然的可扩展性：理论上，你能加一台机器，就能加一千台机器（尽管现实里没那么美好，但你的老板深信不疑）。
内置的高可用性和容错性：在足够大的规模下，硬件故障不是偶发事件，而是常态。一个合格的分布式系统，必须对单点故障有足够的冗余机制。
更低的延迟潜力：通过将数据节点部署在离用户更近的地理位置，分布式系统能一定程度上弥补“光速有限”的物理瓶颈。

听起来像是“分布式万岁”。但所有的馈赠都标好了价格。

为什么不是所有问题都能靠“加机器”解决？

在深入分布式系统的好处之前，我们先来回头看看它试图替代的是什么。

所谓垂直扩展，是指通过提升单台机器的性能来增强系统能力。这种方式包括更换更强的 CPU、内存和硬盘，也包括构建一个大型共享资源架构——比如多台服务器连接同一个共享存储，看起来像是一台“超级计算机”。

这种方式的问题在于：

扩展性有限：硬件资源总有极限，单点性能的提升会遇到物理和经济上的瓶颈。
成本非线性增长：更强的机器意味着更高的成本，而性能提升往往不是线性的。
部署位置受限：资源集中在单点意味着天生无法提供异地容灾能力，一旦中心节点宕机，服务将全面瘫痪。

于是我们才开始认真考虑无共享架构（shared-nothing architecture）——也就是我们今天所说的分布式系统。

在无共享架构中，每个节点都是一台独立的物理机或虚拟机，节点之间没有共享内存或磁盘，所有的协调通信都运行在以太网之上，系统的核心能力依赖于软件层面的调度、一致性与容错机制。

新的机遇，还是新的复杂性？

正是这种架构，让“加机器”变得可能，也让我们走上了分布式的道路。

但随之而来的，不只是能力的提升，更是复杂性的爆炸。数据如何分片？事务如何保证？一致性如何维护？服务如何容灾？这些都不再是“买个更强的服务器”就能解决的问题。

分布式数据系统的数据复制

复制，即在多个节点上保存相同数据的副本，以提供冗余和容错能力。如果某些节点出现故障或临时不可用，系统可以通过其它副本节点继续提供数据访问服务，从而实现高可用性。

常见的数据复制策略包括：

主从复制（Leader–Follower）：一个主节点负责处理所有写请求，写入变更会同步或异步地复制到一个或多个从节点。读请求可以由主节点处理，也可以转移到从节点以减轻负载。该模式实现相对简单，是很多关系型数据库（如 MySQL）的默认复制机制。
无主复制（Peer-to-Peer）：所有节点地位平等，均可接收读写请求。节点之间相互同步，通过冲突检测和协调机制来维持最终一致性。该模式提高了可用性，但实现复杂，且一致性保障较弱，常用于弱一致性场景，如某些 P2P 系统或协同编辑工具。
多主复制（Multi-Leader）：系统被划分为多个逻辑片区，每个片区拥有自己的主节点与若干从节点。从节点不仅从本地主节点复制数据，也会从其它片区的主节点同步数据。该方案适用于跨数据中心部署，能显著提升写入吞吐与容灾能力，但需要更复杂的冲突解决策略。

根据写操作传播的时机不同，复制又可分为：

同步复制：写操作需要在所有副本成功（或多数副本）写入后才算完成，能保证强一致性，但可能带来较高延迟和可用性损失（如少数节点宕机会影响整体写入能力）。
异步复制：写操作只需在主节点成功即可返回，副本稍后再同步。这样延迟低、可用性高，但在主节点失败的情况下可能出现数据丢失（即复制滞后带来的数据不一致）。

分布式数据系统的数据分区

分区（也称为分片，Sharding）是将一个大型数据库拆分成多个较小的子集，每个子集由不同的节点负责存储与处理，从而实现系统的横向扩展。

最常见的分区方法主要包括以下几类：

哈希分区（Hash Partitioning）：对主键（或其一部分）进行哈希计算，将结果映射到不同的分区。哈希的随机性有助于实现较为均衡的负载分布，是应对高并发场景的常见选择。不过，哈希分区的一个明显缺点是无法高效支持范围查询，因为相邻的数据项在物理上通常被分配到了不同的节点上。
范围分区（Range Partitioning）：根据主键值的区间范围，将数据划分到不同分区。该方式适用于时间序列数据、按业务维度有序增长的数据等场景，能很好地支持范围查询。但其缺点在于数据分布可能不均衡，易形成“热分区”或“热点节点”，从而影响系统性能。
一致性哈希（Consistent Hashing）：这是一种结合哈希与范围思想的机制，常用于动态可变的节点环境。它将整个哈希空间组织为一个环，数据和节点都映射到该环上。通过引入虚拟节点等手段，一致性哈希能够在扩容或缩容时大幅减少需要迁移的数据量，从而保持系统的稳定性与负载均衡。

分区再平衡（Rebalancing）

随着系统规模变化、负载波动或节点故障，原有的分区方式可能会失衡，导致部分节点过载。因此，我们需要动态地对分区进行“再平衡”。

Hash 分区的扩展

在哈希分区中，扩容通常意味着增加节点数量。一个简单但代价昂贵的方法是重新哈希所有数据，但这会导致大量数据迁移。

优化的方式之一是使用虚拟节点（Virtual Nodes），即将哈希空间切分为更多、更小的段，每个节点负责多个段。新增节点时，只需迁移部分虚拟节点，代价更小，平衡更容易。

FYI: 这篇文章还讨论了对于Hash分区的一种扩展方法，以避免过量的数据迁移。

范围分区的扩展

对于范围分区，扩容通常需要调整区间边界，即将一个负载较高的区间细分成多个更小的子区间，并将其迁移到新节点。这种方案虽然易于理解，但实际操作时需谨慎处理数据迁移期间的一致性问题。

请求路由

随着分区数量的增加，客户端或前端服务需要具备将请求准确路由到目标分区的能力。这通常有三种策略：

客户端路由：客户端通过哈希函数或路由表直接定位目标分区，效率高但不易变更。
中间代理层（比如 Router 或 Coordinator）：系统部署专门的请求路由组件来管理和分发请求，灵活但增加了系统复杂度。
元数据服务：由一个集中的元服务组件记录所有分区状态和位置，客户端或中间层可据此查询路由路径，常见于大规模系统中（如 HBase 的 Meta Table）。

小结

通过上文的内容，我们已经初步了解了分布式数据系统的核心机制：系统如何通过分区实现横向扩展，如何借助复制提升可用性与容错能力，以及如何设计合理的路由机制来协调各个节点间的请求调度。

这些机制构成了大多数 NoSQL 数据库的基础架构逻辑，也解释了它们为何能够支撑起大规模、高并发的业务系统。

不过，真正的挑战往往不止于此。在涉及跨节点的数据一致性、事务操作、以及如何在一致性、可用性与分区容错性之间进行权衡时，系统设计将面临更复杂的决策。

这也是我们在下一篇中将继续探讨的方向 —— 希望能有下一篇。

为什么我不建议你阅读《数据密集型应用系统设计》（之一）

2025-05-17T00:00:00+08:00

因为我是标题党。

这本书与我们常用来垫显示器的《算法导论》或《深入理解计算机系统》（如果你是大一大二的同学，可能还包括《算法竞赛入门经典》）并不属于同一类。它更接近《C++ Primer》或那本《算法》(Robert Sedgewick 著）——属于通识型读物。

换句话说，如果你尚未掌握相关基础知识，阅读这本书的学习曲线将会异常陡峭；而一旦你已经入门，它的表达方式会让你觉得十分优雅，结构也很清晰，却又可能让你觉得“说得都对，但好像也没什么新东西”。

如果你是初入数据相关系统领域的新手，我更希望你先对这本书的脉络和重点有个清晰概览，剪枝信息、化繁为简，帮助你更快建立起基础认知，从而更高效地阅读这本书，而不是在术语和细节中反复迷路。

什么是数据密集型系统

数据密集型系统可以理解为一个结构上的“双面体”：一方面，它需要实时地处理数据的存储与检索；另一方面，它还承担着异步处理和计算已有数据的任务。这两种模式共同支撑了系统对数据的全面利用。

我们之所以称其为“数据密集型”，是因为它所处理的数据具备以下三个核心特征：

数据是不可再生的——一旦丢失，就无法重新获取，具有唯一性与不可逆性；
数据是持续增长的——系统需要不断接收新数据，数据量随着时间推移呈线性，甚至指数级上升；
数据的应用是不断演进的——数据的价值和使用方式会随着业务需求和技术手段的发展而变化。

正因为如此，设计和构建数据密集型系统时，我们必须重点关注三个目标：
* 可靠性：防止数据丢失，保障系统在故障时能够正确恢复；
* 可扩展性：系统能够随着数据量和访问量的增加平稳扩展；
* 可维护性：系统结构清晰、易于理解，能够适应未来不断变化的需求和环境。

数据模型与数据编码

数据模型

数据模型是对现实世界的结构化抽象，是我们与数据系统沟通的“语言”。不同类型的数据模型基于不同的设计假设，适用于不同的场景。

常见的数据模型包括：

关系模型
- 典型代表：MySQL、PostgreSQL 等传统 SQL 数据库
- 数据以“表格”的形式组织，每张表表示一种实体或关系，每行是一条记录
- 特点：
  - 严格的结构约束（schema）
  - 支持复杂的查询语句和事务处理
  - 数据一致性强，适合结构清晰、关系复杂的场景
文档模型
- 典型代表：MongoDB、Redis（部分用作文档存储）等 NoSQL 系统
- 数据以文档形式组织（通常是 JSON 或 BSON 格式），每个文档是一条记录
- 特点：
  - 模式灵活，不强制 schema
  - 更适合嵌套结构和非结构化数据
  - 写入与扩展性能更好，适用于快速迭代和海量数据场景

选择何种数据模型，本质上是对业务需求和系统约束之间做出的权衡。

数据编码

在内存中，我们倾向于使用链表、哈希表、树等结构进行快速访问。但在持久化存储和网络传输中，我们需要将数据编码成紧凑且结构化的格式，以提高读写效率与兼容性。

好的数据编码格式需要权衡三个核心指标：

向前兼容性：新版本的系统仍能读取旧格式的数据；
向后兼容性：旧版本的系统能忽略新数据中的未知字段，正常运行；
效率：编码后的数据大小与 CPU 解码开销之间取得平衡。

常见的数据编码方案：

语言内置格式（如 Python 的 pickle、Java 的 Serializable）
- 与语言紧耦合，移植性差
- 不支持数据结构演化
- 编解码效率不高，不建议用于跨系统持久化或网络传输
文本格式（如 CSV、XML、JSON）
- 通用、易读、调试友好
- 几乎被所有编程语言支持
- 存在大量冗余（如键名重复），不适合高效存储或传输
- 不适合嵌套结构或二进制数据
二进制格式（如 Protobuf、Thrift、Avro）
- 高度紧凑，支持嵌套与复杂结构
- 支持数据演化，兼容性好
- 编解码性能高，但不易调试（需工具查看）

在构建数据密集型系统时，模型与编码的选择往往影响深远，且难以随意更改，务必根据业务需求慎重选择。

数据检索

事务处理系统（OLTP）中的索引结构

OLTP（在线事务处理）系统主要处理高并发、实时读写请求，因此对延迟极度敏感。常见的索引结构有：

哈希表：用于快速键值对检索，结构简单，性能高；
LSM-Tree：多层已排序数组结构，写入快，适合写多读少场景；
B-Tree：多叉平衡排序树，适合读写混合场景，是多数数据库的默认索引类型。

数据分析系统（OLAP）中的索引结构

OLAP（在线分析处理）系统用于处理大规模离线数据任务，关注的是整体吞吐而非单次请求的响应延迟。

事实表与列式存储

在数据仓库中，事实表记录每一条事件数据，通常有很多列来表示不同维度。虽然逻辑上按行存储，但物理上采用列式存储更为高效：

查询只需读取必要的列，I/O更少；
同一列数据分布相似，压缩率更高；
列式布局更利于向量化计算和并行处理。

小结

从模型、编码到检索，数据系统的基础构成其实围绕着一个核心问题展开：我们如何高效、可靠地组织、保存与使用数据。

数据模型决定了我们如何抽象现实世界中的事物与关系；
数据编码决定了我们如何在系统之间传递和持久化这些抽象；
数据检索结构则决定了我们如何以尽可能低的开销获得所需信息

下一篇，我们将探讨分布式日志、复制机制和一致性协议在数据系统中的角色与实践 —— 希望能有下一篇。

3D打印解压玩具 / 3D Printed Fidget Toy

2025-04-05T00:00:00+08:00

这是一款我用3D打印制作的小巧解压玩具，造型为柔和的三角形，中间布满可以按压的小圆点，简单又有趣。适合在工作或学习时用来放松，也适合小朋友玩耍。

我使用的是PLA材料，手感偏硬。如果用TPU等柔性材料打印，可能会更接近硅胶的感觉，但我还没有实际尝试。

This is a small fidget toy I designed and 3D printed. The soft triangular shape with pressable dots makes it a fun and relaxing little tool—great for work, study breaks, or as a toy for kids.

I printed it using PLA, which feels firm. Flexible materials like TPU might give a more silicone-like feel, though I haven’t tested that yet.

风力涡轮机 3D 模型 / Vertical Axis Wind Turbine (VAWT) 3D Model

2025-04-05T00:00:00+08:00

这是一款垂直轴风力涡轮机（VAWT）3D模型，外观采用螺旋扭转的叶片设计，具有极强的美感和结构对称性。它不需要支撑结构，方便3D打印，同时底部设计了一个标准的608轴承接口，用于展示旋转效果。需要注意的是，它并非真正的风力驱动设备，仅为一个展示用模型。

本模型使用 Fusion 360 软件建模，并附带 .f3d（Fusion 360 原始文件）和 .3mf（适用于多数切片软件的格式），方便进行修改或直接打印。

This is a vertical axis wind turbine (VAWT) 3D model, featuring a twisted helical blade design that enhances symmetry and visual appeal. It’s designed to be support-free for easy 3D printing, and includes a 608 bearing mount at the bottom to allow free spinning when assembled. Please note: this is a non-functional display model and is not powered by wind.

The model was created using Fusion 360, and comes with both .f3d (Fusion 360 source file) and .3mf (widely compatible with slicer software) formats, making it easy to modify or print.

动手实现智能指针（上篇） - C++ for the Antiquated（之四）

2025-01-21T00:00:00+08:00

智能指针（如 std::shared_ptr 和 std::weak_ptr）已经成为现代 C++ 编程的重要工具，尽管它们并不算是“新兴”的特性。在 C++11 标准之前，Boost 库就已经引入了智能指针的实现，特别是 boost::shared_ptr 和 boost::weak_ptr，它们为 C++11 的智能指针特性奠定了基础。因此，可以说智能指针在 C++ 中的发展历程已经有很长时间，而它们的引入极大地简化了内存管理和避免了常见的内存泄漏和悬挂指针问题。

本文将围绕以下主题展开讨论：

C++ 智能指针的实现原理
非侵入式智能指针与侵入式智能指针的区别
利用 atomic 避免多线程竞态条件
如何实现侵入式版本的 shared_ptr 和 weak_ptr
采用 concept 约束模板类型
探讨完美转发（std::forward<T>）在智能指针中的应用

C++ 中的智能指针

`std::shared_ptr`的实现

std::shared_ptr 是一种智能指针，能够自动管理对象的生命周期。它通过引用计数的方式来跟踪有多少个 shared_ptr 实例指向同一个对象，确保当最后一个 shared_ptr 被销毁时，对象的内存能够自动释放。

引用计数与原子操作

std::shared_ptr 的核心机制是引用计数。每个 shared_ptr 会维护一个引用计数。当多个 shared_ptr 指向同一个对象时，计数器会增加；当一个 shared_ptr 被销毁时，计数器会减少。如果计数器归零，表明没有任何 shared_ptr 再指向该对象，这时对象会被删除。

引用计数通常由一个控制块（control block）管理。控制块不仅保存引用计数，还会保存对象本身以及与对象生命周期相关的其他信息。std::shared_ptr 的实现一般使用“非侵入式引用计数”（即不嵌入对象本身）。

示例代码如下：

template <typename T>
class control_block {
public:
    control_block(T* ptr)
        : ref_count(1), obj(ptr) {}

    // 增加引用计数
    void add_ref() { ++ref_count; }

    // 减少引用计数
    void release_ref() {
        if (--ref_count == 0) {
            delete obj;  // 删除对象
            delete this; // 删除控制块
        }
    }

    T* get() { return obj; }

private:
    std::atomic<int> ref_count;    // 引用计数
    T* obj;                        // 实际对象
};

简化版 `shared_ptr` 实现

下面是一个简化版的 shared_ptr 实现示例。这个版本仍然有一些重要细节需要注意，比如原子操作和异常安全等问题，但可以帮助理解 shared_ptr 的基本原理：

template <typename T>
class my_shared_ptr {
private:
    T* ptr;
    control_block<T>* ctrl_block;

public:
    explicit my_shared_ptr(T* p = nullptr) 
        : ptr(p), ctrl_block(new control_block<T>(p)) {}

    // 拷贝构造函数
    my_shared_ptr(const my_shared_ptr& other) 
        : ptr(other.ptr), ctrl_block(other.ctrl_block) {
        if (ctrl_block) {
            ctrl_block->add_ref();
        }
    }

    // 析构函数
    ~my_shared_ptr() {
        if (ctrl_block) {
            ctrl_block->release_ref();
        }
    }

    T* operator->() { return ptr; }
    T& operator*() { return *ptr; }
};

`std::weak_ptr`的实现

std::weak_ptr 是与 std::shared_ptr 配合使用的智能指针，它解决了 shared_ptr 在某些场景下的循环引用问题。

循环引用问题发生在两个或多个对象通过 shared_ptr 相互引用时，导致引用计数永远不为零，从而引发内存泄漏。为了避免这个问题，我们引入了 weak_ptr。

为什么需要 `weak_ptr`

std::weak_ptr 不增加引用计数，因此它不会影响对象的生命周期。当一个对象的所有 shared_ptr 被销毁后，weak_ptr 将变为“悬挂”状态。这与普通指针的“空悬指针”（dangling pointer）不同，空悬的 weak_ptr 会返回空指针 nullptr，表明该对象的生命周期已经结束。

weak_ptr 提供了一种访问 shared_ptr 的方式，但并不控制对象的销毁，因此它可以有效避免循环引用问题。

通过 weak_ptr，我们可以在不延长对象生命周期的前提下，检查对象是否仍然存在，并访问它。具体来说，weak_ptr 可以通过调用 lock() 方法来创建一个 shared_ptr，如果对象还存在（即引用计数大于零），则返回一个有效的 shared_ptr，否则返回空指针。

控制块的扩展

为了支持std::weak_ptr，我们需要扩展控制块的功能，使其能同时管理对象的引用计数（ref_count）和弱引用计数（weak_count），从而保持对对象的生命周期的正确管理。

template <typename T>
class control_block {
public:
    control_block(T* ptr)
        : ref_count(1), weak_count(1), obj(ptr) {}

    // 增加引用计数
    void add_ref() { ++ref_count; }

    // 增加引用计数
    bool lock() { 
        int prev = ref_count.load();  // 使用加载当前值，避免重复读取
        while (prev > 0 && !ref_count.compare_exchange_weak(prev, prev + 1)) {
            prev = ref_count.load();   // 如果失败，重新加载当前值
        }
        return prev > 0;  // 如果 prev > 0，表示锁定成功
    }

    // 减少引用计数
    void release_ref() {
        if (--ref_count == 0) {
            delete obj;  // 删除对象
            release_control_block(); // 尝试删除控制块
        }
    }

    // 增加弱引用计数
    void add_weak_ref() { ++weak_count; }

    // 减少弱引用计数
    void release_weak_ref() {
        if (weak_count.fetch_sub(1) == 1) {
            delete this; // 删除控制块
        }
    }

    T* get() { return obj; }

private:
    // 删除控制块，只有在弱引用计数为0时才删除控制块
    void release_control_block() {
        if (weak_count == 0) {
            delete this; // 删除控制块
        }
    }

    std::atomic<int> ref_count;    // 强引用计数
    std::atomic<int> weak_count;   // 弱引用计数
    T* obj;                        // 实际对象
};

`weak_ptr` 的简化版实现

下面是一个简化版的 weak_ptr 实现，它与 shared_ptr 共享相同的控制块。weak_ptr 本身不增加引用计数，因此不会影响对象的生命周期。

template <typename T>
class my_weak_ptr {
public:
    my_weak_ptr() : ctrl_block(nullptr) {}

    // 从 shared_ptr 构造 my_weak_ptr
    my_weak_ptr(const std::shared_ptr<T>& shared)
        : ctrl_block(shared.ctrl_block) {
        ctrl_block->add_weak_ref();
    }

    ~my_weak_ptr() {
        if (ctrl_block) {
            ctrl_block->release_weak_ref();
        }
    }

    // 尝试获取指向对象的 shared_ptr
    std::shared_ptr<T> lock() {
        return std::shared_ptr<T>(*this);
    }

private:
    control_block<T>* ctrl_block; // 控制块
};

template <typename T>
class my_shared_ptr {
private:
    T* ptr;
    control_block<T>* ctrl_block;
public:
    // ...
    my_shared_ptr(const my_weak_ptr<T>& weak_ptr) {
        if (weak_ptr.ctrl_block && weak_ptr.ctrl_block->lock()) {
            ptr = weak_ptr.ptr;
            ctrl_block = weak_ptr.ctrl_block();
        } else {
            throw exception("bad weak ptr");
        }
    }
    // ...
};

理解并优化`std::atomic<T>`操作

在上面的代码示例中，我们使用了std::atomic<int>作为智能指针的引用计数。与直接使用int变量不同，std::atomic<int>可以在多线程环境中正确地管理对同一智能指针的引用计数。

然而，在上述代码中，我们仅使用了std::atomic<int>的基本操作（如自增、自减和赋值等），这些操作默认使用memory_order_seq_cst内存序（稍后会讨论）。在多线程编程中，std::atomic<T>提供了多种内存序（memory ordering）选项，用以控制操作的可见性和执行顺序，以确保数据一致性。不同的内存序策略决定了编译器和CPU对指令的重排序程度。

开发者的目标是选择合适的内存序，优化程序性能，同时确保程序的正确性。

内存序的核心概念

理解内存序的关键在于重排序和跨线程可见性：

重排序（Reordering）
编译器和CPU可能会重排指令，以优化性能。例如，它们可能会提前执行某些计算，或者将存储操作推迟执行。正确使用std::atomic可以防止某些关键操作被错误地重排序。
可见性（Visibility）
在多线程环境中，一个线程对变量的修改可能不会立即被其他线程看到，或者多个线程对同一变量的操作顺序可能不确定。原子操作的内存序决定了其他线程何时能看到这些修改。

不同内存序的作用及使用场景

`memory_order_relaxed`（松散顺序，最低开销）

特点：不保证顺序，仅保证操作是原子的。
作用：确保同一std::atomic<T>变量的读写操作是原子的，但不提供线程间的同步，不影响可见性或顺序。
适用场景：适用于数据竞争不影响程序正确性的场景，如无依赖的计数（统计线程数、事件计数等）。

示例

std::atomic<int> counter{0};
counter.fetch_add(1, std::memory_order_relaxed);  // 仅保证原子性，不保证可见性

这里，fetch_add确保counter自增操作不会丢失，但不同线程的修改可能会被延迟看到。

`memory_order_acquire`（获取，防止重排序到前）

特点：保证当前线程在acquire之后的所有操作不会被重排序到acquire之前，因此，其他线程中相同原子变量的释放操作（release operation）之前的写入对当前线程是可见的。
适用场景：用于读取共享数据，确保当前线程能够看到其他线程之前对该变量的修改。

`memory_order_release`（释放，防止重排序到后）

特点：确保当前线程在release之前的所有操作不会被重排序到release之后，因此，当前操作所在线程之前的写入，在其他线程施加占有操作（acquire operation）之后是可见的。
适用场景：用于写入共享数据，确保其他线程能在acquire读取时看到修改。

示例

std::atomic<int> flag{0};
int data = 0;

void producer() {
  data = 42;
  flag.store(1, std::memory_order_release);  // 让消费者可以看到 data=42
}

void consumer() {
  while (flag.load(std::memory_order_acquire) != 1);  // 确保 data=42 可见
  std::cout << data << std::endl;  // 确保 data 的修改对本线程可见
}

store(release)确保data=42发生在flag=1之前。
load(acquire)确保flag=1之后，data=42对消费者线程可见。
通过acquire-release，消费者线程能够正确看到生产者线程的data修改。

`memory_order_acq_rel`（获取-释放，双向同步）

特点：结合acquire和release，用于读-改-写（Read-Modify-Write, RMW）操作，确保：
读取时使用acquire语义，保证之前的修改对当前线程可见。
写入时使用release语义，保证当前修改对后续线程可见。
适用场景：用于读-改-写（如fetch_add()、exchange()）操作，确保多个线程能够正确协调。

示例

std::atomic<int> value{0};
value.fetch_add(1, std::memory_order_acq_rel);  // 读写都保证可见性

在这里，fetch_add同时读取旧值并写入新值：
- 读取时使用acquire语义，确保它能看到其他线程的修改。
- 写入时使用release语义，确保它的修改能被其他线程看到。

`memory_order_seq_cst`（顺序一致性，最严格）

特点：所有使用memory_order_seq_cst的原子操作在所有线程看来都是按照相同的顺序执行的，即全局一致的时序。
适用场景：
需要严格同步的场景，如锁、同步变量、临界区保护等。
适用于多线程交互复杂、难以管理依赖关系的情况。

保证：
- seq_cst确保所有操作严格按照全局统一顺序执行，避免乱序问题。

直观比喻

relaxed：随意写笔记，但不保证别人能看到。
acquire：进门检查公告栏，确保看到之前的通知。
release：离开时更新公告栏，让后来的人看到。
acq_rel：进门看公告 + 走前更新公告。
seq_cst：所有人按同样顺序写、看公告，保证一致性。

根据不同场景合理选择内存序，可以提高并发程序的正确性和性能。

优化控制块中的原子变量

#include <atomic>

template <typename T>
class control_block {
public:
    control_block(T* ptr)
        : ref_count(1), weak_count(1), obj(ptr) {}

    // 增加引用计数
    void add_ref() {
        ref_count.fetch_add(1, std::memory_order_relaxed);
    }

    // 尝试增加强引用计数（仅当对象仍然存活时）
    bool lock() { 
        int prev = ref_count.load(std::memory_order_acquire);
        while (prev > 0) {
            if (ref_count.compare_exchange_weak(prev, prev + 1, 
                std::memory_order_acquire, std::memory_order_relaxed)) {
                return true; // 成功锁定
            }
        }
        return false; // 对象已被释放
    }

    // 释放强引用
    void release_ref() {
        if (ref_count.fetch_sub(1, std::memory_order_acq_rel) == 1) {
            delete obj;  // 删除对象
            release_control_block(); // 尝试删除控制块
        }
    }

    // 增加弱引用计数
    void add_weak_ref() {
        weak_count.fetch_add(1, std::memory_order_relaxed);
    }

    // 释放弱引用计数
    void release_weak_ref() {
        if (weak_count.fetch_sub(1, std::memory_order_acq_rel) == 1) {
            delete this; // 删除控制块
        }
    }

    T* get() { return obj; }

private:
    // 删除控制块，仅当弱引用计数也归零时
    void release_control_block() {
        if (weak_count.fetch_sub(1, std::memory_order_acq_rel) == 1) {
            delete this; // 删除控制块
        }
    }

    std::atomic<int> ref_count;    // 强引用计数
    std::atomic<int> weak_count;   // 弱引用计数
    T* obj;                        // 实际对象
};

参考

std::visit实现运行时多态 - C++ for the Antiquated（之三）

2025-01-04T00:00:00+08:00

在传统的 C++ 中，运行时多态 通常依赖于 “接口 - 虚函数” 机制，通过抽象类、具体类与对象的设计来实现。这种多态方式通常被称为 子类型多态（Subtype Polymorphism）。

在之前的文章中，我们介绍了现代 C++ 引入的 std::variant —— 一种类型安全的联合体，以及如何借助 std::visit 在类型安全的前提下，动态地访问联合体中的不同类型，并执行相应的逻辑。这种多态方式被称为 临时多态（Ad-hoc Polymorphism）。

除此之外，还有一种被称为 参数化多态（Parametric Polymorphism），即我们熟知的 C++ 模板。它允许我们编写与类型无关的代码，提供更强的泛型编程能力。由于本篇文章的重点并不在此，我们暂且不展开。

在本篇文章中，我们将重点对比 子类型多态 和 临时多态 的优劣，分析它们在实际场景中的应用与权衡，希望能更好地理解和选择合适的多态机制。

临时多态的实现原理

临时多态（Ad-hoc Polymorphism）与 子类型多态（Subtype Polymorphism）在实现原理上有一定的相似性：它们都依赖于在类型中引入额外的信息来决定不同类型应执行的函数逻辑。

子类型多态：依赖于虚表（vtable） 和 虚指针（vptr），通过运行时的动态分派来确定调用哪个派生类的成员函数。
临时多态：依赖一个 枚举值（enum） 来表示类型信息，通过显式的 switch-case 或 if-else 语句来选择不同的逻辑分支。

简单示例：模拟 std::visit

这里只使用了传统C++的实现，关于std::visit的更详细的解读，可以参考本系列的“动手实现std::visit”一文。

#include <iostream>
#include <string>
#include <cassert>

enum EType : uint8_t {
    TYPE_Int = 0,
    TYPE_Float = 1,
    TYPE_String = 2,
};

struct MyVariant {
    EType type;
    void* obj;
};

void MyVisitor(MyVariant& var) {
    switch (var.type) {
        case TYPE_Int: 
            std::cout << "Int: " << *(int*)var.obj << std::endl;
            break;
        case TYPE_Float:
            std::cout << "Float: " << *(float*)var.obj << std::endl;
            break;
        case TYPE_String:
            std::cout << "String: " << *(std::string*)var.obj << std::endl;
            break;
        default:
            assert(false && "Unknown type!");
            break;
    }
}

int main() {
    int i = 42;
    float f = 3.14f;
    std::string s = "Hello";

    MyVariant var1 = {TYPE_Int, &i};
    MyVariant var2 = {TYPE_Float, &f};
    MyVariant var3 = {TYPE_String, &s};

    MyVisitor(var1);
    MyVisitor(var2);
    MyVisitor(var3);

    return 0;
}

原理解析

EType 枚举
- 定义了一个枚举类型 EType，用于标识 MyVariant 当前存储的具体类型。
MyVariant 结构体
- type 字段保存当前对象的类型信息。
- obj 字段是一个通用指针，指向实际存储的数据对象。
MyVisitor 函数
- 通过 switch-case 语句，基于 type 字段选择不同的分支逻辑来访问和打印不同类型的数据。
- 如果遇到未知类型，程序会触发 assert 以防止未定义行为。

性能优化思考

在实际应用中，switch-case 语句可能随着类型数量的增加而导致性能开销。可以通过二分查找（Binary Search）方法进行优化，减少 switch-case 的分支深度。

临时多态的性能分析

虚函数常因其较低的性能而受到批评。为了更好地了解这一点，我们将对比使用虚函数实现的“子类型多态”和通过 std::visit 实现的“临时多态”在性能上的差异。

使用虚函数实现的代码
使用std::visit + std::variant<object> 实现的代码
使用std::visit + std::variant<ptr> 实现的代码

结果如下：

# 使用g++ --std=c++17 -O2编译运行

# 使用虚函数实现
Total Object Creation Time: 55.53 ms
Total Visit Time: 6.99 ms

# 使用std::visit + std::variant<object>实现
Total Object Creation Time: 26.88 ms
Total Visit Time: 5.93 ms

# 使用std::visit + std::variant<ptr>实现
Total Object Creation Time: 52.15 ms
Total Visit Time: 6.05 ms

结果分析

内存管理开销：
使用虚函数的子类型多态实现通常需要动态申请和释放内存，从而引入了额外的内存管理开销。而使用基于 std::variant<object>的临时多态可以一次性分配所有内存，虽然可能存在一定程度的内存浪费，但避免了频繁的动态内存管理。
性能接近，std::visit 略优：
虽然虚函数和 std::visit 的性能差距不大，但 std::visit 略微优于虚函数。两者都引入了额外的开销以实现多态。

通过临时多态实现Vistor模式

Visitor模式是一种行为设计模式，用于将数据结构的操作与数据结构本身分离。它通常通过“子类型多态”来实现，其中每个具体类型的对象都接受一个访问者（Visitor）并对其进行相应的处理。使用虚函数和继承是实现这一模式的一种方式，但有时我们可以用更轻量的方式来实现，比如通过临时多态结合 std::variant 和 std::visit。

使用虚函数实现Visitor模式

我们首先来看一个传统的通过子类型多态实现Visitor模式的例子：

struct IVisitor;

struct IResource {
    virtual void accept(IVisitor* visitor) = 0;
};
struct IVisitor {
    virtual void visit(IResource* res) = 0;
};

class MyResource : public IResource {
public:
    void accept(IVisitor* visitor) override {
        visitor->visit(this);
    }
};

class MyVisitor : public IVisitor {
public:
    void visit(IResource* res) override {
        // 处理资源
    }
};

这种实现方式虽然能很好地分离数据和操作，但它也有一些不足之处：

每次调用 visit 都需要通过虚函数来间接调用方法，这会引入额外的性能开销。
visitor 无法在 visit 时直接获取资源对象的类型信息，通常需要额外传递类型信息或者让资源类暴露更多的接口。

使用 `std::visit` 实现Visitor模式

通过 std::visit 和 std::variant，我们可以显式地通过类型信息来处理每种资源类型，避免了虚函数调用的开销，同时使得代码更加简洁和类型安全。下面是一个通过临时多态实现Visitor模式的例子：

using ResourceUnion = std::variant<ResourceA, ResourceB, ResourceC>;

std::vector<ResourceUnion> resources;
for (auto& res : resources) {
    std::visit([](auto& res) {
        using T = std::decay_t<decltype(res)>;
        if constexpr (std::is_same_v<T, ResourceA>) {
            // 处理类型为 ResourceA 的资源
        } else if constexpr (std::is_same_v<T, ResourceB>) {
            // 处理类型为 ResourceB 的资源
        } else if constexpr (std::is_same_v<T, ResourceC>) {
            // 处理类型为 ResourceC 的资源
        } else {
            static_assert(always_false_v<>, "Unhandled type!");
        }
    }, res);
}

优点与分析

类型安全：
使用 std::visit 时，编译器可以根据类型推断并为每种类型生成不同的代码路径，从而避免了运行时错误和类型错误，提升了类型安全性。
性能：
由于不再依赖虚函数，std::visit 能避免每次调用 visit 时的虚函数开销，从而提高了性能。
简洁性：
通过 std::variant 和 std::visit，代码更加简洁且不需要繁琐的继承结构。每个资源类型只需关注其自身的实现，而无需处理不同访问者的逻辑。
扩展性：
如果要新增资源类型，只需在 std::variant 中添加新类型，并在 std::visit 的 lambda 表达式中添加对应的分支，避免了修改现有代码的风险。

临时多态的优点与缺点

优点：

类型安全：std::variant 与 std::visit 确保了类型安全，避免了许多传统多态机制中的错误。
性能优化：相较于虚函数，std::visit 通过类型折叠和编译时分支优化，通常表现出更好的性能，尤其在没有动态内存管理时。
自由组织功能函数：你可以灵活地将功能函数组织在一个地方，而无需修改每个具体类型。

缺点：

职责分散：每个类型的行为都可能分散到多个visit函数中，导致代码难以维护。
高耦合风险：当新增类型时，所有访问逻辑需要修改，可能带来较高的耦合度，尤其在类型较多时。

参考

C++20高级编程（罗能） —— 1.6 运行时多态
深入理解面向对象中的多态
C++ 访问者模式讲解和代码示例

动手实现std::visit - C++ for the Antiquated（之二）

2025-01-01T00:00:00+08:00

std::variant 与 std::visit

std::variant

std::variant 是 C++17 引入的类型安全的联合体（type-safe union），可以在多个预定义类型中存储任意一个值。与传统的 union 不同，std::variant 能够在运行时安全地检查当前存储的类型，避免未定义行为。

其核心特点如下：

类型安全：访问值时进行类型检查，防止类型错误。
固定类型集合：存储类型在编译时确定。
异常安全：在赋值失败时会进入无效状态（std::monostate）。

std::visit

std::visit 是一个访问器函数，用于访问 std::variant 中当前存储的值。它通过一个可调用对象（如 Lambda 表达式）来处理存储的值，从而实现编译时多态。

其核心特点如下：

统一访问接口：无论存储的是哪种类型，都可以通过同一个函数进行访问。
类型安全：确保所有可能的类型都被正确处理。

代码示例

#include <iostream>
#include <vector>
#include <variant>
#include <type_traits>

template<typename T>
inline constexpr bool always_false_v = false;

int main() {
    std::vector<std::variant<int, float, std::string>> items {
        10,
        3.14f,
        "foobar"
    };

    for (const auto& item : items) {
        std::visit([](const auto& arg) {
            using T = std::decay_t<decltype(arg)>;
            if constexpr (std::is_same_v<T, int>) {
                std::cout << "int: " << arg << std::endl;
            } else if constexpr (std::is_same_v<T, float>) {
                std::cout << "float: " << arg << std::endl;
            } else if constexpr (std::is_same_v<T, std::string>) {
                std::cout << "std::string: " << arg << std::endl;
            } else {
                static_assert(always_false_v<>, "Unhandled type!");
            }
        }, item);
    }

    return 0;
}

代码分析

std::variant<int, float, std::string>
- 这是一个类型安全的联合体，可以存储 int、float 或 std::string 中的任意一种类型。
- 将多个 std::variant 存储在 std::vector 中，形成一个统一的容器。
std::visit
- 使用 std::visit 访问每个 std::variant 元素。
- 传入一个泛型 Lambda 表达式，通过 if constexpr 在编译时分发到不同的分支，处理不同类型的值。
if constexpr 与 std::is_same_v
- 使用 std::is_same_v 判断存储的实际类型。
- 根据类型进行不同的输出操作。
类型安全
- 如果添加一个未处理的类型，编译器会在 static_assert 中报错，提醒开发者补充处理逻辑。

使用传统C++实现std::visit

实现std::variant

在传统 C++ 中，我们只有简单的 union 来实现“联合体”语义。然而，union 存在一些局限性：

无法存储非平凡类型（例如 std::string）。
无法跟踪当前存储的类型。
无法进行类型安全检查。

而 std::variant 通过类型索引和类型匹配来提供类型安全，支持多种类型的存储与访问。

实现 std::visit

实现 std::visit 需要使用一个可调用对象（例如 Visitor）来访问 std::variant 中的值。具体来说，它在编译时根据实际类型匹配相应的 operator() 方法。

示例代码如下：

#include <iostream>
#include <vector>
#include <variant>
#include <type_traits>

struct Visitor {
    int operator()(const int& item) const {
        std::cout << "int: " << item << std::endl;
        return 0;
    }

    int operator()(const float& item) const {
        std::cout << "float: " << item << std::endl;
        return 1;
    }

    int operator()(const std::string& item) const {
        std::cout << "string: " << item << std::endl;
        return 2;
    }
};

int main() {
    std::variant<int, float, std::string> item(114.514f);

    // 获取当前类型的索引
    std::cout << item.index() << std::endl; // 输出: 1 (float 的索引)

    // 获取当前存储的值
    std::cout << std::get<float>(item) << std::endl; // 输出: 114.514

    try {
        std::cout << std::get<int>(item) << std::endl;
    } catch (const std::bad_variant_access& e) {
        std::cout << e.what() << std::endl; // 类型不匹配，抛出异常
    }

    // 使用 Visitor 访问值
    std::cout << std::visit(Visitor{}, item) << std::endl; // 输出: 1 (float 类型返回 1)

    return 0;
}

实现的核心要点

实现 std::visit 的关键在于以下几个方面：

类型索引 (index())
根据传入的 std::variant 参数类型，确定其在类型集合中的索引。
类型访问 (std::get<T>)
根据传入的模板类型 T，获取存储的值。如果类型不匹配，抛出异常，确保类型安全。
类型分派 (std::visit)
根据当前存储的类型，调用 Visitor 中对应的 operator() 方法。可以通过 switch-case 或模板匹配来实现类型分发。

代码实现0 - 基本框架

template <typename... Ts>
class MyVariant {
public:
    template <typename T>
    MyVariant(const T& item) {
        setValue(item);
    }

private:
    template <typename T>
    void setValue(const T& item) {
        // TODO
    }

    // 用于存储“联合体”的数据
    union Storage {
        Storage() {}
        ~Storage() {}
        std::aligned_union_t<0, Ts...> data;
    } storage;
};

代码实现1 - index()函数

我们使用经典的模板递归来查找类型对应的索引。同时，利用 constexpr 来简化编译时计算的过程。

template <std::size_t N, typename... Types>
using TupleElement = typename std::tuple_element<N, std::tuple<Types...>>::type;

template <typename T, typename... Types>
struct TypeIndex;

template <typename T, typename First, typename... Rest>
struct TypeIndex<T, First, Rest...> {
    static constexpr int value = std::is_same<T, First>::value 
        ? 0 
        : (TypeIndex<T, Rest...>::value == -1 ? -1 : TypeIndex<T, Rest...>::value + 1);
};

template <typename T>
struct TypeIndex<T> {
    static constexpr int value = -1;
};

template <typename T, typename... Ts>
constexpr bool containsType() {
    return TypeIndex<T, Ts...>::value != -1;
}

通过上述代码，我们实现了在编译期确定传入类型对应的类型索引。

template <typename... Ts>
template <typename T>
void MyVariant<Ts...>::setValue(const T& item) {
    using TargetType = std::decay_t<T>;
    static_assert(containsType<TargetType>(), "Type not supported");
    new (&storage.data) TargetType(item);
    typeIndex = getTypeIndex<TargetType>();
}

代码实现2 - `get()` 函数

我们实现了一个函数 MyVariant::get()，通过检查 typeIndex 来确保获取的类型与存储类型一致。

我们也能可以通过MyGet函数模拟std::get<T>函数的行为。

template <typename... Ts>
class MyVariant;

template <typename T, typename... Ts>
T& MyGet(MyVariant<Ts...>& var) {
    return var.template get<T>();
}

template <typename... Ts>
template <typename T>
T& MyVariant<Ts...>::get() {
    using TargetType = std::decay_t<T>;
    if (TypeIndex<T, Ts...>::value != typeIndex) {
        throw std::runtime_error("Wrong type");
    }
    return *reinterpret_cast<TargetType*>(&storage.data);
}

代码实现3 - `visit`函数

接下来是 visit() 函数的实现。它通过递归方式依次访问 std::variant 中的每种类型，并调用与之对应的处理函数。

template <std::size_t N, typename... Types>
using TupleElement = typename std::tuple_element<N, std::tuple<Types...>>::type;

template <typename... Ts>
template <typename TVisitor>
auto MyVariant<Ts...>::visit(TVisitor&& visitor) {
    using FirstType = TupleElement<0, Ts...>;
    using RetT = decltype(visitor(std::declval<FirstType>()));

    return visitImpl<RetT, TVisitor, Ts...>(std::forward<TVisitor>(visitor));
}

template <typename... Ts>
template <typename RetT, typename TVisitor, typename First, typename... Rest>
RetT MyVariant<Ts...>::visitImpl(TVisitor&& visitor) {
    if (getTypeIndex<First>() == typeIndex) {
        return visitor(get<First>());
    } else {
        // 递归访问剩余的类型
        return visitImpl<RetT, TVisitor, Rest...>(std::forward<TVisitor>(visitor));
    }
}

template <typename... Ts>
template <typename RetT, typename TVisitor>
RetT MyVariant<Ts...>::visitImpl([[maybe_unused]]TVisitor&& visitor) {
    // 基础情况：所有类型都已检查，未找到匹配的类型
    throw std::runtime_error("Wrong type");
}

总结

在本文中，我们实现了一个简单版的 std::variant 和 std::visit，通过传统 C++ 实现了类型安全的联合体数据结构。我们依次通过以下步骤构建了这一系统：

MyVariant 类的基本框架：通过联合体 (union) 存储不同类型的数据，并使用模板构造函数动态设置值。
类型索引 (index()) 的实现：使用模板递归技术结合 constexpr 来实现类型的编译时索引查找，从而在运行时根据类型索引来访问对应的值。
get() 函数：实现了获取存储值的函数，并通过类型检查确保类型安全。如果访问了错误类型的数据，则抛出异常。
visit() 函数：实现了一个可扩展的访问机制，使得不同类型的值可以通过同一个 Visitor 被访问和处理。通过递归的方式，系统能够动态地访问不同类型的值，并调用相应的处理函数。

通过这些实现，我们成功模拟了 C++ 标准库中的 std::variant 和 std::visit 功能。同时，通过对比可以看出，现代 C++ 提供了更强大的模板元编程能力。利用这些特性，我们能够使用更直观的语法，在编译期间实现高效且类型安全的联合体访问，从而提供一种灵活、类型安全的方式来处理多类型数据。

constexpr详解 - C++ for the Antiquated（之一）

2024-12-28T00:00:00+08:00

在这篇文章中，我们将深入讨论 C++ 中的常量表达式（constexpr）及其与传统的const常量的区别，并结合实际代码示例进行说明。同时，我们还会探讨constexpr函数在模板编程中的应用，以及 C++11 之后对常量表达式的优化与扩展。

常量表达式（constexpr）

在 C++ 中，const 关键字通常用于修饰变量、引用和指针，使得它们在运行时不能被修改。需要注意的是，const 并没有区分编译期常量和运行时常量，它只是保证了这些变量在运行时不可修改。

例如，使用 const 声明的变量在运行时其值是固定的，但并不意味着它们在编译时已知。

下面是传统 C++ 中 const 关键字的一些常见用法：

#define CONSTANT_1 114514  // 宏也是一种常量
const char* helloworld1 = "helloworld";  // const 字符串
const int value1 = 1;  // 常量值
const int value2 = 2;
const int value3 = value1 + value2;  // 运行时计算
const int value8 = pow(value2, value3); 

const int arr_pow_of_2[] = {1, 2, 4};  // 数组初始化

在上述代码中，虽然 const 修饰的变量在程序运行期间不能修改，但它们的值是在运行时计算的。因此，我们无法在编译时将它们视为常量。所以，const 变量也可以有内存地址，并且在某些情况下可以使用 const_cast 强行进行修改。

#include <cstdio>
#include <cstdint>
#include <iostream>
#include <cmath>

void MakeChange(const int& x) {
    *(const_cast<int*>(&x)) = x + 1;
}

int main() {
    int x = 1;
    MakeChange(x);
    std::cout << x << std::endl; // 输出：2
    return 0;
}

引入 constexpr

C++11 引入了 constexpr，它的字面意思是 constant expression（常量表达式），用于在编译时计算常量值。与 const 不同，constexpr 确保一个变量或者函数的值是在编译时已知的，编译器会在编译时对其进行求值。

通过使用 constexpr，我们可以定义编译时常量，并且 constexpr 函数在某些情况下也能够在编译期计算结果。

使用 constexpr 重写上述代码：

constexpr const char* helloworld1 = "helloworld";
constexpr int value1 = 1;
constexpr int value2 = 2;
constexpr int value3 = value1 + value2;  // 编译期计算
constexpr int value8 = pow(value2, value3);  // 编译期计算

// 编译期初始化数组
constexpr const int arr_pow_of_2[] = {1, 2, 4};

常量表达式函数

constexpr 不仅可以修饰变量，还可以修饰函数。constexpr 函数的特性是，若输入的参数是编译时常量，那么它的返回值也是一个编译时常量。

以下是一个计算 Fibonacci 数列的示例：

constexpr uint64_t MOD = (1LL << 62) - 1;  // 编译时常量

constexpr uint64_t fib(uint64_t n) {
    uint64_t a = 0, b = 1;
    for (int i = 0; i < n; ++i) {
        uint64_t temp = a + b;
        a = b;
        b = temp % MOD;
    }
    return b;
}

int main() {
    // 在编译期计算 Fibonacci 数列
    constexpr uint64_t result = fib(123456);  
    std::cout << result << std::endl;
    return 0;
}

在这段代码中，fib 函数被标记为 constexpr，因此当传入常量参数时，编译器会在编译期间计算出 Fibonacci 数列的第 123456 项。需要注意的是，constexpr 函数的计算存在一些限制：

递归深度限制：constexpr 函数的递归深度通常受到编译器的限制，如果递归过深，编译器可能会产生错误或警告。
计算效率：尽管常量表达式函数可以在编译期计算，但对于复杂的运算，可能会增加编译时间，因为编译器需要进行更多的计算。

constexpr vs 模板元编程

constexpr 函数的使用在某种程度上简化了模板元编程。传统的模板元编程可以实现与 constexpr 类似的功能，但代码结构通常更加复杂。下面是使用模板元编程计算 Fibonacci 数列的代码：

const uint64_t MOD = 1999;

template <uint64_t N>
struct Fibonacci {
    static const uint64_t value = (Fibonacci<N - 1>::value + Fibonacci<N - 2>::value) % MOD;
};

template <> struct Fibonacci<0> { static const uint64_t value = 0; };
template <> struct Fibonacci<1> { static const uint64_t value = 1; };

int main() {
    std::cout << "Fibonacci(40): " << Fibonacci<40>::value << std::endl;
    return 0;
}

在这个模板元编程示例中，Fibonacci 结构体使用递归模板计算 Fibonacci 数列的第 N 项。这与 constexpr 函数类似，但模板元编程的语法更加繁琐。constexpr 的优势在于它能够写出更加接近正常逻辑代码的形式，并且具有更强的表达能力

C++14 对常量表达式函数的增强

在 C++14 中，常量表达式函数得到了进一步的增强。具体增强包括：

支持局部变量：constexpr 函数可以声明和初始化局部变量，但不能声明未初始化的变量、static 或 thread_local 变量。
支持 if 和 switch 语句：constexpr 函数可以使用 if 和 switch 语句来控制流程，但不能使用 goto。
支持循环语句：constexpr 函数支持所有类型的循环语句，包括 for、while 和 do-while。
修改生命周期：在 constexpr 函数内部，可以修改局部变量和非常量引用参数
返回值可以是 void：constexpr 函数可以声明返回类型为 void。

常量表达式与模板函数

在 C++11 引入 constexpr 后，建议在所有需要常量语义的场景中使用 constexpr。constexpr 变量和函数作为编译时常量，在模板函数中具有广泛的应用场景，能够显著提升程序的效率和可读性。

#include <cstdio>
#include <cstdint>

template <typename T>
constexpr T square(T x) {
    return x * x;
}

int main() {
    constexpr uint64_t square2 = square(2);       // 计算常量的平方
    constexpr double square2_0 = square(2.0);     // 计算浮点数的平方
    printf("%lu\t%.04lf\n", square2, square2_0);  // 输出结果
    return 0;
}

模板函数 square 使用了 constexpr，确保在编译时就可以计算结果。对于不同类型的参数（如整数、浮点数），模板会自动进行实例化。

如果模板参数不是编译期常量，constexpr 将不会在编译期执行，但函数本身仍然是有效的。

constexpr 函数中的动态内存分配

在 C++20 中，constexpr 函数得到了进一步增强，支持在编译期进行动态内存分配，但仍然存在一些限制。

std::array 的所有数据都存储在栈上，而不是堆上。严格的说，std::array不涉及动态内存分配。所以std::array可以在constexpr函数中被初始化、修改并返回。

#include <cstdio>
#include <cstdint>
#include <vector>
#include <array>

template <int maxstep=100>
constexpr std::array<int, maxstep> Collatz(int x) {
    std::array<int, maxstep> path;
    int idx = 0;
    while (true) {
        path[idx++] = x;
        if (x == 1) {
            break;
        }
        if (x % 2 == 0) {
            x /= 2;
        } else if (x % 2 == 1) {
            x = x * 3 + 1;
        }
    }
    return path;
}


int main() {
    constexpr auto path = Collatz(12345);
    for (auto item : path) {
        if (item == 0) {
            break;
        }
        printf("%d\n", item);
    }
    return 0;
}

而对于std::string或者std::vector这种需要在堆上分配内存的数据结构，我们则不可以在constexpr函数中直接返回。但是可以在constexpr函数中则用其进行计算。

#include <cstdio>
#include <cstdint>
#include <vector>
#include <array>
#include <string>

constexpr int square(int x) {
    return x * x;
}

constexpr int CountPrimes(int n) {
    std::vector<int> primes{2, 3};
    for (int i = 5; i <= n; i += 2) {
        bool flag = true;
        for (auto prime : primes) {
            if (i % prime == 0) {
                flag = false;
                break;
            }
            if (square(prime) >= i) {
                break;
            }
        }
        if (flag) {
            primes.push_back(i);
        }
    }
    return primes.size();
}


int main() {
    constexpr int cnt = CountPrimes(100);
    printf("%d\n", cnt);
    return 0;
}

constexpr virtual 函数

在 C++20 中，constexpr 函数可以与 virtual 关键字结合使用，实现在编译期进行多态求值。

虚函数的 constexpr 限制：constexpr 虚函数只能在编译期求值，前提是其被调用的具体对象类型是确定的。

在 constexpr 上下文中调用 virtual 函数时，调用将绑定到具体派生类的实现。

#include <cstdio>
#include <cstdint>

struct Base {
    constexpr virtual int Value() const = 0; // 虚拟 constexpr 函数
};

struct Derived1 : Base {
    constexpr int Value() const override { return 1; }
};

struct Derived2 : Base {
    constexpr int Value() const override { return 2; }
};

constexpr int Calc() {
    Base* d1 = new Derived1(); // constexpr 中分配内存
    Base* d2 = new Derived2();
    int value = d1->Value() + d2->Value(); // 调用虚函数
    delete d1; // 必须释放内存
    delete d2;
    return value;
}

int main() {
    constexpr auto v = Calc(); // 在编译期计算
    printf("%d\n", v);
    return v;
}

常量表达式用于模板函数的类型判断

在 C++17 中引入的 if constexpr 提供了一种更加简洁和可读的方式来进行模板元编程的类型判断。根据类型特性，在编译期选择不同的分支路径。

#include <cstdio>
#include <cstdint>
#include <iostream>
#include <cmath>
#include <type_traits>

template <typename T>
bool equal(const T& a, const T& b) {
    if constexpr (std::is_integral_v<T>) {
        return a == b; // 整数类型直接比较
    } else if constexpr (std::is_floating_point_v<T>) {
        return fabs(a - b) <= 1e-3; // 浮点数进行误差比较
    } else {
        static_assert(std::is_arithmetic_v<T> || std::is_pointer_v<T>, "not supported");
    }
}

int main() {
    std::cout << std::boolalpha;
    std::cout << equal(1, 1) << std::endl;                 // true
    std::cout << equal(1L, 1L) << std::endl;               // true
    std::cout << equal(1.0000001, 1.000002) << std::endl;  // true
    std::cout << equal(1.0000001, 2.000002) << std::endl;  // false
    return 0;
}

在传统C++中，我们常用std::enable_if来实现类似的功能。但是很明显，语法会显得过于笨重。

#include <type_traits>
#include <cmath>
#include <cstdio>

// 整数类型
template <typename T>
typename std::enable_if<std::is_integral<T>::value, bool>::type
equal(const T& a, const T& b) {
    return a == b;
}

// 浮点类型
template <typename T>
typename std::enable_if<std::is_floating_point<T>::value, bool>::type
equal(const T& a, const T& b) {
    return std::fabs(a - b) <= 1e-3;
}

// 其他类型
template <typename T>
typename std::enable_if<
    !(std::is_integral<T>::value || std::is_floating_point<T>::value), bool>::type
equal(const T& a, const T& b) {
    static_assert(std::is_arithmetic<T>::value || std::is_pointer<T>::value, "not supported");
    return false;
}

int main() {
    puts(equal(1, 1) ? "true" : "false");                      // 整数
    puts(equal(1.0000001, 1.000002) ? "true" : "false");        // 浮点
    return 0;
}

使用`consteval`强制使用编译期求值

consteval 是在 C++20 中引入的关键字，用于声明立即函数（immediate function）。立即函数要求在编译时进行求值，不能在运行时调用。
如果调用一个consteval。如果调用 consteval 函数时无法在编译期计算，编译器将报错。

constexpr 函数在某些情况下可能会退化为运行时调用，consteval 可以避免这种情况。

例如：

#include <iostream>

// consteval 强制要求在编译时进行计算
consteval int factorial(int n) {
    return (n <= 1) ? 1 : (n * factorial(n - 1));
}

int main() {
    constexpr int result = factorial(5); // OK：在编译时计算
    std::cout << "Factorial of 5 is: " << result << std::endl;

    // int runtime = 5;
    // std::cout << "Factorial of runtime: " << factorial(runtime) << std::endl;
    // 错误：factorial 必须在编译时调用

    return 0;
}

使用`constinit`显式要求编译时初始化

constinit 关键字用于显式要求全局或静态变量在编译期完成初始化。
如果变量无法在编译时初始化，编译器将报错。
constinit 不能用于局部变量。

与 constexpr 不同，constinit 变量可以在运行时被修改。
线程安全性：在多线程环境中，constinit 确保变量在编译期初始化，避免线程安全问题。

#include <array>

// 编译时初始化
constexpr int compute(int v) { return v * v * v; }
constinit int global = compute(10);

// 错误：constinit 变量不能依赖运行时初始化
// constinit int another = global;

int main() {
    global = 100; // 允许在运行时修改

    // 错误：constinit 变量不是常量，不能用作数组大小
    // std::array<int, global> arr;

    std::cout << "Global value: " << global << std::endl;
    return 0;
}

总结

constexpr在多数情况下可以替代const以表达“编译期常量”的语义，可用于函数、变量、类等场景。constexpr 支持在编译期和运行期进行求值，但在某些情况下可能会退化为运行期求值。
常量表达式函数提供了一种更清晰的编译期计算方式，能够在一定程度上取代复杂且晦涩的模板元编程。随着 C++ 标准的演进，constexpr 函数逐步支持了更复杂的语法和逻辑，例如条件语句、循环语句和局部变量。但对于极端复杂的计算场景，编译期计算可能导致显著的编译时间开销。
constexpr可以在模板函数中用于类型判断，通过if constexpr语法有效地取代std::enable_if，从而简化模板编程，提高代码的可读性和可维护性。
constexpr函数的隐式退化风险：在某些场景下，constexpr 函数可能在运行时执行。若需要严格保证仅在编译期求值，可以使用 consteval 来强制进行编译期求值，避免不必要的运行时开销。
constinit提供了一种显式要求变量在编译时完成初始化的机制，适用于非constexpr变量。这在全局和静态变量的初始化中尤为有用，同时也保证了多线程环境下的初始化安全性。

CPU缓存一致性与内存一致性（第二部分-内存一致性）

2024-09-01T00:24:00+08:00

缓存一致性与内存一致性

缓存一致性和内存一致性是多处理器系统中的两个不同概念，它们解决的是不同类型的内存访问问题。

缓存一致性协议（如 MESI 协议）用于解决多个处理器对相同内存位置进行访问和修改时的数据一致性问题。它确保各处理器的缓存中针对同一内存地址的副本保持一致，避免因缓存不同步而导致的数据错误。

而内存一致性关注的是处理器对多个不同内存地址的访问顺序问题。当不同处理器的内存访问顺序与程序代码中的预期顺序不一致时，就会引发内存一致性问题。它要求各处理器按照一定的规则访问内存，以保持程序逻辑的正确性。

简而言之，缓存一致性解决的是同一内存位置的数据同步问题，而内存一致性则涉及多个内存位置的访问顺序问题。

内存乱序访问产生的原因

内存乱序访问的原因可以从两个方面来理解：程序顺序（Program Order, PO）和内存顺序（Memory Order, MO）。程序顺序是指程序代码中编写的内存访问序列，反映了程序员预期的指令执行顺序。按照程序顺序，指令应该依次被执行，以确保程序的逻辑正确性。然而，在实际执行中，系统中可能存在一种不同的顺序，即内存顺序。

内存顺序是指系统中所有处理器对内存操作达成一致的访问顺序。由于现代计算机系统通常由多个处理器共同操作共享内存，为了提高整体性能，这些处理器可能会对内存操作进行重排序，从而产生与程序顺序不一致的内存顺序。

这种内存乱序访问的现象主要是为了优化程序执行效率，通常发生在两个阶段：编译阶段和执行阶段。在编译阶段，编译器会对代码进行优化，这可能会导致指令的重排序，以提高执行效率。在执行阶段，多个 CPU 之间的交互也会引起内存访问顺序的不一致。

在单处理器系统中，CPU 对指令的乱序执行和重排对于程序员来说是透明的，即程序的执行结果与顺序执行的结果是一致的。然而，在多处理器系统中，不同的处理器（或称为观察者）可能会观察到不同的内存执行顺序，这与指令的实际执行顺序不完全一致，从而导致潜在的同步问题和数据不一致性。

几种常见的一致性模型

在多处理器系统中，内存一致性模型决定了不同处理器之间如何观察和执行内存操作的顺序。以下介绍几种常见的一致性模型：

顺序一致性模型（Sequential Consistency, SC）

顺序一致性模型的概念最早由 Leslie Lamport 在 1979 年的论文《如何构建正确执行多处理程序的多处理计算机》中提出。按照他的定义：

任何执行的结果都与所有处理器的操作按照某种顺序依次执行的结果相同，并且每个处理器的操作在这个顺序中出现的顺序与其程序中指定的顺序一致。满足这一条件的多处理器被称为顺序一致性系统。

顺序一致性模型保证了每个加载（Load）和存储（Store）指令按照程序中指定的严格顺序执行，确保了“读->读”、“读->写”、“写->写”以及“写->读”四种操作的顺序。这种模型提供了最强的内存一致性保证，但代价是较低的执行效率，因为它不允许任何形式的指令重排序。

处理器一致性模型（Processor Consistency, PC)

处理器一致性模型是顺序一致性模型的弱化版本，它放宽了对“写->读”操作顺序的要求。该模型允许处理器在读取时从存储缓冲区（Store Buffer）中获取一个尚未写入缓存的值，即使这个值还没有被其他处理器看到。x86-64 实现的全序写（Total Store Ordering, TSO）模型就是处理器一致性的一种。TSO 允许一定程度的乱序执行，提高了系统的性能，同时仍然提供了较强的一致性保证。

弱一致性模型（Weak Consistency, WC）

弱一致性模型进一步弱化了处理器一致性模型的要求，放宽了对“读->读”、“读->写”、“写->写”以及“写->读”四种操作顺序的约束。为了确保程序执行的正确性，程序员需要在合适的地方显式添加同步操作。在这种模型中，多处理器系统的内存访问满足以下三个条件时称为弱一致性内存访问：

对全局同步变量的访问是顺序一致的
在一个同步操作（如内存屏障指令）执行之前，所有先前的数据访问必须完成；
在一个正常的数据访问（如数据访问指令）执行之前，所有先前的同步操作（如内存屏障指令）必须完成。

释放一致性模型（Release Consistency, RC）

释放一致性模型是在弱一致性模型的基础上引入了“获取”（acquire）和“释放”（release）屏障原语，用于简化共享数据的互斥访问。

在该模型中，“获取”屏障原语后面的读写操作不能被重排到该屏障之前，“释放”屏障原语前面的读写操作不能被重排到该屏障之后。这种机制能够更高效地管理多处理器系统中的共享数据访问，提高并行性能。

这些内存一致性模型提供了从严格到宽松的不同选择，适应不同的应用需求和性能要求。选择合适的一致性模型对多处理器系统的设计和优化至关重要。

四种内存乱序

在多处理器系统中，为了优化性能，处理器可能会对内存操作进行不同类型的乱序执行。这种乱序行为包括四种主要类型，每一种都会以不同的方式影响多线程程序的正确性和一致性。

LoadLoad 乱序

LoadLoad 乱序指的是后续的加载（读取）操作可以在先前的加载操作完成之前开始，或者两个加载操作的完成顺序与它们的发起顺序不同。这意味着处理器可能会优先执行后发起的加载操作。这种乱序优化可能有助于提高程序的执行速度，但如果未加以控制，可能会导致某些线程读取到不一致的数据。

LoadStore 乱序

LoadStore 乱序表示一个存储（写入）操作可以在之前发起的加载操作完成之前开始执行，或者写操作可能“超越”读操作。尽管这种优化可以提高处理器的性能，但在多线程程序中可能导致意外的行为。例如，一个线程可能会看到数据被写入之前的状态，导致逻辑错误或数据不一致。

StoreLoad 乱序

StoreLoad 乱序是四种乱序类型中对编程模型影响最大的一种。它允许一个加载操作在之前的存储操作完成之前开始，或者读取操作可能看到写操作的结果，即使这个写操作在程序中的顺序上应该发生在读操作之后。这种乱序执行可能导致一个线程读取到另一个线程的“旧”值，而不是最新写入的值，从而引发数据同步问题。

StoreStore 乱序

StoreStore 乱序涉及两个连续的存储操作，其中后一个存储操作可以在第一个操作完成之前开始，或者它们的完成顺序与它们被发起的顺序不同。这意味着，后一个写操作的结果可能在前一个写操作的结果对其他处理器可见之前就已经被观察到，从而造成数据顺序的不一致。

管理内存乱序的重要性

正确管理这些乱序行为对于并发编程至关重要，特别是在设计无锁数据结构和编写多线程程序时。如果不加以控制，这些乱序可能导致数据不一致、难以重现的错误和程序崩溃。为了避免这些问题，现代处理器和编程语言提供了各种内存屏障（Memory Barriers）或内存顺序（Memory Order）指令，确保在关键的程序点上强制执行所需的内存操作顺序。这些机制帮助程序员在优化性能的同时，维护数据的一致性和正确性。

使用Litmus工具分析内存乱序 - 以x86-TSO为例

在并发编程中，理解和验证内存模型的行为对于确保程序的正确性至关重要。以 x86 Total Store Order (x86-TSO) 为例，我们可以使用 Litmus 测试工具来分析内存乱序现象，并了解如何通过内存屏障来避免这种情况。

Litmus工具可以在这里在线试用，也可以安装到本地环境

x86 Total Store Order (x86-TSO)

在 x86 架构中，Store Buffer（存储缓冲区）用于暂时存放处理器的写操作，而不立即将其写入主存。这种机制提高了处理器的性能，因为它允许处理器在写操作尚未完成时继续执行后续指令。然而，Store Buffer 也导致了某些内存操作的可见性问题，特别是在多处理器环境中。

x86 Total Store Order (x86-TSO) 模型的特性正是由这种 Store Buffer 机制决定的。由于写操作在 Store Buffer 中暂存，x86-TSO 模型保证了一些关键特性，同时也做出了一些基于性能的妥协：

写操作顺序一致性：所有写操作按照程序的顺序执行，并对所有处理器可见，即写操作在 Store Buffer 刷新到主存之前，不会被其他处理器看到。
读操作的自我可见性：处理器可以立即看到自己在 Store Buffer 中的最新写入，即本处理器的读操作可以从 Store Buffer 中读取未提交到主存的值。
防止某些重排序：为了避免因 Store Buffer 导致的读写乱序，x86-TSO 禁止写操作与其后的读操作重排序，确保读写顺序一致。
允许部分读操作重排序：为了进一步提升性能，处理器允许一些读操作的重排序，但仍然遵循严格的规则以保证程序的正确性。

使用 Litmus 验证 x86 的 StoreLoad 乱序

我们可以使用 Litmus 工具来验证在 x86-TSO 内存模型下的 StoreLoad 乱序行为。以下是一个示例代码：

X86 SB
{ x = 0; y = 0; }

P0          | P1          ;
MOV [y],$1  | MOV [x],$1  ;
MOV EAX,[x] | MOV EAX,[y] ;
exists
(0:EAX=0 /\ 1:EAX=0)

在执行该代码后，Litmus 会生成四种可能的结果，分别对应不同的执行顺序。

结果1

在结果1中，程序按照严格的顺序执行，每个处理器的内存操作顺序与程序中的顺序一致。

图中，po（Program Order）表示程序顺序，rf（Reads-From）表示每个读操作从哪个写操作中读取的值。由于内存操作按照预期顺序执行，这种情况没有进一步的乱序行为，因此不需要进一步分析

结果2/结果3

结果2和结果3是对称的，表示在执行过程中，内存的读取发生了“乱序”，即读取操作被重排到了写入操作之前。在 Litmus 中，这种情况被标记为 fr（From-Read），表示一个写操作覆盖了一个读操作所读取的值，即这个写操作发生在读操作之后。这种“写读”操作的乱序可能是由于执行顺序的不同，也可能是内存模型的顺序造成的。

结果4

结果4表示两个线程各自都发生了 fr，即每个线程的读操作都被重排到了写操作之前。这种情况展示了最复杂的乱序行为，其中两个线程的读操作分别“超越”了各自的写操作。

使用内存屏障（MFENCE）指令避免内存乱序

为了避免这种乱序情况，可以使用 MFENCE（Memory Fence）指令。在 x86 架构中，MFENCE 是一种强制内存屏障，确保所有在 MFENCE 之前的内存操作（无论是读还是写）在所有 MFENCE 之后的内存操作之前完成。这意味着在同一线程内，MFENCE 保证了内存操作的顺序性：MFENCE 之前的操作对其他线程可见后，才可以执行 MFENCE 之后的操作。

我们可以将 Litmus 代码修改如下，以插入 MFENCE 指令：

X86 SB
{ x = 0; y = 0; }

P0          | P1          ;
MOV [y],$1  | MOV [x],$1  ;
MFENCE      | MFENCE      ;
MOV EAX,[x] | MOV EAX,[y] ;
exists
(0:EAX=0 /\ 1:EAX=0)

在加入内存屏障后，我们看到结果1到结果3依然会出现，但结果4因 MFENCE 的存在而被避免。通过 MFENCE 确保了内存操作的顺序性，从而防止了某些类型的内存乱序，保证了多线程程序的正确性和一致性。

接下来…

下一篇文章中，我们会介绍C++的内存顺序模型，并且分析更复杂的内存乱序问题

References

本文大（划掉）部分内容由ChatGPT4生成

利用凸组合求解最优值（AtCoder abc356_g Freestyle 题解）

2024-06-15T00:00:00+08:00

题目大意
- 我们已经学会了 N 种不同的游泳技术。对于每种技术 $i$ ，每秒前进 $A_{i}$ 米，并消耗 $B_{i}$ 单位的体力。注意，我们可以任意调整每种技术的使用时长 $t_i$ ，其中 $t_i$ 是一个实数
- 现在，我们面临 $Q$ 次询问，每次询问指定距离终点的距离 $C_j$ 和体力限制 $D_j$ 。我们需要确定是否在体力限制下到达终点。如果可以，求出所需的最短时间。
- （符号使用与原题略有差异）
- 数据规模：
  - $1 <= N, Q <= 2 \times 10^5$
  - $1 <= A_i, B_i, C_j, D_j <= 10^9$
题目分析
- 鉴于数据规模庞大，并且时间 $t_i$ 是实数，传统的动态规划方法不适用。在处理每次询问时，我们需要同时考虑距离、体力和时间三个变量。一个有效的方法是转化这些变量为单位时间内的距离（即速度）和单位时间内的体力消耗。如果单位时间内的距离大于单位时间内的体力消耗，那么理论上我们可以到达终点。接下来的目标是在所有可能的情况中找到最大的速度，作为最终答案。
  以两种游泳技术（N=2）为例进行具体分析。假设在总游泳时间中，技术1和技术2的使用时间比例分别为 $p$ 和 $1-p$ （其中 $0 \leq p \leq 1$ ）。在这种情况下，每秒前进距离为 $A_1 \cdot p + A_2 \cdot (1 - p)$ ，体力消耗为 $B_1 \cdot p + B_2 \cdot (1 - p)$ 。
  从几何角度看，组合这两种游泳技术的速度与体力消耗 $(A_x, B_x)$ 为 $(A_1, B_1) \cdot p$ 和 $(A_2, B_2) \cdot (1 - p)$ 的向量和，其可能的取值位于以 $(A_1, B_1)$ 和 $(A_2, B_2)$ 为端点的线段上的任意一点。
  对于具体询问 $(C_i, D_i)$ ，为了确保“在到达终点之前不能耗尽体力”，我们需要找到的点必须位于斜率为 $D_i/C_i$ 的射线与x轴之间的夹角内。通过这种方式，我们可以确定是否有可能在给定的体力限制下完成指定的距离，并找到速度最快的点。
- 对于多种游泳技术的组合，情况会更复杂一些。我们将所有游泳技术视为一组向量 $(A_1, B_1), (A_2, B_2), \ldots, (A_n, B_n)$ 和一组对应的权重 $p_1, p_2, \ldots, p_n$ ，其中 $\sum_{i=1}^n p_i = 1$ 并且每个 $p_i \geq 0$ ，那么这些向量的加权和 $\sum_{i=1}^n p_i (A_i, B_i)$ 定义了一个在二维空间中的凸多边形，称为这些向量的凸包。
- 我们可以用稍微详细一点的数学来解释这一过程：
  - 向量的线性组合
    - 首先，定义向量 $\mathbf{v}_1, \mathbf{v}_2, \ldots, \mathbf{v}_n$ 在二维空间中的位置。每个向量 $\mathbf{v}_i$ 可以表示为从原点到点 $(x_i, y_i)$ 的箭头。
      当我们考虑这些向量的线性组合时： $\sum_{i=1}^n \lambda_i \mathbf{v}_i$
      其中，每个 $\lambda_i$ 是一个实数系数，我们实际上在描述一个新向量，这个向量是通过在每个原向量上“拉伸”或“压缩”（取决于 $\lambda_i$ 的正负和大小），然后将结果相加得到的。这种线性组合在几何上定义了一个点的集合。
  - 凸组合与凸多边形
    - 当这些系数 $\lambda_i$ 都非负且和为1（即 $\lambda_i \geq 0$ 且 $\sum_{i=1}^n \lambda_i = 1$ ），我们称这样的线性组合为凸组合。凸组合具有重要的几何特性：它定义的点一定位于这些向量端点所形成的凸多边形内部或边界上。
  - 凸多边形的形成
    - 1. 边界的构成：如果你只考虑两个向量 $\mathbf{v}_1$ 和 $\mathbf{v}_2$ ，那么它们的凸组合会形成一条连接两点 $(x_1, y_1)$ 和 $(x_2, y_2)$ 的线段。这条线段是直线，因为所有的组合点都直接通过两点间的直线路径互相连结。
    - 1. 扩展到多个向量：当你有三个或更多向量时，通过考虑任意两个向量的所有凸组合（即所有可能的线段），然后再将这些线段的结果进行组合，最终你将覆盖一个多边形区域。这个区域是由最外围的向量点定义的，这些点在几何上构成了凸多边形的顶点。
    - 1. 数学描述：在数学上，这个区域可以看作是所有可能的 $\lambda_i$ 值（符合凸组合条件）下的 $\sum_{i=1}^n \lambda_i \mathbf{v}_i$ 的集合。由于每个 $\lambda_i$ 都保证非负且和为1，凸多边形的任意内部或边界点都可以通过这样的组合表示，且不会有任何点“凸出”于这个定义的多边形之外，这正是凸性质的体现。
- 类似于仅涉及两个点的简单情况，为了解决问题，我们需要找到凸多边形内与 $x$ 轴之间斜率为 $D_i/C_i$ 的射线包围的区域（即凸包中的深色部分）。我们进一步需要找出该部分中在 $x$ 轴上取得最大值的点。
代码实现 - 并不高效
- 实现步骤
  - 求出所有 $(A_i, B_i)$ 点所构成的凸包
  - 对于每一个查询Q，从零点画出斜率为 $D_i / C_i$ 的射线
  - 如果凸包位于射线的“上方”，则没有满足条件的情况，返回-1
  - 如果凸包位于射线的“下方”或与射线相交，则需要找到凸包在射线“下方” $B_i$ 值最大的点。意味着这个组合可以成功到达终点，并且平均速度最快
- 复杂度分析
  - 对于每一次查询，我们都要遍历凸包的所有边（即“凸包壳”）与射线的交点。时间复杂度 $O(n)$ 。
  - 对于所有查询，时间复杂度为 $O(q * n)$ ，明显是会超时的。
优化的可能性
- 易知，并不是凸包的所有部分都能得出最优解。与原点连线斜率越小的点，其“性价比”越高，即在消耗更少的体力的同时，可以游更远的距离。
  同时，如果凸包内部的某一个点满足条件，则总有位于凸包壳上面的另一个点与它更优。同样，如果凸包壳上有两个点的斜率相同，那么 $B_i$ 值更大的点是更优的。
  所以优化的目标在于找到一系列凸包壳，使其可以只保留最优解所在的边，并且排除所有非最优的情况。
  我们可以从“性价比”最好的点开始，因为对于一个查询，如果所需要的“性价比”高于我们所有的选项，那么一定没有解。
  然后我们逆时针遍历所有点，直到找到 $B_i$ 值最大的点，因为对于一个查询，在满足“性价比”的情况下，这是我们能给出的，消耗时间最小的答案。
- 实现方案1:
  - 我们可以使用凸包算法，找到凸包壳，按照上文所述的方法，找到斜率最小（所谓“性价比最高”）的点，然后逆时针遍历到 $B_i$ 最大的点。这些点必然以斜率从小到大排序。
    对于一个查询 $(C_i, D_i)$ ，我们将其视为斜率为 $D_i / C_i$ 的射线。我们使用二分法，找到与该射线相交的凸包壳边。再通过联立方程方法找到其交点 $(A_x, B_x)$ ，其中 $A_x$ 即为满足查询条件的最大游泳速度。
- 实现方案2：
  - 方案2与方案1类似，只是在查找凸包的时候，加入点 $(0, 0)$ 与点 $(max(A_i), INF)$ 。如下图所示，加入这两个点之后，非最优解的点都被包含在了凸包（蓝色）内部。我们在找到凸包之后，将加入的点删除，并按方案1的方法排序。后续再进行二分，以及求交点等操作。
代码实现
- 我写的（抄了别人的凸包算法）
- 官方题解
感悟
- 别调计算几何，会变的不幸（

实现一个无锁消息队列（续与勘误）

2024-04-14T00:00:00+08:00

本文内容主要参考自Implementing Lock-Free Queue一文（以下简称“原论文”）
是对实现一个无锁消息队列一文的内容进行补充
TL；DR
- 尽管实现一个无锁消息队列一文中的实现是正确的，但是忽略了“非阻塞性”
  - 例如，当任一插入操作被阻塞，则其它插入操作均会陷入忙等待
  - 此实现与A simple and correct shared-queue algorithm using Compare-and-Swap的实现基本一致
- 对于一个支持并发的数据结构，理应同时具备非阻塞性和无等待性
  - 非阻塞性（non-blocking）：无论是由于CPU调度或其他外部因素，数据结构的操作不能被中断或延迟
  - 无等待性（wait-free)：保证没有任何线程会遭受饥饿状态
- 前一篇博文对其它实现的质疑，主要在于ABA问题，但这个问题是Compare&Swap所特有的，需要特定的实现来规避
理论基础
- 我们的目标是实现一个支持并发enqueue/deque的队列
- 对于这样的数据结构，有两个重要的特性
  - 非阻塞性（non-blocking）
    - 对于每一个执行线程，所有的操作将会在有限的次数内完成
    - 无论本线程或其它线程在执行过程中因其它原因（如CPU调度）执行过缓，或者被中断
  - 无等待性（wait-free)
    - 没有线程会饥饿
  - 基于锁的数据结构不符合上述特性，因为持有锁的线程可能会无限期地阻塞所有操作
  - “线性一致性”(Linearizability) —— 更强的正确性
    - 非并发操作应当按照它们的逻辑顺序执行，以保证操作的正确性，而并发操作则可以按任意顺序进行
- “Fetch&Add” 与 “Compare&Swap”
  - 常用的原子操作，这里不做赘述
基于链表的无锁队列实现
- 略，参考原论文与无锁队列的实现一文
基于数组的无锁队列实现
- 略，参考原论文与无锁队列的实现一文
ABA问题
- Compare&Swap操作确保了值修改的原子性。指针作为值的一种，代表着某个内存地址，但Compare&Swap对指针的操作无法保证其指向的内存内容不被修改
- 考虑到可能释放旧内存后再申请新内存，这两块内存虽逻辑不同却可能拥有同一地址，这对Compare&Swap操作造成了困扰
- 解决方案是为指针加入引用计数（ref count），以确保内存在可访问时不会被释放或重用
性能对比
- 上面我们已经提到，A simple and correct shared-queue algorithm using Compare-and-Swap一文中的方法缺少了“非阻塞性”，，但其性能与原论文中的实现十分接近
- 但是在原理上，“非阻塞性”实现可以避免意外的线程停止或延迟
- 疑问：是否会在P99级别的Latency上才会体现出明显的差异？
参考链接
后续

本文大（划掉）部分内容由ChatGPT4生成

CPU缓存一致性与内存一致性（第一部分-MESI协议）

2024-03-18T23:21:35+08:00

在对称多处理系统（Symmetric Multiprocessing, SMP）中，一个变量（或内存位置）可以同时存在于多个CPU的缓存行中。为了提供完美的用户级抽象，任何对一个或多个变量的修改都应该被强制同步，以确保其它CPU的缓存得到更新。
然而，在实现上，由于CPU之间通常通过总线互联，它们不能同时对多个缓存进行写操作。

缓存一致性

缓存一致性是指在一个多处理器系统中，确保当某个处理器修改了存储在共享资源（如主内存或缓存中的数据）时，其他处理器能够访问到最新的数据版本，从而保证数据的一致性。

为了达到这一目标，缓存一致性机制必须处理两个主要问题：写传播（Write Propagation）和事务串行化（Transaction Serialization）。

写传播确保一个处理器核心的写操作能被传播并被其他处理器核心所见。而事务串行化则确保所有处理器核心的写操作按照一定的顺序执行，对所有处理器核心而言这个顺序是一致的。这两个机制共同工作，确保了即使多个CPU可能并发地修改同一份数据，它们也能看到一致的数据视图。

MESI协议

为了实现缓存一致性，多种协议和机制被设计出来，其中MESI协议是最广泛使用的一种机制。

实际上，AMD处理器使用的是MOESI协议，Intel处理器使用的是MESIF协议。这两种协议都是MESI协议的变种。这里不展开讨论。

MESI 协议通过定义缓存行的四种状态——修改（Modified）、独占（Exclusive）、共享（Shared）和无效（Invalid），管理多个处理器缓存之间的一致性。状态之间的转换受到缓存协议控制，以确保数据的一致性和同步。

独占（Exclusive, E）：缓存行仅存在于当前缓存中，并且是干净的（即缓存数据与主存数据一致）。当其他缓存尝试读取该数据时，状态转变为共享；当前缓存写入数据时，转变为已修改状态
共享（Shared, S）：缓存行同时存在于其他缓存中，并且是干净的。该缓存行可以在任意时刻被抛弃
已修改（Modified, M）：缓存行的数据是“脏”的（即与主存的值不同）。如果其他 CPU 核心需要读取这块数据，该缓存行必须先回写到主存，然后状态转变为共享
无效（Invalid, I）：表示该缓存行无效，即为空。上文提到的缓存策略会优先填充无效行

简单来说，MESI的设计目标在于：

防止多个处理器核心同时对共享数据进行修改。任何需要修改共享数据的核心都会先发出RFO（Read For Ownership）请求来获取该缓存块的所有权，并使其他处理器核心中的相应缓存块变为无效。
通过推迟写回操作来减少对内存的频繁修改，确保只有在必要时才将缓存中的更改写回内存。

MESI 的状态转移

MESI 协议的状态转移如下：

从无效（I）到独占（E）：当 CPU 需要写入一个缓存行而该行当前状态为无效时，如果其他 CPU 缓存中没有该缓存行的副本，该行状态变为独占。这表明当前 CPU 缓存中的数据是最新的，且没有其他副本存在
从无效（I）到共享（S）：当 CPU 需要读取一个缓存行而该行当前状态为无效时，如果其他 CPU 缓存中存在该缓存行的副本，则该行状态变为共享
从共享（S）到独占（E）：当一个 CPU 想要写入一个处于共享状态的缓存行时，必须首先获取其他所有 CPU 上该缓存行的独占访问权，如果成功，该缓存行状态变为独占
从独占（E）到修改（M）：当 CPU 对处于独占状态的缓存行进行写操作时，该缓存行状态变为修改。这表示数据已被当前 CPU 修改，且与主存不同步
从修改（M）到共享（S）：当其他 CPU 请求读取处于修改状态的缓存行时，当前 CPU 必须将该缓存行的数据写回主存，并将缓存行状态改为共享，以便其他 CPU 可以读取最新数。
从任何状态到无效（I）：当 CPU 接收到其他 CPU 发出的无效化请求时，如果当前 CPU 缓存中有该缓存行的副本，不论它处于何种状态，都必须将其标记为无效。这通常发生在其他 CPU 想要写入同一缓存行的情况下

可以使用这个简单的模拟器来模拟MESI协议的工作状态

MESI的优化

随着多核处理器的普及和系统复杂度的增加，MESI协议面临着性能瓶颈和效率问题。因此，为了提高系统性能和缩短响应时间，对MESI协议的优化变得非常必要。

写缓冲区（Store Buffer）机制

在进行写入操作时，一个CPU核心（例如核心1）首先需要广播一个读取为了写入（Read For Ownership，RFO）请求，以获得对应数据的独占访问权。在等待其他核心响应此请求并发送回确认信号（ACK）期间，核心1原本需要空闲等待，这无疑是对CPU资源的一种浪费。

为了提高效率，现代CPU设计了“写缓冲区”机制。通过这种机制，当核心1发出RFO请求并将写入操作放入写缓冲区后，它可以立即继续执行其他任务，而不需要等待ACK的到来。一旦收到ACK，CPU再从写缓冲区中取出写入操作，实际写入到缓存中。这样不仅优化了CPU的工作流程，还提升了处理器的整体效能。

失效队列（Invalidation Queue）

为了解决核心在忙碌时无法及时响应RFO请求的问题，现代CPU引入了“失效队列”机制。收到的RFO请求被放入失效队列，并立即发送回ACK，待核心完成手头上的任务后，再处理失效队列中的请求。这种设计有效地缩短了等待时间，加速了数据同步过程。

MESI的潜在问题

由于CPU以64B的Cache Line为最小单位从内存中加载数据，可能会出现这样的问题：

假设变量a和b位于同一个Cache Line中，当前CPU0和CPU1都将这个Cache Line加载到Cache，CPU0只修改变量a，CPU1只读取变量b。当CPU0修改a时，CPU1的Cache Line会变为Invalid状态，即使CPU1并没有修改b，这会导致CPU1从内存或其它核心重新加载Cache Line中的所有变量，影响性能。这就是False Sharing。

解决False Sharing的常用方法是进行字节填充，在a和b之间填充无意义的变量，使一个变量单独占用一个Cache Line。

RMW操作

在并发编程中，读-改-写（RMW）操作，如比较并交换（CAS）和原子加（ADD），需作为单一的原子操作执行以避免数据竞争。

尽管MESI缓存一致性协议确保了处理器核心间缓存行状态的一致性，它并不解决操作的原子性问题。在RMW操作中，由于从读取到写回的时间窗口内可能发生其他处理器的干预修改，可能导致数据竞争和状态不一致。

在为此，LOCK指令被用来确保RMW操作的原子性，通过锁定操作涉及的缓存行，防止在操作完成前被其他处理器访问，从而有效地解决了数据竞争问题，保障了操作的安全性和数据的一致性。

写缓冲区（Store Buffer）优化带来的潜在问题

写缓冲区带来的最主要的问题是与其他核心的数据一致性问题。由于写操作被延迟执行，其他核心可能在这段时间内读取到了旧的数据值，从而导致数据不一致的问题。此外，写缓冲区可能导致内存顺序的问题，即编写的程序逻辑与实际执行逻辑不符。

失效队列（Invalidation Queue）带来的潜在问题

失效队列提高了响应速度，但它也可能引入新的问题。失效队列允许CPU核心在确认接收到失效请求后，延迟处理这些请求。这种延迟可能导致数据在不同核心间的一致性问题，即一个核心可能会在短时间内继续使用已经失效的数据，而这段时间内其他核心已经修改了这部分数据。

参考链接

本文大（划掉）部分内容由ChatGPT4生成

[tl;dr] 论文阅读：Borg - Large-scale cluster management at Google

2023-12-27T00:00:00+08:00

系统概览
- Borg是谷歌开发的一种高效的集群管理系统，旨在优化资源利用率和提高系统的可靠性及可用性
  - 隐藏资源管理细节与故障处理，允许用户专注于应用程序的开发
  - 保证非常高的可靠性和可用性，以支持用户应用程序的高可靠性和高可用性
  - 支持运行来自众多应用的数十万个作业，并高效运行于数以万计的机器上
用户视角
- 用户通过定义job和task与Borg进行交互
  - 一个job由运行相同程序的一个或多个task组成
  - 每一个job运行于一个Borg cell（单元）之中，cell是一组机器的集合，是Borg管理的基本单元
- Borg的工作负载
  - 长期运行的时延敏感型服务
  - 批处理作业
  - 运行在实体机上，避免VM的虚拟化开销
- Allocs
  - 预留给一项或多项任务的一组资源
  - Alloc可以将不同 jobs 的 tasks 聚集到同一台机器上
  - 如果一个 alloc 必须重新分配到另外一台主机，属于它的 task(s) 也会同它一起重新被调度
  - 一旦创建一个 alloc 集合，就可以提交一个或多个 jobs 运行其中
- 命名服务和监控
  - Borg包含一个稳定的 Borg命名服务 (BNS)，包括 cell 名，job 名和 task id
  - Borg将 task 的主机名和端口写入 Chubby，用于 RPC 系统查找 task endpoint
  - Borg还会将 job size与其运行状态写入Chubby，便于load balancer平衡流量
Borg的架构
- Borgmaster
  - 主管理进程
    - 逻辑上的“单点”，有5个在线备份，使用Paxos选举master
    - 状态存储在内存中，并且备份在高可靠性的Paxos存储中
  - 调度进程
    - 可行性检查
      - 用于找到满足任务约束、具备足够可用资源的一组机器
    - 打分（scoring）
      - 在“可行机器”中根据用户偏好，为机器打分
      - 打分策略
        
        worst fit（E-PVN的变种）会将任务分散到不同的机器上
        
        有余量应对流量的尖峰
        
        会导致资源的碎片化，阻碍大型task的部署
        
        best fit，会尽量“紧凑”的使用机器，以减少资源碎片
        
        便于大型task的部署
        
        错误的资源估计会被“惩罚”，尤其影响突发的负载
        
        影响利于富裕计算资源的batch jobs
        
        混合模型，尽量减少“受困资源”，即因为其它资源被完全占用而无法分配出去的资源
    - 优化
      - 启动时间优化
        
        中位数启动时间为25s，80%用于安装相关依赖
        
        将相关task优先分配到拥有相关依赖的机器上
        
        使用 tree-like 或 torrent-like 机制，并发的分发相关依赖
      - 计算开销优化
        
        使得Borg能管理更多的机器
        
        打分缓存：将可行性检查和打分结果缓存
        
        等价类：同一 job 中的 task 通常具有类似的约束，因此可以将多个任务视为一个等价类
        
        松弛随机化：计算所有机器的可行性和得分代价太高，可以随机取样一批机器，然后选择其中一个“足够好”的机器
- Borglet
  - Borglet 是运行在每台机器上的本地代理，管理本地的任务和资源
  - Borgmaster 会周期性地向每一个Borglet拉取当前状态，易于控制通信速度，避免“恢复风暴”
  - 为了性能可扩展性，每个Borgmaster副本会运行无状态的 link shard 去处理与部分Borglet通信
    - 当 Borgmaster 重新选举时，link shard 会重新划分分区
    - link shard 会聚合和压缩信息，仅仅向被Borgmaster报告状态的更新，以此减少更新负载
  - 如果 Borglet 多轮没有响应资源查询，则会被标记为down。运行其上的任务会被重新调度到其他机器。如果恢复通信，则 Borgmaster 会通知 Borglet 杀死已经重新调度的任务，以此保证任务的唯一性
  - Borglet与Borgmaster失去联系时，仍会继续处理相关任务。以应对 Borgmaster 的暂时失效
可靠性
- 自动重新调度器被驱逐的任务
- 将任务分散到不同的失败域中
- 限制一个作业中同时失败任务的个数和中断率
- 使用声明式的期望状态表示和幂等的变更操作，以便无害地重新提交请求
- 对于机器级别的失效，限制其重新调度的速率，因为难以区分大规模机器故障和网络分区
- 避免重试引发错误的<任务-机器>匹配对
- 关键数据持久化，写入磁盘
资源利用和效率
- 评估方法
  - cell compaction：通过移除机器来找出给定工作负载能适应的最小的单元大小，然后反复从头开始重新打包工作负载，以确保不会因错误的配置而陷入困境
- “单元共享”：在同一台机器上运行生产任务和非生产任务，以优化资源使用
  - 实验表明，共享资源会影响实际的CPU计算性能
  - 但是在节约成本的巨大优势上面，CPU性能的退化是可以容忍的
- “大型单元”：允许超大型计算任务，减少任务的碎片化
- 细粒度资源请求
  - 以千分之一的CPU核，和内存、磁盘的字节数为资源请求的最小单元
  - 相比预设资源分配（套餐），可以避免额外的资源开销
- 资源回收
  - 对于可以容忍低质量资源的工作（例如批处理作业），Borg会评估任务将使用的资源，并回收空闲资源
  - 最初的预留值与其资源请求一致，然后300秒之后，会慢慢降低到实际使用率外加一个安全边缘
  - 如果利用率超过资源预留值，预留值会快速增长。
隔离与安全性：
- 安全隔离
  - 使用Linux chroot jail在共享同一台机器的任务之间确保安全性
- 性能隔离
  - 基于cgroup的资源容器，允许详细的资源核算并执行限制，防止任务相互干扰，确保稳定和可预测的性能
  - 使用appclass，尽可能保证延迟敏感服务的资源使用
  - 区分可压缩资源 和 不可压缩资源
    - 可压缩资源（compressiable） - CPU%和Disk IO，可以暂时限流
    - 不可压缩资源（non-compressible） - 内存、磁盘占用，需要清除优先级低的线程
  - 内核的CPU调度器，允许根据每个资源容器的负载状况来动态决定是否要驱逐低优先级任务，同时避免多个高优先级任务在一个cpu上争抢
    - 仍在尝试cpu调度时更好的考虑线程亲和、NUMA亲和等策略
经验教训：
- 负面经验
  - Job作为Task的唯一分组机制的局限性
    - 缺乏将整个多Job服务作为单一实体进行管理，或引用服务相关Job（如Canary与Prod滚动更新）的方式
    - 用户会在Job名称中编入拓扑，并构建外部管理工具来解析这些名称，这导致了滚动更新和作业调整大小等问题的不灵活语义
    - Kubernetes通过使用标签组织其调度单元（Pods），提供了更多灵活性
  - 单个IP地址带来的复杂性
    - 同一台机器上的所有任务共享该机器的单个IP地址和端口空间
    - 导致端口也成为一种资源，在调度时候需要被考虑
    - Kubernetes采用了更友好的方法，每个Pod和服务都获取自己的IP地址，从而简化了这些复杂性。
  - 偏向于高级用户
    - Borg提供了一整套面向“高级用户”的功能，允许他们细致调整程序运行方式
    - 这种API的丰富性使得对于“普通”用户更加困难，并限制了其演变
    - Google构建了自动化工具，对于允许“失败”的应用程序，通过实验来探测适当配置
- 积极经验
  - Allocs是有用的
    - Kubernetes中的Alloc等效物是Pod，它是一个资源包，用于一个或多个容器，总是被调度到同一台机器上并可以共享资源
  - 集群管理不仅是任务管理
    - 尽管Borg的主要角色是管理任务和机器的生命周期，但运行在Borg上的应用程序从许多其他集群服务中受益，包括命名和负载均衡
    - Kubernetes使用服务抽象支持命名和负载均衡，服务有一个名称和一组由标签选择器定义的动态Pods。
  - 自省至关重要
    - 尽管Borg几乎总是“运行良好”，但当出现问题时，找到根本原因可能具有挑战性
    - Borg的重要设计决策之一是向所有用户展示调试信息
    - Kubernetes旨在复制Borg的许多内省技术，例如，它配备了cAdvisor等工具进行资源监控和基于Elasticsearch/Kibana和Fluentd的日志聚合
  - 主控节点是分布式系统的核心
    - Borgmaster最初被设计为一个单体系统，但随着时间的推移，它变得更像是一个内核，位于协作管理用户作业的一系列服务的中心
    - Kubernetes架构更进一步，它有一个核心的API服务器，仅负责处理请求和操纵底层状态对象，集群管理逻辑被构建为小型可组合的微服务，这些服务是这个API服务器的客户端
论文

本文部分内容由ChatGPT4生成

[TL;DR] 论文阅读：Autopilot - 自动化数据中心管理

2023-12-22T23:32:00+08:00

TL;DR
- Autopilot是微软用来自动化运营大规模网络服务的基础架构
- 其设计核心是Device Manager，一个基于Paxos的强一致性分布式状态机，用来保存整个系统的“实际真相”（ground truth），并且根据整个系统的状态确定下一步的行动
- 其它子模块通过与Device Manager通信，在“最终一致性”模型下获取系统信息并执行命令，确保更新可能不是即时的，但最终会在系统中传播
概述：
- 微软运营大规模网络服务，需要可靠的数据中心自动管理
- 为了降低数据中心的运营和资本支出而设计
- 负责自动化软件配置和部署、系统监控，以及执行修复操作来处理软件和硬件的故障
- 微观的策略则交由各个应用程序来确定。例如，确定哪些计算机应运行哪些软件，或者精确地定义和检测需要修复的故障
设计原则：
- 基于大规模“商品级计算机系统”的经济性和不可靠性，Autopilot采用容错和简化设计
- 容错设计：非拜占庭式故障模型，解决数据中心的控制环境问题
  - “非拜占庭式故障模型”假设系统中的错误不是恶意或欺诈性的。在这种模型中，系统的故障被认为是由于一些常规原因，如硬件故障、软件缺陷或网络问题
- 简化设计：
  - 强调简单性和容错性
  - 在构建大型的可靠、可维护系统时，常常选择简单设计而非更高效或看似更优雅但更复杂的解决案。
系统概览：
- Autopilot分为多个组件
- 平衡弱一致性和强一致性之间的抉择
  - 弱一致性：增强可用性
  - 强一致性：简化设计
- Device Manager - 状态和逻辑管理
  - 所有关于系统应处于的“实际真相”（ground truth）状态以及更新这一状态的逻辑，都保存在一个称为 Device Manager 的强一致性状态机中，通常分布在5至10台计算机上
  - 使用 Paxos 算法实现副本间的一致性，同时通过批处理更新以平衡延迟和吞吐量
- Device Manager与“卫星服务”
  - “卫星服务”在发现 Device Manager 状态需要时，惰性地向自身或其客户端的同步信息
  - 如果“卫星服务”发现集群中的故障或不一致，它不会尝试纠正，而是将问题报告给 Device Manager
    - Autopilot会综合这些信息做出下一步决定
  - 当 Device Manager 更新其状态时，会通知“卫星服务”。“卫星服务”也会通过心跳信息尝试拉取最新的状态。简化设计的同时，并且保证最终一致性/正确性。
底层服务：
- 使用稳定的Windows Server操作系统镜像，包含Autopilot配置文件和服务
- 配置服务（Provisioning）包括DHCP和网络引导，不断扫描网络中新接入的计算机
  - 通过Device Manager提供的信息来决定需要运行的操作系统及二进制程序
- 应用部署
  - 定义不同机器类型，存储不同配置文件和应用二进制文件
  - 部署新代码时，以Scale unit为单位更新/回滚各机器类型的配置
自动修复服务
- 使用最小化的故障检测和恢复模型，以节点或交换机为单位，不处理特定进程的错误
  - 只包括Reboot / ReImage / Replace 三种操作
  - Autopilot无需对错误归因，也不需要相关的错误处理逻辑
- 用看门狗进行故障报告，检测特定的属性，并上报给Device Manager
- Device Manager作为一个集中式程序，控制机器的自动修复，并且控制同时进行修复机器的数量
监控服务：
- 记录性能计数器和日志，收集服务形成分布式集合和聚合树
案例研究 - IndexServing：
- 介绍Windows Live Search如何与Autopilot交互，保持高可用性
- 对于需要高可用性和低延迟的面向客户服务的应用程序，需要在基础的 Autopilot 组件之上增加定制的容错层
  - 使用Load balancer和定制的监控服务来探测失效的或者慢速的节点，并且将结论上报到Autopilot
经验与教训：
- 对于关键的配置文件，进行checksum检查是必须的
  - 避免人工失误（例如部署因Debug而临时修改的配置）或者其它意外问题
- 网络是不可靠的
  - TCP/IP的checksum非常弱，所以需要应用层面的额外检查
  - 网络硬件经常翻转数据流中的bit位，导致大量的重试或者未被网络层检测到的数据错误
- 一些节点偶尔会运行的异常慢，但是并不会停止工作。这种问题与“失败停止错误”一样需要被及时检测到
- 节流与负荷削减对于自动化系统非常重要
  - 失效检测模块需要有效的区分节点失效与节点过载的区别
  - 简单的移除节点可能会导致级联式的失效，进而使整个系统失效
论文

本文大（划掉）部分内容由ChatGPT4生成

使用 SPIN/Promela 对多线程 Concurrent FIFO Queue 进行建模与验证

2023-12-17T00:00:00+08:00

引言

并发编程中设计和验证多线程数据结构是一项极大的挑战，即使是实现一个简单的数据结构（见《实现一个无锁消息队列》一文），都需要不少的脑力、讨论与实践才可以尽可能保证其正确性。

本文尝试使用 SPIN/Promela 对多线程环境下的 Concurrent FIFO Queue 的一种实现进行建模与验证。

Concurrent FIFO Queue 的设计

为了保证多线程操作的正确性，我们采用了以下关键设计：

Dummy Head 和 Dummy Tail 节点：引入这两个节点简化了队列操作逻辑，降低并发中的复杂性
Dummy Tail Data 指针作为“锁”：这个方法确保多个线程不会同时操作尾节点，降低了对锁的依赖
利用指针赋值的原子性：通过这种方式，减少了锁的使用，提高了效率

SPIN/Promela 建模中的考虑因素

在使用 SPIN/Promela 建模时，我们面临了几个挑战：

静态内存管理：SPIN/Promela 缺乏动态内存操作，因此我们实现了一个极简的手动管理的静态内存堆栈。
减少状态空间：队列的长度可以是无限的，这也就意味着无限的状态空间。因此，我们将队列的最大长度设为3，以减少状态的穷举空间。
模拟CAS操作：由于缺少CAS指令，我们使用 do 循环和 atomic 块来模拟，同时开启 weak fairness 避免无限循环。（见《在SPIN/Promela中模拟CAS》一文）
LTL表达式的使用：使用 LTL 表达式来穷举检查所有可能的程序状态，包括边缘情况。
- LTL表达式偶尔会有一些”反直觉“的情况出现
- 例如在程序验证路径中，虽然理论上队列大小可以为0~3当中的任意数。但是也存在一种可能，即队列大小可以在2和3之间反复变化。如果我们声明“永远最终一定存在 queue size==1” 的表达式会失败，因为队列大小在这种“人造场景”下永远不会为1。
- 这种情况要求我们非常精确地设计 LTL 表达式
代码与断言的结合：因为 LTL 表达式的表达能力有限，需要结合代码中的 assert 语句来进行更全面的验证

代码示例

下面是我们用于建模和验证 Concurrent FIFO Queue 的 Promela 代码示例：

#define MAX_CAPACITY 3
#define NUM_NODES MAX_CAPACITY + 2
#define EMPTY -1
#define INVALID_PTR -1

#define QUEUE_NOT_FULL (memptr > 0)
#define QUEUE_NOT_EMPTY (memptr < MAX_CAPACITY)
#define QUEUE_IS_EMPTY (memptr == MAX_CAPACITY)
#define QUEUE_IS_FULL (memptr == 0)

#define HEAD 0

typedef QueueNode {
  int nextptr;
  int data;
};

// 1 dummy head + 1 dummy tail + #(data nodes)
QueueNode nodes[NUM_NODES];

// data nodes + dummy tail
int memory[MAX_CAPACITY + 1];
int memptr = MAX_CAPACITY;
int tail;
int queue_size = 0;

bool running = false;

init {
    int i = 0;
    for (i : 0 ..  NUM_NODES - 1) {
        nodes[i].nextptr = INVALID_PTR;
        nodes[i].data = EMPTY;
    }

    for (i : 0 ..  MAX_CAPACITY - 1) {
        memory[i] = i + 2;
    }
    memory[MAX_CAPACITY] = -1;

    nodes[HEAD].nextptr = HEAD + 1;
    tail = HEAD + 1;

    atomic {
      run worker(0);
      run worker(1);
    }
    running = true;
}

inline update_queue_size() {
    d_step {
        int cur = HEAD;
        int size = 0;
        do
            :: nodes[cur].nextptr != INVALID_PTR -> {
                size++;
                assert(cur != INVALID_PTR);
                cur = nodes[cur].nextptr
            }
            :: else -> break;
        od
        assert(nodes[cur].nextptr == INVALID_PTR);
        size--; // remove HEAD
        assert(size >= 0 && size <= MAX_CAPACITY);
        queue_size = size;
    }
}

inline enqueue(workerId) {
    int cur1 = INVALID_PTR;
    atomic {
        if
        :: (memptr - 1 >= 0) -> {
            cur1 = memory[memptr - 1];
            memory[memptr - 1] = -1;
            memptr--;
            assert(nodes[cur1].data == EMPTY);
            assert(nodes[cur1].nextptr == INVALID_PTR);
        }
        :: else -> skip
        fi
    }

    if
    :: cur1 != INVALID_PTR -> {
        do
        :: (true) -> {
            // CAS
            atomic {
                if
                :: (nodes[tail].data == EMPTY) -> {
                    nodes[tail].data = workerId;
                    break
                }
                :: else -> skip;
                fi
            }
            update_queue_size();
        }
        od

        nodes[tail].nextptr = cur1;
        tail = cur1;
    }
    :: else -> skip
    fi
}

inline dequeue(workerId) {
    int cur2 = INVALID_PTR;
    do
    :: (true) -> {
        int nxt2 = nodes[HEAD].nextptr;
        cur2 = INVALID_PTR;
        if
        :: (nxt2 != tail) -> {
            cur2 = nxt2;
            atomic {
                update_queue_size();
                if
                :: (nodes[HEAD].nextptr == nxt2 && nxt2 != tail) -> {
                    nodes[HEAD].nextptr = nodes[cur2].nextptr;
                    nodes[cur2].nextptr = INVALID_PTR;
                    nodes[cur2].data = EMPTY;
                    update_queue_size();
                    break
                }
                :: else -> skip;
                fi
            }
        }
        :: else -> break
        fi
    }
    od

    if
    :: (cur2 != INVALID_PTR) -> {
        d_step {
            assert(nodes[cur2].nextptr == INVALID_PTR);
            assert(nodes[cur2].data == EMPTY);
            assert(memptr + 1 <= MAX_CAPACITY);

            int i;
            for (i : 0 ..  memptr - 1) {
                assert(memory[i] != cur2);
            }
            assert(memory[memptr] == -1);

            memory[memptr] = cur2;
            memptr++;
        }
    }
    :: else -> skip
    fi
}

proctype worker(int workerId) {
end:
    do
    :: (QUEUE_NOT_FULL) -> enqueue(workerId);
    :: (QUEUE_NOT_EMPTY) -> dequeue(workerId);
    od
}

ltl valid_first_node { []( running -> ((nodes[HEAD].nextptr != INVALID_PTR) && (nodes[HEAD].nextptr < NUM_NODES)) ); }
ltl not_always_empty { [](running -> (QUEUE_IS_EMPTY -> <>QUEUE_NOT_EMPTY)); };
ltl not_always_full { [](running -> (QUEUE_IS_FULL -> <>QUEUE_NOT_FULL)); };
ltl size_change_by_1 { [](running -> (
                            (queue_size == 0 U queue_size == 1) ||
                            (queue_size == 1 U (queue_size == 0 || queue_size == 2)) ||
                            (queue_size == 2 U (queue_size == 1 || queue_size == 3)) ||
                            (queue_size == 3 U queue_size == 2))) }

讨论

混合编程的可能性

我们是否可以通过 Promela 与 C/C++ 的混合编程来解决模型中的一些困难？这种方法或许能提供更加灵活的解决方案，但代价又是什么呢？

LTL语句的合理性

在多线程环境下验证数据结构的正确性始终是一项艰巨的任务。对于代码中使用的LTL语句，是否需要继续完善以保证其在更多（甚至所有）场景下的正确性?

对于其他实现的验证

在《实现一个无锁消息队列》一文中，涉及了更多的多线程队列模型，后续会对其进行验证。

本文大（划掉）部分内容由ChatGPT4生成

在SPIN/Promela中模拟CAS（Compare-and-Swap）

2023-12-15T00:00:00+08:00

CAS（Compare-And-Swap）是一种在多线程编程中常用的数据同步方法，它通过比较和交换操作来保证数据的一致性。然而，在SPIN/Promela中没有直接的CAS对应实现。

让我们来看一个例子。考虑以下Promela代码，它模拟了两个工作线程 worker0 和 worker1 使用CAS机制交替修改共享变量 x 的场景：

int x = 0;
bool running = false;

proctype worker0() {
end:
    do
    :: (true) -> {
        atomic {
            if
            :: (x == 0) -> { x = 1; }
            :: else -> skip;
            fi
        }
    }
    od
}

proctype worker1() {
end:
    do
    :: (true) -> {
        atomic {
            if
            :: (x == 1) -> { x = 0; }
            :: else -> skip;
            fi
        }
    }
    od
}

init {
    atomic {
      run worker0()
      run worker1();
    }
    running = true;
}

ltl not_always_0 { [](running -> <>(x == 1)); };

从直观上理解，LTL表达式 not_always_0 应该被满足，因为 worker0 和 worker1 应该会交替执行，从而在未来的某个时刻使 x == 1 成立。

然而，在SPIN的实际运行中，我们可能会遇到一个问题：如果 worker0 在任何点停止执行，worker1 就会陷入死循环，这种情况被称为“饥饿”（starvation）。

为了解决这一问题，我们可以在SPIN中使用 -f 选项来保证弱公平性（weak fairness）。弱公平性意味着，如果一个可执行的动作在无限长的执行序列中有无限次的执行机会，那么它最终必须得到执行。这确保了即使一个动作暂时无法执行，它最终也会有机会执行。

在这个模型中，应用弱公平性可以确保 worker0 和 worker1 最终都有机会交替执行。这使得模型能够模拟现实的多线程CPU执行场景，从而验证了LTL属性 not_always_0 的正确性。

详细命令

spin -a simple-cas.pml
./pan -m10000 -a -f

参考链接
Concise Promela Reference > Executing a Promela system

本文大（划掉）部分内容由ChatGPT4生成

[tl;dr] 论文阅读：Rarest First and Choke Algorithms Are Enough

2023-12-08T00:00:00+08:00

基本概念
- Peer：BitTorrent P2P下载的参与者
- Leecher：“吸血者”，仍在下载过程中的peer
- Seeder：做种者，下载完成后还在继续做种的peer
- Piece：Piece是文件的数据单元。当文件被分享时，它被分割成多个大小相等的片段，称为”pieces”。这些pieces是peer间传输的基本单位
“最稀有优先算法”（Rarest First Algorithm）
- “最稀有优先算法”（Rarest First Algorithm）是BitTorrent协议中的一个关键策略，用于决定哪些数据块（piece）首先被下载和分享。这个算法的核心目标是优化整个网络中数据的分布，确保更快的下载速度和更高的效率。
- 基本原理
  - 数据块的稀有度
    - 在BitTorrent网络中，文件被分割成许多小的数据块。
      - “最稀有优先”算法的目的是优先下载那些网络中数量最少的数据块。
  - 选择下载的块：
    - 当一个peer加入Torrent网络，并开始下载文件时，它首先会从所有连接的peer那里获取有关哪些数据块是稀有的信息。
      - 然后，它优先请求下载那些最稀有的数据块。
  - 动态调整：
    - 随着下载的进行，每个peer会不断更新和重新评估网络中每个数据块的稀有度，并相应地调整其下载优先级。
  - 算法的重要性
    - 提高效率：通过优先下载最稀有的块，这个算法帮助加快了文件的整体下载速度。一旦最稀有的块被更多peer获取，它们就更容易被进一步分享和分发。
    - 防止瓶颈：如果没有这个算法，某些数据块可能会变得很难获得，导致下载过程在接近完成时放慢，这被称为“最后一块问题”（Last Piece Problem）。
    - 促进平等分享：这种方法鼓励peer分享它们拥有的稀有块，从而提高了整个网络中的合作和资源共享。
- 实际应用
  - 在BitTorrent网络中，这个算法对于确保高效的数据分发至关重要。它不仅提高了单个用户的下载速度，而且还提高了整个网络的效率，确保了资源在用户之间的均衡分配。通过这种方式，BitTorrent网络能够有效地避免瓶颈和提高数据的可用性，即使在面对大量用户的情况下也是如此。
- 结论
  - 最稀有优先算法是BitTorrent网络高效运行的关键组成部分。它通过智能地选择下载和分享网络中最稀有的数据块，提高了资源的整体分布和可用性，确保了快速、平衡的文件共享。
“窒息算法”（Choking Algorithm）
- “窒息算法”（Choking Algorithm）是BitTorrent协议中的一个关键组成部分，用于管理多个peer之间的数据传输。这个算法帮助优化带宽的使用，确保网络中的资源被高效合理地分配。其核心目的是促进peer间的合作和数据的快速分发。
- 窒息算法的基本原理
  - 选择和窒息（Choking and Unchoking）
    - 在BitTorrent网络中，每个peer同时维护着一组“窒息”（choked）和“未窒息”（unchoked）的peer名单。
      - 被“窒息”的peer无法从窒息方接收文件数据，而“未窒息”的peer可以进行数据交换。
      - 这种状态是动态的，peer根据算法定期更新它们的窒息/未窒息peer名单。
  - 利益驱动的决策
    - 算法核心是“利益驱动”（tit-for-tat）策略，即peer更倾向于向那些能给它提供数据的peer提供数据。
      - 这种方法鼓励peer分享数据，因为分享越多，获得数据的机会也越大。
  - 优化器：
    - 除了基于交换数据的量来决定窒息状态外，大多数BitTorrent客户端还实现了一个“优化器”（Optimizer），用于探索新的peer。
      - 通常，这是通过定期“未窒息”一个随机选择的peer来实现的，即使它在过去的数据交换中表现不佳或没有数据交换。
  - 窒息周期：
    - peer定期评估其连接，并根据从其他peer接收到的数据速率来更新其窒息/未窒息名单
- 窒息算法的重要性
  - 合作促进：通过奖励那些分享资源的peer，窒息算法鼓励合作，提高了网络中的资源共享效率。
  - 防止自私行为：算法减少了自私peer（只下载不上传的）的优势，因为这些peer不太可能被其他peer“未窒息”。
  - 网络拥塞控制：它帮助控制网络拥塞，通过限制peer的连接数量和数据传输，优化带宽使用。
- 结论
  - 窒息算法是BitTorrent协议高效性的关键，它通过一种简单但有效的方式来鼓励数据共享和合作，保证了整个网络的健康和高效运行。通过这种动态的窒息/未窒息机制，BitTorrent网络能够有效地管理带宽和连接，确保资源在网络中的快速且公平的分配。
为什么说“已经足够了”
- 因为这是一门实验科学
- “最稀有优先算法”（Rarest First Algorithm）
  - 种子的熵
    - 描述了种子中各个数据块在所有peer间的分布情况
    - 高熵意味着数据块在所有peer中分布得很均匀，peer之间更有可能拥有彼此尚未下载的块
    - 高熵的种子通常意味着更高的数据交换效率
  - 理想熵（Ideal Entrophy）
    - 是指网络中的数据块（pieces）在所有leechers之间均匀分布
    - 每个leechers都持有一些其他leechers需要的数据块，从而确保了网络中的每个leechers都对其他leechers感兴趣。
  - 冷启动（Transient State）
    - 当种子刚开始传播时的动态，优先传播稀有块，提高下载效率
    - Rarest First Algorithm解决了种子的冷启动问题，确保了最不常见的块被优先传播，提高了整个网络的下载效率
  - 稳定态（Steady State）
    - 网络中的大部分块已经被比较均匀地传播。最稀有优先算法在这一阶段继续确保数据块的多样性，从而减少了任何特定块成为瓶颈的可能性
    - 算法鼓励peer间的有效合作，因为每个peer都可能持有其他peer需要的稀有块
  - “最后一块”问题（Last Pieces Problem）
    - 下载接近完成时，某些块变得非常稀有，从而延缓整个下载过程
    - 算法确保即使在下载的后期，所有参与的peer仍然有激励去交换彼此之间缺少的块
    - 避免了下载末期的稀有块瓶颈
- “窒息算法”（Choking Algorithm）
  - “对等原则”（Tit-for-tat Fairness）
    - 如果A从B下载的数据少于B从A下载的数据，A会拒绝继续与B分享数据
    - 用来保证公平性，杜绝free rider
    - 在动态或非对称网络环境中可能效率低下
    - 会导致网络空闲资源的浪费
  - 旧版窒息算法
    - 旧版窒息算法只考虑了peer之间的下载速度，而不是它们的上传贡献
      - 少量上传速度快的leecher会占据大量带宽，不利于种子熵的增加
      - 下载速度快的free riders得到了比实际贡献更多的回报
    - 基于更宏观的性能指标（如整体上传贡献）的策略能够更好地适应这些变化
  - 新版窒息算法
    - 上传速度快的leecher一定比上传速度慢的leecher获得更多的下载速度，保证了近似的对等原则
    - 对于seed（做种者）而言，应该对每个leecher提供相同的服务时间。保证了网络中的公平性和效率
    - 因为文件块可以被更平均的分配给了其它peer，在冷启动时的弹性更强，对于free riders的抵抗性也更强
Link
- Rarest First and Choke Algorithms Are Enough

本文部分内容由ChatGPT4生成

A2B Game Solutions

2021-11-18T00:00:00+08:00

A2B is a “zach-like” programming game, which let you to use a very simple “programming language” to solve different problems for strings.

Personally, I highly recommand this game along with “Shenzhen IO” and “Factorio” as an beginner tutorial for anyone who wants to be a software engineer.

Spoiler Alert

** The following article includes huge spoilers for A=B Game. **

If you have a different solution or a better solution. Feel free to share it with a comment.

Cpt1. A=B

1-1. A to B

a=b

1-2. Uppercase

a=A
b=B
c=C

1-3. Singleton

aa=a
bb=b
cc=c

1-4. Singleton 2

aaa=aa
aa=

For all substring which has more than n ‘a’s, replace them with n-1 ‘a’s.
For all “aa”s, remove them.
For all singleton “a”s, keep it as-is.

1-5. Sort

ba=ab
ca=ac
cb=bc

Bubble sort.

1-6. Compare

ba=ab
ab=
aa=a
bb=b

Firstly, sort the string. Make it to “aaaa…aabbb…bb” pattern.
If there’s an “ab” substring in the middle, remove it.
After that, there will be only “a” or “b” in the string.
Remove the redundant characters to make the answer.

Cpt2. Keyword

2-1. Hello World

=(return)helloworld

2-2. AAA

aaa=(return)true
b=
c=
=(return)false

2-3. Exactly Three

b=a
c=a
aaaa=(return)false
aaa=(return)true
=(return)false

2-4. Remainder

b=a
c=a
aaa=
aa=(return)2
a=(return)1
=(return)0

2-5. Odd

ba=ab
ca=ac
cb=bc
aaa=a
bbb=b
ccc=c
aa=(return)false
bb=(return)false
cc=(return)false
=(return)true

Sort the string to “aa…aabbb…bbbcc…cc” pattern.
Remove all “aaa”, “bbb”, “ccc” substring, this will keep the parity of each characters.
If theres “aa”, “bb” or “cc” in the remaining string, it means that there’s at least one type of character has even number of appearances.

2-6. The Only

aaa=aa
bbb=bb
ccc=cc
aa=X
bb=X
cc=X
a=Y
b=Y
c=Y
X=
YY=(return)false
Y=(return)true
=(return)false

Because for substring like “aaa..aa”, all “a”s has at least 1 neighbour which is same to itself.
It means we can safely replace those substrings with a delimeter, marked as “X”.
Check if the remaining string has exactly 1 character which is not “X”.

2-7. Ascend

Solution1 (9 Lines)

ba=ab
cb=bc
ca=ac
b=xy
yx=xy
ax=
yc=
xc=(return)true
=(return)false

Sort string to parttern “aa…bb..cc”.
Split every character “b” to “xy”, then sort the string to “aaa…xx…yy..cc”.
Remove all the occurrences of “ax” and “yc”.
If:
- there’re remaining “a”s means count(a) > count(b)
- there’re remaining “x”s means count(b) > count(a)
- there’re remaining “y”s means count(b) > count(c)
- there’re remaining “c”s means count(b) > count(b)
Only if there’re any “xc”s in the remaining string, we’ll return true.
Otherwise, return false.

Solution2 (8 Lines)

ba=ab
ca=ac
bc=cb
cb=x
cx=xc
ax=
xc=(return)true
=(return)false

Sort string to pattern “aaa…cccc…bb”.
For every occurrence of “cb”, replace it with “x”. If there’re n “x”s, means there’re n “b”s and n “c”s.
Move every “x” to the front of “c”s.
Eliminate every “a” with adjacent “x”.
If:
- there’re remaining “a”s means count(a) > count(b)
- there’re remaining “x”s means count(b) > count(a)
- there’s no remaining “c”s means count(b) > count(a)
We match the pattern “xc” as a signal for returning “true”.
Otherwise, return “false”.

2-8. Most

ba=ab
ca=ac
cb=bc
b=xy
yx=xy
ax=
yc=
ac=
a=(return)a
y=(return)b
c=(return)c

Similar idea from 2-7.
Sort then split, make the string like “aaa…xxx..yyy…ccc”.
It’s easy to know that count(x) == count(y) == count(b).
Eliminate all occurances of “ax”s and “yc”s.
It means:
- count(remaining a) = count(a) - count(b) if there’re remaining “a”s
- count(remaining x) = count(b) - count(a) if there’re remaining “x”s
- count(remaining y) = count(b) - count(c) if there’re remaining “y”s
- count(remaining c) = count(c) - count(b) if there’re remaining “c”s
If there’re only “x”s and “y”s remain, it means “b” has the largests count
If there’re only “a”s or “ay”s remain, it means count(a) > count(b) >= count(c)
If there’re only “c”s or “xc”s remain, it means count(c) > count(b) >= count(a)
If there’re only “a”s and “c”s remain, we will eliminate all “ac”s, the type of character left is the final answer.

2-9. Least

Solution1 (11 Lines)

ba=ab
ca=ac
cb=bc
b=xy
yx=xy
ax=
yc=
xy=
ac=(return)b
x=(return)a
y=(return)c

Similar idea from 2-8

Solution2 (9 Lines)

ba=ab
ca=ac
cb=bc
ab=x
xb=bx
xc=
bc=(return)a
x=(return)c
ac=(return)b

Similar idea from 2-7, solution2

Cpt3. Start and End

3-1. Remove

(start)a=
(end)a=

3-2. Spin

(start)b=(end)b
(start)c=(end)c

3-3. A to B 2

Solution1 (4 Lines)

(end)a=(start)A
(start)A=(end)b
(start)a=(end)A
(end)A=(start)b

Solution2 (5 Lines)

(end)a=X
aX=XX
(start)a=X
Xa=XX
X=b

3-4. Swap

(start)a=(end)XXXXXXXXa
bX=(start)b
X=

Move all starting “a”s to the end of the string, and make it “XXXXXXXXa”. e.g. aacbbb -> cbbbXXXXXXXXaXXXXXXXXa.
If there’re “b”s at the end of the original string, it will definitely followed with “X”. So we move “bX” to the beginning of the string.
Remove all redundant “X”s.

3-5. Match

(end)aXaY=(return)true
(end)bXbY=(return)true
(end)cXcY=(return)true
(start)a=(end)XaY
(start)b=(end)XbY
(start)c=(end)XcY
=(return)false

Say the original string is “uv…w” (“u”, “v” and “w” could be arbitrary characters among “a”, “b” and “c”).
Firstly move the starting “u” to the end of the string, added with “X” and “Y”, i.e. uv...w -> v...wXuY.
If “wXuY” is “aXaY”, “bXbY” or “cXcY”, return true. Otherwise, return false.

3-6. Most 2

Solution1 (12 Lines)

ba=ab
cb=bc
ca=ac
ab=(start)X
Xa=aa
X=b
bc=(start)Y
Yb=bb
Y=c
ac=(start)Z
Za=aa
Z=c

Solution2 (11 Lines)

ba=ab
cb=bc
ca=ac
ab=(start)X
Xa=aa
X=b
bc=(start)Y
Yc=cc
ac=(start)Y
Ya=aa
Y=b

3-7. Palindrome

Solution1 (10 Lines)

XaX=(return)false
XbX=(return)false
XcX=(return)false
(end)aXa=
(end)bXb=
(end)cXc=
(start)a=(end)Xa
(start)b=(end)Xb
(start)c=(end)Xc
=(return)true

Solution2 (8 Lines)

(end)aXaX=
(end)bXbX=
(end)cXcX=
(start)a=(end)XaX
(start)b=(end)XbX
(start)c=(end)XcX
XX=(return)false
=(return)true

Cpt4. Once Upon A Time

4-1. Hello 2

(once)=(start)hello

4-2. Remove 2

(once)a=
(once)a=
(once)a=

4-3. Cut

(once)=(start)XXX
Xa=
Xb=
Xc=

4-4. Remove 3

(once)=(end)XXX
bX=Xb
cX=Xc
aX=
X=

4-5. Reverse

(once)=(start)X
Xa=(end)Ya
Xb=(end)Yb
Xc=(end)Yc
aY=(start)a
bY=(start)b
cY=(start)c

4-6. Reverse 2

(once)=(end)XXXXXXXXXX
aX=(end)a
bX=(end)b
cX=(end)c
X=

4-7. Cut 2

(once)=(start)XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXDXX
Xa=(end)a
Xb=(end)b
Xc=(end)c
Da=
Db=
Dc=

“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXDXX” = 58 * “X” + “D” + 2 * “X”.
60 “X”s is the LCM of all possible length of the remaing string (2, 3, 4, 5, 6)

4-8. Clone

Solution1 (13 Lines)

(once)=(start)XXX
Ya=(end)a
Yb=(end)b
Yc=(end)c
XXXa=YaaXX
XXXb=YbbXX
XXXc=YccXX
XXa=YaaX
XXb=YbbX
XXc=YccX
Xa=Yaa
Xb=Ybb
Xc=Ycc

Solution2 (16 Lines)

(once)=(start)XXX
Xa=(end)aA
Xb=(end)bB
Xc=(end)cC
Aa=aA
Ab=bA
Ac=cA
Ba=aB
Bb=bB
Bc=cB
Cc=cC
Cb=bC
Ca=aC
(end)A=(start)a
(end)B=(start)b
(end)C=(start)c

Solution3 (10 Lines)

(once)=(start)X
A=(end)a
B=(end)b
C=(end)c
Xa=AaY
Xb=BbY
Xc=CcY
(once)Y=X
(once)Y=X
Y=

4-9. A to B 3

(once)=(start)X
Xa=bX
Xb=aX
Xc=cX
X=

4-10. Half

Solution1 (9 Lines)

(once)=(start)X
Xa=Y
Xb=Y
Xc=Y
Ya=aX
Yb=bX
Yc=cX
Y=
X=

“X” is the operator to remove the character.
“Y” is the operator to keep current character and remove the next character.

Solution2 (8 Lines)

(once)=(start)XX
XXa=X
XXb=X
XXc=X
Xa=aXX
Xb=bXX
Xc=cXX
X=

“XX” is the operator to remove the character.
“X” is the operator to keep current character and remove the next character.
This could help us to save 1 line of code.

4-11. Clone 2

(once)=X
(once)=(end)Z
XZ=
AY=(end)a
BY=(end)b
CY=(end)c
Xa=AYaX
Xb=BYbX
Xc=CYcX

4-12. To B or not to B

(once)b=bX
(once)=Y
X=(start)Y
YYa=bYY
Yb=bY
Yc=cY
Ya=cY
Y=

4-13. Center

(once)=(end)Y
(start)aY=(return)a
(start)bY=(return)b
(start)cY=(return)c
aYX=Y
bYX=Y
cYX=Y
(start)a=(end)X
(start)b=(end)X
(start)c=(end)X

4-14. Center 2

(once)=Lx
(once)=(end)R
LxaR=
LxbR=
LxcR=
Lxa=aLY
Lxb=bLY
Lxc=cLY
Y=(end)x
aRx=xRa
bRx=xRb
cRx=xRc
ax=xa
bx=xb
cx=xc

4-15. Expansion

(once)=YYYYYYXXXXXYYYYYXXXXYYYYXXXYYYXXYYXY
(once)=(end)E
Xa=aa
Xb=bb
Xc=cc
Ya=(end)a
Yb=(end)b
Yc=(end)c
XE=E
YE=E
E=

4-16. Merge

Solution1 (10 Lines)

(once),=XXXXXXXXXXXZ
YXX=YX
YX=
Z=(start)Y
Ya=(end)a
Yb=(end)b
Yc=(end)c
Xa=(end)aZ
Xb=(end)bZ
Xc=(end)cZ

Solution2 (9 Lines)

(once)=(start)X
(start)Xa=(end)a
(start)Xb=(end)b
(start)Xc=(end)c
Xa=(start)XaX
Xb=(start)XbX
Xc=(start)XcX
X,=
,=,X

Cpt5. Math

5-1. Count

Solution1 (11 Lines)

(once)=(end)XYXXYXXXYXXXXYXXXXXYXXXXXXY
0X=0
0Y=
1XY=(start)a
1XXY=(start)aa
1XXXY=(start)aaaa
1XXXXY=(start)aaaaaaaa
1XXXXXY=(start)aaaaaaaaaaaaaaaa
1XXXXXXY=(start)aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aX=a
Y=

Solution2 (8 Lines)

(once)=(end)XYXXYXXXXYXXXXXXXXYXXXXXXXXXXXXXXXXYXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXY
0X=0
0Y=
1X=AX1
1Y=
AX=(start)a
X=
Y=

Solution3 (7 Lines)

(once)=(end)XYXXYXXXXYXXXXXXXXYXXXXXXXXXXXXXXXXYXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXY
0X=0
0Y=
1X=aX1
1Y=
aX=(start)a
Y=

Solution4 (5 Lines)

(once)=X
X1=(start)aX
X0=(start)X
Xa=aaX
X=

Solution5 (11 Lines, no keyword)

0=$X$
1=$Y$
$$=
YXXXXX$=XXXXXX$aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
YXXXX$=XXXXX$aaaaaaaaaaaaaaaa
YXXX$=XXXX$aaaaaaaa
YXX$=XXX$aaaa
YX$=XX$aa
Y$=X$a
$X=$
$=

5-2. A + 1

(once)=(end)X
0X=1
1X=X0
X=1

5-3. A + B

Solution 1 (14 lines)

Not a good solution

(once)+=x+x+x+x+x+x+x+x+x+z
(start)y=(end)y
(end)0y=
(end)1y=(start)1
(end)y=
0x+=(start)y|
1x+=(start)y1|
x+=(start)y|
||z=|z0
|1|z=|z1
|11|z=1|z0
|111|z=1|z1
|z=
(start)0=

Solution 2 (8 lines)

+1 = |x+
+0 = |+
x| = |xx
| = 
1x = x0
0x = 1
x = 1
+ =

5-4. A - B

Solution 1 (18 lines)

Not a good solution, too

(once)-=x-x-x-x-x-x-x-x-x-z
(start)y=(end)y
(end)0y=
(end)1y=(start)G
(end)y=
0x-=(start)y|
1x-=(start)y1|
x-=(start)y|
||z=|z0
1G=G1
G1=
|1|z=|z1
|G|z=G|z1
|G1|z=|z0
|GG|z=G|z0
|z=
|=
(start)0=

Solution 2 (8 lines)

-1 = |x-
-0 = |-
x| = |xx
| = 
1x = 0
0x = x1
- = 
(start)0 =

Solution 3 (11 lines, no keyword)

-1 = |x-
-0 = |-
x| = |xx
| = 
1x = 0
0x = x1
- = yyyyyyy
0y = y0
1y = y1
y0 = 
y =

5-5. A * B

No solution yet

5-6. A / B

No solution yet

Cpt6. Aftermath

6-1. Hello Again

c=a
b=a
aa=a
a=helloworld

6-2. Palinedrome 2

Solution1 (32 Lines)

Not a good solution

c=^C$
b=^B$
aa=^A$^A$
$a=$^A$
a^=^A$^
$^=
XA=AX
XB=BX
XC=CX
YA=AY
YB=BY
YC=CY
ZA=AZ
ZB=BZ
ZC=CZ
AX$=$
BY$=$
CZ$=$
^A=^X
^B=^Y
^C=^Z
^$=true
^X$=true
^Y$=true
^Z$=true
X$=false
Y$=false
Z$=false
X=
Y=
Z=
^=

Solution2 (21 Lines)

c=^C$
b=^B$
aa=^AA$
$a=$^A$
a^=^A$^
$^=
XA=AX
XB=BX
XC=CX
AXXX$=$
BXXXXX$=$
CXXXXXXX$=$
^A$=true
^B$=true
^C$=true
^A=^XXX
^B=^XXXXX
^C=^XXXXXXX
^$=true
^XX=^X
^X$=false

6-3. To B or not to B 2

Solution 1 (14 Lines)

Not a good solution

a=^A$
c^=^c
$c=c$
b^=XbY
$b=XbY
AX=Xb
cX=Xc
YA=bY
Yc=cY
^=
$=
X=
Y=
A=c

Solution 2 (13 Lines)

a=^AAAAAAAc$
c^=^c
$c=c$
b^=^XbX
$b=XbX$

XAAAAAAAc=bX
AAAAAAAcX=Xb
^=
$=
Xc=cAX
cX=XAcA
X=
A=

Appendix

Proof of Turing Completeness Explained

Ref

Implement Your Own A2B Language

Wizmann/a2b-lang

浅淡TCP BBR

2021-08-17T00:00:00+08:00

背景

在一对跨地域的机器（美国<->香港），使用TCP（Cubic拥塞控制算法）通信throughput最高2MB/s，丢包率0.02%。使用UDP通信throughput最高能达到140MB/s。

这是一个非常典型的长肥管道（LFN），并且丢包率比较高。尝试使用BBR算法后，throughput可达50MB/s+（Windows系统，通信协议使用用户态MsQuic）。

Loss-based Congestion Control Algorithm

Reno和Cubic是比较经典的，用于TCP的拥塞控制算法。这一类算法使用的是基于丢包反馈的思想，即一旦产生了丢包，就认为链路上产生了拥塞。先将拥塞窗口减半，再进入快速恢复模式。

在快速恢复完成后中，就又会重新进入拥塞避免阶段。

Reno当收到一个ACK包时，会将拥塞窗口增大一个MSS，窗口大小线性增长。而Cubic使用的是一个基于上次拥塞事件产生时间的三次函数，所以拥塞窗口能更快速的恢复到拥塞事件发生之前的大小。

但无论是Reno还是Cubic，在遭遇高丢包率的时候，其拥塞控制窗口的大小会一直处于一个非常小的状态。

在RTT较大时，拥塞窗口的大小增长速度更加缓慢，使得带宽利用率长时间维持在一个较低的状态。

下图为Cubic在有丢包（0.002%, 0.02%, 0.2%, 1%, 2%），高延时（200ms RTT）的网络条件下throughput数据。

BBR - Congestion-based Congestion Control

不同于Reno和Cubic，BBR并没有使用“丢包”做为拥塞产生的信号，而是构建了一个反馈系统，通过时延的变化来确定链路上是否发生了拥塞。

拥塞产生的三个阶段

App Limited 应用限制阶段
在此阶段，数据传输速率由用户程序决定。用户程序并没有利用所有的带宽，RTT维持稳定
Bandwidth Limited 带宽限制阶段
在此阶段，数据传输速率由链路带宽所决定，有效吞吐量等于链路带宽。但由于链路缓存的存在，发送端的发送速率可以略大于链路带宽。此时数据开始在链路缓存上堆积，RTT增加
Buffer Limited 缓冲区限制阶段
当链路缓存无法容纳所有的数据包时，就会产生丢包

Loss-based拥塞控制算法会在阶段3的时候产生“拥塞”信号，但是此时大概率为时已晚。因为链路缓存堆积的数据已经开始影响RTT，并且各个节点之间的缓存大小差异，还会导致短时间内的持续丢包，使得拥塞窗口大小急剧减小。

而BBR会将拥塞控制在阶段1和阶段2的交界处，这样可以最大化利用带宽，并且使得链路时延最小。

确定拥塞窗口的大小

从理论上分析，要使一条连接同时保持最高throughput和最小的延迟，那么其发送速率一定等于网络带宽。此时，在途的数据大小BDP = BtlBw × RTprop，就可以用满链路的带宽而不产生拥塞。

BDP意为“带宽时延乘积”。而BtlBw意为“瓶颈带宽”，即为整条链路中，带宽最小的部分。RTprop意为“链路固有传输延迟”。

RTT（往返时延）与RTprop（链路固有传输延迟）的区别是：RTT包括了收发两端应用层的时延，而RTprop只包含网络传播的时延

不凑巧的是，在通信中我们几乎无法直接确定BtlBw和RTprop。BBR建立了一个模型来对其进行估计。公式如下：

η代表的是网络队列的抖动、接收方ACK时延等等。

但是，时延与带宽无法同时探测。因为探测时延时，我们必然要减慢发包速度，排空队列避免拥塞；而探测带宽时，我们需要尽量占满带宽，以检测ACK速率是否发生变化。所以时延与带宽的探测需要交替进行。

ProbeRTT - 时延探测

BBR每10秒钟会进入时延探测状态。在此状态下，BBR会限制拥塞窗口的大小到4个MSS（为什么？）。当收到ACK包后，会更新MinRTT的取样值。

ProbeBW - 带宽探测

BBR大部分时间都会处于ProbeBW状态。

BBR通过计算包的发送时间与收到ACK时间的差来确定带宽，使用“送达速度”来拟合带宽。

同时，BBR会采用gain cycle来随机微调（+25%, -25%, 不变）发送速率，以实时检测链路上带宽的变化。（图中的绿线看起来像心电图的部分）

性能比较

这里是Cubic与BBR在有丢包（0.002%, 0.02%, 0.2%, 1%, 2%），高延时（200ms RTT）的网络条件下的throughput对比。

杂项

在Linux系统下，可以使用tc命令模拟不同的网络状态。

例如100ms延迟（RTT=2*延迟），1%丢包率：

sudo tc qdisc add dev lo root handle 1:0 netem delay 100msec loss 1%

在Windows下可以使用Clumsy进行模拟，但是有怀疑其会严重影响网络性能，效果有待进一步测试。

在Linux系统下，可以使用以下命令替换系统congestion control算法。

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

References

论文阅读-WiscKey：SSD友好的KV分离存储引擎

2021-08-15T00:00:00+08:00

背景

基于LSM-Tree的存储引擎

Log-Structed Merge-Tree (a.k.a. LSM-Tree)是当下常用的一种基于磁盘的存储引擎。与Hash索引和B-Tree同为数据库核心的数据结构。

LSM-Tree的优势在于：

无需将所有的Key索引在内存中。可以通过分级查找的方式，查询到特定KV在磁盘中的偏移量
数据写入与合并使用顺序追加写，最大程度的利用磁盘的顺序写性能
对于数据写入，会使用batch方式写入磁盘
支持范围查询

LSM-Tree的劣势在于：

读放大与写放大
无法对单条数据加锁（事务支持）

现在常用的LevelDB和RocksDB，都是基于LSM-Tree的存储引擎。

WiscKey主要解决的问题

LSM-Tree在性能上面的瓶颈主要在于读写的放大。简单说来，假设你的磁盘最大带宽为4GB/s，读写放大倍数为10，那么在应用层的有效吞吐量（Goodput）最多只能达到400MB/s。并且，对于一些大数据集，读写放大的值有可能会非常大（大于100）。

那么是什么原因导致的读写放大呢？我们下面分开讨论。

读放大

我们重温一下LSM-Tree的查询机制：

首先在mutable memtable中进行查找
然后在immutable memtable中进行查找
最后在不同的LSM-Tree层级中的SST file中进行查找

对于1和2，都是内存操作，其耗时与读取磁盘相比可以忽略不计。
对于3，SST file文件的查找会先使用二分查找定位特定KV位于该层的哪一个SST文件中。

如果特定的KV不存在于此SST文件中，会被常驻内存的bloom filter过滤掉，不会真正的读取文件。（大概率，bloom filter的原理了解一下）

如果特定的KV在此SST文件中，会通过index block进行二分查找，确定KV位于哪个block。然后这个block会被从磁盘上读取到内存进行解压，最后通过二分+遍历找到对应的KV。

论文里对于读放大的计算方法有点夸大了。对于RocksDB来说，一般情况下index block和bloom filter都是常驻内存的。除非是内存非常紧张的场景，否则并不会产生论文中如此夸张的磁盘读放大的。

所以读放大主要因为读取一个KV，需要读取+解压整个block。当KV大小远小于block size的时候，问题会更加严重。

写放大

我们再重温一个LSM-Tree的写入机制：
1. 首先写入mutable memtable
2. mutable memtable后续会被sealed，成为immutable memtable
3. immutable memtable会被flush到磁盘，成为L0
4. L0中的数据会在后台，逐层向下合并，直到合并到最底层

层次数据逐层向下合并的过程中，必然会产生写放大。（具体原理这里不展开了）

写放大值可以使用以下方法估算。已知options.max_bytes_for_level_multiplier代表每一层大小的倍数k，并且假设L0与L1的大小相等，总共有N层。那么写放大约为(N - 1) * k + 1。

正文

入活了入活了！

WiscKey的设计目标

降低写放大
降低读放大
对SSD进行优化
提供LSM-Tree兼容的API
针对现实场景的KV size

WiscKey的设计思路——KV分离

在一般的场景中，在一对KV中，Key的大小远比Value的要小。如果我们在LSM-Tree中只保留Key，那么对于一次读写，我们所要处理的数据就会少很多，从而降低了读写放大。

对于Value，我们会将其存储在另外一个数据结构vLog中。每一次查询，会在LSM-Tree中记录其在vLog中的<offset, length> 。这样一来，读取Value的操作也只有一次磁盘访问，并且不会产生写放大。

这里有一个疑问，如果按论文里面的设计，vLog里面的数据是不会打包的block进行压缩的，必然会损失capacity。如果打包压缩了，那么读放大并没有显著优化。又如果value size ≈ block size，那么其实在读放大上面的优化也就比较微弱了。

WiscKey的设计挑战

并发范围查找

因为使用了KV分离的存储方式，所以范围查找（range query）对于value就会退化成很多次随机读取。

但是由于SSD的并发读取特性，WiscKey会将所需要读取的value的<offset, length>放到一个队列中，多线程并发读取所需要的value。

如图所示，对于较大的value size，顺序读与并发读的throughput基本保持一致。

但是多线程并发读会消耗更多的CPU。

不过对于一个存储系统来说，CPU大概是最不重要的资源了吧（见仁见智咯）

垃圾回收

对于重复写入的KV，LSM-Tree会通过层次合并来将旧值换出。而WiscKey会使用垃圾回收机制来将旧值换出。

vLog可以视作一个循环数组，head指针表示数据的开头（较新的数据），tail指针表示数据的结尾（较旧的数据）。在head和tail指针之外的空间都视作free space。

当空闲数据小于一定阈值之后，会触发GC。WiscKey会从tail依次读出一部分旧数据（batch read），查询LSM-Tree，如果这条数据已经被覆盖或删除，那么就丢弃此数据；否则从head指针处写入此条数据。

为了保证在GC过程中的crash不产生数据的丢失，GC的流程为：

将tail处的KV写入到head处，并调用fsync()将其持久化
同步的将KV的新位置，和head/tail指针的最新位置写入LSM-Tree

由于我们使用了LSM-Tree的WAL，可以保证所有在LSM-Tree里的数据都是可用的。

崩溃一致性（Crash Consistency）

在垃圾回收一节中，我们其实已经遇到了一致性的问题。其根本原因，在于LSM-Tree和vLog是两个不同的模块，在其间保持一致性必然是困难的。

WiscKey使用了现代文件系统（ext4，btrfs和xfs）的一个有趣特性，即对于一个（将要）写入文件的数据流，文件系统会保证这个数据流的一个前缀（或者整个数据流）成功写入文件。

WiscKey的优化

vLog写入Buffer

众所周知，磁盘的同步写入必然会带来一些overhead。对于小数据来说，这在性能上会产生严重的损耗。

这里的优化类似于将vLog也添加一个memory table，所有写入vLog的数据都先写入这个memory table，然后依次flush到磁盘上。

这样的优势在于将写入batch化，可以减少overhead，提升性能。劣势在于，在系统崩溃时，可能会丢失部分数据。但丢失数据时，仍能抱证上文提到的崩溃一致性。

优化LSM-Tree WAL

LSM-Tree的WAL虽然保证了写入的数据的持久性，但是不可避免的，它也会消耗磁盘的一部分带宽。

关闭WAL，意味着LSM-Tree memtable在进程重启时一定会丢失数据。不过我们可以利用vLog重建LSM-Tree（的memtable部分）。

由于vLog之中已经包括了所有的KV对，所以在WiscKey重启时，我们可以从head指针处扫描vLog的数据，由于崩溃一致性的保证，当指针扫描到已经存在于LSM-Tree的数据时，可以认为LSM-Tree已经重建成功。

文件系统的优化

WiscKey使用posix_fadvice()向OS层预声明接下来vLog的操作类型以适应不同场景的磁盘访问模式。使用fallocate()，通过”hole-punching”功能进行GC，以减少数据的移动。

WiscKey的性能

论文的最后给出了一系列数字。由于WiscKey的读写放大很小，所以在value size比较大的场景下（>= 1KB），性能远优于传统LSM-Tree。同时，磁盘空间的使用也更友好。

这里有一个疑问，论文里做microbenchmark的时候，对于LevelDB和RocksDB，是不是还开着压缩。。。

后记

WiscKey应该是“LSM-Tree + KV分离”思路的比较早期的论文，其中仍有很多不明确的细节。但是整体思路是可行的。

PingCAP的Titan是一个基于WiscKey思想的RocksDB KV分离存储引擎。后续可以参考其实现再了解更多的实现思路与细节。

我到底从UW-CSE341学到了什么

2020-12-29T00:00:00+08:00

TL;DR 什么也没学到

课程首页

Coursera-课程-A, B, C

介绍当中说，本课程主要内容是FP，并且顺道讨论一下程序语言的设计。

UW官方上面的课程只有Slides和assignments，video不提供。Coursera有video，但是版本比较老，是2013年的。下面的讨论都是基于au20的新版本。

简单来说，前半学期（hw1-hw4)是关于OCaml，一种静态类型的FP。后半学期(hw5-hw7)是Racket，一种动态语言FP。课程里面80%+（的难度）都在于新的FP编程语言，只包含少数PL的内容。例如HW4中，需要实践一个简单粗暴的tokenizer/parser；HW6实现了一个虚假的编程语言MUPL，这个实现并不需要你解析代码，而是手写解析好的语法树，在上面实现求值、闭包、递归等。

调试与debug也是一个非常蛋疼的问题，尤其是Racket写闭包的时候。。。

学习建议：

OCaml的部分比较简单，7天一个小长假就可以搞定。做为平时的娱乐调剂也可以，周期不会超过一个月。
如果不想使用OCaml，可以尝试F#。因为都是一个流派的，语法接近。使用VS还可以有实时的提示。
Racket的部分难度较大，主要是与平时所使用的语言差别较大。没啥好办法，只能多打log。
HW7难度不高，但是提供的代码里面有一个在构造函数里面Call虚函数的迷惑操作。
多写测试。

Repo地址：https://github.com/Wizmann/UW-CSE341-au20

仅供参考。

感谢华大（

Introduction to Ceph

2020-11-29T00:00:00+08:00

什么是Ceph

Ceph是一个可扩展的，高性能的分布式存储系统。提供了三种不同类型的接口以适应不同的应用场景：

block-based: 块存储，可以用做VM的虚拟磁盘
object-based: 对象存储，与Amazon S3等常用对象存储兼容
file system: POSIX兼容的分布式文件系统，可以被本地系统挂载，并且能被多个客户端共享

Ceph的特性

由于采用了CRUSH算法，Ceph有着优异的可扩展性（宣称可以无限扩展）。并且借助可扩展性，进而实现高性能、高可靠性和高可用性。

Ceph是一个去中心化的存储系统，无需中心节点进行资源的管理与调度，全部的管理功能由存储节点自治完成。使得整个系统可以自我管理与自我恢复，减少运维成本与管理成本。

RADOS - Ceph的存储引擎

RADOS=Reliable Autonomic Distributed Object Store。RADOS是Ceph底层的存储引擎，所有的接口都建立在RADOS的功能之上。

RADOS中的存储结构

存储池（pool）：逻辑层，每一个pool里都包含一些放置组
放置组（placement-group, PG)：逻辑层，一份数据会在PG当中进行灾备复制。每一个PG都对应着一系列的存储节点
存储节点（OSD）：用以存储数据的物理节点。与PG之间形成多对多的关系。

一份数据在写入RADOS时，会先选中一个pool。Pool中再使用一定的hash规则，伪随机的选中某一个PG。PG会将数据写入多个OSD中。读取数据时，也是类似的规则。

Pool是用户可见的管理数据的基本单位，用户可以对Pool进行一系列的配置（权限控制、使用SSD or HDD、使用数据拷贝 or 纠删码，etc.）。而PG与OSD对于用户是不可见的。

PG的组织

在一致性哈希中，我们使用节点来划分哈希值域。这种方法的问题是，如果产生了数据不平衡，我们需要重新进行划分值域来进行再平衡。这会造成大量的数据迁移。

CRUSH采用了虚拟节点（也就是PG）将哈希值域划分成了固定的等长区域。这种方法在单条数据与物理节点之间加入了一个虚拟层。之后，再使用哈希取模的算法确定数据属于哪个PG。使得数据的迁移是以虚拟节点为单位，而不是对每一条数据都重新计算。Ceph官方的建议是，每1个OSD对应着100个PG。

一般情况下，在规划的初期需要确定PG的数目，如果后期需要调整PG，有可能会导致大量的数据迁移，甚至需要服务暂时停止服务。

监控子集群（MON）与Cluster Map

RADOS集群中除了OSD存储节点之外，还有监控子集群（MON），用于存储系统的拓扑结构——Cluster Map。

元数组管理（MDS）节点用于管理CephFS中的文件元信息，后文会有介绍。

不同于传统的中心化管理节点，MON并不会对资源进行调配与调度，而仅仅是一个观测者，用以存储系统当前的拓扑与状态。

MON与OSD、OSD与OSD之间会定时发送心跳包，检测OSD是否健康。如果某个节点失效，MON会更新内部存储的拓扑结构信息（ClusterMap），并且通过P2P协议广播出去，从而使得整个系统都有着（最终）一致的拓扑信息。

主从同步与节点自治

在一个PG中，会有一个主节点（Primary）和一个或多个从节点（Secondary）。主节点负责维护从节点的状态，包括数据复制（replication）、失效检测（failure detection）和失效恢复（failure recovery）。

CRUSH - Ceph皇冠上的明珠

CRUSH是一个可扩展的，伪随机的数据放置算法。以去中心化方法，将PG按规则映射到相应的存储设备上。并且系统的拓扑结构发生变化时，尽可能的减少数据的迁移。

CRUSH的优势

CRUSH对于每一个数据元素使用一个伪随机算法，决定其放置的位置。所以，只要所有参与者都拥有相同的系统拓扑结构信息，那么数据的位置就是一定的。所以我们可以去掉中心节点，采用P2P的方法来进行数据的存储与检索。

并且，由于伪随机算法只与单个PG相关，如果我们操作得当，节点数量的变化并不会引起大量的数据迁移，而是会接近理论最优值。

数据放置（Data Placement）

CRUSH的数据放置算法有很多不同的实现，这里只介绍最常用的straw算法。

Ceph中，每一个OSD节点都有一个权值w，代表着某个节点能支持多少数据的存储与检索。一般来说，权值与节点的容量成正比。

假设一个pool里面有n个PG，在一条新的数据写入时，我们分别会计算这n个PG的length值。

$$ length_{i} = f(w_{i}) * hash(x) $$

$f(w_{i})$是一个只于当前OSD节点权值有关的函数。$hash(x)$代表当前PG的哈希值。所以，PG会放置在哪个OSD上，仅与其权值相关。

假设某个OSD节点发生变化时（新加、删除、权值变化），在此受影响节点的数据会迁移到其它的OSD节点。其它OSD节点的原有数据并不会受到影响。

Ceph当中的straw算法有straw1和straw2。straw1的实现采用了有缺陷f(w)函数，会导致意外的数据迁移。straw2解决了这个问题。
详情请戳这里

主从架构

每个PG所包含的OSD都由CRUSH算法计算得出，并根据配置选出前r个OSD进行主从配对。列表中的第1个OSD做为主节点（Primary），其它的节点为从节点（Secondary）。

主从节点的分配与管理由PG内部进行自治，不需要额外的外部系统进行管理。

CephFS

CephFS是一个POSIX兼容的（共享）文件系统。CephFS利用文件元数据子系统（MDS）来维护目录树结构和文件和目录的元信息（owner, timestamps, inodes, etc.)等。

MDS子系统会在内存里面维护一份Cache，对于需要持久化的信息，会使用WAL的方式写入RADOS里一个专用的Pool当中。

动态树划分（Dynamic Tree Partitioning，DTP）

CephFS的扩展性的关键之一，在于元信息子系统的扩展性。CephFS实现了动态树划分的算法，将目录树结构根据当前系统的负载，将其划分到不同的MDS节点上去。

维护目录树结构的优势在于利用了文件系统的局部性（locality），可以方便的进行预取（prefetch）。动态的树划分，可以保证元信息可以线性增长，以保持高可扩展性。

写在最后

本文基于Ceph的三篇论文综合而成（CephFS、RADOS、CRUSH）。其中加入了一些自己的看法，使其逻辑通顺，并不保证与论文的思路完全一致。

这三篇论文并没有明确的依赖关系，换句话说，需要综合阅读，才能有比较明确的理解。

建议在通读论文后，去学习一下这个视频，会对理解Ceph有很大的帮助。Youtube上面还有很多Ceph的tech talk，可以一并的了解一下。

Ceph相关的书籍以实践居多，只推荐Learning Ceph。

参考链接

2020 计蒜之道线上决赛 - C. 攀登山峰

2020-10-26T00:00:00+08:00

本文使用了一种概率算法，不是正解，只求骗分。

题意

原题

给一个长度为n的数组A[1…n]。

现在有q个查询请求（q <= 1e5），每个请求给定一个长度为m的子数组A[i…j]和一个整数t。问在子数组中出现次数超过m/t的数字中（t <= 20），最大的数是多少。

题意中的坑

阈值m / t是一个实数。（题意不明先死个🐴好吗？）

解法

首先我们将每种数字出现的位置简历一个索引，此时对于任意一个数，我们可以用二分法在O(logn)的时间内求出其在某个区间内出现的次数。

因为t最大是20，也就意味着如果我们随机取数，那么取到一个符合出现次数限制的（超过m/t次）数字的概率是1/t。如果我们进行多次尝试，并使用上面的方法对其进行验证，几乎可以保证我们一定可以取到正确的那一个。

那么“多次尝试”是多少次呢？我们枚举所有的t，然后计算其在q=1e5的情况下的成功率。因为这是一个随机算法，我们先使用下面的代码分别计算一下成功率为10%和50%的期望尝试次数。

#coding=utf-8

for i in xrange(1, 21):
    fail = 1 - (1. / i)
    for j in xrange(1, 3000):
        ff = 1 - fail ** j
        if pow(ff, 100000) > 0.1:
            print i, j, pow(ff, 100000)
            break

由上表我们可以知道，对于不同的t，我们可以使用不同的尝试次数以达到预期的胜率。

总的时间复杂度为O(q * logn * attempt)，对于极限数据可能会有超时的风险，所以我们在随机尝试时可以加入些许的优化，例如加上输入输出外挂，以及不计算重复值与小于最大值的值等。剩下的工作就是孜孜不倦的提交，直到获得AC为止。（评测机你辛苦了）

以及，记得加上初始化随机数种子srand(time(NULL));，否则你的随机数每次都一样。。。

实际上总的胜率还是很高的，说明数据并没有达到极限，出题人手下留情做了个人（

代码请见这里

6.824 Lab 2: Raft协议实现指南（无剧透版）

2019-05-02T21:33:00+08:00

背景

MIT6.824是一个用来学习分布式系统的非常好的资源。其中第二个课程作业就是关于Raft算法。

由于在工作中涉及到分布一致性算法的调研，接触了paxos/raft算法。然后被@neutronest安利了一发，于是开始着手实现这个作业。

本文是我对这个项目的实现总结。希望能在划出重点的同时，不涉及实现细节，避免破坏大家的写代码体验。

本文唯一参考资料：In Search of an Understandable Consensus Algorithm

任务分解

在官方文档里，整个项目被分成了2A、2B、2C三个部分：

2A - 投票与选举
2B - 一致性
2C - 可持久化

实际上，2C的工作量非常少，我们可以把2B和2C合成一个。然后单独提出几个比较重要的测试用例，划分成子项目。任务分解如下：

2A - 投票与选举
2B/2C - 一致性和可持久化
三个难度比较高的Case
- Test (2B): leader backs up quickly over incorrect follower logs
  验证协议实现的正确性
- Test (2B): RPC counts aren’t too high
  测试协议是否产生了过多的RPC请求。验证协议的性能。
- Test (2C): Figure 8 (unreliable)
  测试在极端混乱的情况下，Raft协议是否能及时恢复正常工作。验证协议实现的正确性和性能。

所以推荐大家按顺序以上顺序进行实现。并且充分利用版本控制对代码进行开发和重构。

需要关注的知识点

以下会介绍每一个部分需要重点关注的知识点，内容包括golang基础和论文中的知识点，无剧透，请放心食用。

准备工作

golang是一门傲慢的语言，其标准库的缺乏实在是让人感到TMD蛋疼。但是对于一个课程作业来说，我们也没有必要引入一系列第三方库。所以我们先要扩充util.go文件，使其为我们的开发提供更多的便利。

Log模块

项目给出的DPrintf函数非常简单，只提供了一个fmt.Printf的封装。并不能打印行号和文件名。这里提供一个扩展版本。

func DPrintf(format string, a ...interface{}) {
    if Debug > 0 {
        _, path, lineno, ok := runtime.Caller(1);
        _, file := filepath.Split(path)

        if (ok) {
            t := time.Now();
            a = append([]interface{} { t.Format("2006-01-02 15:04:05.00"), file, lineno }, a...);
            fmt.Printf("%s [%s:%d] " + format + "\n", a...);
        }
    }
}

其输出示例如下：

2019-05-02 09:28:35.04 [raft.go:652] Node[1] is processing, state: [LEADER], term 1, commitIndex: 12, logCount: 12, leader 1

Max和Min函数

golang是没有对于int值的max和min函数的，这里省略脏话100句。

func Min(a int, b int) (int) {
    if a < b {
        return a;
    } else {
        return b;
    }
}

func Max(a int, b int) (int) {
    if a > b {
        return a;
    } else {
        return b;
    }
}

Assert函数

是的，你没有看错，golang也没有提供assert函数。如果你嫌到处写if和panic太丑的话，可以使用这个assert函数。

func Assert(flag bool, format string, a ...interface{}) {
    if (!flag) {
        _, path, lineno, ok := runtime.Caller(1);
        _, file := filepath.Split(path)

        if (ok) {
            t := time.Now();
            a = append([]interface{} { t.Format("2006-01-02 15:04:05.00"), file, lineno }, a...);
            reason := fmt.Sprintf("%s [%s:%d] " + format + "\n", a...);
            panic(reason);
        } else {
            panic("");
        }
    }
}

Log Id

为了验证日志的一致性，我们在日志中额外加入一个UUID来进行标识。

import "math/rand"

func CreateLogId() (uuid string) {
    b := make([]byte, 16)
    _, err := rand.Read(b)
    if err != nil {
        fmt.Println("Error: ", err)
        return
    }

    uuid = fmt.Sprintf("%X-%X-%X-%X-%X", b[0:4], b[4:6], b[6:8], b[8:10], b[10:])

    return uuid
}

以上代码可以生成一个（伪）UUID对日志进行标识。推荐使用math/rand，因为这里我们使用伪随机数就够了。

注：这里的UUID只是看起来像一个UUID，实际上UUID有其特殊的规范与格式。但是由于golang内部没有提供可用的UUID库，所以只好随手模拟了一个。

文件组织

默认的实现是把所有的东西都写到了raft.go文件里。一个非常大的文件可能会给我们的开发带来负担，所以我的做法是把所有的类声明放到models.go文件里。以避免文件的膨胀。

锁与defer

在raft实现中，锁可以用来保证在多线程环境下数据的正确性。所以只要在涉及到raft内部状态的变化时，都需要加锁。一个常见的加锁pattern是：

rf.mu.Lock() // 加锁
defer rf.mu.Lock() // 在函数执行完成后解锁

这里推荐使用defer，因为手动控制锁实现是过于容易出错。但是defer也是有坑的！

不同于C++的大括号作用域，defer的触发时间是在函数执行完成之后，而并不是退出当前大括号时。这点非常需要注意，否则极易出现死锁。

如果我们想实现C++中do { ... } while (0);类似的lock guard pattern，可以使用以下实现：

func() {
    rf.mu.Lock()
    defer rf.mu.Unlock()
    // do something here
}()

这样一来，在执行完当前lambda之后，就会自动解锁。

刷新定时器

由于raft算法里面使用了定时器，这里提供一个刷新定时器的golang代码。这样实现是为了每次在刷新的时候，清空定时器中原有的超时时间，以避免混乱。

func (rf *Raft) renewTimer(timeout time.Duration) {
    if (rf.timer == nil) {
        rf.timer = time.NewTimer(timeout)
    } else {
        if (!rf.timer.Stop()) {
            select {
            case <- rf.timer.C:
                // pass
            default:
                // pass
            }
        }
        rf.timer.Reset(timeout)
    }
}

以及，在定时器超时之后，不要忘了更新定时器。

2A - 投票与选举

所需要类的声明

论文中的Figure2包含了算法中所有的类以及基本算法。在2A中，所有的类都会被用到。由于2A中只包括投票与选举，所以和日志相关的字段可以先忽略掉。

Checklist for 2A

实现raft状态机的三个状态：leader，follower和candidate
实现RPC函数：sendRequestVote（发送端）和RequestVote（接收端的回调函数）
实现RPC函数：sendAppendEntries（发送端）和AppendEntries（接收端的回调函数）
保证raft状态机的任期号（currentTerm）是单调递增的
一个Follower对于某一个Term只能投出一票
实现Leader心跳，维护当前任期（Term）。
实现Follower选举超时（election timeout）
实现Candidate选举的三种场景
- 获得多数选票，赢得选举。状态切换为Leader
- 其它的节点已经被选为Leader。状态切换为Follower
- 在选举中并未获得多数选票，状态切换为Follower
实现Candidate随机选举超时（randomized election timeout）

2B/2C - 日志复制与持久化

基本工作流

日志复制的基本工作流如下：

Leader接受用户请求，将状态变化写入本机的日志流中，并且把日志复制到Followers。如果本条日志合法，Followers会将这条日志标记为“提交”（committed），然后再将这条日志“应用”（apply）到Raft协议之外的状态机。Follower在提交日志之后，就可以向Leader回报这条日志已经被提交。在本条日志被多数节点提交之后，Leader再将这条日志标记为提交。此时，用户的请求就可以被确认（ACK）了。

Raft的论文中，Leader需要维护commitIndex和lastApplied这两个状态。为了简单起见，我们可以忽略“应用”（apply）这个过程。这两个状态我们只需要维护commitIndex即可。

Raft协议不是2PC，千万不要搞混了哦～

回滚与滚回来

从上面的工作流我们可以看到，对于已经committed的日志，仍然有可能是不可靠的。

例如，在Term1时，节点1作业Leader提交到了日志(1, 2)，而Follower节点Node2和Node3分别提交到了日志(1, 2)和(1, 3)。此时Leader短暂断线，出发选举超时，就会进行下一轮的选举。如果节点Node2被选为Leader，那么节点Node3就会被Leader多出一条日志，这是不被允许的。如果节点Node3被选为Leader，那么Node2就比Leader在Term1少一条日志，需要补齐。

这里有人可能会怀疑，节点2比节点3少一条日志，那么按照论文里的说法，因为节点3的日志比较节点2要多，所以只有节点3才能赢得下一轮选举。这其实是不对的，如果节点3断线，节点1和节点2仍然可以组成一个quorum，选举出Leader。

所以我们需要考虑将已committed的日志回滚（向左滚），以及缺失的日志补齐（向右滚）。这里其实有一些优化的点，我们后文再说。

再次注意，保证日志的一致性是Raft协议正确性的必须保证，在这一点上一定要注意。

乱序请求

本项目中，模拟的RPC协议并不能保证可靠性（会丢包）、有序性（会乱序），也没有SLA（没有超时时间的上限），更不用想拥塞控制。我们可以理解为它在底层使用了UDP协议，而不是TCP。所以我们不能做出任何假设。

例如，两个请求先后来到Leader端，A请求编号(1,100)，B请求编号(1,110)。然后我们依次将Log复制到Follower端（A先B后），但是在Follower端有可能收到的顺序是B先A后。甚至只收到B，没收到A。这种情况日常工程中的TCP协议下几乎不能发生，但是在测试环境中要十分小心。

Checklist for 2B/2C

日志的状态会影响Leader选举
如果两份日志流的最后一条日志的Term不一样，那么我们认为Term号大的日志“比较新”。如果Term号一样，那么Index大的日志“比较新”
如果Leader和Follower的日志不一致，那么Follower需要拷贝Leader的日志（向左滚或向右滚的正确性）
这里推荐使用Assert加断言进行保证，如果出错可以获得实时的现场
对于小于当前Term的日志，Leader不需要等多数Follower确认就可以直接commit
一个重要特性：如果两个日志的(Term, Index)一致，那么其内容也是一致的。并且在此日志之前的所有日志都必须是一致的
另一个重要特性：RPC请求是幂等的，也就是多次重复发送一个请求并不会破坏Raft协议的状态

最后的3个Case

最后的三个Case有一个共同点，就是对协议的效率和正确性有比较高的要求。即使前面的代码里你的实现是正确的，也有可能因为各种其它的原因造成Case挂掉。

建议首先解决正确性问题，再提升效率。

向左滚的优化（重要！）

在论文的5.3节，介绍了一种回滚的优化。如果Leader和Follower在某个Index上的日志不一致，Leader的版本记为(Term1, Index)，Follower的版本记为(Term2, Index)。那么Follower需要回滚所有日志，直到Term小于Min(Term1, Term2)。

这样的好处是可以加快回滚的效率。虽然论文上表示这种优化并非必要，但是在模拟出来的极端网络环境下，这样的优化可以帮助我们通过一些比较变态的Case。

其它的非官方优化

这里还有一些论文里没的提到的优化方案，不保证一定是正确的。

为了不剧透，放到单独的链接里了：剧透警告！

还有一个Bonus挑战，谁比较闲可以试一下。

测试结果

在Travis CI上面运行的测试。自我感觉实现的比较一般，所以你们的程序应该跑的比我快一点才正常。

总结

想要完整正确的实现这个项目，首先一定要把论文读懂。并且划出实现上应该注意的重点。

当遇到正确性问题时，一定要回归论文，大部分的问题都可以获得解答。当遇到性能问题时，可以参考作业上面的Hints，里面也有非常有用的信息。

MIT的这个课程还有基于raft实现kv storage的项目，后续如果有时间应该还会做吧。

白话一致性协议 - Paxos、Raft和PacificA[2]

2019-02-18T00:00:00+08:00

PacificA是一个框架

虽然在题目中我们把Paxos、Raft和PacificA并列，但是Paxos和Raft在论文中称自己为一种“算法”（algorithm）；而PacificA对自己的定位是一种通用的，强一致的数据同步框架。

在论文中，作者提到现有的可证明的数据同步协议往往过分简化了性能问题，导致看起来很美的理论设计无法转变有实际的系统（注：本篇论文应该早于Raft的论文）。所以作者的目标是将算法理论与实际相结合，进行相应的系统设计。

PacificA的实现

与Paxos和Raft不同的是，PacificA采用的算法非常简单。所以在这里我不进行太多铺垫，直接进入正题。

主从同步

PacificA使用了主从同步模型，用户的读写请求都会发往主节点，以保证强一致性。

主节点会对发来的写请求进行编号，使得所有写请求编号唯一且单调递增。这个编号也会同步到从节点。

无论是主节点还是从节点，所有的写请求都写入一个只追加的日志。主从节点都需要维护committed指针，代表在这个指针之前的数据都已经被所有节点所认可，处理“已确认”状态。从节点需要额外维护一个prepared指针，代表在这个指针之前所有的数据都处于“待确认”状态，而在prepared指针之后的数据，都是“待同步”状态。

主从之间的数据同步使用两步提交模型（2-PC）：

主节点首先把写请求写入日志
主节点发送prepare请求到从节点，这个请求中包含写入的数据
从节点收到prepare请求后，将数据加入日志，并移动prepared指针，将其标记为“待确认”
当所有从节点返回ACK后，主节点移动committed指针，表明这个数据处于“待确认”状态
主节点向所有从节点发送ACK消息，确认这条请求已经被最终确认
从节点收到ACK消息后，移动committed指针，确认请求

所以对于一个节点，总会有:

全局配置管理器

PacificA使用了一个“中心化的”全局配置管理器。这个管理器用于探测系统内的失效节点，管理、更新节点的配置。而Raft是“去中心化的”，通过节点之间的选举通信来管理配置。

PacificA的全局配置管理器保证在任何情况下，当且仅当全局配置管理器认可节点s为主节点时，节点s才会认为自己是主节点。

全局配置管理器在“钦点”了主节点后，主节点会与从节点发送心跳包（beacons），维护一个租期（lease）。在租期内，主节点和从节点都会互相承认相互之间的主从关系。当租期失效时，主节点会向全局配置管理器报告从节点失效。当从节点收不到心跳包时，从节点会报告主节点失效。

一个中心化的配置管理器会让整个系统的维护变的非常简单，但是也会带来单点失效的隐患。这里，全局配置管理器使用了Paxos算法来保证管理器节点之间的一致性，可以容忍少于半数节点的失效。

配置变化与灾难恢复

由于我们使用的全局的配置管理器，所以添加删除从节点会是非常简单的事情。这里我们主要讨论主节点的失效与灾难恢复。

当主节点失效之后，从节点会揭竿而起，向配置管理器申请成为主节点。这里要注意，根据上面的讨论，从节点中的committed指针有可能会落后于主节点，以及不同从节点中的committed指针可能会不一致。但是被主节点ACK的数据，一定位于从节点的日志中，并处于“待确认”状态。

所以在新的主节点被指派之后，会重新的向其它的从节点发出prepare指令，要求确认其日志中待确认的数据。从而保持数据的一致性

PacificA的正确性的简单讨论

一个强一致性的系统一定会包含以下三种特性：

线性一致性（Linearizability）
由于我们的写请求位于一个只可追加写的日志当中，并且不同的副本的日志保持强一致。所以不同的副本的状态也应该是一致的。
可持久性（Durability）
如果用户收到了ACK，那么这个请求一定已经持久化到所有的副本之上了。即使发生了主节点失效，新的主节点仍会维持已ACK的数据。
前进性（Progress，不知道怎么翻译）
全局配置管理器在处理完配置更新请求后，一定可以剔除失效的节点。使得整个系统可以处理用户的读写请求。

一些其它的讨论

全局配置管理器的可用性和性能

由于全局配置管理器在逻辑上是整个系统的单点，所以其可用性和性能是非常值得关注的。

全局配置管理器了Paxos算法，所以在少于一半的节点失效时，它仍能对外提供服务。

同时，全局配置管理器的处理不在整个系统的关键路径上，所以在一般情况下不会影响系统的整体性能。同时，在系统不正常运行的情况下，即使配置管理器暂时失效，也不会影响系统的运行。

可持久性

PacificA的日志同步采用了两步提交，所以用户收到ACK时，说明用户的写请求已经被持久化在所有的节点之上了。

这意味着，在一个有n台机器的集群里，即使有n - 1台节点失效，我们仍能提供可用的服务。（但是一般只提供只读服务）

主从复制 vs. Paxos

在Paxos范式的实现中，如果一个请求被多数节点认可，我们就可以向用户端返回ACK，声明这个请求已经被整个系统所认可。但是在主从复制的范式下，必须要所有的节点都认可这个请求，我们才可以说这个请求被整个系统所认可。

因为这两种范式之间的不同策略导致了微妙的差别。

我们很容易看出，Paxos范式中对于单个节点的性能波动并不敏感，但是主从复制的一个慢节点可能会拖慢整个系统。但是，如果系统中多数节点全部失效，那么Paxos范式就无法提供服务了（读/写都不可以的）；对于主从复制范式，只要有一个节点是存活的状态，我们就可以对外提供服务，并且保持强一致性。

更重要的是，使用单点来管理整个系统的配置，并让开发与运维的成本降低。换做Paxos范式，一个节点若要成为主节点，则需要同多数节点进行协商。

这两种范式的选择是非常有争议的，PecificA选择主从复制的主要原因就是因为它简单。（太实在了）

在强一致性上的妥协

如果需要放松对强一致性的要求，我们可以让从节点支持读请求。这样带来的问题是我们有可能读到陈旧的数据，由强一致性退化到最终一致性。

最终一致性从本质上说需要满足以下两个要求：

所有的节点需要以同样的顺序执行同样的状态更新操作
在处理请求时，必须返回最新的状态

如果放松第一个要求，就会面临“状态分叉”的问题（像git branch一样），所以我们需要处理这种不一致的问题（像git rebase一样）。这就会带来额外的复杂性和不确定性。

放松第二个要求是更加理性的，因为在PecificA中，所有的状态变化全都被写入一个“只可追加写”的日志中。并且当前的状态变化通过日志指针的移动来表示。又因为从节点的日志一定是主节点的前辍，并且日志指针稍微落后与主节点。所以如果我们可以放松强一致性的要求，就可以让从节点来处理读请求。

写在后面

还有好多东西没读透呢。要不再饶一篇？

C++类型擦除与`std::function`性能探索

2019-02-01T00:00:00+08:00

什么是类型擦除

对于Python这种动态类型语言来说，是不存在“类型擦除”这个概念的。Python对象的行为并不由接口定义，而是由“当前方法和属性的集合”决定。

所以，以下的代码是完全合法的：

class Foo(object):
    def print(self):
        print 'foo'

class Bar(object):
    def print(self):
        print 'bar'

def do_print(obj):
    print obj.print()

do_print(Foo()) // print 'foo'
do_print(Bar()) // print 'bar'

但是对于C++这种静态类型语言来讲，我们就不能使用这种语法：

class Foo {
public:
    void print() { cout << "foo" << endl; }
};

class Bar {
public:
    void print() { cout << "bar" << endl; }
};

void do_print(??? obj) { // <--
    obj.print();
}

do_print(Foo());
do_print(Bar());

熟悉C++的同学们都知道，因为Foo和Bar的类型不同，我们不能直接将不同类型的实例传入do_print(obj)函数。所以我们需要一种方法擦除类型信息，提供一种类型的抽象。使得实现不依赖于具体类型，而是依赖于类型抽象。

C++中类型擦除的实现

简单粗暴 - `void*`

写过C语言同学们一定非常熟悉qsort函数的写法：

// http://www.cplusplus.com/reference/cstdlib/qsort/
int compare (const void * a, const void * b) {
    return ( *(int*)a - *(int*)b );
}

int main () {
    int values[] = {1, 3, 5, 2, 4, 6};
    qsort (values, 6, sizeof(int), compare);
    for (int i=0; i<6; i++)
        printf ("%d ",values[n]);
  return 0;
}

这里的compare(const void*, const void*)函数就是C语言风格的类型擦除，可以支持不同类型的指针类型传入。但是缺陷是在函数中，我们仍然需要将已擦除的类型恢复，以读取其中的数据。

这种类型擦除方法，并不会带开额外的开销。但是这样的强制类型隐含着类型不匹配的风险，需要程序员格外注意。

面向对象的经典方法 - 虚函数（virtual function）

C++做为C语言的进化，引入了面向对象的理念。而多态，做为面向对象编程的一个重要特性，为我们的代码带来了更多的弹性。

对于上面的例子，我们可以使用以下的代码来实现：

class IPrintable {
public:
    virtual void print() = 0;
};

class Foo : public IPrintable {
public:
    virtual void print() { cout << "foo" << endl; }
};

class Bar : public IPrintable {
public:
    virtual void print() { cout << "bar" << endl; }
};

void do_print(IPrintable* obj) {
    obj->print();
}

int main() {
    do_print(new Foo());
    do_print(new Bar());
    return 0;
};

在这里，我们使用了一个IPrintable基类，擦除了子类Foo和Bar的具体类型信息。也就是说，只要子类实现了基类的接口，就可以做为参数传入do_print(obj)中。这样的好处是我们只需要为继承同样接口的类型完成一套实现，提供了更好的封装与抽象。

但是，这种实现的问题在于虚函数的调用是有额外的开销的。需要进行一次运行时虚表的查找，才可以确定对象需要调用哪一个函数。

使用模板（template）

C++提供了模板，支持将类型以模板参数形式传入参数。使得我们可以以一种独立于特定类型的方式编写代码。

我们可以改写上文中的do_print(obj)函数，使其可以支持不同的类型：

template <typename T>
void do_print(T obj) {
    obj.print();
}

这里，传入参数的类型T无需继承IPrintable接口，只要其实现了print()成员函数即可做为对象传入。

C++模板的类型擦除作用于编译期，可以尽早的发现风险，同时（一般来说）不影响运行时的性能。

注意：Java/C#的泛型(generic)语法与C++的模板非常类似，但是Java/C#的泛型是作用于运行时的。这里注意区分二者的区别。

但是模板也有其局限性。模板有隐含的接口语义，但是由于模板所使用的对象并没有共同的基类（接口），所以它不能使用一个统一的容器来储存对象。

??? objs[] = { new Foo(), new Bar() };

C++类型擦除实战 —— `std::function`

在C语言中，我们要表示一个函数对象只能使用函数本身以及函数指针。但是在C++中，我们有了更多的选择：

函数
inline lambda
函数指针（C-style）
仿函数（factor class）
std::bind
std::function

上面的这些对象，我们可以统称为可调用（callable）对象。也就是说，我们可以使用类似f(obj)的语法，以函数形式调用这些对象。

思考以下的场景：我们想要实现一个回调函数。这个函数是用户定义的，可以是以上可调用对象的任意一种。那么我们应该用什么类型来表示这个回调函数对象呢？

是的，答案就是std::function。C++中的std::function为我们提供了对可调用对象的抽象。我们可以使用std::function封装可调用对象，从而擦除其类型信息，使用统一的方法对其进行调用。

请参考以下代码：

// http://www.cplusplus.com/reference/functional/function/function/
#include <iostream>     // std::cout
#include <functional>   // std::function, std::negate

// a function:
int half(int x) {return x/2;}

// a function object class:
struct third_t {
  int operator()(int x) {return x/3;}
};

// a class with data members:
struct MyValue {
  int value;
  int fifth() {return value/5;}
};

int main () {
  std::function<int(int)> fn1 = half;                    // function
  std::function<int(int)> fn2 = &half;                   // function pointer
  std::function<int(int)> fn3 = third_t();               // function object
  std::function<int(int)> fn4 = [](int x){return x/4;};  // lambda expression
  std::function<int(int)> fn5 = std::negate<int>();      // standard function object

  std::cout << "fn1(60): " << fn1(60) << '\n';
  std::cout << "fn2(60): " << fn2(60) << '\n';
  std::cout << "fn3(60): " << fn3(60) << '\n';
  std::cout << "fn4(60): " << fn4(60) << '\n';
  std::cout << "fn5(60): " << fn5(60) << '\n';

  // stuff with members:
  std::function<int(MyValue&)> value = &MyValue::value;  // pointer to data member
  std::function<int(MyValue&)> fifth = &MyValue::fifth;  // pointer to member function

  MyValue sixty {60};

  std::cout << "value(sixty): " << value(sixty) << '\n';
  std::cout << "fifth(sixty): " << fifth(sixty) << '\n';

  return 0;
}

`std::function`的缺陷

std::function的类型擦除功能异常强大，几乎可以封装所有的可调用类型。但是，语法上面的便利却会带来了性能上的损失。

从benchmark结果上我们可以看出，在O2的优化参数下，函数调用（包括函数、函数模板和仿函数）、函数指针和lambda的性能相仿。而虚函数大概需要花费5倍左右的时间，而std::function则需要花费6倍以上的时间。对于一个会被经常调用到的函数，带来的额外的性能开销是不可以忽略的。

method	Linux (Azure VM, E5-2673 v3, -O0)	Linux (Azure VM, E5-2673 v3, -O2)
Function	12.4s	1.2s
Function Ptr	13.5s	1.2s
Inline Lambda	12.7s	1.2s
Virtual Function	14.1s	6.3s
std::function	77.3s	7.2s

究其原因，是由于std::function的模板参数中只提供了参数类型和返回值类型，所以为了进行类型擦除，其中内置了一个虚函数。所以一次std::function调用会引发隐式的多次函数调用，其中还包含着一次虚函数的调用。所以性能下降也就不难解释了。

解决方案

可以确定的是，除非必要，不要使用std::function。

例如，在std::sort中，我们使用模板传入可调用类型，这样就可以避免std::function的额外开销：

template< class RandomIt, class Compare >
void sort( RandomIt first, RandomIt last, Compare comp );

又例如我们可以避免使用不同的可调用类型来规避类型擦除，如统一使用函数指针。在C++14之后，inline lambda也可以表示为函数指针，所以我们也可以通过闭包来封装其它的可调用对象了。

当然，也可以自己造个轮子，这就又是另一个故事了。

写在最后

新的C++规范给我们带来了很多的语法糖。对于传统C++程序员来说，好处在于我们可以写出更舒服的，更符合直觉的代码，但缺点是我们需要了解更多语言背后的东西。所以对于自己不熟悉的新式语法，无论看起来多么诱人，也需要多加谨慎。

参考链接

在WSL中获取Windows剪贴板中的图片

2019-01-04T00:00:00+08:00

背景

Win10里面的WSL（Windows Subsystem For Linux)算是一个开发神器了，虽然功能不是100%完善，但是对于轻度开发已经足够了。现在我的日常开发，就是一个全屏CMD跑内部工具，一个全屏WSL跑tmux+vim。

（跑题了）

问题

之前的文章里，我有写到使用github做为图床，并且使用python脚本进行图片上传。但是仍有一点问题，就是之前的脚本只能上传文件，不能直接上传剪贴板里的图片。

解决

发现Windows里面有内置的访问剪贴板工具，但是只在powershell下可用。不过我们可以在WSL里直接调用exe文件（这点非常神奇），然后读出图片文件放入临时文件夹。然后我们再读出这个文件进行上传。

总的流程仍然是上传已有的图片文件，但是我们把它放在临时文件夹并隐藏了起来。看起来就是实现了WSL和Windows剪贴板的互操作。

#!/bin/bash

TMP=/mnt/c/Users/me/AppData/Local/Temp/
TMPWIN=C:\\Users\\me\\AppData\\Local\\Temp\\

ts=`date +"%Y-%m-%d_%H-%M-%S"`

echo "(Get-Clipboard -Format Image).Save(\"$TMPWIN\\$ts.png\")" | /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe &> /dev/null

if [ $? -ne 0 ]
   then
       echo "no image in clipboard"
   else
       python upload.py $TMP/$ts.png
   fi

白话一致性协议 - Paxos、Raft和PacificA[1]

2018-12-05T00:00:00+08:00

书接上文 - Multi Paxos

在上一篇文章中，我们提到了Basic Paxos和Multi Paxos的异同。在Paxos Made Simple论文中，作者提到了Multi Paxos的一种实现。这个实现允许我们对一个连续的数据流（也可以称为复制日志，replicated log）达成共识，从而实现节点状态的一致性复制。

确定性状态机

我们可以将系统中的每一个节点抽象为一个有着确定性状态机，即给定多个状态一致的状态机，在执行同一个命令之后，其状态仍保持一致。（可以想一想编译原理里面的DFA）

Leader - 系统中唯一的proposer

如果系统中存在有多个proposer，那么就很可能会出现多个提案相互干扰的情况。虽然根据证明，最终这些提案都会收敛到一致，但是性能会非常低下。所以我们可以在系统中通过选举，选出一个leader做为主proposer（distinguishied proposer），所有的提案都由leader提出。

这样一来，在绝大多数情况下都不会出现提案相互干扰的情况。只有在leader切换的瞬间，可能会出现相同编号的不同提案，但是我们的算法可以很好的处理这种情况。

分布式系统中的“TCP”

类似于TCP协议中序列号，Multi Paxos中的每一个命令都有一个递增的编号。即我们前一个执行的命令是100号，那么下一个执行的命令一定是101号。每一个命令都是一个Paxos实例，Leader向所有节点发布这个提案，在提案达成一致之后（多数节点返回ACK），就可以认为这个命令已经达成了一致。

和TCP一样，如果我们顺序的发布并表决提案，效率会非常低下（TCP停等模型）。所以，Multi Paxos采用类似滑动窗口的方案，每次对N个提案进行表决，以增加表决的带宽。

和TCP不同的是，如果某些序号的TCP包在传输中丢失，最坏的情况是我们会RST这条链接，其它的工作都交给应用层逻辑来解决。

但是对于Multi Paxos来说，如果某些提案没有被表决，那么就会在日志中留下空洞（gap）。这会直接影响系统的一致性。如果恰巧这个时候发生了Leader失效，那么新选举出来的Leader节点就要处理日志中的空洞。

解决空洞的原理也很简单，就是Leader向所有成员询问，对于这个提案，是否已经有达成共识的值。如果有的话，就使用这个值。如果没有，就用一个no-op（无操作）命令来填补这个空位。但是，对于实际工程中来说，我们还需要解决未达成共识时值的冲突等情况。

为什么我们还需要Raft？

Multi-Paxos在现实的工程当中更多的是一种符号。因为理论与实践上的隔阂是如此之大，如果想在工程意义上实现一个可用的Multi-Paxos算法，必然会在原算法的基础上进行一系列的魔改，这些魔改虽然均声称自己实现了Multi-Paxos算法，但是这些算法大多不能被证明是正确的。

Raft的目标是，即让算法满足工程化需要，又能保证其正确性。

Raft论文当中说Paxos算法难以理解，我并不这么觉得。因为Paxos论文里面把困难的部分都一笔带过了。只剩下简单的那部分了。

Raft vs. Paxos

Leader选举

在Paxos论文中，Leader选举被视作一种特殊的“提案选举”。只需要Proposer和Acceptor进行一轮或多轮（取决于运气）投票，就可以确定Leader。

但在实际工程中，我们需要考虑以下的问题：

如何判断Leader是否存活
是否每一个节点都有资格担当Leader

Leader的任期

Leader在被选举出来之后，都会被赋予一个任期编号（term）。在任期里，Leader会向所有成员发送心跳包以延续自己的任期。

如果Leader失效无法发送心跳包的话，成员就会产生一个“选举超时”，此时就会重新触发一轮选举。

选举的流程和Basic-Paxos算法类似，proposer向所有成员发送“我要当老大”的提案，成员们会酌情回复。如果得到了多数成员的肯定，这个proposer就是下一个任期的Leader了。

从本质上说，每一个任期的Leader选举，都是一个独立的Basic-Paxos实例。任期号相当于Paxos里面的提案编号。

Leader资格的认定

Raft采用强一致性的模型，对于已经ACK的用户请求，要尽力保证其状态不丢失。

如果你问我，现在来一核弹把机房炸了，数据都丢了，那你怎么能保证强一致性。
其实这个问题非常简单。很明显，我们保证了丢数据的强一致性。

所以我们要选出一个Leader，使其能够包含所有已经ACK的提案。当一个proposer向其它节点发送提案时，就会收到其它节点的响应。因为一个已经ACK的提案必然被多数节点所认可，所以如果一个proposer没有包含所有被ACK的提案时，它的提案就会被其它包含更多状态的节点驳回。最后被选出来的Leader，一定是包含所有被ACK的状态的节点。

日志复制

当Leader被选出后，Leader就会开始处理用户的请求。用户的请求可以看做一系列的命令，在接收到提案后，提案首先被分发到所有节点，节点的状态机顺序执行这些命令。在多数节点返回ACK后，这个命令就被视为“已提交”（commited）。

上文中已经提到了一致性算法中的日志非常类似于网络协议中的TCP。即如果两个命令的ID一样，那么其内容必定也一样；如果两个节点都有认可了编号为p的命令，那么所有编号小于p的命令也必定保持一致。（被称为Log Matching Property）

Raft为了简化算法的工程实现，把节点的状态抽象为严格append only的日志。即我们可以将日志指针向后或向前移动，来“回滚”或“更新”状态。但是绝对不允许在日志中间添加或删除日志条目。所以，在Leader发生变化时，如果leader和其他follower之间的日志不同，那么follower需要回滚日志以保持和leader日志的一致性。

安全性

不归我管的事我不拿主意

前文我们说到，一个节点要成为Leader，一定要拥有所有已经被ACK的状态，否则就会被其它节点驳回。

但是现实都会出现一些小小的意外。在系统的运行过程中，如果有一些提案只被少数节点认可，与此同时发起提案的Leader意外退出。那么在不同节点上的日志会产生“分叉”，那么我们如何解决日志当中的冲突呢？

很明显，因为这些以少数节点认可的提案并没有被确认。所以我们无论是接受提案还是驳回提案，都不影响我们强一致性的要求。所以关键是处理冲突，使其不产生影响系统一致性的后效。

假设在Term1，最后一个提案是”Value:3”，这个提案并没有得到多数节点的认可，Leader就挂掉了。选出来了一个新Leader，Term数加1。在Term2，被提出的第一个提案是”Value:1”，这个提案也没有得到多数节点的认可，Leader也挂掉了。

因为这两个分叉的提案都没有得到多数节点的认可，所以下一个Leader可能已经确认这两个提案，或者两个中的一个，也可能一个都没有确认。新的Leader在被选出后，需要面对的第一个问题是如何处理属于旧Term的提案。

解决方案有两种：

新Leader将日志中仍没有被多数节点认可的提案重新提出，直到被多数节点认可为止
新Leader忽略属于旧的Term的提案，只提交属于本Term的提案；对于日志冲突，使用复制日志的方法解决，但不会显式认可旧Term的提案。

对于方案1，有一个隐含的问题。如上图所示，在时间点1，S2为Leader，标红的两个提案并没有被确认。此时如果Leader在时间点2重新提出”Term1/Value3”，并且得到了S1和S2的认可，那么这条提案已经被多数节点认可。但是在时间点3，S3被选举为了Leader。S1和S2需要回滚日志以保持与S3日志的一致。此时就出现了一种情况，那就是已经被确认的日志被回滚掉了，强一致性就不能满足了。

如果我们采用方案2，那么被选出的新Leader提出的第一个提案的Term一定为3。确认新提案的节点接下来会复制Leader的日志，回滚掉没有被认可的提案”Term2/Value1”。对于标绿的”Term1/Value3”，虽然被复制到了其它的节点上，但是这个值并不会被确认。这样一来，我们既保证了已经被确认的提案不会被回滚，又保证了日志的一致性。

在具体实现中，“T3/V1”往往是一个空命令(no-op)。这样一来，即使没有写请求，Leader就可以更快的确认新的任期并同步Log了。

如何证明

那么怎么保证上面的作法它是正确的呢？

假设当前任期为T1，此时由于系统故障，我们选出了新的Leader - S2，并记Term为T2。因为我们严格遵守了Log Matching Property。

那么，对于以下两种情况：

T2的Leader和Voter的Log中最后一个提案的编号是一致的，那么可以知道他们日志中的提案都是完全一致的
T2中Leader的Log比Voter更新，那么Leader一定包含比Voter更多的提案；否则Voter就不会给Leader投票

我们都可以证明，对于前一个Term已经被确认的提案，一定会被包含在后一个Term的日志中。也就是说，一个被确认的提案不会中途丢失。

成员变化

以上我们的讨论都基于系统的节点不会发生变更，但是在现实工程中，我们很难对此进行任何保证。所以一个实用的系统，一定能解决成员变化的问题。

成员变化问题的本质是系统中不能同时出现两个Leader。

在Raft中，我们将过渡期的配置称为“共同一致”（joint consensus），一但它被确认，说明系统已经过渡到了新的成员配置。

具体的策略如下：

系统中只有旧的配置C_old，新加入的成员不可能成为Leader
当前系统的Leader接受到新的配置C_new。然后Leader向所有节点发起修改配置为C_old+new的提案。
即使这个时间点Leader挂掉了，新的Leader也只会拥有旧配置C_old或者过渡期配置C_old+new。这取决于Leader选举的时机（和运气）。
当过渡期配置C_old+new被多数节点确认后，Leader向所有节点发起修改配置为C_new的提案。
如果这个时间点Leader挂掉了，新Leader会从拥有C_old+new和C_new的节点中选出。新的Leader仍然可以进行配置的变更，而不影响整个系统的安全性。
直到C_new被确认，配置更换宣告完成。

“共同一致”允许节点无需考虑安全性的情况下，在任意时间进行配置的更换。配置的更换也不会影响客户端的请求。

以上我们解决的是安全性问题，但是在实际工程中我们还需要兼顾效率问题。

例如新加入的节点可以视作“non-voting members”，只同步数据，不能对提案进行投票。直到数据同步基本完成，才进行配置变更。这样避免了新的节点由于缺少Log不能及时的处理提案。

又如新的成员列表中，不包含原先的Leader节点。在旧Leader认可了新的配置提案之后，就可以退位让贤，让其它节点选举出新的Leader。

以及被清除出成员列表的节点，不会收到后续的心跳，它们会认为Leader已经失效，所以自己跳出来竞选Leader。这样一来，就会触发新的（无意义的）Leader选举，影响系统的可用性。解决方案是，如果一个节点在一个时间段内收到了Leader的心跳，那么就会忽略Leader的竞选请求。这样既不会影响正常的选举，又可以屏蔽无效的选举请求。

快照

我们的提案越来越多，日志也越来越长。随之而来的是漫长的恢复时间以及磁盘空间的浪费。快照技术可以帮我们清除旧的无用日志，只保留有用的状态信息。

在Raft算法中，每个节点都能自主的生成快照。好处是避免Leader分发快照造成的效率降低，也简化了Leader的功能和职责。又由于日志的“TCP特性”，所以不同节点上，只要保证提案编号一致，那么其内容就可以保证一致。

客户端交互

由于客户端不了解系统内部的选举情况，所以在开始通信时，会随机选一台节点发送请求。如果这个节点不是Leader，就会拒绝这个请求，会告知客户端哪个节点是当前任期的Leader。如果Leader失效，客户端请求超时，就会重新随机选择节点，获取新任Leader信息。

对于客户端发送的写请求，Leader需要记录其唯一的请求ID，以避免客户端发送的重复请求。

对于客户端发送的读请求，Leader需要再次确认它是仍是当前任期的Leader，避免向客户端发送过期数据。如果对数据正确性和时效性的敏感性不高，就可以向系统中的任意节点发送请求，

写在后面

Paxos的亮点在于把复杂的东西说简单了。而Raft的亮点是把简单的东西具体化，使之成为能落地的工程项目。

但是Paxos做为一种Quorum协议（俗称P2P），其工程复杂性是难以避免的。Raft在Paxos协议上面加入了很多限制以简化实现，但是想要完整的实现其功能仍不是一件容易的事。（有兴趣的同学可以挑战一下自己）

下面一篇文章我们会换一种新思路，学习PecificA算法，看一看如何使用Paxos实现一个主从复制协议。

写在更后面

个人觉得，Raft论文的一个更大亮点是充分的思考了Paxos/Multi-Paxos在工程实践上的缺陷。思考并提出有价值的质疑，而不是被他人的观点带着走，真的是最重要的能力之一了。

大胆猜测是因为有足够的理解能力，有额外的带宽去发问？这是一个有意思的问题。

白话一致性协议 - Paxos、Raft和PacificA[0]

2018-11-25T00:00:00+08:00

一致性协议 - Paxos

在分布式系统当中，我们往往需要保持节点之间的一致性。在绝大多数情况下，我们需要让系统中的节点相互协调通力合作，有可能的让系统正确的工作。但是，由于分布式系统本身的特性，需要我们在不可靠的硬件上尽可能的构建可靠的系统。所以，看似简单的一致性问题成为了分布式系统领域的一个重要的课题。

Paxos算法是Leslie Lamport于1990年提出的一种一致性算法。也是目前公认解决分布式一致性问题最有效的算法之一。

Paxos算法的目标是在一个不可靠的分布式系统内，只通过网络通信，能够快速且正确地在集群内部对某个数据的值达成一致。并且保证不论发生任何异常，都不会破坏系统的一致性。

Paxos算法

另一种（简化了的）形象的问题描述 - 买车位

某小区的一些居民在抢车位，而车位只有一个。居民们达成协议，只要一个报价获得半数以上居民认可，那么提出这个出价的居民则获得了车位的所有权。

居民之间非常友善，如果知道了车位已经有了买家，就不会继续出价购买，并且会帮忙传播这个信息。

居民们都是遵纪守法的好公民，在整个过程中都只会如实的与其它用户分享信息。信息的分享是在网上，通过一对一的私密聊天进行。但是小区的手机信号非常差，我们不能保证通信的质量，一些信息可能会丢失。但是居民不会掉线。也不会失去记忆，并且通信的内容是完整的，不会被篡改的。

划重点：

需要半数以上居民的认可，才能声称拥有车位。这个居民被称为车位的“公认拥有者”
车位有且只有一个，所以一个车位不能同时有两个“公认拥有者”
车位可以暂时没有拥有者，但是需要尽快选出一个
通信是不可靠的(not-reliable)，但是正确性(integrity)和可持久性（durability）是可以保证的
整个流程的目标是确定车位的拥有者。流程的参与者不会以自己拥有车位为最终目标

如何选出最终的买家

由于通信是一对一的，对于所有参与者来说，他们对整个系统的了解都是片面的、过时的。但是参与者会通过与其它参与者进行通信，不断获得更及时的信息，从而最终达成一致。

对于普通居民，会记录“已知最高报价”和“已确认报价”两个状态。会处理两种请求：

询价：如果居民已确认了某个报价，则返回这个报价。否则会尝试更新已知最高报价，并报告买家当前的最高报价
报价：居民会将请求中的报价与自己已知的最高报价进行比较，如果高于或等于本地已经报价，无论是否已经有已确认报价，都会确认这个报价

而对于买家，会发出两种不同的信息：

询价：以某一个报价问询多数居民，如果有已确认的报价，则放弃自己的报价。如果这个报价低于居民已知的报价，则提高报价。
报价：如果询价过程中收到了已确认的报价，则帮忙转发这个报价。否则发送自己的报价，如果报价获得了多数居民的认可，即可以认为所有权已经更新

一致性的直观证明

报价阶段，除了保证正确性之外，对于居民和买家并没有任何约束。其本质参与者之间同步信息的过程。

而一致性在报价阶段可以被很好的保证

如果车位还没有主人，那么大家就拼一拼运气和手速，直到有一个买家获得了半数居民的认可。
如果用户A已经声明以价格P买入车位（记为(P, A)），此时必有多数居民已经认可(P, A)。如果用户B想要声明以价格Q(Q >= P)买入车位，首先需要向多数居民询价，在询价的过程中，一定会收到用户A已经拥有车位的信息，此时B只会帮A扩散信息，而不会去争夺拥有权。系统最终会达到一个稳定的状态。

失忆 - 放松可持久性要求

如果我们放松可持久性的限制。即居民可以掉线，或者清空自己的记忆。那此时最差情况是多数已经确认报价的居民不再承认报价，那么系统就有可能退化到“仍没有人拥有车位”的状态。此时我们只需要再进行一轮选举，选出车位新的主人即可。这并不会破坏整个系统的一致性。

旁观者视角

假如我们做为旁观者，想要观察是谁最终拥有了车位。可以有以下两种方法：

“推”模型

当新的买家被选举出来时，新买家会通知所有旁观者车位的拥有者发生了变化。这样观察者们可以实时的获得状态的变化，但是由于通信是不可靠的，旁观者可能会错过状态变化的信息。如果这种情况出现，观察者只能等待下次状态变化，才能更新自己的状态。

“拉”模型

旁观者可以假装自己是一个买家，向多数居民进行询价。如果最终买家已经确定，那么询价的响应中一定包含着最新的拥有者信息。

Paxos如何解决活锁问题

假设居民里有买家A、B，同时向其它居民提出询价/报价。如果他们的询价/报价顺序排列如下，会出现什么状况呢？

A: 询价，1块
众居民：好的，最高价为1块
B：加钱，2块
众居民：收到，最高价为2块
（此时A仍旧认为1块是最高报价）
A：最终报价，1块
众居民：不行不行，B已经加到两块钱了
A：（内心mmp）询价，3块
（B对A提高了报价也毫无准备）
B：最终报价，2块
众居民：滚粗，A已经报价3块了
B：我加钱
A：我再加
B：我加钱
A：我再加
众居民：。。。（你们玩个球啊）

震惊，这帮无聊的人居然为了这几块钱可以玩一天！

以这样的流程进行下去，系统会陷入活锁，几乎不能达成一致了。想要解决这个问题，可以将A和B的询价重试时间加入随机化因子，这样可以帮助更快的让居民们达成一致。

Paxos如何解决投票分裂问题

如图所示，居民们的投票可能会发生分裂，即没有一个值达到了半数。这里的解决方案是让买家重新进行询价，同时加入随机化因子，使得投票达成半数以上的概率更大。

说正经的

对于Paxos算法的官方描述和正确性的详细证明可以参考原论文。这里就不搬运了，只是把我的例子和官方通用术语进行一下讲解，避免把大家带跑偏了。

在上面的例子中，“车位”的通用术语被称为“共识”，整个系统中最多有一个共识。而“询价请求”被称为“prepare请求”，“报价请求”被称为“accept请求”。

每个请求的价格被称为“编号”，编号大的请求可以覆盖编号小的请求，和“价高者得”是一个道理。请求中所带的信息被称为“value”，在我们的例子中，代表着购买者的身份信息。

Basic Paxos和Multi Paxos

上面我们描述的Paxos算法又被称为Basic Paxos，因为每一轮流程执行完，所有的参与者都会（且只会）达成一个共识。而在实际的应用中，我们需要连续不断的对多个值达成共识。这时Basic Paxos算法就力不能及了，一来每一个值的共识都至少需要两次广播网络请求，性能太低，二来同时存在的多个提案会互相竞争，使得通信的效率下降。

所以为了解决这个问题，Multi Paxos算法应运而生，即一种可以高效的、连续不断的对多个值达成共识的算法。

下一篇文章中，我们会介绍一种被普遍认可，以及已经被工业界应用的Multi Paxos的实现 —— Raft算法。

参考链接

七牛云图床自救指南（附github图床小工具）

2018-11-16T22:23:00+08:00

背景

之前一直在用七牛云的存储做图床（简称白嫖）。但是免费的午餐必然不会长久，七牛要求所有bucket都要绑定备案过的域名，否则就停掉你的bucket的外链。这事我也不吐槽，毕竟是白嫖，也不能要求啥。

但是最智障的是，你外链停了没关系，但是我在后台portal查看文件，上面的图还是显示不了，点下载也没有反应，只显示“ [5402] 获取 bucket 域名失败”。说好不嫖了，你却又不让我走了，都没办法数据迁移的。

因为博客里的图全都存在了七牛的图床上，这么一波搞下来就非常伤。于是我积极展开自救行动。

大侦探毛利小五郎

我：你看我们天天查问题，像不像柯南在查案子？
同事：我觉得我们更像毛利小五郎。

大胆猜测七牛的portal也是使用了外链的URL，如果不绑域名的话，是没有文件的URL的。但是我手里又没有备案后的域名。事情就陷入了僵局。

七牛提供了小工具（qrsctl）让我们管理文件，我觉得这可能是个突破点，万一小工具可以把数据下载下来呢？结果也是不行，这就非常GG了。

此时，我又发现小工具有拷贝数据的功能，可以把跨bucket拷贝数据，但是我的所有的bucket都没有绑域名。也并不能解决问题。

我突然又想到，七牛云其实并没有完全禁止外链。对于一个全新的bucket，七牛会免费提供30天的测试域名，所以新的bucket是可以进行文件下载的。

这样问题就解决了，我新建一个bucket，挂上测试域名，然后把文件都下载下来。这样数据就保住了。

一波自信操作

首先我们先从portal上获取ak和sk。

然后使用qrsctl，登录，并获取bucket下面的所有文件。

./qshell_linux_x64 account {ak} {sk} youname@example.com
./qshell_linux_x64 listbucket { bucket_name } | awk -F"\t" '{print $1}' > files.txt

接下来把文件拷贝到新的bucket下面。

./qshell_linux_x64 batchcopy { bucket_name } { new_bucket_name } -i files.txt

此时需要登录portal，获取新的bucket的测试域名。然后填入下载配置文件中。

{
    "dest_dir"  :   "./dest_dir",
    "bucket"    :   "{ new_bucket_name }",
    "cdn_domain" : "{ your_test_domain.clouddn.com }",
    "prefix"    :   "",
    "suffixes"  :   ""
}

最后把文件统统下载下来，大功告成。

./qshell_linux_x64 qdownload qdisk_down.conf

附录：使用Github做图床

Github的Blob文件都是存在S3的，墙外性能还是可以的。对于博客这种轻量使用场景已经足够用了，而且重要的是Github不会搞个智障操作强行锁你数据。

第一步我们需要申请一个”Personal access token”.

然后允许这个token操纵我们的公开repos。注意，这个token非常重要，请不要泄露！

最后我们可以使用这段代码上传图片（或者其它文件）了：

#coding=utf-8
import sys
import base64
import requests
import datetime
import json

fn = sys.argv[1]

with open(fn, 'rb') as f:
    content = base64.b64encode(f.read())

    prefix = datetime.datetime.now().strftime("%y-%m-%d")
    upload_name = fn.split('/')[-1]

    r = requests.put('https://api.github.com/repos/{{ your_id }}/{{ your_repo }}/contents/{{ path_in_repo }}/' + prefix + "/" + upload_name,
            headers = { "Authorization": "token {{ your_token }}" },
            data = json.dumps({ 'message': 'upload data', 'content': content, 'branch': 'master' }))
    info = r.json()
    if 'content' in info:
        print info['content']['download_url']
    else:
        print info

容斥原理以及一些题目

2018-10-14T00:00:00+08:00

什么是容斥原理

容斥原理是一种计数手段。例如在下图中，我们想不重复、不遗漏的求出包含在ABC三个集合中所包含的元素的个数，应该使用怎么样的方法呢？

这个问题对于我们来说并不陌生，当然也并不困难。直观的方法是把所有的元素计数，再把重复的元素排除出去。这种计数的方法，有“容”有“斥”，我们讲其称做“容斥原理”。

容斥原理的应用

小规模的计数问题自然难不倒我们，我们甚至可以使用visit[]数组来记录某元素是否出现。但是当问题的规模增大时，使用数组记录这种方式需要使用更多的内存，在很多情况下，这是我们不能接受的。

考虑一个问题

问题：统计在1~N中的，能被2或3整除的数。(1 <= N <= 1e9)

我们先把这个问题拆成两部分来看：

N以内的，能被2整除的数
N以内的，能被3整除的数

这两个问题都非常简单，我们可以直接使用除法进行求解，其结果分别为N/2和N/3。

与此同时，我们不能忽略同时能被2和3整除的数。这里我们先求得2和3的最小公倍数6，然后应用容斥原理，将重复计数的，能同时被2和3整除的数减去，即得到最后的结果。

一个更复杂的问题（HDU-2204，Eddy的爱好）

给你一个正整数N，确定在1到N之间有多少个可以表示成M^K（K>1)的数。 (1 <= N <=1e18)

这里我们先考虑K=2和3时的情况。对于正整数N，我们有pow(K, 1.0/2)个数可以表示为2^K；有pow(K, 1.0/3)个数可以表示为3^K。这个原理非常简单，这里不做展开。

但是，对于N=64来说，既可以表示为4^3，又可以表示为8^2。那么在上面计数的时候一定出现了重复计数的情况。所以根据容斥原理，我们将所有6的乘方全部排除。

那么对于N=4096的情况，它可以表示为2^12。那么在计数中我们是否需要考虑12的乘方呢？答案是否定的，因为12的乘方一定是6的乘方，这种情况我们已经处理过了，所以不需要再次处理。推而广之，若K可以分解质因数为a^k1 + b^k2 + c^k3，当且仅当k1 == k2 == k3 == 1时，我们才进行计数。

现在我们考虑更普遍的情况，对于任意K，我们先对其进行质因数分解。根据容斥原理，当其质因数的个数为奇数时，我们对其进行计数；为偶数时，我们从计数中排除这种重复情况。

如果我们来出题…

对于容斥原理，如果我们站在出题人的角度，可以将其应用在如下几类“求并集的大小”的（伪）数论问题上：求能被集合中的数整数的数、求能表示为集合中的数的乘方的数、求与给定的数互质的数等。也可以用来配合DP求组合数。

但无论包装成什么样子的题目，如果它的核心是一个计数问题，并且涉及到“求并集的大小”，我们就可以尝试使用容斥原理来求解。

参考链接

实现一个无锁消息队列

2018-05-02T00:39:00+08:00

240414更新：后续补充了一篇勘误文章，见这里

目标

实现一个多读多写的无锁消息队列。

cmpxchg - 比较并替换

比较并替换（compare-and-swap, CAS）是一个用于多线程同步的原子操作。

其工作流程是：

def cmpxchg(val, oldval, newval):
    if val == oldval:
        val = newval
        return True
    return False

也就是说，只有当val等于oldval时，我们才会将val的值替换成newval。在多线程的场景下，cmpxchg用来保证多线程写的原子性。

例如，线程1和线程2都要写入val变量，但是我们需要保证只有一个线程能写成功。使用cmpxchg，能保证只有一个线程能成功的将val变量替换成新值，写失败的线程会得到False的返回值。

ACCESS_ONCE - 消除优化歧义

#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))；

ACCESS_ONCE的作用是将一个指针转化成volatile指针，使得读取操作“真的”去读取指针的值而不被编译器优化掉。

实现

原子操作与Nullable

说到多线程，我们就不能不谈原子操作。对于一个队列来说，我们可以在其中存储任意复杂的数据结构，但是这些数据结构大部分都不支持原子操作。

同样，我们也没有一种有效的手段来标识一个值是“不存在的”。是的，我们可以自己实现一个Nullable<T>的模板，但是带来的额外成本就是对于任意Nullable<T>的赋值都要经过两步以上的中间步骤，这简直就是竞态bug产生的温床。

不过，在C++中自带着一个有着”Nullable”语意的数据结构 —— 指针。当指针为NULL时，意味着值是不存在的，而指针不为NULL时，它代表着它所指向的值。更重要的是，指针的赋值、读取、拷贝都是原子的，这给我们的代码实现提供了非常大的便利。

数据结构

我们使用单链表做为基础数据结构，链表的头代表着队列的头，链表的尾对应着队列的尾。这样添加数据时，我们在TAIL节点处写入，弹出数据时从HEAD节点处弹出。

那么问题来了，在单线程下，维护头尾节点是非常容易的操作。

"""
维护头节点
"""

cur = HEAD.next
HEAD.next = HEAD.next.next # 操作链表

"""
维护尾节点
"""
newnode = Node(value)
TAIL.next = newnode # 操作链表
TAIL = TAIL.next # 操作链表

但是在多线程环境下，维护尾节点需要对链表进行两次操作，我们很难把它做为原子的。这大概是实现无锁队列最大的难点之一。

框架代码

无锁队列中，push和pop两个函数是核心代码。但是我们需要先把框架代码先搭好。

template <typename T>
class NonBlockingQueue {
public:
    NonBlockingQueue() {
        head = &dummy;
        tail = new InnerNode();
        dummy.next = tail;
    }

    void push(const T* item) {
        // pass
    }

    bool pop(T*& item) {
        // pass
    }
private:
    struct InnerNode {
        T* value_ptr;
        InnerNode* next;
    };
private:
    InnerNode dummy;
    InnerNode* head;
    InnerNode* tail;
};

这里的dummy是一个假的头节点，是为了方便节点的插入的，可以替换成一个头节点指针。tail是尾节点，在构造函数里，我们也将其置为一个假的尾节点，注意这里尾节点的设计，后文会再次提到。

出队操作

我们先从最简单的出队操作开始

bool pop(T*& item) {
    InnerNode* cur = NULL;
    do {
        cur = ACCESS_ONCE(head->next);
        if (cur == tail) {
            return false;
        }
    } while (!__sync_bool_compare_and_swap(&(head->next), cur, cur->next));

    item = cur->value_ptr;
    // delete(cur); <- why?
    return true;
}

代码中的__sync_bool_compare_and_swap即上文所说的cmpxchg函数，保证了赋值的原子性。

操作过程非常简单，我们先找到位于队列头的值（HEAD节点后面的第一个）。然后使用CAS操作将其换出链表。

由于tail节点是假的尾节点，所以在head->next == tail时，我们认为队列为空，返回false。

这里有一点需要注意，cur指针在while循环外看似已经脱离了链表，可以放心的删除了。但是由于其它线程仍有可能持有该指针，所以我们并不能在这里对它进行删除操作。

在实际工程中，我们可以将其放置于一个回收队列中，待一小段时间后（如500ms），所有的线程都不持有该指针时，就可以安全的将其回收了。这里由于篇幅原因（注释：懒），就不实现了。

入队操作

void push(const T* item) {
    assert (item != NULL);

    InnerNode* cur = NULL;
    InnerNode* newNode = new InnerNode();

    while (true) {
        cur = ACCESS_ONCE(tail);
        if (__sync_bool_compare_and_swap(&(cur->value_ptr), NULL, item)) {
            cur->next = newNode;
            tail = tail->next;
            break;
        }
    }
}

这里的push操作有一个trick，我们将tail->value_ptr做为“一把锁”。当value_ptr为空时，tail指针代表着一个“假尾节点”。当我们向尾部追加数据时，先将数据写入value_ptr，代表这个节点已经被“占领”。然后再向它的后面追加新的“假尾节点”，最后将指针移动过去。

这样一来，进入if代码块的线程一定是写入tail->value_ptr成功的那一个，后面的指针移动也是单线程的了。

感悟与可能的改进

最近确实好久不写这么底层的代码，手生的厉害，对于多线程状态的分析也不是很灵光。确实需要多努力了。本文中的代码也许还有一些问题，所以欢迎大家指正。

在写这段代码的过程中，感觉有如下需要注意的地方：

析构一块内存是否是安全的，会不会别的线程仍在持有这块内存的指针
编译器会不会给我们捣乱，比如重排指令等
利用CAS的特性，我们可以实现一个锁的结构，但是以哪个变量/指针做为锁可以获得最好的效果

除了用链表实现队列之外，还可以使用环型数组。感觉上来说比使用链表更优雅一点。关键在于环型数组中隐含着前驱指针和后继节点的信息，所以不需要进行复杂的内存管理工作。

完整实现请参考链接，亲测在Ubuntu 16.04下使用g++ main.cc -lpthread编译运行成功。（p.s. 不要加C++11标签，编不过的）

一种区间交问题的奇怪姿势

2018-02-20T22:59:47+08:00

Update[220504]: 原来这种数据结构叫珂朵莉树啊，真神奇。。。

我们要解决什么问题

区间交问题，是我们在做题中经常遇到的问题。

例如，Insert Interval一题，就是比较直白的区间交问题：

给定一系列的整数区间，再插入一个新的区间，问合并后的整数区间是什么

类似的还有Merge Intervals：

给定一系列可能有重叠的整数区间，求合并后的整数区间

另一种区间交问题的描述是时间区间相关的问题，如Time Intersection:

给定用户A和用户B的在线时间区间，问两人同时在线的时间区间

又如经典的会议室安排问题Meeting Rooms和Meeting Rooms II:

给定N个会议的时间区间，问一个人能否参加所有的会议

以及

给定N个会议的时间区间，问最少需要多少个会议室

还有系统设计与API设计包装后的算法题Range Module。归根结底，都是整数区间问题的变形或者包装。

传统解法

对于这类区间问题，传统的解法是将区间使用顺序容器（如vector）保存，在查询和修改时，使用“排序+遍历”或者“排序+二分”。

这种解决在一定程度上是区间问题的通解，但是这样做也有它的问题。

一来区间问题有很多对区间序列进行随机增加、删除，这样的操作对于顺序容器是非常不友好的。

二来对于使用“起点”或“终点”排序的区间，二分查找需要处理很多重复值，在某些情况下会发生复杂度的退化。

那么我们如何优化我们的实现来解决以上的问题呢？

使用`std::set<Interval>`

我们以Merge Intervals一题为例。只要两个区间有交集，无论是哪一种形式的相交，那么我们就需要把这两个区间合并。

所以，我们只需要能高效的判断两个区间是否相交，就可以解决这个问题了。

但是在这里，我们反其道而行之，先来讨论一下不相交的情况。对于两个不相交的区间A和B，只存在两种情况，一是A在B左面，二是A在B右面。

我们可以把区间的左右关系看成不相交区间的顺序关系，即：

如果区间A在区间B的“左边”，我们说A < B
如果区间A在区间B的“右边”，我们说A > B

所以，根据不相交区间的性质，我们可以很自然的将它们存储在std::set<Interval>当中。这样我们就可以在O(logN)时间进行查找、随机插入与随机删除。

那么，回到最开始判断区间是否相交的问题。对于相交的区间A和B，非常明显，A < B与A > B都是不成立的。在std::set<Interval>中，这种关系被判定为相等。

虽然这种相等关系是不符合常规逻辑的，但是却非常实用。如果两个区间有“大小”关系，我们可以知道区间的相对位置。而如果两个区间“相等”，则我们可以知道两个区间一定相交。更重要的是，在这类题目中，两个相交的区间是不能同时存在的。这与std::set<Interval>中元素的唯一性相呼应。

所以，在使用std::set<Interval>来存储区间时，我们可以使用如下的性质：

使用find()函数来查找相交区间。这里要注意，相交的区间可能有多个
使用insert()来插入区间。这里要注意，先要判断是否有区间与新插入的区间相交
使用erase()来删除区间。

实战 - Merge Intervals

在Merge Intervals一题中使用std::set并不是最优的解法。这里只做举例。

题目链接：Merge Intervals

/**
 * Definition for an interval.
 * struct Interval {
 *     int start;
 *     int end;
 *     Interval() : start(0), end(0) {}
 *     Interval(int s, int e) : start(s), end(e) {}
 * };
 */

// overload the comparator for std::set
bool operator < (const Interval& i1, const Interval& i2) {
    return i1.end < i2.start;
}

class Solution {
public:
    vector<Interval> merge(vector<Interval>& intervals) {
        set<Interval> st;
        for (auto interval: intervals) {
            // merge intervals which are overlaped
            while (true) {
                auto iter = st.find(interval);
                if (iter == st.end()) {
                    break;
                };
                interval = {
                    min(interval.start, iter->start),
                    max(interval.end, iter->end)
                };
                st.erase(iter);
            }

            // add the new interval to std::set
            st.insert(interval);
        }

        // copy the intervals to a vector
        vector<Interval> result;
        copy(st.begin(), st.end(), back_inserter(result));
        return result;
    }
};

上面的代码中，std::set<Interval>中存储了已经合并好的区间。当加入新的区间时，我们会先判断新区间是否与已有区间相关，如果相交，则进行合并。

实战 - Range Module

题目链接：Range Module

题意：
设计一个类，提供三个接口：

接口1：void addRange(int left, int right)
将区间[left, right - 1]加入区间集合

接口2：bool queryRange(int left, int right)
查询是否已有区间与区间[left, right - 1]相交

接口3：void removeRange(int left, int right)
移除已有区间内，位于[left, right - 1]范围内的所有数

这个题目看似可以完全套用我们上面讲到的std::set<Interval>的实现，但是这里有几个暗坑需要注意。

首先我们来看接口3，这里的删除并不是删除区间，而是删除整数，所以我们可以使用find()函数，但是与之前的合并操作不同，我们在这里要删除区间中的一部分。

在删除整数操作进行完之后，会引入一个新问题，这就是一些连续的整数区间，会在std::set<Interval>中表现为独立的多个区间。例如，区间[1, 5]，在删除了[2, 3]之后，会形成两个区间[1, 1] 和 [4, 5]。我们再把区间[2, 3]加回来，如果不进行特殊操作，就会产生三个不相交但连续的区间[1, 1]、[2, 3]和[4, 5]。所以我们在插入区间时，要多做一步区间合并的操作。

具体的实现为：

在插入区间[l, r]之前，先查找是不存在区间包含[l - 1, l - 1]或[r + 1, r + 1]。如果有，则先将已有的相邻区间合并的新区间里
将新的区间进行合并操作，插入std::set<Interval>

正确性证明：

已知1：空区间集合不包含不相交但连续的区间
已知2：只有插入操作会产生不相交但连续的区间
归纳假设：我们保证在任何插入新区间的操作之前，std::set<Interval>中均不包含不相交但连续的区间。
证明：

如果区间集合内不包含不相交但连续的区间，那么对于新加区间，我们只需要尝试合并其近邻区间[l - 1, l - 1]和[r + 1, r + 1]，就不会产生不相交但连续的区间。

代码实现如下：

struct MyInterval {
    int left, right;

    bool operator < (const MyInterval& other) const {
        return this->right < other.left;
    }
};

class RangeModule {
public:
    RangeModule() {
        // pass
    }

    void addRange(int left, int right) {
        right -= 1;

        MyInterval ll = {left - 1, left - 1};
        auto liter = st.find(ll);
        if (liter != st.end()) {
            left = liter->left;
        }

        MyInterval rr = {right + 1, right + 1};
        auto riter = st.find(rr);
        if (riter != st.end()) {
            right = riter->right;
        }

        doAddRange(left, right);
    }

    void doAddRange(int left, int right) {
        MyInterval newInterval = {left, right};
        while (true) {
            auto iter = st.find(newInterval);
            if (iter == st.end()) {
                break;
            }
            newInterval.left = min(newInterval.left, iter->left);
            newInterval.right = max(newInterval.right, iter->right);
            st.erase(iter);
        }
        st.insert(newInterval);
    }

    bool queryRange(int left, int right) {        
        right -= 1;
        MyInterval interval = {left, right};
        auto iter = st.find(interval);
        if (iter == st.end()) {
            return false;
        }

        return iter->left <= left && right <= iter->right;
    }

    void removeRange(int left, int right) {
        right -= 1;
        MyInterval newInterval = {left, right};

        while (true) {
            auto iter = st.find(newInterval);
            if (iter == st.end()) {
                break;
            }
            auto cur = *iter;
            st.erase(iter);

            if (cur.left < newInterval.left) {
                st.insert({cur.left, newInterval.left - 1});
            }
            if (cur.right > newInterval.right) {
                st.insert({newInterval.right + 1, cur.right});
            }
        }
    }
private:
    set<MyInterval> st;
};

Bw-Tree：在新硬件平台上的新B-Tree

2017-12-18T00:49:00+08:00

ARS 与 Bw-Tree

nosql数据库从本质上说，都属于ARS（Atomic Record Stores，“原子记录存储”）。

最常见的“原子记录存储”一种实现就是朴素的Hash表：通过一个特定的key，来读写一条独立的数据记录。

一些基于key-value（键-值）模型的nosql的内部实现正是使用了Hash表，例如Redis¹、memcache、Riak等。

而有一些nosql数据库为了支持高效的key-sequential（键-序列）查找，采用了tree-based²数据结构进行数据存储，所以B-Tree成为了一些数据库（both nosql and sql）的首选。

本文介绍了一种基于新型硬件的高性能ARS实现，其核心技术有：

页式内存管理
Bw-Tree，一种基于B-Tree的树存储结构
基于日志的存储管理

在现代硬件上的Bw-Tree

现代多核CPU

多核CPU带来了高并发，但是同时也引入了锁竞争和缓存失效问题。

为了讲解锁竞争，这里我们举一个经典的例子：多线程计数器。

我们都知道，如果不使用锁来保护计数器变量的话，那么最终的结果几乎不可能是正确的。多个线程中，只能有唯一一个线程可以持有锁，其它的线程都需要等待。这样就影响到了程序的并发度。

这里一些高级玩家会提到CAS（compare-and-swap）命令。CAS翻译成中文就是“比较并交换”，用在多线程编程中实现数据交换操作。详情请见：比较并交换

缓存失效产生于两种场景。一是上文提到的锁争用，即每次锁争用都会让当前线程陷入内核态，产生上下文切换，导致CPU缓存的失效。二是缓存一致性协议导致的缓存行失效，即多个CPU在共享一个共同的主存资源时，为了保证缓存中的数据一致性，在主存资源被修改后，相应的缓存行也会失效。

Bw-Tree为了解决以上的问题，使用了以下两个措施。

无锁数据结构
避免了系统阻塞在锁上，更避免了由于锁争用导致的缓存失效以及上下文切换。
增量更新
使用增量更新而不是原地更新，避免修改共享的主存资源，规避缓存一致性产生的缓存失效问题。

现代存储设备

数据库系统的一个重要瓶颈就是IO性能。SSD（固态硬盘）提供了比传统机械硬盘更好的读写性能，虽然表面上缓解了问题，但是IO仍然可能是整个系统的瓶颈。

所以，Bw-Tree使用大内存做为读缓存，同时采用append-only结构保存写信息。因为不论是SSD还是机械硬盘，顺序读写的性能都非常出色。

Bw-Tree的页式存储结构

映射表（Mapping Table）

上文中我们提到了缓存一致性（cache coherance），简单来说，就是当我们修改多个CPU共享的内存资源时，会导致缓存的失效，进而影响指令的执行效率。

Bw-Tree使用页式（paginated）存储管理与映射表解决了这个问题。Bw-Tree以“页”做为存储的单元，每一页都有一个PID。页的物理位置可以存储在主存上，也可以存储在磁盘上。

映射表将PID所代表的映射到页所在的具体物理位置。所以当页的物理位置发生改变时，仍然保持PID一致，不需要对Bw-Tree的结构进行任何修改。

增量修改（Delta Updating）

假设我们现在有数据D，当有修改请求delta到来时，我们可以将数据D原地修改为D'。也可以使用增量更新的方法将其保存为delta + D的形式。

增量更新看起来比原地更新耗费了更多的内存，但其优势也非常明显。一是修改不需要对页加锁，可以使用CAS无锁方法安全的更新共享资源。二是不需要修改页内存，不会导致现有cache失效。

当增量过多时，Bw-Tree会自动合并增量和页内存，这个过程同样是无锁的。

弹性虚拟页（Elastic Virtual Pages）

B+-Tree，图片来源：B+ Trees Visualization

B+-Tree的特性有：

所有记录都在叶子节点（节点也被称为页）上，并且是顺序存放的
每个非叶子节点包含关键字（references）与孩子指针
叶子节点有一个指向左右兄弟的指针，方便顺序遍历数据

Bw-Tree在B+-Tree的基础上添加了：

low/high key，用来标明本节点以及子节点的数据范围
每个节点（包括叶子节点和中间节点）都有一个side pointer指向其右面的兄弟节点

范围查询

由于Bw-Tree的数据都分布在叶子节点，并且叶子节点之间可以通过兄弟指针进行遍历。

我们使用游标（cursor）来标记当前检索的位置。并且使用缓存当前页上符合条件的记录。这样可以加速逐条遍历操作（”next-record” functionality）。

逐条遍历操作是原子的，但是逐条遍历某一段数据则不是原子的。如果读写同时发生在同一页，则我们会根据事务的同步级别来决定是否需要重建检索缓存。

垃圾回收

无锁数据结构导致的一个结果，是我们无法显式的让某个页失效。这意味着，一些线程会持有过时的数据，所以在删除这些过时的数据时要非常小心。

所以这里引入了“代”（epoch）的概念，每一个线程执行每一个操作都在某一个代中，并且这一代中的所有数据以及过时数据都不会被删除。当某一代中所有线程操作都被执行完毕后，这一代就会结束，其中的过时数据就会被安全的回收。

Bw-Tree的结构改变

Bw-Tree的结构会在某些操作下进行改变，以维护其性质。结构改变的操作仍然是无锁的。

为了方便理解，我们假设结构改变的写操作不是并发的。

节点分裂

当某线程发现Bw-Tree中某个节点的大小超出了系统设定的阈值后，在执行完其预定的任务后，就会触发节点的分裂操作。

节点分裂分为两步执行，每一步都是原子的：

子节点分裂
子节点更新后，向上更新父节点

子节点分裂

上图是Bw-Tree中的一部分，现在我们想分裂PQ节点为P和Q两个子节点。即大于某个值KP的数据全部迁移到新节点Q。

节点分裂的操作如下：

先拷贝Q中的数据到一个新的数据页Q'，这一步并不会影响到其它的线程。

在P节点，使用CAS操作，添加分裂的信息Δ，标明该节点已经分裂，其中包含着KP的信息，所以当查询的Key大于KP时，会跳转到新节点Q'进行查询。

父节点更新

同样，父节点的更新仍然是采用增量修改的模式。

我们在父节点使用CAS操作添加一条修改增量（index term delta record）。当查询请求落在Q节点的范围内时，会直接跳转到Q'节点。

更新合并

使用增量更新可以减少数据更新、节点分裂时的时间开销，从而避免失败的分裂操作（failed splits）。

但是最终，我们仍会将产生的更新增量合并成一条完整的记录，以避免过多的空间浪费和指针跳转。

子节点合并

在Bw-Tree数据减少时，我们为了避免过多的指针跳转，需要进行节点合并。节点合并比节点分裂复杂一点，所以需要一系列的原子操作来进行。

删除节点

删除节点时使用标记删除，仍然是CAS操作，添加一个删除增量（remove node delta）到Q。之后所有的读写请求全部转发到其左兄弟P。

这里有个猜测，在Q中原有的数据仍然是要到Q节点进行访问的。论文里没有说，通过常识推断一下应该如此。

合并子节点

在P节点之前用CAS操作添加合并增量（node merge delta）。合并增量将P节点和Q节点从逻辑上合为一个，并且负责转发读写请求。

父节点更新

这个就非常简单，就是CAS操作在父节点标记删除Q节点的Key即可。

序列化结构修改

上面的Bw-Tree结构修改的实现都基于一个假设：数据库的同步机制会处理好数据更新冲突问题。

同步机制包括数据库系统的锁管理器（lock manager）、事务管理组件（transactional component）；或者是采用弃疗方案，允许随机交叉写。

但是在Bw-Tree内部，我们需要序列化树的结构修改（俗称排队）。当一个SMO操作遇到了未完成的SMO操作时，当前线程会等待之前的SMO操作完成后再继续当前操作。

这样的方案可能会形成一个“SMO栈”，但是这种场景比较少见，实现起来也比较简单。

缓存管理

缓存层负责内存与SSD磁盘之间的读、写回以及换页操作。缓存层为Bw-Tree层提供了逻辑页的抽象。

Bw-Tree使用PID访问逻辑页，当逻辑页位于磁盘中时，缓存层先把页读取到内存中，再使用CAS操作将PID指针从磁盘偏移量指向内存偏移量。

预写日志协议与日志序列号（LSN）

日志序列号（LSN）

插入或修改Bw-Tree的增量都会被打上日志序列号。日志序列号由事务子系统产生。

在页的刷写增量（flush delta）中，记录着最后被刷入（flush）磁盘的日志序列号。

事务日志协调

事务子系统维护着一个“最大写入日志序列号”（End of Stable Log, ESL）。事务子系统通过ESL来限制数据管理子系统的持久化进度，也就是说，数据管理子系统只能持久化事务号小于ESL的事务。这保证了预写日志协议的因果性。

数据管理子系统通过向事务子系统反馈最后刷写的事务序号以提供反馈。当事务子系统想要向前移动“事务重做指针”（Redo-Scan-Start-Point, RSSP）时，会向事务子系统发送请求。当事务序号大于RSSP，且小于ESL的所以事务全部刷写到磁盘之后，数据管理子系统会向事务子系统发送ACK信号。最后事务子系统向前移动RSSP，已经落盘的事务信息抛弃。

Bw-Tree的结构修改

我们将Bw-Tree的结构修改（SMO）封装成为一个系统事务。由于Bw-Tree的结构修改是无锁的，所以会有多个线程操作同一页的情况。

将SMO视做事务，允许我们并发的执行SMO操作，当且仅当某一个SMO操作“胜出”时，才将事务提交。

将页写回日志式存储（LSS）

页封装（Page Marshalling）

我们如果要将页写回LSS，首先要先逻辑页转化成线性顺序存储的结构，便于我们将其存储到磁盘。

然后我们要将页的状态设定为“锁定”（captured），以防止后续的修改破坏预写日志协议。

增量刷写（Incremental Flushing）

当刷写页面时，缓存管理器只会刷写ESL之前的数据记录。这样的好处有：

减少磁盘的使用
避免产生过多的磁盘垃圾
避免SSD的写入放大开销

刷写操作

使用双Buffer进行磁盘刷写，可以避免线程等待IO操作。

在刷写操作完成之后，我们会更新mapping table，将页指针改变成磁盘的偏移量。并将内存中的页换出。

缓存管理器会监视系统内存的使用情况，如果内存不够用，就将一部分页从自动内存中换出。

性能

我们的对手

BerkeleyDB

性能良好的独立存储引擎。我们使用C语言实现版本，内置存储引擎为B-Tree。

运行模式为性能较好的“无事务模式”，支持一写多读。

在整个实验中，我们将BerkeleyDB的缓存开到足够大，全部使用主存进行存储与查询操作。

SkipList

无锁的跳表实现。

测试数据集

XBox Live
网游数据。Key的平均大小是94Bytes，Value的平均大小是1.2K。读写比大概是7.5: 1
商业数据库的备份流
总共有27M数据块，去重后有12M。读写比为2.2：1，Key是20Bytes的SHA1哈希值，Value是44Bytes的元信息。
综合KV数据
8Bytes整数Key，8Bytes整数Value。读写比从5：1。

比赛项目

增量链长度阈值对性能的影响

增量链长度阈值影响触发页合并（consolidation）的频率。从图中我们做出如下推测：

增量链长度较短时，读写性能好，但页合并开销大
增量链长度转长时，读写开销大，页合并开销小

系统的整体性能就在这两个因素下面取一个平衡。

无锁环境下的更新失败

数据中我们可以看出，Bw-Tree写入失败（Failed Updates）是非常少的。但是“综合”数据集的“页拆分失败”和“页合并失败”明显高于其它数据集。

这是因为“综合”数据集中的数据都比较小，更新起来比较快，所以会导致比较多的线程竞争。

与传统B-Tree的比较

Bw-Tree明显胜出，其原因有：

Bw-Tree是无锁的，所以并发程度更高
Bw-Tree对CPU cache更加友好

Bw-Tree与无锁跳表比较

Bw-Tree仍然明显胜出，其原因归于Bw-Tree更友好使用了CPU cache。

缓存性能

Bw-Tree的优势有：

与跳表相比不需要过多的指针跳转
内存使用更加高效

后续（201026）

到了新组之后，发现了一个使用BW-Tree的存储引擎。不过已经即将废弃了（挥手

特指Redis的一些主要功能 ↩
tree-based数据结构的一个例子就是图书馆。图书馆用A-Z代表大类，然后使用数字代表小类，最后加上一个数字确定这本书的书号。
图书馆藏书的顺序是按照书号的顺序进行排序的。所以我们在查找一本书的时候，可以使用特定的书号，利用其中的层次信息查找某一本书，也可以根据某一个书号范围进行查找一系列连续的书。
如果还弄不明白的话，可以使用中国图书馆分类法网站加深一下理解。 ↩
图片来源：Wikipedia ↩

Windows Azure Storage Made Simple

2017-10-11T21:12:15+08:00

加机器就是一把梭

没有什么问题是加一千台机器解决不了的，如果有，就再加一千台。
—— 《21天精通分布式系统》

分布式系统在设计之初，是为了解决单机系统的可用性和可扩展性问题的。

举个例子，单机系统就是雇一个小弟替你干活，但是这个小弟不太靠谱，偶尔泡个病号不上班，偶尔工作太多一个人干不过来。

分布式系统就是雇一群小弟帮你干活，偶尔有一两个小弟泡病号，我们会有富裕的人力顶上，工作太多我们可以继续拉新的小弟入伙，美滋滋。

这个比喻很好的描述了单机系统和分布式系统之间的关系。所以一种可能的分布式系统就是这个样子的：

我们将相同功能的服务器组成一个整体，通过一个load balancer对外提供服务。

这样的系统初步解决了我们的问题，在面对可扩展性和可用性的问题时，我们会：

容量不足就加机器
单机挂掉了就把流量调度到其它的节点上

不过单纯的加机器并不能完全满足我们的需要。对于CPU密集型的服务，增加副本数可以有效的均摊计算压力，但是对于存储密集型的服务，我们需要增加分库逻辑才能有效的增加系统的计算能力。

例如我们有100G的数据，但是数据库的容量最多只支持50G。这样无论怎么样增加副本都不能解决问题。如果我们将100G的数据均分，存储在两个50G的分库上，我们就可以支持单机系统容纳不了的数据了。

我们还可以把多个这样的分布式子系统组合起来，就可以组成一个小有规模的分布式系统了。现在我们在使用的一些服务，仍在使用这种模型。

上面分布式模型虽然有效，但是引入了一个严重的问题：因为节点之间是隔离的，并且只能通过消息传递进行通信与协调，所以基本无法完全保证副本之间保持一致的内部状态。

这就是所谓的一致性问题。

补充一点理论知识

CAP理论

CAP理论指的是：

一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本要求，最多只能同时满足其中的两项。

CAP理论由Eric Brewer在2000年首次提出，并且2年后被Seth Gilbert和Nancy Lynch从理论上证明这个理论。

一致性是指数据的多个副本之间保持一致的特性；
可用性是指系统的服务必须一直处于可用的状态;
而分区容错性是指系统在遭遇任何网络分区故障的时候仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障;

抛开一致性问题不谈，“可用性”和“分区容错性”从某种意义上讲是一个分布式系统的“标配”：单机和网络连接并不可靠，从一堆不可靠的硬件上层建立一个不可靠的系统并没有任何意义。

所以一致性常常被牺牲，来保证分布式系统的可用性和分区容错性。

Paxos算法

Paxos是Leslie Lamport在1990年提出的一种基于消息传递且具有高度容错性的一致性算法。

Paxos解决的问题是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。

Paxos的描述和证明有一些复杂，这里不做展开。简单来说，就是系统中的各个节点使用类似于选举投票的算法来达成一致，选举过程中会有短暂的数据不可用中间状态。

“我最讨厌我想做的事情做不成”

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
—— 《从Paxos到ZooKeeper》

无数的理论和实践证明，解决分布式系统的一致性问题是非常困难的。从最直观上来说，我们找不到两片一样的树叶，也找不到两台状态完全一致的分布式节点。

但是前人的智慧是无穷的，我们仍然有以下几种方案来保证数据的一致性：

2PC and 3PC

2PC（Two-phase Commit，两阶段提交）是用来保证分布式系统一致性的一个协议。其流程可以由这个例子来表示：

PM（协调者）: 我要加个需求！（阶段1，提交事务请求）
Dev1（参与者）：你加吧
Dev2（参与者）：你加吧
PM（协调者）：我真加了！（阶段2，执行事务提交）
Dev1（参与者）：加完了
Dev2（参与者）：加完了

注：PM和Dev是程序员老梗而已。各个职业只是分工不同，本质上都是为人民服务。

整个流程看起来很美好，但是我们会遇到如下问题：

同步阻塞
在提交过程中，系统需要等待所有参与者的响应，所以系统整体处于一种阻塞状态，影响效率。
单点问题
协调者是系统的单点，如果当掉，整个系统就处于不可用状态。
数据不一致
一个数据一致性协议会导致数据不一致，确实是非常讽刺的事情。在执行事务提交阶段，如果协调者与参与者的通信中断，可能会导致数据的不一致：
- 当协调者发往部分参与者的Commit消息丢失，没有收到Commit的参与者会因为超时而认为这次请求失败而进行回滚
- 当参与者发往协调者的ACK消息丢失，协调者会认为这次请求失败，但是参与者确实已经Commit了数据

3PC（Three-phace Commit，三阶段提交）是2PC协议的改进版，将整个请求分为三部分：

事务询问
预提交
执行提交

这样的改进减少了同步阻塞的粒度，但是仍然没有解决单点问题和数据不一致的问题。所以2PC和3PC都不是非常理想的数据一致性协议。

Paxos

上文中我们提到Paxos是一种被数学证明过的，具有高度容错性的一致性算法。但是其流程复杂，通信次数较多，并且在提案未被选中之前不能保证数据的可用性。

所以Paxos的应用场景多为命名服务、配置管理、分布式锁等轻量级但是而又非常核心的服务，从而扬长避短，更好的为人民服务，~~更好的反三俗~~。。

Quorum-like Algorithm (Amazon Dynamo)

对于分布式系统的一致性，最直观的解决方案就是在修改节点状态时，将修改广播到所有节点上。这样从理论上讲，就可以保持节点的一致性了。

但是在现实工程当中，广播修改是最不可靠的方案，因为通信可能失败，节点可能失效，我们的修改很有可能不会同步到所有的节点上（假设每个节点的可靠性为99.9%，那么10个节点同时可靠概率只有99%，100个节点同时可靠的概率为90%）。

不过，让所有节点都保持完全一致虽然很完美，但是其付出的代价也许是现有的系统难以承受的。Amazon Dynamo使用了一种类似选举的算法来保证数据的一致性。

设我们有N个节点，我们再指定两个数R和W，使得 R + W > N。在写入数据的时候，我们同时向N个节点写入，当有W个（及以上）节点写入成功，就向客户端返回成功；在读取的时候，我们向R个节点请求数据，此时一定会读到刚刚写入新数据的节点，然后我们将最新的数据返回给用户。

不过这种设计并不完善，当出现网络错误或者大规模节点失效的时候，数据一致性就很难保证了。

我称这种一致性模型为 —— “尽力一致性”。

Event Stream for Eventual Consistency (Apache Kafka)

从Dynamo的经验中我们可以看出，直接将状态的修改广播到不同的节点是不可靠的。那么我们有没有办法解决这个问题呢？

Apache Kafka使用了类似“预写式日志”的方法来保证一致性。当状态修改请求到来时，先写入一条公共的数据流，这条数据流往往是持久化到磁盘的。然后不同的节点再访问数据流，执行同样的状态修改请求，保证节点状态的一致性。

这种设计的缺陷是虽然最终所有节点都会依次执行相同的命令，但是节点执行命令的速度有快有慢，所以在瞬时会有不一致的情况。

这种一致性模型被称为 —— “最终一致性”。

主角登场：Windows Azure Storage

Windows Azure Storage（以下简称WAS）采用了多种一致性算法，在提供较高性能服务的同时，来努力保证存储系统的CAP性质。

其中WAS使用了一些创新性的算法，不过我们还是先从它的整体架构谈起。

Windows Azure Storage的架构

WAS从架构上分为三层，分别是前端（FE Layer），分区层（Partition Layer）和数据流层（Stream Layer）。这三层从功能上各有分工，但是又分别解耦，可以部署在不同的机器上。

下面我们自底向上的讨论一下各层之间的功能与联系。

WAS - 数据流层

数据流包含着各种数据操作，操作包含插入、修改、删除等基本操作，“流”则可以看做是一条无限长的队列。

为什么要使用流结构？

为什么要用流结构呢，原因非常简单，因为流中的操作都是有序的，否则会造成不确定的结果。

例如我们现在有三个操作：

操作1：插入值x=1
操作2：修改该值为x=2
操作3：修改该值为x=5

如果操作是按照顺序来做的话，那么我们获得的值为x=5。但是如果我们将操作2和操作3调换之后，那么我们获得的值为x=2；如果我们将操作1放置在操作2或操作3之后，我们就在修改一个不存在的值，这势必会造成错误。

所以，数据流的有序性保证了操作的“回放一致性”，也就是说，相同的数据流应用在不同的机器上，获得的最终状态是一致的。

同时，由于HDD的顺序读写性能优于随机读写性能。使用流数据结构可以将写入请求顺序化，追加写入磁盘，在廉价的硬件上获得最好的性能。

科普时间：HDD与SSD

HDD指的是Hard Disk Drive，又称Spinning Disk，是计算机使用的一种以磁性碟片存储数据的一种非易失性存储设备（人话就是：断电后不丢数据）。数据存储在同心圆磁道上，工作时碟片会旋转（和CD机一样），磁头会移动到相应的磁道上进行数据的读写（CD机用的是光头）。所以，顺序读写时，HDD的性能会比随机读写要好，因为随机读写带来的大量磁盘寻址会让磁头不断移动，从而拖慢性能。

与此同时，由于碟片内弧的旋转线速度要小于外弧，所以外弧的读写性能会优于内弧。

SSD指的是Solid State Disk，即固态硬盘，也是一种常见的非易失性存储设备。其使用闪存芯片来存储数据。由于其并不像HDD一样需要物理上移动磁头来进行寻址，在顺序写入与HDD或略强于HDD磁盘的同时，随机写入性能要远远强于HDD（这就是为什么我们装电脑都喜欢把系统装到SSD盘上）。

但是SSD在成本和质量上弱于HDD磁盘。1TB的SSD的价格约为400刀，而1TB的HHD价格仅为80~100刀（2017年10月数据）；SSD有写入次数的限制，当闪存芯片损坏时，会影响SSD的性能。相比而言，HDD的技术的性能更稳定，技术更为成熟，质量会更好一些。

数据流的一致性算法

因为要保证可用性，所以数据流必须要是多机的，而多机系统就要面临一致性问题。WAS提出了一种“链式提交”方法来保证了分布式数据流的一致性。

与之前提到的分布式一致性的多机并行的算法不同，WAS在数据流层采用了一种“链式”的提交算法：

当副本1接受到数据后，会首先将数据持久化到磁盘，之后再将相同的请求转发给副本2；
副本2获得数据后，持久化到磁盘，再请请求转发给副本3；
副本3将数据成功持久化后，返回ACK；
副本2接收到副本3的ACK消息后，同样返回ACK；
副本1接收到副本2的ACK消息后，向请求方返回ACK。

这样做的好处是，当数据请求返回ACK后，一定有三个（或以上，根据系统的参数而定）副本同时写入并持久化这条请求。此时三个副本一定是“强一致”的。

不过，如果链式提交当中有任何一个环节出现了问题，比如机器失效、网络超时等，那么我们就要面临数据不一致的情况。WAS为了解决这个问题，引入了被称为“封存”的机制。

封存（sealing）机制

上文说到，数据流是一个无限长的队列，只能在尾部追加写入。所以我们如果想要存储这条数据流，就势必要把这条数据流分为多个节，并把它们分别存储在不同的机器上。否则数据流的大小就要受限于单机的存储容量，这并不是我们想要看到的。

又由于数据流的尾部追加写入特性，所以数据流被分为多个节之后，只有最后一个节是可读写的，其它的所有节都是只读的。

我们将把可读可追加的数据流转化为只读的数据流的操作称为“封存”。

封存的作用之一，就是在数据流的一节过大的时候，停止写入该节，使得数据节的大小可控。

第二个作用，是上面我们提到的，在“链式提交”失败的时候，我们会将所有的数据流副本封存，封存的时候取所有副本的数据的交集。这样就能排除因为写入失败而不一致的数据。

此时有同学会问，如果我们已经成功的写入了三个副本，但是由于网络原因并没能向请求方返回ACK。请求方会认为这段数据写入失败。但是我们在封存的时候，仍然会将这部分数据封存在数据节中。这种情况怎么处理呢？
这个问题后面会有解答，请耐心阅读哦~

数据流层的架构

在前面的文章里，没有提到“数据流管理器”（Stream Manager，简称SM）这个角色。这个角色在整个数据流层扮演了一个很重要的角色。

SM是由一个小型集群使用paxos选举出来的master节点，其它节点备用。SM只用来管理整个数据流的状态，并不负责具体的读写操作。

SM的主要功能有：

统计节点状态
监控节点健康状况
负载均衡
封存、创建新的数据节
备份与垃圾回收

SM管理着一批存储着数据节的节点（Extent Node，简称EN），这些节点存储着数据流中的节。这些节点相互通信，以完成提交、备份等功能。

EN节点中采用了预写入日志。每一次写入操作，EN会并发的

追加写入日志文件，并将新数据写入内存缓存
写入持久化存储

当二者有一个完成，就返回成功标记。这样做的好处是，由于HDD追加写入的性能非常好并且稳定，所以步骤1的响应时间是稳定的并且可以估计的。保证了系统整体的响应时间不出现大的颠簸。

WAS - 分区层

分区层为我们提供了一个被称为“对象表”（Object Table）的抽象。对象表提供了插入、更新、删除功能。

为了提供容量支持，一个对象表会被划分为多个分区（这就是“分区层”名字的来源）。分区之间相互独立，不会互相影响。

对象表构建在数据流层之上。但是从直观上来讲，表结构和流结构是完全不同的，那么分区层是如何将表存储在数据流层的呢？

LSM Tree（Log-Structed Merge-Tree）

段子：
一个学生背着满书包的书进入图书馆，叮叮叮，图书馆的报警器响了，学生赶紧把书从书包倒出来，准备一本一本的验证，看是哪本书有问题。
一旁扫地的阿姨看不下去了，过来把书分成了两挪，先检查第一挪，叮叮叮，报警器响了，说明这一挪有问题，又把这一挪分成两挪，先检查其中一挪，要是哪一挪响了，就把这一挪继续分成两挪，继续检查，不到三回合，大妈就把有问题的哪本书找出来了。
大妈用鄙视的眼神看着那学生，仿佛在说连O（n）跟O（log n）都分不清楚。

我们上文中提到，HDD磁盘可以在较低成本下提供很好的追加写入性能，但是对于随机读写的性能不佳。

但是对于表结构来说，必然涉及到大量的随机读写。因为输入数据就像打乱过的扑克牌，很难保证规律性；而我们又要把特定的输入数据放到特定的行上，所以数据的写入位置必然是随机的。所以，直接在磁盘中存储表结构是非常低效的。

那么LSM Tree是怎么解决问题的呢？

首先我们把已有的数据根据key进行排序，存储在磁盘中，标记第0代。所有写入磁盘的数据都是有序的、只读的。

当有新的数据写入时，我们首先将其缓存在内存中。当数据达到一个阈值时，我们将内存中的数据进行排序，并写入磁盘。这一部分数据被标记为第1代。

之后的数据依次类推，被标记为第2代，第3代…第n代。代数越高，表示数据越新。并且代数高的数据在逻辑上可以覆盖代数低的数据。

在查询时，我们首先检索内存中的缓存数据，如果没有找到，就依次从第n代的数据查询到第0代。如果仍然没有找到，就返回未找到。由于所有的查询都使用二分查找，效率较高。同时我们还可以使用[布隆过滤器][6]，快速判定一个key是否在LSM Tree中。

细心的同学会发现，按照上面描述的算法，LSM Tree的代数会无限膨胀下去，最终导致非常差的的检索效果。在论文中没有明确提到LSM Tree的调教参数，但是我猜测其代数不会太多。并且在冗余数据过多时，会进行垃圾回收，保证检索的效率。
同时这也提醒我们在使用WAS的时候，尽量不要向某一个或某一些连续的分区连续写入大量数据，否则会导致分区层的性能退化。

分区层使用的数据流

分区层使用数据流来保存LSM Tree，使用顺序写入代替随机写入以获得性能提升，这条流被称为“行数据流”（Row Data Stream）。

与此同时，分区层还使用了“二进制数据流”（Blob Data Stream）来保存二进制数据。以及“提交日志流”（Commit Log Stream）来持久化预写入日志。

分区层向数据流层写入时，只有当数据流层返回ACK后，才认为写入成功。所以，在数据流层写入成功，但未能返回ACK时，虽然数据流层保留了数据，但是分区层并不能访问这部分数据，我们就在分区层保证了数据的正确性。

分区层的一致性保证

分区层的持久化信息依赖于数据流层，所以如果分区层使用在线多副本，就会遇到节点状态不一致的问题。也就是说，虽然不同的节点加载了相同的数据，但是加载速度有快有慢，很难保证节点之间以一个同样的状态对外服务。同时，在线多副本的写入会引入竞态，如果再加锁，就会大大的影响系统的效率。

那么WAS是怎么解决这个问题的呢？

答：不能保证一致性就不要一致性。

这样的不要一致性并不是放任节点间的状态不同步，而是每一个分区只使用一个在线服务节点。对于唯一一个节点来说，一致性就是不存在的。（是不是非常暴力）

所以，在同一时间只有一台机器对外提供服务（读+写）。其它的副本是在线备份，在对外提供服务的机器在计划内下线或意外当掉时，就会启用另一台副本对外提供服务。当然这也会造成一致性问题，所以这里牺牲了一点可用性，也就是在旧节点下线后，新节点必须加载完所有的数据才可以对外提供服务。中间的一段时间这个分区是不可用的。

分区层的架构

图中的PS指的就是上文提到的分区服务，每个PS维护着对象表的一个分区，其持久化信息都储存在数据流层上。

PM（Partition Manager）也是使用paxos算法选举出来的master节点，用来管理分区服务的负载均衡、灾备等操作。

Lock Service用来对分区节点进行选举，选出的唯一master节点对外提供服务。

Partion Map Table用来存储与检索分区所对应的节点。

WAS - 前端层

前端层只是薄薄的一层REST API封装，并没有什么其它特殊功能。这里一笔带过。

战胜CAP理论？你他娘的真是个天才！

WAS宣称自己战胜了CAP理论，提供了高可用性和强一致性。WAS能做到这点主要是因为数据流层设计的好。

数据流层使用了只追加写的数据模型，加上链式提交提供的高一致性，所以能应对节点失效（可用性）和网络失效（分区容错性）的故障。

数据流层之上的分区层利用了其特性，很容易的实现了高可用性和分区容错性。同时，又由于其使用单点向外提供服务，所以一致性也有了保障。

所以WAS宣称自己战胜了CAP理论，也不是没有道理。但是个人感觉WAS在分区层的单点设定，是以牺牲可用性（A）换取一致性（C）的一种妥协，只是由于机器故障并非多发，触发问题的机率比较小。

写在后面

本文是《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》一文的读后感，删节了一部分不容易理解的细节。想要更详尽的理解WAS的设计思想，请阅读论文原文以及官方文档。一切内容和理解上的冲突，以原文和官方文档为准。

撰写本文时，我使用Atreus2tap迷之小键盘，在学习前人经验教训的同时，重新学习了打字。

小键盘的好处是便携，以及避免手指移动带来的劳损。缺点是需要精心设计并练习大量的组合键，同时成套的键帽真是不好买。

上一张图。

听说用这种奇怪键盘的人都注孤了。

参考链接

STUP - the Implementation (3)

2017-05-08T22:15:58+08:00

throughput and window size

The wisdom of STUP protocol is all about the window size. The throughput of a TCP communication is limited by two windows: the congestion window and the receive window. The congestion window can determine how many bytes that can be send a simple piece of time, and the receive window indicates the capacity of the receiver to process data.

Both windows influence the throughput of our connection. As the size of receive window is already set after 3-way handshake process, the congestion window is the critical influence. But why?

TCP use congestion control to achieve high performance (really?) and avoid congestion collapse. But here in STUP, we have different situations.

Firstly, we need real high performance. We don’t want the window size cut into half when there is a lost / timeout packet, which is very normal in our “long thin pipe”. Secondly, STUP is not a protocol for general usage, by the initial design, it should be used in an exclusive, non-production environment. So we don’t need to care about our neighbors, we can just use up a reserved, reasonable bandwidth.

However, be aware of the number in Config.py. Our router was down once because of a wrong configuration. :)

other mechanisms and algorithms in STUP

Keep Alive
Nagle algorithm
Piggybacking
Fast retransmission

These features are copied from TCP protocol and absolutely a cliché to have a discuss here. If you have any problem about these, just look it up in Wikipedia.

twisted Twisted Framework

STUP protocol takes me about a whole year to do the development work (and it’s not finished yet). But for more than half of the time, I was struggling with the Twisted framework. For people who want to learn more about Twisted Framework, you can read the official manual or look through this blog for a quick start.

What a pun!

future of STUP

Since STUP protocol is written in Python, one of the main problem is the performance. As a result, I’m planning to rewrite this with C++ (and golang, perhaps) to gain a better performance. I call it: STUPP (STUP in cpp).

In STUPP, several features are to be added:

Selective ACK
Monotonic strictly increasing sequence number to prevent replay attacks
Multiple socks5 connections share a single STUP connection

STUP - Packet Structure and State Machine (2)

2017-05-04T00:53:03+08:00

STUP Packet Structure

Brief Introduction of TCP & UDP Packet Structure

STUP pretend itself as a protocol at the Transmission Layer, but actually it’s absolutely an Application Layer protocol. So before we start, I’d like to recall some knowledge of two important Transmission Layer protocol: TCP & UDP.

It is well known that TCP is a “connection-oriented”, “reliable”, “ordered”. To make an analogy (a little bit inappropriate), TCP is like a phone call (good cell signal strength):

you are keeping a connection
your words and sentences are well-received and well-ordered

As a result, each TCP packet has a unique and ordered sequence number, and your partner has to reply an “ACK” (short of “ACKnowledgement”) when it receive a packet. And it has to keep a connection and control the flow, a lot of control header is added to the header, so as the “window size”.

In a word, TCP is a heavy-weight protocol which offers high reliability. But the performance is highly depend on the network condition.

UDP is on the other way around, it’s “connectionless”, “unreliable” and “unordered”. To make another analogy, UDP is like a SMS message:

there is no connection
there is no guarantee that your partner will receive the message
there is no guarantee of the order of messages, espiecially on a bad network

UDP is a lightweight protocol who doesn’t care about the connection and reliability, it just does it best to serve. And, of course, the performance is better than TCP.

STUP Packet Structure & Why?

As I mentioned before, the only problem for me in TCP is the flow control. But that part is deep in the kernel, it is unnecessarily complicated to hack the kernel, a user application is good enough here for me.

So, I build STUP over UDP to make everything simple. Firstly, UDP is a commonly used and well-known protocol, we can take advantages of existing infrastructure, framwork and libs. Secondly, UDP is lightweighted protocol, the overhead to build a new protocol over it is almost nothing.

The chart above shows STUP packet structure. And the bits in green are plain-text and the others in red are encrypted.

Random IV (16bits): plain text, used to assemble the encrypt key
Version (3 bits): for compatibility use, currently is “000”
Nonce (6 bits): indicate the length of random trail padding data, used for data confusion
URG (1 bit): urgent flag, internal use
LIV (1 bit): keep-alive flag
ACK (1 bit): acknowledgement flag
PSH (1 bit): temporarily prohibit nagle algorithm for this packet
RST (1 bit): reset flag
SYN (1 bit): sync flag
FIN (1 bit): finalize flag
Seq number (32 bits): same as TCP
Ack number (32 bits): same as TCP

The structure of STUP packet is quite similar to TCP packet, because we are imitating TCP, literally.

Data obfuscation of STUP packets

One of the most important part of STUP protocol is obfuscation. We try to hide our intend of the network traffic to bypass the G*W. Except obfuscate the data, we also need to hide some patterns, for example, the handshack process, ack mechanism, etc.

The first step is encryption, of course. It can help us the hide the feature inside data, for example, the pattern of a HTTP request can be easily detected. We use AES-ECB to encrypt the content of our packet.

But why AES-ECB? There are a lot of saying on the internet that AES-ECB sucks, because it leaks plaintext data patterns.

It is because we ecrypt the STUP packet as a whole, it means there is no way to get the sequence number to order the packets before we decrypt it. As a solution, we add a “random IV” as a plain text in the STUP header. So the key to ecrypt is a combination of 48 bits pre-defined key and 16 bits random key. It might lead to a risk of small key space, but actually it’s more than enough to keep out traffic safe as we are not VIP who worth a brute force hacking.

And still, there is another problem that we can’t hide the length information of our packet with a symmetric encryption. The solution is to append random padding bytes at the tail of every packets for data obfuscation, and use the nonce field to mark the length of the paddings, then enrypt it. When receiver get the packets, firstly decrypt the packet, then drop the useless padding bytes and get the real data.

STUP State Machine

STUP state machine is also a simplify TCP state machine. And, in essence, they behave exactly the same.

What’s next?

In next blog (maybe the last one for STUP series), we will talk about some details about the implementation, and future plan for this protocol.

STUP - another (stupid) TCP over UDP protocol (1)

2017-04-20T23:17:45+08:00

What is STUP?

STUP is the abbreviation of “Speeded/Secure Tcp-like Udp Protocol”, which means that it’s another TCP over UDP protocol.

Why TCP over UDP?

TCP is a network protocol for general purpose, and it’s one of the most commonly used internet protocol on this planet. It is reliable, ordered and well optimized with decades of efforts.

But, there’s plenty of reasons to replace that protocol for my scenario.

~~Firstly, create my own network protocol is something geeky-nerdy, yep, suits me perfectly.~~
Firstly, TCP is not “secure” (enough to bypass G*W).
Of course, it’s not TCP’s fault, because the security job is for the application layer. But “大清自有国情在”, we are in urgent need for a secure network protocol to obfuscate our network packet to bypass the firewall to get access to the “free internet”.
Shado*socks is one of the commonly used “secure” network protocol which based on socks5 proxy protocol and TCP. But still, it has its own problem.
Secondly, TCP performs badly on harsh transmission condition.
Because of the flow control and congestion control, the sliding window of TCP will be cut into half when packet is lost or timeout, which is very common on a harsh network connection as the jitter is inevitable.
It’s understandble that TCP has to negotiate the sliding window size with zero knowledge to achieve intra- and inter- protocol fairness, and make a stable network. But for us, we may have enough knowledge for our network, and we may not have too many connections at the same time, so here we don’t need control, we need speed. We come up with our own control mechanism - no control is best the control.

How it works?

Our local application behavess like a socks5 proxy client, and send its data to a local adapter which will translate socks5 packet into STUP packet. The adapter doesn’t need to understand the “meaning” of socks5 packets, it just take it as a byte-flow, then encapsulate the data into the STUP packet.

The local STUP client will encrypt the outgoing UDP packet. More precisely, the job of the encryption is to obfuscate the packet to bypass the detector of the G*W. We will talk about this later.

Then the remote STUP protocol server received the encrypted packet, then it unpack the data and translate it back into the same byte-flow. After that, the socks5 server will get the message and retrieve what we want from the free internet.

In a word, STUP procotol is a secure tunnel between the socks5 client and socks5 server. This design reduces the complexity of the whole system, and make it easy to implement.

How we implement it? (Big picture)

We use Twisted framework to implement our protocol. The good parts of twisted is it hides the details of network programming and turn everything into events. But twisted is aptly named and it is really “twisted”, especially for the new comers.

We implemented our simplfied “TCP stack” with fixed-size sliding window, nagle algorithm, retry mechanism, encrypting, etc. But with the help of Python, one of my favorite programming language … it’s still a complex task to do. And it takes me a year to make it work.

I say thankya.

WorkflowyMd Release Note

2017-01-26T21:07:28+08:00

What is it?

I’ve writen several workflowy enhance plugins by UserScript. The very first one is show the full content of the note of a bullet. The second one is to show images under the bullet. Then I worked on the background image to make a more colorful workflowy.

Yeah, workflowy is a powerful tool for noting and orgainizing your knowledge. And it is FREE! (Say thankee) And the only drawback of this tool is the text format.

In the original version of workflowy (without any plugins), we can only add plain text as note for a bullet. It’s, of course, less expressive than the rich text notes which we’re used to. But now, WorkflowyMd solve that problem.

WorkflowyMd is a suite of usersciprt and stylesheet to enhance the original workflowy with Markdown support. As we know, markdown is one of the most popular lightweight markup language which can create rich text from plain text. We can add headers, images, table, list in the notes, and the original plain text can be fully synced to the server of workflowy.

Here follows the detail and usage of WorkflowyMd.

Markdown support

You have to add [md] tag at the end of the bullet to let the plugin render your markdown note. If you delete the tag, your note will return to the plain text note.

Edit mode

If you want to edit your markdown note. There is no need to type and delete the [md] tag every time. Just double click on the note, the notes will toggle between the markdown style (read-only) and plain text style (editable).

Better image support

There always one annoy stuff about the image - the size. Sometimes the image size is too large for the page, and some oter time we need an image with full size so we can see every details in the image.

Workflowy solve the problem. The image will be displayed in the style max-width: 20% by default. And on a double click, the image will scale to max-width: 100% for us to show the details.

Syntax Highlight

This is the killer feature for this plugin. Syntax highlight! No more explain, let me show you!

Get the code

JS: https://github.com/Wizmann/Utils/blob/master/UserScript/WorkflowyMd.js

CSS: https://github.com/Wizmann/Utils/blob/master/UserScript/WorkflowyMd.css

This plugin might conflict with my previous plugins, and I strongly recommand you to drop the previous versions.

If there are bugs in the plguin, please feel free to contact me. (Or you can fix it yourself, it’s easy)

Thanks

This work based on TamperMonkey and Stylish. These two are both commonly used Chrome extension which are easy to get in Chrome App Store. Also, “Markdown-it” is used here for render the markdown notes and “Highlight.js” is used to highlight the source code. And of course, thanks to jQuery to make everything simple.

Have fun with workflowy and WorkflowyMd!

Special Thanks

Special thanks to Bach and Glenn Gould. :)

Parallel patterns in C#

2017-01-22T22:52:28+08:00

写在前面

与C/C++所使用的，传统的基于线程的并行模式不同，C#实现了丰富的并发编程模型，其中以异步模型最为流行。

本文中我们重点讨论C#在发展过程中出现的几种异步编程模型：

Async Programming Model（APM）
Event-based Async Pattern (EAP)
Task-based Async Pattern（TAP）
async/await语法糖

异步编程入门

同步模式是最常见，也是最被人熟知的编程模型，每一个任务按顺序执行，前一个任务执行完之后才会执行下一个任务。

异步编程和同步编程不同，程序的执行流程是由“事件”所驱动的。异步编程有两种实现方式，回调与future模式。

回调函数在Javascript中被大量使用，相信大家也都不会陌生。但是大量的回调函数会让代码失去可读性，陷入“Callback hell”。

Promise模式是回调函数的一种“包装”。我们使用一个占位符来表示“未来”将会产生的一个异步处理结果。

这个占位符在不同的语言/框架里面有不同的名字，其定义也不尽相同：

Task - C#
Deferred - Python Twisted
Promise - Javascript

在任务结束后，会触发绑定在这个占位符上定义的回调函数，继续预定义好的逻辑。

举个例子，同步模型就是你：

宅家想吃饭 -> 下楼买饭 -> 上楼 -> 吃饭 -> 打游戏看漂亮小姐姐。

而异步模型呢，就是：

宅家想吃饭 -> 手机叫外卖 -> 拿到了外卖定单（拿到占位符或注册回调）-> 打游戏看漂亮小姐姐 -> 外卖小哥把饭送上门（启动回调） -> 吃饭 -> 继续打游戏看漂亮小姐姐。

虽然从上面看，异步模型比同步模型要复杂一些。但是它却节省了耗时的“上下楼买饭”的时间，让你可以分配更多的时间用来看漂亮小姐姐。这和我们写程序时的思路是一致的，节省动辄十几几十毫秒耗时的IO时间，将更多的时间用在CPU上。

Thread Based Parallel

基于线程的并发模型是比较传统的并发模型了，基本上所有的现代编程语言都会支持。C#中Thread的用法与Java类似，这里就不做展开。

与此同时，C#还支持Thread pool，用来运行”long-running processor-bound tasks”。

直接操作线程也许是中年程序员的必修课，但是手动管理线程会给程序带来额外的负担。所以各种模型与框架应运而生，试图降低并发编程的复杂度。

Async Programming Model (APM)

在我们熟悉的async/await语法糖出现之前，C#中使用APM来表示异步操作。虽然这是一种上古时期的回调模式语法，但是现在有很多库仍旧支持这种风格。如Azure Storage SDK中的CloudTable.BeginExecute等一系列函数。

下面是一个简单的使用APM模式的代码范例：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Proxies;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication6
{
    class Program
    {
        public delegate int AsyncInvoke();

        static void Main(string[] args)
        {
            var SI = new AsyncInvoke(MyCall);
            var ar = SI.BeginInvoke(MyCallback, null);

            Console.WriteLine("Main()");
            while (!ar.AsyncWaitHandle.WaitOne(1000))
            {
                Console.WriteLine("Main() waiting...");
            }
            Console.WriteLine("Main() done");

            Console.ReadLine();
        }

        static int MyCall()
        {
            for (int i = 0; i < 5; i++)
            {
                Console.WriteLine("running...");
                Thread.Sleep(500);
            }
            Console.WriteLine("done");
            return 42;
        }

        static void MyCallback(IAsyncResult iResult)
        {
            var result = iResult as AsyncResult;
            var si = (AsyncInvoke) result.AsyncDelegate;
            int ret = si.EndInvoke(result);
            Console.WriteLine(ret);
        }
    }
}

运行结果如下：

我们可以看到：
1. 我们将MyCall()“包装”在一个delegate中，然后调用BeginInvoke函数实现异步执行。这个delegate的执行不会阻塞main thread。
2. 一个异步执行的delegate可以有一个回调，这个回调在delegate执行完后被触发。
3. 我们可以”long-polling”等待一个异步调用执行完。这里的“执行完”不包括条目2提到的回调（小心race condition！）。
4. 异步执行的结果可以通过delegate.EndInvoke(IAsyncResult)函数获取到异步调用的结果。
5. 由条目3我们可以知道，在callback函数中获取异步调用的结果是最合适的。

所以APM风格的代码写起来非常像javascript中的回调写法，如果逻辑复杂的话，维护起来会是一个大坑。

Event Asynchronous Pattern (EAP)

EAP是回调函数的另一种封装。

我们来看下面的代码：

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication2
{
    class StringEventArgs : EventArgs
    {
        public string Content { get; set; }
    }

    class Solution
    {
        private event EventHandler<StringEventArgs> _eventHandler;

        public Solution()
        {
            _eventHandler += Handle1;
            _eventHandler += Handle2;
        }

        public void Run()
        {
            _eventHandler?.Invoke(this, new StringEventArgs()
            {
                Content = "123"
            });
        }

        void Handle1(object sender, StringEventArgs args)
        {
            Console.WriteLine("Handle1 " + args.Content);
            Thread.Sleep(1000);
        }
        void Handle2(object sender, StringEventArgs args)
        {
            Console.WriteLine("Handle2 " + args.Content);
            Thread.Sleep(1000);
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            Solution sol = new Solution();
            sol.Run();
            Console.WriteLine("Done");
            Console.ReadLine();
        }
    }
}

运行结果如下：

我们可以看出，所有的函数都执行在同一个线程上。并且Handle1和Handle2顺序执行。

在实际工程中，我们fire event的代码可以在不同的线程，之后EventHandler，也就是callback函数会被调用。

Event同时支持BeginInvoke和EndInvoke函数，也就意味着我们可以异步的fire相应的回调。但是注意此时我们只能注册唯一的回调，因为BeginInvoke只能有一个目标回调（原理：在同一时间同一线程只能有一个函数调用）。

Task Asynchronous Pattern (TAP)

在.NET 4.0（现在已经到6.0了哦），C#引入了TPL，Task Parallel Library。Task的目标是统一C#中的不同异步编程风格。

TPL中的Task非常像JS中的promise和twisted中的deferred，是“未来会完成的操作的结果”的占位符。

我们来看一段简单代码：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication3
{
    class Program
    {
        static void Main(string[] args)
        {
            Task t = Task.Run(() =>
            {
                Console.WriteLine("Task start");
                Thread.Sleep(2000);
                Console.WriteLine("Task end");
            });

            while (!t.IsCompleted)
            {
                Console.WriteLine("Main(): Task is running...");
                Thread.Sleep(1000);
            }

            Console.WriteLine("Done");
            Console.ReadLine();
        }
    }
}

这段代码我们前面提到的APM和EAP风格的代码有明显的不同，TAP更易读，并且保持了控制流的完整性。不像APM需要在EndInvoke函数中获取返回值以及进行后续操作，也不像EAP一样需要根据不同的event声明不同的回调。

Task也可能“串起来”，实现多级回调的机制。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication4
{
    class Program
    {
        static void Main(string[] args)
        {
            var t0 = Task.Run(() => 0);
            var t1 = t0.ContinueWith((antecedent) =>
            {
                Console.WriteLine(antecedent.Result);
                return antecedent.Result + 1;
            });
            var t2 = t1.ContinueWith((antecedent) =>
            {
                Console.WriteLine(antecedent.Result);
                return antecedent.Result + 1;
            });
            var t3 = t2.ContinueWith((antecedent) =>
            {
                Console.WriteLine(antecedent.Result);
                return antecedent.Result + 1;
            });

            Console.ReadLine();
        }
    }
}

当然我们还可以把回调写成一棵树状结构，然后一层一层的执行，不过生命是如此宝贵，我们并没有充分的理由要这么做。

async/await语法糖

async/await语法糖在C# 5.0中被引入，其目的是为了避免回调带来的代码复杂度。就像Twisted中的@inlineCallbacks一样，省去了defer复杂的回调链。

await中有一个”wait”，说明这是一个“等待”操作。它等待的是相应的Task执行完成。

我们来看一段代码：

private async void DumpWebPageAsync(string uri)
{
    WebClient webClient = new WebClient();
    string page = await webClient.DownloadStringTaskAsync(uri);
    Console.WriteLine(page);
}

当代码执行到await一行时，当前函数会主动放弃当前的控制流。当使用await修饰的Task完成后，当前函数会从之前中断的地方继续执行。

这样做的好处是我们可以写出和同步版本非常相似的异步代码，只需要在必须的地方加上await关键字，提醒编译器这里是一个异步函数，需要额外的处理逻辑，但这一切都是对开发者透明的。

async/await干了什么

想弄清楚async/await到底干了什么，首先我们要想明白线程到底是什么、干了什么。

线程是进程内一条执行流的状态，其中包括了硬件状态（IP、Registers等）以及堆栈（栈上的局部变量和堆上的进程级内存）。那么如果我们想实现挂起/启动（Hibernating and Resuming），那么我们就要有一个机制来保存当前线程的运行状态。

所以当你写下了async/await关键字后，编译器在后面帮助你生成了状态保存和恢复运行上下文的代码。

async/await到底干了什么

想像我们有一个复杂的async函数，里面有很多个await调用，那就意味着这个函数中会有多次挂起/继续操作。同时我们还要维护这个函数的状态。如果我们是这个语法糖的设计者，我们会选择怎么样的手段来处理这个问题呢？

是的，状态机。async/await避免了代码的碎片化，它的解决方案并不是消灭了回调函数和Continuation Tasks，而是使用工具（编译器）来帮助人类进行重复劳动。当async函数从挂起中恢复时，会调用MoveNext函数（相信看过async函数那一长串的traceback的同学肯定对这个函数非常眼熟），MoveNext函数会在async函数第一次被调用以及从挂起中恢复时被调用。状态机保存了当前函数的执行状态，当MoveNext函数被调用时，会根据当前状态来判断接下来执行什么代码。

asycn/await到底TMD干了什么

由于async/awaic语法糖是在编译期才被翻译成相应的程序代码，所以我们只能使用IL反编译器来窥探编译器到底做了怎样的处理与优化。不过反编译器你懂得，生成的代码基本没法看，讲解起来也会非常晦涩。

幸好在99%的情况下，我们并不需要知道async/await是怎样被展开的。如果你确实对这个问题感兴趣，可以参考这篇文章：Async Await and the Generated StateMachine。

几个常见的坑

await 与锁

由于await会中断当前函数在当前线程的执行流，并且可能在恢复时，被指派到另外的线程。所以对await加锁明显是多此一举的。并且如果操作不当，还会造成死锁。

所以我们应该把await放到加锁的区域外。

lock (sync)
{    
    // Prepare for async operation
}

int myNum = await AlexsMethodAsync();

lock (sync)
{    
    // Use result of async operation
}

“There is an … unfired Task between us”

一个async函数如果返回的是Task，那么它返回的一定是一个hot task，即已经被启动了的Task。

并且await只可能等待一个启动了的Task，否则await操作将会hang住，破坏程序既定的执行流。

使用TPL (Task parallel library)

Async methods are synchronous util needed.

如果我们想同时执行几个异步操作，使用for来遍历执行可不是一个好主意。因为这样函数执行流仍然是顺序执行相应的函数。

TPL提供了WhenAll、WhenAny等函数，让我们可以有弹性的并发执行Task。

当然我们还可以使用PLINQ，不过这就是另外一个话题了。

参考链接

Twisted Defer and DeferredQueue

2016-12-10T11:34:38+08:00

写在最前面

这篇文章本来是想用英文写的，但是最近英文水平下降的和狗一样。还是怂一波吧。

写在前面

最近在用Twisted库写一个诡异的项目，具体内容暂且不在这里讨论。在写的过程中，被Twisted里面的一个重要概念 —— defer，折腾的不行。最终通过阅读twisted的部分源码，以及与代码做斗争的丰富经验，最终算是解决了问题。

本文算是使用twisted开发踩坑的一个小小总结，如果一切顺利，后面会有大菜。：）

Twisted介绍

Twisted is an event-driven networking engine written in Python.

Twisted是一个基于事件驱动的网络框架。那么什么是“事件驱动”呢？

事件驱动指的是将事件与事件回调绑定起来，在程序运行时根据实时的事件触发相应的响应的一种机制。

例如select/poll/epoll这些IO复用函数，在文件描述符（fd）可读/可写/出错时，会立即返回，由相应的处理函数来对新事件进行处理。事实上，twisted的事件驱动功能，正是由这些IO复用函数提供的。

但与IO复用函数不同的是，twisted中的事件可以是“更高层次的事件”，即对网络的读/写/错等基础事件进行更进一步的封装。

这里我们以LineReceiver为例（API文档）。LineReceiver是对传输层协议的二次封装，当我们读完一整行之后，就触发lineReceived事件，对获取的数据进行处理。

这种封装，将开发者与底层的网络交互隔离开来。利用这些“高级事件”，开发者可以将更多的精力放到程序本身逻辑的开发之中。

还有一点，正如Python语言本身的一大优点一样，Twisted现成的协议实现的非常丰富，同时在工业界也较为广泛的使用。虽然赶不上golang这种“明星语言”，但是也还是可以“自成一派”，搞点事情。

Defer与回调

Twisted使用Defer来管理callback链，如果你写过js，就可能对被回调链（callback chains）所支配的恐惧记忆深刻。当然，Twisted的defer也并没有好到哪里去。（蛤！）

Seriously，defer允许我们使用一般的顺序型编程模型来编写回调代码。我们只需要把函数按照顺序注册到defer当中，就可以完整的实现一个回调链了。

本文不会对defer进行过多讲解，如果想要了解更多的话，可以参考twisted的官方文档。

defer做为一个回调链的抽象，有一个非常重要的性质，就是你不fire它，它是不会调用它的callbacks的。正像俗话说的一样：

事不说不知，木不钻不透，砂锅不打一辈子不漏

又有人说过（异步发卡）：

A: There’s something between us.
B: What is it?
A: An unfired defer.

如果你想激活defer中的callbacks，就需要手动的fire它。那么什么时候来fire它呢？当然是在需要的时候啦。

一个典型的defer使用场景 - txmongo

txmongo是一个异步的mongodb python sdk。而我们常用的pymongo库则是同步的，所有的请求都要同步等待数据库返回结果。

由于是异步的sdk，所以在同一时间，txmongo会同时持有多个mongodb连接（连接池）。并且由于我们不能预测mongodb的响应时间，所以需要在收到mongodb响应后，启动相应的回调函数，以触发更高级别的消息事件。

# txmongo/protocol.py#L368
def handle_REPLY(self, request):
    if request.response_to in self.__deferreds:
        df = self.__deferreds.pop(request.response_to)
        if request.response_flags & REPLY_QUERY_FAILURE:
            # some error handling code
        else:
            df.callback(request)

我们从这段代码中看出，当txmongo收到响应后，会先从self.__deferreds字典中取出相应的defer，之后使用request做为参数，启动defer中的callbacks，将查到的数据返回给调用者。

新手会遇到的defer坑 —— 测试

做为一个马上就要步入中年的程序员，我最大的一个优点就是不相信自己（汗）。所以在开发时会及时写单元测试来尽可能保证代码的正确性。于是在开发的很早就踩到了defer的坑，包括：

测试hang住
测试通过，但是报错”reactor was unclean”
由于回调没有执行，测试挂掉

坑1比较好解决，defer没有callback，hang住了只能怪自己。不过查哪里hang住了会比较麻烦，最直接的方法是多打log，从log里很容易就知道哪里有问题。

坑2和坑3都属于我们使用defer的姿势不对。defer是“延时”的，我们不能像调用函数一样的直接调用，测试代码需要defer执行完最后一个callback函数后再继续执行。那么我们需要把测试代码也写成callbacks，然后附在需要测试的defer后面吗？

答案是否定的，twisted为我们提供了一个神奇的工具@defer.inlineCallbacks。这个装饰器可以用于开发环境与测试环境。我们可以使用yield等待defer执行完成，并且可以获得defer的返回值。这类似于C#的async/await语法，使用起来非常方便。

所以在我们的测试当中如果使用了defer，就需要将测试case使用inlineCallbacks装饰起来，在等待defer时，需要使用yield语法，等待异步代码的执行。在case的最后，将不需要的defer cancel掉即可。

DeferredQueue与循环

Queue的一个重要用法就是循环。包括线程/进程通信的Queue，BFS中使用的Queue，都是需要循环读取数据。

DeferredQueue是Twisted中通信的一个重要数据结构，其使用方法和一般的Queue从逻辑上是一样的，接口也只有两个：put和get。

DeferredQueue之所以有一个Deferred前辍，是因为它的get函数返回的是一个defer。我们可以在这个defer上绑定callbacks，即有数据可读时，触发相应的回调函数。

所以我们很容易就把代码写成了这样：

q = defer.DeferredQueue()

def get_and_print(item):
    print item
    q.get().addCallback(get_and_print)

q.get().addCallback(get_and_print)

for i in xrange(100):
    q.put(i)

一眼看上去，这个代码没有什么问题，我们会循环的从队列中获取数据并打印。但实际上，这段代码有一个神奇的坑。

说一下这个坑是怎么发现的吧，我把代码写的差不多之后，就想跑benchmark来测性能。然后发现CPython的性能一般，就想试试pypy。然后却怎么也得不到正确的结果，最后发现是因为DeferredQueue引发了递归过深的异常。但是为什么CPython没有这个问题呢。原因在于CPython的递归栈是按深度算的，而pypy的递归栈是按大小算的，但是这两个参数的标量是一样的，所以pypy的递归栈就远小于CPython的。这才暴露了这个问题。不过单纯的扩栈也是不合理的，因为我们很难估计极端情况，并且Python的递归性能非常差。

感兴趣的同学可以去参考源码，这里就直接说结论了。当队列中有元素时，q.get().addCallback(get_and_print)会直接调用get_and_print函数本身，如果队列中的元素非常多，那么我们就有递归过深的危险了。

解决方案也很简单，与其让Twisted把我们的循环写成递归，还不如我们自己实现Queue的循环。至于方法，看看DeferredQueue的内部实现就清楚了，然后我们就发现了另外一个坑。

DeferredQueue与性能

我啥都不说，就贴一行代码：

return succeed(self.pending.pop(0))

您这就是在逗我。

再贴个性能对比，使用list.pop(0)弹出10^5个数据需要2.23s，而使用deque.popleft()只需要0.12s。

不要功能实现了就不管性能了嘛同学。

Mosca源码阅读

2016-11-11T22:04:13+08:00

先在前面

最近心血来潮看了看一个比较有名的开源MQTT broker —— Mosca。不读不知道，读完才恍然大悟 —— 这是啥破玩意（哈哈）。

由于我是nodejs的超级初学者，所以本文会比较浅显，并且只关注big picture，不陷入细节。

这里先规定几个缩写，让后面行文时少打一点字：

MQ - MessageQueue
Asco - Ascoltatori

Ascoltatori - 听者

Ascoltatori是一个意大利语单词，翻译成英文就是listener。

这里严重吐槽作者取名字的方式，mosca这种短小的外语单词我们是可以接受的，你说ascoltatori这么长的意大利语单词，你让我们怎么记。
差评，退款，邮费也要退！

Asco模块的作用是提供一个一致的MQ的抽象，供上层broker使用。

这里我们只分析基于Redis的实现，原因是Redis我相对比较熟悉，功能也比较简单。

接口分析

RedisAscoltatore有三个半接口：

subscribe
unsubscribe
publish

剩下的那半个是模块的构造函数。接下来我们分别分析接口的功能及其实现。

this._sub是RedisAscoltatore用来subscribe的连接。首先我们要向MQ订阅指定的topic。

之后我们要在本地维护一个topic到callbacks的映射关系。因为Mosca是一个broker，需要将end user订阅的topic的内容完整的发送到用户那里去，每一个用户在Asco里，用一个callback函数来代表。

用户可以订阅一个特定的topic，也可以使用一个pattern来订阅一系列的topic。

从图中我们可以看出，右上方的client订阅了h?llo（相当于regex中的h.llo）。右下方的client订阅了h[abcde]llo。而左边的client向hello topic发布了一个消息。此时右边的两个client都收到了这条消息，其中pmessage代表这条消息是有pattern的，第二个参数代表了client订阅的pattern topic，而第三个参数代表了这条消息的实际topic，最后一个参数是消息的正文。

所以我们在维护topic-client列表时，只需要维护pattern topic（没有pattern的topic可以视做只匹配当前topic的patter）。当有消息到来时，我们使用pattern topic映射到clients，之后再进行下一步操作。

这里Asco使用了一个叫做qlobber的库，它使用Trie树对topic进行匹配。我们在上文已经说到，Asco是一个统一化的MQ抽象层，所以在不同的MQ中所使用的不同的pattern，我们都需要将其统一成同一种语法进行匹配。而qlobber，在Asco中被封装成RedisAscoltatore，就是用来统一不同的语法的。

Unsubscribe接口

有订阅就有退订，这个接口与上面的是对应的关系。我们只需要将订阅的顺序反过来做一遍就可以了。这个函数相对简单，就不多说了。

Publish接口

这里的publish，代表是用户的publish的操作。用户数据在“去MQ特色化”之后，会经由this._client发布到相应的redis服务。最后调用用户的callback。

这里再吐一个槽，为啥订阅连接叫this._sub，发布连接叫this._client。难道你不造pub/sub才是真正的对应吗？

构造函数

构造函数虽然说是“半个接口”，但是代码量和重要性，却高于上面的接口。因为redis的pub/sub模型是单工的，需要两个连接才可以完成。所以两条连接需要单独初始化。

this._startPub

我们先从简单的开始。

这个太简单了，没的可说。就是拉一条电话线，成功了之后改一下状态。

没了。

this._startSub

这个比pub要复杂一点。首先，我们还是要拉一条到redis的电话线（连接）。之后注册消息到来时的回调。

我们来看一看这个回调是怎样的流程。

首先还是“去MQ特色化”，将Redis的pattern语法化归成Asco的内部语法。再通过pattern取出相应的callbacks，将消息通过callbacks传递给相应的用户。

这里补充一下，(sub, topic, payload)三个参数如果命名为(pattern, topic, payload)其实会更清晰。

这个类其实原理上并不复杂，但是由于其需要将不同MQ的pattern转换为统一的语法，所以在中间加了一层，导致复杂性的提升。如果我们只做一个专用的broker，代码其实可以写的更明朗的。

Mosca - 苍蝇

与Mosquito相对，Mosca是苍蝇的意思。Mosca是Asco的上层封装，与其一起组成了一个MQTT broker，与end user直接交互。

MQ的单一职责是负责消息的发布/订阅，Mosca在其上添加了：

在线离线状态检测
离线消息的支持
客户端持久化
一些权限检测接口

在这里，我们从Mosca的工作流程出发，主要关注离线消息和客户端持久化这两个broker中非常重要的特性。

持久化

这里我们还是只看Redis的实现。其实Redis并不是真正的持久化，不过who cares。

这里的持久化就包括了离线消息和客户端持久化两个概念。

离线消息使用packet:{client_id}为key进行保存，当用户离线时，broker会将消息先保存在redis中，当用户重新上线时，就将保存好的消息一口气推送过去。

客户端持久化稍微复杂一点。客户端在broker中的状态是其订阅的topic，一般情况下，broker会一直保存用户所订阅的topic，以便保存用户的离线信息。当broker掉电或重启时，我们需要从持久化层将用户的状态重新load到内存。此时，我们使用client:sub:{client_id}为key进行保存。

整体工作流程

在Mosca启动时，先会注册一些事件，比如“用户登录”，“用户下线”，“用户订阅”等。这些消息由配置文件决定是否下发。

这种设计是为了方便broker的scale out，我们可以在一个MQ上面部署多个broker，这些broker通过MQ的$SYS信道进行通信。

当Mosca启动完成后，我们像上面一样，重点关注broker的三个重要事件：

subscribe
publish
unsubscribe

这些事件理论上是Asco的封装，添加了权限控制接口、更复杂的事件，当然还有持久化的支持。例如subscribe事件，除了调用Asco之外，还将用户的这次订阅记录在了持久层里。

publish事件则是先将数据包存放在持久层，再调用Asco的publish函数。unsubscribe也是同样的道理。

补一张结构图

Mosca的可扩展性

根据我浅薄的理解，Mosca是可以支持scale out的。也就是我们可以在同一个MQ（或同一个MQ抽象）上部署多个Mosca，以服务更多的用户。但是一个用户必须严格对应一个shard，否则会出现消息的重复。这个问题可以在Client端解决，但是不应该是一种常态，只应该在用户迁移或者比较大的系统变动的时候才出现。

由于Mosca的持久化层是以Client为Key的，所以不支持多MQ的模式。MQ的扩展需要由MQ自己来完成，对外提供一个统一的抽象即可。不过这种功能，并不被所有MQ所支持。

Disclaimer

真是nodejs小白以及MQ小白，上面说的哪里不对，请帮忙提出来。强烈建议不要以本文中的任何观点不加测试的应用到生产环境当中去。

总结 - phxrpc代码阅读(8)

2016-10-23T15:50:44+08:00

写在前面

这应该是phxrpc代码阅读系列正文的最后一篇。通过阅读代码，发现了自己在知识上的若干不足。

临渊羡鱼，不如退而结网。接下来可能会在网络编程方面再下一点工夫。请大家期待下一个系列吧。

其实真没人读，我就是在骗自己。

先补充一点 - 代码生成

protobuf并不包含RPC的实现，但是它可以声明rpc。客户端和服务端需要实现RPC接口，来实现通信。

phxrpc使用proto文件来定义接口，然后解析并使用代码模板进行生成。

这里我们不讨论代码生成的细节，因为pb实在太过流行，代码生成的方法也有不少的流派。并且用C++来做代码生成，真心不是我的菜。

想了解更多，可以参考这篇博客。

工作流程 - 客户端

客户端与服务器的通信有如下的特点：

连接少
负载少
通信的主动方

所以，所有的网络交互相关的内容可以托管给网络库中的协程。每个协程主动运行一段时间后，主动放弃CPU时间，将控制权交还给主控制流的epoll。

所以协程中不能有CPU密集的运算，幸好面对开发者，phxrpc并不暴露内部函数，而是将CPU密集的运算分配给工作线程来完成。

工作流程 - 服务端

服务器的通信有以下的特点：

连接多
负载多
通信的被动方
响应时间敏感

这里说一下响应时间的问题，响应时间是和负载多对应的。客户端一般只负责发请求，其响应时间并不在整个系统中占主导地位，换句话说，客户端发请求是完全有主动权的。而服务端负责响应请求，需要经过CPU运算，或者有一些服务的级联或扇出操作，所以响应时间是不可控的。

由上面我们可以了解到，服务器端肯定需要与客户端不同的策略来处理连接与响应。

首先，一个独立的线程来同步accept请求，这个线程大部分的时间都block在accept()里，负载比较低。

在accept到fd后，将其压入到调度器中。之后fd会hang在IO循环上，直到有请求到来。与此同时，协程会调度其它的fd。

请求到来后，IO线程会把请求加入队列中，把自己从epoll调度中删除。之后就开始睡觉觉。睡醒了之后，发现响应没到碗里来，就shutdown连接。(我觉得这里应该加入重试，例如三次失败再断线)

如果响应来了，先会调用一个激活fd的操作，将响应放到封装fd的结构体中，再将自己放回到epoll调度，最后顺手给epoll发一个信号。当fd可写时，再把响应返回给客户端。

由于phxrpc使用的通信协议是HTTP，所以不需要考虑分包的问题。

可能的改进

调度器的超时

int nfds = epoll_wait(epoll_fd_, events, max_task_, 4);

这段调度器中的代码，生生的把IO复用模型改成了轮询。猜测这是为了照顾超时定时器，但实际上这个并无必要。我们可以使用timerfd和eventfd来取代定时器。但是这只是一种猜测，这种写法可能也是有性能上的考虑吧。

代码风格

代码风格可能是一个比较泛的问题，但是phxrpc的代码我能明显的感觉到编码风格的不同。以及元素层次不明朗，上下级模块相互耦合的情况。

没有测试！没有测试！没有测试！

因为phxrpc没有测试代码，所以我严重怀疑这就是一个玩票的项目，没有（或暂时没有）在生产环境上运行。

如果有可能的话，请加上性能测试！请加上功能测试！请加上性功能测试！

写在后面

时间仓促，水平有限。写点东西，方便大家学习交流。

如果我写的哪里不对，99%的锅归我傻逼，1%的锅归phxrpc代码没写测试。欢迎大家多做自我批评。

好啦好啦，就到这里吧。

RPC - phxrpc代码阅读(7)

2016-10-22T23:03:36+08:00

前言

看了这么久代码，终于我们要接近phxrpc的核心部分了。

但是出人意料的是，rpc部分并没有过多的概念和magic trick。而且因为ucontext已经被封装好了，所以在rpc里的操作，可以完全按照同步的写法来搞，开发者们不需要切换同步异步的思维模式，就可以在底层的封装之上，做自己想做的事了。

线程安全(?)的队列 - ThreadQueue

我不知道开发者为啥要起ThdQueue这样令人迷惑的名字，这种诡异的命名风格贯穿了整个代码。咋一看这个类是maintain一堆线程的，类似于线程池，但其实这个类就是一个BlockingQueue的实现。

之后，这个队列有三种操作，push、pluck和break_out。push操作不用多说，pluck对应的我们所理解的pop操作，即从队列中弹出元素（pluck这个词貌似是从grpc里面来的，那我就不吐槽了，毕竟Google爸爸）。

更令人疑惑的是break_out这个操作。从代码来看，像是清空队列，并且在dtor中也显式的调用了这个函数。

但是有以下的几个问题。

一，break_out_是一个bool变量，且在不同线程间共享，问题在于这个变量可能被cache住，直接访问可能会造成非预期的结果，可能需要volitaile，或者在pluck函数里加一个mem barrier。

二来，在析构函数中调用break_out_，有可能的一种情况是有其它线程还在pluck函数中，而ThdQueue对象已经被析构了，我们就需要承担这种不安全行为的后果（此处有广告：大铁棍子医院捅主任，张姐去了都说好）。

当然，如果这个函数只在结束进程时使用，其实写的糙一点也无所谓，因为毕竟线上服务是没有“退出”这种状态的。当我们要清空队列时，已经不需要对外提供服务，之后直接kill -9就好，不会触发多线程的坑。不过，这里我觉得应该还是要加小心。

UThreadCaller

这个破类让我看了一小时，分析它的keepalive是怎么实现的。结果发现这个类被没有被调用。

GG。

一个超级文件 - HshaServer

不知道为啥开发者要把这么多文件写一块，拆开不好吗？

DataFlow

DataFlow包含了Request和Response两个Queue，还附加了入队的时间戳和一个args参数指针。

HshaServerStat

一个统计类。会在后台新建一个线程，约每一秒打印一次统计日志。

这个类里有一个技巧，在CallFunc()函数中，每一秒循环一次并没有使用sleep家族的函数，也没有使用select的超时。而是使用了condtional variable。

std::condition_variable::wait_for函数，实质是就是带超时的等待。而这里，在一般状态下，是没有线程会notify的，所以wait_for函数会睡满1s。但是在退出时，会显式的notify统计线程，破坏等待状态，使统计线程退出。

wait_for函数的具体用法，可以参考文档。

下面的HshaServerQos也是一样的思路，Qos即“Quality of service”。

Worker和WorkerPool

这两个类其实是一个和一堆的关系，不过由于这里的诡异的写法，导致一个依赖一堆，一堆调用一个。

WorkerPool是一个全局的线程池，里面有线程（废话），输入输出队列，Disipatcher和调度器。所以Worker要反过来依赖WorkerPool里面的数据。造成了很大的耦合性。

Worker从输入队列中获取信息，并且使用dispatcher进行CPU密集的处理（我觉得dispatcher这个名字起的也有问题）。之后将结果放入输出队列，由后面的HshaServerIO::ActiveSocketFunc驱动协程库进行之后的IO操作。

完成调度器 - HshaServerIO

这个类的主要作用就是补全调度器缺少的函数，并提供了一个IO的工作函数HshaServerIO::IOFunc。

调度器的工作流程前面已经说过了，我们现在就从更具体化的实现上来阅读一下。

HshaServerIO :: AddAcceptedFd，这个函数由外部调用，传入已经accept的fd，之后HshaServerIO::HandlerAcceptedFd将这个fd，和IO工作函数IOFunc一起放入调度器中进行调度。

工作函数IOFunc只负责将请求放入队列，而并不负责从输出队列中取出响应。这个事情由HshaServerIO::ActiveSocketFunc负责。

换句话说，在调度器的工作循环中，epoll_wait中等待的只有在进行IO的两种fd，一是读还没读完的，二是写还没写完的。

进行完CPU操作的fd，由active_socket_func_函数重新激活，向客户端写回响应。所以这个函数应该叫activate_socket_with_resp_func_更合适一些。（至少第一个单词得是个动词好不。）

后面的keepalive的处理也是非常浅显的，这里就不多说了。

多线程IO - HshaServerUnit和HshaServer

前面我们说了不少协程的事，但这并不代表我们不使用多线程带来的红利。或者至少在性能不符合预期的时候，用多线程来tuning一下。

HashServerUnit包装了一组线程，其中包括一个IO线程和若干CPU线程。我们在HshaServer中，还可以配置多个Unit，使得我们有多个IO线程，充分榨干CPU和IO的每一滴汗水。

由于手里也没有测试数据，也就不能更详细的来说配置服务参数的策略。但是无责任猜测，IO线程应该不超过3个。CPU线程数目应该略多于CPU核数。

一个独立的Acceptor

HshaServerAcceptor类相对比较独立，它是用来接受访问请求。是主线程的工作循环。

这里比较奇怪的是，LoopAccept函数设置了CPU亲和性。使得控制线程只在CPU0上运行。

    cpu_set_t mask;
    CPU_ZERO(&mask);
    CPU_SET(0, &mask);
    pid_t thread_id = 0;
    int ret = sched_setaffinity(thread_id, sizeof(mask), &mask);

具体原因有待探讨，可能是和中断亲和性有关。

写在后面

总算囫囵吞枣的把这RPC读完了，其实这里还是有好多疑问的。但是由于phxrpc的文档实在是。。。基本算是没有吧。所以可能还要去Github上提一波Issue。

在学习过程中，真的感觉自己懂的还是太少。简直药丸。

还需要更加努力才好。

非阻塞TCP流和HttpClient - phxrpc代码阅读(6)

2016-10-19T00:03:12+08:00

写在前面

其实这点东西有点鸡肋。因为TCP流在前面已经讲过，难点在于“流”和“流缓冲区”部分。而HttpClient只是TCP流的一个应用，代码不多，且重点在于HTTP协议的调教上面。

不过因为前面有写阻塞TCP流，还是前后呼应，把非阻塞TCP流也小小的讲解一下。顺便饶一段HttpClient的讲解，算是充实一下内容吧。

非阻塞TCP流缓冲区 - `UThreadTcpStreamBuf`

这个其实没啥可讲的，传入一个socket，然后读写分别调用UThreadRecv和UThreadSend，IO复用和协程切换的复杂操作都被封装在里面了。剩下的操作都由基类函数来解决。

非阻塞TCP流 - `UThreadTcpStream`

确实没啥可说的，你们自己去读代码吧。。。

非阻塞TCP流和阻塞TCP流的区别是~~它不阻塞~~，在阻塞TCP流中，我们传入的是一个TCP流，而非阻塞TCP流传入的是一个协程调度器和一个TCP流。

这个很好理解，一个阻塞流自然会占满一个线程的IO和CPU —— 在阻塞流IO读写时，CPU空闲；在CPU忙时，IO空闲。

而非阻塞流会将自己IO wait的时间托管给epoll，把剩下的时间用于CPU计算（和一些overhead上）。所以一个线程可以handle多个socket，协程调度器就是必须的了。之后的读写操作就交由我们前面讨论过的epoll和ucontext协程来共同完成了。

HttpClient

其实这里分析HttpClient的意义不是很大，因为Http毕竟是一个成熟的协议，然后相应的设置含义虽然明确，但是放到相应的上下文中分析比较好。

这篇博文《HTTP协议头部与Keep-Alive模式详解》中有一部分背景知识，感兴趣的同学可以简单了解一下。

在HttpDispatcher中使用的一个小技巧

在http_dispatcher.h文件中，作者使用了一个比较新奇的技巧：“Function Pointers to Member Functions”。

我们来看代码：

typedef int (Dispatcher::*URIFunc_t)(const HttpRequest & request, HttpResponse * response);

这行代码的意思是，为一个参数为(const HttpRequest&, HttpResponse*)且返回值为int的函数声明一个别名URIFunc_t，并且这个函数，一定是Dispatcher类的成员函数。

到目前为止，一切都还是正常的样子，语法也是我们常见的类型。但是下面这种写法，确实是我第一次见。

if (uri_func_map_.end() != iter) {
    ret = (dispatcher_.*iter->second)(request, response);
}

这里的(dispatcher_.*iter->second)，iter->second是从map中拿出来的，在dispatcher_对象中的成员函数的指针。我们使用星号解引用，再把它和dispatcher_对象拼接在一起，像正常调用成员函数一样调用就可以了。

貌似写的有点少，再饶一段吧 - epoll测试服务端/客户端

我们翻篇回到network文件夹下面，看一下test_epoll_[server|client].[h|cpp]文件。

epoll测试客户端

首先，我们读取命令行参数，新建一个调度器，由参数决定调度器的woker协程数量。之后新建UThreadEpollArgs_t，把调度器指针塞进去。再之后把echoclient工作函数和args参数放由调度器中进行调度。

接下来我们看看工作函数echoclient。

工作函数的第一步是申请一个socket fd：

int fd = ::socket(AF_INET, SOCK_STREAM, IPPROTO_IP);

这里我解释一下最后一个参数IPPROTO_IP：

In the in.h file, the comment says: Dummy protocol for TCP.
This constant has the value 0. It’s actually an automatic choice depending on socket type and family.
If you use it, and if the socket type is SOCK_STREAM and the family is AF_INET, then the protocol will automatically be TCP (exactly the same as if you’d used IPPROTO_TCP). Buf if you use IPPROTO_IP together with AF_INET and SOCK_RAW, you will have an error, because the kernel cannot choose a protocol automatically in this case.

这个参数的意义是告诉内核，如果只有一个选项的话，你特么爱用哪个协议就用哪个吧。所以有一些时候，我们会直接把最后一个参数写成0，这就是IPPROTO_IP宏的字面值。

更多信息，可以参考这个问题。

后面的流程非常简单，先接收server发来的欢迎信息，之后ping pong十次，发送“quit”包后结束协程。

epoll测试服务端

服务端和客户端区别不大，主要区别在于客户端在一开始只有一个协程。之后在accept连接时，会主动新建工作协程。

这里解释一下listen(fd, backlog)函数的第二个参数backlog：

backlog意为内核为相应套接字排队的最大连接个数。内核为任何一个给定的监听套接字维护两个队列：

未完成连接队列(incomplete connection queue)
已由某个客户发出并到达服务器，而服务器正在等待完成相应的TCP三路握手过程。这些套接字处于SYN_RCVD状态
已完成连接队列(completed connection queue)
每个已完成TCP三路握手过程的客户对应其中一项。这些套接字处于ESTABLISHED状态

当队列满时，TCP会忽略改分节，但是不发送RST。服务端会期望客户端重发SYN，采用正常的重传机制来处理

队列的真实大小往往比设定backlog值要大一些（~1.5倍）

我们继续看工作函数echoaccept。第一步是新建一个UThreadSocket_t对象，用来监听accept事件。当有新的连接进入时，我们就将新的连接，以及连接所用的工作函数echoserver加入到调度器中。

echoserver函数首先发送一个欢迎信息，之后就和客户端打起乒乓球来，直到客户端发来quit，就结束这个工作协程。

其实这里有一个问题，如果发生了一个字符串拆成两半发的现象，比如第一个包是“blahblahquitq”，之后一个包是“uit”，那么这个协程永远就不会停止了。由于TCP是一个流协议，我们不能保证每一次recv回来的信息都是一个完整的“包”。不做不必要的假设，不给自己找麻烦。

不过因为这里ping pong的消息都比较短，可以强行认为每一个包都包含着一个完整的字符串。当然，这种假设也是无意义的。所以我们要留意phxrpc在真正的生产环境，是怎样处理这种“粘包”的问题的。

写在最后

上一张女神的图：

没啦~

使用epoll驱动ucontext - phxrpc代码阅读(5)

2016-10-17T01:28:40+08:00

用pipe叫醒你 — EpollNotifier

class EpollNotifier类型封装了一个使用pipe传递信号的Notifier类。

Run()函数（其实我觉得叫Register或Activate会更好）首先声明了两个单向的pipe：pipe_fds_，从文档中我们可以知道pipe_fds_[0]是读管道，而pipe_fds_[1]是写管道。这里有一丁点反直觉，就是pipe拿了两个fd，但是仍旧是单工的。

然后将读fd设为O_NONBLOCK以供epoll调度，最后将Func()函数传入scheduler_中。

这里跑个题，想起了当年我大一的时候上过的通信导论的选修课。那会我还没有沉迷代码，还是一个积极乐观好好学习的新时代大学生。自从开始写了代码，人就越来越废物了，连女朋友都找不到了。
年轻人们啊，有饭辙干点啥都行，千万别写码啊。

Func()函数做的事情很简单，就是从管道里尝试poll一段数据，拿到数据后直接扔掉。因为管道里传来的数据并没有实际意义，这样设计的主要意义在于唤醒epoll。

我们可以从Notify()函数中看出，传入管道的是一个字符”a”。

调度器类 — UThreadEpollScheduler

调试器类在初始化时，声明了协程栈的大小以及调试器所调度的最大任务数。不过这个最大任务数是一个“软线”，因为在最新的Linux内核中，epoll使用动态内存管理fd，epoll_create中的size参数已经失去了作用。而后面epoll_wait中的max_event参数只是每次返回的最多event数，也就是如果我们向调度器中加入了超过限制的fd，也不会有什么恶劣的后果。（参考epoll文档和epoll_wait文档）

让人搞不懂的Instance函数

这个函数看起来像一个Singleton的实现，但是明明UThreadEpollScheduler类的构造函数是public的。也就是这个函数像是一个单例，但它又不是一个单例。

在其它的代码中，也没有调用个函数的地方，我觉得这个函数是开发者忘记删了。

远古智慧 — CreateSocket

这个函数其实没啥可说的，算是对UThreadSocket_t构造的封装，但是这里面有一个小技巧，就是calloc的使用。

calloc的作用是向内核申请一段栈空间（和malloc行为一致），然后将这一段内存清0。

个人感觉这样做的目的是防止指针没有初始化带来的一系列诡异的问题。把指针清零，可以让问题在第一时间出现，方便出错时的调试。但是我觉得还是用测试覆盖这种问题已经好，因为空指针在特定的情况下，仍可能是导致诡异行为的源头。

跑 — Run

Run()函数是调度器的核心函数（当然啦），简单来说就是一个循环获取event，用适当的协程处理event。

函数的一开始，先调用ConsumeTodoList()函数，将列表中的协程全部激活，并hang在epoll上。

之后进入一个“死循环”，通过epoll_wait将有数据可读的fd取出，并调用相应的协程进行处理。这里我们看到，epoll_wait的超时时间是写死的4ms，并没有使用next_timeout给出的下次超时时间。这是因为这里支持了“active socket”，即服务器对活动连接操作，例如发送响应甚至新建一个socket。

后面的handler_accepted_fd_func_和active socket是类似的，不过这个函数是用来处理已经建立好的连接，为其分配相应的协程。

所以，由此可见，这个循环即是事件驱动的，又是轮询的。然而这两种模型，居然能写在一个函数里，真是令人印象深刻。

下面的DealwithTimeout函数处理了一下超时的协程，并且更新了next_timeout变量。然而这个变量因为众所周知的原因，并没有什么卵用。

Poll来Poll去 — 一堆epoll函数的封装

UThreadPoll(1)

UThreadPoll函数有两个版本，一个是poll单个socket，另外一个是poll一堆socket。我们先从单个socket的看起。

第一步是注册一个超时时间，第二步将这个socket放到epoll的监听列表上。之后调用yield，把控制权交还给主控制流。

当epoll收到相应的事件时，主控制流会将控制权交还给协程，协程将socket从epoll监听列表中移除，之后进行后面的操作。

整体的工作流可以参考下图。

UThreadPoll(2) - 边缘触发和水平触发

epoll有两种触发模式，边缘触发(edge-trigger, ET)和水平触发(level-trigger, LT)。

简单解释一下epoll的这两种触发模式。ET意味着只要有fd可读或可写，epoll_wait就返回这个fd，而LT意味着当且仅当fd由“不可读变为可读”或由“不可写变为可写”时，epoll_wait才会返回。（这有可能出现所谓的“粘包”现象，详见这里）

第一次听到“粘包”这个词，我一直以为这是啥好吃的。。。

这意味着，当我们使用LT时，我们必须清理干净fd中的数据，即只要可读，就一直读；只要可写，就一直写。否则就会出现问题。

在这里，我们使用的是比较常用的ET模式。并且我们利用了ET的特性实现了“监听多个fd，返回最早响应的那一个”。

首先，我们新建了一个epoll fd（简称内部epoll），将列表中的所有socket放到里面监听。之后将这个socket fd放到list[0]->epollfd所对应的epoll（简称外部epoll，通常是主工作循环的那个epoll）监听列表中。

当列表中的socket有返回时，内部的epoll会返回一个EPOLLIN事件，外部的epoll接收到这个事件后，进行协程切换，回到当前函数中。

下一步我们epoll_wait内部的epoll fd，因为我们确定此时一定有可操作的fd，所以我们将epoll_wait的timeout参数设为0。之后我们将返回的fd的waited_events参数填好，最后返回操作成功的fd的数目。

这个函数比较绕，不过有一个好消息 —— 这个函数也没有被其它地方调用过。不过这种cascaded epoll的技巧确实是让人耳目一新。

延时执行 - UThreadWait

剩下的几个函数基本都是无脑封装，顺着看一遍代码基本就知道是啥意思了。不过UThreadWait这个函数比较有意思，可以用来复习一下uthread + epoll的工作流程。

void UThreadWait(UThreadSocket_t & socket, int timeout_ms) {
    socket.uthread_id = socket.scheduler->GetCurrUThread();
    socket.scheduler->AddTimer(&socket, timeout_ms);
    socket.scheduler->YieldTask();
    socket.scheduler->RemoveTimer(socket.timer_id);
}

首先，获取当前uthread的ID，当我们调用Resume()函数时，让代码知道我们要返回到哪个协程上面。

然后我们向调度器中添加一个定时器。之后Yield()，离开当前协程。

主工作循环运行到超时时间后，会在这个协程打上一个“超时”标签，然后Resume()切换回这个协程上来。

剩下的工作，就交由协程内部绑定的函数来进行处理。

写在最后

在网络编程方面，真心是一个初学者。很多用词可能不恰当，也有一些是自己生造的。大家阅读的时候，尽量以代码和更专业的术语为准。

然后因为在行文中，可能追求了过多的逗比感，对原代码调侃了几句。并没有什么恶意，如果哪里说的不对，欢迎拍砖。

佛祖保佑，永无Bug。

ucontext - phxrpc代码阅读(4)

2016-10-13T23:45:24+08:00

写在前面

国庆假期过半，phxrpc的代码阅读大概要小小告一段落啦。因为这两天还要读工作相关的代码，以及最后几天还有一次短途旅行。

所以非阻塞TCP流可能要留到下一篇了，这一篇只涉及非阻塞TCP流使用到的ucontext协程库，及其使用的一些框架代码。

161013更新：这点破东西写到今天才写完，GG。

什么是ucontext

“Subroutines are special cases of … coroutines.” –Donald Knuth.

首先我们来看一下，什么是线程。线程是进程内一条执行流的状态，包含了硬件状态（硬件计数器，寄存器，条件码等）和堆栈中的数据。

线程通常只有一个入口和一个出口。当线程返回时，线程的生命周期也结束了。所以，通常线程的执行由内核调度。

协程的定义与线程类似，也是硬件状态+堆栈的状态组合。但是与线程不同的是，协程可以有多个出口。可以通过yield来暂停自己，调用其它协程。再次启动时，会从上次挂起的地方继续运行。

phxrpc中的ucontext

phxrpc提供了system和boost两种ucontext的实现，所以提供了一个uthread_context_base的基类。其实在这里我是有一点怀疑虚函数的性能的，不过好在协程的切换以及网络IO操作还是比较耗性能的，所以虚函数多出来的几次内存寻址也并非不能接受。

在这篇文章中，我们只看uthread_context_system这个使用系统ucontext库的实现。

协程上下文：`UThreadContext`

这个类是协程上下文的虚基类，所以代码很少。并且也没有什么好解释的。

void Make(UThreadFunc_t func, void * args)函数是makecontext()的封装。

bool Resume()和bool Yield()是swapcontext的封装。

个人感觉这个类拆分成一个工厂类（传入一个Create仿函数）和一个上下文基类会更清楚一点。

使用系统ucontext库的协程上下文：`UThreadContextSystem`

在phxrpc的文档中，说明使用系统原生的ucontext库的性能要差于boost版本的。但是从数据上来看微乎其微，所以我们先从这个版本看起，力求举一反三。

UThreadContextSystem在构造函数中传入了协程栈大小，协程要执行的函数（及参数），协程执行后的回调，以及调试用的need_stack_protect flag。

每一个上下文对象都维护了两个context，main_context用来表示主程序执行流的上下文，而context_则用来表示协程的上下文。

main_context是static thread_local修饰的，也就意味着这个静态变量在每一个线程中有且只有一个。执行在同一个线程上的不同协程，都会切换/被切换到这个上下文上。

在Resume()函数中，我们激活协程上下文，并将主程序执行流的上下文保存在main_context上。

在Yield()函数中，我们将主程序执行流的上下文激活，将协程上下文保存回context_中。

这里的UThreadFuncWrapper()值得我们特别关注。这个函数包装了我们的工作函数uc->func_，并且将this指针传进去。

传入指针时，这里使用了一个技巧。首先我们将指针强转为uintptr_t，这个是编译器内置的一个typeof，意在将指针类型无损失的转为整型。之后，将一个uintptr_t拆为两个uint32_t。最后，在wrapper函数中，将这两个uint32_t拼回成一个指针类型。

初看这段代码，我们就有这样的疑问：“这特么不是有病么？” 但是，折腾自然有折腾的道理。

When this context is later activated (using setcontext(3) or swapcontext()) the function func is called, and passed the series of integer (int) arguments that follow argc; the caller must specify the number of these arguments in argc.

从官方的文档中我们可以看到，用在setcontext中的函数，只支持int类型的参数，并且需要我们显式声明参数的数目。这里一定要小心，因为变长参数列表并不能有很强的编译期检查支持，搞出UB或core dump来就非常难查。

ucontext中使用的栈内存：`UThreadStackMemory`

ucontext协程是在同一个线程执行多个上下文，所以就要配备多个栈空间。这里的栈大小我们是可以手动管理的，所以我们可以根据程序的实际情况来调整栈大小，以节省内存使用。

内存的申请并不是使用malloc或者new这种比较高层次的内存操作函数，而是使用的mmap。这样的好处是我们可以使用参数控制申请出的内存的权限。

栈内存有两种模式，保护和非保护。保护模式用于调试，会在正常栈内存的两端，各申请一个页大小的保护内存。正常栈内存的权限是读写：PROT_READ | PROT_WRITE，而保护内存的权限是禁止访问：PROT_NONE，也就是说，任何试图访问这块内存的请求，都会触发段错误。

在非保护的运行模式下，栈内存还会使用MAP_ANONYMOUS | MAP_PRIVATE还进行保护。MAP_ANONYMOUS表明这段内存是匿名的，即不占用fd，也无需进行写回操作，使mmap的行为类似于malloc。MAP_PRIVATE意为这段内存不会被其它进程访问，可以使用私有的写时复制映射。（虽然没找到相关资料，但是感觉这两个配置牺牲了可调试性来获取更好的性能）

ucontext的运行时：`UThreadRuntime`

这个类其实很简单，但是由于代码的命名过于意识流，所以很容易把人绕晕。

一个UThreadRuntime代表着一个线程中运行着的N个ucontext上下文。上下文信息保存在std::vector<ContextSlot> context_list_中。

slot是可以复用的，first_done_item_记录着已执行完的context的下标，然后slot中的next_done_item记录着下一个执行完的context的下标。简而言之，这就是类似一个“脏池”的设计。不过这个命名啊，一点都不赛艇。

剩下的代码基本就是UThreadContext的无脑封装了。需要哪个协程开始工作就Resume哪个协程，需要暂停就调用Yield。结束后，调用回调函数，把运行完的协程往脏池一扔，完活。

写在最后

上面我们分析了phxrpc对ucontext协程库的封装，下一篇，我们就来正式看一看ucontext是如何与IO多路复用的技术连接在一起的。

最后上几张皂片：

打造你的专属键盘 — ErgoDone

2016-10-05T21:38:58+08:00

写在前面

低能预警：这是最没有技术含量的一篇博客，无关人员可以撤离。

部分图片来自网络，侵删

这个十一假期，亲手DIY了一把键盘。当然，我只搞定了焊接部分，把不同的组件拼在了一起。

在焊接的过程中，也学习到了一些新知识。写在这里，记录下来。

ErgoDone介绍

ErgoDone是著名开源硬件ErgoDox的中国特色版本，精简了一些硬件以控制成本。总体价格在500RMB左右，是工薪阶级装逼界的一颗新星。

Ergodox的一个版本：

ErgoDone明显就屌丝了许多：

键盘主控

ErgoDone使用了Arduino pro micro做为主控，基中使用了mega32u4做为芯片，提供了模拟USB输入设备的相关函数（包括键盘、鼠标）。网上有许多现成的范例，用这款芯片（以及另一版使用mega32u4的Arduino开发版，Arduino Leonardo）制作体感鼠标（搭配陀螺仪）、游戏摇杆（搭配相关硬件）以及各种专用输入设备。

Arduino pro micro淘宝价不到20块钱，相对来说算是非常超值了。

焊接

由于本人算是菜的抠脚的业余选手，在这个键盘上的主要工作就是焊接。然而，就在焊接这样一件相对简单的工作上，我也是踩了不少坑。

MiniUSB转MicroUSB

在ErgoDone的设计中，整块键盘的供电，都是通过MiniUSB线来完成的。然而，pro micro的接口是MicroUSB的，这里我们需要一个转换工作。

MiniUSB，俗称T口USB。其中有五颗线，代表供电，D+，D-，ID与接地。

MicroUSB就是现在市面上绝大多数安卓手机的充电/数据接口。其中的线序与MiniUSB中的类似，只是多数情况下，我们不使用ID线。

在焊接键盘的过程中，我们需要完成一个自制MicroUSB接口，把导线连接到MicroUSB头上去。这个任务相对难度高一些，不过我们也有偷懒的方式。

因为MicroUSB线实在过于流行，现在无论谁手里都会有那么两三条。那么我们可以拆掉手机充电线的MicroUSB公头，把其中的线引出来，连到应该连的位置上，就可以正常的使用了。

如果你的MicroUSB线是良心厂家出产的话，其中会有四颗线：红绿白黑。

红：供电，5V
绿：Data+
白：Data-
黑：接地

在ErgoDone这里，我们不需要接地线也可以正常工作。然后在焊接的时候要注意线不要留的过长，否则会很难看（不要问我为什么知道）。

一些打磨工作

ErgoDone的两片键盘是通过3.5mm的音频线连接的，然后音频接口不出意料的比外壳预留的接口要厚一些。所以一些打磨工作是必须的。

这里推荐打磨神器 —— 磨刀石。好的磨刀石有粗细两面，方便控制粒度，同时打磨的效率也比较高。如果真的啥都没有，可以强行试一波指甲钳上面的小挫。

卫星轴的安装

可以参考这篇帖子，上面已经说的很好了，我就不重复了。记得重要的一点是要把钢丝入扣，否则可能会卡键什么的。情况允许，还可以加一点润滑脂，让摩擦力小一点。

焊轴

焊轴相对是最简单的一步了，因为焊点的距离足够远，而且也足够大。只是注意别在焊盘上停留太多时间，把焊盘弄掉了就好。

飞线与TDD

这两个放在一起写的原因是因为这两个技术都需要一样工具 —— 万用表。当然这里只是用来测连通性的，所以如果你愿意折腾，自己用发光二级管自己搞一把也不是不可以。

如果我们操作不当，不小心把焊盘搞下来了，有什么方法可以补救呢。答案是飞线，就是不借助电路板上的电路，而是显式的用导线来导通某两个或多个管脚。

ErgoDone由于是对称的两块，所以在焊崩了之后，可以依样找一个可用的焊盘来找可以飞线的焊点。如果手里只有一块板子而且情况不允许的话，就只好在焊之前，尤其是比较高难度的操作之前，先留好plan B，想想万一搞砸了有没有回滚方案（蛤）。

TDD，又称测试驱动开发。就是在焊完一部分之后，立刻进行测试。比如集成电路或者主控，在焊完之后，一定要用万用表确认一下是不是有相临管脚短路的情况。在二极管焊完之后，用镊子测试一下是否可以触发相应的按键。

一个半成品：

对键盘编程

这种DIY键盘的一大好处就是可以自定义配列，通过Fn键做一些很fancy的事情。比如触发组合键，或者是录制一些宏。对于程序员和一些游戏玩家来说，这个功能是非常吸引人的。

我的配列

默认层：http://www.keyboard-layout-editor.com/#/gists/a9278a768f78adf9d7b019b883678390

Fn层：http://www.keyboard-layout-editor.com/#/gists/79ad8e6c4ac70cfad1ed400355e960a7

右手的那堆Fn对应着0~9上面的符号

Vim层：http://www.keyboard-layout-editor.com/#/gists/950dc52b3b27c24601661f2fd43a6d69

模仿vim/bash映射了一些快捷键

魔改层：http://www.keyboard-layout-editor.com/#/gists/8bb13d2439c542a06d99e17fca3a234b

用来魔改/创造一些不存在的键位和组合

食指多出来的四个键分别对应着四种括号<>(){}[]。在编程中会比较常用到。

魔改举例

在食指的扩充键位中，我设计了一个不存在的键位组合：<(和>)。即在默认状态下，输入()；在Shift状态下，输入<>。这种设计并没有直接的解决方案。对于圆括号的输入，我们可以使用组合键宏。而Shift输入尖括号，则需要一些技巧。

幸好之前已经有人提出并解决了类似的问题。简而言之，就是将Shift改成“Fn+Shift”，在按下Shift的同时，切换到一个新的层上。新的层上，我们可以用组合键宏输入尖括号。而剩下的键位，我们将其设置为透明。当你按下其它的键时，与平时按下Shift没有区别。

最终的代码

// Generated by TKG at 2016-10-05 22:35:43

#include "keymap_common.h"

#define KEYMAP_TKG( \
    K0A, K0B, K0C, K0D, K0E, K0F, K0G, K0H, K0I, K0J, K0K, K0L, K0M, K0N, \
    K1A, K1B, K1C, K1D, K1E, K1F, K1G, K1H, K1I, K1J, K1K, K1L, K1M, K1N, \
    K2A, K2B, K2C, K2D, K2E, K2F,           K2I, K2J, K2K, K2L, K2M, K2N, \
    K3A, K3B, K3C, K3D, K3E, K3F, K3G, K3H, K3I, K3J, K3K, K3L, K3M, K3N, \
    K4A, K4B, K4C, K4D, K4E,                     K4J, K4K, K4L, K4M, K4N, \
         K5B, K5C, K5D, K5E, K5F, K5G, K5H, K5I, K5J, K5K, K5L, K5M  \
) { \
    { KC_##K0A, KC_##K0B, KC_##K0C, KC_##K0D, KC_##K0E, KC_##K0F, KC_##K0G, KC_##K0H, KC_##K0I, KC_##K0J, KC_##K0K, KC_##K0L, KC_##K0M, KC_##K0N }, \
    { KC_##K1A, KC_##K1B, KC_##K1C, KC_##K1D, KC_##K1E, KC_##K1F, KC_##K1G, KC_##K1H, KC_##K1I, KC_##K1J, KC_##K1K, KC_##K1L, KC_##K1M, KC_##K1N }, \
    { KC_##K2A, KC_##K2B, KC_##K2C, KC_##K2D, KC_##K2E, KC_##K2F, KC_NO,    KC_NO,    KC_##K2I, KC_##K2J, KC_##K2K, KC_##K2L, KC_##K2M, KC_##K2N }, \
    { KC_##K3A, KC_##K3B, KC_##K3C, KC_##K3D, KC_##K3E, KC_##K3F, KC_##K3G, KC_##K3H, KC_##K3I, KC_##K3J, KC_##K3K, KC_##K3L, KC_##K3M, KC_##K3N }, \
    { KC_##K4A, KC_##K4B, KC_##K4C, KC_##K4D, KC_##K4E, KC_NO,    KC_NO,    KC_NO,    KC_NO,    KC_##K4J, KC_##K4K, KC_##K4L, KC_##K4M, KC_##K4N }, \
    { KC_NO,    KC_##K5B, KC_##K5C, KC_##K5D, KC_##K5E, KC_##K5F, KC_##K5G, KC_##K5H, KC_##K5I, KC_##K5J, KC_##K5K, KC_##K5L, KC_##K5M, KC_NO    }  \
}

#ifdef KEYMAP_SECTION_ENABLE
const uint8_t keymaps[][MATRIX_ROWS][MATRIX_COLS] __attribute__ ((section (".keymap.keymaps"))) = {
#else
const uint8_t keymaps[][MATRIX_ROWS][MATRIX_COLS] PROGMEM = {
#endif
    [0] = KEYMAP_TKG(
        GRV, 1,   2,   3,   4,   5,   HOME,END, 6,   7,   8,   9,   0,   BSPC, \
        TAB, Q,   W,   E,   R,   T,   LBRC,RBRC,Y,   U,   I,   O,   P,   BSLS, \
        ESC, A,   S,   D,   F,   G,             H,   J,   K,   L,   SCLN,QUOT, \
        FN3, Z,   X,   C,   V,   B,   FN7, FN8, N,   M,   COMM,DOT, SLSH,FN3,  \
        LCTL,LGUI,LALT,FN11,DEL,                     MINS,EQL, F10, F11, F12,  \
             LCTL,FN2, SPC, FN4, PSCR,CAPS,FN6, PAUS,FN5, ENT, FN1, LGUI),
    [1] = KEYMAP_TKG(
        TRNS,F1,  F2,  F3,  F4,  F5,  TRNS,TRNS,F6,  F7,  F8,  F9,  F10, DEL,  \
        TRNS,1,   2,   3,   4,   5,   TRNS,TRNS,FN21,FN22,FN23,FN24,FN25,TRNS, \
        TRNS,6,   7,   8,   9,   0,             FN26,FN27,FN28,FN29,FN30,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,                    VOLU,VOLD,MPRV,MPLY,MNXT, \
             TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS),
    [2] = KEYMAP_TKG(
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,END, TRNS,TRNS,TRNS,TRNS,TRNS,PGUP,INS, TRNS,TRNS,TRNS, \
        TRNS,HOME,TRNS,PGDN,TRNS,TRNS,          LEFT,DOWN,UP,  RGHT,TRNS,TRNS, \
        TRNS,TRNS,DEL, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,FIND,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,                    TRNS,TRNS,TRNS,TRNS,TRNS, \
             TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS),
    [3] = KEYMAP_TKG(
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,          TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,FN9, FN10,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,TRNS,TRNS,TRNS,TRNS,                    TRNS,TRNS,TRNS,TRNS,TRNS, \
             TRNS,TRNS,BSPC,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS),
};

#ifdef KEYMAP_SECTION_ENABLE
const uint16_t fn_actions[] __attribute__ ((section (".keymap.fn_actions"))) = {
#else
const uint16_t fn_actions[] PROGMEM = {
#endif
    [1] = ACTION_LAYER_MOMENTARY(1),
    [2] = ACTION_LAYER_MOMENTARY(2),
    [3] = ACTION_LAYER_MODS(3, MOD_LSFT),
    [4] = ACTION_MODS_KEY(MOD_LGUI, KC_SPACE),
    [5] = ACTION_MODS_KEY(MOD_LGUI, KC_TAB),
    [6] = ACTION_LAYER_TOGGLE(1),
    [7] = ACTION_MODS_KEY(MOD_LSFT, KC_9),
    [8] = ACTION_MODS_KEY(MOD_LSFT, KC_0),
    [9] = ACTION_MODS_KEY(MOD_LSFT, KC_COMMA),
    [10] = ACTION_MODS_KEY(MOD_LSFT, KC_DOT),
    [11] = ACTION_MODS(MOD_LCTL | MOD_LSFT | MOD_LALT | MOD_LGUI),
    [21] = ACTION_MODS_KEY(MOD_LSFT, KC_1),
    [22] = ACTION_MODS_KEY(MOD_LSFT, KC_2),
    [23] = ACTION_MODS_KEY(MOD_LSFT, KC_3),
    [24] = ACTION_MODS_KEY(MOD_LSFT, KC_4),
    [25] = ACTION_MODS_KEY(MOD_LSFT, KC_5),
    [26] = ACTION_MODS_KEY(MOD_LSFT, KC_6),
    [27] = ACTION_MODS_KEY(MOD_LSFT, KC_7),
    [28] = ACTION_MODS_KEY(MOD_LSFT, KC_8),
    [29] = ACTION_MODS_KEY(MOD_LSFT, KC_9),
    [30] = ACTION_MODS_KEY(MOD_LSFT, KC_0),
};

成本统计

PCB板 + 外壳 = 220 RMB （已加邮费）
轴 + 平衡栏 + 灯 = 100 RMB （包邮）
键帽 = 119RMB （包邮）
合计：440RMB

总的看来，这个复刻版本，比国外动辄上百刀的版本更有吸引力。不过高大上程度还是略逊一筹。

ErgoDone，让你重新定（学）义（习）打字。

阻塞TCP流 - phxrpc代码阅读(3)

2016-10-03T22:22:14+08:00

写在前面

phxrpc的流（stream和streambuf）与网络访问其实是耦合在一起的，所以本文可以结合着第一篇笔记一起来看。虽然我非常想吐槽这种强耦合性的设计，但是我决定还是好好理解phxrpc的设计之后。。。攒一波大的：）

BlockTcpStreamBuf

class BlockTcpStreamBuf继承自BaseTcpStreamBuf。其中重写了precv和psend两个函数，并且持有了一个文件描述符(file descriptor)：socket_。

precv和psend直接调用了<sys/socket.h>中的recv(2)和send(2)，并没有其它操作。

网络相关的操作，则由class BlockTcpStream来负责。BlockTcpStreamBuf只负责IO部分。

if (BaseTcpUtils::SetNonBlock(sockfd, false)
        && BaseTcpUtils::SetNoDelay(sockfd, true)) {
    stream->Attach(sockfd);
} else {
    phxrpc::log(LOG_ERR, "set nonblock fail");
    error = -1;
    close(sockfd);
}

在BlockTcpStream把fd传递给BlockTcpStreambuf之前，需要把fd设置为block的。而这段代码最大的槽点就是这个SetNonBlock函数，和下面的set nonblock fail日志（想一想）。完全让人摸不到头脑，达到一脸懵逼的最高境界。

由于recv和send函数是block的，所以在读取、写入缓冲区时，如果没有足够的数据可读或没有足够的空间可写，则读取写入操作会阻塞住。

BlockTcpStream

在这里我又想吐个槽了，为啥在这里把TCP Server和Client的工作流混为一谈。我觉得至少应该从命名上区分一下，否则极容易误用。

TCP的工作流程

图片来源：UNIX网络编程卷一：套接字编程 4.2节

从图中我们可以看到，TCP的服务端与客户端的工作流程是不同的，相对来说，客户端的程序要简单一些。

BlockTcpStream中，客户端应用的函数只有BlockTcpUtils::Open，而服务端的BlockTCPUtils::Listen函数包括了bind()和listen()两个操作，而accept()则需要开发者手动调用。

SO_REUSEADDR

在服务端的Listen()函数中，phxrpc使用了SO_REUSEADDR选项，这个选项的意在通知内核：如果端口忙，但是TCP状态位于TIME_WAIT时，可以重用端口。

一个套接字其实是一个（协议，源地址，源端口，目标地址，目标端口）五元组。SO_REUSEADDR意味着我们可以重用源地址和源端口。当然此时的风险在于如果该原套接字发送了一些错误的数据，此时我们的应用程序的TCP工作流就会产生错乱。但是由于TCP的实现中，通过随机的消息序号规避了这个问题，所以这里的风险可以忽略不计。

使用SO_REUSEADDR的好处是，在服务端程序崩溃和退出时（对于一般的服务端程序来说，崩溃和退出是没有区别的），可以立即重启，而不需要等待2MSL时间。

那么我们要问了，为什么在这里我们需要等待2MSL时间呢。

图片来源：Effective TCP/IP 3.8节

TCP拆除连接使用了四次握手的机制，而主动关闭连接的一方在发送完最后一个ACK之后，需要等待2MSL的时间。这就是上面所说的，当服务器重启后，出现Address already in use的报错信息，需要额外等待大约1~4分钟的原因。

究其原因，TIME-WAIT状态的意图在于避免主动关闭连接的一端最后一个ACK发送失败。此时，主机1已经完全关闭，而主机2因为没有收到FIN包的ACK，处于半关闭状态。此时主机2向主机1发送的任何信息（如延迟的ACK包等）都只会收到RST，导致连接的异常关闭。

为了规避这个问题，主动关闭端需要等待2MSL时间。一个MSL是给最后的ACK包，而另外一个MSL，是为了等待被动关闭端重新发送FIN包。如果在TIME_WAIT期间收到了对端的数据包，会刷新TIME_WAIT状态的时间。

参考：Effective TCP/IP 3.8 3.9节

IO复用：Poll

图片来源：UNIX网络编程卷一：套接字编程 6.2节

IO复用是指内核在发现进程指定的一个或多个IO条件就绪，内核就通知进程。通常来讲，常用的IO复用函数有select()和poll()。

当poll()返回后，我们需要遍历其中的fd数组找到可操作的fd。

struct pollfd {
   int   fd;         /* file descriptor */
   short events;     /* requested events */
   short revents;    /* returned events */
};

我们可以从events和revents获得该fd的状态，从而判别可读、可写、超时或出错。

在这里，我们并没有使用poll函数的IO复用能力，而是把它做为另一个阻塞IO调用来使用。

BlockTcpUtils::Open函数中，我们使用了poll，用来监视相应的（一个）fd是否可读。这样一来，我们就隐式（为什么说隐式呢，因为他们一不写文档，二不写注释，一切都是潜规则）规定了C/S交互的基本工作流程：当C/S连接建立后，Server端要先说话，Client端接收到消息之后，才可以进行下面的流程。

Client：“不管你们信不信，是Server先动的手。”

具体为什么先用poll，再把fd设为blocking的，我表示二脸懵逼。在我的实验中，即使把poll删掉，测试代码也是可以work的。可能在后面的代码阅读中，这个问题可以获得解释吧。

和select一样，poll也存在被中断的情况，在phxrpc的代码里，我们给了中断“a second chance”。当poll被中断后，会重新再poll一次；如果这次再被中断，则直接返回TIMEOUT。

// retry again for EINTR
for (int i = 0; i < 2; i++) {
    ret = ::poll(&pfd, 1, timeout_ms);
    if (-1 == ret && EINTR == errno)
        continue;
    break;
}

if (0 == ret)
    errno = ETIMEDOUT;

写在最后

由于这篇文章中的知识点比较杂，写作的顺序也是随机的。所以连贯性不是那么强。如果有什么问题，忍着点吧您就。

忍不了的话。。。那就留言交流吧~

定时器以及其它 - phxrpc阅读笔记(2)

2016-09-29T01:28:09+08:00

写在前面

phxrpc使用了协程(ucontext)和IO复用技术(epoll)来实现网络通信。定时器在其中起到了非常重要的作用。下面我们就来分析一下phxrpc的timer.[h|cpp]中的代码。

system_clock vs steady_clock

system_clock和steadly_clock都是来自<chrono>库，都是用来获取当前时间的。

system_clock用来从系统时钟获取时钟时间(wall clock time)，而steadly_clock获取的是时钟tick，而且保证随着时间的推移，时钟tick数不会变小。

然而实际上，在某些系统下，这两个时钟的实现是一致的。详细信息可以参考这里。

注：在clang++ 4.2.1, g++ 5.4 下实验，这两个时钟是不同的。所以个人认为在这里最好不要做任何无意义的假设。

几毫秒的安睡

void Timer :: MsSleep(const int time_ms) {
    timespec t;
    t.tv_sec = time_ms / 1000;
    t.tv_nsec = (time_ms % 1000) * 1000000;
    int ret = 0;
    do {
        ret = ::nanosleep(&t, &t);
    } while (ret == -1 && errno == EINTR);
}

这里phxrpc使用了nanosleep实现了高精度的sleep。

注意这里的用法，由于nanosleep可能被信号中断，此时errno被设为EINTR。所以我们需要进行额外的判断。当nanosleep被信号中断时，会把剩余时间写入第二个参数指向的timespec变量中，之后我们再次调用nanosleep，就可以把剩余的时间再睡一个回笼觉了。

可删除优先队列

这个设计一颗赛艇啊。

对于std::priority_queue以及大多数手写的优先队列（又称堆，heap）。一般只有top(), push(), pop()这三个操作接口，如果想实现删除操作，大多数情况（为了偷懒）会把std::priority_queue替换为std::set。std::set的内部实现是平衡树（确切的说，红黑树），可以实现获得最大最小值，查找某个值，以及删除某个值的操作。

但是std::priority_queue（或者用数组或vector实现的堆）是顺序容器(sequence containers)，而std::set是关联容器(associative containers)。相对来说，由于cache的原因，顺序容器的性能比关联容器要好。当然我扯得有点远了。对此感兴趣的同学可以去参考《Effective STL》一书。

在这里，我们的需求是这样的：

堆是小根堆，按超时时间增序
堆中的元素是socket描述符UThreadSocket_t
根据描述符，我们可以删除堆中的任意元素

如果我们有清醒的头脑，就会认为这个需求是不好实现的。删除堆中元素并不复杂，只需要将堆中最后一个元素放到被删除元素的位置上，然后再执行一次heap_down()操作就可以了。问题在于我们很难确定某一个元素的具体位置。

想一想，堆中的数据是如何组织的。如果想找到某一个特定的值，除了遍历之外，还有没有其它的方法。

这里phxrpc使用了一种侵入式的手段，将下标写入堆中元素。然后堆外持有指针。然后在维护堆性质的时候，同步更新堆中元素，使其中保存的下标与其在堆中的下标一致。

这样我们就可以通过指针拿到相应元素的下标，删除操作也变得简单了起来。

那么侵入式堆下标有什么问题吗？一来我们对于元素的查找只能根据容器外持有的指针来进行，并不能像std::set那样通过比较关系来查找。二来侵入式下标需要额外的内存空间，对于小型对象会造成可观比例的overhead。同时容器内只能持有元素指针，在某种程度上会带来额外的寻址开销。

不过，这大概也是让堆支持删除的唯一方法了。

小小吐槽

这段代码写的，貌似耦合的太紧了一点。class Timer内部提供的功能有

得到当前时间
nanosleep
封装TimerObj类
维护一个定时器堆，提供top(), push(), pop(), erase()功能，并且大多数操作都是硬编码的

至少在我看来，这并不符合“高内聚，低耦合”代码风格。

你问我为啥不给改改？

因为他们没写测试啊！

补充

其实对于class Timer，phxrpc是有写测试的(test_timer.cpp)。但是这个代码写的就更迷了。这里再分析一下。

一开始，先创建100个timer，sleep时间随机。然后将50个timer放入need_remove数组中。

之后每删一个timer，就配套睡到超时时间pop一个timer。弹出超时timer后，再判断一下时间误差是否超过10ms，如果是，就报错。

这。。。

自定义你的stream buffer - phxrpc阅读笔记(1)

2016-09-28T22:35:55+08:00

写在前面

phxrpc是微信团队开源的一个轻量级RPC框架。

我对RPC这些东西了解不多，看到phxrpc的代码相对简单，而且还在初步开发阶段（在本文写作时，版本号是0.8）。所以想读一读，提高一下姿势水平。

就是这样。

自定义stream buffer

network/socket_stream_base.[h|cpp]中的class BaseTcpStreamBuf继承了std::streambuf，自定义了一个流缓冲区，用于接收/发送TCP数据包。

这个用法比较新颖（或者是我见识少），网上的资料也不多。这里翻译一篇介绍文章，学习一下新姿势。

A beginner’s guide to writing a custom stream buffer

流(streams)是STL中提供的一个重要的抽象概念。著名的“Hello world”程序，便是使用了std::cout将字符串写入标准输出流(stdout)。

流当然可以做比cin/cout更有意思的事。这篇文章我们会研究如何扩展C++流，来实现自定义的流缓冲区(stream buffer)。p.s. 建议本文的读者至少要有基础的C++知识。

C++标准库为磁盘文件操作提供了基础的接口，如std::fstream，std::ifstream和std::ofstream。我们还有stringstream，可以像流一样操作字符串。

std::ostringstream oss;
oss << "Hello, world!\\n";
oss << 123 << '\\n';
std::string s = oss.str();

相似的，我们可以从std::istringstream中使用>>操作符读取数据。

Boost库中的lexical_cast正是使用了这种机制，让用户可以使用统一的方式将一个对象(object)转换为字符串表示。

using boost::lexical_cast;
using std::string;

int x = 5;
string s = lexical_cast<string>(x);
assert(s == "5");

流缓冲区有着很强的灵活性，可以满足不同的“缓冲并传输字符（串）”需求，比如文件操作、字符串操作、命令行(Console)操作等。我们可以从网络、闪存(Flash memory)等不同设备，使用同样的接口获取流式字符串。“流缓冲区”与“流”是正交的，所以我们可以自由的交换、更改(swap and change)流所使用的缓冲区，或者将其重定向到其它地方。我认为C++中的流，正是“策略模式”(strategy design pattern)的一个良好范例。

比如，我们可以重定向标准日志流std::clog到一个字符串流：

#include <iostream>
#include <iomanip>
#include <string>
#include <sstream>

int main()
{
    std::ostringstream oss;

    // Make clog use the buffer from oss
    std::streambuf *former_buff =
        std::clog.rdbuf(oss.rdbuf());

    std::clog << "This will appear in oss!" << std::flush;

    std::cout << oss.str() << '\\n';

    // Give clog back its previous buffer
    std::clog.rdbuf(former_buff);

    return 0;
}

不过，自定义一个流缓冲区却是有一点tricky，或者说有一点吓人，尤其是当你第一次尝试的时候。所以本文意在提供一些流缓冲的实现范例。

首先我们来看一下流缓冲区的一些基本概念。所有的流缓冲区继承自std::streambuf，并且需要覆盖一些虚函数来实现自定义功能。std::streambuf是“顺序读取设备”的一个抽象，即我们可以从中顺序的读取字符序列。在特定的场景下，我们可以重填(re-fill)、冲洗(flush)以及清空(empty)一个缓冲区。

当我们向一个ostream中插入数据时，数据将会被写入缓冲区中的一个数组。当数组上溢(overflow)时，数组中的数据将会被冲洗(flush)到目标接受者，之后这个数组的状态将会重置，以便存储后续的字符。

当我们从一个istream中获取数据时，数据从缓冲区的数组中读出。当数组下溢时(underflow)，没有数据可读，我们会从数据源重新拉取信息来填充缓冲区，之后这个数组的状态也将被重置。

我们使用6个指针，来维护缓冲区的内部状态。输入和输出缓冲各使用3个指针。

维护输出缓冲区的状态

put base pointer
输出基指针，用来指定缓冲区内部数组的第一个元素。可以使用std::streambuf::pbase()来获取
put pointer
输出指针，用来指向内部数组下一个写入的地址。可以使用std::streambuf::pptr()来获取
end put pointer
输出哨兵指针，指向内部数组最后一个再后面一个(one-past-the-last-element)的地址（译注：类似std::vector::end()）。可以使用std::streambuf:epptr()来获取

一般来说，基指针和哨兵指针不会改变，在使用时，以输出指针维护内部状态。

维护输入缓冲区的状态

输入缓冲区和状态维护和输出缓冲区类似，我们有：

end back pointer
输入基指针，指向缓冲区数组内的最后一个字符。可以使用std::streambuf::eback()来获取
get pointer
输入指针，指向缓冲区下一个读取的字符地址。可以使用std::streambuf::gptr()来获取
end get pointer
输入哨兵指针，批号向内部数组最后一个再后面一个(one-past-the-last-element)的地址。可以使用std::streambuf::egptr()来获取

同样，基指针和哨兵指针在流缓冲区的生命周期中也不会改变。

由于输入缓冲区要支持putback()操作，即将读出的字符重新放回缓冲区，所以输入缓冲区比输出缓冲区更复杂一点。通常来说，putback()操作支持放回一个字符即可。

一个std::streambuf可以同时支持输入输出两种操作，所以我们不需要我分别实现std::istreambuf和std::ostreambuf。std::fstream是一个良好的例子。但是，实现一个全功能的缓冲区相对更复杂一些，所以我就不趟浑水啦~ ：）

同时，流缓冲区也可以支持宽字符(wide character)。std::streambuf是std::basic_streambuf<char>的别名，如果你需要宽字符流缓冲区，可以使用std::basic_streambuf<wchar_t>。

例1：文件缓冲区 —— 与C代码集成

假设我们需要调用一个历史悠久的库，一个文件操作函数会返回给一个FILE*指针，但是我们想用C++的流接口来读写数据。我们先从读文件开始，用std::istream包装FILE*的读操作。

#include <streambuf>
#include <vector>
#include <cstdlib>
#include <cstdio>

class FILE_buffer : public std::streambuf
{
    public:
        explicit FILE_buffer(FILE *fptr, std::size_t buff_sz = 256, std::size_t put_back = 8);

    private:
        // overrides base class underflow()
        int_type underflow();

        // copy ctor and assignment not implemented;
        // copying not allowed
        FILE_buffer(const FILE_buffer &);
        FILE_buffer &operator= (const FILE_buffer &);

    private:
        FILE *fptr_;
        const std::size_t put_back_;
        std::vector<char> buffer_;
};

由于功能简单，我们只需要实现构造函数以及underflow接口就可以实现我们的功能。

构造函数指定了读取文件的FILE*指针，以及内部缓冲数组的大小。数组大小由两个参数决定：
* put-back area size
* buffer size

我们使用std::vector<char>做为缓冲区域。put_back_变量用于存储”put-back”区域的大小。

以下是构造函数的实现：

using std::size_t;

FILE_buffer::FILE_buffer(FILE *fptr, size_t buff_sz, size_t put_back) :
    fptr_(fptr),
    put_back_(std::max(put_back, size_t(1))),
    buffer_(std::max(buff_sz, put_back_) + put_back_)
{
    char *end = &buffer_.front() + buffer_.size();
    setg(end, end, end);
}

在初始化列表中，我们将缓冲区的常量进行赋值。之后使用std::streambuf::setg()来初始化输出缓冲区。

setg()的三个参数分别代表eback()，gptr()，egptr()三个内部指针的值。一开始，我们将它们都指向同一个地址。表明buffer是空的，在下一次读取时，会重新填充缓冲区。

underflow()会返回数据源中当前的字符。一般来说，会返回buffer中的下一个可用字符。然后当buffer为空时，underflow()应该重新填充缓冲区数组，在本例中，即从FILE*中读取字符。当缓冲区重填后，我们需要再次调用setg()更新流缓冲区的状态。

当数据源中的数据读完(depleted)后，underflow()会返回一个traits_type::eof()。这里要注意，underflow()的返回值是int_type，这个值足够装下eof()，同时也足够装下任何的字符。

std::streambuf::int_type FILE_buffer::underflow()
{
    if (gptr() < egptr()) // buffer not exhausted
        return traits_type::to_int_type(*gptr());

    char *base = &buffer_.front();
    char *start = base;

    if (eback() == base) // true when this isn't the first fill
    {
        // Make arrangements for putback characters
        std::memmove(base, egptr() - put_back_, put_back_);
        start += put_back_;
    }

    // start is now the start of the buffer, proper.
    // Read from fptr_ in to the provided buffer
    size_t n = std::fread(start, 1, buffer_.size() - (start - base), fptr_);
    if (n == 0)
        return traits_type::eof();

    // Set buffer pointers
    setg(base, start, start + n);

    return traits_type::to_int_type(*gptr());
}

函数的第一行，首先判断buffer是否耗尽。如果否，则返回当前字符，即*gptr()。如果是，则进行重填(re-fill)操作。

回想一下我们在构造函数中的实现，三个状态指针全都指向缓冲区的末尾。如果我们调用underflow()时，发现状态指针并非如此，则说明缓冲区已经被填充了至少一次。

现在我们考虑重填操作，我们memmove最后put_back_个字符到buffer的末尾，用做”put-back area”。（我们不用memcopy因为我们的buffer比较小，`memmove()的效率会更高一些）

译注：实际上，memcopy与memmove各有所长。memcopy不需要判断内存overlap的情况，即如果源区间与目标区间有重叠，那么得到的结果会是错的。而memmove由于是移动语义，所以在移动步长较小时，可以只操作cache。所以二者各有所长，要根据具体情况判断优劣。Stackoverflow上有更详细的讨论

我们处理完”put-back area”之后，就可以使用fread()函数来重填缓冲区了。如果读不到数据，则意味着文件已经读到了结尾（当然这是一种简化情况，但在现实中99.9%的读取失败都是因为文件结束）。

在fread()成功读取数据之后，我们通知streambuf更新内部的三个状态指针。之后返回buffer当前的指针。

这就是我们的流缓冲区的基本实现，希望这并不是太难。当然我们还可以添加更多的功能。特别的是我们可以在缓冲区里面进行查找。如果你想实现它的话，可以试试重写std::streambuf::seekoff()和std::streambuf::seekpos虚成员函数。

我们也可以实现写缓冲区。不过，在你们读完第三个例子之后，你们就可以轻松愉快的实现自己的版本了，不骗你。

例2：读取内存中的数组

本例中，我们要使用std::istream包装内存中的一个只读数组，并且格式化的进行读入。这个例子和上一个例子有一点不同的是，我们并不需要一个真正的缓冲数组，从源数组一次性读取就好了。

想象中的实现是这个样式儿的：

class char_array_buffer : public std::streambuf
{
    public:
        char_array_buffer(const char *begin, const char *end)
        {
            setg(begin, begin, end);
        }

        int_type underflow()
        {
            return  gptr() == egptr() ?
                    traits_type::eof() :
                    traits_type::to_int_type(*gptr());
        }
};

但是，这并没有什么卵用。因为setg()函数只接受非常量(non-const)指针参数。这显而易见，如果一个缓冲区不可写，我们就不能提供”put-back”功能。所以我们要动一动手脚，重新实现一下这个类。

#include <streambuf>

class char_array_buffer : public std::streambuf
{
    public:
        char_array_buffer(const char *begin, const char *end);
        explicit char_array_buffer(const char *str);

    private:
        int_type underflow();
        int_type uflow();
        int_type pbackfail(int_type ch);
        std::streamsize showmanyc();

        // copy ctor and assignment not implemented;
        // copying not allowed
        char_array_buffer(const char_array_buffer &);
        char_array_buffer &operator= (const char_array_buffer &);

    private:
        const char * const begin_;
        const char * const end_;
        const char * current_;
};

在这个版本中，我们重写了几个私有函数，这些函数都是从std::streambuf继承而来。

第一个构造函数需要用户指定起止指针，而第二个构造函数只需要指定起始指针，之后我们会调用std::strlen()来判断字符串的大小。

我们使用uflow(), pbackfail()和showmanyc()来维护缓冲区内部的状态，而不是调用setg()，因为buffer并不可写。

在这个版本中，我们要手动维护eback, gptr, egptr三个指针。在构造函数中，我们将对其进行赋值。

#include "char_array_buffer.hpp"

#include <functional>
#include <cassert>
#include <cstring>

char_array_buffer::char_array_buffer(const char *begin, const char *end) :
    begin_(begin),
    end_(end),
    current_(begin_)
{
    assert(std::less_equal<const char *>()(begin_, end_));
}

char_array_buffer::char_array_buffer(const char *str) :
    begin_(str),
    end_(begin_ + std::strlen(str)),
    current_(begin_)
{
}

之前我们使用underflow()来获取当前字符，但这次我们需要使用uflow()。因为uflow()需要同时执行两步操作，一是获取当前字符，二是让gptr()前进一步。但是又因为缓冲区由我们手动管理，std::streambuf并不能正确的执行管理操作。所以我们需要重写uflow()而不是underflow()。

char_array_buffer::int_type char_array_buffer::uflow()
{
    if (current_ == end_)
        return traits_type::eof();

    return traits_type::to_int_type(*current_++);
}

下一步我们还要实现pbackfail()。当我们调用std::istream::unget()或std::istream::putback(ch)时，我们会把已经读出的数据写回数组中。但是由于数组是只读的，所以我们只能模拟这种操作。

在默认的实现中pbackfail()只会返回traits_type::eof()，而在我们的版本中，如果写回成功，将会返回写回的字符，不成功返回eof。

char_array_buffer::int_type char_array_buffer::pbackfail(int_type ch)
{
    if (current_ == begin_ || (ch != traits_type::eof() && ch != current_[-1]))
        return traits_type::eof();

    return traits_type::to_int_type(*--current_);
}

在FILE_buffer中，我们也可以考虑重写pbackfail()，来提供反向查找以及（用前面的数据）重填buffer的功能。

最后一个重写的函数是showmanyc()，这个函数被std::streambuf::in_avail()调用，以判断当前有多少个字符可以返回。由于我们接管了状态指针，所以这个函数也要我们自己来实现啊。（译者：为什么要给自己找麻烦。。。）

std::streamsize char_array_buffer::showmanyc()
{
    assert(std::less_equal<const char *>()(current_, end_));
    return end_ - current_;
}

由此可见，本例中的buffer比前面的要复杂一点点。这是因为我们接管了状态维护的工作。这使得我们更好的理解了std::streambuf内部是如何工作的。

例3：句首变大写的缓冲区

本例中我们将要实现一个将句首字符变大写的buffer。当然我们只考虑最基本的情况，移植到不同的区域和语言，其实是很琐碎的事情。（译者：文字编码坑的亲妈都不认了）

#include <streambuf>
#include <iosfwd>
#include <cstdlib>
#include <vector>

class caps_buffer : public std::streambuf
{
    public:
        explicit caps_buffer(std::ostream &sink, std::size_t buff_sz = 256);

    protected:
        bool do_caps_and_flush();

    private:
        int_type overflow(int_type ch);
        int sync();

        // copy ctor and assignment not implemented;
        // copying not allowed
        caps_buffer(const caps_buffer &);
        caps_buffer &operator= (const caps_buffer &);

    private:
        bool cap_next_;
        std::ostream &sink_;
        std::vector<char> buffer_;
};

这里我们需要重写overflow()和sync()函数。overflow()在输入缓冲区满的时候被调用，并且在成功时返回任意非eof的值。

sync()的作用是把当前的buffer写入目标，即使当前buffer并未填满。std::flush()会调用sync()函数，当失败时返回-1。

我们编写一个辅助函数do_caps_and_flush()，用来将小写变大写，并写入sink_输出流。我们再声明一个哨兵变量cap_next_来标识下一个字符是否需要小写变大写。

#include "caps_buffer.hpp"

#include <cctype>
#include <ostream>
#include <functional>
#include <cassert>

caps_buffer::caps_buffer(std::ostream &sink, std::size_t buff_sz) :
    cap_next_(true),
    sink_(sink),
    buffer_(buff_sz + 1)
{
    sink_.clear();
    char *base = &buffer_.front();
    setp(base, base + buffer_.size() - 1); // -1 to make overflow() easier
}

buffer_的最小可能大小是1，同时我们也只需要维护两个指针，因为这里不需要像输入缓冲区一样的维护”put-back area”。

我们把buffer_的大小设成buff_sz + 1，这样是为了overflow()被调用时，我们有一个额外的空间存储当前的字符。最后将缓冲区数组和最后一个字符一起刷新到ostream中。

caps_buffer::int_type caps_buffer::overflow(int_type ch)
{
    if (sink_ && ch != traits_type::eof())
    {
        assert(std::less_equal<char *>()(pptr(), epptr()));
        *pptr() = ch;
        pbump(1);
        if (do_caps_and_flush())
            return ch;
    }

    return traits_type::eof();
}

第一步是把ch写入buffer_，并且使用pbump(1)将pptr()向前移一位。之后调用do_caps_and_flush()做一些脏活，之后返回一个字符声明调用成功。

sync()的实现也非常简单:

int caps_buffer::sync()
{
    return do_caps_and_flush() ? 0 : -1;
}

我们再看一看do_caps_and_flush()函数

bool caps_buffer::do_caps_and_flush()
{
    for (char *p = pbase(), *e = pptr(); p != e; ++p)
    {
        if (*p == '.')
            cap_next_ = true;
        else if (std::isalpha(*p))
        {
            if (cap_next_)
                *p = std::toupper(*p);

            cap_next_ = false;
        }
    }
    std::ptrdiff_t n = pptr() - pbase();
    pbump(-n);

    return sink_.write(pbase(), n);
}

对于本例来说，内部的缓冲区并非必要，我们可以一个字符一个字符把数据发到sink中。但是我的观点是一个内部buffer仍有其用处。

介绍 Boost IOStreams 库

如果你是流缓冲区的新手，希望你已经对它有一点点了解了。本文中的例子都非常基础，但是你可以用它们做更多有意思的事情。但是当我实现更复杂的流缓冲区时，问题的复杂度却上升的很快。这时我发现了Boost IOStreams库，它为更复杂的缓冲区和流提供了必要的框架支持。

它允许你解耦数据源，数据输出，过滤器以及其它一些概念。在我们的最后一个例子中，我们硬编码数据输出到std::ostream中。如果我们要输出到一个没有流接口的类呢？Boost IOStreams库提供了更多的灵活性，将一坨紧耦合的代码分解成独立的抽象概念。

扩展阅读

The C++ Standard Library by Nicolai M. Josuttis
The C++ Standard, BS ISO/IEC 14882:2003 (Second Edition)
Dinkum Compleat Reference online

Code Golf - Heapify

2015-08-01T00:00:00+08:00

void heapify(vector<int>& vec) {
    int n = vec.size();
    for (int a = 0, b = 1; b - 1 < n; a = b, b <<= 1) {
        nth_element(vec.begin() + a, vec.begin() + b, vec.end());
    }
}

You can implement a “heapify” by only four lines of code. And the time complexity is O(n).

Using Set Cover to Optimize a Large-Scale Low Latency Distributed Graph

2015-07-26T22:48:33+08:00

Background

Linkedin (or other social networks, such as Facebook and G+) use the “social graph information” to show the social relationship between you and other members.

Such as, “You and Mr.Obama share 10 mutual friends” or “You have 1,000 second-degree connections”.

This feature is very common for a social network. But where does it come from?

The information about a social relationship can be get from three basic APIs.

Get Connections
“Who does member X know?”
Get Shared Connections
“Who do I know in common with member Y?”
Get Graph Distance
“What the graph distance between member Z and me?”

Main Components for the System

Graph Database (Graph DB)
Distributed Network Cache (NCS)
Graph APIs

Because the problems of social graph share the same essence. Here we just talk about the “Graph Distance” problem.

The Graph DB stores all the relationship of the members. When we ask for the information of second degree creation,

Firstly, the web server communicate with GraphDB to get all the 1st degree connections
Secondly, web server communicate to GraphDB again to get all the 2nd degree connections
At last, the web server will merge all the results from the GraphDB to make it sorted and unique.

To make the retrieval more effectively, we add a cache level called NCS to cache the result we get from the GraphDB.

The Disadvantages of the Basic Algorithm

As we know, for a distributed system, there are shards, replica and load balancer to handle large amount of data and queries.

Consider this scenario.

Two queries are both ask for the data from shard 1 and shard 2.

The first query (the green one) has to communicate with the database twice, and then do the merging to get the final results.

And the second query (the red one) only has to talk to database once. And no de-duplicate is needed, because there’s definitely no duplicate data in one single node of the database.

We can make a conclusion that if we have a wise load balancer, we can optimize our retrieval logic remarkably.

Set Cover Problem

Given a set of elements {1,2,…,m} (called the universe) and a set S of n sets whose union equals the universe, the set cover problem is to identify the smallest subset of S whose union equals the universe. (Wikipedia)

This problem is similar to ours. The optimal algorithm for a load balancer is to find the minimal subsets of all sets which union equals to the ones that asked by the query input.

It seems that we find the key to our problem. But this is NP-complete. There is no effective way to find the optimal solution.

However, in practice, a greedy algorithm will actually do the trick. The rule of the greedy algorithm is to find the set which contains largest number uncovered elements.

Conclusion

We finally find out that the social information and the relationship graph is not that difficult. The basic concepts are quite easy. And the main work for the whole system is to use the cache to reduce the amount of calculation on the fly.

Reference

This post is mainly based on this video.

Slides

Special thanks to Linkedin for the sharing. :)

Workflowy full notes

2015-05-22T09:51:47+08:00

Recently, I’m becoming a crazy fan of workflowy because its ability to build a personal wiki concisely.

However, there’s only one thing bothers me that workflowy hide all the notes as the screenshot below, and it annoys me a lot.

Luckily we can always find a way to get around those limitations. Here I recommand the “Stylish”, which is a powerful tool to manipulate the CSS style of the page.

Just simpliy add these line to Stylish, and everything will be there as your wish.

DIV.notes DIV.content {
  height: auto !important;
  overflow: visible !important;
  display: block !important;
}

用C++实现一个通用的sort函数

2015-04-25T11:17:01+08:00

问题

用C++实现一个尽可能通用的sort函数

分析

一个通用的sort函数应该包含以下要点：

确实可以排序(LOL)
可以应对C-style array和C++-style container的排序需求
可以应用于任意random access container
可以使用用户自定义的排序函数 / 仿函数 / lambda函数

实现

为了与std中的通用函数做区别，这里的命名规则，包括类型与函数，都在前面加了”my”以示区别。可能与标准的命名法有出入，所以仅做示例用。

思路

** 拷贝代码是愚蠢的行为。**

或者说，

** 对于同一钟实现，尽量使用同一份代码。 **

感谢C++ Templates，对于不同类型与需求的函数，我们可以将生成多份代码的劳动放心的交给编译器。并且，Templates的代码生成是在编译期完成的，即不会造成额外的代码膨胀（如果你姿势正确的话），也一般不会造成额外的运行时开销。

函数原型

我们模仿std::sort来进行开发。

template< class It, class Compare >
void sort(It first, It last, Compare comp );

从迭代器/指针获得元素类型

我们要处理C风格的数组与C++网络的容器。首先要从迭代器/指针It中获得元素类型。

template<typename It>
struct myiter_traits {
    typedef typename It::value_type value_type;
};

template<typename T>
struct myiter_traits<T*> {
    typedef T value_type;
};

这个实现非常简单，不做赘述。

实现mysort函数

template<typename RandomAccessor, typename FUNC>
void mysort(
        const RandomAccessor& head,
        const RandomAccessor& tail,
        FUNC cmp) 
{
    if (tail - head <= 1) {
        return;
    }
    const RandomAccessor pivot = mypartition(head, tail, cmp);

    mysort(head, pivot, cmp);
    mysort(pivot + 1, tail, cmp);
}

mysort函数本体并不难理解，这里重点讨论一下模板的思路。

由于迭代器不需要移动，所以声明为const reference。又由于我们需要兼容各种不同类型的排序方法（函数、仿函数、lambda、std::function等），所以不对FUNC类型进行限制，即所有可以被call的类型都可以做为模板参数。

实现mypartition函数

快速排序的灵魂就是快速划分。如果处理得当，quick sort可以视作一个稳定的排序函数；否则，一组构造（不必要精心构造）的数据就可以把quick sort变成”slow sort”。

可能会上quick sort退化的数据

基本一致的数据
e.g. 1, 1, 1, 1 ... 1, 1 or 1, 1, ... 2, 2, ... 3, 3
有序或基本有序的数据
e.g. 1, 2, ... 5, 6 or 6, 5, ... 2, 1

解决思路

对于有大量重复的数据，我们在处理时要注意平均分配这些重复数据。即，对于与pivot相等的数据，尽量保证一半放在左面，一半放在右面。

对于有序或基本有序的数据，我们在pivot的选择上可以使用随机、三值法等手段，保证数据的平均分配。

总的说来，quick sort的高效性，取决于partition函数的平均分配性能上。

一个实现

template<typename RandomAccessor, typename FUNC>
RandomAccessor mypartition(
        const RandomAccessor& head,
        const RandomAccessor& tail,
        FUNC cmp) 
{
    auto dis = distance(head, tail);
    RandomAccessor pivot = head + rand() % dis;
    iter_swap(pivot, head);
    pivot = head;

    RandomAccessor l = head;
    RandomAccessor r = tail - 1;
    int ptr = 0;
    while (l <= r) {
        while (l <= r) {
            bool lt = cmp(*l, *pivot);
            bool gt = cmp(*pivot, *l);
            bool eq = !lt && !gt;
            if (lt || (eq && ptr == 0)) {
                l++;
                ptr ^= (eq? 1: 0);
            } else {
                break;
            }
        }
        while (l <= r) {
            bool lt = cmp(*r, *pivot);
            bool gt = cmp(*pivot, *r);
            bool eq = !lt && !gt;
            if (gt || (eq && ptr == 1)) {
                r--;
                ptr ^= (eq? 1: 0);
            } else {
                break;
            }
        }
        if (l <= r) {
            swap(*l, *r);
            l++;
            r--;
        }
    }
    iter_swap(pivot, r);
    return r;
}

主函数

int main() {
    srand(time(NULL));

    vector<int> vec({2, 1, 3, 0, 4, 1999});

    mysort(vec.begin(), vec.end(), less<int>());
    for (const auto& i: vec) {
        printf("%d ", i);
    }
    puts("");

    int array[] = {99, 19, 9999};
    mysort(array + 0, array + 3, 
            [](int a, int b)->bool { return a > b; });
    for (int i = 0; i < 3; i++) {
        printf("%d ", array[i]);
    }
    puts("");

    return 0;
}

ZeroMQ启示录

2015-04-07T10:01:34+08:00

ØMQ是一个消息系统

ZeroMQ是一个消息系统，也被称为“消息中间件”。它被广泛的用于经济、游戏、嵌入式等领域。

什么是消息系统

打个比方，消息系统就像我们使用的IM软件一样。首先，一方决定将消息发往何处（一对一或一对多）。然后将信息打包，点击发送按钮。之后，IM系统会帮你料理剩余的事务。

但是，它们也有很大的不同点。IM系统对于消息系统似乎太低效了一点。另外，消息系统是没有用户界面（GUI）的。在错误发生时，消息的另一端也不会有人来智能的介入处理。

所以，我们可以这样下定义。消息系统是具有高效性和容错性的消息传递解决方案。

ZeroMQ的起源和发展

ZeroMQ最先的设想是实现一个炒鸡快的用于证券交易的消息系统，所以在设计初期的关注点就是在极致的优化上。

第一年的工作重点，在于发明性能测试的方法，和设计高效架构。

之后，大约在第二年，工作重点转移到实现一个通用的消息系统，以应用于分布式系统，使其可以利用不同的编程语言，使用不同方式，来传递各种模式的信息。

启示1：独立应用 vs. 程序库

ZeroMQ是一个程序库，不是一个消息服务器。这样设计的主要原因是：性能。

使用一个中间消息服务器（Broker），每一条消息都会被在网络上传递两次（Sender->Broker->Receiver)。这样的设计会影响时延和吞吐量。更严重的是，如果所有消息都通过中间服务器，那么这个点就会成为整个系统的瓶颈。

使用中间消息服务器的另一个弊端，是不利于大规模部署。对于证券交易来说（ZeroMQ最初的应用场景），跨组织的消息传输是不可避免的。这样一来，中央集权式的消息传输就不在有效了。

所以，我们缩小消息系统的粒度，使之成为一个程序库。使其更轻量，更易于部署。同样，更轻量的消息系统可以实现更复杂的拓扑结构。

获得的启示：对于一个新项目来说，如果可能，尽量把它实现为一个程序库。将一个新库联编到原有程序中，只需要少量的人力，也提供了足够的灵活性。

启示2：全局状态

对于程序库来说，全局状态往往不能正确的工作。

由于一个程序库可能被一个应用程序加载多次，这就不能保证只有独一无二的全局状态。

ZeroMQ的解决方法是由库的调用者显式的维护一个“环境”，如图所示。libA和libB都有其独有的“环境”信息。

获得的启示：不要在程序库中使用全局状态。如果你这么做了，当库恰好需要在同一个进程中实例化两次时，它很可能会崩溃。

启示3：性能

ZeroMQ在最初设计时，性能调优就是首要的目标。做为一个消息系统，其性能指标主要有两个：吞吐量和延时。

但是我们怎么度量它们呢？

如上图所示，A向B发送信息。B在6秒内接收到了5条信息，因此吞吐量为0.83消息/秒，平均时延为1.2秒。

如果我们换一种计量方式，A向B发送消息，对于单条信息来说，其平均时延为3秒。A花费2秒，发送了所有的消息；B花费了4秒，接收到了所有的消息。所以A的吞吐量为2.5消息/秒，B的吞吐量为1.25消息/秒。这个数据与我们上面得出的数据相差甚远。

由此，我们可以看出，使用不同的计量标准，对于我们估计系统的性能，会带来很大的不同。

时延只有在两个节点通信时，才可能发生。所以，并不能有“某节点的时延”这种度量标准的出现。同样，我们可以对多条消息的时延进行平均，但是并不能有“一个消息流的平均时延”。

吞吐量，与时延不同，只能在单个节点上进行度量。所以，并不能有“节点间的吞吐量”这种度量方法。

获得的启示：深入了解你所要解决的问题。否则，你会在解决问题时会引入（错误的）假定和玄学，写出有缺陷的复杂代码。

启示4：关键路径

代码中经常被调用的代码，被称为关键路径。

对于ZeroMQ来说，建立链接与内存申请都不是影响性能的最主要因素。因为ZeroMQ使用长链接进行通信，所以建立链接的开销均摊到每一条信息微乎其微。同样，ZeroMQ使用高效的内存维护机制，尽可能少的向系统直接申请内存空间。

获得的启示：只在系统的关键路径上做优化。否则只是浪费时间。

启示5：内存申请

对于一个高效的系统来说，高效的处理内存的方法往往是在内存申请与内存拷贝之间寻求一个平衡。

对于小型数据来说，直接拷贝数据，即“深拷贝”，的开销更小。而对于大型数据来说，所谓“浅拷贝”的开销更小。

ZeroMQ使用透明的方式来处理两种不同的场景。并且，对于规模较大的数据，使用引用计数的策略，最大限度的复用与节省内存使用。

获得的启示：当我们优化性能时，不要假定只有一个全局最优解。在不同的场景下，最优解的定义可能大不相同。

启示6：批处理

对于一个高性能消息系统来说，系统调用的绝对数量就是系统的瓶颈。这其实是一个很普遍的问题，消息在调用栈之间传递，会带来不可忽略的性能损失。所以，在构建一个高性能系统时，应该尽量避免消息在栈间的传递。

如下图所示，对于四条消息，我们需要遍历整个网络栈四次。

然而，如果我们将这些消息打包成一条消息。我们只需要遍历网络栈一次。

在这里，我们的策略与TCP/IP协议中的Nagle算法类似。Nagle算法是为了充分利用带宽，而ZeroMQ的Batching策略是为了均摊网络栈的时间开销。

具体的实现如下:

当消息的频率没有超过网络栈的带宽时，ZeroMQ会把所有batching关掉，以CPU利用率来换取低时延。
当消息的频率超过网线栈的带宽时，ZeroMQ会启用batching，以时延为代价来优化吞吐量。
当消息队列中的消息过多时，ZeroMQ会采用更激进的batching策略。因为消息的堆积造成的时延增长已经不可避免，索性将更多的信息打包，这样可以更快的清空消息的积压。

另外，batching策略只应该被应用于顶层。在顶层采用batching之后，低层的batching就没有意义了。

获得的启示：
* 在一个异步系统中，想要获得最佳的响应时间，应该把底层的batching策略转移到顶层。
* batching只应该在新数据到来的速度超过系统带宽时才采用。

启示7：整体架构

用户利用“socket”与ZeroMQ进行交互，一个socket可以同多个peer进行交互。

socket存在于用户线程中。而一些工作线程会处理异步的交互过程，如：从网络读取消息，将消息放入队列，接受新的连接请求等。

session负责与ZeroMQ中的socket进行交互，engine负责网络交互。session只有一种，而engine根据使用的协议不同，可以有很多种。

session与socket之间使用pipe进行通信，pipe被实现为线程安全的双端队列，用来在线程间传递信息。

获得的启示：学习了整体的设计思路（笑

启示8：并发模型

高效的ZeroMQ必然要利用多核的计算资源，而传统的多线程模型会引入锁、信号量等线程同步机制，会影响系统的整体性能。而使用独立的线程又会引入上下文切换的开销。

ZeroMQ使用的并发模型是Actor，其目标是完全避免锁的使用，让所有的组件全速运行。

每一个CPU核心只有一个worker线程，所有内部对象都是线程专有的，这样就完全避免了锁的使用。

这样一来，许多对象都要分享有限个数的worker。所以，系统应当是全异步的。因为每一个worker的阻塞，都会阻塞其它使用worker的对象。

获得的启示：Actor模型是极致解决性能与扩展性问题的方法。但是，如果你不是在使用ZeroMQ或Erlang，你需要手写许多相关的Test Case来测试系统的正确性和稳定性。另外，如果你无法应对模型中的复杂模块（如ZeroMQ的shutdown），请不要轻易尝试使用Actor模型。

启示9：无锁算法

无锁算法使用简单的方法进行线程间的通信，而不依赖内核级的同步原语。无锁算法的关键是CPU中的原子操作，例如compare-and-swap（CAS）操作。但是，要记住，无锁操作并不是真正的“无锁”，而是把锁操作放到了较为高效的硬件层。

ZeroMQ使用一个无锁队列在用户线程与工作线程间进行消息传递。ZeroMQ中的无锁队列有如下特点：

第一，每一个队列为“一写一读”。当有一对多的读写需求存在时，ZeroMQ会创建多条队列。这样的设计使得我们不用关心多线程读写带来的同步问题，有利于我们对其性能的优化。

第二，即使无锁算法比传统的锁算法要快很多，但是其代价仍然是过高的（尤其是在CPU核心之间的通信）。所以，我们仍然依赖于“batching”算法，将昂贵的同步操作均摊到多条消息上。在从队列真正的读写操作之前，加入一次预处理（pre-write / pre-read），将消息打个包，发申通。

获得的启示：无锁算法是非常精巧的，如果可能的话，尽量使用成熟的设计。如果你需要极致的性能，不要仅仅依赖于无锁算法。尽管无锁算法非常快，你仍然可以通过batching策略优化它。（另外，加钱上船也可以。）

启示10：API设计

设计API，就像设计一款产品。

用户对于一个程序库的第一感觉来自于用户接口。ZeroMQ简化了自己的用户接口，将其由原来的“炒鸡复杂一不小心坑死你的企业级消息框架”变为了“想发消息调用下就OK”的极易上手的入门级产品。

另外一个重要的方面，ZeroMQ使用了广为使用的BSD Sockets API。这样做的优点是：

这是一个大家都熟知的API，学习曲线相当平缓
使ZeroMQ与现有的技术连接起来，有利于复用已用的框架与设计
最重要的是，使用一个成熟与久经考验的框架，可以避免踩前人踩过的坑、

获得的启示：除了代码复用之外，我们还可以以一种更一般的方法，复用成熟的技术。当你设计一个新产品时，借鉴一下类似的产品（腾讯！）。不要犯“在这里还没有被发明”（Not Invented Here）综合症。复用一切合适的想法、API、框架抽象。允许用户使用已有的知识，同时也可以让我们规避未知的风险。

启示11：消息模式

ZeroMQ的设计思路是专注于一个领域，把它做到最好。因为，大而全的产品只能给领域专家来使用，而小而精的产品的受众则是任何受过训练的程序员。

s = socket (REQ)
s.connect ("tcp://192.168.0.111:5555")
s.send ("Hello World!")
reply = s.recv ()

当我们要给用户提供更一般性的解决方案时，一个技术栈，栈的每一层可以有不同的实现，从而适应不同人群的需要。

这和Internet栈的设计思路非常相似：TCP可以解决基于链接的、可靠的数据流传输，UDP可以解决不可靠的数据包传输，SCTP可以解决多用户数据流传输问题等等。

这样一来，所有的解决方案都是正交的，我们可以利用其中好的设计，也可以没有额外代价的抛弃不好的设计。

获得的启示：当解决一个复杂且多面化的问题时，单个通用型的解决方案可能并不是最好的方式。相反，我们可以把问题的领域想象成一个抽象层，并基于这个层次提供多个实现，每种实现只致力于解决一种定义良好的情况。

当我们这么做时，确定问题的粒度非常重要。如果粒度过细，软件的一般性就会受到限制。如果粒度过粗，那么产品就会变得非常复杂，给用户带来模糊和混乱的感觉。

后记

原文链接：http://www.aosabook.org/en/zeromq.html
中文翻译：http://www.ituring.com.cn/article/4669

本文中借鉴了中文翻译的部分词句，对此表示感谢。

Codeforces Round #290 (Div. 2) Tutorial

2015-02-18T00:30:24+08:00

A. Fox And Snake

Implementation

(n, m) = map(int, raw_input().split())

res = []

for i in xrange(n):
    if i % 2 == 0:
        res.append('#' * m)
    elif (i / 2) % 2 == 0:
        res.append('.' * (m - 1) + '#')
    else:
        res.append('#' + '.' * (m - 1))

for line in res:
    print line

B. Fox And Two Dots

DFS

AAAA
ABCA
AAAA

We start at arbitrary point, and traverse the neighbour point with the same color to see if there is a circle.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 54;

const int mx[] = {0, 1, 0, -1};
const int my[] = {-1, 0, 1, 0};

int n, m;
char g[SIZE][SIZE];
char visit[SIZE][SIZE];

bool do_dfs(int y, int x, char c, int dir) {
    if (visit[y][x]) {
        return true;
    }
    visit[y][x] = 1;
    for (int i = 0; i < 4; i++) {
        int ny = y + my[i];
        int nx = x + mx[i];
        if (nx < 0 || nx >= m 
                || ny < 0 || ny >= n 
                || g[ny][nx] != c
                || (dir != -1 && i == (dir + 2) % 4)) {
            continue;
        }
        if (do_dfs(ny, nx, c, i)) {
            return true;
        }
    }
    return false;
}

bool dfs(int y, int x) {
    char c = g[y][x];
    return do_dfs(y, x, c, -1);
}

int main() {
    input(n >> m);
    memset(g, 0, sizeof(g));
    memset(visit, 0, sizeof(visit));

    for (int i = 0; i < n; i++) {
        input(g[i]);
    }
    try {
        for (int i = 0; i < n; i++) {
            for (int j = 0; j < m; j++) {
                if (!visit[i][j]) {
                    bool res = dfs(i, j);
                    if (res) {
                        print("Yes");
                        throw "Got it";
                    }
                }
            }
        }
        print("No");
    } catch (...) {
        // pass
    }
    return 0;
}

C. Fox And Names

Topsort

This is a classic interview problem. We can find the relationship between two letters from the given name list.

But in this instance, there is no possible lexical order because the name list is invalid.

aaa
aa
a

So the algorithm can be describe in this way:

If the name list is invalid, there is no solution.
Try to find the order of the letters.
Topsort
If topsort is success, print out the new lexical order of the name list. If failed, there is no solution.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <queue>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 26;

vector<string> names;
vector<int> g[SIZE];
vector<int> res;
int n;
int in[SIZE];

bool makeG() {
    for (int i = 1; i < n; i++) {
        const string& pre = names[i - 1];
        const string& now = names[i];

        int len = min(pre.size(), now.size());

        if (pre.size() > now.size() && pre.substr(0, len) == now) {
            return false;
        }

        for (int j = 0; j < len; j++) {
            if (pre[j] == now[j]) {
                continue;
            }
            int a = pre[j] - 'a';
            int b = now[j] - 'a';
            g[a].push_back(b);
            in[b]++;
            break;
        }
    }
    return true;
}

bool top_sort() {
    queue<int> q;
    int cnt = 0;
    for (int i = 0; i < SIZE; i++) {
        if (in[i] == 0) {
            q.push(i);
            cnt++;
        }
    }
    while (!q.empty()) {
        int now = q.front();
        q.pop();
        res.push_back(now);
        for (auto next: g[now]) {
            in[next]--;
            if (in[next] == 0) {
                q.push(next);
                cnt++;
            }
        }
    }
    return cnt == SIZE;
}

void print_res() {
    for (auto i: res) {
        printf("%c", 'a' + i);
    }
    puts("");
}

int main() {
    string name;

    input(n);
    memset(in, 0, sizeof(in));
    for (int i = 0; i < n; i++) {
        input(name);
        names.push_back(name);
    }

    if (makeG() && top_sort()) {
        print_res();
    } else {
        puts("Impossible");
    }
    return 0;
}

D. Fox And Jumping

Extended Euclidean algorithm

As we might know, for every positive integer x and y:

ax + by = gcd(x, y)

Let’s extend this theorem, for an array of positive integer Xs:

As * Xs = gcd(Xs)

(As is an array of constants, both positive and negative)

If gcd(Xs) equal to one, that is, every two number of the array is co-prime.

So, we can find a subarray that every two number is co-prime, and have the minimal cost.

As there are not too many factors in a single number, even the number here is as large as 10^9. The gcd() of the subarray won’t have too many results, and could be stored in a single unordered_map here.

And,

C++ Iterator Invalidation Rules (C++03)

Associative containers

[multi]{set,map}: all iterators and references unaffected

Here is the rule of C++ about the behavoir of the iterators when we try to add something into the map during the iteration. So we can just use one sigle map, and avoid the complexity of moving things between to containers.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>
#include <unordered_map>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 500;
const int INF = 0x3f3f3f3f;

int gcd(int a, int b) {
    if (a % b == 0) {
        return b;
    }
    return gcd(b, a % b);
}

struct Card {
    int step;
    int cost;
};

int n;

vector<Card> cards;

int main() {
    input(n);
    cards.resize(n);
    for (int i = 0; i < n; i++) {
        input(cards[i].step);
    }

    for (int i = 0; i < n; i++) {
        input(cards[i].cost);
    }

    unordered_map<int, int> mp;
    for (auto& card: cards) {
        if (mp.find(card.step) == mp.end()) {
            mp[card.step] = INF;
        }
        mp[card.step] = min(mp[card.step], card.cost);
    }

    for (int i = 0; i < n; i++) {
        int thres = mp.find(1) != mp.end()? mp[1]: INF;
        for (auto& p: mp) {
            auto step = p.first;
            auto cost = p.second;

            if (step != 1 && cost >= thres) {
                continue;
            }

            int g = gcd(step, cards[i].step);

            if (mp.find(g) == mp.end()) {
                mp[g] = INF;
            }

            if (g == step) {
                mp[g] = min(mp[g], cost);
            }

            mp[g] = min(mp[g], cost + cards[i].cost);
        }
    }

    if (mp.find(1) == mp.end()) {
        print("-1");
    } else {
        print(mp[1]);
    }

    return 0;
}

E. Fox And Dinner

Max Flow Algorithm

As we know, every odd number must be connected to two even numbers. And, of course, one even number should be connected to two odd numbers.

We use the max flow algortihm. Every odd number have a path with 2 unit of flow to the source node, every even number have a path with 2 unit of flow to the sink node. And if the sum of one odd number and an even number is a prime, we connect them with a path with 1 unit of flow.

As the result, we have a undirected graph that every node have a degree of 2. It’s easy to find out that is an Euler circuit. We find the circuit and print it out.

The problem is not easy as it seems. Harsh one, indeed. I used Dinic algorithm for the max flow. Actually, I don’t like my code here.

#include <cstdio>
#include <cstring>
#include <cstdlib>
#include <iostream>
#include <algorithm>
#include <vector>
#include <queue>
#include <stack>

using namespace std;

#define print(x) cout<<x<<endl
#define input(x) cin>>x

const int NODE = 200 + 19;
const int EDGE = NODE * NODE;
const int INF  = 0x3f3f3f3f;

struct node
{
    int st, end, flow, next;
    node(){}
    node(int ist, int iend, int iflow, int inext):
            st(ist), end(iend), flow(iflow), next(inext) {}
};

int n;
node edge[EDGE];
int head[NODE];
int ind;
int source,sink;
vector<int> nums;
vector<int> cnc[NODE];
char visit[NODE];

void addEdge(int s,int e,int f)
{
    edge[ind]=node(s,e,f,head[s]);
    head[s] = ind++;

    edge[ind]=node(e,s,0,head[e]);
    head[e] = ind++;
}

namespace dinic
{
    int level[NODE],curhead[NODE],Que[NODE];
    int estack[4*NODE+4*EDGE],estop;

    int BFS()
    {
        memset(level,-1,sizeof(level));
        Que[0]=source;
        level[source]=0;
        for(int fr=0,tail=1;fr!=tail;fr=(fr+1)%NODE)
        {
            int cur=Que[fr];
            for(int e=head[cur];e!=-1;e=edge[e].next)
            {
                int next=edge[e].end;
                if(edge[e].flow && level[next] == -1)
                {
                    Que[tail]=next;
                    level[next]=level[cur]+1;
                    tail=(tail+1)%NODE;
                }
            }
        }
        return level[sink]!=-1;
    }

    int DFS()
    {
        int indptr,minf,e;
        int res=0;
        int cur=source;                                                   
        estop=0;
        memcpy(curhead,head,sizeof(head));  
        while(estop>=0)
        {            
            if(cur==sink)
            {                                      
                minf=INF;
                for(int i=estop-1;i>=0;i--)
                {
                    e=estack[i];
                    if(edge[e].flow<=minf)
                    {
                        minf=edge[e].flow;
                        indptr=i;
                    }
                }
                res+=minf;                                   

                for(int i=estop-1;i>=0;i--)
                {               
                    e=estack[i];
                    edge[e].flow-=minf;
                    edge[e^1].flow+=minf;
                }
                estop=indptr;                                    
                cur=edge[estack[estop]].st;          
            }
            for(e=curhead[cur];e!=-1;e=edge[e].next)
            {  
                curhead[cur]=e;
                int next=edge[e].end;
                if(edge[e].flow && level[next]==level[cur]+1)
                {
                    estack[estop++]=e;
                    cur=next;
                    break;
                }
            }
            if(e==-1)
            {                                           
                estop--;
                level[cur]=-2;                                    
                cur=edge[estack[estop]].st;               
            }
        }
        return res;
    }
}

void init()
{
    ind=0;
    memset(head,-1,sizeof(head));
    memset(visit, 0, sizeof(visit));
}

void dfs(int p, vector<int>& res) {
    res.push_back(p);
    visit[p] = 1;
    for (auto& u: cnc[p]) {
        if (visit[u]) {
            continue;
        }
        dfs(u, res);
    }
}

void show_res() {
    for (int i = 0; i < EDGE; i++) {
        if (edge[i].flow == 0) {
            int a = edge[i].st;
            int b = edge[i].end;

            if (a == source || b == source || a == sink || b == sink) {
                continue;
            }

            if (nums[a - 1] % 2 == 1 && nums[b - 1] % 2 == 0) {
                cnc[a].push_back(b);
                cnc[b].push_back(a);
            }
        }
    }
    /*
    for (int i = 1; i <= n; i++) {
        printf("%d -> ", i);
        for (auto& item: cnc[i]) {
            printf("%d ", item);
        }
        puts("");
    }
    puts("---");
    */
    vector<vector<int> > res;
    for (int i = 1; i <= n; i++) {
        if (visit[i]) {
            continue;
        }
        vector<int> tmp;
        dfs(i, tmp);
        res.push_back(tmp);
    }
    print(res.size());
    for (const auto& vec: res) {
        printf("%d", (int)vec.size());
        for (const auto& i: vec) {
            printf(" %d", i);
        }
        puts("");
    }
}

bool isPrime(int u) {
    if (u % 2 == 0) {
        return false;
    }
    int v = sqrt(u) + 1;
    for (int i = 3; i <= v; i += 2) {
        if (u % i == 0) {
            return false;
        }
    }
    return true;
}

int main()
{
    freopen("E.txt", "r", stdin);
    int x;
    input(n);
    init();

    source = 0;
    sink = n + 1;

    for (int i = 1; i <= n; i++) {
        input(x);
        nums.push_back(x);
    }

    for (int i = 1; i <= n; i++) {
        if (nums[i - 1] % 2 == 0) {
            continue;
        }
        for (int j = 1; j <= n; j++) {
            if (nums[j - 1] % 2 != 0) {
                continue;
            }
            if (isPrime(nums[i - 1] + nums[j - 1])) {
                addEdge(i, j, 1);
            }
        }
    }

    for (int i = 1; i <= n; i++) {
        int u = nums[i - 1];
        if (u % 2 == 1) {
            addEdge(source, i, 2);
        } else {
            addEdge(i, sink, 2);
        }
    }

    int res = 0;
    while(dinic::BFS()) {
        res+=dinic::DFS();
    }

    if (res != n) {
        puts("Impossible");
    } else {
        show_res();
    }

    return 0;
}

Codeforces Round #289 (Div. 2) Tutorial

2015-02-16T21:16:31+08:00

A. Maximum in Table

Simulation.

n = int(raw_input())
g = [[1 for i in xrange(n)] for j in xrange(n)]

for i in xrange(1, n):
    for j in xrange(1, n):
        g[i][j] = g[i - 1][j] + g[i][j - 1]

print g[n - 1][n - 1]

B. Painting Pebbles

Reading comperhension & Constructive.

The key point of this problem is abs(b(i, c) - b(j, c)) <= 1.

First of all, it’s safe to paint k pebbles of every pile with the same color, when k = min(piles). At this moment, every b(i, c) - b(j, c) == 0.

And then, we paint 1 pebbles of every pile with color C[i] at a time (if possible). That is, for every pile, the number of pebbles with color C[i] is zero or one.

If you can’t paint all the pebbles with proper color, just print a “NO” here.

(n, k) = map(int, raw_input().split())
ps = map(int, raw_input().split())

(mini, maxi) = min(ps), max(ps)

if maxi - mini > k:
    print 'NO'
    exit(0)

print 'YES'
for p in ps:
    r = [1 for i in xrange(mini)] + [i + 1 for i in xrange(p - mini)]
    print ' '.join(map(str, r))

C. Sums of Digits

Brute force & Constructive

After reading this problem, there is one thing that we could NEVER miss is the scope of number n: 1 <= n <= 300, which means that the max number here is no more than 40 digits and we can solve the problem with brute force.

As we know, the number in the array must be incremental, and every number should be the minimum.

Assuming we have got an array which is incremental, the last number is K. Such as:

K = d3 ++ d2 ++ d1 ++ d0

Our mission is to find a way to generate the smallest number which follow the rules:

the number here is greater than the previous one
the digit sum

Rule No.1 is not hard as it seems, if we increase any digit of the number K, the new number is of course greater. But how to satisfy the digit sum?

For example, we got a new number K1:

K1 = d3 ++ (d2 + 1) ++ d1 ++ d0

Here, of course, K1 > K. But the number K2:

K2= d3 ++ (d2 + 1) ++ 0 ++ 0

is smaller then K1, and also greater than the number K.

And then, we fill the lower digits with number to make the sum of the digits equal to the given one. If failed, keep on trying, such as:

K3 = d3 ++ (d2 + 2) ++ 0 ++ 0

K4 = (d3 + 1) ++ 0 ++ 0 ++ 0

or even

K5 = 1 ++ 0 ++ 0 ++ 0 ++ 0

import sys

def do_fill(num, ptr, delta):
    for i in xrange(ptr):
        num[i] = min(9, delta)
        delta -= num[i]
    return delta == 0

def solve(num, pre):
    l = len(pre)
    i = 0

    while True:
        t = pre + [0 for j in xrange(i - l + 1)]
        while t[i] + 1 < 10:
            t[i] += 1
            for j in xrange(i):
                t[j] = 0
            delta = num - sum(t)
            if delta < 0:
                break
            if do_fill(t, i, delta):
                return t
        i += 1

if __name__ == '__main__':
    ns = map(int, sys.stdin)[1:]
    ans = [[0]]

    for num in ns:
        ans.append(solve(num, ans[-1]))

    for item in ans[1:]:
        print ''.join(map(str, item[::-1]))

D. Restoring Numbers

Math

Each number of the input matrix is (A[i] + B[i]) % MOD. And we can get (A[i] - A[j]) % MOD by subtract the number on the same line.

Sometimes, the (A[i] - A[j]) % MOD can be both positive and negetive. And we can get the value of MOD here.

As a result, we can get the value of every A[i] - A[0]. We set A[0] to the number ‘0’, and get the values of array A.

(n, m) = map(int, raw_input().split())

mat = [map(int, raw_input().split()) for i in xrange(n)]

mod = -1
diffs = [0 for i in xrange(m)]

for i in xrange(1, m):
    diff = set([
        mat[j][i] - mat[j][0] for j in xrange(n)
    ])

    if len(diff) == 1:
        diffs[i] = list(diff)[0]
        continue

    if len(diff) != 2:
        print 'NO'
        exit(0)

    a, b = diff

    if mod == -1:
        mod = abs(a - b)
    elif mod != abs(a -b):
        print 'NO'
        exit(0)

    diffs[i] = max(a, b)

As = [0 for i in xrange(n)]
Bs = [0] + diffs[1:]

Bs = map(lambda x: x - min(Bs), Bs)

for i in xrange(n):
    As[i] = mat[i][0] - Bs[0]

if mod == -1:
    mod = (10 ** 18) - 1

for i in xrange(n):
    for j in xrange(m):
        if mat[i][j] != (As[i] + Bs[j]) % mod:
            print 'NO'
            exit(0)

print 'YES'
print mod
print ' '.join(map(str, As))
print ' '.join(map(str, Bs))

E. Pretty Song

Math & Thinkin’ in reverse

It’s hard to get the answer by brute force because the scope of this problem is too large.

Try to think in reverse. It’s hard to calculate all the value of the substrings, but why don’t we find a way to get the value that every vowel contributes to the final result?

For example, string “AAA”. The first “A” will add 1 + 1/2 + 1/3 to the final result. And the second “A”, 1 + 1/2 + 1/2 + 1/3. And the last “A”, 1 + 1/2 + 1/3.

We can make a table here for a 4-length string.

We can easily find the pattern here. (Of course we can prove it.) And the code is right here.

(But you can always find a harder way to sovle it. LOL. But I have to say that pypy is awesome!)

# pypy: 171ms
# python2: 467ms
VOWELS = list('AEIOUY')
N = 500010

ds = [0 for i in xrange(N)]

for i in xrange(1, N):
    ds[i] = ds[i - 1] + 1.0 / i

S = raw_input()
n = len(S)
d = 0
ans = 0

for i, c in enumerate(S):
    d += ds[n - i] - ds[i]
    if c in VOWELS:
        ans += d

print ans

pypy is about 3~5 times faster than the original python interpreter, and this is the very useful tool to help us with the algorithm problems.

F. Progress Monitoring

This problem is about the pre-order traversal with a tree. There are multiple situations of the output string given in the problem.

  a    | b c d |         | e f g h i j |
  ^        ^                    ^
father  children   siblings & siblings children

  a    | b c d e f |         | g h i j |
  ^          ^                    ^
father   children    siblings & siblings children

But be aware, if x < a, a and x can’t be siblings.

dp[i][j] stands for the number of permutations of the subtree. whose pre-order traversal is right match the s[i...j], the substring of the given traversal path.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

typedef long long llint;

const llint MOD = 1000000000 + 7;
const int SIZE = 555;

llint dp[SIZE][SIZE];
int n;
vector<int> outvec;

void solve() {
    for (int i = 0; i < n; i++) {
        for (int j = 0; j + i < n; j++) {
            int l = j, r = j + i;
            if (l == r) {
                dp[l][r] = 1;
                continue;
            }
            if (outvec[l + 1] > outvec[l]) {
                dp[l][r] += dp[l + 1][r]; // <l + 1 ... r> are siblings
                dp[l][r] %= MOD;
            }
            dp[l][r] += dp[l + 1][r]; // <l + 1 .. r> are child nodes
            dp[l][r] %= MOD;

            for (int k = l + 2; k <= r; k++) {
                if (outvec[k] > outvec[l]) {
                    llint child   = dp[l + 1][k - 1];
                    llint sibling = dp[k][r];
                    dp[l][r] = (dp[l][r] + child * sibling) % MOD;
                }
            }
        }
    }
}

int main() {
    int x;
    input(n);
    if (n == 1) {
        print(1);
        exit(0);
    }
    memset(dp, 0, sizeof(dp));
    for (int i = 0; i < n; i++) {
        input(x);
        outvec.push_back(x);
    }
    solve();
    print(dp[1][n - 1] % MOD);
    return 0;
}

Codeforces Round #288 (Div. 2)

2015-02-16T21:16:30+08:00

A. Pasha and Pixels

Brute force.

There are multiple ways to form a 2*2 square at one single step.

So at every step, we have to check the neighbours of pixel that is colored black.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <vector>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 1024 + 123;

const int mx[] = {0, 1, 0, 1};
const int my[] = {0, 0, 1, 1};
const int MOVE = 4;

int mp[SIZE][SIZE];
int n, m, k;

bool isBlackBlock(int y, int x) {
    int cnt = 0;
    for (int i = 0; i < MOVE; i++) {
        int ny = y + my[i];
        int nx = x + mx[i];

        if (ny >= 0 && ny < n
                && nx >= 0 && nx < m
                && mp[ny][nx]) {
            cnt++;
        }
    }
    return cnt == MOVE;
}


int main() {
    int y, x;
    input(n >> m >> k);
    memset(mp, 0, sizeof(mp));
    int ans = 0;
    for (int i = 0; i < k; i++) {
        input(y >> x);
        x--; y--;
        mp[y][x] = 1;
        bool flag = false;
        for (int j = 0; j < MOVE; j++) {
            flag |= isBlackBlock(y - my[j], x - mx[j]);
        }
        if (flag) {
            ans = i + 1;
            break;
        }
    }
    print(ans);
    return 0;
}

B. Anton and currency you all know

At first, you have to understand the questions accurately.

The exchange rate is an odd number. And your mission is swap one digit with another, to make it the maximum even number.

Because if the exchange rate is an even number, it will lead to a more sophisticated problem.

The intuitive thought is that we can swap the hightest even digit with the last digit. However, for this case “92291”, you may swap the second digit “2” and the last digit “1”. But “91292” is not the largest number, “92192” is.

So, ther are two scenario. First is the final answer is greater than the ordinary one. Just find out the first even digit that is less than the last digit. Second is the final answer is less than the given one. If we want to make it the largest one, we have to find the lowest even digit and then swap.

We can make it by loop twice. But there is a way to find the final answer in one single iteration.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 123456;

char number[SIZE];

int main() {
    scanf("%s", number);
    int len = strlen(number);
    int p = -1, q = number[len - 1] - '0';

    for (int i = len - 2; i >= 0; i--) {
        int u = number[i] - '0';
        if (u % 2) {
            continue;
        }
        if (p == -1 || q > u) {
            p = i;
        }
    }

    if (p == -1) {
        print(-1);
    } else {
        swap(number[p], number[len - 1]);
        print(number);
    }

    return 0;
}

C. Anya and Ghosts

The background of this problem is quite twisted.

First of all, we have to find out in which scenario there is no way to defence against the ghost.

It’s easy to find out in that diagram above that if the duration of the candle is less than the number of candles which is needed.

So, before the ghost comes, we have to light up the candles. If we want to have K candles in one second, we have to light it up at second (T - 1) (T - 2) … (T - K).

import sys

(m, t, r) = map(int, raw_input().split())
ghosts = map(int, raw_input().split())

# impossible
if t < r:
    print -1
    sys.exit(0)

ans = 0
candles = [-1 for i in xrange(r)]

for ghost in ghosts:
    delay = 0
    for i in xrange(r):
        if candles[i] < ghost:
            candles[i] = ghost + t - 1 - delay
            delay += 1
            ans += 1

print ans

D. Tanya and Password

Tanya cut the password into three-letter continuous substrings. Our mission is to re-assemble these substrings.

For example,

Password: fuckme
Substrings: fuc, uck, ckm, kme

It’s not hard to find out that the problem is not about the “string” but the “graph”. But how to convert the string and substrings into a graph.

At the every beginning, we regard the substrings as vertexes, every two substrings which could be connected has an edge between them.

In this scenario, all we have to do is find a path that visit all the vertexes. This path is called Hamilton path. The algorithm to find a hamilton path in a graph is quite slow with O(2 ** N) time complexity. We have to find another way.

Similar to hamilton path, the eular path is a path that visit all the edges of the graph. And this inspires us to make the strings to another graph, and the eular path will be the final answer with the complete password.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>
#include <string>
#include <set>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x
#define err(x)   cerr << x << endl

const int BASE = 64;
const int SIZE = 64 * 64;

int g[SIZE][SIZE];
int iter[SIZE];
int father[SIZE];
int indeg[SIZE], outdeg[SIZE];
int n;
vector<int> ans;

int get_value(char c) {
    if ('a' <= c && c <= 'z') {
        return c - 'a';
    }
    if ('A' <= c && c <= 'Z') {
        return c - 'A' + 26;
    }
    if ('0' <= c && c <= '9') {
        return c - '0' + 52;
    }
    err("get_value_err:" << ' ' << c);
    return -1;
}

int get_char(int v) {
    if (0 <= v && v <= 25) {
        return 'a' + v;
    }
    if (26 <= v && v <= 51) {
        return 'A' + v - 26;
    }
    if (52 <= v && v <= 61) {
        return '0' + v - 52;
    }
    err("get_char_err" << ' ' << v);
    return -1;
}

int get_id(char a, char b) {
    int ia = get_value(a);
    int ib = get_value(b);
    return ia * BASE + ib;
}

void add_edge(const string& node_str) {
    int a = get_id(node_str[0], node_str[1]);
    int b = get_id(node_str[1], node_str[2]);
    g[a][b]++;
    outdeg[a]++;
    indeg[b]++;
}

int get_father(int x) {
    if (father[x] == x) {
        return x;
    }
    return father[x] = get_father(father[x]);
}

bool is_connected() {
    for (int i = 0; i < SIZE; i++) {
        father[i] = i;
    }

    for (int i = 0; i < SIZE; i++) {
        for (int j = 0; j < SIZE; j++) {
            if (g[i][j]) {
                father[get_father(i)] = get_father(j);
            }
        }
    }
    set<int> st;
    for (int i = 0; i < SIZE; i++) {
        if (!indeg[i] && !outdeg[i]) {
            continue;
        }
        st.insert(get_father(i));
    }
    return st.size() == 1U;
}

int get_start_point() {
    if (!is_connected()) {
        return -1;
    }
    int a = 0;
    int b = 0;
    int c = 0;
    int res = -1;
    for (int i = 0; i < SIZE; i++) {
        if (outdeg[i] == indeg[i] + 1) {
            a++;
            res = i;
        }
        if (outdeg[i] == indeg[i] - 1) {
            c++;
        }
        if (outdeg[i] == indeg[i]) {
            b++;
        }
    }
    if (a == 1 && b == SIZE - 2 && c == 1) {
        return res;
    }
    if (a == 0 && b == SIZE) {
        return 0;
    }
    return -1;
}

void dfs(int p) {
    for (int i = iter[p]; i < SIZE; i++) {
        if (g[p][i]) {
            g[p][i]--;
            dfs(i);
        }
        iter[p]++;
    }
    ans.push_back(p);
}

void show_path(int st) {
    string res;

    for (auto u: ans) {
        u %= BASE;
        char c = get_char(u);
        res += c;
    }
    char a = get_char(st / BASE);
    res += a;
    reverse(res.begin(), res.end());
    print(res);
}

int main() {
    input(n);
    string node_str;
    for (int i = 0; i < n; i++) {
        input(node_str);
        add_edge(node_str);
    }
    int u = get_start_point();
    if (u == -1) {
        print("NO");
    } else {
        print("YES");
        if (u == 0) {
            u = get_id(node_str[0], node_str[1]);
        }
        dfs(u);
        show_path(u);
    }
    return 0;
}

E. Arthur and Brackets

DP + Greedy

For this problem, be ware that the position of the right bracket is not the absolute position but the relative position. And according to the common sense, there will only be complete brackets between one left bracket and one right bracket.

For example,

RIGHT: *(* ()(()) *)*
WRONG: *(* ((((() *)*

So, it’s OK to close the bracket if possible. And this is the key to solve to problem.

n = int(raw_input())
brackets = [tuple(map(int, raw_input().split())) for i in xrange(n)]

res = ''
ptr = 0

INF = 0xcafebabe
st = []

for (l, r) in brackets:
    res += '('
    st.append((ptr + l, ptr + r))
    ptr += 1
    while st:
        (pre_l, pre_r) = st[-1]
        if pre_l <= ptr <= pre_r:
            res += ')'
            ptr += 1
            st.pop()
        else:
            break

if st:
    print 'IMPOSSIBLE'
else:
    print res

Sequence Median

2014-12-14T16:51:50+08:00

Description

Given a sequence of integer numbers, try to find the median of the sequence.

Extending

Make sure your code can get the right answer in any conditions
Make sure your code work effectively on some special kinds of sequence. For example, ordered sequence or a nearly ordered one, a sequence with few unique items.
If the memory is not large enough for all the elements in the sequence, how can we implement this algorithm?
If it’s not a sequence, but a data stream. How can we find the median?

Solution

Finding the median is quite similar to finding the kth element.

The basic solution to find the kth element is to sort the sequence first, and then find the kth. It’ll get the right answer, of course, but the time complexity is O(n * logn), which is not the optimized one.

There is a vintage algorithm to get the kth_element.

int partition(int array[], int st, int end) {
    int pivot = array[st];
    int l = st, r = end - 1;
    while (l <= r) {
        while (l <= r && array[l] <= pivot) {
            l++;
        }
        while (l <= r && array[r] > pivot) {
            r--;
        }
        if (l <= r) {
            swap(array[l++], array[r--]);
        }
    }
    swap(array[st], array[r]);
    return r;
}

int kth_element(int array[], int n, int k) {
    return kth_element(array, 0, n, k);
}

int kth_element(int array[], int st, int end, int k) {
    int pivot_idx = partition(array, st, end);
    if (pivot_idx - st + 1 == k) {
        return array[pivot_idx];
    }
    if (pivot_idx - st >= k) {
        return kth_element(array, st, pivot_idx, k);
    } else {
        return kth_element(array, pivot_idx + 1, end, k - (pivot_idx - st) - 1);
    }
}

double find_median(int array[], int n) {
    if (n & 1) {
        return 1.0 * kth_element(array, n, n / 2 + 1);
    } else {
        int a = kth_element(array, n, n / 2 - 1);
        int b = kth_element(array, n, n / 2);
        return 0.5 * (a + b);
    }

The time complexity of the algorithm is O(N). It works well in most conditions. But there is a potential error in the code, can you find it?

return 0.5 * (a + b);

If a + b is greater than INT_MAX, it will overflow, and make a mess to your code. The right way is：

return 0.5 * a + 0.5 * b;

There is another problem in the code. If the sequence is already ordered, the algorithm will take O(N^2) time, and can’t work effectively as what we design. It is because the pivot is the very first element of the sequence (or the sub-sequence), if the sequence is ordered, we will partition the sequence into this:

nil ++ pivot ++ [elements]

The solution is to use the random pivot. And we will modify the code here.

int partition(int array[], int st, int end) {
    if (st == end) {
        return st;
    }
    int pivot_idx = st + random() % (end - st);
    int pivot = array[pivot_idx];
    swap(array[st], array[pivot_idx]);

    int l = st, r = end - 1;
    while (l <= r) {
        while (l <= r && array[l] <= pivot) {
            l++;
        }
        while (l <= r && array[r] > pivot) {
            r--;
        }
        if (l <= r) {
            swap(array[l++], array[r--]);
        }
    }
    swap(array[st], array[r]);
    return r;
}

This code will perform well for the ordered / nearly ordered data. But there is another “however”, what if there are few unique elements in the sequence?

For example, the sequence [1, 1, 1, 1, 1, 1, 1]. If we deal this sequence by the previous algorithms, it also takes O(N) time, because we can just separate the sequence into this:

[elements] + pivot + nil

This scenario is similar as the previous one. So we have to come up a new way to cope with it.

int partition(int array[], int st, int end) {
    if (end - st <= 1) {
        return st;
    }
    int pivot_idx = st + rand() % (end - st);
    swap(array[st], array[pivot_idx]);
    int pivot = array[st];

    int l = st, r = end - 1;
    int flag = 0;
    while (l <= r) {
        // <- rewrite zone
        while (l <= r && array[l] <= pivot) {
            if (array[l] == pivot && flag == 0) {
                flag ^= 1;
            } else if (array[l] == pivot) {
                break;
            }
            l++;
        }
        while (l <= r && array[r] >= pivot) {
            if (array[r] == pivot && flag == 1) {
                flag ^= 1;
            } else if (array[r] == pivot) {
                break;
            }
            r--;
        }
        // <- end of rewrite zone
        if (l <= r) {
            swap(array[l++], array[r--]);
        }
    }
    swap(array[st], array[r]);
    return r;
}

This code could put the same number into left part and right part by half.

With all these optimization, you can get an Accepted in the problem POJ-2623. But be ware, the function to initizalize of random number, srand(time(NULL)), is disallowed when using the G++ compiler, please choose C++ instead.

There’s always something next, if we don’t have enough memory to storage all the data in the sequence. We will use a heap to find the kth_element, and that will save half of the memory space. But the time complexity is O(n * logn) here.

// This is a bad code :)
int main() {
    int n;
    long long x;
    input(n);
    int k = n / 2 + 1;
    priority_queue<long long> pq;
    for (int i = 0; i < n; i++) {
        scanf("%lld", &x);
        pq.push(x);
        if ((int)pq.size() > k) {
            pq.pop();
        }
    }
    if (n & 1) {
        printf("%.1f\n", 1. * pq.top());
    } else {
        long long a = pq.top();
        pq.pop();
        long long b = pq.top();
        printf("%.1f\n", double(a + b) / 2.);
    }
    return 0;
}

Okay, there is the last problem: what if the sequence is a stream that you have to find the median whenver a new number comes in? The solution is using two heaps. The max heap storages the numbers which less than the median, and the min heap storages the numbers which greater than the median.

template<typename T>
class MaxHeap: public priority_queue<T> {};

template<typename T>
class MinHeap: public priority_queue<T, vector<T>, greater<T> > {};

class MedianStream {
public:
    void add(int u) {
        if (_max_heap.empty() || u <= _max_heap.top()) {
            _max_heap.push(u);
        } else {
            _min_heap.push(u);
        }
        do_adjust();
        _size++;
    }
    double get_median() {
        if (_size & 1) {
            return 1.0 * _max_heap.top();
        } else {
            int a = _max_heap.top();
            int b = _min_heap.top();
            return 0.5 * a + 0.5 * b;
        }
    }
private:
    void do_adjust() {
        while (_max_heap.size() > _min_heap.size() + 1) {
            _min_heap.push(_max_heap.top());
            _max_heap.pop();
        }
        while (_min_heap.size() > _max_heap.size()) {
            _max_heap.push(_min_heap.top());
            _min_heap.pop();
        }
    }
private:
    size_t _size;
    MaxHeap<int> _max_heap;
    MinHeap<int> _min_heap;
};

类型-长度-值（TLV）协议

2014-11-17T00:25:42+08:00

在数据通信协议中，可选的信息或字段通常使用type-length-value（a.k.a TLV）元素来进行编码。

Type - 类型

用来标示字段类型的值，通常是一个二进制值或简单的字母

Length - 长度

字段长度，单位通常为Byte

Value - 值

一个变长的比特数组用来存储这个字段的值

优势

TLV序列方便遍历查找
新的字段可以无痛的加入现有的协议中。解析的时候，对于未知的字段，可以轻松的跳过。这点与XML类似
TLV元素的顺序可以是随意的
TLV元素通常使用二进制存储，可以使解析速度加快并且使数据更小
TLV可以与XML数据相互转换，易于人类阅读

例子

在这里，我们以protobuf的可选和变长字段为例。

field_number ++ wire_type

每一个protobuf的字段在传输时，都会加上field_number和wire_type这两个值，这两个值组成这个字段的key。

key = (field_number << 3) | wire_type

field_number标明了字段的编号，方便协议向前向后的兼容。而wire_type标明字段的类型，方便解析程序使用相应的方法来进行反序列化。

Varint 变长整型

对于一个变长整型字段，protobuf中使用Type(0)来标示，而长度并没有显式的标出。

Varint的值使用如下编码方法：

Varint使用分段存储方法，每个Byte为一段
Varint每段的第一个字节是标示位，如果这一位是1，则下一个Byte也是这个数的一部分，如果这一位是0，则在这个Byte是这个Varint的最后一个Byte

String 变长字符串

字符串被标示为Type(2)，长度使用Varint类型显式标出。

一个string在protobuf中被编码为：

encoded_string = key ++ length ++ string

其它方法

TLV同样也可以表示tag-length value，例如HTTP、FTP、POP3等协议都是使用这种基于可读文本的”Field: Value”协议。这样设计的原因大概是由于在“上古时代”，互联网速度远小于CPU处理的速率（现在更应该是远远小于，CPU已经爆了IO一条街了），设计一些更可读的协议对人类来说确实比较方便。

而TCP/IP核心协议都使用的定长不可变的协议，这样可以使编码、解析速率达到最快。

对于XML和json这种奇行种，我们就不说了吧 :)

参考链接

Reasons They Recruit

2014-11-16T01:03:14+08:00

From Ace of Programming Interview, Cpt1 - Hiring Programmers: The Inside Story

Establish a Rapport

For an interviewee, one the the most efficient way to build a rapport is to try to see things in from the interviewer’s perspective.

understand the motivation of the interviewer
establishing a common ground
adapting your responses appropritely

Reasons They Recruit

If you know what the reason is and understand the motivation for it, then you can optimize your approach accordingly.

Planned Expansion

This is a common scenario that the company’s expansion require them to take on more programmers accordance with the comming business growth.

The Interviewer vs. You

As the hiring is due to a long plan, so the interviewer is unlikely to feel a great sence of urgency. The interviewer will have a well prepared job description (a.k.a JD), or even a person profile. The interviewer are unlikely to compromise their pre-determined requirements. If you are deviate from their expectation, they will probable be less open to giving you the offer.

Your approach is to highlight these areas which matches to the job profile. That’s the easy part.

If your skills are not a good fit, you can use these three tricks below to change the situation.

Play it down

Your first choice is to downplay the perceived gap in skills – including the option of substituting other experience as being of equivalent value.

For example,

“It’s been my experience that it never takes long to learn the basics of a new component library, since, as programmers, we face an endless supply of new components and frameworks both open source and from the major vendors.”

or,

“One thing I really like about programming is the experience of learning new
technologies and platforms. It’s part of the ongoing attraction of the job.”

However, the biggest risk in taking this approach is that you might appear evasive, so be wary of overdoing it.

Take it on the chin

If you decide to take it on the chin, simply agree with the interviewer’s observation and at the same time show your enthusiasm for learning something new.

“I don’t have experience of that particular technology but I would really enjoy learning it.”

If the interviewer persists, you might feel it appropriate to ask how other developers in the team might learn new things.

“Could you describe how the developers in your team generally learn new skills?”

Each example the interviewer gives you is an opportunity to show how, as a part of the team, you would benefit the same approach and so acquire the necessary skill.

Understand the requirement

Your third option is to gently probe the motives underpinning the requirement. The basic idea is that you explore the requirement looking to show that you understand and can meaningfully address the underlying requirement despite lacking a specific skill or experience.

Whatever approach you take, keep in mind that you should not dwell on any particular mismatch. In particular, keep you comment brief and to the point. The more you talk about it, the more prominence it will have in the interviewer’s memory of the interview when they reflect afterward.

Specific Projet

When a company spots an opportunity in the market, it might scramble to put
together a development team focused on delivering a solution to capitalize on
the opportunity.

The Interviewer vs. You

The interviewer wants to know that you can work under pressure, and that you are someone who finishes what you start. Sometimes that the pressure to hire can relax the strictness with which the interviewer will match your experience against the details of job specification, although of course you can’t assume that case.

Be ware that although you have to demonstrate how your skills and experience are good match for the position, the interviewer also probable has the need of specific project in mind. You enthusiasm and ability to adapt might count for more than usual. Showing an ability of grasp key aspect of project give you an advantage over others.

If you are not sure of the motivation of hiring, there’s absolutely no harm to ask directly:

Could I ask why you are recruiting? Is it for a specific project?

Replacing Someone

This is another common reason for hiring simply to replace someone who is leaving or has left the company.

The Interviewer vs. You

An interesting aspect of this situation is that they will probably have experience of a previous person i lling this role, for better or for worse, and will therefore have a list of things they want to ensure the next person will and won’t bring to the role.

Unless you are very lucky, you can’t gather insight into what interviewer like or dislike prior to the interview. What you can do at the interview is ask about unique challenge for the role, things for which you might to need to be on guard, and so on:

“Could you tell me a bit about the challenges of this role that might make it different from the usual programming job?”

If you ask right questions, you may get vatal clues about the things you need to highlight with regard to your experience and ability:

“Can I ask whether there have been issues about how the team has been working together that make this ability particularly important?”

Quora - What are effective ways to assess if someone is good at "getting things done"?

2014-11-15T16:08:10+08:00

Ian McAllister, GM at Amazon. I lead the AmazonSmile program.

First, let’s break “getting things done” into two components: “excellent functional skills” and “drive”. Someone with great functional skills but poor drive will not get (enough) things done. Someone with great drive but poor functional skills will not get things done, or they’ll do the wrong things, or they’ll do the right things shittily.

Excellent functional skills

You can probe for domain knowledge and functional skills effectively in an interview or on a phone call. You come up with a list of role-specific responsibilities, probe deeply (several levels below the surface) into past examples where they’ve done similar work, and give them example challenges and see how they perform. You can make allowances for language or tool by letting them pick the language or tool of their choice, but don’t give them a pass on accomplishing the task set forth.

Drive

Drive is tougher to gauge effectively. You’ll have to form a picture of drive based on a number of different signals, and use your judgment on how heavily to weight each one.

Projects they’ve initiated - Are they spawning new projects, based on their own ideas or prototypes? If so, that’s evidence they’re pushing the boundaries of their role in good ways. If they haven’t, then they might make a good soldier, but you’ll know going in that they’ll always need someone to tell them what to do next.

Variation in projects or roles - Have they worked on the same types of projects for 5+ years? If so, they might have deep knowledge and be able to get things done in that domain, but it is evidence that they have a comfort zone. They clearly don’t have a drive to leave or expand their comfort zone, and may not be effective if your role places them outside of it. Look for evidence that a candidate has initiated some type of change in the type of work they do.

Progression in complexity of projects or roles - Someone good at getting things done gets more done over time. Often the results of this are not more projects, but projects of larger scope and complexity. A good résumé will show this, but you can also probe for it explicitly.

Side projects - I have a hard time hiring engineers, web developers, or designers (maker roles) who don’t have a history of side projects. These days, if you’re hiring a young engineer you’re looking for one who has been coding since she was twelve (or younger).

I intend to add more signals as I think of them, but hopefully these are a start.

The Checklist of Steve Yegge

2014-10-26T00:24:44+08:00

Hey man, I don’t know that stuff

Stevey’s talking aboooooout

If my boss thinks it’s important

I’m gonna get fiiiiiiiiiired

Oooh yeah baaaby baaaay-beeeeee....

非技术部分

热身

好好读一本讲数据结构和算法的书

熟悉一些“术语”，可以强化分辨问题的能力。

Yegge推荐了 Steven S. Skiena 的《算法设计手册》，而我推荐的是
Udi Manber 的《算法引论》。

每一本书都有它的长处短处。找一本评价不错的书，认真读完，肯定会有收获。

找个朋友来面试你，尝试白板编程

在白纸/白板上编程的体验和在计算机上大有不同。没有条件的情况下，试试Leetcode的“Pick one”，然后在白纸上练习吧！

在面试前保持警醒，充分热身

读读书记
喝点咖啡，这可以让你的思路快一些

心理准备

保持谦逊、开明、专注的态度

不要质疑面试官的水平，但是也不要害怕问问题。问一个蠢问题总比沉默僵持半小时要好的多。况且，一个好问题也许还是一个加分项。

并且，不要尝试去转移话题，把注意力放在问题本身。

了解面试官对代码的要求

有的面试官不会要求你写代码，但是他们希望你在回答问题时写一点代码。如果你不能确定，不妨直接问一下。

不同的面试官对于面试代码风格的要求是不一致的，对于苛刻的面试官，最好提高对代码的要求。并且仔细检查。

问问题的艺术

在面试中的有不清楚的地方是可以问的（并且问问题是被鼓励的），有时候还可以去和面试官确认自己是不是在正确的方向上。

什么都不问，直接冲到白板前开始写代码有可能会留下“设计无用”的坏印象。所以，即使你确定自己怎么做，也要先说说自己是怎么样的。但是，也不要说的太多。

自带高级装备

细头可擦马克笔
铅笔和橡皮

在面试中要使用一切可以使用的资源，例如白板上的空间管理。

技术部分

算法

大O
排序算法 —— 快速排序和归并排序
哈希表
树 —— 构造和遍历
至少熟悉一种平衡二叉树 —— 必须掌握实现细节
图 —— 存储与遍历，Dijkstra和A*

每次遇到问题，首先应当考虑的就是图算法。它们是任何关系最基本、最灵活的表示方法，任何有点意思的设计问题可以说有一半的机会涉及图算法。只有在你百分之百确定没办法用图算法来解的时候，才能去考虑其它方案。这条建议一定要牢记在心！

NP问题 —— 应该知道NP完全问题是什么意思
好好读数据结构书，能记多少记多少
离散数学 —— 计数问题、概率问题

计算机基础知识

操作系统

进程、线程、并发
锁、互斥锁、信号量，管程机制
死锁和活锁
进程和线程各需要什么资源、上下文切换、调度

作者推荐了 Doug Lea 的《Java并发编程》，做为一个Java hater，我决定还是勉为其难的看一下吧。:)

语言

至少要熟练掌握一种编程语言，最好是C++或者Java。并且一定要对那门语言的细节有相当程度的了解。

其它的基础知识

在作者的文章中没有提到的，但是也许比较重要的知识。

CS专业第二重要的知识 —— 编译原理
计算机网络 —— TCP/IP协议也许是个重点
数据库的一些知识
MapReduce？

其它

剩下的基本就是看脸了。。。

总结

好好热身。实际工作只会让你反应迟钝！

Snake Problem

2014-10-20T09:11:27+08:00

题目

在一个平面上，有n+m条蛇，其中n条蛇沿水平方向（y轴方向）移动，m条蛇沿竖直方向（x轴方向）移动。

现给出这些蛇头和尾所在的坐标点，求出这n+m条蛇在此时共有多少个交点。在同一个方向移动的蛇不会有交点。

如图所示，n = 5, m = 4，这些蛇一共有5个交点。

分析

对于此题，最简单直接的方法就是枚举蛇两两之间的关系，这种算法的时间复杂度为O(n^2)。

当然，我们不能满足于这种暴力的解法。那么，有没有更优美的方法呢？

对于这一条在y轴方向上的（红）蛇来说，它与x轴方向上的（黑）蛇共有三个交点。那么，也就意味着，问题的关键在于，我们如何快速确定某一条红蛇（或黑蛇）与其它蛇一共有多少个交点。

我们可以做出如下假设，我们知道当x = k时，所有在平面上的蛇的位置。根据这个假设，我们可以使用区间求和的算法来确定竖直位置上的蛇会有多少个焦点。

假设我们从x = 0到x = MAX_X方向进行扫描，每条蛇在扫描时，都有且只有两种状态：

扫描线第一次经过蛇的某端点
扫描线第二次经过蛇的另一个端点（废话！）

这两个状态分别意味着某一条黑蛇在x = k时是否存在。我们维护一个数组，数组中第u个元素代表y = u的黑蛇是否在x = k时存在。

这个时候，当我们查询一条x = [v, w]位置的红蛇共有多少个交点时，只需要计算数组中[v … w]元素的和。而使用树状数组(Binary Indexed Tree, BIT)，每次这样的查询只需要O(logN)时间。

所以，总的时间复杂度为O(N * logN)，比O(N^2)的算法优化了很多。

代码

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 1024;

inline int lowbit(int x) { return x & (-x); }

struct BITree {
    int _tree[SIZE];
    void init() {
        memset(_tree, 0, sizeof(_tree));
    }
    void add(int x, int p) {
        while (p < SIZE) {
            _tree[p] += x;
            p += lowbit(p);
        }
    }
    int sum(int p) {
        int res = 0;
        while (p > 0) {
            res += _tree[p];
            p -= lowbit(p);
        }
        return res;
    }
    int sum(int a, int b) {
        return sum(b) - sum(a - 1);
    }
};

struct Point { int x, y; };
struct Snake { Point start, end; };

class Solution { // manual tested
public:
    int count_intersection(const vector<Snake>& xsnakes,
            const vector<Snake>& ysnakes) {
        int ans = 0;
        _tree.init();
        vector<Mark> vec;
        for (auto s: xsnakes) {
            vec.push_back(Mark({s.start.x, 1, s.start.y}));
            vec.push_back(Mark({s.end.x,  -1, s.end.y}));
        }
        int p = 0;
        for (auto s: ysnakes) {
            vec.push_back(Mark({s.start.x, 0, p++}));
        }
        sort(vec.begin(), vec.end());
        for (auto mark: vec) {
            if (mark.type == 1) {
                _tree.add(1, mark.val);
            } else if (mark.type == -1) {
                _tree.add(-1, mark.val);
            } else {
                p = mark.val;
                int a = ysnakes[p].start.y;
                int b = ysnakes[p].end.y;
                ans += _tree.sum(a, b);
            }
        }
        return ans;
    }
private:
    struct Mark {
        int pos, type, val;
        friend bool operator < (const Mark& a, const Mark& b) {
            return a.pos < b.pos;
        }
    };
    BITree _tree;
};

int main() {
    vector<Snake> xsnakes({
        Snake({ Point({1, 2}), Point({5, 2}) })
    });
    vector<Snake> ysnakes({
        Snake({ Point({2, 1}), Point({2, 3}) }),
        Snake({ Point({3, 1}), Point({3, 3}) })
    });
    Solution S;
    print(S.count_intersection(xsnakes, ysnakes));
    return 0;
}

题目来源

《算法引论》

扩展题目

POJ-2482 Stars in Your Window

思维训练 - Thinkin' in induction 2

2014-10-01T00:05:29+08:00

最大导出子图（maximal induced graph）

你现在在组织一个学术会议。现在你有一份人员名单。假定名单中的每一个人都同意到达，并且有充足的时间交流意见。同时，每一个科学家都写下了他愿意与其进行交流的科学家的名字。

现在，问题来了：~~挖掘机技术哪家强？~~

如果要保证每一位科学家至少能与k位到场的科学家进行深入的交♂流♂。那么我们最多可以邀请多少人到会？

注：如果A愿意和B交流，AB一定会进行交流。反之亦然。

我们可以把问题转化成数学语言：对于一个无向图G=(V, E)，试求得G的最大导出子图H，使得H中所有顶点的度大于或等于k，或者证明这样的子图是不存在的。

我们继续使用归纳的思想来解决这个问题。

易得，对于顶点数为k的图，如果存在k-导出子图，则该图必为一个完全图。

假设，对于任意顶点数小于n的图，我们总可以找到图的k-最大导出子图。

对于有n个顶点的图G来说，如果有任意顶点的度小于k，那么对于图G的任意子图，此顶点的度总小于k。

所以，对于图中任意度小于k的点，必然不属于所求的子图。于是，我们每次删除一个不属于k-导出子图的点，就可以把有n个顶点的图问题化归为n-1顶点的图问题。

一对一映射

给定一个集合A和一个映射关系f。求A的一个子集S，使得f对于S是一个一对一映射。即：f把S中的一个元素映射到一个元素；S中没有两个元素映射到同一个元素。

我们仍然可以做假设：对于含有k个元素的集合，我们有方法找到所求。

基础情况的证明非常简单，对于一个点的情况，f(A) = A满足条件。对于两个点，找到两个点(A, B)，在图中有(A -> B)和(B -> A)即可。

对于任意集合，我们可以确定，当没有f(x) = i时，元素i必然不属于这个集合。所以，每次操作我们都删除掉必然不属于所求子集的那个点，把问题Q(n)化归为子问题Q(n-1)。

社会名流问题

社会名流都是逼格比较高的人，这体现在所有的人都认识他，但是他不认识任何人。

试在n个人的聚会中，找出唯一的名流。而找出的名流的方法，就是询问任意一个人：Do you know that person? 每一个人都会如实回答。而你的目标是使询问次数最少。

我们仍然使用归纳的方法，如果这个聚会只有两个人，我们很容易就知道谁不是名流。(Why?)

对于一般的情况，如果询问A：Do you know person B?

如果A回答YES，那么A必然不是名流。如果A回答NO，那么B不是名流。

如是，我们又可以一步一步缩小题目的数据范围。最后在排除了所有不是名流的人之后，对最后一个候选人再进行一轮验证。

总结

以上三题都是Thinkin’ in induction的良好范例。对于有些题目，做出大胆的假设并不是纯粹的碰运气，而是一种科学的尝试。同时，在思考时，如果不能直观的找出“谁是对的“，我们不妨反向思考一下，找出“谁是不对的”。

本文参考Udi Manber的《Introduction to algorithms - A creative approach》.

思维训练 - Thinkin' in induction

2014-09-26T00:10:45+08:00

热身题 - 24Game

原题请戳我

题意

给你一个包含整数1…n的集合S。接下来进行n-1次操作，每次操作从集合S中选取两个数，在加、减、乘三种运算中选取一种，将结果放回再集合S。在n-1次操作完成后，集合S中只剩下一个数。求问一种取数和运算策略，使最后的结果为24。

举例：

S = [1, 2, 3, 4, 5]

我们选取(2, 5)，并进行加法运算，获得结果7。再将7放回集合S中。

此时，S = [1, 3, 4, 7]。

数据范围

1 <= n <= 100000

解答

建议：请思考10分钟后再来看答案

我们日常写代码，往往是为了实现一个功能或者实现一套逻辑。这时候，我们做的事一般是从零开始，然后逐步迭代，最终实现目标。

这是正常的一种思维方式，也是不错的思维。但是，在我们做题时，按部就班的思路往往会束缚我们的想法。我经常自黑说：“做什么题都像做模拟题”，实际上就是这样一个道理。

对于此题，如果我们从零开始思考，必然会遇到“第一次选哪两个数”、“第二次选哪两个数”这样的问题，而解决这种问题的方式大多只能有暴力搜索一种方式。而根据这题的数据规模，暴力搜索在时间和空间上都是不可能的。

当然，也有的同学善于逆向思维，但是，同样也会进入暴力搜索的死路中。

那么这题如何思考呢？我们不妨试试归纳法。

假设n = k，并且有f(k)，使得f(k)=>24。那么，易得，对于f(k + 2)=>f(k) * ((k + 2) - (k + 1))=>24。

此时，我们只需要找到f(k)=>24，就可以证明所有f(k + 2x) => 24。聪明的同学们必然可以手动算出f(4) = 24的过程，这可以证明对于所有k >= 4的偶数，总有f(k) => 24。

f(5) => 24略微复杂一点，但是也不在话下。这样我们的结论已经扩展到了k >= 4的所有整数。

又由于在k = [1, 2, 3]时，f(k)必须不能推出24。我们的结论已经推广到了所有正整数。此题得证。

归纳法

在Udi Manber的_Introdcution to Algorithms - A creative approach_一书中，在第二章就对数学归纳法进行了大篇幅的的讲解。而在一般的算法书中，这个位置往往是给了算法分析。

归纳法是一种“非常有力的证明方法”，可以提供一种想问题的方法，同时可以证明算法的正确性。

归纳法的基本过程如下：

Let T be a theorem we want to prove.

Suppose that T includes a parameter n whose value can be any natural number.

Instead of proving directly that T holds for all values of n, we prove the following two conditions:

T holds for n = 1

For every n > 1, if T holds for n - 1, then T holds for n

归纳法应用 —— 笛卡尔树

已知一个最大堆的中序遍历序里，要求恢复该最大堆。

或者用另外一种方法来表示，

给定一个数组，求一个二叉树，这个二叉树的父节点总比子节点要大，并且这棵树的中序遍历与原数组相同

如果我们从build from scratch的角度来思考这个问题，那么得出来的结论一定是O(n^2)的 —— 每次找到（子）数组的最大值，然后partition这个数组，直到构造出整棵树。

换一种思考方式

我们尝试用归纳法的思维去考虑这道题。假设我们已经有一棵树，这棵树满足上面所说的条件，且这棵树展开后为数组的前k项。

此时，我们想要插入第k+1项，有以下几种情况。

A[k+1] <= A[k]，此时第k+1项会成为到第k项的右儿子，这样树展开时，第k项和第k+1项必然相联，并且也满足父节点必须比子节点大的条件。
A[k+1] > A[k]，第k+1项必然会成为第k项的左儿子。但是我们还需要考虑，第k项的父节点比第k+1项小的情况。经过思考，我们不难发现，第k+1项的左儿子t，一定是第k项祖先节点中小于第k+1项的最大值。而第k+1项则替换掉节点t的位置。

情况一示意图：

情况二示意图：

由此一来，原本看起来复杂的思路一下子变的简单。我们可以把一个复杂的问题化归到重复的子问题上来。这样我们只需要每次解决一个问题了。

关键代码如下：

class Solution {
    // ...
    TreeNode* do_insert(int v) { // one node at a time
        TreeNode* ptr = NULL;
        TreeNode* now = new TreeNode(v);
        while (!st.empty()) {
            ptr = st.top();
            if (ptr->value > v) {
                now->left = ptr->right;
                ptr->right=now;
                st.push(now);
                return root;
            }
            st.pop();
        }
        now->left = ptr;
        st.push(now);
        root = now;
        return root;
    }
    // ...
};

课后习题 - 最大子段乘积

这是Leetcode新加的一题，在昨天吃撑了喝醉了的情况下，勉强AC，今天看来，自己还是too young too simple啊。

给你一个int数组，求这个int数组的最大子段乘积。（不需要考虑溢出）

从零开始的想法

最大子段乘积必然是一段不含有0的子段。所以我们可以把子段分割为k段，每一段都不包含0。

对于每一个子段，要满足两个条件，一是尽量为正，二是尽量包含更多的数。

所以对于子段A[l…r]，最大乘积只能为A[m…r]或A[l…m]两种情况。所以我们维护两个指针，就可以求得最后的结果了。

不过。。。等下。。。这真特么twisted啊。。。_(:з」∠)_

class Solution { // a drunk moron who wrote this
public:
    int maxProduct(int A[], int n) {
        int p = 0, q = 0;
        int ans = -INF;
        int pro = 1;
        for (int i = 0; i <= n; i++) {
            if (i != n && A[i] != 0) {
                pro *= A[i];
                ans = max(pro, ans);
                q = i + 1;
            } else {
                if (i < n && A[i] == 0) {
                    ans = max(ans, 0);
                }
                while (p < q) {
                    pro /= A[p];
                    p++;
                    if (p == q) {
                        break;
                    }
                    ans = max(pro, ans);
                }
                p = q = i + 1;
            }
        }
        return ans;
    }
private:
    static const int INF = 0x3f3f3f3f;
};

用归纳法解决这个问题

让我们做一个假设，对于A[k]来说，我们已知mini = min(A[i...k])和maxi = max(A[i...k])。mini和maxi是以k结尾的子段中，乘积绝对值最大的负数/正数。所以无论乘一个负数还是一个正数，maxi和mini的值只会是maxi * a和mini * a。

那么，对于第k+1项来说，以第k+1项结尾的最大子序列必为max(mini * A[k+1], maxi * A[k+1], A[k+1])(mini和maxi可能为0)。

同时，我们继续维护mini和maxi两个值。此时，我们就有了一个循环的子问题。代码也就在我们的笔下了。

class Solution:
    def maxProduct(self, A):
        mini, maxi = (1, 1)
        ans = -0xdeadbeef
        for a in A:
            mini *= a
            maxi *= a
            ans = max(ans, mini, maxi, a)
            mini, maxi = min(mini, maxi, a), max(mini, maxi, a)
        return ans

最小表示法及其证明

2014-09-17T00:46:16+08:00

问题

对于一个字符串S，求S的循环的同构字符串S’中字典序最小的一个。

我们举例说明，字符串”abcd”的循环同构字符串有：["abcd", "bcda", "cdab", "dabc"]。

题目的目标是求这些字符串中字典序最小的那个。

暴力解法

暴力解法非常直观，直接枚举字符串的起点，然后找到构成最小字符串的那一个。

代码就不在这里写了。

最小表示法

最小表示法是解决同构字符串最小表示的巧妙算法。

其算法描述如下：

令i=0,j=1
如果S[i] > S[j] i=j, j=i+1
如果S[i] < S[j] j++
如果S[i] == S[j] 设指针k，分别从i和j位置向下比较，直到S[i] != S[j]
         如果S[i+k] > S[j+k] i=j,j=i+1
         否则j = j + k + 1
返回i

初看这个算法，一般都会一头雾水：这TMD是嘛玩意儿？

但是我们可以经过证明，来证实它的正确性。

最小表示法的正确性证明

首先，S = S ++ S

设i < j，且S[i] < S[i + 1 ... j - 1]。

并且以i为起点的字符串为RS[i]，以j为起点的字符串为RS[j]。

且RS[i]为RS[0...i-1]字典序最小的。

RS[i] = S[i...i+k] ++ S[i+k+1 ... i+n-1]
RS[j] = S[j...j+k] ++ S[j+k+1 ... j+n-1]

以上为我们的子问题。

i = 0, j = 1时，子问题即成立。

情况0

易得。

当S[i] < S[j]时，j++。

当S[i] > S[j]时，i = j; j++。

情况1

S[i+k+1 ... i+n-1] == S[j+k+1 ... j+n-1]。

此时易得，字符串S是由一个长度为k的子串循环复制生成。所有的同构子串只有RS[i ... j-1]这k个，又由于RS[i + 1 ... j - 1]的所有字符串都字典序大于RS[i]。所以i即为最后的答案。

情况2

S[i+k+1 ... i+n-1] > S[j+k+1 ... j+n-1]，那么此时RS[i] > RS[j]。

由于S[i...i+k] == S[j...j+k]，且这两个前辍中，只有S[i] == S[j]字典序最小。

所以i指向j点，保持最小性质。而j则指向j + k + 1。

保持i < j，且S[i] <= S[j]的性质。使问题回到我们归纳的子问题上来。

情况3

S[i+k+1 ... i+n-1] < S[j+k+1 ... j+n-1]，那么此时RS[i] < RS[j]。

由于S[i...i+k] == S[j...j+k]，且这两个前辍中，只有S[i] == S[j]字典序最小。

所以i不变，保持最小性质。而j指向j + k + 1。

保持i < j，且S[i] <= S[j]的性质。使问题回到我们归纳的子问题上来。

代码

// Result: wizmann  1509    Accepted    272K    16MS    C++ 1247B   2014-09-17 00:44:22
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <string>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 12345;

char instr[SIZE];

int solve(const char* str, int n)
{
    if (n <= 1) {
        return 0;
    }

    int p = 0, q = 1;
    while (p < n && q < n) {
        if (str[p] < str[q]) {
            q++;
        } else if (str[p] > str[q]) {
            p = q;
            q++;
        } else {
            int i, l = p, r = q;
            for (i = 0; i < n; i++) {
                int ll = l % n, rr = r % n;
                if (str[ll] < str[rr]) {
                    q = r;
                    break;
                } else if (str[ll] > str[rr]) {
                    p = q;
                    q = rr;
                    break;
                }
                l++; r++;
            }
            if (i == n) {
                break;
            }
        }
    }
    return p;
}

int main()
{
    int T;
    input(T);
    while (T--) {
        scanf("%s", instr);
        int u = solve(instr, strlen(instr));
        printf("%d\n", ++u);
    }
    return 0;
}

后记

证明的逻辑性不好，但是应该是对的。只是语言表达上问题很大。
有一个好的子问题假设会大大提升做题效率啊！

参考链接

理解字符串循环同构的最小表示法

System Design - 最热门的IP地址

2014-08-08T01:25:54+08:00

写在前面

问题是非常流行的，也确实流行了一阵的system-design问题。在知乎上再次被人提起。然后我非常欣赏陈硕的回答。所以要写一篇文章，记下自己的感想。

问题

海量数据算法:如何从超过10G的记录IP地址的日志中，较快的找出登录次数最多的一个IP？

银弹？

面对这种system-design问题，尤其是这种，非高并发、非实时的问题，很多人会采用_map-reduce_ —— 解决system-design问题的银弹。

我对map-reduce的理解非常肤浅，但是可以解释一下大概的流程。

将日志进行分片。把hash(ip)相同的ip地址分到同一个片中。（注：这里的hash并不是签名函数，只是一个分片标示）
分片后的日志的大小会小很多，可以方便的进行排序，记数。
然后再从各个片中，统计出最热门的IP地址。（或TopK的IP地址）

如果不满意我的答案的话，推荐Mining of Massive Datasets一书，其中对map-reduce算法做一番不错的介绍。

正确的分析姿势

业务实体

业务实体拥有四种主要的组件：信息模型、生命周期模型、访问策略以及通知。

换句话说，业务实体就是题目中提到的“名词”。

在本题中，业务实体有：

IP地址（默认为ipv4）
最热门IP地址

业务应用

业务应用指的是当前场景的特殊应用，以及业务实体的关联关系。

在本问题中，业务应用指的是：

找到最热门的IP地址
大数据量，10G的日志文件 —— 不方便在内存中进行操作
（在动辙上百G的服务器面前，10G的数据量真是弱爆了^_^)

物理

物理指的是数据的物理模型，包括数据结构、数据库表等。

在本题中，指的是对IP地址存储和记数的数据结构。

让我们做一下分析

本题中，业务实体的特点是：

IPv4可以由一个uint32_t来表示
ip地址是稀疏的
- 大部分ip地址的访问次数非常少（长尾）
- 很多ip地址是保留地址，所以不可能出现在日志中

业务应用的特点是：

“最热门”表示要求得精确解，而不是满意解
内存限制

应用的物理结构的特点是：支持存储与记数

无代码无真相

#include <assert.h>
#include <stdint.h>
#include <stdio.h>
#include <vector>

static_assert(sizeof(void*) == 8, "64-bit only.");

std::vector<uint8_t> counts_;
struct IPcount
{
  uint32_t ip;
  uint32_t count;
  bool operator<(IPcount rhs) const
  { return ip < rhs.ip; }
};
std::vector<IPcount> overflows_;

IPcount top;

void addOverflow(uint32_t ip)
{
  IPcount newItem = { ip, 256 };
  auto it = std::lower_bound(overflows_.begin(), overflows_.end(), newItem);
  if (it != overflows_.end() && it->ip == ip)
  {
    it->count++;
    assert(it->count != 0 && "you need larger count variable");
    newItem.count = it->count;
  }
  else
  {
    overflows_.insert(it, newItem);
  }
  if (newItem.count > top.count)
    top = newItem;
}

void add(uint32_t ip)
{
  if (counts_[ip] == 255)
  {
    addOverflow(ip);
  }
  else
  {
    counts_[ip]++;
    if (counts_[ip] > top.count)
    {
      top.ip = ip;
      top.count = counts_[ip];
    }
  }
}

uint32_t getMostFrequenntIP()
{
  return top.ip;
}

int main()
{
  assert(counts_.max_size() > 0xFFFFFFFFUL);
  counts_.resize(1L << 32);
  printf("%zd\n", counts_.size());

  add(0x1);
  add(0x2);
  add(0x2);
  for (size_t i = 0; i < (1L << 32)-1; ++i)
    add(0x3);
  printf("%08x %u\n", top.ip, top.count);
}

从代码说开来

这段代码不算最漂亮，有几个小槽点，但也算是非常优雅的。

从思路上说，这段代码注意到了我们刚才分析到的，这个问题的业务特点。

ipv4地址可以存在uint32_t中，无需存储字符串
ip地址是稀疏的，所以使用一层uint_8进行哈希记数，对于少数的热门ip再进行uint32_t计数
（同时考虑了ip地址的稀疏性以及内存的限制，并且对内存的优雅使用，可以提高缓存的命中率，提高效率）
使用精确计数，获得正确解

代码留给我们的思考题

练习：找出 worse case，让运行时间长达几分钟甚至十几分钟，然后提出并实施改进措施

由于我们拿不出real world中的data，所以很多分析都是纸上谈兵，不过一切的实践也都是从纸上谈兵开始。

题目中的std::vector<IPcount> overflows_;使用unordered_map更好，减少查找的时间（O(logN) => O(1)），并且减少插入的时间（O(N) => O(1)）
std::vector<uint8_t> counts_;可以在适当的情况调整为uint16_t，可以减少哈希节点生成对于内存的频繁申请。

后记

题目中的分析有很多是“执果索因”的成果，毕竟反推比正推要更容易一点。

想要从反推提升为正推，真的需要良好的发散思维以及敏锐的洞察力。因为面试时，没人会把题目帮你写在纸上。

话说，我才知道ipv6是128位的。那么当题目中的ip地址为ipv6时，又会有什么好方法呢？

参考链接

介绍：业务实体和业务实体定义语言

Single Number Problem

2014-08-05T23:07:02+08:00

Introduction

There are a lot of interview problem based on the 1D-array, which is the one of the easiest “data structure”.

But the problem about that simple data structure might not be that simple. Here is the summary of the problem about 1D-array.

Of course, most of them come from Leetcode.

All Twice Excpet One

Given an array of integers, every element appears twice except for one. Find that single one.

This problem is the very basic one. So I just paste my code here. If you are confused with the xor operator， you might have to review the knowledge of bit manipulation carefully.

class Solution:
    # @param A, a list of integer
    # @return an integer
    def singleNumber(self, A):
        return reduce(lambda x, y: x ^ y, A)

Time complexity: O(n)

All Once Except One

Given an array of N integers, which are in the scope of [1…N - 1]. Every element in the array appears once except one. Find that number.

This one is simple enough. But it looks a “hard” problem because we can solve this by using the previously “xor”.

It’s easy for us to calcuate the summary of the array [1…N - 1], and easy enough to calculate the summay of the given array as well. And the answer is the diffrence of the two summary.

class Solution:
    # @param A, a list of integer
    # @return an integer
    def singleInteger(self, A):
        n = len(A)
        return sum(A) - sum(range(n))

Time complexity: O(n)

p.s. xor(A) ^ xor(range(n)) is better if we have a large N that might overflow when we add all the elements.

Given an array of integers, every element appears once except for one which appears twice. Find that special number.

This problem is harder because all numbers in the array is arbitrary. And it seems hard to find any rules and patterns in the array.

I don’t know there is an algorithm which is O(1) space and O(n) time complexity. Tackle it with a hash set may be the best solution, which takes O(n) space and O(n) time complexity.

All three times except one

Given an array of integers, every element appears three times except for one. Find that single one.

To slove this problem, just using an array of size 32 to keep track on the total count of the ith bit.

And a tricky solution to reduce the memory usage is use three integers to indicate the remainder of 3 of the total count of the bits.

int singleNumber(int A[], int n) {
    int ones = 0, twos = 0, threes = 0;
    for (int i = 0; i < n; i++) {
        twos |= ones & A[i];
        ones ^= A[i];
        threes = ones & twos;
        ones &= ~threes;
        twos &= ~threes;
    }
    return ones;
}

All twice except two

Given an array of integers, every element appears twice except for two. Find that two numbers.

xor(array) = 0 ^ a ^ b

This problem is an update of “All twice except one”. It’s easy to prove that if there is an “1” in the bits of xor(array), it indicates that a and b are diffrent on that bit. We can separate the whole array by that bit, and then we can get two arrays which each contains a single “single number”.

Once, twice, three times a lady

Given an array of integers, some of the numbers appear once, and some appear twice, and the others appear three times. Please find the number which appear three times.

Of course, hash map is a panacea, with O(n) space and O(n) time.

And there is another way to solve this problem with O(1) space and O(n) time. But it has its limitation – integer overflow. If the max number of this array is too large, it can’t be done.

from random import randint
from collections import Counter

N = 100

ns = [randint(0, N - 1) for i in xrange(N)]
counter = Counter(ns)

for i in xrange(len(ns)):
    num = ns[i] % N
    ns[num] += N

d = {}
for i in xrange(len(ns)):
    cnt = ns[i] / N
    if cnt:
        d[i] = cnt

print d == dict(counter)

Considering the number ns[i] with the index i and with the value val. We make ns[i] = count(i) * MAX + val. By that, we can get the count of number i by ns[i] / MAX, and get the value of ns[i] by ns[i] % MAX.

And it’s the same to find the “missing number of an array of [1 … n]`` or something like that.

Summarize

Hash Map is PANACEA

Almost every problem on the array which want you to detect a single / two / or more “special” number can be tackled by the Hash Map. Easy and fast.

But for almost every problem, a hash map may no the very BEST solution.

Bit Map takes less memory

An update for the hash map is the bit map. It takes less memory, but can storage less infomation, 0 or 1. Further, you can treat several bits as one to put more information in it.

By its very nature, bit map is the same with hash map.

More powerful tool: Bloomfilter

Bloomfilter is a powerful algorithm / data structure which is used to slove the “in / not in” problem, and takes less memory than hash map, and can do better than bit map if the data is sparse and random.

But it can’t keep way the randomizing error called false positive, and if you can put up with that error and want to reduce your memory usage, try that.

I didn’t mention this in my passage, but you can find some information on this wikipedia page. It’s easy.

xor and bits manipulation

xor is a good way to solve the “only one appear once” problem. And xor manipulate will never cause overflow which will ruin your whole program.

just calculate the sum of the array

Somethimes we just forget the simplest way to deal with a “hard problem”.

For example, once I was asked “give you three integers (a, b, c), and calculate how many (x, y, z) is possible to make ax + by + cz == R”.

I’m glad because it is so much like a “3-Sum” problem, and I solve it fast. But the interver told me it’s not the best solution. (You know how to deal with 3-sum, right?)

I thought for a while, and give up at last. And the interver told me that the solution is to enumerate (x, y) and get z by this formula.

z = (R - ax - by) / c
p.s. must be exact division

It’s a better and much easier solution, right? It was a shame for me not came up with that idea.

So, don’t forget the simple way, it may be the very best solution.

attach some information to some numbers

It useful if the length of the array (L) and the max value of the array (M). If M * L <= MAX_INT, you can storge the counter of number i in the array[i] by array[i] = array[i] + counter * M.

It’s a useful way to implement a counter in the array. And it will be a big plus for you in the interview.

Codeforces 447D DZY Loves Modification

2014-07-24T23:44:44+08:00

题意

给你一个n * m的矩阵，让你做K次操作，使得最后得到的值最大。

操作有两种：

一是在任意一行上操作，最终的结果值加上这一行数的和，然后这一行每一个数都要减去p。

二是在任意一列上操作，最终的结果值加上这一列数的和，然后这一列每一个数都要减去p。

数据范围：1 ≤ n, m ≤ 10^3; 1 ≤ k ≤ 10^6; 1 ≤ p ≤ 100

退化版的题目思路

如果我们只限定一种操作，此题就是简单题了。我们维护一个大根堆，堆中保存每一行（或列）之和。

每次操作只需要取出最大值，加到最终结果上。之后将这个值减去对应的p * n（或p * m），再加入堆中。

经过K次循环，就可以得到最后的答案了。

真正的题目思路

对于行和列同时操作，我们也可以套用这种方法。但是要解决对行操作后，对列上数字的值的影响。

易得，如果行列混合操作，且只使用上述方法的话。每次行操作所得到的值，实际上为简单行操作得到的值 - 此次行操作之前的所有列操作次数 * p(为什么？)。对于列操作亦然。

假设我们有一个操作序列，<a0, b0>代表序列的一段执行了a0个行操作和b0个列操作。如下图所示：

<a0, b0>  | <1, 0>  | <0, 1>  | <a1, b1>|
|<---A--->|<---B--->|<---C--->|<---D--->|

操作被分为了四个阶段。

对于B阶段来说，其结果为1次简单行操作的值 - b0 * p(为什么？)，对于C阶段来说，其结果为1次简单列操作的值 - (a0 + 1) * p。

那么，如果当我们把B阶段和C阶段互换的话，结果是不变的。(为什么？我真TMD是十万个为什么。。。)

所以我们可以得出，在任一个操作序列中，我们可以交换任意一个的行操作和列操作，而总结果不变。

最终，我们可以将操作序列等价变化成下面的序列。

<a, 0> | <0, b>

此时，最终的结果为a次简单行操作的值 + b次简单列操作的值 - a * b * p。(为什么？)

而a与b的值可以简单的通过枚举得到。思路有了，代码如果不出大问题，这题就可以AC了。

代码

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <queue>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

typedef long long llint;

const int SIZE = 1024;
const int K = 1024000;

int n, m, k, p;
llint sumX[K + 5], sumY[K + 5];
vector<llint> xs, ys;

void do_calc(const vector<llint>& vs, llint sum[], int u)
{
    priority_queue<llint> pq;
    for (auto i: vs) {
        pq.push(i);
    }
    sum[0] = 0;
    for (int i = 1; i <= k; i++) {
        llint now = pq.top();
        pq.pop();
        sum[i] = sum[i - 1] + now;
        now -= (llint)p * u;
        pq.push(now);
    }
}

void calcX()
{
    do_calc(xs, sumX, m);
}

void calcY()
{
    do_calc(ys, sumY, n);
}

int main()
{
    int a;
    freopen("input.txt", "r", stdin);
    input(n >> m >> k >> p);
    ys.resize(m);
    xs.resize(n);
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < m; j++) {
            scanf("%d", &a);
            ys[j] += a;
            xs[i] += a;
        }
    }

    calcX();
    calcY();

    llint ans = std::numeric_limits<llint>::min();
    for (int i = 0; i <= k; i++) {
        llint t = 0;
        t += sumX[i];
        t += sumY[k - i];
        t -= (llint)i * (k - i) * p;
        ans = max(ans, t);
    }
    print(ans);
    return 0;
}

后记

某厂的g++版本是3.4.x，没有C++11，根本秀不起来啊！

说的就和你会写C++11一样_(:з」∠)_

CPU cache引发的性能血案

2014-07-20T00:18:00+08:00

在__为什么转置一个512x512的矩阵，会比513x513的矩阵慢很多？__一文中，作者引用了一个矩阵转置的例子，来讲解由于CPU cache的失效而带来的性能损失。

上面的文章对问题的解释与讨论都非常的透彻。我的这篇文章只是对上面文章的一篇读后感和实验报告。就酱。

CPU cache 之组相联

组相联的实现和原理不必再赘述了。我想讨论的是，如何在编程中优化CPU的cache性能。

查看CPU信息

我的系统是Ubuntu 12.04，CPU是i5-3230M。（屌丝机 :D)

wizmann@Wichmann:~$ ls /sys/devices/system/cpu/cpu0/cache/index0/
coherency_line_size  physical_line_partition  size
level                shared_cpu_list          type
number_of_sets       shared_cpu_map           ways_of_associativity

使用cat命令查看文件内容，可以获得CPU L1 cache的一些信息。

Key	Value
level	1
size	32K
ways_of_associativity	8
type	Data
number_of_sets	64

以上可知，CPU L1 cache有64组，每组有8个cache line。是8位组相联的Cache类型。

分析缓存失效率

对于以上问题，我们可以手工计算，也可以使用程序模拟Cache的失效率。

同时，Valgrind为我们提供了cachegrind工具来分析cache的失效。

wizmann@Wichmann:/tmp$ valgrind --tool=cachegrind --D1=32768,2,16 ./test
==14282== Cachegrind, a cache and branch-prediction profiler
==14282== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==14282== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==14282== Command: ./test
==14282== 
--14282-- warning: L3 cache found, using its data for the LL simulation.
Average for a matrix of 257: 1875==14282== 
==14282== I   refs:      18,708,198
==14282== I1  misses:         1,404
==14282== LLi misses:         1,355
==14282== I1  miss rate:       0.00%
==14282== LLi miss rate:       0.00%
==14282== 
==14282== D   refs:       8,936,548  (4,543,346 rd   + 4,393,202 wr)
==14282== D1  misses:     1,107,687  (1,086,263 rd   +    21,424 wr)
==14282== LLd misses:        10,502  (    5,179 rd   +     5,323 wr)
==14282== D1  miss rate:       12.3% (     23.9%     +       0.4%  )
==14282== LLd miss rate:        0.1% (      0.1%     +       0.1%  )
==14282== 
==14282== LL refs:        1,109,091  (1,087,667 rd   +    21,424 wr)
==14282== LL misses:         11,857  (    6,534 rd   +     5,323 wr)
==14282== LL miss rate:         0.0% (      0.0%     +       0.1%  )

其中I1代表指令1级缓存，D1代表数据1级缓存，而LL代表二级或三级缓存。

上面的输出也许过于复杂，我们在下面列表分析。

测试环境

只讨论L1的情况，L1大小32768 Bytes，2路组相联，每个cache line有16 Bytes。

valgrind测试命令为：

wizmann@Wichmann:/tmp$ valgrind --tool=cachegrind --D1=32768,2,16 ./test

测试程序

#define SAMPLES 64
#define MATSIZE 256

#include <time.h>
#include <iostream>
int mat[MATSIZE][MATSIZE];

void transpose()
{
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < i ; j++ )
   {
       int aux = mat[i][j];
       mat[i][j] = mat[j][i];
       mat[j][i] = aux;
   }
}

int main()
{
   //initialize matrix
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < MATSIZE ; j++ )
       mat[i][j] = i+j;

   int t = clock();
   for ( int i = 0 ; i < SAMPLES ; i++ )
       transpose();
   int elapsed = clock() - t;

   std::cout << "Average for a matrix of " << MATSIZE << ": " << elapsed / SAMPLES;
   return 0;
}

测试结果

-	MATSIZE = 256	MATSIZE = 256 + 1
运行时间 (g++ O2) 1024次	78ms	39ms
D1 Miss	2,621,967	1,107,687
D1 Miss Rate	29.5%	12.3%

由此可见，Cache的Miss Rate基本决定了程序的运行速度，运行时间比例和D1 MISS RATE的比例基本一致。

注：本机环境与cachegrind参数是不一致的，在本机上由于cache较大，且采用8位组相联，所以D1 cache miss较少，差异主要体现在LLd Miss Rate上。

实际意义

如果程序对一段内存进行顺序读取的时候，以上的缓存失效问题有可能会显现出来。但是缓存失效只是程序性能问题的一个可能的原因，应该在对程序进行profile之后再做结论。

其它profile工具

我的提问：__有没有什么方法可以对CPU cache失效进行计数？__中，各位答主还提供了以下几种工具：

perf (linux)
Tiptop
qemu
visual studio的cpu counter
intel performance counter monitor
vtunes

profile的方法很多，选一个易用性与正确性达到平衡就可以。反正我是哪个也不会_(:з」∠)_

参考链接

Codeforces Round #253 Tutorial

2014-06-21T19:24:37+08:00

443A - Anton and Letters

Simple and easy, solved by two lines of python code.

ls = filter(lambda y: y, map(lambda x: x.strip(), raw_input()[1:-1].split(",")))
print len(set(ls))

443B - Kolya and Tandem Repeat

Brute force. Just enumerate the beginning and the end of the substring, and check if that substring is tandem repeat.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

string str;
int k;

int main()
{
    freopen("input.txt", "r", stdin);
    input(str >> k);
    for (int i = 0; i < k; i++) {
        str += '?';
    }
    int len = str.length();

    int ans = 0;
    for (int i = 0; i < len; i++) {
        if (str[i] == '?') {
            break;
        }
        for (int j = 1; i + j < len; j += 2) {
            int slip = (j + 1) / 2;
            for (int k = 0; k < slip; k++) {
                if (str[i + k] == str[i + k + slip] || str[i + k + slip] == '?') {
                    /* pass */;
                }
                else {
                    goto fail;
                }
            }
            ans = max(ans, j + 1);
fail:       /*pass*/;
        }
    }
    print(ans);
    return 0;
}

442A - Borya and Hanabig

Because Borya knows about the color and value of all his cards, he just need to distinguish each card from the others.

Distinguish one card from all others seems difficult, but distinguish one card from ONE other card is simple enough. So if we can tell the difference between one card and any other, it can be determined from all pairs which contain this card. At last, if all pairs of cards can be distinguished, we can claim that we can distinguish all cards.

It’s easy to find out that we have 10 different kind of hints in total(5 colors and 5 values) and 1024 different combination of all that hints(1 << 10). As a result, we can enumerate all combinations, and try to indicate whether this batch of hints can distinguish all these cards.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <vector>
#include <cassert>
#include <map>
#include <set>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 5;
const int INF = 1 << 29;

int n;
char instr[10];
int mp[256];

void init()
{
    const char _str[] = "12345RGBYW";
    for (int i = 0; _str[i]; i++) {
        mp[int(_str[i])] = i;
    }
}   

int conv(char x)
{
    return mp[int(x)];
}

int main()
{
    freopen("input.txt", "r", stdin);
    init();
    while (input(n)) {
        set<int> st;
        vector<int> vec;
        for (int i = 0; i < n; i++) {
            scanf("%s", instr);
            int a = conv(instr[0]);
            int b = conv(instr[1]);
            int v = (1 << a) | (1 << b);
            // print(a << ' ' << b << ' ' << v);
            if (st.find(v) != st.end()) {
                continue;
            }
            st.insert(v);
            vec.push_back(v);
        }
        int ans = INF;
        for (int i = 0; i < (1 << 10); i++) {
            for (int j = 0; j < (int)vec.size(); j++) {
                for (int k = j + 1; k < (int)vec.size(); k++) {
                    int diff = vec[j] ^ vec[k];
                    if (!(i & diff)) {
                        goto fail;
                    }
                }
            }
            ans = min(ans, __builtin_popcount(i));
fail:       /*pass*/;
        }
        print(ans);
    }
    return 0;
}

442B - Andrey and Problem

Assuming that the possibility of getting exactly one problem from some of Andrey’s friends is p1 and get no problem is p0. So, if we want to add one friend whose possibility of comming up a problem is pa to this very friend set, we can get next_p1 = p1 * (1 - pa) + p0 * pa and next_p0 = p0 * (1 - pa). And it easy to indicate that a greater pa will lead to a greater next_p1.

The initial value is that p0 == 1; p1 == 0. And we add the friends one by one ordered by the possibilites reversely. At last, the max p1 is the final result.

n = int(raw_input())
ps = map(float, raw_input().split())

ps.sort(reverse=True)

good = ps[0]
bad = 1 - good

ans = good

for p in ps[1:]:
    good, bad = good * (1 - p) + p * bad, bad * (1 - p)
    ans = max(ans, good)

print ans

A simple problem - World at War

2014-06-12T17:42:51+08:00

Background

This problem is from the book “Algorithm 4th edition” (Exersise 4.1.10)

There are N cities and M undirected roads between those cities. People can travel to any city along the roads.

One day, a war breaks out. Our cities are under attack! As we can’t defend all these N cities, the commander wants you to find the least important city, which means that if this city fell to the enemy, the traffic among other cities would not be affected.

If there are multiple answers, print any one of them. If there’s no that kind of city, print -1.

The spanning tree of a graph

It is a spanning tree of a graph G if it spans G (that is, it includes every vertex of G) and is a subgraph of G (every edge in the tree belongs to G).
– wikipedia

For example, there is a spanning tree of a graph. These nodes in green is leaf node. So it is easy to know that if we remove a leaf node, the graph won’t be affect. The rest of the graph (and the spanning tree) are still connected.

So the answer is here.

How to generate a spanning tree

There are multiple ways to generate a spanning three of a undirected graph. The most famous algorithm is prim, which will generate a MST(minimum spanning tree) with O(n**2) time complexity.

However, MST is not needed in this scenario, because an arbitrary spanning tree is enough to find one of the leaf nodes.

Depth first search (a.k.a DFS) is one of the simplest way to generate the spanning tree. We just start from arbitrary node of the graph, and search through the graph until it comes to a dead-end – the leaf node. Then print the answer.

Problem solved.

Show me the code

class Solution {
public:
    int least_important_city(vector<vector<int> > g) {
        if (g.size() == 0) {
            return -1;
        }
        int n = g.size();

        vector<bool> visit;
        visit.resize(n);
        fill(visit.begin(), visit.end(), false);

        int now = 0;
        while (true) {
            bool flag = false;
            visit[now] = true;
            for (auto iter = g[now].begin(); 
                    iter != g[now].end(); 
                    ++iter) {
                int next = *iter;
                if (!visit[next]) {
                    now = next;
                    flag = true;
                    break;
                }
            }
            if (!flag) {
                break;
            }
        }
        return now;
    }
};

内存屏障初探

2014-05-08T19:05:26+08:00

原文地址

Barrier February 17th, 2007

前言：多核时代的挑战

尽管80核心的浮点运算巨兽仍然遥不可及，多核处理器的时代已经到来。多核处理器的概念并非新鲜事物，在Power Macintosh 9500中就已经采用了多核处理器技术。现在，让我们深入理解多核处理器的内在机制。

线程技术探讨

名词解释

线程

线程是一种拥有共享地址空间的、能被抢占式调度的执行上下文。

多线程

多线程是一种用于简化控制流、绕过阻塞系统调用的方法，并不专门用于实现程序的并行化。

并发多线程

物理上并行执行的线程，旨在通过利用多核处理器优化系统性能。

“并发多线程”的挑战

尽管并发多线程被广泛讨论，其挑战并非源自自然原因，而是我们自己的设计选择所造成的。主要问题在于，针对单线程程序的过度优化在多线程环境中不再适用。

具体来说，由于CPU的执行速度远超内存响应速度，我们开始对内存内容进行“预测”，从而避免CPU等待内存检查。这里的“预测”实际上是CPU和编译器对内存状态做出的越来越激进的假设。

示例分析

写线程示例

// 初始时 variable1 = variable2 = 0;
while (1) {
    variable1++;
    variable2++;
}

读线程示例

while (1) {
    local2 = variable2;
    local1 = variable1;
    if (local2 > local1) {
        print("Error!");
    }
}

正常逻辑下，local2 应当始终小于或等于 local1，因为 variable1 总是在 variable2 之后增加。

然而，现实是否如此？

#include <cstdio>
#include <iostream>
#include <ctime>
#include <pthread.h>
#include <sys/time.h>
#include <unistd.h>

using namespace std;

unsigned variable1 = 0;
unsigned variable2 = 0;
#define ITERATIONS 200000000

void *writer(void *unused) {
    for (;;) {
        variable1 = variable1 + 1;
        variable2 = variable2 + 1;
    }
    return NULL;
}

void *reader(void *unused) {
    struct timeval start, end;
    gettimeofday(&start, NULL);
    unsigned i, failureCount = 0;
    for (i=0; i < ITERATIONS; i++) {
        unsigned v2 = variable2;
        unsigned v1 = variable1;
        if (v2 > v1) failureCount++;
    }
    gettimeofday(&end, NULL);
    double seconds = end.tv_sec + end.tv_usec / 1000000. - start.tv_sec - start.tv_usec / 1000000.;
    printf("%u failure%s (%2.1f percent of the time) in %2.1f seconds\n",
           failureCount, failureCount == 1 ? "" : "s",
           (100. * failureCount) / ITERATIONS, seconds);
    exit(0);
    return NULL;
}

int main(void) {
    pthread_t thread1, thread2;
    pthread_create(&thread1, NULL, writer, NULL);
    pthread_create(&thread2, NULL, reader, NULL);
    for (;;) sleep(1000000);
    return 0;
}

输出结果：0 failures (0.0 percent of the time) in 1.2 seconds

貌似是正确的？

程序运行的正如我们预期的那样，那么我们可以确信程序是一定正确的吗？

不能。

因为程序中的两个线程如果在同一个CPU上被调度，我们永远都会得到正确的结果。

线程与不同的CPU进行绑定

void *writer(void *unused) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(0, &cpuset);
    sched_setaffinity(0, sizeof(cpuset), &cpuset);
    // ...
}

void *reader(void *unused) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(2, &cpuset);
    sched_setaffinity(0, sizeof(cpuset), &cpuset);
    // ...
}

// p.s. 我机器是i5双核四线程，所以绑在了CPU0和CPU2上

结果：0 failures (0.0 percent of the time) in 1.4 seconds

似乎仍然是准确的

尽管如此，我们考虑到CPU对变量的操作其实是作用在寄存器上，而variable1和variable2紧密相邻，这可能导致它们位于缓存的同一行。因此，它们有可能会同时被写入缓存并一起写回内存。

为了观察不同的效果，我们尝试将这两个变量分别放置在堆和栈上。

0 failures (0.0 percent of the time) in 1.2 seconds
0 failures (0.0 percent of the time) in 1.2 seconds
2000000000 failures (100.0 percent of the time) in 1.2 seconds

太感人了！

我们的敌人 —— 编译器

Multithreading bugs are very delicate.

并行多线程的错误总是那么的奇妙，也许你的程序运行了几天安然无恙，但是在某一天某一时突然出现了难以复现的精妙bug。

如果多个线程调度在同一个CPU核心上，Bug会被掩盖。
如果多个变量在CPU同一行Cache上，Bug会被掩盖。
如果你人品足够好的话，Bug同样会被掩盖。

但是，如果我们排除了以上的情况后，问题就浮现出来了。

我们来看一看reader的反汇编代码：

(gdb) disas reader
Dump of assembler code for function reader(void*):
   0x0000000000400950 <+0>: push   %rbx
   0x0000000000400951 <+1>: xor    %eax,%eax
   0x0000000000400953 <+3>: mov    $0x10,%ecx
   0x0000000000400958 <+8>: mov    $0x80,%esi
   0x000000000040095d <+13>:    xor    %ebx,%ebx
   0x000000000040095f <+15>:    sub    $0xa0,%rsp
   0x0000000000400966 <+22>:    mov    %rsp,%rdi
   0x0000000000400969 <+25>:    mov    %rsp,%rdx
   0x000000000040096c <+28>:    rep stos %rax,%es:(%rdi)
   0x000000000040096f <+31>:    xor    %edi,%edi
   0x0000000000400971 <+33>:    movq   $0x4,(%rsp)
   0x0000000000400979 <+41>:    callq  0x400790 <sched_setaffinity@plt>
   0x000000000040097e <+46>:    lea    0x80(%rsp),%rdi
   0x0000000000400986 <+54>:    xor    %esi,%esi
   0x0000000000400988 <+56>:    callq  0x400710 <gettimeofday@plt>
   0x000000000040098d <+61>:    mov    0x2006e4(%rip),%rax        # 0x601078 <variable2_p>
   0x0000000000400994 <+68>:    mov    0x2006e6(%rip),%edx        # 0x601080 <variable1>
   0x000000000040099a <+74>:    mov    (%rax),%ecx
   0x000000000040099c <+76>:    mov    $0x77359400,%eax
   0x00000000004009a1 <+81>:    nopl   0x0(%rax)
   0x00000000004009a8 <+88>:    cmp    %ecx,%edx
   0x00000000004009aa <+90>:    adc    $0x0,%ebx
   0x00000000004009ad <+93>:    sub    $0x1,%eax
   0x00000000004009b0 <+96>:    jne    0x4009a8 <reader(void*)+88>
   0x00000000004009b2 <+98>:    lea    0x90(%rsp),%rdi
   0x00000000004009ba <+106>:   xor    %esi,%esi
   0x00000000004009bc <+108>:   callq  0x400710 <gettimeofday@plt>
   0x00000000004009c1 <+113>:   cvtsi2sdq 0x98(%rsp),%xmm0
   0x00000000004009cb <+123>:   cvtsi2sdq 0x90(%rsp),%xmm1
   0x00000000004009d5 <+133>:   movsd  0x1a3(%rip),%xmm3        # 0x400b80
   0x00000000004009dd <+141>:   mov    %ebx,%eax
   0x00000000004009df <+143>:   cvtsi2sdq 0x88(%rsp),%xmm2
   0x00000000004009e9 <+153>:   cmp    $0x1,%ebx
   0x00000000004009ec <+156>:   mov    $0x400b3d,%ecx
   0x00000000004009f1 <+161>:   mov    $0x1,%edi
   0x00000000004009f6 <+166>:   divsd  %xmm3,%xmm0
   0x00000000004009fa <+170>:   mov    %ebx,%edx
   0x00000000004009fc <+172>:   mov    $0x400b40,%esi
   0x0000000000400a01 <+177>:   divsd  %xmm3,%xmm2
   0x0000000000400a05 <+181>:   addsd  %xmm0,%xmm1
   0x0000000000400a09 <+185>:   cvtsi2sdq 0x80(%rsp),%xmm0
   0x0000000000400a13 <+195>:   subsd  %xmm0,%xmm1
   0x0000000000400a17 <+199>:   cvtsi2sd %rax,%xmm0
   0x0000000000400a1c <+204>:   mov    $0x400b3c,%eax
   0x0000000000400a21 <+209>:   cmovne %rax,%rcx
   0x0000000000400a25 <+213>:   mov    $0x2,%eax
   0x0000000000400a2a <+218>:   mulsd  0x156(%rip),%xmm0        # 0x400b88
   0x0000000000400a32 <+226>:   subsd  %xmm2,%xmm1
   0x0000000000400a36 <+230>:   divsd  0x152(%rip),%xmm0        # 0x400b90
   0x0000000000400a3e <+238>:   callq  0x400700 <__printf_chk@plt>
   0x0000000000400a43 <+243>:   xor    %edi,%edi
   0x0000000000400a45 <+245>:   callq  0x4006f0 <exit@plt>

简而言之，关键在以下几句：

0x000000000040098d <+61>:    mov    0x2006e4(%rip),%rax        # 0x601078 <variable2_p>
0x0000000000400994 <+68>:    mov    0x2006e6(%rip),%edx        # 0x601080 <variable1>
0x000000000040099a <+74>:    mov    (%rax),%ecx
0x000000000040099c <+76>:    mov    $0x77359400,%eax
0x00000000004009a1 <+81>:    nopl   0x0(%rax)
0x00000000004009a8 <+88>:    cmp    %ecx,%edx
0x00000000004009aa <+90>:    adc    $0x0,%ebx
0x00000000004009ad <+93>:    sub    $0x1,%eax
0x00000000004009b0 <+96>:    jne    0x4009a8 <reader(void*)+88>

我们可以看出，循环体在+88～+96行，而对variable1与variable2的取值都放在了循环以外。

注：
adc是带进位加法，adc $0x0, %ebx => %ebx = $0x0 + %ebx + CF
cmp的结果正是放在CF（大于表示为溢出），ZF（相等表示为0），PF（小于表示为-1,则低8位全为1,故有偶数个1）

正是这个“小意外”，导致了我们的结果要不是100%正确，要不是100%错误。

使用volitile（？）

让我们修改一下代码：

volatile unsigned variable1 = 0;
volatile unsigned *variable2_p = NULL;
#define ITERATIONS 500000000LL // 调小一下数据规模，因为volatile太慢了_(:з」∠)_

我得出的来的结果是：

0 failures (0.0 percent of the time) in 9.6 seconds

而作者得出的结果是：
（时间上的差异不计，因为我们的数据规模不一样，我实验的次数要多一些。

fish ) ./a.out
12462711 failures (24.9 percent of the time) in 3.7 seconds

从作者的结果来看，看起来效果好了很多，虽然慢了30多倍，但是结果并不是全对全错了。

而从我的结果来看，volatile看似神丹妙药，解决了所有的问题。(both g++ and clang++)

这是为什么呢?

其原因在于体系结构的差异。volatile只能保证如下两点：

volatile变量的访问不会优化成寄存器访问，而是每次都去访问“内存”（这个引号一会再解释）
volatile变量间的访问顺序不会被编译器乱序

而其他的一切，volatile和编译器都不会给出任何保证。

例如，不同的CPU都有其内部的私有Cache，CPU的内存访问，如果命中了Cache，则不会真正的访问内存。但由于其私有Cache对于其它的CPU是不可见的，使用volatile就埋下的Bug的种子。

虽然在我们的实验中，程序运行的很好，没有出现Bug。但是，一是由于多线程的Bug都是subtle和delicate的，我不能保证在一个需要7x24工作的服务器程序中，它不会出现任何Bug；二是至少我们的代码是 not portable 的，如果有一天，我们从x86-64平台切换到了PowerPC？或是IA64？我们不能保证在这些体系结构上，编译器和CPU能为我们提供同样的保障。

于是有人高声疾呼： volatile不能用来做为多线程的同步机制！

补充于20240317：在一台老旧的安卓手机上重复了实验，volatile确实无法提供相关的保障

~/tmp $ clang++ -O2 a.cc && ./a.out
99880586 failures (49.9 percent of the time) in 3.0 seconds

小心CPU的行为

在先前的实验中，尽管程序的表现与预期一致，但我们无法确保CPU将始终按顺序执行代码。实际上，CPU可能会对操作顺序进行优化，例如，将var1++和var2++的执行顺序调换，这在当前主流的CPU中是常见的做法。

值得注意的是，由于乱序执行会导致功耗增加，某些处理器如ARM和Intel Atom已经取消了这一机制。然而，我们无法预知未来代码可能会在哪种硬件架构上运行，例如ARM集群，这需要我们保持警惕。

避免使用锁

通常情况下，通过引入互斥锁（mutex）似乎能够解决并发问题。然而，根据作者的测试，引入互斥锁可能会导致程序速度降低至原来的1/130，而自旋锁（spinlock）也可能使得速度降低至原来的1/4。

因此，我们应该暂缓，仔细考虑作者接下来的建议。

内存屏障的应用

在多CPU环境中，处理器往往独立运行，不会协调彼此的操作。

目前，我们面临两个并不理想的解决方案：一是将所有线程限制在单个CPU上运行，二是通过引入重量级锁来同步操作。这些方法都不尽人意，且效率低下。

实际上，我们需要做的是，通过内存屏障技术，暂时阻止编译器或CPU对程序中的数据读写操作进行重排序。

for (;;) {
    variable1 = variable1 + 1;
    barrier();
    *variable2 = *variable2 + 1;
}

这样我们保证了，在var1++必然早于var2++。var2++后面也可以加一道barrier，只不过在我们的场景下，提供这种保证是不必须的。

作者又做了一次试验。

fish ) ./a.out
260 failures (0.0 percent of the time) in 0.9 seconds

这次且错误减少了许多。

我们再把读线程写加上memory barrier.

for (i=0; i < ITERATIONS; i++) {
    unsigned v2 = *variable2;
    barrier();
    unsigned v1 = variable1;
    if (v2 > v1) failureCount++;
}

看看结果：

fish ) ./a.out
0 failures (0.0 percent of the time) in 4.2 seconds

程序表现出了正确的结果。

我们可以看出，如果你对线程A的读写顺序做出要求，必然的，你也要对线程B的顺序做要求，以此类推，线程C，线程D……

所以，Memory barriers always come in pairs, or triplets or more.

同样的，线程锁也是这样的，自己锁自己总不是一种愉快的体验（笑

CPU的乱序执行

我们可以看到PowerPC有三种内存屏障，而DEC Alpha平台有更多。这意味着，CPU使用更激进的策略来重排指令，而强制限制其重排的代价是非常高的。

而x86平台则非常守序，作者猜测其原因是由于早期x86的指令技术并非完善，而在那时内存与CPU的速度不像现在这样悬殊，所以x86使用了strongly ordered memory而非像上面几款CPU一样的采用过多的指令重排序。如今，由于x86背上了向前兼容性的包袱，看似我们的”好日子”一直不会结束。

x86-64，做为x86的64位升级版，同样没有实现weakly ordered，或者说，保留了实现weakly ordered的权利。而IA64平台，如Itanium，则实现了weakly ordered。

作者猜测x86_64之所以保守，是为了与IA64平台对抗。x86_64的对于x86良好的兼容性可以让程序员多活几年，所以x86_64在市场的表现更好。

作者还表示，而苹果放弃IA64平台转投x86-64多少有一些可惜，因为苹果并没有移植性问题，PowerPC已经逐渐衰落，为什么不试试IA64呢。

实际上，根据Wikipedia，现在支持IA64的操作系统非常少，只有WinNT Family，Red Hat Linux，Debian/Gentoo/Suse以及其它。而从Windows Server 2008 R2之后，Microsoft也表示不再支持Itanium。所以从现在看来，IA64平台相对x86/x64来说，是失败的。

双重检查锁

让我们看一下如下的Obj-C代码

+ getSharedObject {
    static id sharedObject;
    if (! sharedObject) {
        LOCK;
        if (! sharedObject) {
            sharedObject = [[self alloc] init];
        }
        UNLOCK;
    }
    return sharedObject;
}

这是非常经典的一种DCLP(Double Checked Lock Pattern)的实现。

这个看起来不错，但是你已经知道这并不靠谱了。当我们初始化我们的共享单例，先要再修改类内的指针，使其指向一块声明好的内存，再初始化一个sharedObject的instance。

不过，你是知道的，CPU和编译器会把一切都搞砸，它们会以任意的顺序执行我们的命令，同时处理器之间互相不通气，于是就会出现如下的情况：

线程A为指针声明了一段空间，但是还没来及初始化这个instance，线程A就被挂起了。

之后线程B接管一切，发现指针有值，结果因为访问了野指针导致程序挂掉。

不过根据上面的文章，你们应该知道怎么处理这个问题了 —— 试试内存屏障！

p.s. 如果大家对obj-c不熟悉的话，可以看我另外一篇文章。那篇文章是关于Scott Meyers大神写的一篇论文，专门用来讨论DCLP问题的。

+ getSharedObject {
    static id sharedObject;
    if (! sharedObject) {
        LOCK;
        if (! sharedObject) {
            id temp = [[self alloc] init];
            OSMemoryBarrier();
            sharedObject = temp;
        }
        UNLOCK;
    }
    OSMemoryBarrier();
    return sharedObject;
}

而在《C++ and the Perils of Double-Checked Locking》一文中，Scott Meyers和Andrei Alexandrescu给出的解决方案如下。

Singleton* Singleton::instance () {
    Singleton* tmp = pInstance;
    // insert memory barrier
    // clear the cache to flush ``pInstance``
    // prevents "downwards migration" of Singleton’s construction (by another thread);
    if (tmp == 0) {
        Lock lock;
        tmp = pInstance;
        if (tmp == 0) {
            tmp = new Singleton;
            // insert memory barrier
            // prevent optimistic that eliminate the temporary variable ``tmp``
            // prevents "upwards migration" of pInstance’s initialization
            pInstance = tmp;
        }
    }
    return  tmp;
}

两种解决方案的memory barrier插入的位置不同。但是都不能说是错的。因为一个是传static instance，一个是传pointer。

其实还有更“暴力”的方法。

直接来一把大锁，哐当把整个函数锁起来，并且在每一个线程内保留一个本线程专属指向单例的指针（做cache）。这样N个线程只需要调用这个函数N次，线程竞争也相对少很多。并且根据Linux下的futex技术，无竞争下的锁相对节省了不少资源。

Singleton* Singleton::instance() {
    Lock lock;
    if(pInstance == 0) {
        pInstance = new Singleton;
    }
    return pInstance;
}

我们真的需要这么做吗

上面的obj-c代码中，保证双重检查锁正确的，其实是第二个内存屏障。但是，在那里，我们需要的其实是一个”data dependency barrier”。

Linux内核中给出很多经过精心优化的内存屏障，我们在这里可以使用。不过，要在使用的时候写好注释，一是为了未来的验证，二是为了记录自己当时的思路。

毕竟多线程的操作要小心再小心，我们需要充足的理由，更多的小心来应对。

+ getSharedObject {
    static id sharedObject;
    if (! sharedObject) {
        LOCK;
        if (! sharedObject) {
            id temp = [[self alloc] init];
            OSMemoryBarrier();
            sharedObject = temp;
        }
        UNLOCK;
    }
    /* data dependency memory barrier here */
    return sharedObject;
}

一切都结束了吗？

是的。不过让我们总结一下吧。

处理器和编译器并不能充分保证代码执行的顺序，它们会把你的代码到处移动。所以Be warned and wary!
多线程的错误是非常subtle和delicate的，所以我们很难设计测试用例
因此，别指责QA了，他们也不是故意的。RD要对自己的代码负责
锁很安全，但是也很重
内存屏障是一种更快的，不阻塞的，不会死锁的一种锁的替代物。它们总要花费更多的心思，并且也不是到处可用的银弹。但是它确实很快，有更好的伸缩性。
内存屏障往往是成对出现的。了解第二个内存屏障要出现在哪里，有助于你理解你的代码，即使你所使用的体系结构不需要第二个内存屏障。

扩展阅读

LINUX KERNEL MEMORY BARRIERS

Memory Consistency and Event Ordering in Scalable Shared-Memory Multiprocessors

Codeforces Round #242 (Div. 2) Tutorials and Solutions

2014-04-30T17:39:00+08:00

A. Squats

Trun x => X or X => x to make the number of ‘x’ is equal to the number of ‘X’.

n = int(raw_input())
hamsters = [c for c in raw_input()]

sits = hamsters.count('x')
stands = hamsters.count('X')

if sits == stands:
    print 0
    print ''.join(hamsters)
else:
    if sits > stands:
        num = sits - n/2
        key = 'x'
    else:
        num = stands - n/2
        key = 'X'
    print num
    for i, c in enumerate(hamsters):
        if c == key:
            hamsters[i] = c.swapcase()
            num -= 1
        if not num:
            break
    print ''.join(hamsters)

B. Megacity

Binary search.

Find the minimal radius of the circle to contain as many city as we need to form a megacity. But beware that you may get wrong answer if you take the lower bound of the binary search, and the answer may not exist if there no way to make a megacity.

import math

class Point:
    def __init__(self, x, y, v):
        self.x = x 
        self.y = y
        self.v = v

def distance(a, b):
    return math.sqrt((a.x - b.x) ** 2 + (a.y - b.y) ** 2)

def megacity(r, cities, v):
    u = 1000000 - v
    rem = 0
    for city in cities:
        if distance(Point(0, 0, 0), city) <= r:
            rem += city.v
    return rem >= u

n, v = map(int, raw_input().split())
cities = []
for i in xrange(n):
    (x, y, p) = map(int, raw_input().split())
    cities.append(Point(x, y, p))


left, right = 0, 2e6

while abs(left - right) > 1e-7:
    mid = (left + right) / 2.
    #print mid
    if megacity(mid, cities, v):
        right = mid
    else:
        left = mid

if megacity(right, cities, v):
    print right
else:
    print -1

C. Magic Formulas

U = reduce(xor, p[1...n])
V[i] = reduce(xor, map(j % i, [for j in 1...n]))
Q = U ^ reduce(xor, V[1...n])

First of all, we can easily get the value of U.

Secondly, as n is up to 1e6. We have to reduce the calculation and the method will shown by code.

At last, we xor them all together to get the final result.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 1000010;

int xorsum[SIZE];

void init()
{
    int sum = 0;
    xorsum[0] = 0;
    for (int i = 1; i < SIZE; i++) {
        sum ^= i;
        xorsum[i] = sum;
    }
}

int main()
{
    int n, Q = 0, a;
    init();
    input(n);
    for (int i = 0; i < n; i++) {
        scanf("%d", &a);
        Q ^= a;
    }

    for (int i = 1; i <= n; i++) {
        int div = (n / i) % 2;
        int rem = n % i;
        if (div) {
            Q ^= xorsum[i-1];
        }
        Q ^= xorsum[rem];
    }
    print(Q);
    return 0;
}

D. Biathlon Track

Binary search again.

I calculate the wrong time complexity and get many TLEs using brute force algorithm.

The idea is to fix the left-up point A, (ax, ay), and fix the y-axis of the right-buttom point B, (bx, by). And then, using binary search to get the x-axis of the B to get the nearest cost (aka “distance covering time”) to the desired time t.

The time complexity is O(logn * n^3). A bad ass code is below.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

const int SIZE = 301;
const int DIRS = 4;
const int INF = 1 << 29;

typedef long long llint;

int n, m, t;
int tp, tu, td;

enum {
    NORTH, EAST, SOUTH, WEST
};

int land[SIZE][SIZE];
int costxy[4][SIZE][SIZE];

inline int move(int now, int next) {
    if (now > next) {
        return td;
    } else if (now == next) {
        return tp;
    } else {
        return tu;
    }
}
void count_time()
{
    for (int i = 0; i < m; i++) {
        for (int j = n - 2; j >= 0; j--) {
            costxy[NORTH][j][i] = costxy[NORTH][j + 1][i] + move(land[j + 1][i], land[j][i]);
        }
    }

    for (int i = 0; i < m; i++) {
        for (int j = 1; j < n; j++) {
            costxy[SOUTH][j][i] = costxy[SOUTH][j - 1][i] + move(land[j - 1][i], land[j][i]);
        }
    }

    for (int i = 0; i < n; i++) {
        for (int j = 1; j < m; j++) {
            costxy[EAST][i][j] = costxy[EAST][i][j - 1] + move(land[i][j - 1], land[i][j]);
        }
    }

    for (int i = 0; i < n; i++) {
        for (int j = m - 1; j >= 0; j--) {
            costxy[WEST][i][j] = costxy[WEST][i][j + 1] + move(land[i][j + 1], land[i][j]);
        }
    }
}

int get_cost(int ay, int ax, int by, int bx) 
{
    int cost = 0;
    cost += costxy[NORTH][ay][ax] - costxy[NORTH][by][ax];
    cost += costxy[SOUTH][by][bx] - costxy[SOUTH][ay][bx];
    cost += costxy[EAST][ay][bx]  - costxy[EAST][ay][ax];
    cost += costxy[WEST][by][ax]  - costxy[WEST][by][bx];
    return cost;
}

int main()
{
    freopen("input.txt", "r", stdin);
    scanf("%d%d%d", &n, &m, &t);
    scanf("%d%d%d", &tp, &tu, &td);
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < m; j++) {
            scanf("%d", &land[i][j]);
        }
    }
    count_time();

    int ans = -INF;
    int rsax, rsay, rsbx, rsby;

    for (int ay = 0; ay < n; ay++) {
    for (int ax = 0; ax < m; ax++) {
    for (int by = ay + 2; by < n; by++) {
        int lbx = ax + 2, rbx = m - 1;
        int now = lbx, step = rbx - lbx;
        while (step > 0) {
            int half = step >> 1;
            int mid = now + half;
            int cost = get_cost(ay, ax, by, mid);
            if (cost >= t) {
                step = half;
            } else {
                now = mid + 1;
                step = step - half - 1;
            }
        }

        for (int bx = now - 10; bx <= now + 10; bx++) {
            if (bx < lbx || bx > rbx) {
                continue;
            }
            int cost = get_cost(ay, ax, by, bx);
            // printf("%d %d %d %d => %d\n", ay, ax, by, bx, cost);
            if (abs(cost - t) < abs(ans - t)) {
                ans = cost;
                //print(ans);
                rsax = ax; rsay = ay; rsbx = bx; rsby = by;
                //printf("%d %d %d %d\n", rsay + 1, rsax + 1, rsby + 1, rsbx + 1);
            }
        }
    }
    }
    }
    printf("%d %d %d %d\n", rsay + 1, rsax + 1, rsby + 1, rsbx + 1);
    return 0;
}

Codeforces Round #240 (Div. 2) Tutorials and Solutions(incomplete and incorrect)

2014-04-08T14:39:11+08:00

Overview

It has been months that I didn’t participate in the contest on CF, now I’m back. :)

This round of contest makes me confused that the problem B and C is a little bit too twisted, if you can’t catch the vital point, you will get a lot of WAs in the end.

Additionally, the problem D is too easy, just a simple DP and the time limit is too long for an unoptimized solution.

And as usual, I have no idea to the problem E. :(

A. Mashmokh and Lights

The description is too long for a problem A, but it is as easy as it used to be.

Just decalre an array to keep the records of who is the first to turn off the light.

(n, m) = map(int, raw_input().split())
bs = map(int, raw_input().split())

ts = [0 for i in xrange(n + 1)]

for b in bs:
    for i in xrange(b, n + 1):
        if not ts[i]:
            ts[i] = b

print ' '.join(map(str, ts[1:]))

B. Mashmokh and Tokens

It is quite confused that Mashmokh just save the tokens for NOTHING?! I took it for granted that Mashmokh should save all the extra token for a final exchange. But I was wrong. The problem just asks for how many tokens is useless for the tokens-salary exchange everyday.

Uh, so sad. If I was Mashmokh, I just give all my tokens to my boss as the saved tokens would never counts.

n, a, b = map(int, raw_input().split())
ts = map(int, raw_input().split())

for t in ts:
    c = (t * a) % b
    print c / a,

C. Mashmokh and Numbers

You need a full-time QA for this problem because some of the scenarios will lead to hours of debuging. :(

The thought of the problem is easy enough, just print two numbers with the gcd equal to g and a sequence of squential numbers with m pairs that each pair has a gcd equals to 1. At last, just make sure that g + m == k.

However, there are some special test cases.

n = 1, k = 0.
You can pass this case if you print any positive number.

n = 1, k - (n / 2) + 1 <= 0.
It will lead to “-1”.

And the scenarios that the n is odd.

n, k = map(int, raw_input().split())

m = n / 2
t = k - (m - 1)

if n == 1 and k == 0:
    print 19,
elif n == 1 or t <= 0:
    print -1
else:
    print t, 2 * t,

    idx = 1
    for i in xrange(m):
        while True:
            a, b = idx, idx + 1
            idx += 2
            if [a, b] != [t, 2 * t]:
                break;
        if i == m - 1:
            if n % 2:
                print a,
        else:
            print a, b,

D. Mashmokh and ACM

A simple DP problem. The formula is quite easy.

dp[k][i] = sum(dp[a0][i - 1] + dp[a1][i - 1] ... dp[ai][i - 1])
(k % ai == 0)

The time complexity is m * n * (1 + 1/2 + 1/3 + ... 1/n), and the sum of series 1 + 1/2 + ... is called harmonic number of n which approximately equals to ln(n). So the final time complexity is m * n * ln(n).

Further, we can reuse the space of dp array to gain a better CPU cache optimizism.

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>
#include <ctime>
#include <map>

using namespace std;

#define print(x) cout<<x<<endl
#define input(x) cin>>x

typedef long long llint;

const int SIZE = 2048;
const llint MOD = 1000000007LL;

int n, m;
llint dp[SIZE][SIZE];

int main()
{
    input(n >> m);
    memset(dp, 0, sizeof(dp));
    for (int i = 1; i <= n; i++) {
        dp[i][0] = 1;
    }

    for (int i = 1; i < m; i++) {
        for (int j = 1; j <= n; j++) {
           for (int k = 1; j * k < SIZE; k++) {
               dp[j * k][i] += dp[j][i - 1];
               dp[j * k][i] %= MOD;
            }
        }
    }

    llint ans = 0;
    for (int i = 1; i <= n; i++) {
        ans += dp[i][m - 1];
        ans %= MOD;
    }
    print (ans);
    return 0;
}

"alloca" vs "placement new"

2014-04-07T21:08:59+08:00

WHAT?!

For most time, we use malloc or new for memory allocation, which will get it on heap.

However, access memory on heap is not as effective as the memory on stack, because the heap is “free-floating region of memory”. To the contrary, memory on stack is managed by CPU automacitally and tightly. As a result, the further of the stack compared to heap is that we can have a faster read/write speed due to the fact that stack memory is more likely to optimized by CPU cache, in addition, it only uses a single instruction to allocate or deallocate stack memory. Just like this.

sub esp, 0x10; => allocate
add esp, 0x10; => deallocate

alloca

The alloca() function allocates memory from the stack.

int *p = (int*)alloca(sizeof(int) * size);

It’s quite the same as the malloc way. But we shouldn’t free the memory allocated on the stack; these memory will be automatically deallocated when you leave the function(not the code block).

placement new

The placement new is one of the overloads of the new functions; this new syntax can do something as the alloca() function.

char buffer[1024];
int *p = new(buffer) int[64];

The placement new can be also used in some other scenarios but won’t be mentioned here.

variable-length array

C90 and C++ both support the variable-length array which will be allocated on stack, and it will be deallocted whhen you leave the clode block, such as “if”, “while”, etc.

This is much simplified, but be ware if you use both variable-length array and alloca() in the same function, the deallocation of the array will also free anything more recenly allocated by alloca.

Defects

Stack has its limitation. If the allocation on stack causes stack overflow error, then the behavior of the program is undefined.

Further, the variable-length array and alloca() are not included in ANSI-C standard and therefore could limit portability.

The Google C++ style guide encourage developers to use scoped_ptr or scopted_array instead of variable-length array and alloca().

Some experiment

// compile with: g++ -std=c++0x -O2 -Wall -g -o "foo.cc" "foo"
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <algorithm>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

#if defined(__i386__)
static __inline__ unsigned long long rdtsc(void)
{
    unsigned long long int x;
    __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
    return x;
}
#elif defined(__x86_64__)
static __inline__ unsigned long long rdtsc(void)
{
    unsigned hi, lo;
    __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
    return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}
#endif


//#define MEMORY_ON_HEAP
//#define MEMORY_ON_STACK

const int SIZE = 102400;
int *array[SIZE] = {NULL};

int main()
{
    unsigned long long start = rdtsc();

    #ifdef MEMORY_ON_HEAP // RDSTC: 20586280
    for (int i = 0; i < SIZE; i++) {
        array[i] = (int*)malloc(sizeof(int));
        *array[i] = i;
    }
    #endif

    #ifdef MEMORY_ON_STACK // RDSTC: 3660502
    for (int i = 0; i < SIZE; i++) {
        array[i] = (int*)alloca(sizeof(int));
        *array[i] = i;
    }
    #endif


    unsigned long long end = rdtsc();
    print(end - start);
    return 0;
}

You can use info register esp in gdb to inspect the stack pointer before and after you call the allocation function or declare a variable-length array.

GeoHash算法

2014-02-04T00:10:00+08:00

GeoHash

Geohash is a latitude/longitude geocode system invented by Gustavo Niemeyer when writing the web service at geohash.org, and put into the public domain. It is a hierarchical spatial data structure which subdivides space into buckets of grid shape.

简单说，GeoHash是一个将经纬度信息编码成一个string的算法。从而便于储存、查找。

GeoHash算法的步骤

GeoHash对经度纬度分别编码，原理是迭代做二分，进而逼近真实值。

我们以纬度举例。

由于地球纬度区间是[-90,90]，所以取区间中点pivot。如果某地点P的纬度大于pivot的值，则编码的第1位为1，反之为0。

然后缩小范围，迭代N次。得到最后的结果。

经度的范围是[-180, 180]。我们重复上面的过程，也可以得到经度编码。

最后我们把经度和纬度的编码进行交错组合，偶数位放经度，奇数位放纬度。得到最后的GeoHash编码。

例如，经纬度(57.64911,10.40744)可以使用base32编码为 u4pruydqqvj。

GeoHash算法的用途

由于GeoHash使用经纬度交错编码，所以我们使用某一个前辍，就可以划定一个经纬度范围。

如果我们对GeoHash编码这一列进行索引加速，则可以在较快的时间内查找到某一个范围内的所有grid，进而获得POI等信息。

GeoHash的压缩思想

GeoHash的交错编码为区间查找提供了遍历。而对经纬度的逼近编码则提供了非常好的压缩特性。

易得，一个点位于pivot的左右/上下的机率是相同的。所以编码的每一位的信息量都是-logPr[s]=>1bit，达到了数据压缩的下限。

又由于二分逼近的良好性能，使得压缩/解压缩的速度可以达到极限。

不过在实际应用中，POI不可能完全平均分布，所以GeoHash的压缩只是一种接近最优解的方案。但是由于二分逼近法带来的可索引性，GeoHash绝对可以称的上是一个精妙完美的设计了。

应用 - 拉取目标周围的POI

我们在一些LBS应用中，经常需要拉取某一点周围的POI。

假设我们将POI存储为一个pvlist映射。并且获得了某点的GeoHash值。那么我们怎么取得周围的POI呢？

理想状态下，“附近的POI”都是在一个以某点为圆心的圆进行查找。但是由于GeoHash划分的范围是一个矩形，所以我们使用一个3×3的大矩形来替代圆形范围。

其中3×3矩形中最中间的矩形是我们确定的那个点。

然后，我们根据给出的半径r确定GeoHash的精确度。使得我们的3×3大矩形可以包含理想的圆形范围。

于是下一步的目标就是找到某点GeoHash的8个临近的GeoHash。

由上文我们可以得出，GeoHash的经纬度是分别编码的。以一个4×4的地图为例。

这是在纬度上的划分。

可以看出，连续的GeoHash Grid的纬度编码也是连续的。

经度同理。

所以我们只需要decode我们的GeoHash编码，将longitude和latitude编码分别进行-1/+1的操作就可以获得附近的POI的GeoHash码/前辍了。

总结

GeoHash的三个特性，可索引，压缩，便于存储。

还有，好久不写文了。

参考资料

如何判断一个网站的地理信息

2014-01-24T00:00:00+08:00

啥？

面试题：

有一个网站，如何判断这个网站的地理信息

方法

使用反向DNS

当我们只有网站的IP地址时，我们可以使用反向DNS来获得这个IP地址对应的域名。

反向域名解析，Reverse DNS。反向域名解析与通常的正向域名解析相反，提供IP地址到域名的对应。

我们可以使用dig -x来进行查询

$ dig -x 75.126.43.235

; <<>> DiG 9.8.1-P1 <<>> -x 75.126.43.235
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26688
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;235.43.126.75.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
235.43.126.75.in-addr.arpa. 3518 IN PTR 75.126.43.235-static.reverse.softlayer.com.

;; Query time: 76 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Jan 24 18:15:22 2014
;; MSG SIZE  rcvd: 100

我们可以从接续出来的域名中，获得一些信息，例如公司名/机构名，以及.cn, .us等有可能标识地理位置的信息。

但是，反向DNS不一定成功。

查询DNS LOC信息

In the Domain Name System, a LOC record (RFC 1876) is a means for expressing geographic location information for a domain name.

所以我们可以尝试使用dig loc命令来查询位置信息。（不一定成功

$ dig loc SW1A2AA.find.me.uk

; <<>> DiG 9.8.1-P1 <<>> loc SW1A2AA.find.me.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49682
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;SW1A2AA.find.me.uk.        IN  LOC

;; ANSWER SECTION:
SW1A2AA.find.me.uk. 21600   IN  LOC 51 30 12.748 N 0 7 39.611 W 0.00m 0.00m 0.00m 0.00m

;; Query time: 1232 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Jan 24 18:21:44 2014
;; MSG SIZE  rcvd: 64

随便看看

查看我们要调查的网站，找寻可用的线索。（囧

使用whois服务

http://whois.chinaz.com/sina.com

我们可以看到域名的注册信息，其中也必然透露了线索。

traceroute与whois配合使用

可以根据包的转发状况来获得最终的地理位置

使用Time of day service

telnet www.bupt.edu.cn 13可以获得主机的当前时间，从而判断主机所在的经度。（不一定成功。。。

参考链接

http://www.private.org.il/IP2geo.html

http://www.ipgeo.com/

Codeforces Round #223 (Div. 2) 不完全不正确题解

2014-01-18T14:47:00+08:00

由于大号已经进Div. 1了，所以接下来的几场Div. 2都是用小号做的。

等有实力切D题了，再去打一区。（弱

事情一直很多，所以题解落后了好久才发。

A. Sereja and Dima

纯模拟，Python随便搞

n = int(raw_input())
pokers = map(int, raw_input().split())

v = [0, 0]
p = 0

for i in xrange(n):
    if pokers[0] > pokers[-1]:
        v[p] += pokers[0]
        del pokers[0]
    else:
        v[p] += pokers[-1]
        del pokers[-1]
    p ^= 1

print v[0], v[1]

B. Sereja and Stairs

题目要求实现一个数组，使前一半为递增，后一半为递减。

a[1] < a[2] < ... < a[i - 1] < a[i] > a[i + 1] > ... > a[n - 1] > a[n]

所以我们观察到，某一个数x在数组a中最多可以出现两次，其中一次在左边的序列，一次在右边的序列。

所以我们就对给出的数组s进行一次统计，找出每一个数出现的次数。

并分别讨论出现一次和出现两次的情况。

SIZE = 5120

n = int(raw_input())
cards = map(int, raw_input().split())

cnt = [0 for i in xrange(SIZE)]

maxi = max(cards)
for item in cards:
    cnt[item] += 1

left = []
right = []
for i in xrange(maxi):
    if cnt[i] == 1:
        left.append(i)
    elif cnt[i] > 1:
        left.append(i)
        right.append(i)
left.sort()
right.sort(reverse=True)

ans = left + [maxi] + right
print len(ans)
print ' '.join(map(str, ans))

C. Sereja and Prefixes

给定一个空序列A，然后这个序列上可以有两种操作。

一是A.push_back(x)，二是A.push_back_batch(A[0]...A[i])。

由于操作的次数是10^5，于是我们将序列A存成一个如下的形式。

a -> b -> c -> copy(0...i) -> d -> copy(0 ... j)

我们可以看出，如果询问的位置pos是一个数，则我们可以直接返回结果。如果询问的位置pos位于一个copy块里面，那么这个数一定会在A[0...i]中出现，则我们可以处理pos -> pos'，使pos'位于A[0...i]区间内。如此循环，直到pos是一个数为止。

然后这题用的算法貌似不是最快的，但是我觉得是最好理解的一种。

使用一个大根堆循环取query中最大的值，然后进行处理。

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
#include <queue>
#include <map>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

typedef long long llint;

const int SIZE = 100010;

struct node {
    llint st, end;
    llint prefix, rep;

    node(llint ist, llint pre, llint r) {
        st = ist;
        end = st + pre * r - 1;
        prefix = pre;
        rep = r;
    }

    node(llint ist, llint v) {
        st = end = ist;
        prefix = v;
        rep = -1;
    }

    node(){}

    bool is_value() {
        return rep == -1;
    }

    llint value() {
        return prefix;
    }

    bool contains(llint v) {
        return st <= v && v <= end;
    }
};

struct query {
    llint v, q;
    query(){}
    query(llint iv, llint iq): v(iv), q(iq){}

    friend bool operator < (const query& a, const query& b) {
        return a.v < b.v;
    }
};

priority_queue<query> pq;
int n, m;
vector<node> vec;
map<llint, llint> mp;
llint ask[SIZE];

void solve()
{
    int ptr = vec.size() - 1;
    while (!pq.empty()) {
        query nn = pq.top();
        llint now = nn.v;
        llint q = nn.q;
        pq.pop();

        while (!vec[ptr].contains(now)) {
            ptr--;
        }

        if (vec[ptr].is_value()) {
            mp[q] = vec[ptr].value();
        } else {
            llint delta = now - vec[ptr].st;
            delta %= vec[ptr].prefix;
            pq.push(query(delta + 1, q));
        }
    }
}

int main()
{
    llint a, b, c;
    input(n);
    llint st = 1;
    for (int i = 0; i < n; i++) {
        input(a);
        if (a == 1) {
            input(b);
            vec.push_back(node(st, b));
            st++;
        } else {
            input(b >> c);
            vec.push_back(node(st, b, c));
            st = (--vec.end()) -> end + 1;
        }
    }
    input(m);
    for (int i = 0; i < m; i++) {
        input(a);
        ask[i] = a;
        pq.push(query(a, a));
    }
    solve();
    for (int i = 0; i < m; i++) {
        if (i) printf(" ");
        printf("%lld", mp[ask[i]]);
    }
    puts("");

    return 0;
}

D. Sereja and Tree

暴力乱搞，因为树的高度只有7000，所以怎么搞都大概能过。但是为什么做的人好少。

可能是题目表述的不太好吧。

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
#include <queue>
#include <map>
#include <stack>
#include <set>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

typedef long long llint;

const int SIZE = 7010;
const int LINE = 501000;

struct node {
    int l, r;
    int val;

    node(){}
    node(int il, int ir, int ival): l(il), r(ir), val(ival) {}
};

int n, m;
int ls[LINE], rs[LINE];
vector<node> ins[SIZE];

bool intersect(int a, int b, int c, int d) {
    if (b < c || a > d) return false;
    return true;
}

void init()
{
    ls[1] = 1;
    rs[1] = 2;
    int cnt, p = 3;
    for (int i = 2; i < LINE; i++) {
        if ((1 << cnt) == i) {
            cnt++;
            ls[i] = p++;
            rs[i] = p++;
        } else {
            ls[i] = -1;
            rs[i] = p++;
        }
    }
}

int query(int a, int b) {
    set<int> s;
    int ll = b, rr = b;
    for (int level = a; level <= n; level++) {
        for (int i = 0; i < (int)ins[level].size(); i++) {
            if (intersect(ll, rr, ins[level][i].l, ins[level][i].r)) {
                s.insert(ins[level][i].val);
            }
        }
        ll = ls[ll] == -1? rs[ll]: ls[ll];
        rr = rs[rr];
    }
    return s.size();
}

int main()
{
    int tp;
    int l, r;
    int a, b;
    init();
    input(n >> m);
    while (m--) {
        input(tp);
        if (tp == 1) {
            input(a >> l >> r >> b);
            ins[a].push_back(node(l, r, b));
        } else {
            input(a >> b);
            print(query(a, b));
        }
    }
    return 0;
}

E. Sereja and Brackets

不出意外的又看错题了。。。_(:з」∠)_

最长的括号区间居然是可以在中间删除一些括号的区间。这样题目就变成了一道比较简单的离线化+树状数组了。

代码如下：

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
#include <queue>
#include <map>
#include <stack>

using namespace std;

#define print(x) cout << x << endl
#define input(x) cin >> x

typedef long long llint;

const int SIZE = 1000100;

struct ppair {
    int l, r;
    int id;

    ppair(){}
    ppair(int il, int ir, int iid): l(il), r(ir), id(iid) {}

    friend bool operator < (const ppair& a, const ppair& b) {
        return a.r < b.r;
    }
};

inline int lowbit(int x)
{
    return x&(-x);
}

struct BIT//点更新，区间查询
{
    int baum[SIZE];
    inline void init()
    {
        memset(baum,0,sizeof(baum));
    }
    void add(int x,int val)
    {
        while(x<SIZE)
        {
            baum[x]+=val;
            x+=lowbit(x);
        }
    }
    int sum(int x)
    {
        int res=0;
        while(x>0)
        {
            res+=baum[x];
            x-=lowbit(x);
        }
        return res;
    }
    int sum(int a,int b)//查询区间和
    {
        return sum(b)-sum(a-1);
    }
};

int q;
char ss[SIZE];
vector<ppair> match;
vector<ppair> query;
vector<int> ans;

void preload()
{
    stack<int> st;
    for (int i = 0; ss[i]; i++) {
        char c = ss[i];
        if (c == '(') {
            st.push(i);
        } else if (c == ')' && !st.empty()) {
            int now = st.top();
            st.pop();
            match.push_back(ppair(now + 1, i + 1, -1));
        }
    }
}

void solve()
{
    sort(match.begin(), match.end());
    sort(query.begin(), query.end());
    ans.resize(query.size());
    BIT bit;
    bit.init();

    int p = 0;
    for (int i = 0; i < (int)query.size(); i++) {
        while (p < (int)match.size() && match[p].r <= query[i].r) {
            bit.add(match[p].l, 1);
            p++;
        }

        ans[query[i].id] = bit.sum(query[i].l, query[i].r);
    }
}    

int main()
{
    int a, b;
    scanf("%s", ss);
    preload();

    input(q);
    for (int i = 0; i < q; i++) {
        input(a >> b);
        query.push_back(ppair(a, b, i));
    }
    solve();
    for (auto iter = ans.begin(); iter != ans.end(); ++iter) {
        print(*iter * 2);
    }
    return 0;
}

状态	不变式形式	是否立即满足	性质
普通节点	\( S_{L,R} = \text{Merge}(S_{L,M}, S_{M+1,R}) \)	是	严格不变式
有懒标记	\( S_{L,R} = \text{真实值} + \delta \cdot (R - L + 1) \)	暂不满足	延迟不变式
下推后	子节点恢复准确值	恢复	最终仍满足整体一致性

Maerlyn's Rainbow

《数学觉醒：学会更清晰地思考》读书笔记

1. 理解的核心是心理图像，而不是符号操作

2. 形式语言保证精确性，但不保证理解

3. 数学活动是想象、语言和推理之间的反复转换

4. “反直觉”是认知状态，不是对象属性

5. 主要的学习阻碍之一，是对”不懂”的羞耻感

6. 数学训练的产物是”清晰”，而不是定理本身

简要归纳

7. 实践应用：把这套方法搬到 competitive programming 上

Prompt：Competitive Programming 学习助手

使用建议

一个“一读多写”无锁队列的实现

一个“一读多写”无锁队列的实现

1. 背景与设计目标

2. 生产者逻辑：try_enqueue

代码实现

深度拆解：生产者入队 (try_enqueue) 的三部曲

1. 第一阶段：观察 (Observation)

2. 第二阶段：抢占 (Logical Claim) —— 核心中的核心

3. 第三阶段：发布 (Physical Publish)

3. 消费者逻辑：try_dequeue

代码实现

关键设计：为什么需要 while 循环？

4. 深度原理：Happens-Before 关系图谱

链条一：数据发布链 (Producer Consumer)

链条二：资源回收链 (Consumer Producer)

为什么 Relaxed 是安全的？

5. 总结

Luogu P14761 - CCD 的序列【动态序列统计】（之二）

1. Splay 是“自调整”的，而不是“显式平衡”的

2. 什么是 splay 操作

3. Splay 中的三种经典旋转模式

Zig（单旋）

Zig-Zig（同向双旋）

Zig-Zag（反向双旋）

4. 为什么 Splay 不需要维护平衡条件

5. 隐式 Splay 与普通 Splay 的区别

6. 区间信息的维护

7. 为什么 push_up 是“三段合并”

8. 总结

Luogu P14761 - CCD 的序列 【动态序列统计】 （之一）

1. 题意概述

匹配关系与“匹配发生变更”

本题的核心问题

2. 题目分析与建模：从匹配变化到区间统计

插入操作的结构本质

哪些括号的匹配会发生变化？

转化为区间统计问题

核心公式

区间 \((open, close)\) 在动态插入下的维护方式

3. 为什么需要平衡树，以及为什么选择 Splay

朴素与线段树方案的不足

为什么选择隐式 Splay？

区间信息如何挂在树上？

4. Splay 树的基本性质（简述）

5. 实现思路与代码结构

单点与区间信息

区间查询与插入

总体复杂度

结语

从字符串替换到图灵机：A=B 的完备性构造

0. 背景：A=B 是什么

什么是“图灵完备”？

1. 理论背景：字符串重写系统为何图灵完备？

2. 核心命题与证明纲要（把任意图灵机编译成 A=B 程序）

3. 举例：计数器程序（用例证法说明完备性）

程序规则

与图灵机构造的对应关系

为什么这个例子能说明图灵完备性？

4. 顺序/左端优先会不会削弱能力？

5. 关系图（理论坐标系）

6. 结语

C++ 的 `volatile`：它到底管啥、不管啥

为什么需要 volatile

没有 volatile，编译器会“更高效地做错事”

volatile 的真实语义

volatile 的声明位置，别修饰错对象

volatile 能做什么，不能做什么

顺序保证是有限的

7. 为什么 `push_up` 是“三段合并”

Luogu P14761 - CCD 的序列【动态序列统计】（之一）

8) GPU 与 `constexpr` 的共同语言：C++ 本体