D0

出于省钱的考虑，我们买了 PVG 往返 SIN 的飞机票。周六早上 9.35 起飞，所以我们周五就住在浦东机场了。PVG 的汉庭挺旧的，索性还算干净。

D1

早上六点就从酒店过去了，结果被骗了，短信说是 H 岛，实际上是 T2 的廊桥，所以我们在 PVG 等了好半天。幸亏飞机没有延误，所以我们接近是满血登上飞机。这个飞机还不错，是个 787，不仅有午饭吃，甚至每个人还有 20 min 的免费 wifi 可以用。不过据说外航现在都接入马斯克的 starlink，全程有免费 wifi 了。anyway，我还是在飞机上看完了白日梦想家这个电影，然后我觉得我们冰岛没去白日梦想家小镇那也太对了，感觉实在没啥可看的，而且这个电影没有花多少镜头在这个小镇上。

下了飞机，我还处于没有电话卡的状态呢。我之所以这么勇，是因为之前查过樟宜机场是全 wifi 覆盖的（后来发现大部分地铁站也有免费 wifi）。

我们入境也挺麻烦的，那个护照扫描一直要 rescan，而我妈好像弹出一个比较奇怪的错误提示。后面工作人员挺不耐烦告诉我们要先去入境登记，所以我就跑到另一边的几个 ipad 那边入境登记。反正那个系统贼麻烦，填了一堆东西，末了我发现好像可以两个人写在一个单子里面，就可以少填一份，不过也没办法了。反正最后还是跌跌爬爬入境了，然后就是弄电话卡，然后去摆渡车。这个摆渡车还分了两个队，我傻等了两分钟，愣是等到一辆我们的车开走，才知道这个不是我们的队。所以我索性直接出去等了，不过也没等多久，车就到了，我们上去，总算到了 T2，走 T2 上了地铁。

我们先去的酒店，走索美塞下车，走一会就到了。不过这里路口很扯，那个 Orchard 路，一边有红绿灯可以过，一边没有。去宾馆就还是挺顺利的，也没要交什么城市税，也没有刷信用卡授信。这个宾馆其实还行，无非就是床小了点，设备旧了点。

放下东西，喝了点厕所的水，我们就出门。zhangqi 还在外面，所以我先带我妈去逛逛附近的福康宁公园。

晚上和 zhangqi 吃了饭。好久不见，原来他已经工作了。据说是在 HW 新加坡 branch，然后他们那并不加班。

D2

今天一天都是植物之旅。

早上首先是按照我从小红书临时搜到的线路 city walk，第一站坐到 city hall，看一下几个教堂。应该是周日的缘故，所以大家还在做弥撒，教堂不太能走进去。后面看了下旧禧街警察局，发现不就是昨天从福康宁公园下来的地方么？然后仔细一看，这边好像是新加坡现在的什么文化和青年部。再往前走就又是 clay quay 了，我们就没有再进去逛，而是往牛车水方向走。不过我实际感觉这段又累又没啥可看的，有个楼上涂鸦了一个花旦，我妈站在天桥上拍了下。进入了牛车水附近，路牌也会标注中文，还是挺有意思的。总而言之，在经过了老巴刹之后，我们就开始往喷水狮子那边走。路上有趣的是我看到了头条的新加坡办公楼。

到了喷水狮子那里，遮蔽越来越少，原来还能有连廊或者树木遮阳，现在直接在海边暴晒了。我们拍了拍现在已经近在咫尺的金沙三炷香，然后去狮子那边。狮子也没啥了不得的，我们就几个角度拍了照，就准备走了。

我看了下去滨海湾的公交，最后还是决定走路过去。不过走路过去好像也不是很远。这里我原以为滨海湾花园就是在金沙那三炷香顶上，后来才知道，这是一个专门的地方，在金沙的东边。一路上走着，听见说滨海湾的花穹和云雾林都很冷，想着我今天短袖短裤别给搞感冒啊。滨海湾花园有点类似于一片大公园，我们需要走一个小匝道绕进去。进去之后啥都没有，我还是看了路牌，换了一对导航才确信自己走对了。不过深入走了一段，很快就能看到那些长得很神奇的人造树，我确定自己走对了地方。然后就是买票，这边如果现场买票贼贵，一个景点都要 50 新。所以我搜了下 klook，两个人才 240，给我便宜哭了。我甚至担心这个是假的，不过我们很顺利就进去了。

花穹进去的通道，觉得很冷，但是等到了那个冷室里面，反而不冷了。这是因为冷室是玻璃的，所以太阳照进来暖洋洋的。这个冷室挺大的，分为了好多区。我刚进去往左走，分别是南非和南美。然后再深入，则可以往下或者往左上走。往左上走是去加州区，往下走则可以到一个庭院，里面是土耳其主题的花卉展，感觉最近是在和土耳其搞活动。说到这个，其实刚才一进来就看到一个土耳其航空的飞机，这我总算是回过味来了。

回到出口那，其实右边还有一堆地方没探索，主要是猴面包树区和多肉植物区。比较有意思的是这个区域中还陈列了一堆插花作品，我拍了一些，感觉都挺有创意的。

从花穹出来，就直接去云雾林了，距离很近，其实这两个甚至共用了一个出口。一进云雾林，就看到一个巨大的瀑布，非常壮观。然后再往前走就是一些恐龙，比如霸王龙，梁龙等等，头还能动，还有各种声光特效。我感觉挺违和的。不过云雾林非常有意思的地方是你可以坐电梯到 6 楼，然后爬到 7 楼，再往下走。因为这个展区实际上是为了展示热带雨林从高海拔到低海拔的植被的变化，所以这么做我觉得挺有意思的。类似的，我们晚上在国家兰花园里面，也看到一个类似的展区，按照海拔展示了不同的兰花。

云雾林有个特色就是下雾，进门去的时候，我们留意了下，下一场是 14.00。我原以为他会喷出一种西游记那样的烟雨蒙蒙的仙境的感觉，但实际上它就是搞了点小雾气洒洒水而已。

中午在滨海湾的时候和 Bugen 约了晚饭，是 Little Elephant 啥的店，一个泰餐。我看了下，发现它离植物园也不远，仔细研究了下，我发现可以从植物园北门逛到南门，这样正好可以坐地铁去那边。

从滨海湾花园出来，我们又是绕来绕去兜了不少路，走到一个商场的 B2 去吃一个肉骨茶，据说是米其林，然后点评也是排名前几的。结果一到那边发现 B2 是个食阁，所以米其林这么没牌面的么？食阁大概就是没有一个专门的店面，只有一个档口，然后中间有一些共享吃饭的地方。把饭拿过来之后，就在那边吃，吃完要自己送餐盘到规定的地方，然后还要按照是否清真来分类放置。

吃完饭，我们准备走路去地铁，前往植物园，路上还发现这个地方居然有赌场。我之前从没见过赌场，发现好像进去居然要登记护照。并且这个赌场看起来很奢华，占了一层，金碧堂皇的。我们后面走外面走，也好像路过这个赌场开在外面的门，但是是常闭的，写着什么“尊上禁止进入”之类的话，感觉又客气又严肃。

下了植物园地铁站，出到地面就是植物园。这个植物园是免费的，只是里面的兰花园要收费。我们的时间不多了，所以只能简单逛逛。刚进门的地方有一些竹子和攀爬植物，然后绕来绕去走到了一个植物园边缘的道路上。植物园是半开放的，这个道路走着走着就能走到外面的公路上，自然这条路也没啥风景可以看。但是我很快在地图上看到有个叫芳香植物的地方，所以我就想过去闻闻香味。所以我们又找了个岔路绕了点路回去，走到了一个小山上。在快走到的时候，我发现还有个园区是有关药用植物的，然后旁边还有个关闭着的园区写着是有毒植物，我们远远看了看，基本都不认识。不过药用植物里面有不少也挺香的，反而是走到芳香植物那个片区，我预想的那种芳香满庭的场景并没有发生，我们还是得凑到花上去闻才行。

从芳香植物下来之后，我们就准备前往兰花园了。不过路上我看到一个热带雨林片区，里面黑黢黢的，一开始不敢走，怕蚊子。不过后来看到两个老外进去了，所以我也返回，也带着老妈扎了进去。因为走的快，所以其实还好，没有被怎么咬到。中间还看到一棵大树，STRANGLING FIG，它的牌子上写着没有游客能够走过这个树而不驻足观看的。因为他真的特别特别粗。

到了兰花园门口，准备买票。我看了下 klook 好像没优惠，就直接走信用卡了。但好像其实你点进去，是有折扣的，不知道这个软件是怎么设计的。这个地方收费也很离谱，最便宜的只要一块钱，我们这种啥弱势群体/公民身份都不沾的就得 15 新奉上。入口的人还问我妈有没有满 60 岁，我也比较好奇这个是不是纯看诚信？

后来我总结，兰花主要是根和花。它的根有点类似于水仙花那样长，并且很容易寄生在别的树木上面，在一些地方，我看到它甚至是在钢筋上面的。

晚饭时间，点了冬阴功，感觉更酸辣。点了点香茅饮料水，感觉是真的挺好喝的，我和我妈后面又补了一杯。另外，沙拉也挺好吃的。我们在那里谈了不少东西，感觉非常传奇。有一点我比较震撼的是知道现在做 LLM 的人基本 90% 都是中国人，不过处于合规的原因，很多都得出国了。我还请教了 vLLM 和 SGLang 的区别，据说现在两个同质化很严重。SGLang 只是一开始引入的结构化生成语言（也就是得名）比较有意思，不过现在都是 OpenAI 的接口了。说到这，他也提到他现在在做的一些工作，我也对 vLLM 的接入层进行了学习了解。

然后我们就回宾馆了。

D3

今天一天都是动物之旅。

早上起的比较早，先去地铁站附近的大南洋吃了个早饭。是海鲜面啥的，感觉还行吧。

然后就是去动物园了，我们走索美塞上车，直接可以坐到卡迪。走卡迪下车，没几步就是 M2 的公交车了。其实在地铁站里面是有个路牌的，我当时还看着 google 地图找了一阵子。

这个 M2 也是奇怪，前面的车刚坐满，一个人没往上站，就让我们坐下一辆。但是下一辆又是站满了人，不知道是什么目的。总之也是晃晃悠悠才到了动物园片区。这个片区非常大，并不只是我们知道的五大动物园，还有一堆探险园啥的，都挤在一起。

我的计划是新加坡动物园和河川馆，因为飞禽世界在另一个区，而 night safari 大家都说啥都看不到。

先去了新加坡动物园，在 klook 上买的票，也是很省钱的，两个人才 358。不过这里坑的是最好买的时候就选一下日期，不然就要在一个很难用的网页上选日期，我们在门口搞这个卡了很久。另一个是最好每个人分开来买，这样优惠最高。我看了一些七拼八凑的攻略，也试了下旅途随身听，感觉实际都不如 Mandai 那个 App 有用。

我们墨迹到快十点才进园，然后我就直奔那个海狮表演。进去的时候，走了下树冠小路，比自己预期差了不少，因为只有一点点短。从上面下来之后，都是有凉棚的路，当然平行的也有一条树林小径，这个后面我们也走了一遍。

然后我们就走到动物园的中心，也就是餐厅，什么阿明餐厅啥的。在那边往左拐，再往右拐，走一会，就到那个剧场了。后来我发现这个海狮表演应该是这个动物园完成度最高的表演了。

海狮表演结束之后，我们连合照都没合照，就赶快去那个萌宠表演。这可要了大命，萌宠表演在另一个非常远的地方。我们后来回想，其实不如就在这里拍下照，等 11 点的另一场表演结束算了，萌宠表演可以下午看。而我们实际上是先急行军过去看了萌宠表演，然后下午两点半临走前，又绕回来看了这个剧场的另一个表演。

Anyway，我们走了点回头路，然后又穿过了整个绕来绕去的爬行馆片区，然后走到了一片 kid’s world 区域。我们在那里来回绕了半天，从冲淋区走到萌宠区，终于在一个类似于露天广场的地方找到了这个表演。当时表演已经进行了一部分了，我们看的部分是一只羊、一只猫、一只马和一只狗，我的第一反应是方舟动物园里面的萌宠不会就是照着新加坡动物园做的吧。不过这个表演与其说是才能展示，不如说是行为展示。羊象征性走了下秋千，但这个已经是最给面子的了。猫就是慢慢的走，然后穿过一个比一个小的圈圈。为了凑时间，甚至还邀请了一个大人和一个小孩上去钻更大的呼啦圈。马的展示就是看了四个刷子，然后刷一下马。因为马脸比较娇嫩，所以有个专门的刷子，感觉过的比人还好。那个叫 Lucas 的狗是最离谱的，啥都不做，就只会握手。

总之看完这个表演，我们才开始逛动物园。首先是先把萌宠这个区给逛完，然而我们也失算了，因为这个区实在是太乱了。我的想法是从 kids world 开始逆时针逛，所以大概是把来的时候的爬行馆给逛了。我觉得这是对的选择，因为新加坡动物园的爬行区确实很赞。南京红山森林动物园其实只是学了新加坡动物园的一些管理思想吧，比如不训练动物表演，但其实展出的动物类型还是差别蛮大的。比如我们就看到一个大蜥蜴，已经觉得很霸气了，但一看，是什么科莫多巨蜥，我一直以为这个是某个已经灭绝的牛逼生物呢。过了巨蜥，还看到不少超大的乌龟。而爬行馆里面更是五花八门，比如说有两个头的蜥蜴还是蛇，有传说中的西部菱斑响尾蛇。这里还有一个鸟/蝴蝶馆和脆弱雨林展区，我们也在稍后逛过了。鸟馆里面，与其说是鸟，我见到最多的是果蝠。爬到一个台子上面，可以离他们很近观看。雨林展区里面也是挺大的，感觉和爬行馆里面展示的东西差不多。

新加坡动物园还有一个特色的猴子比较多。从鸟馆出来之后，我也看到黑冠猴啥的。路上还看到有小蜥蜴在爬，还拍了视频。然后我们就离开这个片区往回走了，然后走到一个 Sensory Garden 里面，这里面是个南美巨骨鱼，那鱼还挺大的。然后这一圈又是一个猴子岛，里面有很多猴子，这一片其实就是灵长类王国。

出去之后，就是一个埃塞俄比亚大峡谷展区。里面展示了一些土著的建筑，以及一个非常大的狒狒园区。狒狒看起来还是非常离谱的，屁股又红又大。

最后一站看了亚洲象，然后就回到早上那个剧场看最后那个表演。中途，我准备抢 16.30 的票，发现网非常拉胯，硬是没抢到。

从新加坡动物园过来，就直接去河川馆了。这次吸取经验，让我妈自己买指定日的票了。进去之后，发现这个馆好像不是很大。我们是朝左走，好像是可以看大熊猫，虽然我也不是很喜欢大熊猫。它这个河川馆的意思是展示了全世界的各个河流的生态，比如尼罗河、澜沧江等等，基本上是一条单向的步道，走到大熊猫那边是长江展区。看完之后，相当于就走了一半了。跨过一个桥，就到了另一边。另一边主要就是 16.30 的表演，以及一个 5 新的船。我买了票，说是要排 30 min，实际上 12 min 就上了。我们一共坐了三次，3 4 5 排都体验过了。这个船还是挺好的，首先它不是很吓人，也没有溅很多水出来。然后，它路过的动物都是比较活跃的，比如食蚁兽、朱鹮、猎豹、卡皮巴拉，还有一些猴子等。

坐完船，其实前面就没啥了。有印象的主要是一个亚马逊主题，里面有一个非常深的水池，里面养了海牛等等之内的大动物。可以从一个海底隧道进去，然后绕着圈圈一直看到最上面。不过因为我去过大阪的海游馆，所以我觉得也就 soso。

从动物园出来，准备在卡迪地铁站附近的超市买点水果，都准备买了，发现原产地是澳大利亚，感觉没啥意思啊，就没买。这边水果品种也不多，4 个芒果 4 新好像倒是很便宜，但是特别大，感觉带不走。

因为 zhangqi 推荐了白鸡尾饭，所以今天我在 Orchard 站附近的一个商场的食阁里面找到了一家也是很有名的天天海南鸡饭。这个商场是真的破，感觉和兴化的招商城有的一拼。但里面剪头美甲真的好贵，剪头要 25 新，美甲要 100 新，而且也不是那种很装修豪华的店，就跟街边的小店一样，感觉新加坡是真的贵。天天家的点菜，我是真的不知道了，因为我不知道白鸡尾饭用英文怎么说。幸亏那个店员会中文，所以我跟他说他是听的懂得。好像这个就是海南鸡，只是部位不同。一般的是带骨头的，但是鸡尾是不带骨头的，并且还特别嫩。

从这个店出来，找到一家 fair price 超市，准备买点水果。这边不少水果奇形怪状，我找了半天，最后用 kimi 和 chatgpt 帮忙选了一个叫 salak 的水果。吃着挺好吃的，很香，肉也紧实，水不是很多，吃在嘴里还有点脆。

回到宾馆，问了下服务人员，说是可以免费寄存行李的，只要不过夜。

D4

今天起的更早了，原因是我想先出去逛一逛，然后回来洗个澡再退房，不然我一天汗流到屁股沟子里面很难受了。昨天晚上我就在纠结到底去哪里，早上去圣淘沙好像不太来得及，但是那些博物馆又是十点钟才开门。正好我妈昨天晚上说见了一大堆外国人，所以我寻思就带他去看看各个民族的街区吧。

所以第一站我们去了小印度。这时候，旅途随身听就起到了作用，对于这个景区，它规划还是挺好的，讲解也不错。我们先去了竹脚中心，我妈有点想吃印度飞饼，但是我们找了一个摊子，发现人家说没开门，也不知道真的假的，我看他倒是做的热火朝天的。anyway，我们逛一圈也没看到有啥可以吃的，就出去继续逛了。期间逛了一些某个华人的故居，甘地纪念馆，一些印度不同地方风格的寺庙。比较有趣的是在一条街上距离 30 米内有一家印度庙，一家观音庙和一家清真寺。

逛完小印度，准备去苏丹回教堂和甘榜格兰。不过发现与其坐地铁，好像走几步就到了。中间我还试了下这边的甘蔗汁机器，感觉不错。这边甘蔗比较有意思的，它好像一节节纺锤一样。走到武吉士附近，能看到一个 Rochr 运河，以及来福士医院。我妈觉得挺神奇的，为什么这个医院门口没有像江苏省人民医院门口全是人挤人。苏丹回教堂看着挺漂亮的，不过没开。往前走一点就到了甘榜格兰，它感觉就差强人意，其实就是个小庙。而且也没开放，还有墙围着，所以我们就准备往回走，去看看马来文化园。这个地方好像之前说黄循财来过，最近还在免费期。

到了文化园，还差几分钟 10 点，准备等一下。我妈上了个厕所，我找了半天入口，发现在另个建筑中。走进去发现这其实是一个小馆，并不是很大，两层楼，每层楼有四五个展厅。刚进去的时候，门开不下来，然后找到那边办公室，说是免费的，但是还是要先给我们一个 tag 贴在衣服上，比较有仪式感了属于是。一楼是新加坡国王，以及殖民相关的，比较有印象的是有个抓大象用的矛。二楼是近代相关的，还有一个专门的马来西亚电影艺术家展厅。这里比较有意思的是二楼的一个像船一样的东西，其实叫 Congkak。另外还有个刨椰子的东西。

我们是匆匆逛完这个文化园的，然后就快速往宾馆走。路上又看到那个回教堂，但是抓紧时间，也没有再进去，从外面看了下，里面全是人。到了宾馆，洗了个澡。我妈把我想扔掉的衣服又偷偷背回来了，不过我还是想办法扔掉了个白的。

从宾馆出来，这次就直接退房了。因为要去新加坡国家博物馆，所以路线还是和第一天一样，路过多美歌，以及福康宁树洞，这一次总算是可以看看长什么样子了。我们路过 Istana Park 的时候，我突然意识到，对面那个戒备庄严的地方，可能就是新加坡的总统府，后来发现好像确实是这样。

到了新加坡博物馆，发现太阳是真的毒辣。此时，刚好快 12 点，我寻思博物馆也不知道要逛多久，不如吃个东西。一搜，结果附近有一个便宜米其林，这就过去吃了。

吃完，就去博物馆。这个博物馆应该是我看过最垃圾的博物馆了。

存储

综述

目前存储格式基本上分两种思路：

• 基于图的方法，如 HNSW、Vamana / DiskANN
  • 结构：向量是图里面的点。选择比较近的向量，或者能够向其他 cluster 连通的向量（Vamana）去连边。
  • 搜索方式：从入口点开始，查找当前节点的所有邻居和待查询向量的距离，然后选择最近的跳过去。重复迭代，直到找不到更近的邻居。
  • 特点：Accuracy 高，但如果图太大或者结构太复杂，IO 性能不是很好。特别地，HNSW 得全部放在内存里面。
• 基于聚类的方法，如 IVF-PQ、SPANN、SPFresh
  • 结构：先用 KMeans 等算法对向量进行聚类，然后把这些向量都挂到对应的 cluster 下面，类似倒排索引一样（Inverted File / IVF）。
  • 搜索方式：找到最近的几个 Centroids，把倒排索引里面的向量捞出来比对。
  • 特点：对磁盘友好，数据局部性好。

量化技术

Vamana 算法

Vamana 没有 HNSW 那么多层级，它只有一层图。这一层图中，既保留了 HNSW 中最下面的稠密层类似 kNN 那样的边，但是又保留了一些长程边。这样，兼顾了 HNSW 稀疏层的“快速跨越跨度”能力和稠密层的“局部精细搜索”能力。

因为只有一层，所以 Vamana 是把一个节点及其所有的邻居节点、连同它们的原始向量，物理上紧密地排列在磁盘上的相邻位置。当算法访问节点 $A$ 时，直接把 $A$ 的向量和它所有邻居的信息整块（Block）读入内存。Vamana 严格限制每个节点的最大邻居数（例如最多 64 个）。这样可以确保“节点+邻居信息”的大小绝对不会超过磁盘的一个 Page（通常是 4KB）。

具体实现

1. 搜索时的 Tradeoff：参数 $L$
   • $L$ 设得大： 搜索时在内存里维护的候选队列更长，探索的分支更多。代价是更慢（计算距离和磁盘 I/O 次数增加），收益是更准确（Recall 更高，不容易漏掉正确答案）。
   • $L$ 设得小： 搜索时只看眼前最近的几个节点。代价是容易掉进局部最优解（准确率下降），收益是极速返回。
2. 建图时的 tradeoff：参数 $\alpha$
   $\alpha$ 是 Vamana 独创的 RobustPrune 算法中的参数，通常 $\alpha \ge 1$。它的真正使命是控制长程边（跨区域高速公路）的生成，从而从根本上决定搜索的跳数和效率。
   假设在建图时，节点 $A$ 已经连了邻居 $B$，现在算法在评估要不要保留通向远处 $C$ 的边：
   • 当 $\alpha = 1$ 时（严格剪枝）： 算法非常“近视”。只要通过 $B$ 通过多条短边一点点挪去 $C$ 的距离在数学上还能接受，它就会把 $A$ 直连 $C$ 的边剪掉。最终图里全都是局部短边。由于缺乏跨越巨大空间的长程边，搜索时需要一步步缓慢挪动，跳数急剧增加，导致搜索非常慢。
   • 当 $\alpha > 1$ 时（例如 1.2，适度放松）： 算法变得更加包容，会刻意保留一些跨越较大空间的长程边。这正是 Vamana 能用单层图匹敌 HNSW 多层图的奥秘。这些长程边充当了“高速公路”，搜索时能极快地跨越广阔的向量空间逼近目标区域，不仅让搜索变快（跳数大幅减少），还能跳出局部死胡同（提高准确率）。
   • 当 $\alpha$ 极大时（例如无穷大）： 算法完全不剪枝，直接退化成传统的 kNN Graph（每个点只连物理上绝对距离最近的几个点）。整张图彻底失去长程高速公路，且极易断连成一个个孤岛，导致全局搜索常常在中途断掉，准确率会暴跌。

α 的判断条件

在 Vamana 为某个中心节点建图时，它会按距离从近到远遍历所有的候选节点，并使用以下公式来决定是保留还是剪除（Prune）一条边：
如果在候选池中，存在一个节点 $p’$，满足以下条件：

$$\alpha \cdot d(p^*, p’) \le d(p, p’)$$

那么，系统就会剪掉中心节点 $p$ 直连 $p’$ 的边（将其从候选池中剔除）。
这里面的三个变量代表什么？

• $p$：当前正在建边的中心节点。
• $p^*$：刚才已经被 $p$ 选中的近邻节点（已经决定要连边了）。
• $p’$：还在候选池子里，等待被评估要不要和 $p$ 连边的目标节点。
• $d(x, y)$：表示两个节点之间的距离。

不妨令 alpha 为 1，这也意味着：如果目标节点 $p’$ 距离已选邻居 $p^*$ 的距离，比它距离中心节点 $p$ 的距离要小，那么 $p’$ 就不要连一根线去 $p$ 了。那么搜索的路径就是

$$
p \rightarrow p^* \rightarrow p’
$$

alpha 等于 1 或者无穷大的时候，都没有长程高速公路？

• 当 $\alpha = 1$ 时（极端吝啬）
  高速公路死于：“过度追求最短路径，把长边当成了浪费”。
  • 逻辑： 当 $\alpha = 1$ 时，剪枝机制极其严格。只要 $A$ 觉得“通过 $B$ 走到 $C$ 的距离 $\le A$ 直达 $C$ 的距离”，$A$ 就会无情地把直达 $C$ 的长边剪掉。
  • 结果： 在这种极度“抠门”的策略下，算法认为任何长跨度的边都是“冗余的、不划算的”，因为总能找到一系列小短边拼凑出一条路径。
  • 资源状态： 节点手里的 64 个连边名额（$R$）可能都没用完。但它就是不愿意建长边，最后图里全是非常精简、互不重叠的小短边（在数学上这非常接近 Delaunay 三角网格）。
• $\alpha = \infty$ 时（极端短视）
  高速公路死于：“名额被短边全部占满，根本没有余力去连远方”。
  • 逻辑： 当 $\alpha = \infty$ 时，剪枝机制彻底关闭（不再判断抄近路的问题）。算法会严格按照绝对物理距离，连接周围的点。
  • 结果： 因为距离中心节点最近的点，肯定是它身边的局部点。这些局部点会迅速消耗掉那 64 个连边名额（$R$）。
  • 资源状态： 当算法扫描到远处的节点（潜在的高速公路目标）时，发现名额已经满了。

正文

结论

