今日三荐：HTTP/2 帧、列式缓冲与 vnode 树

1. grpc-go：一次调用是三轮帧

为什么今天看

最值得拆的机制

• 一次调用是三轮帧。 请求头走 HEADERS，消息走 DATA，状态码走最后一轮 HEADERS，这一轮叫 trailers。5
• 消息在 DATA 里带五个字节前缀。 1 字节压缩标志，4 字节大端长度，后面才是消息体本身。5
• 出错时连 DATA 都没有。 规范管这叫 Trailers-Only：一个 HEADERS 帧带 grpc-status 与 grpc-message 就结束。5
• 状态码不在 HTTP 那一层。 正常返回时 HTTP 是 200，业务结果放在 trailers 的 grpc-status 里。5
• 重复的头只发一次。 HPACK 维护一张动态表，第二个请求用索引指回第一个请求发过的头。5

wrote HEADERS len=98 stream=1
read  HEADERS len=14 stream=1            :status 200, content-type: application/grpc
read  HEADERS len=24 END_STREAM stream=1 grpc-status=0, grpc-message=""
[stats] OutHeader  authority="127.0.0.1:50051"
[stats] OutPayload wire_length=12
[stats] InPayload  wire_length=18

wrote HEADERS len=17 stream=3
read  HEADERS len=2 stream=3
read  HEADERS len=2 END_STREAM stream=3

复现难度：低

最小上手路径

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
mkdir grpctry && cd grpctry && go mod init example.com/grpctry
go get google.golang.org/grpc@v1.85.0
mkdir demo

syntax = "proto3";
package demo;
option go_package = "example.com/grpctry/demo";

message Ask   { string name = 1; int32 n = 2; }
message Reply { string text = 1; int32 idx = 2; }

service Greeter {
  rpc Say   (Ask) returns (Reply);
  rpc Count (Ask) returns (stream Reply);
}

protoc --go_out=. --go_opt=paths=source_relative \
       --go-grpc_out=. --go-grpc_opt=paths=source_relative demo/demo.proto
go run ./cmd/server &
GODEBUG=http2debug=2 go run ./cmd/client

今晚练习

1. 把帧打开。 就用上面那条 GODEBUG，数第一次调用出现几个 HEADERS、几个 DATA。本机是三个 HEADERS，DATA 一个都没打印。
2. 自己算一遍前缀。 把 Ask 里的名字改成 11 个字符，wire_length 应该从 12 变成 18。算对一次，5 字节前缀就记住了。
3. 比两次调用。 在同一个连接上连发两次，盯住第二个 wrote HEADERS 的 len。98 掉到 17 就是 HPACK 在起作用。
4. 造一个错误。 让服务端返回 status.Error(codes.InvalidArgument, ...)，再跑一遍。你会看到只有一个 HEADERS 帧，grpc-status=3。
5. 读 :authority。 注册一个 stats.Handler，在 OutHeader 里打印 Authority。这个字段是 1.85.0 才有的，值就是网线上发出去的那个伪头。1

版本动作与限制

• 1.85.0 要求 Go 1.26，go.mod 里写的是 go 1.26.0。6
• Stop() 现在能打断正在等待的 GracefulStop()，卡住的进程有救。1
• 缺 :authority 与 Host 的请求会被直接拒掉。前面挂着自己写的 HTTP/2 客户端时，得补上这个头。1
• 控制帧限流上限可以用 GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT 调，名字里带 experimental。1
• http2debug=2 不打 DATA 帧，本机数出来是零条。消息大小只能从 stats 的 WireLength 看，这一点别指望日志。
• 这是 Go 的实现。上面那套帧格式是所有语言共用的规范，换个语言读到的还是同样的三轮帧。5

2. arrow-rs：一张表是几段缓冲

为什么今天看

最值得拆的机制

• 一个数组只有四样东西。 类型、一串缓冲、长度、null 的个数。10
• 定长类型就是一段连续值。 一列 Int64 是每 8 字节一个值，从头排到尾，没有指针。10
• null 单独存一位。 有效性位图一位一个槽，全非空时可以不分配这块内存。10
• 变长类型分两段。 offsets 存 length+1 个起点，data 存所有字节挤在一起。10
• 切片的代价是一个整数。 缓冲一动不动，只把起点往后挪，这就是零拷贝。10
• 64 字节对齐是为了 SIMD。 一次读满一个 512 位寄存器，循环里不用再判边界。10

本机实测：一百万行，两列

rows=1000000 cols=2
arrow memory accounting = 28777496 bytes
row store: vec slots = 32000000 bytes, string heap = 20000000 bytes, total = 52000000 bytes
slice(100,10): offset=0 len=10 pointer delta=800 bytes first_value=100
record batch slice: pointer delta=800 bytes first_id=100
5 values, 2 nulls: values buffer = 40 bytes, null bitmap = 1 bytes
filter every-100th row: 10000 rows out of 1000000 in 456.641µs, output memory = 240220 bytes
parquet write: 24404164 bytes in 86.172526ms, 1 row groups
parquet read: id column only = 4.49705ms, both columns = 20.310449ms
parquet zstd(3) write: 1865768 bytes in 94.840177ms

复现难度：中

最小上手路径

cargo new arrowtry && cd arrowtry
cargo add arrow@60.1 parquet@60.1

