hellopoisonx bb

分布式事务

Tue, 28 Jul 2026 14:57:38 +0800

分布式事务

单库事务依赖数据库的 ACID 能力；跨服务或跨数据源后，没有天然的全局原子提交。方案选择应围绕一致性要求、可用性、吞吐量和业务补偿成本，而不是追求统一解法。

2PC / XA

2PC 由协调者驱动：第一阶段询问参与者是否可以提交，第二阶段统一提交或回滚。XA 是数据库与事务管理器之间常用的两阶段提交规范。

它能提供较强的一致性，但参与者在事务完成前可能持有锁或连接资源。同步等待、协调者可用性和故障恢复都会拉低吞吐量，因此更适合事务短、强一致性要求高且参与者支持 XA 的场景。

TCC

TCC 是业务层的两阶段提交。每个参与者（RM）都需要实现三个操作：

Try：校验条件并预留资源；
Confirm：确认并完成业务动作；
Cancel：撤销预留资源。

事务协调器（TC）协调参与者：所有 Try 成功后执行 Confirm；任一 Try 失败或超时则执行 Cancel。Try 成功意味着参与者必须能够最终完成 Confirm，因此 Confirm 与 Cancel 都必须可重试且幂等。

TCC 以业务预留替代长时间的数据库行锁，通常有更好的并发能力；代价是实现侵入性高。还必须处理空回滚和悬挂：Cancel 可能先于 Try 到达，迟到的 Try 不能再次预留资源。实践中应通过本地事务记录每个分支的状态，并据此拒绝非法状态转换。

Saga

Saga 将一个长流程拆为多个本地事务，每一步都定义对应的补偿动作。前序步骤成功、后续步骤失败时，按逆序执行补偿。

它适合跨服务、流程长且可接受最终一致性的业务。补偿是新的业务操作，不等同于数据库回滚；设计时必须明确哪些状态可补偿，以及补偿失败后的人工或自动处置方式。

事务消息

事务消息解决的是“本地状态变更”和“发布消息”不能原子完成的问题，核心目标是可靠投递，而非让多个服务同步回滚。

Outbox 模式

在同一个本地数据库事务中，同时写入业务数据和 outbox 消息记录。后台投递器读取 outbox 并发送到 MQ，投递成功后更新记录状态。

这保证本地提交成功的事件最终至少投递一次。因此消费者必须幂等，系统也必须接受短暂的不一致；下游处理失败时，应通过重试、补偿或对账恢复，而不是回滚上游已提交的本地事务。

RocketMQ 事务消息

RocketMQ 以半消息和状态回查实现类似的可靠性：

Producer 先发送对消费者不可见的半消息；
Producer 执行本地事务；
本地事务成功则提交消息，失败则回滚消息；
若 Producer 未完成确认，Broker 回查本地事务状态后决定提交或回滚。

本地事务的结果必须可查询，并且消费者仍需按至少一次投递来设计。

方案取舍

方案	一致性	主要代价	适用边界
2PC / XA	强一致性	阻塞与资源占用	短事务、数据库支持 XA
TCC	业务强一致性	三套业务逻辑与状态治理	资源可预留、需要较高并发
Saga	最终一致性	补偿设计复杂	长流程、跨服务编排
事务消息	最终一致性	幂等、重试与对账	异步驱动的状态传播

My Docker 3

Thu, 18 Jun 2026 17:59:24 +0800

今日目标

使用 pivot_root 系统调用实现文件系统隔离

`pivot_root` vs `chroot`

chroot 只是改动了进程的根路径，并没有真正切断对原文件系统的访问。pivot_root 是 Linux 专门为容器场景设计的接口，更严格、也更安全。两者的关键差异：

维度

chroot

pivot_root

作用域

仅当前进程的根目录指针

整个 mount namespace

对老 root 的处理

仍处于挂载状态，可被再次访问

必须挂到新根下的某目录，再 umount 即可彻底消失

文件系统要求

不限制

新老根必须位于不同文件系统

逃逸风险

存在：硬链接 + 未关闭的 fd + fchdir 可回到原 root

无

典型用途

早期 jail、构建 chroot 环境

容器运行时（如 Docker、runC）的根文件系统切换