这个 bug 的表象是：endless consistency 测试中，insert 负载下同一个 start_ts 对拍 TiKV 和 TiFlash，TiFlash 偶发少返回若干行，例如 tikv: [35068980], tiflash: [35068960]。再次用同一个 TSO 查询，结果会自动恢复一致，说明底层数据没有永久丢失，也不是被后续 snapshot 覆盖修好的持久化损坏。

最终根因不是 ReadIndex 没有推进 max_ts，也不是 TiKV memory lock、bypass lock、Region Split 本身。真正的问题在 DeltaMerge 的 DeltaIndex 复用：一个较早的读已经拿到了旧的 segment snapshot，但尚未完成 place index；另一个较晚的读先执行，把共享 DeltaIndex 推进到了更新的状态。这个更新后的 DeltaIndex 中如果包含“重复写入的同一批 row_id + version”，会把较早 snapshot 中仍应该可见的那批重复 tuple 标记为 deleted。较早的读继续执行时复用了这个过新的共享 DeltaIndex，于是漏读了这些行。

PR #9000 的修复就是围绕这个点：

• 在 DeltaTree 里记录 max_dup_tuple_id，place insert 时记录发生重复 tuple 的最大 tuple id
• clone DeltaIndex 时除了检查 delete range 数量不超过 snapshot，还要检查 snapshot 是否覆盖了共享 DeltaIndex 中所有 duplicated tuples
  • 如果不覆盖，就不能复用共享 DeltaIndex，必须为当前 snapshot 重新 place。

最小化后的触发序列

issue 评论中 J-H 给出的抽象复现可以概括成：

1. 线程 A 通过 resolveLocksAndReadRegionData 写入一批行 batch_1，随后获取 segment snapshot snap_a。
2. 线程 C 又写入一批和 batch_1 具有完全相同 row_id 和 version 的行 batch_2。
3. 线程 B 获取更晚的 segment snapshot snap_b。
4. 线程 B 先于线程 A 执行读流程，并更新 segment 的共享 DeltaIndex。
5. 线程 B 更新 DeltaIndex 时，因为 row_id/version 重复，batch_1 在 delta tree 中被 delete 掉。
6. 线程 A 继续使用 snap_a 读，但 clone/reuse 了线程 B 推进后的共享 DeltaIndex，导致 batch_1 对线程 A 不再可见，从而少读。

这个错误是 transient 的：后续读通常会拿到更完整、更靠后的 snapshot，delta 覆盖了重复写入的全部 tuple，DeltaIndex 和 snapshot 再次匹配，所以结果自然恢复。

现场现象和证据链

初始 issue #8845 在 2024-03-14 提交，描述是 consistency test 中 select count(*) 对拍失败，TiFlash 少 20 行。Issue 被标记为 storage critical bug。

关键现象：

• workload 基本只有 insert，没有注入错误。
• 错误窗口很短，同一个事务或同一个 TSO 后续查询会收敛到正确结果。
• 多次现场都伴随 Region Split、Remote Read、Learner Read、lock resolve 或并发读写 DeltaMerge。
• 不是所有 TiFlash 节点都错，通常是某个节点的某次 TableScan 少了固定数量的行，例如 20、50、863。
• 检查同一时间之后的 apply snapshot，排除了“后续 snapshot 覆盖坏数据导致恢复”的解释。

4 月下旬的日志把方向从事务层拉回到了 DeltaMerge：

• 同一 region、同一 applied index 下，来自 Raft Apply 线程的写入和来自 Learner Read/resolve lock 路径的写入发生并发
  这其实是一个关键线索，因为它能够极大的缩小范围。实际上如果 C-N 当时没有看到这条线索，那么会在事务层上浪费更多的时间。
  C-N 当时提到，不妨假设事务层是有问题的，那么在这种情况下，Delta Index 也有问题。
• 同一批 50 条记录被两条路径写入。第一次读的 snapshot 中 fully_indexed=false，第二次读已经 fully_indexed=true

两次 snapshot 行数差和 delta index 行数差相差正好 50，吻合“重复 tuple 被过新的 delta index delete 掉”的模型。

定位过程：难点主要在找到 DeltaIndex

这个问题在定位到 DeltaIndex 之后，修复并不复杂，真正困难和耗时的是前面的定位：现象强烈指向事务/ReadIndex/lock/Remote Read，但最终根因藏在 DeltaMerge 的读索引复用。

早期首先确认了几个事实：

• TiFlash 少的是某一次 TableScan 的行数，不是聚合或 TiDB 层统计错误。把同一查询拆到各 TiFlash 节点看 MPPTaskStatistics，发现只有某个节点某次 scan 少了 20/50 行。
• 用相同 start_ts 后续再查会恢复，说明不是数据永久丢失，也不是 PageStorage/DeltaMerge 持久化写坏。
• 错误现场经常伴随 Region Split 后 epoch mismatch 触发 Remote Read，因此最早怀疑 remote read 的 key range、region split 处理、apply snapshot 覆盖等路径。
• 检查错误时间点之后的 apply snapshot，发现没有发生能解释“恢复正确”的 snapshot 覆盖行为，于是排除了 apply snapshot 覆盖坏数据。
  这个判断是很重要的，因为在检查 raft 路径导致的不一致问题的时候，需要首先区分是否是 apply snapshot 导致的。对应的后续调查方案是不一样的。

接着排查转向事务可见性。C-N 在 issue 第一条评论里提出过一个很合理的怀疑：

• #3971 引入了同 region 的历史 ReadIndex 结果复用
• 如果两个事务互不可见，start_ts 和 commit record 在 Raft log 中的顺序不一定一致，那么较小 TSO 复用较大 TSO 的 read index 可能读不到后面的 commit record
  这个假设解释力很强，因为现象正好是“TiFlash 少读已提交数据”。
• 但后续 J-H 指出，Async Commit 的 max_ts 推进理论上应该防止这个问题，所以它不能直接作为根因。

之后又集中排查了 max_ts、memory lock 和 bypass lock：

• TiFlash 的 read index 路径一度被怀疑没有真正通过 TiKV 的 ReadIndexObserver 推进 max_ts，因为旧的 read_index RPC 已经不再使用，而 TiFlash 看起来发送的是 RaftCmdRequest{cmd_type=ReadIndex}。
  后来通过继续跟 TiFlash proxy 到 TiKV leader 的交互确认，TiFlash 虽然内部使用 RaftCmdRequest，但真正和 TiKV 交互仍走 MsgReadIndex raft message，路径是合理的。
• 使用 TiKV 侧临时日志确认：TiFlash Proxy 发出的 MsgReadIndex 带上了目标 start_ts；TiKV 收到后确实打印了 advance max_ts to ...，也返回了对应 read index。这排除了“完全没有推进 max_ts”的简单解释。
• memory lock 也被排除
  因为：多个复现场景中错误附近没有足够的 memlock 事件；有些焦点 region 的 bypass_locks 为空；TiFlash 遇到 lock 后触发 Remote Read、resolve lock、重试的行为在日志上能解释，但不能解释最终少行。
• bypass lock 也被排除
  因为：相关日志显示读事务并没有依赖异常的 bypass lock 路径，且 lock 的 min_commit_ts/commit_ts 关系不能完整解释“同一 TSO 后续恢复”的现象。

这个阶段最迷惑的是“矛盾日志”：

1. TiKV 已经 advance max_ts 并返回 read index，例如 region 459 返回到 313679。
2. 但 TiFlash 随后在 apply 313680 时仍看到 commit_ts < read_tso 的记录。

这看起来像 follower read 与 Async Commit 的线性一致性问题。后续还去咨询 TiKV 侧，分析 async commit、read through lock、min_commit_ts 推进规则。这个方向耗时很大，因为它确实和一致性语义相关，而且日志表面上支持。

后续这个问题进入了僵局。最终 C-N 发现了下面的问题：

转⽽考虑，⽆论是否承认 max_ts 有问题，⾄少确认已经 apply 到了 79 这个 raftlog，那么：

1. 要么能看到 lock
2. 要么能看到 commit
   不应该出现既没有看到 lock ⼜没有看到 commit 的情况。因此准备转⽽调查 resolvelock 和 raft command 两个地⽅的⾏转列的过程。

这是整个问题解决的关键，因为它揭示了在经过了那一团浆糊一样的事务问题之后，无论这时候的数据是否已经有问题，那么后续的处理也是有问题的。

C-N 把两次读同一个 segment 的信息做了对比：

• 第一次读拿到的 snapshot：fully_indexed=false，snapshot 中的 stable/persisted/mem rows 总数较少。
• 第二次读拿到的 snapshot：fully_indexed=true，snapshot 行数更多，DeltaIndex 也更靠后。
• 两次 snapshot 行数差是 4860，两次 delta index placed rows 差是 4810，差值正好 50。
• 同时 Learner Read 线程和 Raft Apply 线程对同一 region、同一 applied index 写入了同一批 50 条记录，版本和 handles 完全吻合。

这组证据把问题从“为什么读不到已经 commit 的 MVCC 数据”改写成“为什么旧 snapshot 会使用包含额外重复 tuple 删除信息的过新 DeltaIndex”。随后 JHL 在 PR #9000 中抽象出单测：

• 线程 A 先拿旧 snapshot，线程 B 先读并推进 shared delta index
• 然后线程 A 复用这个 shared delta index 时少读。

PR 评论里最小测试曾复现 count1 = 118, count2 = 128，这直接证明了问题在 DeltaIndex 和 snapshot 的匹配关系，而不是事务层。

为什么这么难查

1. 症状像事务一致性问题，但根因在存储读索引复用。TiFlash 少读的行对应的 commit_ts 小于读 TSO，且现场经常出现 ReadIndex、Async Commit、memory lock、bypass lock、Remote Read、Region Split，因此很自然会先怀疑 max_ts 推进、lock resolve 或 ReadIndex 复用。
2. 问题会自动恢复，容易误导排查。相同 TSO 之后再查是正确的，说明数据既没有永久丢也没有损坏；这排除了很多常规方向，但也让现场窗口很短，必须在错误发生时保留 segment snapshot、DeltaIndex、KVStore、日志和 region 信息。
3. 复现条件苛刻。它需要高并发读、Remote Read/resolve lock 触发的写入、Raft Apply 写入、相同 row_id/version 的重复 tuple、旧 snapshot 和新共享 DeltaIndex 交错复用。早期本地集群和 IDC 集群很难稳定复现，后来通过调小 region 大小、提高 split 频率、打开 failpoint 增加 remote read 才提高概率。
4. 中间出现了多个合理但非最终的假设。PR #3971 引入的 batch/async read-index 复用逻辑一度被怀疑；#8873 增强了 ReadIndexWorker 日志；#8874 增加写入 version 和 segment snapshot rows 日志；#8928 用来检查 async task 测试/日志路径。这些帮助排除方向，但不是最终修复。
5. TiKV/TiFlash 日志存在时钟漂移和跨组件链路。文档里曾用 TiKV 加日志确认 TiFlash Proxy 确实发了 MsgReadIndex，TiKV 也 advance max_ts 并返回 read index；但 TiFlash 随后仍看到看似 commit_ts < read_tso 的写入。这让问题一度看起来像 Async Commit 与 follower read 的线性一致性问题。后续才确认这不是最终矛盾，而是并发写入和 DeltaIndex 复用造成的读视图错配。

从 TiFlash 架构看，为什么一致性问题更难查

TiFlash 的 HTAP 架构选择是“TiKV 行存主副本 + TiFlash 列存 learner 副本”。官方文档中也说明，TiFlash columnar replica 是通过 Raft Learner 异步复制得到的：TiFlash Overview；VLDB 论文 TiDB: A Raft-based HTAP Database 也描述了 TiFlash learner 接收 Raft log，并把 row-format tuple 转成 columnar representation。这个架构带来了很好的 HTAP 隔离和列存性能，但一致性排查天然更复杂。

1. TiFlash 不是事务提交路径上的 voting replica，而是 learner columnar replica。写入先在 TiKV/Raft 事务语义中成立，然后 TiFlash 通过 Raft log apply、row-to-column decode、DeltaMerge 写入、segment snapshot、DeltaIndex 等步骤把数据转成可分析查询的列存视图。因此一个读结果不一致，可能发生在事务层、Raft learner apply、proxy 交互、行转列、DeltaMerge 存储视图、查询执行任意一层。相比单一存储引擎，怀疑面更宽。
2. TiFlash 的“读到某个 TSO”不是简单读一个本地 MVCC store。它需要 ReadIndex 保证 learner 至少 apply 到足够新的 Raft index，还要处理 Async Commit lock、max_ts/min_commit_ts、read through lock、bypass lock、resolve lock、Remote Read 重试。也就是说，读可见性由 TiKV 事务协议、Raft read index、TiFlash learner 状态和本地 DeltaMerge snapshot 共同决定。任何一层日志单独看都可能“合理”，但组合起来才暴露矛盾。
3. Region Split 和 Remote Read 会把一个逻辑 table scan 拆成跨 region、跨 TiFlash 节点、跨 epoch 的多个子读。Issue #8845 的现场多次出现 split 后 epoch mismatch，随后触发 Remote Read；Remote Read 又可能在另一个 TiFlash 节点上以 Coprocessor 请求形式读同一个 region。这样一来，同一个 SQL 的错误可能只出现在某个 region 的某个 remote cop task 上，而其他 TiFlash 节点和后续查询都正确。定位时必须把 SQL、MPP task、region epoch、remote target、read index、segment 读任务全部串起来。
4. TiFlash 本地列存不是 Raft KV 的直接镜像，而是 DeltaMerge 的多层读视图。一次读会拿 segment snapshot，再决定是否复用 shared DeltaIndex、是否需要 ensurePlace、是否 fully_indexed。这类内部优化通常不改变持久化数据，只影响某个瞬间的读视图，所以 bug 表现为“瞬时少读，后续恢复”。这种问题不会像数据损坏那样留下稳定现场，也不会像事务协议错误那样一定能从 TiKV 日志直接解释。
5. TiFlash 为了性能引入了多处跨请求复用：ReadIndex 结果复用、shared DeltaIndex 复用、batch read index、remote read 重试、snapshot 复用/推进。这些优化单独看都有正确性条件，但一致性 bug 往往出现在“两个正确优化的边界交错”上。#8845 就是旧 snapshot 和过新的 shared DeltaIndex 在 duplicated tuple 场景下组合出了错误读视图。

和其他 HTAP 实现相比，这个复杂度有 TiFlash 架构自身的特点：

• SingleStore 官方文档强调它可以在一个系统中结合 rowstore 和 columnstore，并在单个查询里合并实时和历史数据：High-Performance for OLTP and OLAP Workloads。它也有分布式和存储格式复杂性，但通常不是“TiKV 行存主副本 + TiFlash Raft learner 列存副本”这种跨进程、跨引擎复制后的读视图问题。
• CockroachDB 更偏向单一分布式 KV/MVCC 存储层，上层有向量化/列式执行来加速分析型查询：Architecture Overview。这类架构的难点更多集中在事务、租约、range、closed timestamp 等同一存储系统内的一致性，而不是额外列存 learner 副本与行存主副本之间的视图对齐。
• OceanBase 官方 HTAP 介绍强调在同一个分布式数据库内直接承载交易和分析：OceanBase HTAP introduction。它同样有分布式事务和分析执行复杂性，但 TiFlash 这种“主行存 + 异步列存副本 + Raft learner + 行转列 DeltaMerge”的链路，给排查额外引入了副本同步点和列存视图构建点。

所以 TiFlash 的一致性问题难查，并不是因为某个模块特别脆弱，而是因为它把事务系统、Raft 复制、异步列存副本、MPP/Remote Read、DeltaMerge 本地读优化组合在一起。问题的真实根因可能在任意一层，但表象往往会穿过多层后才被 SQL 对拍发现。#8845 正是这种架构复杂性的典型案例：外观看起来像事务/ReadIndex 问题，实际是列存读视图中 shared DeltaIndex 和 snapshot 的代际错配。

关联 PR 和作用

• #9000：最终修复。核心是阻止旧 snapshot 复用包含其未覆盖 duplicated tuples 的过新共享 DeltaIndex，并补充单测 DupHandleVersionAndDeltaIndexAdvancedThanSnapshot、ReadWithMoreAdvacedDeltaIndex2 等。
• #8873：排查期间改进 ReadIndexWorker 代码和日志，记录 read index 复用等信息。
• #8874：增加可选的 record version 日志和 segment snapshot rows 日志，用于确认写入版本、行数和 snapshot 关系。
• #8928：排查 remote read / async task 相关现象时用于检查测试路径，不是根因修复。
• #3971：历史上引入高并发下按 start-ts batch/reuse read-index 的机制，一度被怀疑会导致旧 TSO 复用过小 read index；最终由 max_ts 逻辑和后续证据排除为主因。

如果用 AI 辅助调查，能加速哪里

这类问题里，AI 最有价值的地方不是直接猜根因。早期现象确实很像 ReadIndex、Async Commit、lock 或 Remote Read 问题，AI 如果只根据表象下结论，也很可能走同样的弯路。真正能加速的是把大量日志、代码路径、假设和反证组织起来，让调查更快收敛到“哪个假设还站得住”。

1. 日志归并和时间线重建
   这个 bug 的证据分散在 endless 报错、TiFlash MPPTask、LearnerReadWorker、RemoteRequest、DeltaMergeStore、Segment、Proxy、TiKV raftstore 日志里。
   AI 可以围绕同一个 start_ts、region_id、applied_index、row_id/version 自动抽取事件，重建“split -> remote read -> read index -> resolve lock -> raft apply -> segment read”的时间线。
2. 维护假设和排除矩阵
   排查过程中出现过 remote read key range、Region Split、apply snapshot、ReadIndex 复用、max_ts 未推进、memory lock、bypass lock、DeltaIndex 等多个假设。
   AI 的作用是能够快速地去探明一个可能的原因是否是真的 root cause，从而去简化上下文。这是因为随着查询链条的深入，也引入了多个分叉，链条之间的因果就不是那么牢靠。从一个角度能解释的通，但是从另一个角度可能这个原因就解释不通。
   更重要的是，它可以提醒“fully_indexed=false + 后续 shared delta index 被推进”本身就是存储读视图风险点，避免在事务层钻牛角尖，从而更早转回 DeltaMerge。
3. 生成更精准的 instrumentation
   排查中实际合入了 #8873 和 #8874 来增强日志。AI 可以基于当前假设建议更有针对性的打点，这能减少“先广泛加日志再人工筛”的迭代成本。
4. 从现场日志反推出确定性单测
   最终 #9000 的测试本质上是把线上交错压缩成一个可控序列：线程 A 先拿旧 snapshot，线程 B 先读并推进 shared delta index，然后线程 A 再用旧 snapshot 读。AI 很适合根据日志里的 happens-before 关系生成这种 test skeleton，帮助把偶发线上问题变成稳定单测。
5. 跨组件语义校验
   ReadIndexObserver、MsgReadIndex、RaftCmdRequest、Async Commit、max_ts、min_commit_ts、read through lock、bypass lock 这些概念很容易混在一起。AI 可以把设计文档、代码和日志放在一起核对：当前路径到底是否推进了 max_ts，哪个 message 类型生效，bypass_locks=[] 能排除什么，commit_ts < read_ts 的日志是否一定表示事务层错误。这个能力能帮助更快识别“看似矛盾但其实不是根因”的证据。
   这能够减少查问题的时候，因为涉及到不同组件，不同人之间的协调产生的损耗。

这是一篇简单直接的文章（或者被认为是提纲），目的是提出价值判断、提出关键问题。我刻意避免引用例子，或者论述逻辑来佐证观点，也刻意避免提出解决方案，因为我认为这一部分工作已经被 AI 所取代。

本文主旨在于探讨在 AI 时代，一个工程师还能够输出什么样的价值。
《空中浩劫(ACI)》系列是理解工程思想很好的学习案例，而计算机系统和航空产业又有很多的共同点。下面几点尤其值得关注：
1.所有的黑天鹅都是灰犀牛
2.本质上都不相信人和机器，对环境保持最低限度的假设
3.计算机（AI、自动驾驶）的参与度都很高

管控风险

瑞士奶酪模型（Swiss Cheese Model）：在复杂的工程系统中，灾难极少源于单一故障，而是多层防御体系中的隐患恰好‘对齐’所致。

从单个模块的视角观察，一些缺陷的影响并不显著，但是在系统中则会成为致命风险中的一环。在实践中，这样的缺陷可能还会被放大，呈现“蝴蝶效应”。一个超出 SOP 的行为可能产生远超自己预期的结果。
这个模型没有强调的一点是，在计算机或者民航这样的高强度运行的系统中，一切有可能发生的问题最终一定会发生。因此，管控风险不能功利主义地乘上概率，而是真的要把那微小的 corner case 当做正常情况来处理。
我认为一个系统的复杂度和风险无论经过怎么样的封装或者 trade off，都是不能最终被消除的。既然风险是正常情况，管控和确认风险将始终是每个工程师的任务。

和机器相处

人机接管边界

控制权在人与机器之间切换的那个“边界时刻”，往往最容易引发问题。此类问题的特征是机器或者人类都可以独立完成任务，但是当两者合作时就产生了交接过程中的掉棒，或者合作过程中的冲突。
这种问题本质上是在几万年的进化中，人和人之间已经形成了诸多共识；在机器设计的过程中，各个模块间指定了 protocol，并通过测试来保证正确性。但是人和机器的交互之间并没有形成相互的理解，也没有信任。

从写认知到读认知

读优化和写优化是数据库系统中常常要思考的问题，对于人脑也是如此。从我的观察来看，人脑是一个写优化的系统：布道远比学习要容易，输出自己永远比理解他人要容易。

统计学与偏见

人类的大脑是一台出色的“模式识别机”，但绝对不是一台合格的“统计计算机”。 —— 丹尼尔·卡尼曼

在我的文章《概率论中的几个有趣问题》 中论述了一些“反直觉”的统计问题。
但更本质的是，无论是“厌恶”还是“偏见”，人类更愿意基于经验去得到一个非 0 即 1、非黑即白的结论，这是厌恶非确定的本能。关于这个问题我在 《形式谬误和非形式谬误》 一文中也进行了详细的论述。
我认为 AI 的出现会加剧这样的问题，因为 AI 迎合了人类这样的性格弱点。

从提出问题到构建价值

Code is cheap, show me the talk.

在 AI 年代，这句话指出了提出问题比解决问题更加困难也更加有价值这个事实。因此本文的写作中，根本也没有提出解决方案，毕竟有太多关于它们的讨论了。

但随着 AI 将能力边界扩展到了“主动式智能”领域，它们是有能力提出一个好问题，从而推动进化和进步的。所以问题留给了人类，当 AI 澎湃的生产力剥夺了人的利他性，那么人类的最终价值是什么？

我想这个答案应该很简单，当人的所有属性都被剥夺之后，人的价值就不再依赖任何的属性和定位，人的价值就在于他是人。我希望 AI 能够引导一个伟大的社会变革，但留给人类最应该做的是为 AI 的发展方向提供一个优化目标，也就是构建价值。

比失败更糟糕的是“局部成功”

最后想再多说一句，现在是一个人人 demo 的年代，”Done” 的门槛已经越来越低，Done is no longer better than perfect。
那么什么是真正的门槛呢？我想 BERT 本身就是一个很好的反例，它的失败恰恰可以归功于它的成功。也许我们每次在设计的时候，真的需要多问自己一句，这个架构是不是真的就止步于此了？

D0

我的行程在 https://github.com/CalvinNeo/CalvinSchedule 中。

D1 初一

因为我对象年三十值班，所以我们是定了初一下午的飞机飞呼和浩特。为什么去呼和浩特是因为去长春的飞机票买晚了，所以在选择从大连出发玩东北，还是从呼和浩特出发玩呼和浩特和大同之间的权衡。

事实证明，呼和浩特是一个挺好的地方，首先它去大同比太原还要方便，其次，它的机场到高铁站很方便，所以我们直接定一个高铁站旁边的酒店就非常舒服了。不过据说呼和浩特的新机场要启用了，因此后面它就没太原爽了。

因为我们值机比较靠前，所以下飞机是比较快的，然后就直往地铁站跑，赶上了倒数第二班地铁。事实证明坐地铁还是对的，因为后面我们点了个鼎鼎眼镜烧烤，发现等了好久都没有骑手接单，最后还是加钱人家才送的。

D2 初二

今天起来还是很感冒，还是流鼻涕。

早上 8 点，我们的小团才接我。这也是因为我们住在呼市最东边的缘故，所以不用起那么早。车上除了我全是女的，所以我就坐在副驾驶了。这个副驾驶的头枕非常靠后，所以我睡起来很不方便。

第一站是辉腾草原上面的马场。这个马场除了骑马和卡丁车（实际上没人玩）啥都没有，所以尽管我们没有定骑马的套餐，所以逼到最后还是只能骑马。那边报价 140，而淘宝只要加 120，所以我们用淘宝价还价骑了马，然后又加了 120 骑了快马。
大概流程就是先上一匹小马，然后几匹马一起被牵着走到跑马场。到那边老板就问要不要骑快马，如果骑，就换到大马身上。然后老板就会同时拉着你的缰绳和自己的缰绳把马跑起来，嘴上还嘚嘚嘚嘚的。一开始马是小跑，这个时候你得用腿用力夹住马的肚子。不过后面马就会撒开来快跑了，这个时候，就是颠屁股了，感觉整个人都要散架，必须要拉着马鞍才会稳一点，然后就跑完了。

总的来讲感觉价格偏贵。体验上的话，快马还是可以的，不过时间也很短。当然，再长一点，我呛风也受不了了。然后这地方的旱厕也是堪称一绝，里面的屎冻成了棍子，我也是第一次见。导游说你就路边上尿吧，我寻思这么大的风，不吹到身上么。

然后就是去吃饭，开车到了右翼中旗县城里面，就开了那么几家店。我们选了一家，我对象点了个羊杂，点了个驼饼。我吃了下，感觉羊杂还挺香的，驼饼感觉就是普通的肉饼吧，然后查了下，说是骆驼肉。

吃完饭，就去火山了，这个也是要开一大段路的。那一块其实有很多火山，有的火山形状像草帽山，我把它叫土帽山。不过我们实际去逛的那个叫南炼丹炉，是一个平顶的火山。相比我们在冰岛看到的，这个火山确实有点火山的感觉。

从火山回来，就是长达三个小时的回程了。我们让司机帮我们送到宽巷子，这样就可以直接吃东西了。下车就能看到杨老大焙子店，结果没开门。旁边的星月排满了队，所以我们就去清和园了。这边买芝士奶饼好多都是几十个买的，我们只买了两个感觉很亏。然后我们就去珠萨拉买了几个酸奶糕，是冰着的，感觉挺好吃。

吃完就准备打车去泽成冰煮羊了，这个店在附近有两家。我决定去万象城那一家，因为那边等的时候至少可以逛一逛。事实上感觉也是对的，因为那天晚上我感冒贼难受，加上又很干，嗓子不舒服。排队也是一百多号，特别渴，所以想买个奶或者沙棘汁喝喝，找到一个牧野晨曦奶茶店，说是要等一个多小时，立马吓退。

