票据锁：消除长尾延迟的公平艺术

在高并发系统的深水区，我们往往会发现一个反直觉的现象：最快的锁未必是最好的锁。

标准的自旋锁（Spinlock）通常基于 CAS (Compare-and-Swap) 竞争。虽然在低争用场景下极其高效，但在高负载下，它就像一群人在挤公交车——身强力壮（或者运气好）的线程总能抢先一步，而运气差的线程可能被饿死，导致系统的长尾延迟（Tail Latency）飙升。

今天我们来聊聊一种更“文明”的同步原语：票据锁 (Ticket Lock)。它通过引入排队机制，将无序的丛林法则变成了有序的 FIFO（先来先服务），并在 Zig 中展示如何利用内存布局优化来对抗虚假共享。

1. 为什么我们需要排队？

想象一下银行的柜台业务。如果采用标准自旋锁模式，所有人都会挤在柜台前。每当柜员喊“下一个”，所有人同时冲上去抢椅子。结果是：

不公平：刚进门的人可能比等了一小时的人先抢到。
混乱：所有人的冲抢动作（CAS 操作）导致了大量的无效竞争，消耗了巨大的总线带宽。

票据锁引入了两个计数器：

next_ticket：发票机。每个新来的线程领一个号，然后 next_ticket 加一。
current_ticket：叫号屏。显示当前正在服务的号码。

线程领到号后，只需要盯着 current_ticket 看。一旦屏幕上的数字等于手中的号码，就轮到它了。

这种机制带来的核心价值是 可预测的公平性。在高并发场景下，它消除了线程饥饿，让 P99 延迟变得平滑可控。

2. Zig 实现：显式的内存控制

在 C++ 或 Rust 中，控制内存布局往往需要复杂的属性标记。而在 Zig 中，我们能以极其直白的方式处理它。

以下是一个生产级的票据锁实现。请注意我们如何处理缓存行（Cache Line）：

const std = @import("std");
const atomic = std.atomic;

/// 票据锁：保证公平性的同步原语
/// 通过双计数器实现 FIFO 顺序
pub const TicketLock = struct {
    // 核心优化：将两个计数器强制对齐到 64 字节（常见缓存行大小）
    // 这避免了 "虚假共享" (False Sharing)
    next_ticket: atomic.Value(u64) align(64) = atomic.Value(u64).init(0),
    current_ticket: atomic.Value(u64) align(64) = atomic.Value(u64).init(0),

    /// 获取锁：领票并等待
    pub fn acquire(self: *TicketLock) void {
        // 1. 原子领票 (Fetch-and-Add)
        // 这是一次性的原子写入操作，确定了你的服务顺序
        const my_ticket = self.next_ticket.fetchAdd(1, .Monotonic);

        // 2. 自旋等待 (Read-Only Loop)
        // 只要当前票号不等于我的票号，就持续检查
        while (self.current_ticket.load(.Acquire) != my_ticket) {
            // 提示 CPU 我们在自旋，避免流水线空转过热
            std.atomic.spinLoopPause();
        }
    }

    /// 释放锁：叫下一个号
    pub fn release(self: *TicketLock) void {
        // 3. 递增当前票号 (Store-Release)
        // 这一步会立即使得持有 (my_ticket + 1) 的线程退出循环
        const current = self.current_ticket.load(.Unordered);
        self.current_ticket.store(current + 1, .Release);
    }
};

3. 深度解析：虚假共享的代价

在上面的代码中，align(64) 并不是装饰品，它是性能的关键。

如果 next_ticket 和 current_ticket 紧挨着放在同一个缓存行（Cache Line，通常 64 字节）里，会发生什么？

线程 A 调用 acquire，修改 next_ticket。
线程 B 调用 release，修改 current_ticket。

虽然它们修改的是不同的变量，但因为处于同一缓存行，CPU 的缓存一致性协议（如 MESI）会强制该缓存行在核心之间来回失效（Invalidate）和传输。这就是 虚假共享 (False Sharing)。

通过 align(64)，我们将这两个高频更新的变量隔离在不同的缓存行中。

next_ticket：主要由新来的竞争者写入。
current_ticket：主要由持锁者写入，等待者读取。

这种物理隔离显著降低了核心间的通信流量。

4. 权衡：它不是银弹

票据锁虽然解决了公平性，但也引入了新的问题：全局自旋。

在 acquire 阶段，所有等待的线程都在不断读取同一个 current_ticket 变量。

当锁被释放，current_ticket 更新。
所有等待线程的缓存行都会失效，它们都会重新读取内存。
但只有一个线程（持有下一个票号的）能成功获得锁，其他线程又继续自旋。

这种“惊群效应”在几百个核心的机器上依然会造成总线风暴。对于极度敏感的场景，我们可能需要进一步升级到 MCS 锁（每个线程只在自己的本地变量上自旋），那是另一个话题了。

总结

票据锁是并发设计中“以空间换时间，以秩序换公平”的典范。它告诉我们：

公平性是有代价的，但在长尾延迟敏感的系统中，这个代价值得付。
硬件细节不可忽略，简单的 align(64) 可能带来成倍的吞吐提升。
预测性优于爆发力，稳定的 FIFO 队列往往比忽快忽慢的 CAS 竞争更适合工业级系统。