工作原理图解与说明

`chroot` 的原理

chroot 只是改变了进程 task_struct 中关于根目录的指针。

[新目录 /home/user/jail] <-- chroot 把进程的 "/" 指向这里

隐患：老根目录在内核中依然处于挂载状态。如果进程在新目录里创建了一个硬链接，或者利用未关闭的老根文件描述符，再调用一次 fchdir，就可以轻松跳回真正的系统根目录。

`pivot_root` 的原理

pivot_root 是一次真正的"偷天换日"。它要求新根和老根必须在不同的文件系统（挂载点）上。

交换：pivot_root 把当前 mount namespace 的根挂载点切换为参数中传入的新路径；与此同时，原来的根文件系统会被挂载到新根下的 put_old 目录（例如 /new_root/.pivot_root）。
隔离：对 put_old 调用 umount(..., MNT_DETACH)，老的文件系统在当前命名空间里彻底消失。新环境中的进程无论拥有多大权限，也无法访问到宿主机的任何文件，因为路径已经不存在了。

[新文件系统] ───> 变成新的 "/"
[老文件系统] ───> 挂载到新 "/" 下的某个临时目录（例如 /new_root/.pivot_root）

执行 umount(MNT_DETACH) 后：

[新文件系统] ───> "/"
                    ↳ 旧 root 在当前 mount namespace 内不可见

补充：man 2 pivot_root 明确要求新老根不能位于同一文件系统（new_root 必须是 put_old 的下层目录反之亦然），这也是为什么 pivotRoot 里要先做一次 bind mount，把目录变为为一个独立的挂载点。

UnionFS OverlayFS

Fri, 12 Jun 2026 15:45:11 +0800

是什么

UnionFS 即聚合文件系统，是一种虚拟文件系统，用于将多个文件系统聚合为一个挂载点

主要实现有 AUFS 和 OverlayFS 两种，其中前者已被主流抛弃，目前 OverlayFS 才是绝对主流（已并入 Linux 主线内核，是 Docker 镜像的默认文件系统）

OverlayFS

分为上下两层（upper, lower）其中 upper 为可写层，lower 为只读层

# 准备实验环境
$ mkdir {upper,lower,merged,work}
$ echo 1 > ./lower/a
$ tree .
.
├── lower
│   └── a
├── merged
├── upper
└── work
$ sudo mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged
$ tree .
.
├── lower
│   └── a
├── merged
│   └── a
├── upper
└── work
    ├── index  [error opening dir]
    └── work  [error opening dir]

$ cat lower/a
1
$ cat merged/a
1

可以看到 merged 后的目录与 lower 目录完全一致，如果这个时候我们修改 merged/a 的值呢？

My Docker 2

Fri, 12 Jun 2026 13:48:54 +0800

今日目标

基于 Cgroup 实现资源控制

如何实现

参考 k8s 官方文档, 有以下两种驱动

cgroupfs
systemd

cgroupfs 直接操作 /sys/fs/cgroup 下的虚拟文件接口, 而 systemd 则通过 D-Bus 总线与 systemd 通信，将操作 /sys/fs/cgroup 的任务委托给它

为了降低项目复杂度，目前只计划实现 cgroupfs 驱动且不考虑适配 Cgroup v1

将 Cgroup 控制的资源抽象为接口

type Resource interface {
	// CgroupFile 返回 cgroup v2 控制器文件名（如 "cpu.weight"）。
	CgroupFile() string
	// CgroupValue 返回要写入文件的格式化字符串。
	CgroupValue() string
	// Validate 做边界检查，失败返回 ErrInvalidResource。
	Validate() error
}

每一种资源最终都会变为字符流(CgroupValue())写入 cgroup 叶子节点对应的文件(CgroupFile())

内存

// MemoryLimit 单位是字节，对应 cgroup v2 的 memory.max。
// 不允许 0（v2 中 0 = "max" 即无限制），用户想解除限制就别传 -m。
type MemoryLimit int64

func (m MemoryLimit) CgroupFile() string  { return "memory.max" }
func (m MemoryLimit) CgroupValue() string { return strconv.FormatInt(int64(m), 10) }
func (m MemoryLimit) Validate() error {
	if m <= 0 {
		return fmt.Errorf("%w: --memory must be > 0 bytes, got %d",
			ErrInvalidResource, m)
	}
	return nil
}