反正最后总算是进去了，这个冰煮羊必须要至少点一斤的羊肉或者羊排。

D3 初三

今天需要早起去大同。因为我们在火车站旁边住，所以提前一个小时起床绰绰有余了。内蒙古的火车会说什么内蒙古好羊肉，内蒙古羊肉好，非常洗脑。反正一路上也是比较困，睡睡醒醒的。
从一路上看，内蒙古和山西确实不太一样，首先，内蒙古真的有很多风车。然后，内蒙古感觉是草原的感觉，是有黄草的，但山西的话会更有黄土高原的感觉。

下了大同站，想要拉屎。我对象不在车上拉，结果下了车就要排队。其实始发站的火车，我一般是喜欢在火车上拉屎的，因为一般都很干净。拉完屎还有五分钟，就跑到直通车那里，准备去云冈石窟。上了车，开个大概有一个多小时才到，真的是非常非常堵了。

云冈石窟人非常多，主要体现在：首先，它景区检票口开了好几个，但居然都要排队。其次，是它的讲解也要排队，我们想想还是旅途随身听算了。反正进去之后，就绕了一圈，看了一下它的一个寺庙的前中后殿，然后过了桥，就是石窟的主体。

因为我之前在车上已经预习过了，所以我大概知道这些石窟大概分为几个系列，然后哪些是比较精华的。反正一开始进去的第一窟和第二窟都是比较惨烈的，因为它们的开口很小，所以基本人只能站在石阶上往里面伸着头看，我似乎就看到几个石柱子，感觉没啥意思。

第五窟和第六窟是一起的，实际上我们排最长的也是第六窟，因为第五窟当时已经维修了。保安说要排一个多小时，但实际排了四十几分钟就进去了。这个窟实际上是有前窟和后窟的，云冈石窟大部分也都是这个式样。并且相比于莫高窟或者龙门石窟，云冈石窟的颜色没怎么掉，所以看起来更鲜艳，据说这个可能是因为之前有人补过颜色吧。

在排第 6 窟之前，还看到旁边有一个可以往上爬的地方，当时也没有注意是啥。回来的时候，我们找从上面下来的人问了下，说也是一些小石窟，所以就没有再上去了。后面到那个院史馆看了下，说上面好像是有个什么寺的遗址，我觉得也是挺神奇的。

9/10 两个窟或者是 7/8 两个窟好像是一对的，就是它们的构造都很相似。据说是什么太后要和皇帝平起平坐，所以搞了两个相同的。

11/12/13 这几个窟是连在一起的，也就是有名的音乐窟。这几个窟人不是很多，感觉是因为窟比较大，所以能够流水线进出。

14 窟看不出来是啥。15 窟是那个万佛洞，里面雕的全是佛像，看起来有点密恐。

16-20 就是著名的昙曜五窟了。

看完 20 窟，再往前走就是西部窟群，里面的东西就比较挫了。

旅途随身听上看到有个云冈石窟博物馆，加上之前听到说有什么东西被抠出来放到了博物馆里面，我就想去看看，结果这博物馆就没开。我记得之前好像也是哪个景区里面的博物馆也不开的，感觉还是比较遗憾的。

出去的路也是比较奇葩的，因为这个景区里面有一堆美术馆，但是都关门了，最离谱的是还有一个侏罗纪断层的展示，上面放了一堆恐龙模型，也不知道是在干嘛。

琥珀知道我们到了大同，就想跟我们面面基，一开始提议是去古城看灯展。所以我们从云冈石窟出来，就买了直通车的票，准备回古城，和琥珀约一下。这个直通车体验是真的差，首先，车里面暖气开的热的像桑拿一样。然后，路上又贼堵，关键是这车非要沿着堵麻了的平城街开到和阳门那里下客。我能理解上客得在那，但是既然那么堵，为什么不能在古城北门先让我们下一下呢？本来我们是准备坐这个车先到宾馆放一下东西再进古城的，但是这一下子开了快两个小时，感觉再回去就来不及排队吃饭了，所以我们就在古城下车了。一进古城就发现东门排着队，我们觉着应该是上城墙准备去看花灯的，所以也果断不去看灯展了。

琥珀显然对大同的人流没有预期，搞了半天说要吃紫泥，结果我们去古城紫泥拿了个号，发现要等 290+ 桌。不过我们倒是在古城的凯鸽也排了个号，只有 29。不过考虑到它一直不叫号，并且古城也没啥可以逛的（人特别多），所以我们就准备出去找点东西吃。经过一系列的电话咨询，我们发现紫泥在南环路的一家店还是可以取号的，所以就骑自行车过去。

骑车过去的路也是比较奇葩，主要是出了古城城门需要往右拐，结果交警让我们走上面走，结果骑着骑着就骑到了永泰门广场上了。这个广场是被拦着的，自行车没法进，我们也下不去。结果我们只能闯过一片烂泥地强行进去，然后又在前面的栅栏的地方，把自行车搬了出去。骑到紫泥那里，它家在三楼，但是只有直梯上去，感觉挺麻烦的。上去之后果然全是人，反正是取了个号，然后打算先去找点东西垫垫肚子。先骑车去旁边的和笙财，点了个沙棘冰淇淋，这个冰淇淋是真好吃。然后发现旁边就是老柴削面的总店，但是我对象还是想吃喜晋道，所以就骑车去旁边的喜晋道，中途路过大同一中，感觉这个学校真的是富丽堂皇啊。进去喜晋道，他家是一个非常大的门面，装修非常漂亮，但是一进去，就说没位置了，并且都不发号了。于是就灰溜溜排老柴削面。再过去，就发现老柴削面外面都全是人了。因为反正没事做，就进去点了个最基础的猪肉面，后面就是漫长的等待。我对象要找个座位，我是受不了，因为里面又热又闷又吵又挤，感觉就像是浴室里面一样。然后不断还有人端着碗要你让，或者叫着“臭油”把一堆泔水一样的东西拿到外面倒掉。我一直在外面等，发现有人把盘子端到旁边的黄焖鸡的店面里面吃，黄焖鸡的老板也是日了狗了。这家店外面还有叫什么老柴门口烧烤，也有人点，不过我搜了下，说这烧烤贼一般，就算了。

等老柴削面的过程也是很累，我们应该是 834 号，点完单的时候刚叫到 78x 号。然后一堆人就在那个打面的地方排着听叫号。这里面坑的是一个号可能点很多碗面，比如一个东北大哥一个号点了七八碗面还有一堆小菜，前后端了大概有五六次。相比之下，我们这一碗面就显得很亏。反正最后还是等到了面，吃起来，感觉挺一般的，有点类似于之前在太原全季早餐吃的刀削面。也许有那么一点更劲道，或者汤底更香吧，但可能是纯感觉，唯一可以确定的是这汤底是确实齁咸。

吃完了老柴削面，紫泥差不多也快到了，于是就走路过去。上去之后，发现大厅等得全是人，然后还有人源源不断上来，然后服务员说还要再等两个多小时。我们好像是 179 号，反正就是硬等了。有一个大哥盯着监控，看哪一桌走了，就说我就是下一个号，你给我就安排那里吧，感觉是饿坏了。很快到我们了，然后我们前面的号问我们要不要，自己当时排了两个号，我说我就是下一桌了。

D4 初四

今天继续是早起的一天，我们需要去恒山景区。从酒店到南站有一定距离，还是扫了个车骑了过去。然后，发现百度导航真的是糟糕，直通车明明是车站的另一端，它给标错了。总之赶到了直通车那，说恒山的车堵在高架上，可能要晚点。然后我就去上了个厕所，果然是上厕所定律了，上到一半，车就来了，结果我赶快跑了回去。在车上迷迷糊糊睡到恒山，到了那个游客中心附近又开始堵车了。总之到了下面，就要坐摆渡车，我也看到了之前在小红书上看到的排队标志，所幸今天的人没有昨天多，不过悬空寺方向还是挺长的，所以我们决定先去爬恒山了。

去恒山的车会经过悬空寺，在经过一个隧道之前，能看到悬空寺，并且这是一个很好的从上往下看的机位，建议不要错过，因为返程的时候，需要倒着头向后来看，不是很方便。

到了恒山脚下，我决定还是坐摆渡车上山，爬上去，然后索道下来。中间我对象买了个帽子，然后就又去排上山的队。今天可能景区被骂优化过了，所以我们在排摆渡车之前就检票了，没有等很久。一辆车走了之后，等了一会，然后突然开过来五辆车，都并排停了。我们上了第一辆车的最后一排，我对象不太乐意，因为她有点晕车。

上了摆渡车，很快就到真武庙了，从这里就往上爬。我带了个 insta360 的相机，可以看到，全程都很简单，我觉得都没有南京紫金山难爬。中间有个庙，爬上去的石阶比较陡，感觉应该是最困难的部分了，但其实也就那样。然后从庙出来，就是冲顶阶段了，过了一个叫氵麦极门的地方之后，就看到小红书上堵人的地方，我们不出意料也开始堵了。感觉就是从这里开始，台阶变得高了点，所以有的人就要歇歇了，加上石阶又变窄了，所以交通就阻塞了，好在这一段不是很长，很快就到了一个亭子那。那是一个三岔路，往左是索道下山方向，往右是登顶方向。我们登顶，好在那里石阶就宽很多了，基本都可以跑起来，所以跑了大概十几分钟，我也登顶了。总共算上等的时间是六十几分钟吧。总的来说，恒山其实没啥意思，主打一个五岳打卡。然后确实很多人都在峰顶的那个地理标识那边排队拍照，说那边一个人只有 20s 的拍照时间。

下到缆车的地方，看到人也不是很多，就打算坐缆车，结果下来之后发现别有洞天，还是排了不少的。不过其实是可以忍受的，实际上也就等了不到二十分钟。中间前面的京爷因为不知道什么事情吵起来了，然后又打起来了，然后又吵起来了，反正我们就翻栏杆排到了他们前面，感觉也是个乐子。下山就直奔摆渡车站，去古城的在排队，但是去悬空寺的不需要排队，我们就直接上了。

很快就到了悬空寺，看到很多人在往里面走，好像是自驾过来的，所以我其实有点想看完悬空寺就直接打车回去浑源古城看永安禅寺，省得坐他那个摆渡车兜圈子了。anyway，我们往里面走，是茫茫多的人，然后进去也要走一段路。反正到了悬空寺下面，感觉其实进不进去看也一个样子了，不过来都来了，就进去看一下。里面就是一个小广场，给你拍拍照，然后有一个地方是登临的入口，感觉排了一堆人，我们估算了一下，感觉肯定不止景区宣传的 3260 人每天的量。然后这波人是一波一波往里面放的，所以大家都只能慢慢等，我挺庆幸自己没找黄牛买票，感觉过来排队也还是受罪。过了一个桥，可以更近看悬空寺，不过其实没啥区别，主要这寺确实很小。我对象说梁思成其实也不怎么 care 这个寺，我也不知道为啥。

出了门，问了保安，说这边社会车辆进不来，他也不知道哪里能打车。我打开滴滴，发现自己站的地方就能打车，所以滴滴肯定是在扯淡。既然打不了车直接去浑源古城，我们只能坐大巴先去游客中心了。快到游客中心我们就远远看到了电瓶车，等下了车，我们就扫了个更近的电瓶车，往浑源古城那边骑。这电瓶车还挺贵的，骑了几公里，扣了我四块钱。

到了浑源古城，先去永安禅寺逛了下，这个也是辽金时候的建筑，也是出现在浪浪山这个电影里面的。主要看的是它主殿的壁画，正面是画的各个法王，最有名的就是不动明王，他是一个白净的，撕开脸的造型，和其他的法王区别很大，所以他在文创上的露脸也很多。另外一个法王的眼睛很奇特，从左边看是紫色的，从右边看事棕色的，说是因为它眼睛是用贝壳做的，所以有不同的反光。然后左右两边的说是明清的时候画的，其中右边的好像是道教的一些人物，不太看得懂，左边的听了一圈解说，说是佛教里面的六道轮回。我们蹭了好几个解说，所以大概都听了个明白，其中有个解说甚至把谁是东海龙王，谁是地藏王都指出来了。讲解还贴心的照了一下壁画，给我们看这个壁画实际上是有厚度的。

从永安禅寺出来，就去吃了下小媳妇凉粉。浑源这边遍地都是小媳妇凉粉，但是我们吃的好像是真的小媳妇。点了个凉粉，还有个熏蛋。凉粉啥感觉记不得了，熏蛋还真的挺有意思的。喝了他们的沙棘汁，感觉不如昨天的紫泥的酸。

骑电瓶车回去，差不多要赶六点的直通车。发现根本找不到直通车的乘车点，百度地图真的是拉胯，但是切换高德地图也找不到。反正问了一圈，终于找到了一个标志，跟着走下去。发现除了 901，还有 25 块钱和 39 块钱不一样的直通车。因为我们已经买了 39 块钱的，所以就过去检票。然后因为我们买的是 7 点的，所以还涉及到改签的问题。第一班车已经只剩下最后两个坐了，所以我们跟检票的小哥一顿交涉，跟着前面几个妹子一起去坐下一班车了。然后小哥上来先让我买一个新的票，然后他再给我把老票直接退了。然后就是等，车很快又要坐满了，中间来了两个女的，发现又只有最后一排的坐了，就想等下一班，但是司机说又已经检过票了。反正折腾了一圈，她们去打车了。然后上来了几个，又有不愿意坐最后一排的，总归折腾了很久还是发车了。

我们选择在大同南站下车，因为我们路上排了两家凯鸽都要等一段时间，我希望去宾馆洗一下屁股，顺便看看有没有其他能吃的。这个时候琥珀也要来找我，说怎么说再吃个饭按摩一下。因为太饿了，我还请宾馆帮我热了下昨天的肘子垫吧垫吧，不得不说，那肘子还是可以的。然后我就让他来宾馆，自己也顺便洗了个衣服。然后他到了，我们发现凯鸽水泉湾店快排到了，然后就赶快打车过去。到了之后，我对象进去等，我们出去逛了下，发现旁边就是他们的御河，我理解就类似于太原的汾河吧，不过没有自行车道，感觉不如太原做得好。

凯鸽的菜：

• 风沙鸡：感觉很一般，就跟我们这边普通的脆皮鸡差不多
• 糖醋里脊：很香，我理解主要还是山西那边醋确实强调香吧，然后就是也没有那么甜
• 炸油糕：我朋友说不好吃，不过我们点了个尝一下还不错
• 烧麦：皮跟纸一样，但吃起来感觉没啥意思
• 羊肉火锅：感觉一般，我对象说味道太重了，我倒是挺喜欢这味道，但是我觉得太肥了，有点我点的锅圈食汇的肥羊的感觉，不是很喜欢
• 沙棘汁：还不错，没有紫泥的酸，但是挺普适的
• 酸奶：挺好
• 烤骨头：有点里脊肉的味道，但是是肘子的感觉，挺有意思的

一边吃，一遍搜附近的按摩，感觉这边按摩都挺喜欢擦边的。我觉得心思放在擦边上的店基本上手艺挺一般的，所以我直接过滤掉了。反正最后选了一家 150 的，其实做下来感觉也挺一般的。这家店开在小区里面，我们过去的时候，也是穿过小区走过去的。中间我们又看到了山西的省灯，我觉得他们是不是会暗自较劲，看谁家的灯最花里胡哨？反正到了那家店，感觉是个坑姐妹钱的店，全是美容的设备。我们的 80 分钟果不其然是只按 60 分钟，然后做个热敷 20 分钟。然后他们急着下班，又边做边热敷了。我做的是什么泥膜，感觉非常烫。我感觉自己可能都要被烫伤了，就让他给我摘下来，一摸发现全是黏糊糊的汗。因为一直在烫伤的那种疼，所以让她拍照片发现皮肤是白的，看来确实是没有烫伤。不过这个后劲确实大，我大概缓了有一个多小时，这个烫伤的感觉才消失。所以这样看来，感觉这个泥膜还是挺舒服的。

D5 初五

今天算是比较奇妙的一天。首先，昨天晚上睡觉前跟我对象讨论了，说今天早上去应县木塔吧。然后晚一点我就想把直通车的票买了，结果一看，9.30 的票只有一张了。因为木塔下午人多，并且，从木塔回古城更顺，所以我们又只能买早上的，就很尴尬。我还不信邪，又刷了几遍，中间还错买了去恒山的，总归坐直通车是不行了。灵机一动，决定去搜下有没有其他的巴士，结果 902 好像要两个多小时，不过中途发现，应县是有高铁站的，并且高铁站也是有巴士去木塔景区的，所以我就决定买火车票了。结果 12306 晚上关门，没法买票，于是我只能定了早上的闹钟。早上起来，发现买票是需要在系统里面排队的，我等了几十秒发现还没刷出来，就又小眯了会。几分钟又醒了，发现刷了两个不挨着的座位，果断付了款，结果再一开，火车票就卖空了。

结果上了高铁，发现这趟高铁也不算特别挤啊，不知道在那里票都卖光了。不过我们一站就到了应县西站，然后门口就是蓝色巴士，五块钱就到木塔了。然后发现这个巴士似乎也接路上的村民，并且送到木塔之后，也会继续往前开的。

因为我们是高铁来的，所以应该比大部队要早，到的时候，木塔没啥人，跟之前小红书上看到的完全不一样。我们进去之后，逛了两次一层，分别是从左边和右边走的，所以对里面的雕塑和浮雕看的都比较清楚。印象里面，可以看到木塔是有梯子可以上去的，不过特别陡。然后佛像正面是有两个洞，说是之前被破坏过。

实际上我们去的时候，木塔二层上是有工作人员在跑动的，只是不知道他们在做什么。站在木塔下面，如果角度不对，其实是不太看的出来木塔已经歪了的。但是确实能看到它的暗层，也确实能看到之前被敲掉的泥墙被换成的窗户，也理解那边的本地人为什么要把泥墙砸掉，因为换成窗户确实好看。

木塔一个拍照片的角度，就是他的几个底座的角落，我们在那边拍了照片，感觉挺好。不过如果要看木塔，我觉得还是站在下面比较好，我觉得是非常漂亮的，有种雍容华贵的感觉。特别是当你看到木塔周围那些拆迁到一半的破落房子和杂物堆的时候，这个木塔就更有一种清水出芙蓉的感觉了。

准备离开木塔的时候，风突然大了起来，并且沙子也多了。身边的游客在感叹，这地方还真的是太干旱了，风沙多，结果后来才知道，这是多年没见过的沙尘暴，是从蒙古国吹过来的。总而言之，离开的时候，回望木塔已经是灰黄笼罩的一片了。

前面那条街还在表演，看了会，就往回走，结果那妖风是越来越大了。走到南门出来的哪个巷子中，推开一个铁门，然后就走到一片很很乡下的地方。前面几个人躲着不肯走，我们过去一看，好家伙，前面黄沙都飞起来了。因为我们赶时间，就硬走过去了，我对象新买的帽子不知道什么时候被刮飞掉了。我们来回找了一下直通车在那里，因为之前在刮风那里确实远远看到“景区”几个字，但是走过去发现不是景区直通车，而是景区官方什么什么的。反正最后问了人，确定了就是在净土寺的广场，和我在微信公众号上看的一样的，所以我就直接导航到净土寺，总算是赶上了。不过上去之后，又是最后一排的位置。不过幸好之后还有一堆人要上车，所以最后我们换了个更大的车，因此又做到前面了。

上车发现琥珀发的消息，说是已经登机了，结果是什么沙尘暴，说又被赶下飞机了，气的要死。难怪我们这全是沙子，我先前以为他们这每天都这样呢，心想这样也太不好过了吧。

下午的计划是去古城看华严寺和善觉寺。我们先到古城看看晋喜道的情况，当然是停止放号了，跟我们说晚上的号下午四点开始发，要我们到时候来取。然后就网上搜了下刘姥姥豆面，发现在那个全是牌坊的十字路口，于是就过去。因为中途路过北魏家宴，所以我就说我们也去取个号，我对象说包取不到的，我就不信邪，结果还真只要排一小会，所以我们就先去吃了刘姥姥豆面，顺便等北魏叫号。

BTW，从下车的那一刻起，我们就感觉到了这个沙尘暴的厉害。进入古城，发现里面人少了很多，估计是风太大都不敢出来了。古城里面的灯会据说也是取消了。走到那个牌坊路口的时候，感觉自己仿佛到了黑沙滩，这风打在脸上是真的疼。琥珀说他的飞机已经延误到三点多了，然后我说你能不能航旅纵横买一个延误险，我看这风，你们三点估计都起飞不了，他说买不了了。实际上后面看小红书，就是我们快到古城，然后下车，也就是 12 点到 1 点那阵子风沙是最大的。

回到刘姥姥面馆，这面馆也是一个要看本事 DIY 座位的地方。不过好处是它有夹层和二楼，所以我们在二楼找到了个位子。我们点了一些小菜，以及一碗面，里面有它的豆腐干，还有两条青椒。

吃完刘姥姥，看到北魏的号是刷刷刷地过，突然就只有三个了。我们赶快跑过去，我对象还摔了一下。到了的时候，只有一个号了，所以我们就可以预点菜了。

吃完北魏，就去华严寺了，这又是蹭解说的一天。一进去，感觉里面鲜花盛开，我以为是冬天快走了，开了一堆梅花，结果走近一看是假的。华严寺一个看点就是大雄宝殿，这个大雄宝殿有一对超级大的鸱吻，另一个特别的是它的入口的门造型比较奇怪，据说是借鉴了伊斯兰教的一些风格。这个大雄宝殿里面到底是啥，因为里面很挤，解说声音又很小，所以我也没啥印象了。然后是普贤阁和文殊阁，好像一个是新的，一个是旧的。我看牌匾全是颜真卿题的，但看这个样子，感觉不是什么老物件。看完大雄宝殿就准备走了，但是发现那边还有个华严塔，然后那个塔排了好长的队。一查，原来是有个纯铜打造的地宫，于是决定还是排吧。当时风还是挺大的，所以我们顶着风排了好久，我中途还要上厕所也是忍下来了。这玩意要排队是因为它要换鞋套，这就慢了。然后首先是下地宫，这个地宫还是不小的，里面有一个台子，供奉了舍利子。相比南京的大报恩寺，这个舍利子还是挺慷慨的，能够够着看到，感觉就是个比较长的米粒一样。逛完了地宫，就往上走，爬塔。据说这个塔是仅次于应县木塔的塔，因为应县木塔不让爬了，所以要爬这个塔。爬的感受就是小号的姬路城，我觉得比较好的是爬的过程中可以看到塔的暗层。暗层实际上有很多像倒金字塔一样的结构，不知道是干嘛的。塔总共有三个明层，上面没啥好看的，风景也一般。下来之后，就准备出去了，半路上看到一个薄伽教藏殿，这个殿是个比较屌的殿。里面全是佛像，佛像上全是灰，解说的意思是这个灰从佛像造完之后，就没有被清理过了。里面有一个佛像是一个露牙齿的女的，说是照着一个小女孩做的，反正我也不是很懂，反正梁思成说很屌，有个什么称号。

逛完华严寺，刚好四点多了，赶快出去抢号。结果发现晋喜道拿号居然也要排队，我们拿的是 c90，取号的小哥说也不知道要排到啥时候，反正五点钟才开始叫号。所以我们赶快去逛一下善化寺，因为善化寺在南门，所以我们要走好远。基本上就是第一天我们到大同古城走的路线了。反正到了之后，善化寺门口有一个五龙壁，说是之前什么寺拆掉了，然后移动到善化寺门口的。进去之后，当然又是蹭导游了。善化寺的一个重点是它的三圣殿，这个殿比较有名的是那个像菊花一样的斗拱，说这个斗拱即使是辽金的建筑都很少见。然后它的大雄宝殿里面也是一些塑像，有一个塑像比较有意思，是说一个小鬼被点化成为一个善良的送子娘娘，然后就把他们一起塑像了，说是很少见的。然后讲解还介绍了一下工艺，说是塑像是整体镀金的，然后需要显示金线的地方，就把颜料扣掉。另一个塑像栩栩如生，讲解说他腿部的青筋都被雕刻出来了。这个殿里面还有个碑，说是朱熹的什么亲戚的，有一个讲解还指着说第几行有什么字，然后说了什么事情，我是没搞懂。总之觉得这两个殿，旅途随身听的讲解做的比较烂，得一直蹭讲解才行。

在排队的时候，我要上厕所，结果用百度找了几个厕所，一个都没有用，还是问的别人。后面立即下了高德，发现高德是准的。上完厕所，就直接去晋喜道了，当时已经快排到我们了。我们点了个肉末的面，一个番茄面，几个小菜，鸡爪，串和沙棘汁。小菜方面，我觉得山西的醋确实香，配上大蒜末，所以那个蒜泥肘花就很好吃了。鸡爪感觉就是茶叶蛋的味道。凉拌黄花算是山西特色了，和其他店里没啥区别。肉末面和昨天吃的老柴总店也是比较类似的，不过没有那么咸，更有点汤面的感觉。番茄面比之前在全季早饭吃的稍微好点，主要它不太是那种面是面，浇头是浇头的感觉，相对来说入味点，番茄泥也弄得比较干净。

因为这两天走的屁股都肿了，所以吃完走到东门打了个车，就直接回去了。中途看到了九龙壁，隔着栅栏看挺漂亮的，结果进去还得买十块钱的票，那谁还进去看啊。等车的时候发现和阳门对面的城楼，也有一种晋祠的感觉。

D6 初六

今天在大同逛一下博物馆，就可以回呼和浩特了。早上起来退房，打车去博物馆。我们没有抢到预约，所以只能买特展的票。一开始我以为可以在门口给大爷看完就退了，结果发现这只是一个预检票，后面还有一道需要刷二维码的闸机呢。

进去之后，逛了一会一楼，上了个厕所，出来然后一个女的就问我们要不要拼团讲解，说是 100 块钱，看我们可能要急着走，就说 80 块钱算了，结果我们就定了。中间想先去看一半穆夏的特展，结果人家说只能进去一次，所以就放弃了，又下来。不过好在那讲解员拉客能力比较强，很快就齐活了，她先照着大厅里面的那个壁画讲了一遍，后面我们才知道，这个壁画并不被公开展示。然后我们就又从恐龙那边开始逛了。不过不同的讲解员的路线略有区别，所以我们这次就没有讲那个编织壶。我问了下，那个恐龙为什么那么完整，讲解员说这个叫什么天镇恐龙，当时挖出来也不是完整的，说是考古学家拼的。反正没懂我意思，因为有些恐龙是会缺几个骨头的，但是这几个恐龙是完整的。