use std::sync::Arc;
use arrow::array::{Int64Array, StringArray};
use arrow::datatypes::{DataType, Field, Schema};
use arrow::record_batch::RecordBatch;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let ids: Int64Array = (0..1_000_000i64).collect::<Vec<i64>>().into();
    let names = StringArray::from_iter_values((0..1_000_000).map(|i| format!("user-{i:07}")));
    let schema = Arc::new(Schema::new(vec![
        Field::new("id", DataType::Int64, false),
        Field::new("name", DataType::Utf8, false),
    ]));
    let batch = RecordBatch::try_new(schema, vec![Arc::new(ids), Arc::new(names)])?;
    println!("{}", batch.get_array_memory_size());
    Ok(())
}

cargo run --release

今晚练习

1. 打印一段缓冲。 拿 Int64Array::values() 看它指向哪儿，再看 offsets() 的那段。一列变长字符串会多出 offset 缓冲，长度是行数加一。
2. 量一次切片。 ids.slice(100, 10) 之后，把两个指针相减。本机是 800 字节，正好一百个 8 字节，证明没复制。
3. 算一遍位图。 造一个有 5 个值、2 个 null 的数组，位图占 1 字节。行数涨到 100,000 时再算一次，应该是 12,500 字节。
4. 跑 filter。 一百万行留十分之一，输出 10,000 行。把输出体积和 10,000 × (8 + 4 + 11) 对一下，能看出它只留了选中行。
5. 只读一列。 Parquet 读回时加 ProjectionMask::leaves，只投影 id。本机从 20.31 毫秒掉到 4.50 毫秒。
6. 压一次。 用 WriterProperties::set_compression(Compression::ZSTD(...)) 再写一遍，对比文件大小。24.4 MB 掉到 1.87 MB。11

版本动作与限制

• 60.1.0，Apache-2.0。12
• 仓库里 57、58、59 三条旧线还在发补丁，升级前先确认自己钉在哪条线上。9
• 列式换来的代价是改一行要重写整列。单点更新、随机写，它不是好选择。10
• 内存记账会把 64 字节填充算进去，28,777,496 这个数比有效载荷大一点。10
• 本机只测了一列短字符串。真实宽表、长文本、嵌套类型，差距会比这里更大，代价也更碎。
• 这套内存布局是跨语言的规范，Python 的 pyarrow、C++ 的实现读到的字节排布和这里一模一样。10

3. preact：一次更新先是一棵树

为什么今天看

最值得拆的机制

• 组件是一个函数。 它返回 vnode，vnode 是普通对象：type、props、children、key。18
• 一次更新先建一整棵新树。 然后把新树和旧树比，只把差异落到 DOM。18
• 默认按位置配对。 第 3 个旧节点对第 3 个新节点，不看内容是什么。18
• 给了 key 就按 key 配对。 节点能找到自己上一轮的身份，位置变了也只是移动。18
• hooks 按调用顺序存。 第 n 次 useState 取数组第 n 格，所以 hook 不能放在条件里。18
• 核心只有两千多行。 src 下十三个文件共 2,197 行，最大的一个是 diff/index.js，833 行。

本机实测：往一千行的列表前面插一行

keyed   prepend to 1000: 8.86 ms insertBefore=2 appendChild=0 removeChild=0 text=0
unkeyed prepend to 1000: 4.54 ms insertBefore=2 appendChild=0 removeChild=0 text=1000

复现难度：低

最小上手路径

mkdir preacttry && cd preacttry
npm init -y
npm i preact@11.1.0 jsdom

import { JSDOM } from 'jsdom';
const dom = new JSDOM('<div id="root"></div>');
globalThis.window = dom.window;
globalThis.document = dom.window.document;

const { h, render } = await import('preact');
console.log(JSON.stringify(h('li', { class: 'x' }, 'hi')));
render(h('li', null, 'hello'), document.getElementById('root'));
console.log(document.getElementById('root').innerHTML);

{"type":"li","props":{"class":"x","children":"hi"},"__k":null,"__":null,"__b":0,"__e":null,"__c":null,"__v":1,"__i":-1,"__u":0}
<li>hello</li>

今晚练习

1. 打印一个 vnode。 就用上面那三行。看清 type 和 props 之后，preact/src/create-element.js 那 122 行就不难读了。
2. 数 DOM 操作。 把 insertBefore、appendChild、removeChild 包一层计数器，再把 CharacterData 的 data setter 也包一层，就能复现上面那两行结果。
3. 换个改法再测。 把「前面插一行」换成「反转整个列表」，再跑一遍同样的计数，看两种写法的差距往哪边变。
4. 看 hooks 存在哪。 渲染一个用了两次 useState 的组件，打印它的 __c.__H，会看到一个长度 2 的数组。
5. 量体积。 preact.mjs 12,088 字节，gzip 后 5,023；hooks 3,636，gzip 1,594；compat 9,788，gzip 3,985。
6. 读一遍 11 的删除清单。 replaceNode 没了，Component.base 没了，SuspenseList 没了，useEffect 的清理延后到绘制之后。17

版本动作与限制

• 11.1.0，MIT。18
• 核心只发 ESM，扩展名 .mjs。.module.js、CommonJS、UMD 三种包全删了，直接引 preact/dist/preact.min.js 会拿不到文件。17
• 浏览器下限是 Chrome 71、Safari 12.1、Firefox 69、Edge 79；TypeScript 最低 5.1。17
• style={{ height: 500 }} 不再自动补 px，这个行为搬进了 preact/compat。不用 compat 的话，渲染结果会变。17
• useEffect 的清理函数现在延后到浏览器绘制之后，和 React 一致。卸载后立刻断言的测试要先冲一次 effect。17
• 上面那些毫秒数是 jsdom 里量的，不是真浏览器。DOM 调用次数可信，绝对时间只能当量级看。

怎么选今晚的第一条路径