CPU占用率

// CPUMax 描述 cpu.max 的一行：每周期的 CPU 时间配额和周期长度。
// 对应 cgroup v2 cpu.max 文件格式 "$MAX $PERIOD"（单位均为微秒）。
type CPUMax struct {
	Quota  uint64 // 0 表示 "max"（不限制）
	Period uint64 // 周期长度（微秒）
}

func (c CPUMax) CgroupFile() string { return "cpu.max" }
func (c CPUMax) CgroupValue() string {
	if c.Quota == 0 {
		return fmt.Sprintf("max %d", c.Period)
	}
	return fmt.Sprintf("%d %d", c.Quota, c.Period)
}
func (c CPUMax) Validate() error {
	if c.Period == 0 {
		return fmt.Errorf("%w: cpu-max period must be > 0", ErrInvalidResource)
	}
	return nil
}

驱动接口

// Driver 是 cgroup 后端抽象。cgroupfs 和 systemd 各自实现一份。
//
// 接口维度（不是底层路径）：
//   - Create: 申请容器所属的 cgroup（scope 对 systemd 来说是 lazy：在 AddPID 时才创建）
//   - Apply: 写入 Resource 指定的资源限额
//   - AddPID: 把进程加进 cgroup；host PID 而不是容器内 PID
//   - Remove: 销毁 cgroup；可恢复错误（残留进程）记 warning 不 fatal
type Driver interface {
	Create(id, parent string) error
	Apply(id, parent string, resources ...Resource) error
	AddPID(id, parent string, pid int) error
	Remove(id, parent string) error
	Name() string
}

cgroupfs 实现

My Docker 1

Wed, 10 Jun 2026 15:43:55 +0800

今日任务

init 传参改用匿名管道

匿名管道

为什么要使用匿名管道

原方案通过 /proc/self/exe init [args...] 将所有参数直接塞进 exec.Command() 调用中，如果参数过长或者有特殊符号就会发生错误。

匿名管道的读和写直接走文件io，可以加强对参数的控制和校验

// run
func NewParentProcess(interactive, tty bool) (*exec.Cmd, *os.File) { // 返回 Cmd 对象和 管道的写对象
	fr, fw, err := os.Pipe() // 创建匿名管道
	if err != nil {
		l.Error("failed to create pipe", "detail", err)
		return nil, nil
	}

	cmd := exec.Command("/proc/self/exe", "init") // 不需要在此处将 args 传入
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID |
			syscall.CLONE_NEWNS | syscall.CLONE_NEWNET | syscall.CLONE_NEWIPC,
	}
	if interactive {
		cmd.Stdin = os.Stdin
	}
	if tty {
		cmd.Stdout = os.Stdout
		cmd.Stderr = os.Stderr
	}

	cmd.ExtraFiles = append(cmd.ExtraFiles, fr) // 将管道的读文件描述符放进新创建进程的文件描述符数组中, 新的进程通过这个fd可以打开对应的管道文件
	return cmd, fw
}

// init
const readingFd uintptr = 3 // 不固定

func Init() error {
	l.Info("initiating")

	l.Info("opening pipe")
	f := os.NewFile(readingFd, "pipe") // 打开对应的管道
	if f == nil {
		l.Error("failed to create FILE with the given fd", "fd", readingFd)
		return fmt.Errorf("failed to create FILE with the given fd: %d", readingFd)
	}

	l.Info("reading from pipe")
	data, err := io.ReadAll(f) // 直接走文件io
	if err != nil {
		l.Error("failed to read from pipe", "detail", err)
		return err
	}

    // 将参数反序列化
    //
    // 用 NUL 分隔符还原 cmds,避免含空格的参数(如 sh -c "echo hi")被腰斩
    // 使用管道传参可以完成更多的操作
	args := strings.Split(strings.TrimRight(string(data), "\x00"), "\x00")
	if len(args) < 1 || args[0] == "" {
		return fmt.Errorf("command is nil")
	}

	l.Info("remounting `/`")
	if err := syscall.Mount("", "/", "", syscall.MS_PRIVATE|syscall.MS_REC, ""); err != nil {
		l.Error("failed to remount `/` with `MS_PRIVATE`", "detail", err)
		return err
	}

	mountFlags := syscall.MS_NOEXEC | syscall.MS_NOSUID | syscall.MS_NODEV
	if err := syscall.Mount("proc", "/proc", "proc", uintptr(mountFlags), ""); err != nil {
		l.Error("failed to mount proc", "detail", err)
		return err
	}
	l.Info("executing", "argv0", args[0], "argv", args)
	if err := syscall.Exec(args[0], args, os.Environ()); err != nil {
		l.Error("failed to init", "cmds", args, "detail", err)
		return err
	}
	return nil
}