二楼是比较精华的部分，即北魏展厅，因为大同直接是北魏的都城。其实它有两个展厅，讲解员只带我们逛了第一个。第一个中又分为两个主题，第一个主题是一个墓葬里面的发掘物，包含了漆画屏风以及它的附属，包括挂它的架子、柱子、石墩子都展示出来了。然后还有对应的墓志铭，以及一些陪葬的陶俑。第二个主题是丝绸之路，包含一些陶俑、壁画以及玻璃制品。这里的玻璃制品还是很漂亮的，是非常剔透的蓝色。

三楼是辽金和明清展厅，大同是北魏的陪都。然后，看到了一个非常大的鸱吻，说是从某个大殿上拿下来的。说鸱吻是龙和鲸鱼的后代，它长得就很像鲸鱼的尾巴。

讲解团解散之后，就去逛了下穆夏的特展。这个人是画板画的，不过眼睛画的很传神。另外，他也会画油画。看完特展，我发现二楼其实还有个展厅没看，所以就又下去看那个展厅。

D7 初七

今天早上打车去了大召寺。这个寺是藏传佛教的，我不太懂，感觉没啥意思。有一个乃琼庙，里面都是骷髅头，很吓人。

从大召寺出来，就是塞上老街，我们又去吃了泽成冰煮羊，吃完，就打车去内蒙古博物馆。这个车是真离谱，调个头就花了十几分钟，堵得要死，结果我们等了有 20min 才上车。

内蒙古博物馆是真的大，感觉建得跟人民大会堂一样，里面也很大。我们预约的早上的，结果下午去就刷不进去了，被门口的说了下，就放进去了。一楼的展厅没有时间看，就奔着二楼去了。二楼是一堆乱七八糟的展厅，影响深刻的有一个马年的特展，还有一个神舟飞船的展厅。另外，他有一个特别大的古生物的展厅，里面放了从寒武纪奥陶纪，到恐龙时代的各种化石。我怀疑这个博物馆跟云南哪里有什么合作，因为它展出了很多云南出土的文物。

我的项目是 https://github.com/CalvinNeo/OpenBoardGame。

D0

作为 Demo 实现了一个掼蛋游戏。

发现问题：

• AI 对规则理解非常不正确，例如缺少对三带二、同花顺炸弹的支持，并且也不能顺子的长度和一手牌数量的上限。
• AI 对空间感不熟悉，一些提示文字和牌重合。

# Jan28 - Jan29

在这 2 天中，我大概用了 45 刀左右的额度。完成了 Cabo、骷髅牌、你画我猜、璀璨宝石四个游戏逻辑和 Bot 的开发。并且，我还支持了断开重连、房间管理等机制。我还优化了 UI 的美观度和便捷度。

AI 会理解错一些点。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/ab26a9c00cd5d9720b39bf3e248b672881cb52ed 这个修复 commit 就展示了 AI 对璀璨宝石最大数量的多次理解问题：

1. 一开始，它根本没有实现这个限制。
2. 后面，它实现为只有超过 10 才不能拿，但是从 9 到 12 这个行为是被它允许的。
3. 最后，才修改对了。

AI 会漏掉一些情况。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/c8e82736975325f0b9300b471524ec86b005129e#diff-794e220aafafcfac193a89abd6fb142d92255d544728f217d64e7a1162c79e28 这个修复 commit 展示了 AI 对用户离开规则的遗漏：

1. 先前，AI 处理了 in game 的情况。此时如果最后一个活人玩家离开游戏，那么这个房间可以被手动清理掉。
2. 但是，它漏掉了 in lobby 的情况。此时房间并没有开始游戏，那么玩家离开房间（比如创建一个新的房间）不会导致该房间出于可以被清理的状态。

经验：

• 让 agent 缩小阅读的范围。例如可以告诉它“这是完全的前端修改，你不需要看后端代码或者其他游戏的代码”，这样它就可以更快解决问题，并且能节省不少额度。这随着项目增大是尤为有效的，因为看 thinking 是可以发现它有倾向去学习其他代码是怎么做的。
• 让 AI 先整理信息，然后再写一个 design 征求意见非常重要。因为 AI 在实现的时候还是偏向于漏点东西的，这也可能是出于对问题的不正确理解。
• 逻辑比较独立的部分，可以让 AI 整理出测试。虽然目前也没看到 AI 会主动修改代码从而 break 掉测试，但这样会更有自信。

Jan 30 - Jan 31

这几天主要实现了出包魔法师、猜狐狸、截码战三个游戏。

Feb 1 - Feb 3

这几天主要实现了角斗士棋、Store&Load、印象花语、AI 画物语四个游戏。主要是由 Gemini 生成游戏说明书，再由 Codex 生成 design。等我 Review 了之后，再实现代码。

角斗士棋和印象花语中都涉及到了拖拽旋转对象的设计。我发现 AI 在适配手机端上的拖拽是相对比较蠢的，需要手动告诉怎么搞。

角斗士棋实现起来很简单，但是其实要打磨的很多：

• 手机版如何精准地把方块放到格子里面就很难困难。因为每个方块的焦点并不是方块的重心。后来加了上下左右移动的键，但是感觉还是很蠢。
• 还有一些奇怪的 bug。

印象花语这个游戏，我对实体版的一些物理效果进行了模拟：

• 因为印章可以印得深浅不一，所以我增加了点按时长来决定透明度的机制。并且我也增加了根据色彩学原理来模拟印章叠加的效果。
• 因为可以倾斜印章，使得只盖一半。所以我增加了一个 Mask 机制，可以去 Clip 印章。这个就好像我在按之前垫了一张废纸，这样章可以只盖一半在画布上。

我觉得这一部分涉及到物理世界的原理的，应该只有人类能意识到并且提出来。

Store&Load 是非常有意思的点，AI 当时给我提供了一个完全不一样的解决方案。例如它执着于解决 Session 的问题，如何处理同名玩家和同名 Room。但是我提出了一个非常简单的做法，就是完全新建一个 Room，然后新玩家可以进去 Claim 老玩家的 Seat。这样做能够减少很多的复杂度。另外，我还发现新创建的房间并不支持 Auto Save 选择了，这个我觉得也是 AI 本身缺乏引申的能力。

AI 画物语的实现是跟其他桌游完全不一样的，因为要涉及生成图。所以我开了 https://github.com/CalvinNeo/aidixitgen 这个 repo。

一开始它是用的 pollinations 做的。然后我发现这个工具经常生成水母，然后问了他，他说是提示词的问题：

为什么这个代码里面的 prompt 这么喜欢生成 jellyfish？
这是一个非常经典且有趣的 AI 生成现象，通常被称为 “模式坍塌” (Mode Collapse) 或 “安全区偏差”。出现大量水母（Jellyfish）、热气球、云朵、漂浮的岛屿，原因主要有三点：
关键词的“刻板印象”： 你的代码里用了 surreal（超现实）、dreamlike（梦幻）、whimsical（异想天开）这些词。 在 AI 的训练数据（Latent Space）里，水母是“梦幻”和“超现实”的超级代表物。它们透明、发光、漂浮，长得就像外星生物，完美符合 AI 对“梦境”的理解。只要你还要“唯美”和“超现实”，AI 就会懒惰地选择水母。
Prompt 缺乏约束： 我们在请求 AI 写创意时，给的指令太宽泛了（”Generate ONE single short… description”）。当指令太宽泛时，AI 会倾向于输出它认为“最稳妥、最符合题意”的高概率词汇。对于 Dixit 风格，水母就是那个“最稳妥”的答案。
风格修饰词的引导： 我们在画图时强制加了 soft colors（柔和色彩）和 floating（虽然没写但 dreamlike 隐含了漂浮感）。这也极大地增加了生成海洋生物或云端生物的概率。

然后，我又发现它生成的东西太容易重复了，例如几乎生成了两个只是风格不同的钟。所以我后面又设计了双主体的方案，结果最后生成的结果是比较理想的了。

后来发现 pollinations 一直 502 了，所以就换 hugglingface 了。

Feb 4 - Feb 6

这几天主要实现了前端美化、Flip 7、德国心脏病、绝妙误解。

主要是由 Gemini 生成游戏说明书以及设计。然后由 Codex 去实现。但是我要求 Codex 在实现前先问我不清楚的项目，而不是自己随便实现一版。事实发现，让 Codex 去问一下自己不知道的，而不代替我做决定，是很重要的。

AI 前端的主要问题：

• UI 直白
  例如用一个列表表示玩家信息。用一个表格表示当前状态。这对玩家而言体感不好，感觉是在上班。
• 没有交互设计
  特别是手机端玩家，操作的时候需要翻来翻去。
• UI 可能存在 Bug
  例如在手机端会发现 Flip 7 的 Game 面板会非常少。

德国心脏病的开发是非常典型的。主要包含几点：

• 得到的开发计划是经典版的 Halli Galli，也就是牌上的水果一定是相同的。这个跟我们玩的不一样，所以后面让它开发了一个 DLC 一样的东西。
• 电脑根本没有给翻拍和按铃的等待时间，所以加上 bot 之后，基本 bot 都是秒按铃，秒翻牌，根本没法玩。即使没有 bot，我们也需要考虑人类的反应时间，以及各个网络的延迟。所以我这里要求加了等待 3s 的按铃时间，以及在点击翻拍后，有一个 1s 的倒计时，方便大家准备看新水果。
• AI 生成的界面依然是列表，这个我让 AI 改成了围成一个圆。

Feb 7 - Feb 10

主要工作是修复之前各个游戏的问题。例如：

• cabo 的规则实现错误
• flip7 的相关问题
• 继续修理绝妙误解中糟糕的前端问题
• 印章话语支持投票
• 支持日志复制
• 发现之前代码中有 valid 检查，一直是死代码，启用

实现了新游戏，包括：Gold Rush、Hanabi、Cyber Pictures、The Gang、逻辑猫。

对 FRONTEND.md 进行了修订，后续的移动端 UI 开始要好一些了。

此外，还支持了新的功能：

• Download Memories，用来下载整个游戏的回放
  实现的过程中，发现设计非常死板。例如花了大篇幅去展示什么 user id，但是游戏内容就缩在一小列里面。而且他非常喜欢表格。
• 在游戏过程中开启 Auto Save

Feb 11 - Feb 12, Feb 26-27

主要支持了我画我猜、方鸟、小早川、牛头王。快艇骰子。

方鸟这个游戏非常有趣，是 Gemini 生成了一段很有歧义的规则说明，然后 Codex 直接按照错误的方式理解了。

Feb 28 - Mar 12

这段时间开始尝试探索 AI 多模态能力的边界。主要开发的游戏有历史奇旅、卡卡颂、德州扑克、project L、璀璨宝石宝可梦。此外，还尝试了诸如 Claude code 等其他模型的能力。

其中：

• 历史奇旅主要是识别质量较高的游戏卡牌
• 卡卡颂是识别卡牌，并能拓扑地利用它们
  实际上，识别是最难的。我大部分时间用来调试 Codex 生成 72 个基础地图。Codex 经常是分不清城堡是否占边，是否占角。还分不清城堡和道路的重合关系。在生成 svg 的时候，非常喜欢用圆而不是二次曲线去拟合，导致生成的图片很僵硬。
  但是，一旦生成成功，后面包括地图连通性判断就非常简单，直接一遍过。
• project L 是阅读游戏说明书，然后生成
  这里面主要是前端显示问题。就是一个 svg 生成好好的，让它转成前端，就变成了长方形的长条而不是正方形的格子了。
• 宝可梦是识别质量较低的游戏卡牌
  可以说非常痛苦，目前来看人工校对是必要的。强烈建议对于这种任务，让 ai 首先生成一个校对工具，这样每次的错误至少是能收敛的。另外，确实是有 corner case AI 无法识别，这样就只能人工标注。
  另外，这种 case，AI 喜欢写一段识别代码，我建议提示 AI 不要用 tesserocr。另外，这种类似于“蒸馏”的方式其实挺好。

此外，还进行了一些优化：

• 将 app.js 拆分以减少 tokens 开销
• 引入 vendor 减少 cdn 故障导致的无法游戏
• 增强游戏选择界面
• 引入帮助功能

原理

解决什么问题

3FS 作为一个训推一体框架，解决的几个痛点是：

• 痛点一：AI 训练中海量数据的“随机读取”瓶颈 在模型训练时，数据加载器（Dataloader）需要不断对海量的训练样本进行全局 Shuffle（打乱重排）以防止模型过拟合。这会产生极其庞大的纯随机读取操作。在传统架构下，为了不让 GPU 等待数据，往往需要预先将数据搬运到计算节点的本地硬盘上。3FS 聚合了全局极高的并发随机读取能力，让计算节点可以直接像访问本地文件一样，在全局数据集上进行无感知的随机采样，省去了繁琐的数据预取和搬运。
• 痛点二：传统文件系统“读缓存失效”造成的内存浪费 主流的操作系统高度依赖 Page Cache（页缓存）和预读机制来加速文件读取。但在 AI 训练的随机洗牌场景下，读过的数据短时间内几乎不会再被重复读取。这意味着传统的“缓存”不仅完全无效，还会大量无谓地侵占计算节点的系统内存，甚至干扰训练任务的稳定性。3FS 针对这一点进行了彻底剥离，它主要依赖 Linux AIO 和 io_uring 直接处理 I/O 操作（Direct I/O），完全抛弃了对本地文件缓存的依赖，把宝贵的内存还给了计算任务。
  关于这一点，可以参考 Are You Sure You Want to Use MMAP in Your Database Management System？ 这个文章。我们在使用 tantivy 的时候，也发现 tantivy 的 mmap 会逃逸 tiflash 读节点的内存管理，导致频繁出现 memory over limit 的软限制，导致查询报错。
  我们开发的 tici 使用的 tantivy 会使用 mmap，并且会对每个 fragment 做 cache。mmap 无法直接控制，frag cache 目前也是必须的，所以这一块的内存管理很被动。
• 痛点三：超大规模集群的“并行 Checkpoint”风暴 万卡集群在训练千亿/万亿参数大模型时，需要高频保存模型权重状态（Checkpoint）以防硬件故障导致训练白费。这就要求系统必须在极短的时间内，将几十 TB 甚至上百 TB 的数据同时且高并发地砸进磁盘。3FS 极高的吞吐上限（官方测试可达极高的 TiB/s 级别），将写入 Checkpoint 导致的集群全量停机等待时间压缩到了极致。
  这里面的 Checkpoint 不仅是模型参数 Weights（每一层的权重），还包括优化器的状态，如 Adam 优化器的一阶矩和二阶矩，梯度和一些元数据等。主要的内容是 Adam 部分。
  假设你在训练一个 1,750 亿参数（175B）的模型，以半精度（16-bit）保存，权重约 350GB。但加上优化器状态后，一个完整的 Checkpoint 可能高达 2TB 左右。如果是一个万亿参数（MoE 架构）的模型，单个 Checkpoint 达到 10TB-20TB 并不罕见。为了容灾和实验回溯，集群通常会保留多个步数的副本，因此总占用达到百 TB 级别是非常正常的。
• 痛点四：推理阶段 KV Cache 的容量与成本限制 在处理超长上下文（Context）的 LLM 推理时，保存在昂贵 GPU 显存或系统内存（DRAM）中的 KV Cache 会迅速触及容量天花板。3FS 极低的读写延迟和超高并发，让 DeepSeek 能够实现“将 KV Cache 卸载到廉价高速磁盘（SSD）上”的技术方案。这为超长文本的推理提供了一种极具性价比的替代路径。

3FS 的方案

对此，3FS 的方案是：

1. 把显存 offload 到 SSD 上。主要还是借助 NVMe 和 RDMA 技术。
2. Global Prefix Caching：我理解这一部分主要的优化点是超级冗长的系统提示词 (System Prompt) 以及各种套娃。

另外，是 KVCache 的内存开销，其实是和上下文线性相关的

设计 – design notes

3FS 中有个 design notes，这里主要是概括了 design notes。

需要解决的问题

OSS 方面：

• 现在的 OSS 并不支持原子地移动一系列文件或者一整个目录，或者递归地删除整个目录。而 3FS 的场景（实际上数据库的场景也是这样）涉及要创建一个临时目录，然后对这个目录写入数据，最后将这个目录 move 到最终的位置。
• 3FS 需要广泛使用 symbolic 或者 hard 链接
• 提供一个熟悉的文件接口，我理解这也是 3FS 选择 FUSE 的原因

FUSE 方面：

• 在 Fuse 学习一文中介绍了为什么 FUSE 不支持 Zero Copy。但这也是 FUSE 的缺点之一。
• FUSE 使用一个由 spin lock 保护的多线程共享的队列。3FS 团队的测试显示，400K 4KiB reads per second 的写入负载之后，因为 lock contention 的方法。
• Linux 5.x 上的 fuse 不支持对一个文件的并发写。所以很多需要更大带宽的程序会并发写多个文件。
• 对小的随机非对齐读性能不好，SSD 和 RDMA 网络的带宽没有被利用充分。

但是将 client 实现为一个 VFS 内核模块则能解决上面说的问题，但也更有挑战性。内核的 bug 更难定位和修复。此外，升级的时候需要停掉所有访问这个 fs 的进程，或者重启。

因此，3FS 选择在 FUSE daemon 里面设计一套原生的 client，由它来支持异步的 Zero copy IO。其中，File meta operation 例如 open、close 等还是被 FUSE daemon 处理。但是在 open 的时候会把拿到的 fd 通过 native API 注册。然后就可以通过 native client 去读取数据了。

这个 API 类似于 io_uring，其中关键结构如下：

• Iov
  user process 和 native client 共享的内存
• Ior
  user process 和 native client 通过这个 ring buffer 进行交互。具体方式类似于 io_uring。
  请求会被按照 io_depth 攒批执行，不同的 batch 的执行是并行的。

Metadata 存储

chunk 的分布

文件按 chunk 为粒度，被条带化到多个 replication chain 中。
创建新文件的时候，会根据 stripe size，使用 round robin 的方式，选择一系列的 chain。选出来的这些 chain，会随机分给不同的 chunk 写入。

存储 file attributes

为什么 3FS 的 inode 里的 length 会不准确？因为写路径走的是 CRAQ，而 inode 是在 metadata service 里面的。如果每次写操作完都更新一下 metadata，那么会多一次 metadata RTT，写放大严重，吞吐和延迟都会变差。
但是如果 metadata 迟迟不更新，例如是 100mb，而客户端写到 120mb 就挂了，此时，虽然数据已经通过 CRAQ 持久化到 chunk 存储了，但因为读的时候从 metadata 获得的长度偏小，所以还是在效果上丢失数据。
一种方式是按照 interval 上报更新 metadata，但这就存在不一致窗口。不过先考虑容灾问题，大概有两个方案：

1. 重启之后，从 chunk 存储中恢复数据，并由此更新 metadata。但是从 chunk 扫描数据恢复的代价很大
2. 3FS 的设计是由 client 按照 interval 上报 max writer position，因为 client 上报的 position 一定是已经被 tail 提交了的，所以是安全的。但是如果 client 长期丢失，那么 gap 就得通过第一种方式补齐了。

Chunk 存储

Suppose there are 6 nodes: A, B, C, D, E, F. Each node has 1 SSD. Create 5 storage targets on each SSD: 1, 2, … 5. Then there are 30 targets in total: A1, A2, A3, …, F5. If each chunk has 3 replicas, a chain table is constructed as follows.

这里的 Version 是配置的 Version，节点下线会导致这个增大。

这里的一个 Chain 类似于一个 Raft Group 的概念。但是它也不是像 TiKV 一样跟某一段数据绑定的。一个 Chain 可以被多个 chain table 包含。引入 chain table 的概念，这样对于每一个 file，metadata service 就可以为它选一个 chain table，并根据这个 table 中的 Chain 去 strip 这个 file 的所有 chunk。

Balanced traffic during recovery

如果一个节点 A 故障了，就需要由 Chain 中的其他节点来承担原来 A 的流量。而之前的 Chain table 中，A 节点基本上只和 B、C 玩。

在新的架构中，A 在 Chain 2 里和 B/D 在一起，在 Chain 5 里和 C/F 在一起。

Data replication

一个 Write request 可能是从 client 或者 Chain 的前驱发送出来的。一个节点收到 Write request 后的处理：

• 校验 write request 中的 chain version。
• 通过 RDMA Read 去 pull 写入的数据。如果 client 或者前驱挂掉了，导致拿不到数据。写入就 abort。
• Once the write data is fetched into local memory buffer, a lock for the chunk to be updated is acquired from a lock manager. Concurrent writes to the same chunk are blocked. All writes are serialized at the head target.
• 读取这个 Chunk 的 committed version，对它 apply change，然后将更新后的版本存储为 pending version。版本号是单调连续递增的。
• If the service is the tail, the committed version is atomically replaced by the pending version and an acknowledgment message is sent to the predecessor. Otherwise, the write request is forwarded to the successor. When the committed version is updated, the current chain version is stored as a field in the chunk metadata.
• When an acknowledgment message arrives at a storage service, the service replaces the committed version with the pending version and continues to propagate the message to its predecessor. The local chunk lock is then released.

实现

Chain replication

CRAQ 的最大的特点是：复制链路是固定的，而 Raft 的复制链路因为存在 Quorum 是随机的。因此，对于单个 entry 的复制，Raft 的延迟可能会比 CRAQ好，但是 CRAQ 的延迟和吞吐更稳定，可以被预测。

延迟维度的对比：

1. Raft 最优
   a. 条件：follower 延迟几乎一致、没有网络问题
   b. commit latency 约等于 RTT
2. Raft 最劣
   a. 条件：quorum 中某个 follower 抖动，例如出现了 Write Stall
   b. Throughput 约等于 1 / avg([max(follower latency)]，这里的 avg 因为抖动是不均匀的，因为多数派每次都不一定一样。
3. CRAQ 最优
   a. 条件：链上每个 node 的 hop_latency 相同，管道用满
   b. Throughput ≈ min(hop throughput)，这个很简单，木桶效应嘛。
4. CRAQ 最劣
   a. 条件：链上每个 node 变慢
   b. 存在木桶效应，每个 entry 的提交都被固定变慢。

吞吐维度的对比：

1. Raft 最优
   a. 条件：同延迟。
   b. Throughput ≈ follower replication rate
2. Raft 最劣
   a. 条件：同延迟。
   b. commit latency 等于 max(quorum follower latency)，出现了木桶效应
3. CRAQ 最优
   a. 条件：链上每个 node 的 hop_latency 相同
   b. commit latency 约等于 chain_length * hop_latency。因为 CRAQ 在 Tail 返回确认，所以 3 副本也是两次数据传输，和 Raft 的 1 个 RTT 是接近的。但是链长了，CRAQ 就会变慢。
4. CRAQ 最劣
   a. 条件：存在一个很慢的 node
   b. 同上，但是木桶效应被放大很明显。

CRAQ 的其他特点：

1. 没有 quorum 容错
2. failover 不需要重新选主，但需要重构链。需要根据挂的是哪一个来讨论。

Reference

• https://github.com/deepseek-ai/3FS/blob/main/docs/design_notes.md

常见的表达

避免直接翻译汉语词

少用汉语式的名词化表达，例如“执行 xx 行动”，“处理 xx 过程”。

1
2
3
4
5

the lock is released

===>

the release of the lock is performed

不要自以为是去形容词化。如下，adaptive 的意思是自适应的，和我们实际要指代的“适配代码的行为”是不对应的。

1
2
3
4
5

We need to **adapt** the code to the new behavior. However, this **adaptive** work is not easy.

===>

... However, the adaptation work is not easy.

实词虚化、具体词抽象化

汉语中，很多虚词功能是通过复用实词来的。但是在英语中，如果有对应的虚词，就不要直接翻译汉语中的实词了。

1
2
3
4
5
6

Based on this reason, ...

===>

As a result, ...
For this reason, ...

又例如下面的“带来麻烦”，这里的带来没必要用 bring 这个实词

1
2
3
4
5
6
7

brings lots of trouble to investigate ...

===>

made the issue difficult to investigate ...
// Or
significantly complicated the investigation to ...

又例如下面的“定位到问题”

1
2
3
4
5

The problem is located by ...

===>

The problem was also detected by ...

虚词实化

但是，一些汉语中的虚词，在英语中要实化。例如，“这会导致难以理解的代码”，就是

1
2
3
4
5

It could result in confusing codes.

===>

It could generate confusing codes.

这个原则甚至不限于词，对于任何表达都是这样。This may cause problems，建议直接具体一点说是什么 problems。如

1
2
3

This behavior can cause a deadlock when two tasks hold the mutex across an await point.
// Or
This design is problematic in terms of concurrency safety, because it allows a task to hold a mutex across an await point.

需要调整句子结构

尽量避免使用形式主语 It is 或者 there is 等来拖长表达

1
2
3
4
5

It is hard to inspect the state.

===>

Inspecting the state is difficult.

但注意，非形式主语是可以用 it 的，如下所示，这好过说 “I think” 等

1
2
3

It indicates ...
This implies ...
The result shows ...

从下面的例子中，能感觉到动名词前置的用法，更干练

1
2
3
4
5

I don't think the service itself should persist the updated configuration to the config file. Instead, this should be handled by the operator.

===>

Persisting the updated configuration should be the responsibility of the operator, not the service itself.

语序

副词顺序应该稳定在动词后。

1
2
3
4
5

We must immediately do this.

===>

We must do this immediately.

其他

下面的表达，相比更能体现出不仅不能做之前说的，也不能做现在说的。而 Also 显得更像一个连接。

1
2
3
4
5
6

Also, A can't do sth.

===>

Moreover, A can not do sth either.
We can't ..., nor can we ... .

使用更恰当的单词

使用更精确的词

避免使用

possible -> feasible

使用恰当的搭配

动名词搭配。

辩证具体含义的差别

如：

• be confident of 和 be confident in

宏观写法

先给结论，再给解释（Top-down writing）。

特定场景的表达

偏向数据分析

表达“A使用的内存占A的调用者的比重，相比B使用的内存占B调用者的比重是相近了”，从书面到口语。

1
2
3
4
5
6
7
8

// 这里的 footprint 更专业术语一点。
A’s memory footprint relative to its callers is similar to B’s.

A and B exhibit similar memory-to-caller ratios.

The proportion of memory used by A relative to its callers is similar to that of B.

A and B have similar memory usage ratios with respect to their callers.

• 西安商业化太浓重了，例如大唐不夜城、城墙上骑车等。当然这也不是坏事，但如果玩的多了，就会觉得商业化严重的景点如同预制菜一样，不能说不好吃，但感觉容易腻
• 西安人太多了

但太原的问题主要是：

• 交通很不方便。虽然也看到它有专门的旅游线路，并且感觉是用心的，但体验上确实还有欠缺。

D1

我们是早上 7.55 的飞机，所以定了个 5.10 的送机，相比打车要贵一点，但好在不需要担心到时候没有车。正好前一天是跨年夜，我们就去雨花台吃了点饭，逛了下雨花万象，就住在雨花了。因为我经典的失眠，导致那一天我实际上没怎么睡。

在机场躺大座睡了一个小时，然后登机门开了，风吹进来冷的要死，没法继续睡了。好在也快登机了。这鬼飞机是摆渡车，真的冷死，外面还下着雪。

到了机场，出门就能打车，打车秒打，司机就在停车场，很快就上了车。太原机场离市区是真的近，离太原南站也很近，所以是非常适合中转的城市，这很类似之前去过的张家界。

北齐壁画博物馆分为三个展厅：

• 第一展厅是娄叡墓的壁画。比较有印象的一个是狩猎图，一个是升天图。有印象的细节一个是马一边跑一边被吓得拉屎。另一个是雷公，长得特别奇怪。
• 第二展厅徐显秀墓。因为整个博物馆实际上就是盖在这个墓上面的，所以比较有趣。我们可以看到当时发现这个墓的土丘上的盗洞。值得一提的是，虽然我们没法下到最下面的墓里面去，但是旁边有个清晰度贼高的 vr 可以看，不仅壁画很清楚，而且能看到总共五个盗洞。我想，为什么我们看不到棺椁，可能就是这么多盗洞把它们都偷走了了吧。另外，后面在山西博物院中，我们能看到这个墓里面的壁画，但不知道是仿制品，还是移过来的。
• 第三展厅是拼好展，里面展示了不同的墓的壁画。

从北齐壁画博物馆出来，打车非常难打。索性看到有个公交车，就上去，发现好像是个旅游专线，只到双塔公园和火车站。用微信乘车码就可以刷码，坐上去之后，司机一个人发了一张门票一样的东西，实际上就是旅游专线的车票，感觉挺用心的。

考虑了下，我们觉得先回宾馆比较好。一来，双塔公园离着纯阳宫和宾馆都很远，后面两者反而比较近。二来，我那个包确实太重了。于是打了辆车，直奔宾馆。

到了宾馆，准备出门，发现山西博物院突然放了一千多张票。于是打电话问，答复说只要是今天的时间预约的就可以来。接线的是个女人，用非常热情的预期表达了对我们的欢迎，非常点赞。所以，我们临时改了计划，去看山西博物院。

山西博物院就靠着我们的亚朵，中间隔了自然博物馆和图书馆。走过去的时候，门口就排了个小队了。进去之后，发现博物馆里面全是人。这个博物馆主要是四层，重点的是在 2/3 两层，另外有几个重要展物被放到了第 1 层和第 4 层。山西博物馆主要就是看各种青铜器。四楼有很多主体展厅，比如玉、应县木塔、钱币等。总体感觉这博物馆年代比陕历博要老，基本上全是青铜器。比较有印象的一个是那个猫头鹰，还有就是大蜗牛上骑着小蜗牛，以及博物馆徽标上的大鸟上骑小鸟的。有个叫雁鱼铜灯的文物好像被国博借走了，直接在下面放了个不知道是啥的青铜器掩耳盗铃。

从山西博物馆出来，快五点了，我们赶快打车去河东颐祥阁。事实证明这决定很正确，因为我们到的时候饭店还没开门。但是我们刚坐下来，一堆人就陆陆续续进来了，然后他们就要排队。我们在饭店点了非常多的东西，在此点评一下：

• 涮肚 我老婆说这个麻辣烫很好，因为里面的麻酱没有麻酱味，她能接受。我觉得也不错。
• 芥末凉粉 很爽口。
• 风葫芦 感觉是炸的一个脆皮球，然后里面是很嫩的鸡蛋。我对象很喜欢，我觉得还行，但没有特别很好吃。
• 黄米排骨 这个是最贵的，但吃起来感觉一般。
• 麻辣串 实际上就是豆干，但是加了他那个口感很椒麻胡辣的汤汁，很好吃。我对象不喜欢胡椒和辣口味，她不怎么喜欢。
• 羊腿 我觉得很好吃，我对象也觉得。而且她觉得不太膻。
• 槐花 小学里课文学过，但实际上是第一次吃槐花，感觉挺好吃的。没想到是咸的，感觉有点吃野菜的感觉，但并不像野菜那样有茎的感觉。
• 野菜丸子 感觉就是北方的那种丸子。
• 绿豆糕 挺甜的，但是很好吃。
• 烧饼 有点像肉夹馍的馍，但是是很热的，吃起来很香。

从颐祥阁出来，已经打包了一堆东西，我们打算去鼓楼街再去看看。太原的地铁在长风街这一段特别稀疏，但吃的又都在这里，所以我们走了好远上了地铁。从府西街站下来，我们拐进了帽儿巷。

刚去的时候，人是一般多，我老婆还说这个离长沙差远了。我们随便走走，就看到一家要排队的卖麻花的，说特别有名。买了黑芝麻和蜂蜜的，感觉就是小时候的味道，有点类似于我奶奶买的那个火腿肠面包。我记得那个面包皮我特别喜欢，就是这个麻花的味道。

我们后面又买了枣糕和碗托。碗托的那个面感觉挺好吃的，是糯糯的。而很早之前我对象在淘宝买的感觉就很干，跟那种硬胶水一样。不过我当时已经又累又撑，不太吃的下了。

我准备往地铁站走准备回去了，但是我老婆说，这个鼓楼街，我们还没见到鼓楼呢。于是走到横过来的一条街上，这条街就洋气很多了，都是一些洋人的建筑。再往前走，还有一个巨大的钟楼。这里人就开始特别多了，有种长沙的感觉。

在认一力吃了几道菜：

• 羊肉水饺 点了两种，但感觉都一个味道。我老婆说羊肉味特别大，根本没法吃。我觉得还行，但是感觉很咸。感觉羊肉馅里面加了很多葱姜蒜。另外，第二天我从冰箱里面拿出来的时候，感觉它们散发着一股呕吐味。但加热之后，又能吃了，感觉还行。
• 沙棘醪糟 感觉挺好吃的，很清淡，不是特别的酸，也不怎么甜。但是很爽口。
• 头脑 头脑里面的羊肉挺好吃的，炖的烂。但是那个粥一样的东西就是一言难尽了。吃起来感觉就好像是熬的很浓的羊油和粥一起煮成的粘稠物。但是呢，它本身又不具备酸甜苦辣咸这些基础的味道，所以吃在嘴里就是一股腥味。

从认一力出来，人就开始比肩接踵了，于是我们准备往回走了。当时我已经又撑又困到神志不清了，终于走到了柳南地铁站。坐地铁到太原理工大学站，发现到酒店还要走好远。

晚上回来困得要死，倒头就睡。中途 23 点的时候被老婆叫起来看，原来是酒店对面就放起了烟花。话说山西今年不禁止放烟花，所以大家过年都在放，感觉挺热闹的。汾河上的那条龙今天晚上也是一直亮着灯，还挺好看的。

D2

早上起的有点晚，睡了大概 10 个多小时。吃了个酒店的自助餐，顺便把昨天的水饺热了下。

打车去晋祠，这一路挺远的，司机开得贼快。太原的早晨全是雾霾，路过还有几个大烟囱在冒着白气，可能是供暖工厂吧。到了晋祠，寻思着买了个天龙山的门票。晋祠一进去是非常大的免费公园，里面做了一堆假山雕塑啥的，有个唐太宗的雕塑后面还出现在太原的城市宣传画上，但是感觉雕的人脸都一样。

晋祠博物馆是挺有意思的，原本我以为它就是一个祠堂，拍照打卡走人这样，但里面挺大的，而且建筑的排布很好看，基本上处处是景。

游览这个景点，必须要有个讲解。我当时还是用的旅途随身听，感觉讲的是足够了。总而言之，这个晋祠原来是纪念一个儿子的，后来慢慢的，妈妈名气反而更大了，所以改为了主要祭奠妈妈，结果导致儿子的祠堂偏安在整个晋祠的最角落。

一进门就是晋祠最网红的孙悟空同款了，但其实它并不是祠堂，而是一个戏台，叫水镜台。很多人在正面拍照合影，走到背面有个康熙题的匾额。

然后，我们就按照旅途随身听的导览逛了，先逛了一遍关帝庙、岳飞庙等，我也认识了一堆歇山顶、硬山顶等屋顶的类型，从而判断规格。然后就到了儿子的唐叔虞的祠堂。这哥们属实惨，真的就在最角落，门口还贼小。要不是随身听，我可能都不会进去。

从唐叔虞祠堂出来，就看到前面一堆人。这里应该就是晋祠最核心的地方，也就是圣母堂了。圣母堂有几点比较独特：

• 堂前的十字桥，据说是首创。这个桥在晋祠外围的免费公园中也有个拙劣的模仿。
• 七开间的规格，每个柱子上都有龙盘旋，这些龙长得都不一样，有的还很抽象。
• 圣母堂中的宋代雕塑，惟妙惟肖。
• 圣母堂旁边有个周朝的柏树，然后它被另一棵柏树架着。

从圣母堂转了一圈出来，旁边还有一个苗裔娘娘堂，再绕出来，就到了难老泉。这个说是晋阳第一泉，感觉就是比较谦虚了，毕竟无锡还有个天下第二泉呢。这个亭子是北齐建的，所以可以看到斗拱是非常的大。虽然后面在嘉靖年返修了，但仍然是使用了北齐的手法。而它对面的亭子，斗拱就很小，一看就是明清的建筑。其实在晋祠中，分布着不同朝代的建筑，我们都可以从斗拱的大小，以及房顶上鸱吻头和尾巴的比例来分辨年代。晋祠中比较主要的建筑如圣母殿等都是在唐左右建设的。

难老泉会通过一个龙头流到旁边的一条小溪里面，然后很多人排队在那里接水。我们绕过那群人，就可以走到子乔祠、董寿平美术馆那一带，不过那些就不是重点了。

我去逛了逛美术馆，我老婆根本就没去逛，而是再绕回来到正面，到了圣母堂之前的一些建筑，如会仙桥、献殿等。比较有意思的是金人台，上面有个非常小的小楼，不知道那是干嘛的。献殿上面有个万历四年的匾额，我对象说是不是那个万历四年春，我说那是庆历四年春。

从晋祠出来，下一站就是天龙山。但我们必须走很长的路才能穿过外围的免费公园。我们还路过了晋文公艺术博物馆，不过没进去看，不知道里面怎么样。博物馆附近有很多大湖环绕，里面可以划船，但是现在是冬天，这些湖面都结冰了。博物馆前按照先秦的特色，搞了点夯土柱子。绕过博物馆，就到了出口，在这里进行了一些简单的修整，买了个烤红薯和上海阿姨，就去找景区交通。

公交站排队等了比较长的时间，感觉得有至少十分钟，车来了。因为我们觉得不太妙，所以当时就站的比较靠前，所以有座位坐，但没想到这个公交车是不给站的。所以我们眼睁睁看着后面的人上不来，司机跟他们说等下一班吧。这公交车开了，没一会就上了盘山公路。这路应该太原花了很多钱搞了个旅游公路，很多盘山公路被搞成了类似南浦大桥那样的展线，所谓网红桥。这些展线上停了一堆小轿车，人们在那里往低处拍照片。到了龙门站，我们下车，其实已经花了几十分钟了。

这天龙山其实很坑，它主要是看石窟的，分为东峰和西峰，但是我们去的时候东峰全封掉了，所以我们就直接往上走回去了，也没再去下面的天龙寺。具体到西峰石窟，里面也是丢的丢，乱涂乱画的也有。后面打了个车去国宝馆，里面看到了东峰石窟中第 8 窟的佛头，说是被日本人之前抢走了的，后来被中国又追回来了。国宝馆旁边还有个数字馆，就是给你看看一些石窟的宣传片。

从国宝馆直接坐车到晋祠，下了车就打车去植物园。太原植物园很大，一进去是一个湖，湖面已经结冰。围湖种了一圈银杏，叶子很漂亮，不过走近一看发现是假的。因为是冬天，主要能逛的就是几个温室。这几个温室设计的都很好，造景很有一套，并且有高低不同的步道，可以方便游客游览观看不同高度的植物。热带雨林馆里面有个瀑布，大家挤在那里拍照。不过我最喜欢的还是沙生植物馆，一进门是三个大黄柱子，加上远处落日，夕阳照在上面的感觉，给我一种置身于沙漠或者火星表面的感觉。另外还有一个蝴蝶馆，以及一个园艺馆，反正都挺好看的。太原植物园还有萤火虫看，不过冬天就暂停了。

最终也没等到植物园那个网红天花板亮灯，而是五点二十不到就打车走了。当时打车很容易，不过刚开到市区就发现植物园门口堵红了。我觉得这里的交通设计有问题，汽车要去植物园门口，实际上要走很远到前面掉头才行。这也是太原的一个特点，快速路很多，但是跨越高速路，或者掉头，就很麻烦了。

去吃东北爱情麻辣拌，在一个非常荒芜的小巷中的破落小平房，里面墙上天花板上都是之前顾客的留言。只能选择加料，以及辣度。我加了麻花和什么的，我对象加了另外一种。这麻辣拌全是素的，全是碳水，要不就是豆制品。旁边一个京爷在吹牛逼说自己老爹是个煤矿里面的啥科长，然后后面北京就不让挖煤了 blabla，说房子贵得要死，幸亏买得早。

从麻辣烫出来，不远就能走到附近的上帝炸鸡，因为我觉得尽管有外卖，但是没必要一定吃总店。路上还遇到一个卖碗托的路边摊子，不过这次卖的是保德碗托。味道很不一样，我看到她加了一种黄色的酱汁，我想这个应该导致了我们最终吃到的是有点酸味的。加上我们没有要很多辣油，就导致碗托并不腻。不过它的面感觉就和淘宝的荞麦面碗托一样，不如昨天的那个有糯劲。卖碗托的斜对面就是上帝炸鸡，我们点了一份大份的，吃起来感觉就是那种老派炸鸡的感觉，外皮特别脆，但是里面很多汁。不过我觉得得加点辣粉更好吃。

买完上帝炸鸡，就去利源沾片子。中途路过似乎是太原比较繁华的体育路街区，有个盒马。我们继续往北走就到了沾片子，在一个灯光很暗的小街上。我老婆先去的，然后出来告诉我要排位，留了个电话号码。然后我们就寻思附近转转，这附近可真没啥能转的。一些很拉胯的咖啡厅，泰山啤酒，一堆成人用品店。最后，我们回到那个店，发现人都换了一遍，显然老板看生意好，就没有叫我们。所以我们被迫在店里面站着等位，等的时候，后面最多来了四队人。老板让我们提前点菜，我们点了一堆：

• 沾片子 吃起来比较素。我比较喜欢豇豆的那个，感觉保留了蔬菜的本味。
• 炒茄子 很好吃，茄子很脆，酱汁很香。
• 莜面
• 清徐灌肠 实际上也是素的，感觉挺油的

这家店不光等位慢，做得也慢，出来了就九点多了。打车不太打得到，所以就准备坐地铁，路上还买了一盒草莓，大个的，才 30 块钱。好不容易坐上了地铁，然后下错站了，所幸直接打车算了。不过这样晚上在汾河边散步的计划就泡汤了，实际上那天晚上步道的灯光包括那条龙也没开，所以就算了。

D3

早上七点五十就起来了，先把昨天的炸鸡拿到宾馆餐厅里面热热，顺便再吃吃他的刀削面和豆花。太钢汽水也是尝了尝别的味道，感觉都还可以。

吃完饭，就去汾河边散散步。这次见识到了传说中的自行车道，其实挺窄的，一个方向只能容纳一个人骑。并且这个自行车道的下匝道有点少，很多地方是高架。要散步的话，可以穿过自行车道再往河边走。

逛完回去已经快九点半了，赶快打车去晋商博物馆。晋商博物馆实际上就是原来的巡抚衙门，在民国时期也是山西的中枢所在，到了新中国，一度是省委和省政府的办公地，一直到 2017 年改建为博物馆。这个博物馆确实透露着政府办公室的气息，特别是中间一栋苏联式样的办公楼，一进去就能闻到浓烈的复写纸的味道。

我发现山西这边的博物馆有一个喜好，就是搞大全套收集。例如山西博物院就搞了个钱币展，非常夸张的收集了先秦时期各个国家的钱币，以及后面历朝历代不同年号的钱币。晋商博物馆中更是收集了七八套大小不一的编钟，收集了鼎、盆、壶、斛等各种器皿。最特别的是，我第一次看到了一个东西叫灶。晋商博物馆挺长的，进去先是一个高楼，里面存了据说是山西第一巡抚诺敏的匾额。后面是2号楼和3号楼，两栋楼通过走廊连在一起。在后面是个会议室，和一个苏联样式的高楼。再往后有一个钟楼，但是不让过去了。比较幸运的是，东花园原来在修缮，但是这一次对我们开放了。进去可以看到民国时候的一些陈列，以及五几年的时候省委书记的住房。

从晋商博物院出来，就去吃了一诺铜火锅。我老婆照例点了一辈子都吃不完的菜，点评如下：

• 铜锅 感觉一般
• 黄米凉糕 很好吃，但是不要把上面的糖拌进去，不然就太甜了
• 丸子串 一般
• 羊肉串 很好吃
• 涮肚 感觉很好吃，我老婆觉得麻将很多，但是我觉得跟颐祥阁一模一样
• 蒜泥茄条 挺好吃的，酸酸甜甜
• 小酥肉 肉感觉一般，但是旁边的蘑菇还不错
• 烤饼 感觉很好吃，也带回去了
• 鸡包豆腐 感觉就是千页豆腐？一般
• 过油肉 很好吃
• 酸辣白菜 酸酸甜甜的很好吃

吃完饭，才 12.40，感觉还有一段时间，因此就准备去纯阳宫。因为我在打车过来的路上就看到纯阳宫了，所以就直接骑车过去，风风火火，花了不到十分钟就骑到了。进去之后，我老婆终于要上厕所了，我先进去逛。它的展厅都好没意思，啥陈列都没有，就干放视频。走到最后，是个主题展，里面陈列了一个常阳天尊像，居然是一级国宝，并且是 195 文物。这玩意也没有被框起来，能够近距离观赏感觉挺好，大家也都很有素质，不上手摸。出门，上楼梯，二层的展览就很蠢了，有个展厅里面全是文物已借出。二楼可以通到前面的九宫八卦院，有很多人在那边拍照。

往回走，打开了旅途随身听，介绍了九宫八卦院，这个建筑布局很有意思，据说是全国唯一的。再往回，就是吕洞宾殿，也就是纯阳宫的主要建筑。再往回就是弥勒佛铜像。我老婆跟我说这里面有个西汉的石狮子，还有明代的铜狮子，居然就直接摆在那里，也没有保护，感觉山西还是富，人们和文物生活在一起。

再往回走，就快到了出口。此时左边是一个假山，上面是一个关羽像。关羽像没有胡子，因为这个像是在明朝的，而关羽有胡子的说法是明末根据三国演义才有的。右边是个碑廊，然后里面放着另一个 195 文物，涅槃变相碑。这玩意也没有被保护起来，我觉得还是不太好，毕竟这个是室外嘛，还是要有点防护为好。

我在看涅槃变相碑的时候，因为空间狭小，我的书包还把后面的一个壁画的说明牌给蹭下来了，幸亏没有伤着壁画，不过这也说明了这个陈列比较拥挤，容易碰到。

从纯阳宫出来立马打车赶往机场，不得再次羡慕太原机场离市区实在是近。

• 针对这些问题的技术性解法和运维性的解法
  涉及到某些内部知识的将不予公开。
• 对于问题严重程度应该如何判断
• 如何为了达成上线的既定目标，设计临时性的缓解措施

POC on TiDB-X for Customer U, late Nov 2025

主要问题

1. 支持 Keyspace
2. 运维手段
   包含 Shard、Reader 和 Importer
3. 支持 Security
4. openssl 的编译问题
5. arm 编译的问题
6. 上线后出现的影响可用性的 bug
7. 上线后出现的影响性能的 bug

Nov 21

讨论 import into 场景下，如果某个 worker 因为 OOM 重启，则因为目前缺少 Heartbeat 机制和 reschedule 机制，整个任务会因为这个小任务失败而停止。

另外，也提到了和 import into 流控相关的问题。

Nov 23

遇到了 tokio Sender 报错 channel closed 问题。当时没有空查。

这个问题实际上就是协程因为哪里 unwrap 而 panic 了，而因为协程池是跑的消息循环，所以 panic 了不 join 也不知道。一直没找到是哪里，后来我加了点 panic hook，才在 Nov 30 定位到是服务发现的问题。

Nov 26

1. TLS options are only supported with HTTPS URLs
   这个错误很 plain
2. Client had asked for TLS connection but TLS support is disabled. Please enable one of the following features: [“native-tls-tls”, “rusttls-tls”]
   我们不能用 native，只能用内置的 rusttls
3. undefined symbol: pthread_atfork
   ARM 上的编译问题，有专门文章介绍
4. TLS error error:0A000086
   这个就是要启动的时候指定下用 ring 还是 aws_lc_rs

Nov 27

1. 排查 ARM 上的问题，这里做了两套方案，先设法用 x86 跑起来。这证明也是正确的，白天我们发现了更多的问题，最终因为 TLS 的问题也没有跑起来。但是晚上我们把 ARM 验证了下，发现不报原先的错了。
2. 遇到一个新问题是我们的云上 operator 机制不支持改参数，我们挂的又是 ro 文件系统，导致很难验证
3. etcd client unavailable or unhealthy, attempting reconnect
   这个是 kebab-case 的锅，Rust 和 C++ 的格式不一样，写配置的同学把 ca-path 写成 ca_path 了。
4. 后来发现，TiFlash CN 还是绕不开 TLS 的问题。所以还是得兼容。

Nov 28

1. get meta channel failed times
   这个错误还是 etcd client 的 ca-path 没传对
2. 到这里为止，整体看上去能跑了，但是查询报错，看日志感觉核心服务没起来
   首先 lsof 看了一下，发现服务器都没起来。
   因为没有 panic，直觉是哪里有个报错死在协程里面没传播出去。进而发现是 rust 的 grpc server 不能在 dns 格式的 url 上启动。不得不说我几天前的 advertise_addr 的改动很有先见之明 https://github.com/pingcap-inc/tici/pull/515

Nov 29

1. 白天是在 import into 导入数据，晚上出现了一堆问题。
2. 首先，是之前的那个 panic 导致协程退出的阴魂不散又来了。我紧急去掉了一堆 unwrap，并且加了 panic hook 打印错误日志。
3. 然后，是 writer 那边没有对 meta 返回的错误码进行处理，但是加上了处理之后，一个集成测试不通过了。大家觉得要不就把这个测试禁用了吧，但是我很反对，因为这个测试是唯一一个带上真实的 worker 和 reader 跑完 e2e 的测试。并且我看了日志发现一个 writer node 被超时移出了，所以尽管 pr owner 认为他并没有改动到这一块的逻辑，我仍然认为他的修改导致一个严重问题暴露了。因此，我们应该先查问题。原因是即使我们强行合并了，也不能拿这个 commit 去跑生产。后来，确实发现了是在处理 heartbeat 的时候会等待一个异步任务结束，所以导致后面 heartbeat 消息循环直接卡死了。所以，这个问题确实会导致 writer 因为丢失心跳从而被全不 failover，进而整个集群没有 writer 可用的 critical 问题。不 approve 这个 PR 是完全正确的。

Nov 30

今天主要切换到性能方面的支持上：

• warmup 的速度太慢了，所以想把这一块改成并发执行
  在这个处理之后，8 个节点，24 个并发，大概是不到两个小时就处理完毕了。
• 因为 worker 出现了异常重启，导致重启后 meta 向它发送了大量的 add shard message，导致触发了 grpc 的消息大小上限。临时通过增加上限来 workaround 了。实际上是可以通过拆成多个 heartbeat response 来解决。另外同事也提到，可以只发部分信息，其他的后续让主动请求，但这个可能会产生很多的 grpc 调用。

Dec 1

• 发现查询速度比较低，原因是串行访问的所有 shard

Dec 2

• 发现查询并发比较低，原因是查询的 filter 不能通过主键进行过滤，所以导致每次查询需要访问所有的 shard

Dec 3

• 关于昨天的并发问题，认为一个 shard 中有多个 fragment，并且一个 fragment 中又有多个 segment，因此会影响查询的速度。通过 Manual compaction 和调大内存的方式，使得 fragment 和 segment 都变少。
• 因为目前没有自动 balance 机制，所以还需要 Manual reschedule。

Dec 5

功能侧：

• 主要处理 duplicate fragment 的问题。我认为因为 apply compaction 需要根据 frag path 来定位，重名的 frag 会导致问题，所以应该由 meta 来禁用。

测试侧：

• 执行了 Compaction，并且后续自动执行了 Merge，发现查询 QPS 提高了 50%，但依然是比较差的
• 因此决定用 (token0_address, ts) 作为新的主键，和 TiKV 解耦

Dec 6

这一轮测试发现调整了新的主键之后，QPS 增加了很多，可以看出列存中使用不同的 Sharding key 的重要性：

• 静态数据 QPS 2.6k+，P999 61.6 ms，且仍有弹性。其中 TiFlash CPU 是 2300%，内存是 8 * 91G。
  https://github.com/CalvinNeo/ue-bench/blob/master/src/main.rs

  1	SELECT * FROM ... WHERE token0_address = ? AND platform = ? AND ts < ? LIMIT 5

• 写入的索引大概是 10.5TB 左右。Shard 数量约为 5800+。

某 OP 用户：Q1 2026

1

/tiflash/tiflash: symbol lookup error: /tiflash/libtici_search_lib.so: undefined symbol: pthread_atfork

首先，ldd 看到，链接的是本地的 /lib64/libpthread.so.0。

可以通过 strings /lib64/libpthread.so.0 | grep '^GLIBC_' 命令查询 GLIBC 的版本。

然后，nm 了一下 /tiflash/libtici_search_lib.so，结果是：

1. x86 开发机

   1 2 3 4 5 6 7 8

   nm libtici_search_lib.so | grep pthread 0000000003c97e70 t __pthread_atfork 0000000003c97e70 t pthread_atfork U pthread_attr_destroy U pthread_attr_getguardsize U pthread_attr_getstack U pthread_attr_init U pthread_attr_setstacksize

2. arm tiflash:v2025.8.10-2-gc9e3144-centos7 镜像
   

3. x86 tiflash:v2025.8.10-2-gc9e3144-centos7 镜像
   这个是 multi arch 镜像，但是 glibc 版本不一样

那么这个符号在 /lib64/libpthread.so.0 里面有么？nm 了一下：

• x86 的版本是 2.34，显示这个 so 是没有 Debug info 的。难道被 trim 了么？ls 了一下这个文件，发现只有 15KiB 左右。后来了解到，在较新的 GLIBC 中，pthread 相关的被整合到了 libc.so 中，我 nm 了 libc.so 确实可以看到。
• arm 版本是 2.17，nm 了可以看到其他 pthread 符号，但是看不到 pthread_atfork。

原因是在大多数 Linux 发行版（使用 glibc 的系统）中，pthread_atfork 的符号并不在常规的共享库如 libpthread.so.0 中，而是通过链接器脚本特殊处理，其具体实现位于 libpthread_nonshared.a 这个静态归档文件中，而非 .so 文件里 。

解决方案参考 https://github.com/pingcap/tiflash/pull/10571，强制使用 -pthread 而不是 -lpthread 即可。

mpsc

mpsc 有 bounded 和 unbounded 两种形式。通过不同的 semaphore 来区别。

Chan 结构

对于 unbounded semaphore，其最低的 bit 表示这个 channel 有没有关闭。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

// ===== impl Semaphore for (::Semaphore, capacity) =====

impl Semaphore for bounded::Semaphore {
    fn add_permit(&self) {
        self.semaphore.release(1);
    }

    fn add_permits(&self, n: usize) {
        self.semaphore.release(n)
    }

    fn is_idle(&self) -> bool {
        self.semaphore.available_permits() == self.bound
    }

    fn close(&self) {
        self.semaphore.close();
    }

    fn is_closed(&self) -> bool {
        self.semaphore.is_closed()
    }
}

// ===== impl Semaphore for AtomicUsize =====

impl Semaphore for unbounded::Semaphore {
    fn add_permit(&self) {
        let prev = self.0.fetch_sub(2, Release);

        if prev >> 1 == 0 {
            // Something went wrong
            process::abort();
        }
    }

    fn add_permits(&self, n: usize) {
        let prev = self.0.fetch_sub(n << 1, Release);

        if (prev >> 1) < n {
            // Something went wrong
            process::abort();
        }
    }

    fn is_idle(&self) -> bool {
        self.0.load(Acquire) >> 1 == 0
    }

    fn close(&self) {
        self.0.fetch_or(1, Release);
    }

    fn is_closed(&self) -> bool {
        self.0.load(Acquire) & 1 == 1
    }
}

无论是 unbounded 还是 bounded，最终都是到 chan::Tx 和 chan::Rx 这两个结构里面。这两个类都持有一个 Arc<Chan<T, S>>。

我们会看到有两个 Tx：

1. chan::Tx 是一个 Arc<Chan<T, S>>，它实际上封装了 Chan，更上层一点
2. list::Tx 是一个 Block 的链表。它是 Chan<T, S> 的 filed，更底层一点

list::tx 是一个无锁队列。这个队列的内存是以 Block 为基础分配的，每个 block 能装 const BLOCK_CAP: usize = 32; 个 Value。所以，Chan 中实现了解耦：

• list 模块只负责无锁队列的实现
• Chan 的其他部分负责容量控制、notify/waker 的逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

pub(super) struct Chan<T, S> {
    /// Handle to the push half of the lock-free list.
    tx: CachePadded<list::Tx<T>>,

    /// Receiver waker. Notified when a value is pushed into the channel.
    rx_waker: CachePadded<AtomicWaker>,

    /// Notifies all tasks listening for the receiver being dropped.
    notify_rx_closed: Notify,

    /// Coordinates access to channel's capacity.
    semaphore: S,

    /// Tracks the number of outstanding sender handles.
    ///
    /// When this drops to zero, the send half of the channel is closed.
    tx_count: AtomicUsize,

    /// Tracks the number of outstanding weak sender handles.
    tx_weak_count: AtomicUsize,

    /// Only accessed by `Rx` handle.
    rx_fields: UnsafeCell<RxFields<T>>,
}

block 的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#[cfg(all(target_pointer_width = "64", not(loom)))]
const BLOCK_CAP: usize = 32;

#[repr(transparent)]
struct Values<T>([UnsafeCell<MaybeUninit<T>>; BLOCK_CAP]);

pub(crate) struct Block<T> {
    /// The header fields.
    header: BlockHeader<T>,

    /// Array containing values pushed into the block. Values are stored in a
    /// continuous array in order to improve cache line behavior when reading.
    /// The values must be manually dropped.
    values: Values<T>,
}

/// Extra fields for a `Block<T>`.
struct BlockHeader<T> {
    /// The start index of this block.
    ///
    /// Slots in this block have indices in `start_index .. start_index + BLOCK_CAP`.
    start_index: usize,

    /// The next block in the linked list.
    next: AtomicPtr<Block<T>>,

    /// Bitfield tracking slots that are ready to have their values consumed.
    ready_slots: AtomicUsize,

    /// The observed `tail_position` value *after* the block has been passed by
    /// `block_tail`.
    observed_tail_position: UnsafeCell<usize>,
}

看 Block::grow，就是一个无锁链表的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

...
        let mut curr = next;

        // TODO: Should this iteration be capped?
        loop {
            let actual = unsafe { curr.as_ref().try_push(&mut new_block, AcqRel, Acquire) };

            curr = match actual {
                Ok(()) => {
                    return next;
                }
                Err(curr) => curr,
            };

            crate::loom::thread::yield_now();
        }
...

为什么是关于 Block 的无锁队列？

为什么是关于 Block 的无锁队列，而不是关于 Value 的呢？

1. 减少锁竞争和原子操作 (Reduced Contention and Atomic Operations)
   集中操作 (Batch Operations): 在高并发场景下，如果每次发送一个 Value 就需要对共享队列（如链表或原子指针）进行一次原子操作（例如 CAS - Compare-and-Swap）来添加节点，那么多个发送者 (Multi-Producer) 之间的竞争会非常激烈，导致性能瓶颈。
   Block 机制: 使用 Block（块），每个 Block 中可以存放多个 Value。这样，发送者可以一次性分配一个 Block，并填充多个 Value。在将这个 Block 链接到队列末尾时，只需要进行一次原子操作来更新队列的尾指针。这大大减少了对核心共享数据结构（队列头/尾）的原子操作次数，从而降低了锁竞争和系统开销。
   局部性 (Locality): 一旦一个发送者成功获取并填充了一个 Block，它就可以在没有竞争的情况下，向该 Block 中写入若干条消息，这利用了 CPU 缓存的局部性原理。
2. 优化内存分配 (Optimized Memory Allocation)
   批量分配: 每次发送一个 Value 就进行一次内存分配是低效的。Block 允许一次性分配一块较大的内存，用于存储多个 Value。
   更少的元数据: 如果每条 Value 都是一个独立的链表节点，那么每个节点都需要存储一个指针（指向下一个节点）作为元数据。在 Block 方案中，只有 Block 之间有链接指针，一个 Block 内部的多个 Value 可以紧凑存储，减少了内存开销。

channel 创建

send 实现

unbounded

unbounded 的 send 的实现，可以看到，最终调用了 Chan 的 send，后面会详细介绍。

1
2
3
4
5
6
7
8

pub fn send(&self, message: T) -> Result<(), SendError<T>> {
    if !self.inc_num_messages() {
        return Err(SendError(message));
    }

    self.chan.send(message);
    Ok(())
}

inc_num_messages 的逻辑如下，主要是每次增加 2，保证末尾是 0

1
2
3
4
5

if curr & 1 == 1 {
return false;
}

.compare_exchange(curr, curr + 2, AcqRel, Acquire)

bounded

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

async fn reserve_inner(&self, n: usize) -> Result<(), SendError<()>> {
    crate::trace::async_trace_leaf().await;

    if n > self.max_capacity() {
        return Err(SendError(()));
    }
    match self.chan.semaphore().semaphore.acquire(n).await {
        Ok(()) => Ok(()),
        Err(_) => Err(SendError(())),
    }
}

pub fn max_capacity(&self) -> usize {
    self.chan.semaphore().bound
}

pub(crate) fn acquire(&self, num_permits: usize) -> Acquire<'_> {
    Acquire::new(self, num_permits)
}