匿名管道

Tue, 09 Jun 2026 16:10:17 +0800

本质

存在于内核内存中的虚拟文件系统，属于进程的资源，内部使用引用计数

特性

数据单向流动
可跨进程

大小

可以通过以下命令查看

$ cat /proc/sys/fs/pipe-max-size
1048576 # 单位 byte, 1 MB

可以动态调整

阻塞/非阻塞

阻塞模式下，读/写一个写/读端被关闭的管道会直接返回
非阻塞模式下，读/写立即返回

如何创建

A -> B

A 进程创建管道， fork 出子进程 B

fork 会让主进程和子进程共用同一个fd数组，此时A和B实现了进程间通信

为了保证管道中数据的单向流动, A 关闭 fdr(读), B 关闭 fdw(写)

go 中如何创建

fr, fw, err := os.Pipe() // 创建
if n, err := fw.WriteString(strings.Join(cmds, "\x00")); err != nil {} // 写入
_ = fw.Close() // 写完一定要及时关闭，防止接收方堵塞

// 读取
//
// 需要打开管道
// readingFd 为进程中管道文件描述符在fd数组中的索引
f := os.NewFile(readingFd, "pipe")
if f == nil {
}

data, err := io.ReadAll(f)
if err != nil {
}

My Docker 0

Tue, 09 Jun 2026 11:36:16 +0800

仿造一个自己的 docker

今日目标

mydocker run -i -t
基础隔离

启动流程

mydocker run -i -t -> 解析 -> 启动 init 进程 -> 重新挂载 / 为 PRIVATE -> 挂载 proc -> 执行(Exec 系统调用)

为什么需要 `init` 进程

init 进程有独立的命名空间(namespace)和控制组(cgroup)，执行系统调用(Exec)后可以保证 pid 为 1并且与宿主机隔离

为什么要重新挂载 `/` 为 `PRIVATE`

使用以下代码验证

func Init(cmdPath string) error {
	mountFlags := syscall.MS_NOEXEC | syscall.MS_NOSUID | syscall.MS_NODEV
	if err := syscall.Mount("proc", "/proc", "proc", uintptr(mountFlags), ""); err != nil {
		l.Error("failed to mount proc", "detail", err)
		return err
	}
	if err := syscall.Exec(cmdPath, []string{cmdPath}, os.Environ()); err != nil {
		l.Error("failed to init", "cmdPath", cmdPath, "detail", err)
		return err
	}
	return nil
}

$ sudo ./cli run -i -t /bin/sh
sh-5.3# ps
    PID TTY          TIME CMD
      1 pts/5    00:00:00 sh
      6 pts/5    00:00:00 ps
sh-5.3#

可以看到容器内 ps 命令执行没有报错并且返回内容符合预期(作为容器内的 init 进程)

Linux Namespace

Sat, 06 Jun 2026 14:30:57 +0000

发信箱模式 Outbox Pattern

Sat, 06 Jun 2026 14:25:36 +0800

解决了什么问题？

分布式系统通过消息队列等手段互相解耦带来的状态不一致, 如数据落库成功但是kafka消息发送失败等情况

是什么？

利用本地数据库事务的原子性，将数据入库和消息入库(outbox-records)变为原子性操作。

异步启动一个 poller() worker 定时从 outbox-records 中取出消息尝试发送，消息至少被成功发送一次, 保证了分布式系统数据的一致性。

问题

高并发场景下会导致更高的延迟
消息接收端需要做幂等性校验
发送失败/超时不能自动回退数据库操作