Chan 的 send 实现

Chan 的 send 的实现如下

1
2
3
4
5
6
7

fn send(&self, value: T) {
    // Push the value
    self.tx.push(value);

    // Notify the rx task
    self.rx_waker.wake();
}

这个 rx_waker 是一个 AtomicWaker 对象。

1
2
3
4

pub(crate) struct AtomicWaker {
    state: AtomicUsize,
    waker: UnsafeCell<Option<std::task::Waker>>,
}

Reference

• 完备性
• 唯一性

Case by case

如何表示一个空区间？

有一些 string，那么可以用 [s1, s2) 来圈出一些 string。因为是左闭右开区间，所以空集难以表示。这里只能通过

如何表示“和上次一样”

Option<Vec> 还是 Vec？

Vec 是 Option 的上位类型。

1.0 Introduction

Linux 的读写 API 经历了：

• read

• pread：增加了 offset

• preadv：offset 是 iovec 的形式，就是支持分散读

  1 2 3 4 5

  struct iovec { void __user *iov_base; __kernel_size_t iov_len; };

• preadv2：加了 flags
  可以参考 https://www.man7.org/linux/man-pages/man2/preadv2.2.html

但上述的 API 都是同步的。posix 有 aio_ 系列的 API 标准，但是没啥人用，性能也不好。

Linux 有个 libaio，它和 POSIX 的 aio_ 系列不是一个东西。但它也有问题：

• 它要求 O_DIRECT，不然就和同步调用没啥区别。而 O_DIRECT 会 bypass cache，并且有严格的对齐要求，所以用途受限制。

• 即使满足 async 的所有条件，最终也不一定是 async 的。比如：

  • 如果要修改元数据，可能会 block
  • storage device 的 request slots 的数量是固定的
    这里的 request slots 表示 storage device 同时可以处理的并发数。
    传统存储协议如 SATA、SAS 中，只有一个命令队列，存放未完成的 io，它的长度就是 io depth。如果下层 storage device 的 request slots 数量小于 io depth，那么 io 请求就可能在 io 队列中等待。
    NVMe SSD 支持多个 Submission Queues (SQ) 和 Completion Queues (CQ)，每个 SQ 条目可对应一个正在执行的 I/O 命令。比如有 64 个 queue，每个 queue 深度是 1024，那么理论上最多可并行执行 64 × 1024 = 65536 个命令。

• 提交一个 io 需要复制 64 + 8 bytes。完成一个 io 需要复制 32 bytes。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  struct iocb { __u64 aio_data; __u32 PADDED(aio_key, aio_rw_flags); __u16 aio_lio_opcode; __s16 aio_reqprio; __u32 aio_fildes; __u64 aio_buf; __u64 aio_nbytes; __s64 aio_offset; __u64 aio_reserved2; __u32 aio_flags; __u32 aio_resfd; }; struct io_event { __u64 data; __u64 obj; __s64 res; __s64 res2; };

  Depending on your IO size, this can definitely be noticeable.
  IO always requires at least two system calls (submit + wait-for-completion), which in these post spectre/meltdown days is a serious slowdown.

2.0 Improving the status quo

一开始有一些改良 libaio 的工作：

• If you can extend and improve an existing interface, that’s preferable to providing a new one.
• It’s a lot less work in general.

libaio 主要有三个接口：

• io_setup
• io_submit 用来提交一个 io
• io_getevents 用来等待完成，并收获结果

后面觉得，这种改良会把接口改得非常复杂，而且只能解决上面列出的一个问题。

3.0 New interface design goals

• Easy to use, hard to misuse.
• Extendable. 希望这个接口不止支持 block oriented IO。对于网络，和非块存储设备，它都能适用。
• Feature rich. Linux aio caters to a subset (of a subset) of applications. I did not want to create yet another
  interface that only covered some of what applications need, or that required applications to reinvent the same
  functionality over and over again (like IO thread pools).
• Efficiency. While storage IO is mostly still block based and hence at least 512b or 4kb in size, efficiency at those
  sizes is still critical for certain applications. Additionally, some requests may not even be carrying a data payload.
  It was important that the new interface was efficient in terms of per-request overhead.
• Scalability. While efficiency and low latencies are important, it’s also critical to provide the best performance
  possible at the peak end. For storage in particular, we’ve worked very hard to deliver a scalable infrastructure. A
  new interface should allow us to expose that scalability all the way back to applications.

4.0 Enter io_uring

首先是摘录作者的感言，性能必须从一开始，在设计接口的时候就考虑。

Despite the ranked list of design goals, the initial design was centered around efficiency. Efficiency isn’t something that can be an afterthought, it has to be designed in from the start - you can’t wring it out of something later on once the interface is fixed.

作者认为，新的设计要避免 submission 和 completion 事件在内核和用户空间之间的复制，也要避免 indirection，所以他由浅及深得出了下面几点：

1. 内核和用户空间需要 share 这些结构
2. 因此，这些结构应该在内核和用户的共享内存中
3. 因此，必须要去维护这里面的同步关系
4. 如果要用锁，那么就肯定会有系统调用，系统调用肯定 overhead 就大了
5. 因此，single producer single consumer ring buffer 是适合的

考虑到对于 submission 事件，用户是生产者，内核是消费者；而 completion 事件则相反。所以需要两个队列：SQ 和 CQ。

4.1 DATA STRUCTURES

cqe 的后缀表示 Completion Queue Event。

1
2
3
4
5
6

struct io_uring_cqe {
   // 从 submission 中透传过来
   __u64 user_data;
   __s32 res;
   __u32 flags;
};

sqe 则复杂很多

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

struct io_uring_sqe {
   // 操作类型，例如 IORING_OP_READV 表示向量读
   __u8 opcode;
   __u8 flags;
   __u16 ioprio;
   __s32 fd;
   __u64 off;
   // 指向内存地址，如果是向量读写，则指向一个 iovec array 的地址
   __u64 addr;
   // 表示长度，或者 iovec array 的长度
   __u32 len;
   union {
      __kernel_rwf_t rw_flags;
      __u32 fsync_flags;
      __u16 poll_events;
      __u32 sync_range_flags;
      __u32 msg_flags;   
   };
   __u64 user_data;
   union {
      __u16 buf_index;
      // 64 bytes 对齐
      __u64 __pad2[3];
   };
};

4.2 COMMUNICATION CHANNEL

SQ 和 CQ 的 indexing 是不太一样的，先从简单的 CQ 开始。

cqe 是一个内核和用户共享的 ring buffer，内核写会更新 tail，用户读会更新 head。ring buffer 的大小是 2 的幂，它的好处我在 Redis底层对象实现原理分析中有所解析。

如下所示，head 是可以自然溢出的。当然，正如我在 libutp源码简析或者ATP中的实现那样，当 tail 比 head 小的时候，我们也可以认为发生了溢出。
cqring->cqes 是被共享的结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

unsigned head;
head = cqring->head;
read_barrier();
if (head != cqring->tail) {
   struct io_uring_cqe *cqe;
   unsigned index;
   index = head & (cqring->mask);
   cqe = &cqring->cqes[index];
   /* process completed cqe here */
   ...
   /* we've now consumed this entry */
   head++;
}
cqring->head = head;
write_barrier();

SQ 这边，就是用户生产，内核消费了。之前说到，SQ 的 indexing 不一样，它是有个 indirection 的。submission 的 ring buffer 中存放了 index，索引到 sqe 中的位置。例如下面的例子中，提交顺序是：sqe5 → sqe2 → sqe3。

1
2

SQ array: [5, 2, 3]
SQEs:     [sqe0, sqe1, sqe2, sqe3, sqe4, sqe5]

在文章中，作者提出一个好处是可以将 request units 放到 internal structure 中，我理解就是后面看到的自定义的 app_sq_ring。另外，也能允许在一个操作中提交多个 sqe。我理解就是如下代码所示，先 fill sqe，再写 array 的操作。

1
2
3
4
5
6
7
8
9
10
11
12
13

struct io_uring_sqe *sqe;
unsigned tail, index;
tail = sqring->tail;
index = tail & (*sqring->ring_mask);
sqe = &sqring->sqes[index];
/* this call fills in the sqe entries for this IO */
init_io(sqe);
/* fill the sqe index into the SQ ring array */
sqring->array[index] = index;
tail++;
write_barrier();
sqring->tail = tail;
write_barrier();

只要 sqe 被内核消费了，application 就可以复用 sqe entry，即使内核还没有完全处理完毕，内核会在需要的时候复制这个结构。

这样，sqe 的生命周期就比较短，而 application 可能会发送更多的 submission，从而导致 CQ ring 可能溢出。所以默认下的 CQ ring 的大小是 SQ ring 的两倍。

Completion events 可能以任意顺序到达，它和 submission 的顺序是没有关系的。SQ 和 CQ 两个 ring 是独立运行的。但是每个 submission 事件和每个 completion 事件都能一一对应。

5.0 io_uring interface

下面介绍的是 io_uring 的“裸”接口，即 system call。

io_uring_setup

entries 的取值是 1..=4096，表示 sqe 的数量，必须是 2 的幂。

1

int io_uring_setup(unsigned entries, struct io_uring_params *params);

params 如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

struct io_uring_params {
   // 由内核填写，表示支持多少个 sqe
   __u32 sq_entries;
   // 由内核填写，表示支持多少个 cqe
   __u32 cq_entries;
   __u32 flags;
   __u32 sq_thread_cpu;
   __u32 sq_thread_idle;
   __u32 resv[5];
   struct io_sqring_offsets sq_off;
   struct io_cqring_offsets cq_off;
};

struct io_sqring_offsets {
   __u32 head; /* offset of ring head */
   __u32 tail; /* offset of ring tail */
   __u32 ring_mask; /* ring mask value */
   __u32 ring_entries; /* entries in ring */
   __u32 flags; /* ring flags */
   __u32 dropped; /* number of sqes not submitted */
   __u32 array; /* sqe index array */
   __u32 resv1;
   __u64 resv2;
};

io_uring_setup 返回的 int，实际上是一个 fd。如之前所说，这个 fd 是被内核和用户共享的。而 sq_off 和 cq_off 就表示了这共享内存中，SQ 和 CQ 的位置。

1
2
3

#define IORING_OFF_SQ_RING          0ULL
#define IORING_OFF_CQ_RING  0x8000000ULL // 128MB，指的那个 index 数组
#define IORING_OFF_SQES    0x10000000ULL

用户可以自定义 sq ring 的结构，这个结构中的每个字段都是一个指向到共享内存中位置的指针

1
2
3
4
5
6
7
8
9

struct app_sq_ring {
   unsigned *head;
   unsigned *tail;
   unsigned *ring_mask;
   unsigned *ring_entries;
   unsigned *flags;
   unsigned *dropped;
   unsigned *array;
};

如下面的 setup 所示，可以看到自定义的 sring 是如何通过 ptr 和 sq_off 组装起来的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

struct app_sq_ring app_setup_sq_ring(int ring_fd, struct io_uring_params *p)
{
   struct app_sq_ring sqring;
   void *ptr;
   ptr = mmap(NULL, p->sq_off.array + p->sq_entries * sizeof(__u32), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
   ring_fd, IORING_OFF_SQ_RING);
   sring->head = ptr + p->sq_off.head;
   sring->tail = ptr + p->sq_off.tail;
   sring->ring_mask = ptr + p->sq_off.ring_mask;
   sring->ring_entries = ptr + p->sq_off.ring_entries;
   sring->flags = ptr + p->sq_off.flags;
   sring->dropped = ptr + p->sq_off.dropped;
   sring->array = ptr + p->sq_off.array;
   return sring;
}

io_uring_enter

1
2
3
4
5
6

int io_uring_enter(
   unsigned int fd, // io_uring_setup 返回的那个 fd
   unsigned int to_submit, // tells the kernel that there are up to that amount of sqes ready to be consumed and submitted
   unsigned int min_complete, // asks the kernel to wait for completion of that amount of requests.
   unsigned int flags, 
   sigset_t sig);

可以发现，这个 syscall 可以同时 submit 和 wait for completion，这个也对应了本文作者之前提到的对 aio 的批评之一。

flags 中有一个参数，设置它，则内核会 actively wait for min_complete events to be available。简单来说，如果希望 wait for completion，则必须设置这个 flag。

1

#define IORING_ENTER_GETEVENTS (1U << 0)

5.1 SQE ORDERING

这一节主要讲了如何实现 fsync/fdatasync。

因为之前提到 SQ 和 CQ 是完全独立的，所以这样的机制需要额外的设计。并且因为写入是乱序的，所以我们在乎的是确定所有的写入已经完成。

io_uring 的机制是，支持 draining the submission side queue，直到之前的 completion 事件都已经结束。在这之前，application 会将后续写入入队。

通过 IOSQE_IO_DRAIN 这个 flag 来实现这个特性，它会 stall 住整个 SQ。因此，application 可以考虑使用多个 io_uring context，来保证不相关的写是并行的。

io_uring supports draining the submission side queue until all previous completions have finished. This allows the application queue the above mentioned sync operation and know that it will not start before all previous commandshave completed.

5.2 LINKED SQES

所有连续的指定了 IOSQE_IO_LINK 的 io 请求会被串联起来执行，这些请求一定是按照顺序执行的。但是它们和没有指定 IOSQE_IO_LINK 这个 flag 的请求之间的关系是不确定的。

5.3 TIMEOUT COMMANDS

6.0 Memory ordering

在 并发编程重要概念及比较 中，我们知道 memory order 主要是考虑读-写和写-写问题，如下所示：

read_barrier(): Ensure previous writes are visible before doing subsequent memory reads.
write_barrier(): Order this write after previous writes.

我们也知道，不同的 CPU 架构的乱序执行逻辑是不一样的，所以这里只是讨论概念。

考虑用户侧写入一个 seq，并且通知 kernel 可以去消费了。这就包含了两个过程：

• 填写 sqe 中的字段，并且将 sqe index 写入 SQ ring array
• 更新 SQ ring 队列的 tail

这个操作可以简化成下面的伪代码，每一行代表一个内存操作。如果没有合适的 memory order，CPU 是有理由进行乱序执行的。也就是说，无法保证 write 7 是在最后执行的。

1
2
3
4
5
6
7

1: sqe→opcode = IORING_OP_READV;
2: sqe→fd = fd;
3: sqe→off = 0;
4: sqe→addr = &iovec;
5: sqe→len = 1;
6: sqe→user_data = some_value;
7: sqring→tail = sqring→tail + 1;

所以，需要添加如下的 write barrier

1
2
3
4
5
6
7
8
9

1: sqe→opcode = IORING_OP_READV;
2: sqe→fd = fd;
3: sqe→off = 0;
4: sqe→addr = &iovec;
5: sqe→len = 1;
6: sqe→user_data = some_value;
 write_barrier(); /* ensure previous writes are seen before tail write */
7: sqring→tail = sqring→tail + 1;
 write_barrier(); /* ensure tail write is seen */

7.0 liburing library

通过这个库，可以：

• 不需要写一堆 boiler plate code
• 不需要考虑 memory ordering 的问题
• 不需要考虑自己维护 ring buffer 的问题

7.1 LIBURING IO_URING SETUP

8.0 Advanced use cases and features

8.1 FIXED FILES AND BUFFERS

8.2 POLLED IO

8.3 KERNEL SIDE POLLING

9.0 Performance

Reference

• https://man7.org/linux/man-pages/man2/io_submit.2.html

• LLM 的基础原理
• Transformer 的架构
• KVCache

基本来自于我的问题，以及我对通过 chat 学习到的东西的总结，由 AI 整理。完整版我放在腾讯文档中，这里选取一些方便摘录的写成博客。

LLM 的基础理论(AI Infra)

大模型的计算复杂度

Prefill 和 Decode

N 为上下文长度：

• 如果没有 KVCache，O(N^2)
• 如果有 KVCache，O(N)

O(N) 的原因：

• Prefill 阶段，需要拿一个 $N \times d$ 的 Query 矩阵，去乘以一个 $d \times N$ 的 Key 矩阵（$d$ 是维度）。这会生成一个 $N \times N$ 的注意力分数矩阵（Attention Map）。这个对应了“为什么当你扔进去一本 10 万字的小说，模型在吐出第一个字之前，会卡顿很久（首字延迟 TTFT 很高）。”
  • 当然，这里和 N_head 也有关系。每个 head 是单独算的。
• Decode 阶段，这里是 KVCache 的优化了。
  • 没有 KV Cache 的傻瓜做法： 假设模型要吐出第 $N+1$ 个词。如果没缓存，它必须把前面的 $N$ 个词加上新词，重新过一遍 $O((N+1)^2)$ 的计算。这显然极其愚蠢且缓慢。
  • 有了 KV Cache 的聪明做法： 因为前 $N$ 个词的 Key 和 Value 已经存在显存里了。对于第 $N+1$ 个词，模型只需要单独为这 1 个新词计算它的 Query（大小为 $1 \times d$）。
  • 数学本质： 此时的注意力计算，变成了拿这个 $1 \times d$ 的 Query 向量，去乘以缓存中 $d \times N$ 的 Key 矩阵。
  • 复杂度： 向量乘矩阵，计算复杂度瞬间从 $O(N^2)$ 暴降到了 $O(N)$！

两个耗时：

• TTFT (Time To First Token - 首字时间)： 衡量 Prefill（预填充） 阶段的耗时。即你按下回车，到屏幕上蹦出第一个字等了多久。

  • 优势： 它是高度并行的。现代 GPU 非常擅长干这种巨大的矩阵乘法，虽然计算量大，但 GPU 的几万个核心都在同时工作，效率极高。这被称为 Compute-bound（算力瓶颈）。

• TPOT (Time Per Output Token - 每输出词元时间)： 衡量 Decode（解码） 阶段的速度。即后续的字像吐牙膏一样，每个字蹦出来平均要多久。

  • 为什么耗时： 它必须是串行（Sequential）的！因为模型必须等第 1 个字出来，才能去算第 2 个字。在这个阶段，计算量虽然降到了 $O(N)$，但就像我们之前说的，为了算这 1 个新词，GPU 必须把显存里庞大的 KV Cache 重新搬运一遍到计算单元。
  • 劣势： 此时 GPU 的算力核心其实大部分时间在“闲置摸鱼”，它在等显存（HBM）把数据一点点搬过来。这被称为 Memory-bound（内存带宽瓶颈）。

• 场景 A：长输入，短输出（Prefill 耗时长）

• 场景 B：短输入，长输出（Decode 耗时长）

尽管如此，O(N) 依然是恐怖的：
当 $N$ 达到 1,000,000 时，即便只是单步 $O(N)$ 的计算，对于内存带宽的压力也是极其巨大的。因为你要为了这一个新词，把显存里 100 万个历史 Key 和 Value 全都搬运到计算单元里比对一次。这种现象叫做 Memory Bound（内存带宽瓶颈），此时 GPU 算力可能只发挥了 5%，剩下的时间都在等显存传输数据。

关于注意力头

在阅读大模型论文或源码时，经常会看到两个容易混用的“维度”概念：

• 模型的总维度 ($d_{\text{model}}$)： 这是模型在每一层之间传递数据的整体“宽度”。比如一个典型的 13B 模型，它的 $d_{\text{model}}$ 可能是 5120。
• 注意力头的维度 ($d_{\text{head}}$)： 因为大模型采用的是“多头机制（Multi-Head）”，它不会拿 5120 这么庞大的向量直接去算，而是把它“切分”给多个不同的“头”去并行计算，让每个头关注不同的特征。

它们的严格数学关系是：
$$
d_{\text{model}} = N_{\text{heads}} \times d_{\text{head}}
$$

例如，把 5120 的总维度分给 40 个头（$N_{\text{heads}} = 40$），那么每个头的维度 $d_{\text{head}}$ 就是 128。

PagedAttention

vLLM 是一个用于大语言模型（LLM）的开源高性能推理和服务引擎。vLLM 最具革命性的特性是 PagedAttention 技术：传统方法分配 KV Cache 像住宾馆，必须预留连续的、足够大的房间（连续显存），导致大量显存碎片被浪费。PagedAttention 借鉴了操作系统的虚拟内存机制，将 KV Cache 拆分成一个个极小的“内存页”（Block），按需分配，非连续存放。这几乎消灭了显存碎片，让系统能同时服务的用户数翻了好几倍。

架构层面：

• vLLM 就像是生产线上的“超级组装机”，负责飞速地计算和吐出 Token
• 3FS 则是紧挨着生产线的“超高速立体仓库”，专门负责存放那些流水线上放不下的半成品（KV Cache）。
  vLLM 本身自带了前缀缓存（Prefix Caching）功能，但这通常局限在单台服务器内部。3FS 的目的是全局视角的缓存共享。

PagedAttention 是如何实现的，如下其实还是比较传统的：

• 它将每个用户请求的 KV Cache 划分成固定大小的“块”（Block）。每个块不再是以字节（Byte）为单位，而是以 Token 数量为单位（默认通常是 16 个或 32 个 Token）。
• 逻辑与物理分离 + 维护块表（Block Table）

不同点：

• OS 是以 Bytes 为基础。PA 以 Token 为基础。一个 Block 占用多少显存，取决于模型的层数、注意力头数和数据精度。例如，在 Llama-2 13B 模型中，一个 16-Token 的 Block 可能占用几兆字节（MB）的显存。
• 访问模式不同：OS 是随机访问多。PA 是可预测的，大模型的文本生成（自回归）是严格按顺序追加（Append-only）的。模型永远是一个词一个词往后吐，KV Cache 只会顺着时间轴往后写。
• 触发 offloading 的时机不同：OS 就是缺页中断。vLLM 是在应用层（框架层）预测显存够不够。如果不够了，vLLM 会主动把一些 Block 踢到系统内存（Offload），这被称为抢占（Preemption）或重计算（Recomputation），完全由软件逻辑控制。

那么如何利用这个特性？

• 减少碎片
  • 消灭内部碎片： 一个物理块一旦分配，模型就会按顺序把它填满。除了当前正在生成的最后那个未填满的 Block，所有已分配的 Block 的空间利用率都是 100%。
  • 消灭外部碎片： 因为物理块在显存中是不连续的，只要显存里还有任何一个空闲的 Block，就可以立刻分配给任何请求。这让显存的整体利用率从传统方案的 20%-40% 瞬间飙升到了 90% 以上。
• 由于 PagedAttention 是纯软件层面的控制，它拥有“全局视野”。所以它可以选择重新计算，还是 offload 到 3FS 中。

Hybrid Sparse Attention

DeepSeek（特别是在其最新的 V4 架构中）采用的 Hybrid Sparse Attention，是从算法数学层面下刀，它混合了多种注意力策略来“偷懒”却不掉精度：

• 滑动窗口注意力 (Sliding Window Attention, SWA)： 对最近的一小段上下文（比如最近 128 个 Token），采用全量密集注意力，保证局部的绝对精确。
• 压缩稀疏注意力 (Compressed Sparse Attention, CSA)： 对远古的历史上下文，它不再让当前 Token 和所有历史 Token 一一比对，而是利用轻量级的“索引器（Indexer）”挑选出最相关的 Top-K 个 Token，只计算这部分极其重要的记忆，其余的直接忽略（稀疏化）。
• 重度压缩注意力 (Heavily Compressed Attention, HCA)： 把极其冗长的历史记录，像打“压缩包”一样，将多个 Token 融合压缩成少量的特征向量，提供一个全局视角的模糊记忆。

vLLM 和训推存储底座

vLLM 并没有完全撒手不管“存”。它管理最宝贵、最快的 GPU 显存（HBM）。一旦发现显存快满了，就立刻把暂时不用的 KV Cache 通过超高速网络（如 RDMA）卸载给 3FS。
RDMA（Remote Direct Memory Access，远程直接内存访问）是一种无需计算机操作系统内核接入、无需CPU参与，即可直接在两台机器内存之间读写数据的网络技术。它通过内核旁路（Kernel Bypass）和零拷贝技术，实现了高吞吐量、低延迟和低CPU占用的网络传输，适用于高性能计算和大数据中心。
RDMA 编程通常基于 Verbs API (如 libibverbs) 进行，核心流程是建立连接并交换内存地址信息，随后进行直接读写。

• 内存注册 (Memory Registration, MR)： RDMA 必须先将应用内存区域（Buffer）注册到网卡，锁定物理地址，并获取远程访问的键（R_Key）。
• 队列对 (Queue Pair, QP)： 每个RDMA应用通过QP通信，包括发送队列（SQ）和接收队列（RQ）。
• 工作请求 (Work Request, WR)： 应用通过WR提交发送/接收指令给网卡。
• 完成队列 (Completion Queue, CQ)： 网卡完成传输后，将完成结果放入 CQ，应用通过轮询 CQ 获取结果。

这套机制的作用：

• 独立扩容：vLLM 加显卡，3FS 加 SSD
• 无状态的 vLLM
• 多级缓存：VRAM（显存） -> DRAM（内存） -> 3FS（高速网络 SSD）

前缀

关于前缀

1. 最佳实践：调整 Prompt 结构（把“死”的放前面）
   1. 失效做法： [用户闲聊] + [系统指令] + [长财报]（用户一换，缓存全崩）。
   2. 优化做法： [长财报] + [系统指令] + [用户闲聊]。
2. 基数树（Radix Tree）管理机制
   1. 如果你的输入是 A + B（A 是闲聊，B 是财报），它会先找 A 的缓存。
   2. 虽然它发现 A + B 不能直接复用 C + B 的缓存，但如果系统发现大量请求都有共同的 B，它会尝试在内部进行“多级缓存”匹配。
3. 针对位置编码的魔改：相对位置编码（RoPE）与偏移
4. DeepSeek 的特殊方案：跨序列的注意力（Multi-Head Latent Attention）

距离和位置编码

LLM 对“距离”的感知是弱结构化、统计性的，而不是显式离散结构化的：

1. Transformer 本质上是“全连接注意力”

   1. 任意 token 都可以直接看到任意 token
   2. 不像 RNN 那样必须一步一步传递
   3. 所以模型天然没有“近的更近、远的更远”这种 inductive bias
   4. 如下所示，A attention 到 B 和 E 的距离是一样的

      1

      A B C D E

2. Position Embedding 只是“补充位置信息”
   因为 attention 本身没有顺序概念，所以必须人为加 position encoding。诸如 token_embedding + position_embedding 或者 RoPE 等都是一种形式。

3. 它“知道顺序”，但不是算法式知道

   1	Tom gave Jerry a book because he trusted him.

   大模型能够语义地知道 Tom 这里是 he。但是它不是通过 Tom – he，Jerry – him 这样的位置对应关系知道的。

随着上下文变长：

• nesting depth 增大
• distribution shift 出现
• 模型就容易崩

这也是下面这些比较难做的原因：

• long-context reasoning
• counting
• exact matching

Lost in the Middle 问题

指的是 Transformer 对“长距离结构”和“中间位置”缺乏稳定位置感的一种表现。

Transformer

Attention 机制

NLP 对 token 序列 X 的三种编码方式：

• RNN
  RNN 是递归的结构，所以只能串行计算。

  1	y_t = f(y_{t-1}, x_t)

• CNN
  CNN 能够并行计算，但是因为引入了窗口，所以只能看到局部信息。

  1	y_t = f(x_{t-1}, x_t, x_{t+1})

• Attention

Q、K、V

从定义上看，对于 token 流

1

x1, x2, x3, ... xn

每个 xi 通过三组线性变换生成：

1
2
3

Qi = xi * Wq
Ki = xi * Wk
Vi = xi * Wv

考虑下面的句子

1

The animal didn’t cross the street because it was too tired.

句子中的每一个 token，都有一个自己的 Q。用 Wq 可以提取出这个 Q，如下：

• animal → 它在问：后面有没有补充信息？
• because → 它在问：因果关系是什么？
• it → 它在问：我指的是谁？
• tired → 它在问：谁在 tired？

对于 K，则告诉了这个 token 可以回答什么样的 Q：

• animal → 我是一个名词、可能是指代目标
• street → 我是一个地点名词
• because → 我是因果连接词
• tired → 我是状态形容词
• cross → 我是动作

对于 V，承载了语义信息的本体：

• animal → 动物这个实体的语义
• street → 街道的概念
• tired → 疲劳的状态语义
• cross → 穿越动作

Self-Attention

Self-Attention 指的是 Q、K、V 都来自同一组 token 的 attention。即

1
2
3

X → Q = XWq
X → K = XWk
X → V = XWv

然后

1

Attention(Q, K, V)

为什么叫 Self？

• 不是去外部文档查
• 不是去另一段文本查
• 而是在自己这段序列内部相互对齐

对应的是 Cross-Attention：

• Q 来自 Decoder
• K/V 来自 Encoder

容易发现，Cross-Attention 更适合翻译或者对齐另一段文本。而 Self-Attention 更适合理解一句话内部关系。

Multi-Head Attention

如果一个 token 同时想问多种不同类型的问题怎么办？引入多组问题呗。所以上面的三个矩阵会变成三组矩阵。

1
2
3
4

Wq¹ Wk¹ Wv¹
Wq² Wk² Wv²
Wq³ Wk³ Wv³
...

还是对上面的例子而言

对 it 这个 token：

• Head1 问“我指代谁？”，会关注 animal（指代）
• Head2 问“是否有因果关系？”，会关注 because（因果）
• Head3 问“我与哪个动词相关？”，会关注 cross（动作）

KVCache

Why

Token 是模型处理文本的最小离散单位。所以 LLM 并不是直接处理文字，而是直接处理 token。Token 是通过分词器从文本切出来的子串单位。

1

"Hello world" → [15496, 2159]

但是

1
2

"refund" = 1 token
"refunding" = ["refund", "ing"]

不同的模型能够接受不同的上下文长度，因此，它们的 KVCache 也要更大：

• GPT-3.5 4k tokens
• GPT-4 8k / 32k
• Claude 100k

那么 token 是不是特指用户 prompt输入的 token 或者模型输出的 token 呢？其实根据下面的自回归生成，这两个是一个东西。

1

prompt1 → prompt2 → prompt3 → output1 → output2 ...

自回归生成:模型按顺序生成 token，每个 token 都只依赖之前已经生成的 token。
例如，下面的 token 序列中，x1 到 x3 是用户的 prompt 输入

1

x1 → x2 → x3 → x4 → ... → xT

则 xT 生成的方式是

1

P(x_t | x_1, x_2, ..., x_{T-1})

由此可见，自回归生成导致推理是串行的。为什么要自回归生成呢？原因比较深入，可以理解为：

• 语言本质是序列，唯一通用可行的分解方式就是 chain rule
• 自回归训练极其稳定
  输入是前缀，目标是预测下一个 token，loss 是交叉熵。不需要强化学习。
• 从历史演化角度来看，n-gram、RNN、LSTM 等都是自回归的

因为自回归生成，所以导致了 KVCache 的出现。KVCache 把 O(n²) 变成 O(n)。

KVCache 具有如下的形式：

1

KVCache[layer][token_index] = (K, V)

• layer 是 Transformer 架构的层
  现在的 LLM 大都是 Decoder only 的架构，所以这里的层如下所示。

  1 2 3 4 5 6 7 8 9 10 11 12 13

  Input tokens ↓ Embedding ↓ Decoder Block 1 ↓ Decoder Block 2 ↓ ... ↓ Decoder Block N ↓ LM Head

  不同层的 schema 都不同：

  • 第一层：按字形索引
  • 中间层：按语法索引
  • 高层：按语义索引

  每一层内部包含：

  • Masked Self-Attention
    让每个 token 从历史 token 中选择性地读取信息。
    当前 token 只能看到自己和之前的 token，不能看到未来的 token。
  • FFN
    这里就是前馈神经网络，目的是在单个 token 维度上做语义升维和重映射。可以看成是在理解输入的 token。
  • Residual / Norm

• token_index 表示这是第几个 token
  因为 attention 在第 t 步需要：当前 token 的 Q、对比所有历史 token 的 K、加权读取所有历史 token 的 V。所以这些 K 和 V 需要按照 token_index 来存储。

• K 和 V
  K 是我提供什么信息给别人关注。
  V 是别人关注我时能读到什么内容。

• 为什么不需要缓存 Q？
  因为 Q 只在当前步骤被使用。
  在第 t 步，会用 Q_t 去访问 K_{0..t-1}, V_{0..t-1}。但是在未来，不会再去访问 Q_t 了。

如果没有 KVCache，每生成一个新 token 需要重新计算所有历史 token 的 K/V 复杂度是 O(n²)

Reference

• https://zh.d2l.ai/chapter_attention-mechanisms/attention-cues.html
• https://transformers.run/c1/attention/
• https://zhuanlan.zhihu.com/p/338817680

如果要在不可变数据结构上进行修改，就需要 clone 一份出来。因此：

• 对于一些较大的结构，希望能够尽量复用
• 如果此时只有一份引用，则可以直接获取 mut 引用就地修改

所以有了 Persistent data structures 的概念：

• 每一次修改该结构，都会保留之前的版本
• 历史的版本可以被查询
• 如果历史版本的数据也支持修改，则称为 Full persistence，否则称为 Partial persistence

实现方案

Copy on Write

用一个数组存放所有的历史版本，非常 bruteforce。

Fat node

为每一个 field 维护历史记录。例如

1
2
3
4
5

struct Node {
    int value;
    Node* left;
    Node* right;
}

会变成

1
2
3
4
5

struct FatNode {
    vector<Pair<version, value>> value_history;
    vector<Pair<version, Node*>> left_history;
    vector<Pair<version, Node*>> right_history;
}

查询的过程就有点像是 MVCC 了。给定一个 version，去 lower_bound 找到最大的小于 version 的修改。

容易看到，Fat node 不支持 Full persistence。

Split

Fat Node 不能无限制增长，否则：

• 历史太长
• 查询复杂度上升
• 节点缓存局部性变差

因此，需要将节点 split 为两个节点：

• 新节点记录最新版本的值
• 老节点保留早期历史
• 结构中指向该节点的指针，也在相应版本中被更新为指向新的节点

Path copying

常见的结构实现

List

Vec

Reference

• https://github.com/orium/rpds

read、write 接口

从普通文件 read，涉及两次复制：

• 从磁盘通过 DMA 读到内核的 page cache
  这里的 page cache 机制也是一种 kernel buffer，但专门提供给磁盘文件的。
• 从内核的 page cache 复制到 user buffer

从套接口读数据：

• 从网卡通过 DMA 直接写入 kernel buffer
• 从 kernel buffer 复制到 user buffer

注意，在使用 DMA 之前，磁盘读出来的数据会放到一个寄存器里面，然后通过中断通知 CPU 把数据写到临时的内存中攒批，最后写到 page cache 中。但是该方式性能太差，早已经淘汰了。

读数据过程：

• 调用 read() 函数陷入内核，第一次 context switch
• DMA 控制器将数据从磁盘拷贝到 kernel buffer，这是第一次 DMA 拷贝
• CPU 将数据从 kernel buffer 复制到 user buffer，这是第一次 CPU 拷贝
• CPU 完成拷贝之后，read() 函数返回到用户态，第二次 context switch

写过程类似。

mmap

把 kernel space 的页映射到 user space，所以可以避免从 kernel space 到 user space 的一次复制。
关于 mmap 可以见 内存领域知识。

sendfile

原始 sendfile

sendfile 将数据从磁盘读到内核的 page cache，然后将 page cache 复制到 socket 的 buffer 中。

它的好处是减少了 syscall 的次数。将 read + write 或者 mmap + write 打包了。
但是，仍然需要 2 次 DMA 拷贝和 1 次 CPU 拷贝。

sendfile + DMA 优化

将从 page cache 到 socket buffer 的那一次 CPU 拷贝去掉了。DMA 可以直接从 page cache 拷贝数据到网卡里面。

splice

限制是 fd_in 和 fd_out 中，至少有一个是 pipe：

• 如果 fd_in 是 pipe，那么 off_in 必须是 NULL
• 如果 fd_in 不是 pipe，且 off_in 是 NULL，那么 bytes are read from fd_in starting from the file offset, and the file offset is adjusted appropriately.
• 如果 fd_in 不是 pipe，且 off_in 不是 NULL，off_in must point to a buffer which specifies the starting offset from which bytes will be read from fd_in; in this case, the file offset of fd_in is not changed, and the offset pointed to by off_in is adjusted appropriately instead.

这里解释一下什么是 linux 中的管道：

• 匿名管道（anonymous pipe）
  由父进程创建，用在具有亲缘关系的进程之间通信。
  通过 pipe() 系统调用创建，返回一对文件描述符：一个用于写，一个用于读。
  只存在于内存中，它不是一个磁盘上的文件，不能用 ls 查看，也没有 inode 号。
• 命名管道（named pipe，也叫 FIFO）
  具有名字的管道，可以存在于文件系统中，有路径。文件类型是 p，代表 pipe。
  通过 mkfifo 命令或者 mkfifo() 系统调用创建。
  可以实现非亲缘进程之间的通信。

所有的匿名管道都支持 splice，通常借助匿名管道来实现 zero copy。此时，pipefd 就起到了中转管道的作用，它连接了两个彼此之间不支持零拷贝的 fd。我觉得是一个比较有意思的设计，通过匿名管道的中介，减少了不同 fd 之间实现相互 zero copy 的复杂度。

1
2

splice(file_fd, NULL, pipefd[1], NULL, len, 0);
splice(pipefd[0], NULL, socket_fd, NULL, len, 0);

一些命名管道也支持 splice，但是可能只是可读写，非零拷贝中转。

1
2
3

ssize_t splice(int fd_in, off_t *_Nullable off_in,
              int fd_out, off_t *_Nullable off_out,
              size_t size, unsigned int flags);

Flag 如下：

• SPLICE_F_MOVE
  Attempt to move pages instead of copying. 这里的 move 指的是内核页缓存中的物理页面的引用在 fd 之间进行转移。而不需要读出、复制到 user space、写入这样的流程了。
  注意，这个 flag 只是一个 hint。如果内核无法移动，则还是需要复制。如果 pipe buffer 不指向整个页面。
  The initial implementation of this flag was buggy: therefore starting in Linux 2.6.21 it is a no-op (but is still permitted in a splice() call); in the future, a correct implementation may be restored.
• SPLICE_F_NONBLOCK
  Do not block on I/O. This makes the splice pipe operations nonblocking, but splice() may nevertheless block because the file descriptors that are spliced to/from may block (unless they have the O_NONBLOCK flag set).
• SPLICE_F_MORE
  More data will be coming in a subsequent splice. This is a helpful hint when the fd_out refers to a socket (see also
  the description of MSG_MORE in send(2), and the description of TCP_CORK in tcp(7)).
• SPLICE_F_GIFT
  Unused for splice(); see vmsplice(2).

vmsplice

splice 主要是服务内核空间中的数据传输，原因是指定的都是 fd 或者 pipe，并不包含用户空间中内存的信息。
而 vmsplice 主要服务用户空间和管道之间的数据读写，它们都能实现零拷贝。

1
2
3
4
5

#define _GNU_SOURCE         /* See feature_test_macros(7) */
#include <fcntl.h>

ssize_t vmsplice(int fd, const struct iovec *iov,
                size_t nr_segs, unsigned int flags);

iov 是一个长度为 nr_segs 的数组，表示用户内存中的多段可能不连续的 buffer。

参数：

• SPLICE_F_MOVE
  Unused for vmsplice(); see splice(2).

• SPLICE_F_NONBLOCK
  Do not block on I/O; see splice(2) for further details.

• SPLICE_F_MORE
  Currently has no effect for vmsplice(), but may be implemented in the future; see splice(2).

• SPLICE_F_GIFT
  The user pages are a gift to the kernel.
  表示用户程序不会修改这段 buffer，否则，page cache 和磁盘中的数据就可能不一致。
  将 pages gifting 给内核意味着后面的 splice SPLICE_F_MOVE 能够成功移动 pages。如果不指定，则后续的 splice SPLICE_F_MOVE 必须复制。
  数据必须要 page aligned。我理解这里指的是：

  • iovec[i].iov_base 需要对齐到页
  • iov_len 需要是页大小的整数倍

  如果不满足，则退化到 copy 的行为。

Reference

• https://man7.org/linux/man-pages/man2/splice.2.html
• https://man7.org/linux/man-pages/man2/pipe.2.html

One of the most notable aspects of this project is that it has been developed alongside the rapid evolution of AI agents, which led us to encounter many pitfalls when practicing vibe coding.

About Vide Coding: The benefits and the pitfalls

Pitfalls of Vibe Coding

In early 2025, at the initial stage of our project, one of our core contributors quickly prototyped a demo using Cursor, covering multiple modules such as the read scheduler, index writer, and meta service.

Traces of this early implementation can still be found in the following pull requests:

• https://github.com/pingcap-inc/tici/pull/48
• https://github.com/pingcap-inc/tici/pull/673

Make AI agent more focused

Why focused attention matters

Agents have a limited attention budget. When a prompt blends background, implementation details, and review notes, attention is spread thin and the model drifts. Treating the prompt as code and slicing the work into sub goals keeps the highest-signal spec in focus, which improves determinism, reduces requirement misses, and lowers evaluation cost.

How to draw attention of AI agent

We can treat prompt as code. This is not a new idea in the industry, but many teams apply it unevenly. A common practice is to store prompts as markdown or templates under version control, so they can be reviewed, diffed, and rolled back like any other artifact. Some teams go further and build a “prompt registry” or config service to version prompts outside the codebase, and pair it with evaluation suites that act like unit tests for prompts (golden outputs, A/B runs, regression checks). Others embed prompts directly in application code as constants, which makes deployment easy but tends to hide intent and lose reviewability. The shared direction is clear: treat prompts as first-class assets with explicit structure, reviews, and tests.

I wrote a PR, https://github.com/pingcap-inc/tici/pull/692/files, where the core file(I name it spec), is prompts/0001-gc-cdc.md. That file is the prompt itself, and it is committed with the PR, so anyone can start a session by loading the same prompt. It becomes versioned, diffable, and reviewable like real code, and the team no longer depends on a hidden chat history. Also, we can divide the whole goal into several sub goals and let AI agents to implement different sub goals sequentially or in parallel. And we don’t need to tell the AI the context everytime.

I think this can effectively make the AI agent more focused on what it needs to do, so as to generate bettwer codes with less resources.

Reviewers can write feedback directly in the Reviews section of the prompt doc, and I can pull that back into the next round of vibe. This workflow makes context length much less of a concern because the prompt is the canonical spec. A minimal shape looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// The content of a spec file
# Goal

...

## Sub goal 1

In this sub goal, you need to ...

### Programming Style

### Musts

### Tests

## Reviews

This spec file can be compacted automatically during refactors.

Rust as the language of “Vide Coding Era”?

As Rust becomes increasingly adopted in the “vibe coding era”, it does offer stronger guarantees against concurrency and memory errors. However, it is still too early to say that Rust is THE ONE.

Such an AT-Agent native language will likely consist of at least three distinct sub-languages:

• One for expressing intent
  This is the most critical language, because Developers need a more efficient way to understand what AI agents have actually done.
• One for validating correctness, or so called DoD definition
  The language corresponds to the intent language, and is designed to describe test workflows more efficiently. Developers and Reviwers can fine-tune this part of the code to guide AI agents to generate correct code for corner cases.
• One for concrete implementation
  This language is responsible for concrete implementation. Many AI agents, such as Codex, can already handle this layer well, as they rarely make trivial mistakes. Developers do not need to review this part of the code frequently, as other AI agents can handle the review instead.

Only with this separation can we truly balance readability, robustness, and long-term maintainability. Furthermore, many of the current libraries can be rewritten to be more friendly to AI agent.

The /goal command

此后，大多数 agent 都提供了 /goal 这个功能，其目的也是为了强化目标驱动；

1
2
3
4
5
6

human writes steps

==>

human specifies outcome
agent searches for path

不过，/goal 将我们需要的语言展示得更为具体了。

Use Skills

I introduced several SKILLs into our new project. For example, ManualTest enables AI agents to execute manual test cases automatically.

Implement tests

Hierarchy of tests

The problem

Because each TiDB component is maintained in a separate repository, breaking changes in one component require coordinated adaptations across multiple repositories. Unfortunately, such adaptations cannot be performed atomically and are often non-trivial. While compilation flags or configuration options can sometimes be used to temporarily disable new features, this strategy is not always applicable. In particular, interface changes such as FFI definitions may break compatibility immediately.

In our project, an end-to-end (e2e) test starts a full cluster and asserts it from a client’s perspective, which in our case means sending SQL queries to the database service. Some of these tests are included in our CI pipeline. However, CI-based e2e tests cannot reliably detect adaptation issues. This creates a classic catch-22: resolving an adaptation problem requires updating all related components, yet the e2e tests cannot pass while you are still fixing the first component. As a result, most e2e tests are deferred to what we call the “daily tests”.

Nevertheless, we still need a subset of e2e tests in the CI pipeline. Although these tests may occasionally produce false positives due to compilation or adaptation issues, they provide valuable systematic checks to ensure that a new commit in one component does not break existing rules or behaviors. Deferring such checks to daily tests would be disastrous, as it makes bugs significantly harder to triage. When issues accumulate over time, the project can easily fall into a “bug jail,” where fixing new problems becomes increasingly expensive.

It is also worth noting that integration tests cannot practically detect all logical bugs. In many cases, module owners write integration tests mainly to verify that their own modules work with others, while overlooking the impact their changes may have on the system as a whole. This issue becomes even more critical when AI agents are used to refactor our code, as we need safeguards to ensure that unexpected behavior does not compromise the foundation of the project.

During the development and PoC stage of our project, several critical issues occurred because the tests were not correctly implemented, including:

• Module A uses the API of Module B in a wrong way. Neither is there integration test of Module A, nor its scene is covered in the e2e test.
• Module C fails to verify a corner case, which is later caught by my embedded e2e test (introduced later). This kind of error is easy to be ignored, because it passes all tests except one. However, that single test protects our system from an availability failure caused by a deadlock in Module C.
• Another component changed its convention for constructing a field in an RPC request without informing us, which caused the system to malfunction at the SQL layer and made the issue difficult to investigate. This problem was also detected by my embedded e2e test.

The layers of tests

We can organize the tests for Component A into several layers. Each layer targets specific categories of bugs, and issues detected at lower layers should not propagate to higher layers.

• Daily regression: full system tests for cross-component compatibility only. However, no bugs originating from Component A itself should reach this level. We must proactively investigate daily test failures to avoid falling into a bug jail.
• E2e tests with real components: We may occasionally allow skipping tests at this layer, because cross-component checks can fail due to upstream changes, as discussed earlier. However, bugs that originate within Component A itself must not propagate to this level.
• Integration tests:
  • Embedded e2e: at the component boundary, using mocked RPC/status/FFI calls; required when interface semantics change; validates external behavior and isolates compatibility issues.
  • Module integration: per-module behavior with or without mocks; required for new features or refactors; may need test framework enhancements.
• Unit tests: unit or local integration tests within a single module; most of these can be handled by AI agents.

The embeded e2e test

This idea is based on the observation that a component’s behavior is defined by how it communicates with other components, through RPC, FFI, shared memory, and similar mechanisms.

Therefore, mocking these communications in integration tests provides the following benefits:

• We don’t need to start a full cluster, so we won’t face the adaption problem.
• If an adaptation issue occurs, it can be easily reproduced at this level. This not only simplifies the debugging process, but also increases our confidence in the code.
• This test treats our program as a black box, which makes it easier to implement because we do not need to understand how each module is implemented. These tests are expected to remain stable unless the interfaces or communication frameworks change.

Tests as the Backbone of Vibe Coding

In a Vibe Coding workflow, tests become the primary communication channel between intention and code. Among all types of tests, the embedded end-to-end (e2e) tests play a more and more important role.

Unlike unit tests, which specify local behavior, or integration tests, which usually verify a limited subsystem, my embedded e2e tests define system-level behavioral contracts. They describe what the system should do rather than how it should do it. This makes them naturally aligned with Test-Driven Development (TDD): they serve as executable specifications that drive the implementation.

Systematic choices

Thread or coroutine?

Benefits of using tokio:

• Smaller memory cost, so we can create more coroutines.
• Context switch is faster because there is no syscall.

Pitfalls of using tokio:

• We cannot control the scheduling strategy of tokio’s runtime. For example, we cannot assign a priority to a specific task, nor can we limit the CPU quota of a particular class of tasks.
• Switching to async code is often painful, as even the simplest function may become suspendable due to the use of tokio::sync locks.
• It is hard to investigate deadlock / starvation problems.
• Hard to use itertools. futures::stream can help, but it generates complex types.

Use seperated Runtime for different task pool?

Runtime can only be created outside the “async context” of tokio. So if we need to use tuned Runtimes, we have to create them in advance. This involves lots of refactors.

Propagate the panic outward

We must pay attention to panics inside the actor’s message loop: the handler, whether a thread or a coroutine, will only surface the panic when it is eventually joined, by which time the failure may have gone unnoticed for too long. What I recommend is to:

• Employ the panic_hook to capture the exact scene where things go wrong.

  1 2 3 4

  panic::set_hook(Box::new(|info| { eprintln!("Task panicked: {}", info); println!("Task panicked: {}", info); }));

• Eliminate unwraps and expects

  1 2	#![cfg_attr(not(test), deny(clippy::unwrap_used))] #![cfg_attr(not(test), deny(clippy::expect_used))]

Shared Memory or Actor model?

If we use the coroutine runtime, we may need to decide how to handle race conditions.

Why are “deadlock”s so hard to diagnose when using coroutines?

1. There is neither a wait-for graph in the coroutine runtime nor one in the OS
   await does not block a thread, so we can’t find anything with gdb/strace/perf.
   Meanwhile, these “deadlocks” are hard to be detected because they appears that there is no CPU, no blocking thread, and the program is in a “vegetative state”.
   Coroutine frameworks like tokio provides some o11y tools, however, they are hard to use, and have performance overhead.
2. No actual “deadlock”
   These stalls are mostly “waiting for a train at a bus stop” errors. For example, we may read from a channel which will never be written, which is an easy mistake when we bail on an error without calling .send() first.
   So we recommend to send a Result<T>, and implement a Drop trait that automatically sends Err(Error::DropWithoutReport) as a last-minute remedy.
3. No actual “stack”
   Coroutines don’t carry a real stack. When they hit an await they yield a continuation, and that continuation may be resumed on the same or a different thread.

tokio::RwLock or std::sync::Mutex?

There is a public belief that we have to always use tokio locks in asynchronous code. However, according to the reference of tokio, it is ok and better to use synchronous locks such as std::sync::Mutex or parking_lot::Mutex.

I’d like to refer to these cases as “atomic access structures”, because they all follow the following patten:

1
2
3
4
5
6
7
8
9

struct Wrapped {
    inner: Mutex<String>,
}

impl Wrapped {
    pub fn change_inner(&self, s: String) {
        self.inner.lock().expect("") = s;
    }
}

The key point of this code is to avoid directly exposing the lock itself: we must not allow external callers to access it, and we must atomically release the lock after mutating the protected value. The underlying rationale is that we must not allow a coroutine to “sleep” while holding the lock, as this guarantees that no deadlocks will occur, because:

• If a coroutine holds the lock, it will not “sleep”, because the code change_inner is structured to avoid calling .await while the lock is held. Moreover, the executor thread will not sleep either, since it is not waiting on any condition.
• If a coroutine does not hold the lock, it can eventually acquire it, because the current holder will release the lock promptly. And of course, the lock is released before any suspension point.

For synchronous lock:

• std::sync::Mutex supports poisoning. If a thread panics while holding the lock, future lock() calls return a PoisonError, forcing the caller to acknowledge that the protected state may be inconsistent. However, in most cases such an error can’t be processed, it will eventually lead to a panic, which is not elegant. There are also some other choices, simply accepting the risk is similar with parking_lot::Mutex, and resetting the state is not hazard if there are other threads waiting for this lock.
• parking_lot::Mutex is faster and smaller in many workloads (especially uncontended or lightly contended), but it does not poison. This often turns a hard failure into a latent, harder-to-debug corruption.

The lack of poisoning is exactly why parking_lot::Mutex can be unsafe at the logic level. If a panic happens after partially mutating the protected value, the invariant is already broken. So, unless you can guarantee panic-free critical sections or have a clear recovery path, prefer the standard mutex to make invariant breaks visible. I think the best practice is to abort if any thread panics, which can be easily done with panic hooks.

Implementing an “incomplete” actor mode

In the traditional actor model, each actor node encapsulates its own private data. However, this model is difficult to implement because:

• To rebalance data across nodes, we must introduce new message types and corresponding handlers.
• Inspecting the internal state of actor nodes is difficult.

So, as a simpler alternative, we can:

• Use a concurrent hash map to store all data, with each actor node mutating a portion of the map.
• Allow other components to read or inspect entries in the concurrent hash map. Such inspectors can not mutate the entries, and their accessment must be atomic.

A preferred candidate for the hash map is DashMap. Although this structure frees us from requiring &mut self, most of its methods return a Ref or RefMut that holds a lock guard, so incorrect usage can lead to deadlocks. The following codes shows a simple example.

1
2
3
4
5
6
7
8
9
10
11
12
13

#[test]
fn test_dashmap() {
    let map = DashMap::new();
    map.insert(1, 1);
    map.insert(2, 2);

    for entry in map.iter() {
        println!("{} -> {}", entry.key(), entry.value());
        map.insert(3, 3);
    }

    println!("test end");
}

There is a simple yet effective way to detect potential issues in our code: use #[tokio::test] instead of #[tokio::test(flavor = "multi_thread")]. With the single-threaded runtime, the program will fail immediately if a coroutine “sleeps” while holding a lock.

The linking problem

FFI

TODO

How to support TLS?

TODO

Online config change

There are some ways to update configs without restarting the program:

• For every actor, introduce a new UpdateConfig event, and handle it in the message loop.
• Using arc_swap.

I don’t think the service itself should persist the updated configuration to the config file. Instead, this should be handled by the operator.

Day 1

主要修正了下反手动作。

这里，我最重要的是不要架肘。打的时候，可以用左手稍微按着一点左边的大臂。
然后，乒乓球反手是小臂带动大臂，大臂基本上不用特别发力，而是让小臂画 1/4 的圆弧。
在打完之后，需要还原。击球时，击球点不要太到台内，仿佛把整个手都要伸出去一般。
击球的是高点期。注意，不要急，而是等球到位之后再打，实际上质量更好。
当球落点朝着左边或者右边偏斜的时候，可以考虑靠只移动上半身来接。
作为初学者，不需要手腕有特别大的扭转。

-> 初学者，可以采用下蹲马步，然后再站起来这样。但是最终，是要一直处于一种扎马步的状态，主要是前脚掌着地。然后用一些垫步还是啥的完成重心转换。

Day 2

主要纠正了下正手动作。

我正手有几点问题：

• 撅手腕，教练说撅着手腕可能是因为击打点太靠前，以至于要“等球：
• 大臂架着
• 大臂还喜欢架着往后拉，实际上应该是转腰，而不是动大臂
• 握拍应该虎口直接对着拍子的“侧棱”，类似于羽毛球一样，我可能会喜欢转一点

Day 3

继续是正手和反手的练习，下雨，只有 1.5h。

提到了一些细节：

• 反手可以尝试蹲起，然后站立这种击打方式

录制了一些视频，视频中可以发现，还是喜欢撅着手腕。

Day 4

继续是正手和反手的练习，有事，只有 1.5h。

Aug 21

纠正拉手问题：

• 拉手是肘往后牵引，这个要注意避免。如果拉手，那么正手打出的球可能带有侧旋
• 可以考虑自己夹着一个矿泉水瓶来打正手，能减少拉手问题。

Sep 4

强调转胯的作用：

• 是那种压着腹股沟的感觉
• 要通过转胯而不是拉手来准备正手的引拍

Sep 11

首先询问了还原和启动的关系。教练的意思是攻球，挥拍到前面之后，可以先不动。等对面球出来之后，再判断，然后直接启动。比如如果是正手球，就可以直接侧身准备击球。还原和启动是一个动作完成了。

然后是关于撞和磨的关系的讨论，教练认为还是要先撞后磨的。

这次练了下，感觉最重要的还是放松。

Sep 19

因为重新看了下医生，说暂时不要运动，因此这次就练了下搓球。

搓球的话主要几点：

• 腿要伸进去
• 重心一定要压低压低！可以感受到脸要贴着桌子的感觉
• 击球点要低，基本上是二跳要落下，就要完蛋的那个时候搓。但尽管如此，人是要先上去的，所以这里有一个停顿

Sep 26

本周停止

Oct 22

搓球：

• 脚上，身体也要上，要定住，然后在搓球
• 我搓球的出球有的太高，有的下网了。这个并不是击球点不对，击球点始终是要在下降期的（对于我的水平而言）。搓球的出球高地，主要是要判断来球的旋转，来确定板型。
• 劈长是低点，摆短要抢高点。fzh 跟我说劈长也要高点，后面教练跟我说这也不错，主要是为了出球的一致性，毕竟劈长是一个进攻的技术，如果对面起球的质量不高，那么就能一板打死，高点劈长的效果就体现出来了。但是这个比较难，我暂时不需要掌握。
• 无论如何，搓球球拍要在下面。搓球也是要往前，去点的那种感觉的，不是往下砍。

攻球：

• 正手攻球，其实只要侧身就行。我不要想着要侧很多，因为这样真的容易侧 180 度，类似于羽毛球那样。或者，就是直接拉手了。我理解这里跟羽毛球里面刘辉说的一样，就是我们对于侧身的感知太不敏感了，往往实际侧了很多，我们只感觉到侧了一点。

Oct 30

• 握拍得贴着虎口。因为虎口很大，所以是得靠大拇指一侧，而不是食指一侧
• 搓球的时候，中心前压，不是说要驼背，而是腹部发力
• 打球的时候，可以尝试只用前脚掌，把重心放到前脚掌上
• 摆速的时候，手不要拉
• 搓球的时候，中心要低，但不要趴桌上

Nov 13

正手虽然动作大，但是击球点靠后，所以空中时间长。

搓球亮板子是为了接触面积大。

Nov 21

• 搓球的时候，不要靠大臂往前戳。而是要以肘为轴心，小臂往前，大臂是不需要往前伸的

Nov 27

提了几点：

• 反手搓球，手也要拱着

Dec 4

• 反手搓球，直接上右脚就行，没必要往左边跨一步

• 反手搓球和正手搓球，手都要拱着

• 搓球的时候，拍子不要很立，或者说不要翘起来

• 正手搓球的时候，手可以送一点出去。我理解就是搓球的时候不要像触电一样

• 反手拨球，手也不要翘起来

Dec 11

正手攻球打球有几点：

• 上旋球，如果弧线比较低，也不需要提，直接打过去就行
• 攻球的时候，不仅要注意手不要翘，不要拉手。手腕最好跟搓球一样，能拱一点起来。整体来讲，就是要接触面积大。

反手攻球，发现有时候会打下网，原因还是我手腕没有偏拱，而是有点把手翘起来的感觉。我在微信里面备注了个图，可以参考下。

另外，进一步看了正手搓球：

• 重心还是要低，这里强调了一下，肘部也要低。我打球的时候，可能是提着肘，然后手在下面。其实应该肘和手都在下面。
• 可以想象，准备姿势，重心压低。这个时候，手臂是很贴近台面的。所以，正手搓球的时候，只需要把手臂打横就行了。
• 搓球也需要往前送，正手搓球不要往自己身体收前臂，而是往前送。
• 其实搓球搓起来，球不太容易很贴网的。

Jan 7

中间放假缺了一节课，另外和 fzh 又打了几场球，感觉正手搓球有点差了。主要体现在：

• 伸手太靠近身体
• 身体的发力太多了，手上的动作少了
• 小臂不要翘上去，搞得像一个 V 字一样，还是要放下来一点

在攻球方面，感觉膝盖好了不少。

然后初步学习一下反手拉球，感觉我自己的问题是：

• 手肘架太高了，更像拧
• 可能是怕刮到球台，自己退台太多了

这里的一个重点在于：

• 手腕一定要引拍，让球拍对着自己
• 拉球完毕后，手腕应该恢复类似正常的攻球状态，不要往上翘。其实往上翘也是我之前攻球常见的一个错误问题

我理解反手拉球随着你引拍是在身体左边、中间还是右边，动作的大小和幅度不太一样，但是框架是一样的，就是手腕要制造摩擦。

Jan 8 的时候又和 fzh 语音交流了一下。他的意思是反手拉球其实最重要的是能拉到别人搓过来的比较快并且贴身体的球。基本上退台是不会反手拉的。

Jan 30

今天又是只有我一个人。

搓球：

• 正手搓球不要在身体前面，而是要打开手臂，在身体右前方击球，原因是因为要有一致性。这样，站在那个位置，处理方式会有很多，不会给人感觉你就一定是搓球。不过打开手臂之后，还是要往前的，不能往身体方向收手臂。这个刻意注意一下就行。
• 另一种注意的办法是，搓球的时候可以有个停顿。这里的停顿不是说你就把拍子放在那里等球来了，我们肯定是要向着球制造摩擦的。但是就和羽毛球那样，得有一种“定”的感觉。或者可以认为伸手臂和往前搓实际上可以分解为两个动作。

拉球：

• 反手拉球直接跨步调整位置，不需要滑步。这是因为反手的地方就那么一块，滑步的动作太大了。

另外，我觉得拉球我的问题主要是：

• 不要边动边打球。脚步站好的时候，最好重心也调整好，比如该蹲那时候就蹲了，不要一边挥拍一边往下蹲，这样很难瞄准。
• 拍子要在下面，从下往上挥动。
• 拍子不要往上走，往上是通过手腕那个旋转来做的。手臂就是放松，自然展开就行。

Feb 12

学了下劈长。感觉这个很讲究瞬间发力：

• 如果小臂移动太多，那么就容易出界。
• 如果手腕移动太多，比如最后往上翘了，那么也容易出界。

另外今天体验了一下摆短。我确实可以摆起来，但是是卸力把球托过去的，并没有搓很转，所以没有什么威胁。

今天尝试了下拉球，就是彻底把手放下来，然后就发现有个明显的好处，就是如果我手自然下垂，那么我就没必要很刻意地去内旋我的手腕了，反而更轻松。

Mar 19

继续是反手拉球：

• 拉球是小要外旋，但是是往前，而不是要往上。
• 最重要的是，下降期拉球，如果抢了，就上不了。

继续是搓球：

• 我发现如果我每次搓球动作好的时候，都会碰到桌子。教练说没问题，反正我甚至可以就这样找感觉。
• 另外搓球就是手要打开。无论是正反手。手和胳膊都不要太硬。
• 正手搓球还有一点是，手不要缩着，搓球的点，应该更靠外一点。

Mar 26

Apr 1

正手搓球：

• 搓球正手手腕还是要打开。
• 然后不要整个手臂都往前捅，只是手腕一个小动作。

正手拉球：

• 不要整个手臂都自然下垂。主要还是手肘要夹着，也不要架着。然后小臂要下垂，然后可以稍微向后引拍。

Apr 16

Apr 24

最近反手好了很多，包括跟 fzh 练的时候也能感受到：

• 主要是我现在不会手腕往上翘了，而是往内收，这样摩擦会好点。

今天和一个高中生多球。感觉上：

• 速度起来之后，步伐就不太行。侧身感觉侧不过来，还是手先动。
• 搓球很容易冒高，教练的意思是这个球就不转，所以容易搓高。
• 搓后接着拉球的时候，步伐吃力。

May 9

• 攻球要打开，也就是说拍子要更往外站开点，可以类比正手搓球。
• 攻球可以夹着大臂，拉球不行。
• 拉球手腕不要往上翘。
• 拉球时候，拍头和小臂平齐就行。
• 拉球的时候，类似于用肩膀画弧，但是不要甩大臂。收小臂，把大臂可以带出去。往前不要往左。

May 13

• 正手搓接反手拉。搓球完要回一步。可以理解为搓球的时候右脚就蹬住，搓完了直接用力就能回。然后，看回球的情况，如果短，就可以直接处理，或者特别短的话就上步。如果需要反手拉球，则可以往后垫一步，同时手放下去准备拉球。
• 正手拉球，引拍的步伐不要往前走，而是主要体现为要把重心放到右脚上，并且要侧身。
• 正手拉球，不要拉完人往后仰，而是重心压在前面。
• 正手拉球，前臂要更靠外，可以有快速收小臂的感觉，但是小臂不要收到左边，而是要往前。拉球的整个动作都是要往前的。

D1

这一次从南京直飞大阪。机票照例没有提前多久定，但是两个人往返也才 4k 出头，相当便宜。宾馆就是贵的离谱了。京都的宾馆单人 1.5k，双人接近 4k 感觉简直在抢钱。我先在大阪定了 2 天 700 左右的。然后又订了一天姬路和大阪的。然后最后一天住哪不清楚，大概先这样。

关西机场入国变得麻烦多了，这次虽然没有坐小火车（吉祥航空），但入关排队感觉就花了将近一个小时了。在飞机上被发了入境单要填，我觉得挺麻烦的，现在都是电子化了啊。结果到了入境口发现有 abcd 四个 route，但完全不知道区别是什么。一个国际机场居然没有英文的说明，工作人员也只说日语和简单的英语。Anyway，他有个扫描护照的机器，感觉挺方便的。我用机器扫完，然后就再往前排队等人工。走到一半发现大家还有个 QR code 也不知道是啥，但是这些人扫完 QR 之后又要填一遍纸单子。。。

反正轮到我我就说 I have no QA code but I’ve already finished the note, and I’ve already registered on that machine. 然后那人把我的纸收了就直接贴入境单了，很丝滑很快。这次不去京都，就直接走南海电车了，更便宜。坐到 namba 才 900。

吃完饭，就去附近的 apple 店买个表。现在日本的 apple 店居然不能退税了，只有部分非官方 retailer 可以退税，但是我又不知道哪里靠谱。46mm 的要 3200，国内才 2600。但是因为国内啥啥都没，没快充慢的一批，所以还是买了。总不能为这个专门跑一次 hk 吧。

去 711 给交通卡充值，发现只能用现金。幸亏我带了 15000 jpy 来，本意是上次玩没用掉，这次结果救了命。

晚上出去吃饭回来，发现大阪真的冷，幸亏穿了两件，不然真的冻死。

回来发现日本的窗子真的好隔音，薄薄的平开窗，毫无特点的铝合金，居然这么猛。

D2 京都

因为地铁卡充值要现金感觉不方便，所以我今天就打算不用地铁卡，用 iPhone Wallet 了。这鬼东西又不能用信用卡，我弄了半天才弄了个储蓄卡上去。上地铁又刷坏了，墨迹了半天。到了大阪梅田站，她出不了站，刷了半天不知道怎么就出去了。结果到了 JR 大阪站发现进不去，问工作人员说这个是 osaka subway，我觉得很奇怪，因为 icoca 是通用的，工作人员也说我的 iPhone 是可以的。于是我觉得肯定是被锁了。无论如何，这里可以支付宝买纸票，于是我们就去京都了。

京都的公交车排队排了感觉有半个多小时，后面上了个临时的加班车。这边还不让带行李上公交车，幸亏我们都放在了大阪，就带了个小包。公交车里面非常拥挤，但我们进去的早，所以有个位置。公交车开的特别慢，感觉甚至不如走路。开到清水寺附近感觉花了大概二十多分钟。我们试图在五年阪下车，结果被堵住了，然后司机就不让我们下了。然后后面一个傻逼老外就说 you come here late, you have to follow their rules, it’s not your country 啥的。非常 offensive。

清水寺我们没进去，我对象说没啥意思，我之前去过，感觉也没啥意思，人还特别多。门口的御守他也觉得贼丑。然后我们就顺着三年半二年阪往下走，去找法观寺。我们都已经看到高台寺公园了，发现法观寺走过了，有绕回去找。结果法观寺就是我们来的路上的那个我觉得一般的唐代风格的塔，好像是京都的最老的塔，也不让进去。然后我们又走回到高台寺。

高台寺的垂樱是挺好看的。

高台寺出来很快就到了八阪神社，里面和好吃街一样，我们找了下垂樱在哪里，就去吃那个鳗鱼饭了。

鳗鱼饭吃完出来，就在木屋町那条小路那边拍樱花，感觉比鸭川的樱花好看。

然后又绕回去看了下花见小路，照旧非常无聊。路尽头是什么建仁寺的，大家都没有兴趣看。

然后又走了一大段路去看顶法寺。顶法寺不要钱，里面的樱花很漂亮。还有几个小和尚的雕塑也很有意思。

晚上实在走不动了，就坐了京阪电车，因为阪急还要多走 300m。至于京都 JR，因为坐公交体验太差，完全不考虑了。我们坐的是 18.59 的京阪电车去的大阪。其实以后真的可以坐京阪电车到京都东边，比 JR 方便很多，还便宜。但这次京阪电车属实是个坑货。它终点站在大阪是 yodoyabashi 淀屋桥，但是又有一些车是到一个叫 yodo 淀的地方。然后我就被这个车丢在了 yodo。后面上了个准急的，几乎就是站站乐了，感觉总共花了大概一个多小时才到大阪。

回到大阪，找大阪地铁说明了情况，列车长问我们要不要 refund。我说不要，他就说 OK。然后就解锁了，结果发现之前坐的 namba 的南海的钱居然也没被扣。南海真的血亏啊。

D3 姬路

起来去姬路。这次发现他们电车同一个方向有两个轨道，一边是 local 一边是 express。上车前可以看站台上的屏幕，上车时可以看车的屏幕确认。上车前可以看 Google 或者 Apple 的 map 到达的时间确定自己是不是对应班次的车。上车后也可以听播报。基本上 Rapid、Express 的车都比较推荐，大阪、神户市区的大站基本都停。Limited Express 特急要特价券我没见过。

姬路是个小城市，我们的酒店在车站南边一点。应该是此行中比较大的酒店了。酒店不能提前办理入住，但是可以预先寄存。

姬路站北面正对姬路城，通过一个大道可以直接走过去。大道两侧不少店铺比较出名，我们吃了个咖啡，然后就立即前往姬路城了。

城里面樱花很漂亮，右边走还有个动物园。登城口在左边，要排队，但是队伍很快，等了大概半小时就进去了。买票 +50 yen 就能得到一个旁边的花园的门票。花园里面有个餐厅，我们去的时候已经关门了。姬路城主要就是两块，一个是西之丸庭院，可以脱掉鞋子登上去，类似于一个走廊，有多个城橹。从化妆橹可以下来，据说这个是给城主夫人化妆用的地方。西之丸庭院相比大阪城比较小巧，里面也有不少樱花。

从庭院出来就可以走到天守的口了。然后就是穿过一道道什么 yi 之门、wa 之门、ni 之门，然后走到天守的下面的小庭院内。然后就走过水之 X 门走到大天守里面。大天守有 6 层，第 2 层开始大排长队，人贼多。

D4 神户

神户的酒店在三宫门口，应该是本次我找的最近、最便宜的酒店了，才 500。住宿体验很舒适。

放完东西，去神户动物园。我们应该是顶门到的，进去刷票的时候，我对象把票根掉了，检票员说必须要把票找回来。

在那个破落商店里面有一家后来知道叫 Yellow Submarine 的桌游超市，还挺大的。回来我去问了下有没有那个骰子游戏，他带我去找，然后翻了下，说 sold out 了。我以为附近南京町还有一家，走过去发现那是个别的地方，已经关门了。

D5 奈良 - 大阪

下了奈良站，在 5 号口附近找到一个柜子，600 yen 就可以放两个小箱子和一个包了。不过只接受 100 yen 的硬币，我还要去旁边换。

出去吃了那个口水麻薯，一堆老外在那边拍照。去看了兴福寺，要钱，没意思没进去。兴福寺下来就能看到鹿，鹿很现实，看到我们没买饼就不磕头了。我们到最后也没买，主打白嫖。

旁边的奈良博物馆关门了。

我印象里上次去若草山有个大坡可以坐着休息，但这次去好像就是一些大草坪可以走，有椅子可以坐。大草坪也许是封起来了吧，因为当时看到大草坪上没有人，而且往若草山方向有被拦住。

在大阪这最后一晚住的酒店是最拉胯的。

D6 大阪