使用 PostgreSQL 的行锁

通过给 Outbox 表的查询语句加上行锁

SELECT id, event, payload, topic
FROM outbox
FOR UPDATE SKIP LOCKED

就可以让多个 poller 同时抢占发信任务，提高效率的同时也不会导致竞争

SKIP LOCKED 是 pg 独有的拓展，语义是跳过已经上锁的行

Golang 多路复用

Sat, 06 Jun 2026 14:24:52 +0800

快速路径

运用 select 中的 default 分支可以实现无锁（非阻塞）的快速检查

select {
    case v, ok := <- ch:
        if !ok { // ch 已经被关闭, 直接返回
            return io.EOF
        }
        return v // ch 缓冲区中有内容, 直接取出返回
    default: // ch 缓冲区中无内容，select 走 default 分支防止阻塞
}
select { // 阻塞等待
    case v, ok := <- ch:
        if !ok { // ch 已经被关闭, 直接返回
            return io.EOF
        }
        return v // ch 缓冲区中有内容, 直接取出返回
    case <- ctx.Done(): // 等待超时/取消
        return ctx.Err()
}

在阻塞等待之前加入快速路径主要是因为 golang 中的 select 具有随机性，在高并发场景下可能会出现 <- ctx.Done() 分支永不被进入。详细的源码解析见下文

Linux Cgroup

Sat, 06 Jun 2026 14:16:35 +0800

新版内核普遍采用 v2 版本的 cgroup

是什么

cgroup 既 Controll group, 是 linux 对外提供的文件接口，用来控制进程资源。

$ mount -t cgroup2

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot,memory_hugetlb_accounting)

使用

新建 group

直接在 /sys/fs/cgroup 下新建目录

$ cd /sys/fs/cgroup/
$ sudo mkdir test
$ ls ./test
cgroup.controllers      cpu.stat             memory.peak
cgroup.events           cpu.stat.local       memory.pressure
cgroup.freeze           cpu.uclamp.max       memory.reclaim
cgroup.kill             cpu.uclamp.min       memory.stat
cgroup.max.depth        cpu.weight           memory.swap.current
cgroup.max.descendants  cpu.weight.nice      memory.swap.events
cgroup.procs
...

重点关注 cgroup.procs 这个文件，其中的内容(pid)既我们想要控制的进程号。

控制cpu占用率

$ while true; do : ; done &
[1] 50274 # 50274 为对应pid
$ top -b -n 1 -p 50274 | grep "50274" | awk '{print $9}'
99.7 # 此时没有限制，死循环占用100%的cpu
$ echo 50274 | sudo tee cgroup.procs # 直接使用当前shell的进程号, 这样子随后开启的子进程也会受到控制
$ echo 2000 10000 | sudo tee cpu.max # 10000 微秒内 `$$` 进程只能占用 2000 微秒
$ top -b -n 1 -p 50274 | grep "50274" | awk '{print $9}'
19.9 # 20%

控制内存

测试程序

hellopoisonx bb

分布式事务

分布式事务

2PC / XA

TCC

Saga

事务消息

Outbox 模式

RocketMQ 事务消息

方案取舍

My Docker 3

今日目标

pivot_root vs chroot

工作原理图解与说明

chroot 的原理

pivot_root 的原理

UnionFS OverlayFS

是什么

OverlayFS

My Docker 2

今日目标

如何实现

将 Cgroup 控制的资源抽象为接口

驱动接口

My Docker 1

今日任务

init 传参改用匿名管道

为什么要使用匿名管道

匿名管道

本质

特性

大小

阻塞/非阻塞

如何创建

go 中如何创建

My Docker 0

今日目标

启动流程

为什么需要 init 进程

为什么要重新挂载 / 为 PRIVATE

Linux Namespace

发信箱模式 Outbox Pattern

解决了什么问题？

是什么？

问题

使用 PostgreSQL 的行锁

Golang 多路复用

快速路径

Linux Cgroup

是什么

使用

新建 group

控制cpu占用率

控制内存

`pivot_root` vs `chroot`

`chroot` 的原理

`pivot_root` 的原理

为什么需要 `init` 进程

为什么要重新挂载 `/` 为 `PRIVATE`