小生说大声讲

我只是想打开一个 Markdown 文件看一眼——于是 vibe coding 了一个编辑器

2026-06-06T15:00:00+08:00

一个小到可笑的需求

先说清楚我到底想要什么，因为这决定了后面所有的取舍：

我只是想在 macOS 上随手打开一个 Markdown 文件看一眼，如果能顺便改两笔就更好——仅此而已。

我不需要笔记库（vault）、不需要双向链接、不需要标签系统、不需要文件树、不需要发布到博客的一键流程、不需要 30 个主题。这些功能不是不好，而是它们都在解决"管理大量笔记"的问题，而我的问题是"此刻打开这一个文件"。

这个需求小到，理论上应该有一大把现成软件能完美满足。但真当我一个个试过去，发现没有一个让我舒服的。

我试过的那些编辑器，以及为什么都不行

把候选者摊开，按我最在意的几个维度排一张表：

编辑器	实现方式	价格	维护状态	我的槽点
Typora	Electron / CEF	付费	活跃	体验确实是标杆，但收费 + Electron 套壳，进程动辄几百 MB
MacDown	原生 WebView	免费开源	年久失修	老牌良心货，但更新近乎停滞，对新语法支持滞后
MacDown3000	MacDown 衍生	免费	不稳定	每次跟着更新就容易"罢工"，可靠性堪忧
Mark Text	Electron	免费开源	基本停更	曾经很惊艳，如今 issue 堆积、长期没有新版
Obsidian	Electron	个人免费	活跃	强大但"重"，是知识库工具，为"打开一个文件"杀鸡用牛刀
iA Writer	原生	付费	活跃	原生、极简、很优雅，但要付费，且偏纯写作
Marked 2	原生	付费	活跃	只读预览器，不能编辑，定位和我的需求错位
VS Code	Electron	免费	活跃	它是 IDE，为看一个 md 启动整个编辑器，心理负担太大

把这张表看下来，会发现它们恰好踩满了我的四条雷区：

要么收费——Typora、iA Writer、Marked 2，体验好但要掏钱，而我的需求廉价到不值得为它付费；
要么是 Electron 套壳——Mark Text、Obsidian、VS Code，随便开一个进程就吃掉几百 MB 内存，启动还有可感知的延迟，跟"随手看一眼"的轻快感背道而驰；
要么年久失修——MacDown 这样的老牌开源货，代码还在，但维护近乎停摆，新语法跟不上；
要么不稳定——MacDown 衍生出来的 MacDown3000，我用得最闹心，常常一更新就不能好好工作。

最让我难受的是第 2 条。Markdown 这种纯文本格式，本应是最轻量的东西，结果主流方案却普遍建立在一整个浏览器内核之上。为了渲染几段文字和代码块，背一个 Chromium，怎么想都不对劲。

那就自己写一个吧

既然挑不到，那就自己造。正好赶上 AI 辅助编程（大家戏称 "vibe coding"）已经足够顺手，我决定亲自下场，做一个完全贴合自己需求的编辑器。给它起名 Markdown2——"Markdown Editor Too"，一个不太正经的双关：既是"另一个 Markdown 编辑器"，也是"我也想要一个 Markdown 编辑器"。

立项时我给自己定了几条死规矩，全部是对前面四条雷区的正面回应：

原生，不用 Electron——用 SwiftUI + AppKit，做成真正的 macOS app，启动快、内存小；
轻量，专注阅读/编辑——单窗口，只有"编写"和"阅读"两种模式，不做文件管理、不做笔记库；
离线，不依赖网络——公式、图表的渲染资源全部内置打包，断网照样工作；
开源免费——MIT 协议，自己用得放心，也省得有人重蹈我"挑不到"的覆辙。

技术栈选 Swift 而不是继续套 Electron，理由很直接：我想要的就是"原生的轻"。文本编辑这件事，AppKit 的 NSTextView 经过几十年打磨，底子比任何 Web 富文本都扎实；外层用 SwiftUI 搭界面和状态管理，写起来又足够现代。两者配合，正好是"原生底座 + 现代外壳"。

整个项目用 Swift Package Manager 组织，拆成三层：

MD2Core——纯逻辑层，Markdown 解析、渲染成 HTML、大纲提取、语法高亮、文档统计，不碰 UI，方便写单元测试；
MD2AppSupport——承载启动激活这类与 AppKit 生命周期强相关的辅助逻辑；
MD2App——SwiftUI/AppKit 的应用层，窗口、编辑器、预览、设置都在这。

逻辑和界面分层之后，核心的解析渲染能力是可以脱离 GUI 单独测试的，这让"vibe coding"产出的代码不至于变成一团没法验证的浆糊。

途中那些有意思的坑

vibe coding 不是把需求丢给 AI 就万事大吉，真正花时间的，永远是那些"看起来该工作却不工作"的细节。挑几个印象最深的讲讲——前两个是早期的小坑，后两个则是真正需要先想清楚、再让 AI 动手的复杂需求。

坑一：`swift run` 启动后，窗口躲到了别人后面

开发阶段我习惯用 swift run Markdown2 直接跑。结果发现一个诡异现象：app 进程确实起来了，但窗口总是藏在当前 app 的后面，前台焦点还赖在终端/编辑器上，等于这 app 没法正常用。

排查下来，根因有点意思：SwiftPM 跑出来的是一个裸的 Mach-O 可执行文件，而不是被 LaunchServices 管理的 .app bundle。macOS 对"裸进程"和"正经 app"的窗口前台化待遇是不一样的——从裸进程里直接调 AppKit 的激活 API，并不足以可靠地把窗口抢到最前面。

解决办法是加了一段"直接启动引导"（direct-launch bootstrap）：当 Markdown2 发现自己不是在 .app 里运行时，就在 .build 目录下临时合成一个 Markdown2.app，再通过 NSWorkspace 带激活地把这个 bundle 打开，然后原始的裸进程退出。被 bundle 拉起来的那个进程会跳过引导逻辑，正常进入主流程。后来又发现 SwiftUI 的 WindowGroup 在这条特殊启动路径下，偶尔会进了 applicationDidFinishLaunching 却没真正建出可用的初始窗口，于是干脆在 AppDelegate 里显式创建主 NSWindow，把 SwiftUI 的 ContentView 塞进去托管，再加上几次延迟激活重试兜底。

这个坑我专门写了回归测试，验证激活策略提升、窗口层级排序、以及对"迟到窗口"的延迟重试。它很典型地说明了一件事：AI 能飞快写出主干，但操作系统层面的边角行为，还是得人去抠。

坑二：公式和图表，到底要不要联网

很多 Markdown 编辑器渲染数学公式和图表时，是去 CDN 拉 KaTeX/Mermaid 这些前端库的。但这跟我"断网也能看"的原则冲突——很多时候我打开一个 md，恰恰是在没网或不想联网的场景。

于是我把渲染资源全部内置打包进 app：

数学公式用内置的 KaTeX，行内 $...$ 和独占一行的 $$...$$ 都支持，还带上了 mhchem 扩展，能写化学式 \ce{H2SO4}；
图表支持 mermaid、flow（flowchart.js）和 sequence（js-sequence-diagrams），引擎全部离线内置。

代价是 app 体积大了一点，但换来"任何时候、任何网络环境下打开都一致"，我觉得非常值。顺带一提，这两块功能我是用 spec-driven 的方式做的——先写 proposal/design/spec，再让 AI 照着实现，archive 里留着 add-math-support 和 add-diagram-rendering 两个变更记录。给 vibe coding 套上一层规格约束，产出的可控性明显高很多。后面两个更复杂的需求，更是全靠这套流程才没翻车。

坑三：模式切换后，怎么还"停在原地"

这是个用着用着就越来越忍不了的体验问题：在编写/阅读两种模式之间切换时，视口总是弹回文档顶部。文档但凡比一屏长，每切一次就得重新滚回刚才看的地方，读改循环被打断得很烦。

听起来像"记一下滚动位置"这么简单，真做起来才发现卡在一个根本性的错位上：编辑器和预览是两套完全不同的坐标系。编辑器认的是「源码第几行」，预览是一个 WKWebView，认的是「DOM 元素的像素滚动偏移」。我"刚才在第 180 行"，翻译成预览里该滚到哪个像素，并没有现成的换算。

破局点是文档大纲：每个 Heading 节点同时带着源码 line 和 HTML 元素 id——它天然就是横跨两套坐标系的那座桥。于是策略定为：切换时锚定到「光标/视口上方最近的那个标题」，按章节粒度对齐，不追求像素级或光标级精确——目标是"落回文档的同一部分"，而不是分毫不差。没有标题的文档、或标题之前的内容，则退化成按滚动比例（scroll-fraction）兜底，绝不静默跳回顶部。

真正棘手的是异步：WKWebView 的滚动位置只能通过 evaluateJavaScript 回调异步读取，而 SwiftUI 的模式切换是同步发生的、旧视图瞬间就被销毁。所以根本不能"在切换那一刻才去问预览滚到哪了"——得在用户滚动时就持续把「当前视口顶部是哪个标题」缓存下来，等切换真正发生时直接拿现成的值用。我把纯粹的「行号↔标题」解析逻辑（比如"找出 line 不超过某行的最后一个标题"）抽进 MD2Core 做成纯函数，这样不依赖跑起来的 WebView 就能单测。

这种需求，是没法一句话丢给 AI 的。得先把"用什么做锚、锚在什么粒度、异步怎么规避、没锚点时怎么兜底"这几件事一条条想清楚、写进 spec，AI 才可能写对——否则它大概率给你一个"在简单情况下能跑、一遇到长文档和异步就乱套"的版本。

坑四：藏不住的图表"闪一下"

这个 bug 是做坑三时顺手揪出来的：调试滚动位置时我注意到，预览加载完之后大约一秒，Mermaid 图表会肉眼可见地"闪"一下——先显示一段原始代码文本，然后才被引擎替换成渲染好的 SVG。

根因有两层。其一，图表引擎是异步渲染的，在它 resolve 之前，DOM 里就摆着原始源码当占位文本给读者看到了；其二，前面提过预览的 WKWebView 每次切换模式都会重建，所以这个闪烁不只第一次出现，而是每切一次复发一次。

修法是给占位状态做文章：源码仍然留在 DOM 里供引擎读取，但用 CSS 不再把它当正常文本显示；等引擎渲染完成，再加一个约 120ms 的淡入，把生硬的"代码→图"硬切变成柔和过渡；同时给占位块预留一点 min-height，减少 SVG 撑开时的布局跳动。这里最容易踩的雷是别把错误兜底搞丢了——解析失败时仍然要把原始源码显示出来，绝不能让一个写错的图表变成一片空白。所以"渲染成功才隐藏、失败要回显"这条岔路必须在 spec 里写死，测试也要专门覆盖错误路径仍然可见。

一个需求的调试过程牵出另一个隐藏问题，再各自立项、写 spec、补回归测试——这才是真实软件演进的样子，也是为什么我越来越离不开这套"先规格、后实现"的节奏。

现在的 Markdown2 长什么样

迭代到现在，它已经能覆盖我日常的全部需求：

单窗口、双模式：一个主界面，Esc 从编辑切到预览，预览里 Cmd+双击 切回编辑，手不离键，且切换时停留在同一章节、不会弹回顶部；
多窗口：每个文档独立开窗，从 Finder 双击打开时会复用那些还没动过的空白窗口，不会越开越乱；
大纲侧栏：按标题自动生成，长文档导航很顺；
自动保存 + 关闭确认：已保存的文档防抖自动保存，有未保存改动时关窗/退出会提示；
状态栏：字数、字符数、行数、预计阅读时间一眼可见；
够用的 Markdown 渲染：标题、强调、链接、图片、引用、各类列表、GFM 表格、带语法高亮的围栏代码（Python/Go/Rust/Swift 等十来种语言）、YAML front matter、[TOC]，外加前面说的离线公式与图表；
文件类型关联：打包后把 .md/.markdown 注册给自己，双击直达。

它不做的事同样清晰：脚注、PDF/DOCX 导出、图片上传拖拽、打字机模式、主题管理、笔记库——这些都不在"随手打开看一眼"的射程内，我刻意没碰。约束自己不做什么，往往比堆功能更难，但这恰恰是我对那些"功能太复杂"的编辑器最大的不满，不能自己又掉进同一个坑。

一点心路体会

回头看这趟，从"挑不到一个趁手的 Markdown 编辑器"到"两天攒出一个自己用着舒服的原生 app"，最大的感受有两条。

一是 AI 把"自己造一个轮子"的门槛拉得很低了。放在以前，为了这么个小需求去啃 AppKit、SwiftUI、KaTeX 内嵌，光是查文档就能劝退我；现在 vibe coding 让我能把精力集中在"我到底想要什么、哪里还不对"上，而不是卡在 API 细节里。

二是 AI 替代不了"品味"和"较真"。它能秒出一个能跑的版本，但"窗口为什么躲到后面"这种坑、"要不要联网渲染"这种取舍、"克制住不加哪些功能"这种判断，依然得人来定。工具越强，"想清楚自己要什么"反而越值钱。

代码已经开源在 GitHub（stutiredboy/Markdown2），MIT 协议。如果你也和我一样，只是想随手打开一个 Markdown 文件看一眼，欢迎试试，也欢迎拍砖。

姚顺宇 4 小时访谈，通透有趣的灵魂~

2026-05-19T20:00:00+08:00

听完这四个多小时的访谈，有几点觉得比较有意思的：

1、姚顺宇坦言自己 90% 甚至 99% 的代码都是 AI 生成的，果然极客精神首先还得是实用主义，和古法编程形成了反差，拥有最好的本地大模型和代码助手，还非要去拼人力，这就是跟生产力过不去，当然不妨碍我们应当保留那 1%~10% AI 无法触达的能力；

2、所谓"到了架构瓶颈"，往往只是代码里藏了个低级 Bug。就好比近一年来各大公有云的各种 big boom 可能单纯是一段糟糕的监控代码把控制面给打爆了；

3、Idea 极其廉价，执行力和"靠谱"才是硬通货。姚顺宇提到"AI 这个事其实不太需要脑子，最重要的特质是 Execute（执行力）"。想法需要详尽的架构蓝图，现在不缺天马行空的所谓"英雄"，缺的是能把复杂的项目，一步步拆解清晰，能把事情做细，对交付结果死磕到底的靠谱工程师；

4、祛魅"老登"，破除个人英雄主义神话。"没有哪个老登是你的亲属，他傻就可以直接说他傻"。技术发展到今天这个量级，单枪匹马搞定颠覆性算法的时代已经翻篇了，本质上都是工程体系和集体主义的胜利。只要逻辑自洽、结果能经得起客观标准的检验，就不需要去迷信那些旧时代的权威；

5、Anthropic Dario 所谓的"AI 安全"，不过是反中和争霸的遮羞布。姚顺宇毫不避讳地爆料，离开 Anthropic 有 40% 的原因是因为受不了 CEO Dario 的反华立场，而且极其反感 Dario 那套"我们必须拥有最强模型才能推 AI 安全"的逻辑。这点真的让人挺 respect 的。现在硅谷那帮大佬动辄把"AI 安全"挂在嘴边，搞得极其神圣，但扒开这层皮，底层逻辑无非是"我要垄断最强技术，所以规矩必须由我来定"的政治博弈和商业算计；

6、OpenAI 救了 Google 一命，"如果 ChatGPT 一鼓作气把 Search 吃透，Google 就完了。正因为没做到极致，反而给 Google 留了反击的时间。"如果在技术优势期没有把核心场景打穿、形成绝对的降维打击，那就是给对手留了喘息和重组火力的窗口期。OpenAI 后来高管流失、各种内部动荡，多少也印证了在战略执行上的拖泥带水是致命的；

7、程序员的未来不是消失，而是"极度中心化"的残酷洗牌。"绝大多数失去独特价值，1/1000 的人拿 100 倍工资。"这句话很残酷也也很真实（虽然资本家大概率不会真的给你 100 倍工资）。未来留下来的，必定是那些具备全局视野、能把复杂业务逻辑拆解成 AI 可执行步骤的"超级节点"。这1/1000的人，其实是懂业务、懂架构，还能下一线动手的"超级总包商"；

见识学习了姚顺宇作为"不靠 LP 吃饭、没有历史包袱"的新一代研究员的特质，这些带着浓厚极客精神和真实体感的观点，以姚顺宇相对平静又戏虐的语气跳脱而出，还是很有冲击力的。另外抛开那些虚头巴脑的，不管外面的风口吹得多高，哪怕是 Anthropic、Google DeepMind 这样的神级团队，本质上也是由一个个也会写出 Bug、也会搞出命名乌龙（Claude 3.5/3.6）的工程师组成的。对我们来说，用好当下最锋利的工具去武装自己才是咱们在这个快速变现的时代里最应该马上去做的（至于能不能成为最核心的护城河，谁知道呢~~

借长鑫科技的东风，把存储这件事一次讲透

2026-05-17T10:00:00+08:00

2026 年 5 月 17 日，长鑫科技更新科创板招股书：2026 年 Q1 营收 508 亿、归母净利润 247.62 亿，半年指引营收 1100—1200 亿、归母 500—570 亿，同比预增 2244%—2544%。一家长期亏损的国产 DRAM 厂，半年净利干到 500 亿+ 的体量，把"中国存储能不能赚钱"这道老问题，直接翻篇了。

借这股东风，正好把存储这条产业链相关的信息学习一轮。

一、AI 时代的存储，凭什么分成六层

CPU 和 GPU 自己只有一点点片上缓存，装不下模型，更装不下推理上下文。所以存储被迫往外摊，离算力越远、容量越大、单位成本越低，但延迟和能耗也越高。这就是分层的由来。

按"离算力的距离"由近到远，AI 存储一共六层，2025 年六层合计市场约 2290 亿美元：

挑几个关键点说：

L0 片上 SRAM：嵌在每颗芯片里，本身只有 10—17 亿美元的独立晶片市场，但每一颗 H100、B200、TPU v5 为了多塞 SRAM 都得多买晶圆，真正的利润池落在台积电——全球先进工艺晶圆 70% 以上在它手里。
L1 HBM：用 TSV 把 DRAM 垂直堆叠，再用 CoWoS 贴到 GPU 旁边。它几乎单枪匹马决定了 AI 加速器能跑多大的模型。2025 年盘子约 350 亿美元，2028 年预计冲到 1000 亿美元，CAGR 40%（美光 FY26Q1 业绩会口径）。2026Q1，SK 海力士的营业利润率打到了 72%，比台积电（58%）和英伟达（65%）都高。
L2 主板 DRAM：DDR5/LPDDR/GDDR 这些常规内存条，2025 年 1218 亿美元，是六层里盘子最大的。三星、SK、美光把产能往 HBM 倾斜后，反而让普通 DRAM 维持了高利润和定价权。
L3 CXL 内存池：把 DRAM 从单台服务器"池化"到机架级，多个 GPU 按需共享。当前规模才 16 亿美元，但 2033 年看到 237 亿。这一层最暴利的环节是重定时器，Astera Labs 占 55%，非 GAAP 毛利率 76%。
L4 企业级 SSD：QLC 大容量盘已经把 HDD 从 AI 数据湖里彻底挤出去。2025 年 261 亿美元，CAGR 24%，海力士子公司 Solidigm 与 Kioxia 已经做出 122TB 的单盘。
L5 NAS 与云对象存储：数据湖、归档、跨团队协作的最外层，AWS+Azure+GCP 三家拿走 65—70%，靠的是"数据出网+生态锁定"的复利。

一句话总结：越靠近算力，盘子越小，毛利越高。HBM 盘子只有 DRAM 三分之一，毛利率却翻倍；CXL 重定时器盘子最小，毛利率最高。

二、龙头格局：三强 + 一个新入场的第四名

存储是典型寡头行业，前三家在每一层都基本拿走 90% 以上。

DRAM（TrendForce 2025Q4）：三星 35.8% 重夺第一、SK 海力士 32.1%、美光 22.4%，长鑫 CXMT 升至 4.7%，构成新的"四强"格局。按招股书披露的产能/出货口径，长鑫 2025Q4 全球份额已达 7.67%——口径差异主要在于片数 vs 营收，长鑫片数堆上来了，单价还在追赶。
HBM（2026Q1）：SK 海力士约 58%（拿下英伟达大单）、三星 22%、美光 20%。三星份额从 40% 掉到 22%，主要被先进封装良率拖累。
企业级 SSD（2025Q4）：三星 36.9%、SK（含 Solidigm）32.9%、美光 14.0%、Kioxia 11.7%、SanDisk 4.4%，前五合计约 90%。

韩美三巨头同时吃下 DRAM+HBM+NAND 三层红利，是更全面的"AI 存储平台公司"。长鑫是这个格局里唯一的中国玩家——之前的市场被三星、SK、美光三家寡头垄断超过 90%，长鑫从零起步做到全球第四，本身就是 0→1 的破局。

三、长鑫的产业链全景：设备 + 材料 + 客户

长鑫现在合肥两座、北京一座，三座 12 英寸厂，月产能合计接近 30 万片，按晶圆片数算已占全球 DRAM 接近 15%。上海新厂分两期共 20 万片，2027—2028 年陆续投产，远期奔着 50 万片以上去。IPO 拟募资 295 亿，其中约 200 亿会直接变成设备订单——这是国产设备厂未来两年最确定的基本盘。

上游 · 设备（国产化率 ≈ 45%）

已跑通：刻蚀（北方华创 ICP > 50%、中微 CCP）、CMP（华海清科国产份额 > 90%）、清洗（盛美 SAPS/TEBO）、热处理（北方华创立式氧化炉）。
验证中：薄膜沉积（拓荆 PECVD、北方华创 PVD 进入量产），但 DRAM 电容核心的高 K ALD 还是应材、ASM 的地盘。
卡脖子：光刻国产化率不到 5%，主力还是 ASML NXT:1980Di。2026 年 4 月美国众议院通过 MATCH 法案，要求 150 天内堵死 DUV 出口的灰色通道——这道墙短期绕不开。量测（KLA 占 51-54%）、涂胶显影（东电 90%）、离子注入也都还是个位数国产率。

上游 · 材料（领先设备一个身位）

湿电子化学品 + CMP：晶瑞电材（全品类）、安集科技（抛光液国内 ≈70%）、鼎龙股份（抛光垫国内 > 70%）、格林达（G5 级 TMAH 显影液）。
气体 + 前驱体 + 硅片：广钢气体（电子大宗气签了 15 年长协，国内罕见）、华特气体（光刻气国内 60%）、雅克科技 / 安德科铭（ALD 前驱体）、沪硅产业 / 立昂微（12 英寸硅片）。
靶材：江丰电子，12 英寸国内份额 > 70%，部分进入 3 纳米验证。
薄弱环节：ArF 光刻胶（南大光电、彤程刚破冰），掩模版（Photronics/Toppan/DNP 主导，国产化率极低）。

材料端最大的特点是"量"先于"价"——化学品单价指数从 2022 年的 100 跌到 2025H1 的 77.90，但景气回升直接传导到采购量。按 2026Q1 业绩外推，长鑫全年材料采购规模冲到 270 亿以上是大概率事件。

下游 · 客户与封测

股东即大客户：阿里云（持股 3.85%）、阿里网络、小米、联想、OPPO、vivo；华为昇腾系列的 HBM2/HBM3 与 LPDDR5X 由长鑫优先供应。
封测已国产化：沛顿（深科技）承接 > 50% 委外封测，长电、通富、盛合晶微补位；HBM 后段封装材料（华海诚科 GMC、联瑞新材球硅）随 2026 年底上海后段厂投产开始放量。

四、为什么 DRAM 这一波"确定性"格外强

把视角拉远，三件事同时发生：

AI 驱动的存储超级周期：Omdia 预测全球 DRAM 市场规模从 2025 年的 1505 亿美元增长到 2030 年的 5710 亿美元，CAGR 30.56%；HBM TAM 提前两年看到 1000 亿美元的水平。
三巨头扩产谨慎 + 产能向 HBM 倾斜：直接结果是 2026Q1 DRAM 平均售价（ASP）环比涨幅超 60%，明确的卖方市场。
国产替代被外部约束加速：MATCH 法案越收紧，长鑫每往国产设备多切一个百分点，对应的就是北方华创、中微、拓荆、华海清科、盛美的实打实订单。

风险也要诚实地讲：DRAM 是存储三大品类中需求被两头挤压最严重的一类（上有 HBM 抢算力侧需求、下有 NAND 抢 token 侧需求），从历史周期看也通常是最早反转的。半年 500 亿净利的高基数能维持多久，要看 H2 ASP 走势和长鑫向 G5/HBM3 的代际切换节奏。

结语

长鑫的故事，本质不是一家公司的 IPO，而是整条中国 12 英寸国产存储平台第一次被验证、被复用的过程——刻蚀和 CMP 已经跑通，薄膜沉积和清洗在跟进，量测和光刻是下一个要啃的硬骨头。

对普通投资者来说，与其押单一标的，不如把这张产业链全景图收好：HBM 的利润最暴利但跟自己关系最远，DRAM 的盘子最大、长鑫的扩产传导最直接，材料和设备里的"量增弹性"标的反而最持续。 AI 时代缺芯、缺电、缺存，长鑫正好压在"缺存"这条最确定的线上。

主要数据来源： - 长鑫科技 2026 年更新版科创板招股书； - TrendForce《Price Rally Drives 4Q25 DRAM Revenue Up 29.4%》； - Counterpoint《Global DRAM and HBM Market Share》； - Omdia DRAM TAM 预测； - 美光 FY26Q1 业绩电话会； - SK 海力士 2026Q1 财报。

USB 命名混乱救命表：从 1.1 到 120Gbps

2026-04-26T12:00:00+08:00

为什么需要这张表

USB 的命名乱到什么程度？看几个常踩的坑：

同一个速率，三个商标名：USB 3.0、USB 3.1 Gen 1、USB 3.2 Gen 1 是完全同一个东西（5 Gbps）。你在淘宝看到三种叫法只是上架时机不同。
"SuperSpeed" 比 "SuperSpeedPlus" 慢一倍：听起来就差一个 Plus，实际上一个 5 Gbps 一个 10 Gbps。
USB 3.2 Gen 2 和 USB 3.2 Gen 2x2 不是一回事：后者是双 lane，速率翻倍到 20 Gbps。x2 这个后缀很多店铺不会写。
USB4 也不是只有一种：有 USB4 20Gbps 和 USB4 40Gbps 两个档位，盒子上不写清楚就只能赌。
USB4 不等于 Thunderbolt 4，也不等于 USB-C：USB-C 只是物理接口，Thunderbolt 是 Intel 的超集协议，USB4 是 USB-IF 的协议——三者经常被混着叫。

下面这张表就是用来在买线、选 dock、判断 NAS / 移动硬盘盒接口时一眼对上号的。

营销名 vs 技术名

营销名（Marketing Name）	等价别名（Also Known As）	信号速率	理论带宽	线芯	线长上限
USB 1.1	Full Speed	12 Mbps	1.5 MiB/s	4	4 m
USB 2.0	Hi-Speed	480 Mbps	60 MiB/s	4	4 m
SuperSpeed USB 5Gbps	USB 3.0 USB 3.1 USB 3.2 USB 3.1 Gen 1 USB 3.2 Gen 1	5 000 Mbps	625 MiB/s	8	3 m
SuperSpeedPlus USB 10Gbps	USB 3.1 USB 3.2 USB 3.1 Gen 2 USB 3.2 Gen 2	10 000 Mbps	1 250 MiB/s	8	2 m
SuperSpeedPlus USB 20Gbps	USB 3.2 USB 3.2 Gen 2x2	20 000 Mbps	2 500 MiB/s	12	1 m
USB4 20Gbps	USB4 Gen 2×2 USB4	20 000 Mbps	2 500 MiB/s	12	0.8 m
USB4 40Gbps	USB4 Gen 3×2 USB4	40 000 Mbps	5 000 MiB/s	12	0.8 m
USB 80Gbps 2026 补充	USB4 v2.0 USB4 Gen 4×2 Thunderbolt 5（超集）	80 000 Mbps	10 000 MiB/s	12	1 m（被动）
USB 120Gbps 2026 补充 / 非对称	USB4 v2.0 Asymmetric Thunderbolt 5 Bandwidth Boost	120/40 Gbps	15 000 / 5 000 MiB/s	12	1 m（被动）

看表姿势：买线、买盒子的时候，先把店家写的字串去 "Also Known As" 这一列里搜，落到哪一行就是哪一行的速率。不要被 "SuperSpeed"、"USB 3.2"、"USB4" 这种笼统说法骗——它们对应着多个不同档位。

Gen 命名约定：A x B 是什么意思

USB-IF 后来给 3.x 和 USB4 加的 Gen A x B 后缀，含义其实很规整：

USB Gen A x B

A = 第几代信号（决定每个 lane 的速率）
B = 用了几条 lane（双工对数）

下面这张表把 3.2 / USB4 各代乘开后的实际速率算清楚：

名称	单 lane 信号	总信号速率^a	编码	去编码后^b	理论带宽^b	真实顺序读^c
USB 3.2 Gen 1x1	5 000 Mbps	5 000 Mbps	8b/10b	4 000 Mbps	500 MiB/s	~400 MiB/s
USB 3.2 Gen 1x2	5 000 Mbps	10 000 Mbps	8b/10b	8 000 Mbps	1 000 MiB/s	~800 MiB/s
USB 3.2 Gen 2x1	10 000 Mbps	10 000 Mbps	128b/132b	9 696 Mbps	1 212 MiB/s	~780 MiB/s
USB 3.2 Gen 2x2	10 000 Mbps	20 000 Mbps	128b/132b	19 392 Mbps	2 424 MiB/s	~1 600 MiB/s
USB4 Gen 2x2	10 000 Mbps	20 000 Mbps	128b/132b	19 392 Mbps	2 424 MiB/s	~1 600 MiB/s
USB4 Gen 3x2	20 000 Mbps	40 000 Mbps	128b/132b	38 787 Mbps	4 848 MiB/s	~2 700 MiB/s
USB4 Gen 4x2 v2.0 / 2026 补充	40 000 Mbps（PAM3）	80 000 Mbps	64b/66b	77 575 Mbps	9 696 MiB/s	~6 000 MiB/s

注：多 lane 系统在发端做 lane striping，在收端做 lane bonding，用户看到的就是一个连续 stream。
^a 厂商盒子上印的就是这一栏。
^b 减掉编码开销后的有效速率。8b/10b 损失 20%，128b/132b 损失约 3%，64b/66b 损失约 3%。
^c 实测顺序读速率（要扣掉协议层、文件系统、SSD 主控本身的瓶颈）。

理解了 Gen A x B 之后，再回头看商标名就清晰多了：所谓 "SuperSpeedPlus 20Gbps" 其实就是 Gen 2 信号 × 2 lane；所谓 "USB4 40Gbps" 其实就是 Gen 3 信号 × 2 lane。这套约定唯一的问题是 USB-IF 自己又不在卖品名里写 Gen N×M，反而强推 "USB 80Gbps" 这种以速率为名的新商标——表里第一栏就是这么来的。

线材：4 / 8 / 12 芯

USB 物理线最常见三档：

4 芯：PWR、GND、D+、D-。一对差分信号，半双工一条 lane。
8 芯：4 芯的基础上加 RX+/RX-、TX+/TX-。两条 lane，一上一下，全双工。
12 芯：8 芯的基础上再加一组 RX2+/RX2-、TX2+/TX2-。四条 lane（两上两下），全双工。

一个 USB lane = 一对 ± 差分线。所以 4 芯 = 1 个半双工 lane，8 芯 = 2 个 lane，12 芯 = 4 个 lane。USB 3.2 Gen 2x2、USB4、USB4 v2.0 这些 "x2" 的标准都是要 12 芯线才能跑满的。

USB-A / USB-B 接口（4 芯 / 8 芯）

Type-A 4-wires	Type-A 8-wires	Type-B 4-wires	Type-B 8-wires

8 芯版本的 Type-A 蓝色塑料舌片就是 USB 3.x 的标志——多出来的 5 个针脚塞在原来 4 个的下方/后方。USB-B 8 芯版本（也叫 USB 3.0 Type-B）则是直接在原本梯形上又叠了一块，所以看起来像一个驼背的小房子。

USB-C 接口（12 芯）

只有 USB-C 有足够的引脚数支撑两个完整 lane。

CC1 / CC2：Configuration Channel。两端用来识别谁是 DFP（Downstream Facing Port，主机一侧）、谁是 UFP（Upstream Facing Port，设备一侧），同时也用来协商供电档位、切到 Alt Mode（DisplayPort、Thunderbolt、HDMI 等）。
SBU1 / SBU2：Sideband Use。用作 DisplayPort 的 AUX 通道、热插拔检测（HPD）等辅助信号。

USB-C 真正强大的地方是这两组针脚——没有它们，USB 就是个纯数据口；有了它们，一根 C 线可以同时跑数据、视频、PD 供电，并且正反盲插。

充电规格 / PD 档位

规范	最大电压	最大电流	最大功率
USB 2.0	5 V	500 mA	2.5 W
USB 3.0 / 3.1	5 V	900 mA	4.5 W
USB Battery Charging (BC) 1.2	5 V	1.5 A	7.5 W
USB-C Current Mode（非 PD）	5 V	3 A	15 W
USB-C / Power Delivery（PD 1/2）	20 V	5 A	100 W
USB-C PD 3.1 EPR（Extended Power Range）	48 V	5 A	240 W

要拉满 240 W，必须是支持 EPR 的线（线身上一般直接印 EPR 240W），并且两端 charger / 设备都支持 PD 3.1。普通 100 W 线直接插上去只会握手到 100 W 档位。

2026.04 补充：USB 80Gbps 已经量产

原文写于 2022 年，那会儿的天花板就是 USB4 40Gbps。到 2026.04，新的 USB4 v2.0（USB-IF 现在统一叫 "USB 80Gbps"）已经过了 spec → silicon → 整机三道关，能在零售店里买到。

技术上和老 USB4 的关键差别：

PAM3 信号：每个 symbol 不再是 0/1 两态，而是 -1/0/+1 三态（每 symbol 携带 ~1.58 bit）。这是单 lane 速率从 20 Gbps 翻到 40 Gbps 的核心。
编码换成 64b/66b：开销从 ~3% 略降。
对称模式 80 Gbps：4 lane × 40 Gbps = 160 Gbit 信号，扣编码后约 ~9 700 MiB/s 理论值；实测顺序读目前在 6 GB/s 左右（被 NVMe 主控和 PCIe 拓扑限制住）。
非对称模式 120 / 40 Gbps：3 lane 走一个方向、1 lane 走反方向。专门给 8K 显示、外置 GPU 这种"大头朝外"的场景。USB-IF 称这个档为 "USB 120Gbps"，Intel 在 Thunderbolt 5 里叫 "Bandwidth Boost"——同一回事。
接口仍然是 USB-C，引脚数还是 12。线长上限稍微放宽到 1 m（被动铜线）；超过 1 m 一般要 active 线。

参考

原文：Fabien Sanglard — USB Cheat Sheet（2022-05）
规范文档（USB-IF 官方下载）：USB Document Library
USB 1.0（1996-01）/ USB 1.1（1998-09）/ USB 2.0（2000-04）
USB 3.0（2008-11）/ USB 3.1（2013-07）/ USB 3.2（2017-09）
USB4 v1.0（2019-08）/ USB4 v2.0（2022-10）
USB Power Delivery 3.1 EPR：USB-IF PD Spec
Thunderbolt 5 / Intel Barlow Ridge 控制器公开材料：Intel Newsroom

啤酒游戏：让 Claude 和 Codex 干了这杯酒

2026-04-21T22:00:00+08:00

上一篇讲的是同一门《运营与供应链管理》的设施选址案例。那次比较干净：重心法有唯一解，让两个 AI 互评一轮，再用 Python 跑一遍，基本就能定谁对谁错。

这次不一样。第二次课后作业是经典的啤酒游戏（Beer Game）：零售商 → 批发商 → 制造商三级供应链，真实需求在第 2 周从 4 箱/周升到 8 箱/周，之后保持稳定，但由于信息失真和 4 周提前期，链路里层层放大。案例写到：到第 24 周零售商还堆着 75 箱、批发商还堆着 218 卡车量，而制造商在第 19 周库存已经冲到 93 批。

题目三问：

画出 1–24 周库存和订单图，解释牛鞭效应
分析牛鞭效应的影响、成因、对策
假设你是“聪明零售商”，给出最优订货策略，并算出你比“普通零售商”多赚多少钱

问题 1、2 偏定性，两个 AI 答得大体接近。真正分歧出在问题 3：Claude 最初算出超额收益约 500–1000 元，Codex 最初算出 7500–7900 元。差了一个数量级。

一开始的分歧，其实不只是一道算术题

两份答案的最优订货策略看上去很接近：第 1 周按常态 4 箱，第 2 周开始往上调，之后维持 8 箱/周的稳态。真正的差别只在一句话：

Claude：第 2 周订 12 箱
Codex：第 2 周订 8 箱

但光是 4 箱之差，不足以解释为什么一个答案多赚几百元，另一个多赚几千元。真正把两份答案拉开的，是背后的两个建模选择：

行为假设：第 5 周不可避免的 4 箱短缺，到底能不能在第 6 周作为 backorder 补卖？
收益口径：第 24 周普通零售商手上的 75 箱库存，到底是资产，还是在本题比较口径里被等效忽略掉？

事后看，双方真正争的不是“谁算错了”，而是“哪套假设和口径更适合这道题”。

第一轮：双方先各自为自己的答案辩护

我先让它们各自写一份对比报告：

Claude_VS_Codex_by_Claude.md
Claude_VS_Codex_by_Codex.md

这一轮的立场很清楚：

Claude 认为自己那份更合理，因为案例 PDF 第 6、7 周明确写了顾客会留下名字电话等货，说明 backorder 真实存在
Codex 认为自己那份更严谨，因为从 24 周现金流口径看，普通零售商第 24 周手里还有 75 箱库存，占着现金、卖得慢，财务上不能当成“已经实现的收益”

如果把两边都尽量善意理解，它们其实各有抓手：

Claude 抓的是案例行为证据
Codex 抓的是比较口径和现金占用

到这一步，我还不能明确说谁一定错。因为和设施选址那题不一样，啤酒游戏这道题在第 3 问里确实存在建模自由度。

第二轮：真正让局面收敛的，不是继续争观点，而是“用对方的尺子重算一遍”

第二轮我把两份对比报告再丢回去，让双方继续回应：

Claude_VS_Codex_Round2_by_Claude.md
Claude_VS_Codex_Round2_by_Codex.md

Claude 这一轮做得最好的一点，是它没有继续停留在“PDF 原文支持 backorder”这种事实争论上，而是直接做了一件更硬的事：

用 Codex 自己定义的口径，反算 Claude 的策略。

它的核心计算逻辑是：

如果第 2 周订 12 箱，那么：

第 5 周的 4 箱缺口先形成 backorder
第 6 周正好到货 12 箱
这 12 箱刚好覆盖“第 5 周积压的 4 箱 + 第 6 周真实需求 8 箱”
之后回到稳态，每周到货 8 箱、卖 8 箱
因而 期末库存仍然是 0

按这个路径，套进 Codex 当时自己采用的“收入 - 采购 - 持有成本”的 24 周现金流式口径，会得到：

口径	Claude 策略（W2=12）	Codex 策略（W2=8）
销量（箱）	188	184
收入（元）	23,500	23,000
采购（元）	17,600	17,200
持有成本（元）	9.23	9.23
现金利润（元）	5,890.77	5,790.77
期末库存（箱）	0	0

也就是说，在同一口径下，Claude 的第 2 周订 12 箱方案，比 Codex 的第 2 周订 8 箱方案多赚 100 元。这 100 元恰好就是多履约的 4 箱 × 单箱毛利 25 元。

这一步很关键，因为它把争论从“你觉得、我觉得”推进到了“就用你自己的尺子量，结果还是这样”。

第二轮之后，Codex 的主要修正也很明确

Codex 在第二轮里做了两个重要修正。

1. 承认原先的 7500/7900 元量级不合理

它接受了一个关键点：

不能把普通零售商第 24 周剩余的 75 箱库存直接按 0 价值处理。

因为案例并没有说这 75 箱永远卖不出去。真实需求仍然大约是 8 箱/周，这些库存更合理的理解是：

期末库存资产
后续持有成本负担
潜在的折价风险和资金占用

而不是立刻等于当期亏损。

这一步修完以后，Codex 把自己原先的“多赚 7500/7900 元”回收掉了。

2. 接受“第 2 周订 12 箱”作为基准更优方案

在允许并管理 backorder 的前提下，Codex 也接受了：

第 2 周订 12 箱
第 3～20 周每周订 8 箱
第 21～24 周订 0 箱

这个策略方向。

不过这里 Codex 也补了一句我认为很重要的限定：

这个“12 箱更优”的结论，最好显式写出前提：允许并管理 backorder。

我认为这是必要的，因为 PDF 确实证明了 backorder 现象存在，但它并不自动等于“第 5 周那 4 箱一定 100% 都能补卖”。所以更稳妥的说法，不是“无条件严格最优”，而是“在题目给定的聪明零售商设定下，作为基准解更合理”。

到最后，双方其实收敛到了什么？

如果只看“最后谁赢”，这个过程会被误读成：

Claude 证明了自己是对的
Codex 改口认输

但我觉得更准确的描述是：

双方最后在“主策略”和“收益量级”上基本收敛了，但在普通零售商对照组的具体重构数值上，还没有完全统一。

已经收敛的部分是：

第 1、2 问两边都能作为参考
第 3 问的基准策略应以“第 2 周订 12 箱”为主
这个策略的前提是：允许并管理 backorder
原先的 7500/7900 元 应判为口径失真，不再成立
更合理的收益量级是：几百元到一千元左右

但还没有完全统一的部分是：

Claude 版当前仍把中心值写成 727 元
Codex 修订后写成了基准 476 元，并把现实区间写成 500～1,000 元

这说明它们已经没有大的结论性冲突，但还保留着一个典型的“同方向、不同中心值”的建模差异：普通零售商路径到底按哪组重构数据来算。

一个小插曲：我自己也踩了“AI 不重读文件”的坑

这轮还有个挺好玩的插曲。

共识文件落完之后，我又让 Claude 再检查一次两份正式答案是否还有逻辑冲突。按道理说，这一步应该先重读最新版文件再比。

但它一开始并没有这么做。它直接沿用脑子里前几轮的旧印象，给了我一个“已经基本没问题”的判断。我后来自己去看文件，才发现：

Codex 的正式答案已经被修订过了
第 3 问的主策略、收益区间、口径说明都已经更新了
但 Claude 那次检查没有先读最新版，就直接开始比较

我后来让它重新读取文件，再做一遍结论，结果就正常了。

这件事让我挺警惕一件事：

AI 在多轮上下文里，不是只会“算错”，它也会像人一样偷懒地以为自己还记得文件长什么样。

所以现在我的默认流程变成了：

跨轮复核前，明确要求它重新读取目标文件
不接受“基于之前讨论我认为……”这种比较
文件类任务尽量让它把引用行号和当前版本一起报出来

这次复盘，对流程最大的启发是什么？

1. 有争议的题，不能只让双方“表态”，要让它们“同口径重算”

第一轮的问题在于，双方都能自圆其说：

Claude 说：PDF 支持 backorder
Codex 说：现金口径更保守

这两句话都没错，但都还不够“打穿”对方。第二轮真正让问题收敛的，是 Claude 改变了打法：不用自己的尺子，而是用 Codex 自己的尺子，去量 Claude 的方案。

这比继续争抽象原则有效得多。

2. 案例题里，分歧很多时候不是“算错”，而是“口径没统一”

设施选址那题属于“公式题”，ground truth 比较硬。

啤酒游戏第 3 问更像“建模题”：

backorder 怎么处理
期末库存怎么估值
普通零售商的路径怎么重构

这些都不是 PDF 直接给好的唯一答案，而是解释空间。

所以这种题最重要的不是先问“谁对谁错”，而是先问：

你们是不是用了同一套假设？
你们是不是在用同一套收益口径？

3. 最终共识最好落成文件，而且最好双方都落

这次最终比较清楚的阶段，不是嘴上说“好像差不多了”，而是双方都逐步把立场修正进文件：

Claude_VS_Codex_Final_Consensus_by_Claude.md
Claude_VS_Codex_Final_Consensus_by_Codex.md
以及修订后的 answers/啤酒游戏-案例解答_Codex.md

一旦文件更新，后续讨论就有了稳定落点。否则很容易出现“口头上已经同意了，原答案还停留在旧版本”的错位。

这道题本身也给了我一个额外收获

我觉得这次最有意思的，不只是“谁算赢了”，而是它把一个课堂上常讲、但很多时候很抽象的管理问题，演得特别具体：

同一个案例、同一份 PDF，只要口径和隐含假设不统一，最后得出的“结论”就可能差一个数量级。

这和牛鞭效应本身很像。牛鞭效应里，上游看到的不是“需求”，而是“需求 + 滞后 + 情绪 + 防御性下单”。这次两个 AI 一开始看到的也不是同一个“收益”，而是：

收益 + backorder 假设
收益 + 库存估值口径

所以最后真正值得记住的，不是 7900 还是 727，而是：

在供应链和管理分析里，先统一口径，再比较数值，往往比争谁的数字更大更重要。

尾声

AI 也会偷懒，也会划水。 而且不是个案，使用 AI 也是要走心的~

我是怎么让 Claude 和 Codex 帮忙完成课程作业

2026-04-20T22:00:00+08:00

这学期有一门《运营与供应链管理》，第二次课留了个案例作业：南方超级医疗设备公司的设施选址。题目不难，标准的重心法（Center of Gravity）单仓库选址问题，考的是套公式 + ROI 判断。

我照例先让 Claude 做了一份，给了一个看起来挺漂亮的参考答案。觉得不放心，开了一个新的会话用 Codex 再独立跑了一遍。拿到结果之后我愣住了：两份答案的思路完全一致，计算出来的最优坐标相差不大，但最终 ROI 正负相反、决策完全相反。

Claude：重心在 (7.42, 5.04)，年运输节约 $46,838，ROI −188%，结论：续租堪萨斯城，别搬
Codex：重心在 (7.58, 4.51)，年运输节约 $223,646，ROI +41.22%，结论：应当搬迁

两个都是基于同一份 PDF 案例、同一个重心法公式，怎么会算出一正一负？

左右互博：把裁判位置也交给 AI

我本来的计划是自己动手验算一遍，但看了一会儿发现这事没那么简单——重心法有两个版本（一次加权平均 vs Weiszfeld 迭代）、费率 R 的单位有两种理解（美元/担 vs 美元/担/英里）、外向成本又有两种建模方式。要真人判裁谁对谁错，我得先把讲义从头翻一遍。

懒病发作，我干脆把两份答案一起丢回一个新的 Claude 会话，原话是这样的：

你完成的解答位于：南方医疗设备公司设施选址_参考答案-Claude.md 我使用其他模型解答的结果和你基本不一致，虽然思路是相同的，结果位于：南方医疗设备公司设施选址-案例解答-Codex.md 请检查双方究竟谁的逻辑存在问题，并给出支撑理由，如有必要，请修正完善最终版本结论

注意这里：Claude 开新会话后其实是没有前次对话记忆的，所以这份 _参考答案-Claude.md 对它而言就是一份陌生的答案，和 Codex 的那份在它眼里是对等的。这样它就没有「维护自己面子」的心理包袱。

Claude 翻出了自己的错

它做的第一件事是去读讲义 PDF 里重心法的原始公式。这一步关键——它不是在两份答案的输出之间找分歧，而是把两者都对照原题和教材做 ground truth 校对。

几分钟后它给出了结论：

Codex 的逻辑正确，Claude 的参考答案存在三处方法论错误。

三处错误它一条条列了：

1. R 的单位错。 讲义里目标函数是 TC = Σ Vᵢ·Rᵢ·dᵢ，要求 Rᵢ 为「美元/担/英里」。案例表里给的是「美元/担（当前线路总费率）」，必须除以当前距离才能换算。案例原文第 2 页其实写得很清楚：「可估计出以仓库为起点的外向运输平均成本为 0.0235 美元/担/英里」——这句话就是在提示学生做单位换算。前一次 Claude 把这段忽略了，直接把美元/担当权重用，相当于把当前距离"二次放大"进了权重里，让远距离客户影响被高估。

2. 没迭代。 讲义 p.13 把步骤写得很明白：先用 X₀ = Σ(V·R·X)/Σ(V·R) 算一个初始坐标，然后根据 dᵢ 做 Weiszfeld 迭代直到收敛。前一次 Claude 算完初始坐标就收工了。

3. 外向费率结构错。 案例文本明确给了一个统一的外向均值 0.0235。前一次 Claude 反其道而行之，按每个客户的当前总费率和距离回推了每客户不同的每英里率。这会让 Chicago 显得每英里 0.050、Montreal 每英里 0.019，两者相差 2.6 倍——这种人为的不一致把新选址的外向成本虚推高了，把真实 $223K 的年节约压成虚假的 $47K。

这三处错误串在一起，合力把最优点错误地向东北拉偏、又错误地抬高了新址的外向账单，最终得到"别搬"的结论。Codex 在这三点上都是按讲义和案例原文来的。

用 Python 作第三个独立裁判

到这一步其实已经够了，但我让 Claude 再做一件事：别用自己的文字推理下结论，写段 Python 从头算一遍，以程序的数值输出为准。

下面这段是它写的（我稍微整理了一下）：

import math
k = 230.0  # 1 坐标单位 = 230 英里

# (V, R_per_mile, X, Y) — 内向用个别每英里率，外向统一 0.02346
nodes = [
    (61500,  0.01438521, 3.60, 3.90),   # 菲尼克斯
    (120600, 0.00791246, 6.90, 1.00),   # 蒙特雷
    (17000,  0.02346330, 0.90, 9.10),   # 西雅图
    (32000,  0.02346330, 1.95, 4.20),   # 洛杉矶
    (12500,  0.02346330, 5.60, 6.10),   # 丹佛
    ( 9500,  0.02346330, 7.80, 3.60),   # 达拉斯
    (29500,  0.02346330, 10.20, 6.90),  # 芝加哥
    (21000,  0.02346330, 11.30, 3.95),  # 亚特兰大
    (41300,  0.02346330, 14.00, 6.55),  # 纽约
    ( 8600,  0.02346330, 12.70, 7.80),  # 多伦多
    (10700,  0.02346330, 14.30, 8.25),  # 蒙特利尔
]

# 初始种子
X = sum(V*R*Xi for V,R,Xi,Yi in nodes) / sum(V*R for V,R,Xi,Yi in nodes)
Y = sum(V*R*Yi for V,R,Xi,Yi in nodes) / sum(V*R for V,R,Xi,Yi in nodes)

# Weiszfeld 迭代
for _ in range(100):
    nx = ny = d = 0.0
    for V,R,Xi,Yi in nodes:
        di = k * math.sqrt((X-Xi)**2 + (Y-Yi)**2)
        if di < 1e-6: continue
        w = V*R / di
        nx += w*Xi; ny += w*Yi; d += w
    Xn, Yn = nx/d, ny/d
    if abs(Xn-X) + abs(Yn-Y) < 1e-7: break
    X, Y = Xn, Yn

def TC(Xp, Yp):
    return sum(V*R * k*math.sqrt((Xp-Xi)**2 + (Yp-Yi)**2) for V,R,Xi,Yi in nodes)

print(f"optimum = ({X:.4f}, {Y:.4f})")
print(f"TC @ KC  (8.20, 6.00) = {TC(8.20, 6.00):,.0f}")
print(f"TC @ Claude(7.42,5.04) = {TC(7.42, 5.04):,.0f}")
print(f"TC @ Codex (7.58,4.51) = {TC(7.58, 4.51):,.0f}")
print(f"TC @ optimum          = {TC(X, Y):,.0f}")

跑出来的输出：

optimum = (7.5806, 4.5084)
TC @ KC  (8.20, 6.00) = 6,983,017
TC @ Claude(7.42,5.04) = 6,792,698
TC @ Codex (7.58,4.51) = 6,759,371
TC @ optimum          = 6,759,371

几件事一次性水落石出：

Weiszfeld 迭代收敛到 (7.5806, 4.5084)，和 Codex 的 (7.58, 4.51) 逐位对上
Codex 那份的 TC $6,759,371 在正确方法下也正好是最优值
Claude 前一份的 (7.42, 5.04) 在正确方法下 TC 是 $6,792,698——比最优值贵了 $33K/年，连局部最优都不是
堪萨斯城 TC $6,983,017 和题目给的 $6,982,104 差不到 0.02%（差异来自案例里距离和均值的四舍五入），说明用的参数都没偏

然后年节约 $223,646，减去每年 $10 万新增租金，一次性搬迁投入 $30 万，年 ROI 41.22%，远高于 25% 阈值。正确结论是应当搬迁。

然后它把自己之前写错的那份改了

我让它把修订版直接覆盖原文件，同时在文件顶上标注修订说明。它交出的文件顶部是这样的：

# 案例：南方超级医疗设备公司设施选址 —— 参考答案（修订版）

> 修订说明：本版本相对于初版修正了三处方法论错误——
> (1) 将运输费率 R 从「美元/担」换算为「美元/担/英里」；
> (2) 在初始种子 (X₀, Y₀) 的基础上补充 Weiszfeld 迭代；
> (3) 外向费率按案例原文统一取 0.02346 美元/担/英里，而非按客户回推。
> 修订后结论从「维持堪萨斯城」转为「应搬迁至 (7.58, 4.51) 附近」。

三个情景（Q1 基准、Q2 需求变化、Q3 费率上涨）的结论全部翻过来，ROI 从负值变成 41%–60% 区间，决策从"别搬"变成"都该搬"。

为什么「左右互博」比让单一模型深挖更靠谱

这件事让我后面做类似作业时固定下来了一套流程：一份答案让 A 模型做，一份让 B 模型做，再让 A 当裁判评 B，要求它必须回到原始材料（讲义/教材/题目原文）做 ground truth 校对，最后用 Python 当第三方复算。

为什么这么折腾？几个观察：

单一模型很难发现自己的方法论偏差。 如果我一开始就让 Claude 自己审自己那份答案，它大概率会在"既有框架"里找局部的算术错误，而不会去质疑 R 的单位、是否需要迭代这种框架本身的选择。Codex 那份答案的存在提供了一个不同的框架作为参照，这时候回到原题去校对才有意义。换句话说：两个答案的差异不在于谁算得更准，而在于把可能的解法空间暴露了出来。

当裁判比当选手更挑剔。 让 Claude 做题时它倾向于快速给出一个自洽的流程。让它当裁判时，它会去对照原文、逐字抠公式、做单位分析。同一个模型、同一个任务知识，输出质量差很远——角色不同，防御姿态不同。

Python 兜底是性价比最高的一步。 两个模型吵起来的时候，文字推理再漂亮也有可能都错。让它们最后落到一段可执行的代码上，数值一跑就有定论。这次 Python 确认 (7.5806, 4.5084) 是严格最优，也顺手把 Claude 自己给的 (7.42, 5.04) 彻底证伪了——文字说它"连局部最优都不是"显得没说服力，一行 TC(7.42, 5.04) = 6,792,698 > 6,759,371 谁都没法赖。

模型之间没有「面子」问题。 前面提到我没告诉新会话的 Claude 那份错答案是它自己写的。这是有意为之——同一个账号、同一个模型，它如果意识到是在审自己的作业，有没有可能措辞会软一点？我不敢保证。切掉身份线索，让它以陌生答卷的姿态去评，才放得开。

我有不担心的地方，也有担心的地方

不担心的是：作业本身是死题、有唯一答案、可以程序化验证。在这类场景下 AI + AI + 代码的组合已经比我自己从头算可靠得多——我自己算大概率也会在哪一步单位换算上犯 Claude 初版犯的那种错。

担心的是：不是所有作业都有"Python 可跑的 ground truth"。比如案例讨论题让写一份"定性分析报告"的时候，两个模型可能会写出两份看起来都通顺、实则都在偏差范围内的答卷，而我没有外部锚点去判对错。这种时候"左右互博"只能证伪明显的错误，不能正向保证正确。

但即便如此，让 AI 看它同行的作业依然比让 AI 看自己的作业要诚实。这是我这次学到的最实用的一招。

尾声

借助 AI ，我弄清楚了重心法为什么要迭代、为什么 R 必须是每英里率——这两件事要是我自己硬看讲义，大概率和 Claude 初版踩一样的坑。把作业交给 AI 之后，我反而把原理学得更明白了。

这件事我没推广到所有课——有些课的作业本来就是要自己算才算练到手（比如数理课）。但对那些"考的是方法，不是手算熟练度"的课，我现在的默认姿势就是两个模型互评 + 代码兜底。花的时间比自己硬做少得多，踩的坑反而更少。

下次有类似的折腾再来记录。

用 Cloudflare Worker + KV 给静态博客加一个浏览量计数

2026-04-19T23:00:00+08:00

上一篇换主题写完的时候，心里还有一个未了的念头：新主题把 Google Analytics 那坨早就停服的 UA 代码删了之后，整站就零统计了。写的时候没想太多，但上线一两天之后，每次点开自己的博客都有一种「在给空气写字」的感觉 —— 到底还有没有人看，哪篇被多读几遍，完全没有信号。

于是今晚继续折腾，给每篇文章加一个浏览量，顺带在页脚放一个整站 PV / UV。效果本身没什么稀奇，技术栈和取舍倒值得说一下。

静态站做计数的几种路子

博客源码在 source 分支，CI 构建后推到 gh-pages，GitHub Pages 托管。这个架构的好处是零运维、免费；坏处是 没有访问日志，GitHub 只在 Traffic API 里给 14 天的 top paths，而且要 OAuth 认证，前端根本用不了。

所以任何「在线计数」都得外挂。我考虑过的选项按接入门槛排列大概是这几类：

方案	接入	数据归属	可控性
不蒜子	粘两行 script	第三方	几乎无
GoatCounter 云版	注册、粘 script	第三方	有仪表板和 API
Umami / Plausible 自托管	要一台 VPS	自己	完全
Cloudflare Worker + KV	写个 Worker	自己	完全

这四类都想过。

不蒜子 是中文博客圈最常见的选择，粘两行 JS 就能在页面上显示数字。但它不支持写入初始值、不暴露 API，偶尔还会抽风（busuanzi.ibruce.info 服务不稳是老问题了）。更关键的是：刚删完一大票第三方脚本（GA、AdSense、Disqus）的新主题，再挂一个外链，心理上拧巴。

GoatCounter 其实是符合我审美的选择 —— 开源、隐私友好、有 API、能自建也能用云版。唯一拿不准的是国内访问 goatcounter.com 的稳定性，以及把读者数据托管给第三方（哪怕它是隐私友好的）仍然是「托管」。

自托管 Umami / Plausible 需要一台 VPS 常驻。对一个每月也写不了一两篇的博客，养一台 VPS 就为了这个，是过度消费。

Cloudflare Worker + KV 最终胜出。几个原因：

我本来就是 CF 用户（域名 DNS 在 CF），账号、DNS 都是现成的
Worker 免费档 100k 请求/天、KV 1k 写/天 + 100k 读/天，对个人博客是绰绰有余的天花板
边缘节点在国内延迟一般不差
Worker 是一张多用途底牌 —— 未来要做外链跳转计数、RSS 订阅数统计、简单的 webhook 都能复用同一套基础设施

唯一的缺点是要自己写代码、自己部署。但需求简单到几十行 TS 就能搞定，还换不来过度工程的烦恼。

先用 OpenSpec 把事情说清楚

跟上次换主题一样，动手之前我先让 Claude 用 OpenSpec 写了一份变更提案：

openspec/changes/add-article-view-counts/
├── proposal.md   # 为什么、要改什么、不改什么
├── design.md     # 技术决策与取舍
├── specs/        # 可测试的规范（分三个 capability）
└── tasks.md      # 38 条分步任务

好处和上次一样 —— 边界清晰。比如 design.md 里写死了几个关键决策：

计数口径 粗放全算：不按 IP 去重，不识别爬虫。我的需求是「大致知道哪些文章有人读」，不是给广告主看的精确数字
不做 time series：KV 里只存当前累计值。要趋势数据直接看 CF Dashboard 自带的请求图即可
UV 用 sha256(IP + 当日日期 + salt) 去重：每日盐轮换，不能反推原 IP，GDPR 友好
seed 在前端叠加：这是整个方案最值得单独讲的一点

seed 前端叠加：让老文章不从零起算

启用新计数有个心理坎：所有老文章（最早是 2013 年）都会从 0 开始。十三年前写的博文显示「0 次阅读」，哪怕它本来就没几个人读过，视觉上也很刺眼。

最直接的办法是在 KV 里预填一个初始值，让 pv:<slug> 从比如 3000 起算。但这样做有个恶心的地方：哪天想调整初始值（比如觉得这篇估高了），要从当前值里减掉旧 seed 再加新 seed，很容易算错。

我最终用的办法是 把 seed 放在前端：

// themes/stuhouse/static/data/view-seeds.json
{
  "install-bind-mysql-dlz":    3900,
  "debian-add-cnnic-ca":       3900,
  "pelican-custom-jinja-filters": 3900,
  "postgraduate":               300,
  "peril-of-laziness-lost":       0
}

前端展示时：

display = (seeds[slug] || 0) + realtime_pv_from_worker

这样做的好处有三点：

seed 在 git 历史里。想调整某篇文章的初始值，就是一次普通的 JSON 编辑 + commit，审计友好
数据层与展示层解耦。以后后端换成 GoatCounter / 自建服务，seed 逻辑一行不用改
新文章自动 seed = 0。JSON 里没这个 slug 就当 0，无需特殊处理

seed 数值本身来自一个简单的脚本 scripts/generate_view_seeds.py，公式是 max(评论数 × 120, 年数 × 300)。因为没导 Disqus 数据（懒得等那封导出邮件），实际跑的是纯年份兜底 —— 2013 年老文显示 3900 次阅读，2025 年新文显示 300 次，2026 年刚发的新文显示 0。不精确，但读起来自然。

Worker 侧：两个端点、几行代码

核心逻辑在 worker/src/index.ts，就两个路由：

// GET /v/<slug> → 单篇文章 PV 自增并返回
async function handleSlug(slug: string, env: Env) {
    const key = `pv:${slug}`;
    const cur = parseInt((await env.VIEWS.get(key)) || "0", 10);
    await env.VIEWS.put(key, String(cur + 1));
    return json({ pv: cur + 1 });
}

// GET /v/site → 整站 PV + UV
async function handleSite(request: Request, env: Env) {
    const ip = request.headers.get("CF-Connecting-IP") || "0.0.0.0";
    const today = ymd(new Date());

    // 站点 PV：粗放自增
    const sitePv = parseInt((await env.VIEWS.get("site:pv")) || "0", 10) + 1;
    await env.VIEWS.put("site:pv", String(sitePv));

    // 当日 UV：hash(ip + date + salt) 作 key 去重
    const hash = await sha256Hex(`${ip}|${today}|${env.SALT_SECRET}`);
    await env.VIEWS.put(`uv_today:${today}:${hash}`, "1", {
        expirationTtl: 60 * 60 * 48,
    });

    // 当日 UV size + 历史归档累计
    const todayCount = await countPrefix(env, `uv_today:${today}:`);
    const siteUvTotal = parseInt((await env.VIEWS.get("site:uv")) || "0", 10);
    return json({ pv: sitePv, uv: siteUvTotal + todayCount });
}

两件事值得注意。

KV 没有 atomic increment。上面的 get → +1 → put 在并发写入时理论上会丢计数。但这是个人博客，真并发极低，丢一两次也无所谓 —— 这正是「粗放口径」的含义。如果哪天真撞上高并发，再迁 Durable Object 就是，当下不过度设计。

UV 归档用 cron 做。每天 UTC 00:05 触发一次 scheduled 事件，列出昨日所有 uv_today:<date>:* key 的数量累加到 site:uv，然后把这些 key 删掉。这样 uv_today:* 只保留今天一天的数据，不会无限膨胀。

部署踩坑：custom_domain 的首次 deploy

整个部署靠 wrangler CLI 完成。wrangler.toml 填好 KV namespace id、secret 绑定、cron 触发器之后，一条 wrangler deploy 就能上线。但第一次配 custom_domain 时，我走了个小弯路。

原计划（也是 tasks.md 里最初写的）是老路子：先在 CF DNS 面板手工加一条 views.chenxiaosheng.com 的 A/AAAA 占位记录（任意 IP，重点是 Proxy 状态 orange cloud on），然后在 CF Dashboard 配置 Workers Routes 规则。

后来发现 wrangler 现在有更优雅的写法：

[[routes]]
pattern = "views.chenxiaosheng.com"
custom_domain = true

加上 custom_domain = true 这一行，wrangler deploy 会自动：

给这个子域创建 DNS 记录
向 CF 申请 edge 证书
把 Worker 绑到该 hostname

一条命令搞定 DNS + 证书 + 路由三件事，比老路子干净得多。

有个小注意点：首次 wrangler deploy 之前需要先 wrangler secret put SALT_SECRET，但 put secret 时会触发一次占位 deploy。如果 wrangler.toml 里已经有 custom_domain 配置而 DNS 还没就绪，会报错。保险做法是先把 [[routes]] 段注释掉，完成 secret put 和首次 deploy（会部署到 *.workers.dev），再取消注释重新 deploy 启用 custom domain。我踩过一次之后把这个顺序写进了 tasks.md。

前端：不到 50 行

前端逻辑全在 themes/stuhouse/static/js/views.js。页面加载后做两件事：

function showSiteStats() {
    fetch(WORKER_BASE + '/v/site').then(r => r.json()).then(data => {
        document.getElementById('site-pv').textContent = fmt(data.pv);
        document.getElementById('site-uv').textContent = fmt(data.uv);
        document.getElementById('site-stats-wrap').hidden = false;
    }).catch(() => {/* 静默 */});
}

function showArticlePv() {
    const slug = document.body.dataset.slug;
    if (!slug) return; // 非文章页跳过
    Promise.all([
        fetch(SEEDS_URL).then(r => r.json()).catch(() => ({})),
        fetch(WORKER_BASE + '/v/' + slug).then(r => r.json()).catch(() => null),
    ]).then(([seeds, pvData]) => {
        if (!pvData) return;
        const total = (seeds[slug] || 0) + pvData.pv;
        document.getElementById('article-pv').textContent = fmt(total);
        document.getElementById('article-pv-wrap').hidden = false;
    });
}

几个刻意的设计：

所有展示元素初始是 hidden 的，JS fetch 成功才 reveal。失败就保持隐藏 —— 禁用 JS 的读者看到的页面和接入前完全一致，不会出现占位符或半成品
两个 fetch 彼此独立，一个失败不影响另一个
数字用 Intl.NumberFormat('en-US').format() 加千分位，这行代码比 polyfill 轻多了
文章页由 <body data-slug="..."> 带出 slug；非文章页（归档、标签）body 上没这个属性，JS 直接跳过

加上 CSS 小样式和一个眼睛图标的 inline SVG，前端总共改动不到 50 行。

跑起来之后的样子

上线之后，页脚多了一行：

本站累计阅读 1 次 · 访客 1 人

点开最早那篇 2013 年的《配置 Bind 使用 MySQL dlz 模式》，meta 行变成：

📅 2013-09-09 · 约 3 分钟阅读 · 👁 3,901 次阅读

seed 3900 加上我刚刷的 1 次。整体效果自然，没有违和感。

观察几个刻度：

KV 免费额度：单次页面加载触发 1-2 次 fetch，按每日 100 个访客估算，一天产生约 200 次 write，远低于 1000/天的上限
延迟：Worker 冷启动毫秒级，国内访问通过 CF 边缘节点基本感知不到
CF Dashboard：免费账户自带的 Analytics 已经能看请求量、错误率、cron 触发记录，不需要额外仪表盘

写在后面

整套方案从 OpenSpec 提案到上线，节奏大致是：晚上跟 Claude 对了一轮选型、起草了 proposal 和 tasks，之后花了一个下午跑完 38 条任务里的 36 条（剩两条是明天早上验证 cron 和 UV 归档用的）。工作量其实不大，但过程里有两个体会想记一下。

seed 叠加这个 pattern 值得收藏。它把「初始化数据」这个一次性需求，从数据层（KV）挪到了展示层（前端 JSON），代价是每次渲染多读一个文件，换来的是可审计、可解耦、可迁移。同样的思路可以用在评论数迁移、积分系统初始化、任何「旧数据 + 新增量」的场景里。

CF Worker 作为静态站的「副引擎」很好使。它不改变「源码 + 静态输出」的主流程，却能把那些需要「一点点动态能力」的需求接住 —— 计数、跳转、短链、webhook、简单的 API 代理，都是十几行代码的事。很多人把「加动态能力」和「离开静态站」划等号，其实没必要。

至于今晚之前那个「在给空气写字」的感觉，暂时还没消失 —— 刚上线，KV 里真实数据也就一两条。但架构至少支持知道答案了，剩下的就交给时间。

Claude 在这个周末帮我翻新了博客

2026-04-19T20:30:00+08:00

上一篇《LLM 让程序员的编程美德「懒惰」更显重要了》发完没几天，自己倒先干了一件极其「懒惰」的事 —— 周六晚让 Claude 把博客主题从 2014 年的 Bootstrap 3 一路翻修到新写的 stuhouse。

折腾完准备写这篇更新稿的时候，想起前几天那次「双仓库合一」也是 Claude 陪着做的。两次经历放在一起回看，心里有些话想讲。

背景：博客的技术债从哪来

这个博客从 Pelican 起步就没怎么动过骨架，细数下来积了一堆账：

主题 pelican-bootstrap3 基于 Bootstrap 3.1.1，2019 年已经 EOL
FontAwesome 3 的 icon-* 前缀和后来加载的 FA 4.7 不兼容，图标基本不渲染
导航栏的 .navbar-collapse 没有汉堡按钮，移动端扩展菜单打不开
侧边栏被 hidden-xs hidden-sm 整体隐藏，手机读者看不到任何侧栏元素
还挂着一个 2023 年 7 月就停服的 Google Analytics UA 代码
存在 IE8 兼容分支（respond.js、jXHR.js、条件注释）
<html> 缺 lang 属性，DEFAULT_LANG='en' 和中文内容自相矛盾

虽然写的很少了，但每次打开博客都在心里念叨一句「改一下吧」，然后关掉浏览器。就这么好几年了。

案例一：双仓库合一

在讲主题之前，先倒回去讲一下更早的一次改造。

博客最早的源码放在 Bitbucket，GitHub 上的这个仓库 stutiredboy.github.io 只存构建产物。这种「源码 + 发布」分离的结构是早年从别人那抄来的，对当时的我来说是合理的：Bitbucket 支持免费私有仓库，GitHub Pages 又必须 public。

但维护起来很累：

每次写完文章要先 push 到 Bitbucket，本地 pelican content，再去 GitHub 仓库 push 生成的 HTML
两个仓库的 commit history 基本断裂，追溯改动很费劲
源码仓库没有 CI，发布靠手工

2026 年 4 月中旬，我让 Claude 帮我把这个流程整合了：所有源文件迁到 GitHub 这个仓库的 source 分支，gh-pages 分支改由 GitHub Actions 自动构建 + force-push。

提交记录里那条 Migrate Pelican blog source from bitbucket to single-repo structure 就是这次改造的结果。合并后的工作流简单了不少：

改完文章 push 到 source
Actions 自动跑 pelican content，推到 gh-pages
线上站就更新了

这次改造范围不大，但其实挺花时间，我自己拖了好几年没做。Claude 基本就是 prompt + 15 分钟的事情，包括 deploy workflow 的编排、.gitignore 的合并、content/extra/CNAME 怎么放都替我想明白了。

案例二：这个周末，换主题

这次范围大得多。

用 OpenSpec 先把事情说清楚

技术债那么一大堆，要是自己硬上，大概率会陷入「改一点发现另一个地方也得改」的泥潭，特别是改主题，人肉改起来是真累。这次换主题之前，我先用 OpenSpec 的工作流写了一份变更提案：

openspec/changes/modernize-blog-theme/
├── proposal.md   # 为什么要改、改什么、不改什么
├── design.md     # 新主题的视觉和技术决策
└── tasks.md      # 分阶段任务清单

proposal 里最关键的是 Non-Goals 那一段，明确写了「不引入站内搜索、不引入新评论系统、不做 PWA、不保留旧主题做 A/B 切换」。有了这段边界声明，后面实现的时候就不会被无关想法拉偏。

新主题 stuhouse

新主题目录是 themes/stuhouse，整体思路：

单列居中，正文最大宽度约 720 px
极简顶栏：站名、归档、简介、RSS、明暗切换
桌面宽屏（≥ 1200 px）右侧有 sticky TOC，移动端折叠
彻底去掉侧边栏，标签云迁到独立的 /tags.html
中文系统字体栈（PingFang SC → HarmonyOS Sans SC → 微软雅黑 → system-ui），零字体请求
暗色模式跟随 prefers-color-scheme + 顶栏手动切换，localStorage 持久化
代码块基于 Nord 配色，浅色、深色两套，带一键复制按钮

技术栈清理得更彻底：Bootstrap 3、jQuery、FontAwesome、respond.js、jXHR.js 全删；图标改成内联 SVG；Google Analytics / Disqus / AdSense 相关代码一并下线。

一个中间的小坑

周六 23 点开始挂着 claude 跑，周日早上起来直接可以人工验收了。按 Claude 提示启动 pelican --listen，浏览器打开 http://127.0.0.1:8000，样式完全不对（以下修复还是 Claude 干的）。

开发者工具一看：

GET https://www.chenxiaosheng.com/theme/css/main.css
=> [FAILED] net::ERR_BLOCKED_BY_ORB

原因是 pelicanconf.py 里 SITEURL = 'https://www.chenxiaosheng.com' 直接写死成生产域名，本地生成的 HTML 里所有资源链接都指向线上，自然加载不到新主题的 CSS。

Pelican 社区的标准做法是拆分 dev/prod 两份配置：

pelicanconf.py：SITEURL = ''，本地预览用，生成根相对 URL
publishconf.py：继承 pelicanconf，覆盖 SITEURL 为真实域名，CI 构建用

顺带把 GitHub Actions workflow 的构建命令从 -s pelicanconf.py 换成 -s publishconf.py。再跑 pelican --listen，样式全部到位。

归档

最后把 openspec/changes/modernize-blog-theme/ 迁到 openspec/changes/archive/2026-04-19-modernize-blog-theme/，这个变更就算完结了。tasks.md 里的每一项都对应真实的代码改动，想回溯某个决策随时能翻到上下文。

用 AI 修基础设施的一点体感

两次改造拉通一起看，有几点观察。

AI 缩短了「想做」和「开动」之间的距离。 双仓库合一这件事我拖了好几年，主题翻修拖得更久。之所以一直不动，是因为每次想起来都要估算「我得花多久」「会不会中途卡在某个坑里」。有了 Claude 之后，这个心理门槛明显降低：哪怕卡住，它能帮我很快试出方向，沉没成本低得多。

但 AI 不会替我做判断。 OpenSpec 这种「先写提案再动手」的节奏，核心作用是逼我自己把事情想清楚 —— Non-Goals 该写哪些、视觉调性参考谁、侧边栏留不留。这些决策 Claude 给不了，它最多帮我把判断落成代码。

「懒惰」这事，AI 和人的方向是反的。 上一篇文章里引用了 Bryan Cantrill 的观点：LLM 不受时间约束，没有「为未来的自己省力」的动机，放任它会让系统越滚越大。我这次刻意在 proposal 里写死边界，就是给它上一道缰绳。最终 stuhouse 的代码量比旧主题少了一大截，就是这个约束的结果。

尾声

这篇文章本身是在新主题下写的。预览窗口里看过去，正文宽度、代码块配色、TOC 高亮、复制按钮都按预期工作。写博客这件事本来应该只关心文字本身，过去那些年花在「发布流程怎么跑通」「主题哪里又坏了」上的精力，现在终于可以还给写作本身了。

LLM 让程序员的编程美德“懒惰”更显重要了

2026-04-15T21:30:00+08:00

本文基于 Bryan Cantrill 的博文 The Peril of Laziness Lost 进行半翻译半解读。

最近读到 Bryan Cantrill 的一篇博文，标题叫 The Peril of Laziness Lost（「懒惰」丧失之险）。Cantrill 是 DTrace 的共同作者、Sun Microsystems 前工程师、Oxide Computer 的联合创始人，在系统编程领域是教父级的人物。这篇文章从 Larry Wall 提出的「程序员三大美德」出发，讨论了 LLM 对软件工程的深层影响。读完之后觉得切中要害，值得展开聊聊。

程序员的三大美德

Larry Wall 在经典著作 Programming Perl（业界称为「骆驼书」）中提出了程序员的三大美德：懒惰（Laziness）、急躁（Impatience）和傲慢（Hubris）。

原文引用如下：

If we're going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We've all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine.

这三个词乍听像是贬义，但 Larry Wall 赋予了它们完全不同的含义。其中「懒惰」最为深刻：它不是说程序员偷懒不干活，而是说好的程序员会因为「懒得重复做同一件事」，从而被驱动着去构建更高层次的抽象，让系统变得尽可能简洁。

Cantrill 对此的理解是：懒惰驱使我们把系统做到尽可能简单（但不能过于简单）——去开发强大的抽象，从而让更多的事情变得更容易。

懒惰的悖论：偷懒需要付出大量努力

这里有一个精妙的悖论：要做到「懒」，其实需要非常努力。

当程序员看似在「摸鱼」——躺在吊床上发呆、盯着天花板想问题——实际上是在反复推敲问题的本质。这种「吊床驱动开发」（hammock-driven development）是真正的智力劳动。程序员愿意在当下花费大量时间去打磨抽象，是因为在优化「未来的自己」的时间。当这个计算做对了，效果是辉煌的：好的抽象不仅服务于自己，还惠及所有后来者。

换句话说，程序员的懒惰让软件更容易编写，让系统更容易组合，让更多人能写出更多好的软件。

Brogrammer 文化：虚假的勤奋

然而，过去二十年软件行业的扩张带来了一种不那么健康的文化。现代抽象带来的巨大生产力催生了一种对「虚假勤奋」的推崇——Cantrill 称之为 brogrammer 文化。在这种文化里，「吊床上的深度思考」被「crushing code」的鸡血叙事取代。人们不再关心抽象是否优雅，而是关心写了多少行代码、提了多少个 PR、一天搞定了几个 feature。

LLM：给 Brogrammer 注射类固醇

LLM 的出现，在这堆干柴上劈了一道闪电。

Cantrill 的原话是：LLM 就像 brogrammer 群体的合成代谢类固醇（anabolic steroids）。无论一个人对软件开发持什么态度，LLM 都能放大这种态度的力量。于是那些本来就痴迷于「产出量」的人，现在更加不可收拾了。

他举了一个例子：Y Combinator 总裁 Garry Tan 在社交媒体上炫耀自己一天写了 37,000 行代码，还说「仍在加速」。

Cantrill 不动声色地补了一句作为对比：整个 DTrace 项目的代码量大约也就六万行左右。

用行数衡量软件的价值，就好比用重量衡量文学作品的质量。这个谬误即便是初学者也看得出来。

Garry Tan 的「作品」被拆解

至于 Tan 用如此疯狂的速度构建的产物——一个「newsletter-blog-thingy」——波兰工程师 Gregorein 对其做了一次拆解。结果既意料之中，又令人捧腹：

单次页面加载就包含了多个测试框架（test harnesses）
混入了 Rails 的 Hello World 应用
藏了一个文本编辑器
同一个 logo 出现了八个不同版本，其中一个的文件大小为 0 字节

Cantrill 指出，问题不在于这些具体的 bug（它们都可以修复），甚至不在于有人认为这种方法论代表了软件工程的未来（虽然这确实很烦人）。

真正的问题是：LLM 天生缺乏「懒惰」这一美德。

核心论点：LLM 不懂懒惰

这是整篇文章最精华的部分。

对 LLM 而言，工作是零成本的。LLM 不会觉得需要为自己（或任何人）的未来时间做优化。它会毫不犹豫地往一个越来越高的垃圾蛋糕上继续堆料。如果不加约束，LLM 只会让系统变得更大，而不是更好——也许能满足某些扭曲的虚荣指标，但代价是所有真正重要的东西。

这恰恰凸显了人类的「懒惰」有多关键：正因为我们的时间有限，才迫使我们去开发精炼的抽象。 我们不愿意把自己宝贵的（人类的！）时间浪费在笨拙抽象带来的后果上。最好的工程总是源于约束，而时间的约束限制了我们愿意承受的系统认知负荷。这才是驱动我们把系统做得更简单的力量，尽管系统本身的复杂性是内在的。

LLM 不受时间约束，也不承受认知负荷，因此不能指望它们主动去追求简洁。

LLM 仍然是重要的工具

Cantrill 并没有否定 LLM 的价值。他明确说：LLM 是软件工程的非凡工具——但归根结底，它只是工具。

正确的使用方式是：

用 LLM 处理程序员「非美德性的懒惰」——比如帮助清理技术债务这类棘手但缺乏动力去做的事
用 LLM 提升工程严谨性
但这一切必须服务于程序员自身的「美德性懒惰」：产出更简洁、更强大的系统，不仅服务于当下的自己，也服务于未来一代又一代的软件工程师

个人感想

读完这篇文章，最大的感触是 Cantrill 精准地指出了 LLM 时代的核心矛盾：工具变强了，但使用工具的判断力并没有跟着变强。

LLM 让「写代码」的边际成本趋近于零，但「思考应该写什么代码」的成本一点都没降低。如果把 LLM 当成代码的自动生成器来追求产出量，最终只会得到一个体积庞大但内在混乱的系统。真正应该做的，是把 LLM 节省下来的时间投入到更深层的思考中去——去琢磨更好的抽象、更简洁的设计。

Larry Wall 几十年前提出的「懒惰是美德」，在 LLM 时代反而变得更加重要了。

参考

Bryan Cantrill, The Peril of Laziness Lost, 2026-04-12
Larry Wall, Programming Perl (The Camel Book)

.claude/ 文件夹解剖

2026-03-23T19:36:59+08:00

大多数团队都在某种程度上采用了 AI，但“使用 AI”与“从 AI 中获得可衡量的 ROI”之间的差距，比人们想象得更大。

Postman 发布了一份成本节省分析，评估了六种常见的 API 开发工作流，并对比了“平台内置 AI”与“外部加挂 AI”在实际时间和成本上的差异。

这是一篇简短、数据驱动的阅读材料，能帮助工程负责人判断：AI 原生工具究竟在哪些环节真正能撬动效率。

你可以在这里免费下载这份指南 →

感谢 Postman 今日赞助！

Claude Code 的用户通常把 .claude 文件夹当成黑盒。知道它存在，也见过它出现在项目根目录里，但几乎没人真正打开看过，更别说理解里面每个文件的作用。

这是个被错过的机会。

.claude 文件夹其实是你在项目里“控制 Claude 行为”的中枢。

它保存了你的指令、自定义命令、权限规则，甚至还有 Claude 跨会话的记忆。理解每个文件的位置和意义之后，你就可以让 Claude Code 完全按你团队的方式运行。

这篇文章会带你完整拆解这个文件夹，从你每天会用到的文件，到你只需设置一次就能忘记的部分。

在开始之前，有一点要先知道：实际上有两个 .claude 目录，而不是一个。

一个在项目里，另一个在你的 home 目录：

项目级的文件夹保存团队配置。你会把它提交到 git，所有人都用同一套规则、同一组自定义命令、同一份权限策略。

全局的 ~/.claude/ 文件夹保存你的个人偏好和本机状态，比如会话历史和自动记忆。

这是整个系统里最关键的文件。你启动 Claude Code 会话时，它第一个读取的就是 CLAUDE.md。它会被直接加载进系统提示词，并贯穿整个对话。

说白了：你写在 CLAUDE.md 里的内容，Claude 就会遵守。

你告诉它“先写测试再写实现”，它就会这么做。你写“禁止用 console.log 做错误处理，要用自定义 logger 模块”，它每次都会遵循。

最常见的做法是在项目根目录放一个 CLAUDE.md。但你也可以在 ~/.claude/CLAUDE.md 放一个全局偏好，甚至在子目录里放局部规则。Claude 会读取它们并自动合并。

多数人不是写得太多，就是写得太少。下面是合理的取舍。

建议写：

构建、测试、Lint 命令（如 npm run test、make build 等）
关键架构决策（比如“我们使用 Turborepo 的 Monorepo”）
不显然的坑（比如“TypeScript 开启 strict，未使用变量会报错”）
导入约定、命名规范、错误处理风格
核心模块的文件与目录结构

不建议写：

应该放在 Linter 或 Formatter 配置里的内容
已有文档、可以直接链接的完整说明
长篇大论的理论解释

把 CLAUDE.md 控制在 200 行以内。文件太长会消耗上下文，Claude 的指令遵循度反而会下降。

原文此处有一个“简短但有效”的示例（截图展示）。

大约 20 行，足以让 Claude 在这个代码库里高效工作，而不需要不断追问。

有时你的偏好只属于你本人，不适合全团队。比如你偏好某种测试框架，或者希望 Claude 打开文件时遵循某个固定模式。

在项目根目录创建 CLAUDE.local.md。Claude 会和主 CLAUDE.md 一起读取，但这个文件会自动被 gitignore，不会进入仓库。

CLAUDE.md 适合单一项目。但一旦团队扩大，你很容易得到一个 300 行、没人维护、人人忽视的 CLAUDE.md。

rules/ 文件夹就是为了解决这个问题。

.claude/rules/ 里的每个 Markdown 文件都会和 CLAUDE.md 一起加载。你可以按主题拆分指令：

每个文件都更聚焦、更容易更新。负责 API 规范的人只改 api-conventions.md，负责测试标准的人改 testing.md，互不干扰。

真正的威力在“路径作用域规则”。在规则文件里加一个 YAML frontmatter，就可以让它只在匹配路径时生效：

比如它不会在编辑 React 组件时加载，而只在处理 src/api/ 或 src/handlers/ 时生效。没有 paths 的规则会在每次会话中无条件加载。

当 CLAUDE.md 开始变得臃肿时，这就是正确的拆分方式。

Claude Code 自带一些内置斜杠命令，比如 /help 和 /compact。commands/ 文件夹允许你自定义命令。

你在 .claude/commands/ 里放一个 Markdown 文件，它就会变成一个斜杠命令。

比如 review.md 会生成 /project:review，fix-issue.md 会生成 /project:fix-issue。文件名就是命令名。

原文这里给了一个简单示例：创建 .claude/commands/review.md。

然后在 Claude Code 里运行 /project:review，它会自动把真实的 git diff 注入到提示词中。反引号里的 ! 语法会运行 shell 命令并把输出嵌入。这就是命令真正有用的原因，而不只是“保存一段文本”。

如果你需要传参，可以用 $ARGUMENTS：

运行 /project:fix-issue 234 会把 issue 234 的内容直接送进提示词。

.claude/commands/ 里的项目命令会提交到仓库，和团队共享。若想在所有项目通用，把命令放到 ~/.claude/commands/，它会显示为 /user:command-name。

一个很实用的个人命令：每日站会助手、按你约定格式生成提交信息、或者快速安全扫描。

你已经了解命令。技能看起来很像，但触发方式完全不同。先看这张图的区别：

技能是 Claude 可以自己调用的工作流，不需要你敲斜杠命令，只要当前任务匹配技能描述，它就会自动触发。命令是你手动触发，技能是它自动判断。

每个技能都在自己的子目录里，包含一个 SKILL.md：

SKILL.md 用 YAML frontmatter 描述“什么时候使用这个技能”。

当你说“帮我审这个 PR 的安全问题”，Claude 会读取描述，判断匹配，于是自动调用这个技能。你也可以显式调用，比如 /security-review。

和命令最大的区别：技能可以打包一堆辅助文件。上面提到的 DETAILED_GUIDE.md 就是和 SKILL.md 同目录的参考资料。命令只是单个文件，而技能是一整个包。

个人技能放在 ~/.claude/skills/ 下，跨项目通用。

当任务复杂到值得一个专门专家时，可以在 .claude/agents/ 定义子代理。每个代理是一个 Markdown 文件，包含它自己的系统提示词、可用工具、以及模型偏好：

下面是一个 code-reviewer.md 的样子。

当 Claude 需要做代码审查时，它会在独立上下文里启动这个代理。代理完成工作后会压缩结论再汇报，这样你的主会话不会被几千 tokens 的中间过程撑爆。

tools 字段限制代理能做什么。安全审计只需要 Read、Grep、Glob，完全不该写文件。这个限制是刻意为之。

model 字段让你选择更便宜、更快的模型来做聚焦任务。Haiku 处理读操作够用，把 Sonnet/Opus 留给真正需要能力的地方。

个人代理放在 ~/.claude/agents/ 下，跨项目可用。

.claude 里的 settings.json 控制 Claude 允许做什么、不允许做什么。它定义了哪些工具可以用、哪些文件能读，以及哪些命令需要先询问。

完整文件长这样（原文此处为截图）。

各部分的含义如下：

$schema 行开启 VS Code 或 Cursor 的自动补全与校验，务必保留。
allow list：允许 Claude 无需确认即可运行的命令。典型选择包括：
- Bash(npm run *) 或 Bash(make *)，让 Claude 能自由执行脚本
- Bash(git *)，用于只读 git 操作
- Read、Write、Edit、Glob、Grep 等文件操作
deny list：无条件禁止的命令。合理的 deny list 会阻止：
- 破坏性命令，比如 rm -rf
- 直接网络命令，比如 curl
- 敏感文件，比如 .env 和 secrets/

不在 allow 或 deny 列表里的命令，Claude 会先询问再执行。这种“中间地带”是有意设计的：既有安全网，又不需要你预判所有命令。

另外你也可以用 settings.local.json 做个人覆盖。创建 .claude/settings.local.json，它会被自动 gitignore，不进入仓库。

你很少手动管理这个文件夹，但最好知道它们存在。

~/.claude/CLAUDE.md 会加载到每个 Claude Code 会话里，跨项目生效。适合放你的个人编码原则、偏好风格等。

~/.claude/projects/ 保存项目的会话记录和自动记忆。Claude Code 会把它学到的命令、模式、架构信息自动存下来并跨会话保留。你可以用 /memory 浏览和编辑。

~/.claude/commands/ 和 ~/.claude/skills/ 保存你的个人命令和技能，跨项目可用。

你通常不需要手动整理这些，但知道它们的存在很有用：当 Claude 看起来“记住”了你没明确说过的东西，或者你想清空某个项目的自动记忆、重新开始时，就知道该去哪。

最后把一切串起来：如果你从零开始，以下步骤非常实用。

Step 1. 在 Claude Code 里运行 /init，它会读取项目并生成一个初始 CLAUDE.md，然后你把它精简到关键点。

Step 2. 添加 .claude/settings.json，设置合适的 allow/deny 规则。至少允许运行命令，禁止读取 .env。

Step 3. 创建一两个最常用的命令，比如代码审查或修复 issue。

Step 4. 当 CLAUDE.md 变拥挤时，把指令拆到 .claude/rules/，并按路径做作用域。

Step 5. 在 ~/.claude/CLAUDE.md 写入个人偏好，比如“先写类型再写实现”“更偏函数式而不是类”。

这对 95% 的项目已经够用了。技能和代理只在你有反复出现的复杂工作流、值得打包时再引入。

.claude 文件夹本质上是一套协议：告诉 Claude 你是谁、项目做什么、它需要遵守哪些规则。定义得越清晰，你纠正 Claude 的时间就越少，它做的有用工作就越多。

CLAUDE.md 是你杠杆最大的文件。先把它写对，其他都是优化。

从小做起，逐步精炼，把它当成项目里的基础设施：一旦搭好，每天都会持续带来收益。

感谢阅读！英文原文：https://blog.dailydoseofds.com/p/anatomy-of-the-claude-folder

阿里云域名解析被转移，让我穿越回了 15 年前

2025-06-06T20:30:00+08:00

2025 年 6 月 6 日早上 6 点 10 分醒来，习惯性瞄了下手机，看到同事给我的留言，大概是说 aliyuncs.com 被别的国家注册了

作为一名曾经的域名管理员，我对域名类的故障是比较 敏（害）感（怕） 的，因此基本上我是短时间就清醒了的，抛出了我的第一个疑问：在用的域名忽然被别人注册了？

同事反馈是过期没续费被抢，但是 域名过期是有保护期 的，所以我并没有接受这个说法，在手机上通过 who.is 查了一下信息，发现过期时间是 2026-04-01，既然都还没有过期，那被别人注册了这个说法自然是不成立的。

继续追问了下目前可能对我们公司业务的影响，了解到如果负载均衡 LB Load Balance 有可能直接用了阿里的域名，这下我就不太淡定了，继续用 itdog 试了一下，发现有个别缓存开始失效了。结合可能对我们的影响，这下真的无法淡定了，立马起床开电脑干活！！

考虑到 whois 也会有缓存，赶紧登录自己在欧洲的一台机器重新查了一下，果然发现阿里 aliyuncs.com 的域名被人更新了（而不是被别人注册了），可以看到更新时间是 2025-06-05T21:32:38Z ，考虑到时区，和阿里通告故障的时间是基本对的上，域名、whois 都会有缓存，有一定时间差是符合常理的。

这个时候肾上腺激素开始飙升了，立马让在线的同事开工干活，主要几个动作：

第一时间把涉 aliyuncs.com 的域名捞出来，并整理成共享文档，供接下来使用；
唤醒公司域名管理员，对于我们自建 DNS 这个服务本身，如果使用了阿里 LB 的且评估是对其他业务提供服务的，马上切走。（如果我们的 DNS Server 受这个 LB 影响不可用了，这个时候爆炸半径会直接无限扩大）
域名管理员，发起紧急变更，将缓存 DNS 服务器上关乎 aliyuncs.com 这个域名的解析全部转发劫持到阿里云的权威，确保内部业务能正常解析，尽可能缩小爆炸半径；
根据服务等级，除了在相关工作群通告外，根据服务重要等级唤醒相应运维（或相应域名对应的管理员），并让他们安排将 aliyuncs.com 的业务先切到 VIP 地址；

中间还是会有一些小插曲，比如可能指引不够详细，有运维同学对于域名没有概念或者有同学所涉业务较多，有点手忙脚乱之外，整体还算快速、稳步的推进，更多的细节就不展开了。

当然，这里最终还是要给阿里云的团队点个赞，原以为这个故障时间会远超预期，然后我们在北京时间 08:14 收到反馈说经过阿里云团队的处理，域名解析开始恢复正常了，故障持续的时间大约为 6 小时左右。再加上故障发生在凌晨，另外域名解析的失效也有一个缓存的过程，不幸中的万幸就是我们基本没有受到影响（但是对不起，炸了一群人起来干活 :p

基本没有，也不是完全没有，但都在可控范围内 :-)

15 年前的鬼故事

在响应这个故障的过程中，就有同事问我是不是我们曾经也出现过这个问题，很肯定的说“是”，但也不是，情况不太一样。在这个时间点，我对于阿里云为什么 NS namesever 被改了还是不清楚的，只是猜测大概率是管理不善，帐号被黑客拿走改了 NS 之类~~ 而我们当年（约 15 年前）碰到的一个情况是被注册商（比如万网、NetworkSolutions）以涉敏感内容为由停止了解析，但阿里云 aliyuncs.com 的症状对不上。

说明一下，涉敏感内容肯定和公司没有直接相关，不展开，避免被有心之人用来作为攻击手段，也不确认该方式是否还有效

当时也是发生在凌晨（时差，美国佬刚好上班之类），年轻睡的晚，本来也想睡觉了，鬼始神差的觉得好像不太对劲，开电脑查了一下发现解析被停掉了，多次用我鳖脚的英文和 NetworkSolutions 对线（感谢那时候有 Skype 等软件可以打国际电话），辗转折腾，在多路大佬的帮助下也是差不多在白天业务高峰前才恢复解析，但毕竟是我们的核心域名，加上时间也是大几个小时，不少地方的缓存失效了，影响还是很大的（最后被某位大佬点赞了 hhhh

说说我的害怕

前面说到作为一名曾经的域名管理名，我对域名类的故障是比较敏（害）感（怕）的，这是为什么呢：

DNS 是互联网最基础的业务之一，但凡在互联网上能提供的业务大概都离不开这个基础。越是基础的东西伤害就越大；
基础的服务受关注程度低，大家都默认你正常，所以确实出问题的概率也极低，因为你不敢经常出问题。但带来的问题是所有上层业务都默认你正常，在设计的时候就不会去做过度容灾，一出问题短时间就是解决不了（但确实有时候为了一个极低概率出问题的系统做过度的容灾，不考虑 ROI 也是有毛病的表现。。。
因为 1 和 2 的情况，业务和业务，经年累月下来，你根本改不了。就像现在，你不可能拿出一套系统取代 TCP/IP、取代 DNS，哪怕 IPv4 要进化到 IPv6，这个我从读大学就被这么画大饼了，20 多年过去了，也没见 IPv6 就把 IPv4 干掉了
（价值论）通常在大多数公司里，基础服务的价值讲不清楚，上层建筑容易画大饼讲故事，也有快速创造收益的可能。像我这种做基础设施的，都要经常停下来反思我这点收入真是得之不易，劳心劳命的，然后给自己找到自洽的逻辑，继续努力~
域名的爆炸半径不可控，一方面是因为我们不可能去刷新世界上所有的缓存（运营商大多数情况下也不会鸟你），同时我们也没有办法让用户在出现故障时，让他们切换到另一个域名（如 HttpDNS 等方案这些都只能解决特定场景下的特定问题），另外 缓存是个双刃剑，它能延缓故障的爆炸，却也会让你在宣告解析恢复后要经受不停的挑战，为什么我的服务一直没有恢复？就像这次我们 直到北京时间 13:57 才收到业务反馈说运营商的缓存基本都过期不再报错了，大概是阿里云宣告恢复后的又一个 6 小时

当然，你也可以认为我过度紧张 :-)

小结

阿里云此次 aliyuncs.com 的故障真实原因是什么？这个我也不知道，但从网络上的蛛丝马迹上看是被 VeriSign（不是注册商，是 .com 顶级域的管理）改了域名解析，不考虑更深层次更腹黑的原因，只能猜测是因为阿里云有不合规的内容被投诉了之类。如下一些公众号的猜想：

作为域名的拥有者，有没有可能完全杜绝这个问题？我认为不可能，这次看起来是 VeriSign 操刀的，也就是直接绕开注册局（商）了。包括有些朋友可能会认为加一些注册局锁（类似 serverUpdateProhibited 这些）可能可以缓解，我可以很肯定的说这 只能解决到注册局层面的问题，覆盖不了本次的情况 。当然阿里云做为一家国际云商， 注册局锁这点钱你们就不要省啦 （事后也看到阿里云加上了）：

技术上能不能解决：能，但成本不知几何。鼓励大家在业务上线的时候通过多入口容灾、引入 HttpDNS 等技术解决类似问题，但是当类似问题出现时，影响还是不可避免，手忙脚乱也还是不可避免，毕竟 N 年等一回，但最好一回也不要有，害怕
可能有其他非技术非常规手段，可以从根服务器、顶级域名运营商开始实施保护，但想像不了了，请了解规则的朋友指点哈

Obsidian 接入 DeepSeek API 指南：Text Generator 插件配置教程

2025-05-12T15:07:00+08:00

以下是 Obsidian 接入 DeepSeek API 的配置教程，使用 Text Generator 插件实现智能文本生成功能。教程使用 Text Generator 插件 + DeepSeek API 生成，并经过人工校对：

1. 安装 Text Generator 插件

打开 Obsidian → 点击左侧边栏 Settings (设置)或菜单栏 Preferences
进入 Community plugins (社区插件) → 点击 Browse
搜索 Text Generator → 安装并启用插件。

2. 获取 DeepSeek API Key

访问 DeepSeek 官网注册/登录账号；
进入 API 管理页面（如无公开API，需联系官方申请权限）；
复制生成的 API Key（保存到安全位置，后面无法通过 deepseek 平台查看）；
充值（很重要，否则后面会出错）

3. 配置 Text Generator 插件

在 Obsidian 中打开 Settings → 找到 Text Generator 插件设置。
在 API Provider 中选择 Custom 或 通过+创建自定义配置（若支持）。

注：如上截图，已勾选的 deepseek 是通过后面的 + 创建出来的。
填写以下参数：
API URL: DeepSeek API 的端点地址（如 https://api.deepseek.com/chat/completions）
API Key: 粘贴你的 DeepSeek API Key
Model Name: 填写模型名称（如 deepseek-chat，根据官方文档调整）

4. 测试 API 连接

在 Obsidian 中新建一个笔记，输入内容并选中；
按快捷键 Ctrl/Cmd + J 即可自动生成；
观察是否返回 DeepSeek 生成的文本，若无响应请检查：
API Key 和 URL 是否正确
网络是否畅通
DeepSeek 账户是否有足够配额

5. 高级设置（可选）

自定义提示模板：在插件设置中修改 Prompt Template，适配你的工作流。
调整参数：如 temperature（随机性）、max_tokens（生成长度）等。

常见问题

Q: 插件报错 n.text is not a function？
A: 在插件的 Advance mode 里把 CORS Bypass 打开
Q: 提示 404 或者 Not Found 之类 A: 确认 API 地址（Endpoint）填写正确，如这里是：https://api.deepseek.com/chat/completions
Q: 提示 402 或者 Failed to load resource 之类 A: 先充值！
Q: 如何查看其他报错的详细信息 A: MacOS，使用：Cmd+Option+I 打开控制台查看

通过以上步骤，你可以在 Obsidian 中无缝调用 DeepSeek 的 AI 能力。如果需要更详细的配置（如本地代理），可参考插件官方文档或 DeepSeek API 说明。

25非全考研，人生经历+1

2025-04-13T06:30:00+08:00

23年去华工和D老师/泰老师吃饭闲逛的时候，脑子一抽想到要不干脆我也来考个研算了，但因为离国家统考的时间确实太近了，花80块钱报了名，完全没有时间准备，最后也是不了了之。但念头有了之后，却是挥之不去了，24年春节后，就默默开始准备起来了，25年4月把复试的流程走完，也进入了“拟录取”状态，小记一下人生的的经历。

为什么想考研

考研再读书的想法来的快，却挥之不急，首先还是和个人性格有比较大的关系，当我想到要去做一件事情的时候，总是会想着各种办法去实现，小到种草一件商品，大到买车买房等，只要我确定了我就会很快的想办法去实现。这个性格其实在生活、工作中给我带来了不少的好处的，坚持、靠谱、敢于接受挑战的各种评价大抵来源于此，但实际上却也经常让我个人陷入一些困境的，所谓的”内耗“。但无论如文，考个研读个书的想法真是”野火烧不尽，春风吹又生“，那就实现他吧，黄沙百战穿金甲，不破楼兰终不还。除了性格的原因，想考研读书也是受到方方面面的影响：

1、受益公司的战略调整，这几年开始有机会招聘海外的一些员工，在面试过程中就发现很有意思且很频繁的一个现象，海外同学（这里指坡县）经常会在工作一段时间后又回到学校，再出来工作，如此反复的这么一个过程。让我从“惊讶”进入到了”羡慕“，毕竟在国内要是我们的工作简历上频繁的出现”GAP“，那大抵是不受待见的。甚至于除了”铁饭碗“类的岗位，在大多数行业（比如互联网），虽然大家鼓励学习、知识的沉淀，但对于学历的追求，可能也会得到一个”有什么用呢“的反问？和海外这些员工的接触给我种了草，其他人的想法并不重要，这是让我觉得会有趣的一个经历，那就去试试吧！（谢谢我的热爱学习的同事们） 2、我不知道公司或者整个社会有什么问题，但知道我所在公司的朋友，也应该会关注到我所在的公司这两年也是各种”风起云涌“，口罩后的大家过的都不容易，对于我自己的岗位，从23年开始直到现在，我也一直是抱着背水一战，破釜沉舟的心态，可是当真的走到这一步的时候，我能做些什么，我真的没有想好。小学中学大学十六载，工作近十八载，如果有这么一个窗口，那么我想停一下看一看，也好好想一想接下来的路怎么走（毕竟40岁的互联网人那可太不被待见了啊，哈哈哈），但却并不想让自己无所事事，因此给自己一个重新学习的机会也成了自己一个很好的可选项，给自己一个暂停键，还可以充充电（算不算在逃避呢？嘿嘿）

想到了就去做，而且这次我还算是做了一个和自己性格相逆的”玩法“，早早我就告诉朋友、同事我要去考个研（以前这种人生大事怎么可以告诉大家，都是默默搞定他，免得丢人，哈哈哈），人生海海，何妨让世界听见我的号角？

备考

要说花了很多的时间备考，好像也没有，毕竟日常确实太忙了，基本都是利用周末的时间以 1.5x 甚至 2.0 的倍速刷一下视频，让自己有点印象，其实最担心的无法就是到了考场一个字都蹦不出来。非全日制工商管理类（我报了工程管理）国家统考其实就考两科《管理类综合能力》和《英语（二）》，对于我个人来说，英语其实没啥好准备的（口语不行，但阅读理解却是我的强项），主要时间还是用于学习管综了，买了中公教育的历年真题，这套真题有个好处是看不懂的题目可以刷二维码有视频学习，这对于已经离开学校18年，各种知识已经还给老师的中年人实在是太友好了！当然，这些课程的学习纯粹是为了“应试”，但好在也不是一无事处，有两点收获还是值得回味一下的：

1、算是把初中的一些数学知识重新学习了一下，涉及到基础的几何知识、平面直角坐标系、概率等等的一些知识，家里刚好有一个初中娃，被他问起来的时候显得我没有那么落伍，被我装到了； 2、学到了一个应试技巧，考试时先把”论说文“和”论述文“两篇文章写了，两篇文章只要完成度高，前面的数学题、逻辑题蒙个一半，那基本上也大差不差了。英语在考前找了几个公众号看了下英语写作的模板算是最大的准备了。逻辑题我个人就会认为纯粹就是为了考试而考试设计的各种绕口令了，总之绕晕你就对了（实际我也没有做完，至少有10道选择题就是蒙猜了），当然正能量一点，我找 DeepSeek 讨论了一下对于“逻辑题”的看法，它给出了正面反馈：

考试

考试的仪式感还是很强的，除了文具其他随着携带的东西都是在考场区域外保管的，进考场区域和考室也是面临层层安检。更有趣的是，当天也算是一边考试一边加班了，进考场区域的前 5 钟还在打电话安排和汇报工作。中午和下午考完出来的 5~10 分钟内都有电话和 IM 信息过来的灵魂拷问：“怎么我回信息这么慢的？”（真是紧张又不失有趣啊，肾上腺激素彪升，懂的都懂，哈哈哈，真心感谢当天紧急提供协助的同学们）所幸，流程算是走完了，这个考试状态感觉要凉，哈哈哈，但好在自己并不焦虑，好像有点祛魅了，原来就是这么一回事！

复试

成绩出来后其实并不理想，管综考的比较烂，英语算是拉了我一把，工程管理国家线 162，吹牛的说法是咱超了国家线近 30 分，其实一点都不理想，我所报考的学校计划招生 40 人，我排名 61，是否能进面试其实是比较悬的，最后算是有惊无险，进了复试。复试至少准备上是比初试统考用心了的，在复试通知出来的时候才发现竟然要考一门专业课，足足用了两周下班后的晚上和一个完整的周末在B站刷视频课程学习，专业课和面试的过程就不具体展开了，毕竟用官方的说法这应该属于泄密。但是回到学校复试的感受还是不一样的，走在学校的小路上，看着来往的学子和有着年头的建筑，想重新回到学校的念头还是非常强烈的。所以在对话的一开始还是略微紧张的，但也算是很快调整过来了的，复试的成绩还不错，最后总成绩把自己从 61 拉到前 30 了。因为官方的通告都是 PDF 的，让 DeepSeek 帮忙分析了下：

知识若有趣，前路自有光

至此，非全研究生的考试算是把整个流程走完了，虽然感觉对整个过程是祛魅了，但大抵自己还是会考虑这项“投资”把后面三年的学习流程走完的。印象有点深刻的是最近和同学朋友聚餐时，提到我要去读书，结合我所在的行业（学历已经没什么帮助了）、年龄（中年大叔）、学费（一年5个）、学习方式（非全日制，低人一等？），从部份朋友的眼神里看到了惊讶和不解。但我在复试专业课的准备过程中却看到了知识的趣味性、系统性、延续性，很多工作中看到的现象碰到的问题，原来可以大量使用课程里的原理、逻辑、方法加以解释（如果回到大学，我的想法一定会是这些大道理有什么意义啊？），既然这么有趣（又有挑战，听说这个学校即使非全的按期毕业率低于30%），那就让游戏继续下去吧，这应该是人生最后一次进校园的机会了？

中午逆旅，莫听穿林打叶声，何妨吟啸且徐行。

2025.04.13 06:30

你想要建造自己的数据中心吗？

2025-01-20T13:07:00+08:00

原文来自：https://blog.railway.com/p/data-center-build-part-one 很少看到有从 IDC 基础设施开始写的文章，一时兴起借 AI 工具作了粗浅的翻译。

从一开始，Railway的计算能力就是建立在谷歌云平台之上的。该平台支持了Railway的初步发展，但它也引发了许多问题，这些问题给我们的业务带来了生存风险。更重要的是，构建在超大规模云服务提供商上，阻碍了我们为客户提供最佳平台的可能性。

它直接影响了我们能够提供的定价（有人知道公有云流出流量费用吗？），限制了我们能够提供的服务级别，还引入了工程限制，这些限制了我们能够构建的能力。

我们不仅很少能理解上游环节出问题的原因，而且尽管我们每年花费数百万美元，但能得到的支持也只相当于你花费100美元所得到的。

因此，我们去年启动了一个 Railway Metal 项目。九个月后，我们在加利福尼亚的第一个站点上线，设计、规划并落地了从机柜中的光纤电缆到与互联网服务提供商的各种合同的一切。就在我们发布这篇博客的时候，我们正在启动另外三个区域的数据中心。

为了向我们的客户提供“透明基础设施”的云体验。我们需要迅速且足够好的构建我们自己的物理基础设施。这就是我们今天博客文章的主题。

所以你想要搭建自己的“云”

从 2024 年 1 月启动 Railway Metal 项目开始，我们花了整整五个月时间才将第一批服务器接入。之后，又用了额外的三个月，我们才觉得可以让用户放心地使用这些硬件（并且又过了几个月，我们才开始在这里撰写相关的内容）。

第一步是找到合适的地方。

本地部署时，你需要有地方来放置你那些崭新的服务器以及可靠的电力来保持它们运行。另外，你还需要足够的冷却措施，防止它们“熔化”（保障服务器正常运行）。

一般来说，你有三种主要的选择：绿地建设（购买或租赁数据中心）、机笼托管（在供应商的数据中心内获取一个由网格墙围起来的私人空间）、或者机架托管（租赁托管数据中心中的单个机架或机架的分区）。

这句话的意思是：“我们选择了第二种选择：一个笼子，它能给我们四面墙、一扇安全的门，以及一个空白的画布，让我们可以自由地设计其他一切。

租用或购买足够的空间来放置设备等并不是主要的成本支出，电力（以及由此带来的冷却需求）却是成本最高的部分。根据地理位置的不同，每千瓦时（$/kW）的电力价格可能会有很大的差异。--举个例子，在美国西海岸，我们支付的电力费用可能不到在新加坡支付的一半。电费是按照固定的月度承诺来支付的，无论是否实际消耗，都要支付这笔费用，以确保电力可以随时按需使用。

但是你需要多少电力呢？

能力越大，责任越大

理想情况下，如果你已经开始了数据中心迁移的任务，你应该对想要部署的计算资源数量有一个大致的概念。我们开始时设定了虚拟CPU（vCPU）的数量、内存容量（GBs）以及NVMe（一种高速存储设备）容量（TBs）作为目标，以匹配我们在谷歌云平台（GCP）的容量。

经过一系列指标、数据的分析、比较等过程，我们最终确定了合适的服务器和CPU。计算过程有很多因素、参数等可供选择、调整--甚至于都值得另外写一篇文章了--但对我们来说，最重要的因素是功耗密度。例如，我们如何在特定的功耗范围内获得我们想要的计算密度。

功率计算并不像简单地把瓦数加起来那么直接，尤其是涉及到三相电的情况。Cloudflare有一篇很棒的博客文章详细阐述了这个主题。

电力是数据中心最为关键的资源，一旦电力中断，可能需要数小时甚至数天才能完全恢复正常的运营状态。所以冗余是非常关键的，对每个机柜来说，两路独立的电力接入至关重要。在正常运行时，这两个独立的电源线路会共同分担机架设备的负载，共同为设备提供电力。这样可以保证电力供应的稳定性和效率。然而，更重要的是，这种设计必须能够抵御其中一个电源线路发生故障的情况。即使其中一个电源线路出现故障，另一个电源线路也能够立即接管全部负载，确保机架设备的持续运行，而不会因为电源故障而导致设备断电。

为了将这种电力传输到你的服务器上，你还需要一个电源分配单元（PDU），你需要根据它提供的插座数量和管理功能来选择它。基本款的 PDUI 就像是升级版的延长线，而我们部署的 PDU 则能够实现对每个插座的控制和计量。

凭借前面提及的相关能力，现在机柜里面可以正常供电了。

上帝说要有光

没有一台云机器是孤立存在的，这就是网络发挥作用的地方。

为了在Railway上实现尽可能低的延迟，我们需要为你建立到世界各地的稳定连接。

我们寻找的数据中心要具备与顶级（T1）互联网服务提供商（ISPs）处于同一网络、属于互联网交换点（IX）的一部分以及有可用光纤连接到附近其他数据中心等特性。

部署到Railway的应用程序会想要通过网络连接到各种各样的端点，无论是位于澳大利亚悉尼的家庭互联网用户，还是托管在美国AWS服务器上的API。为了给您提供尽可能低的延迟和最低的带宽成本，我们会与针对每种使用场景优化的多种互联网提供商签订合同

我们在选择互联网服务提供商（ISPs）时，会考虑它们在我们目标地区的网络成熟度。如果在一个地区选择了不合适的ISP，可能会导致到达特定目标的网络路径出现额外的网络跳数（从而产生延迟），或者在最糟糕的情况下，出现复杂的网络路由。因此，为了确保网络服务的质量和可靠性，我们会根据它们在各个地区的网络覆盖范围来选择至少两个不同的网络。

一旦连接建立，我们会从每个互联网服务提供商（ISP）那里接收完整的互联网路由表并将这些路由表整合到我们的网络交换机上以便为每个IP前缀解析出最佳路径。如果你有一个位于澳大利亚的终端用户试图连接部署在新加坡的应用程序，我们很可能会直接将这些数据包转交给Telstra。Telstra拥有澳大利亚最密集的接入网络之一。如果同一个应用程序需要将数据包发送到日本的终端用户或服务器，那么我们很可能会将这些数据包转交给PCCWPCCW直接与日本的NTT（日本电信电话公司）进行对等互联，并且在亚太地区（APAC，Asia-Pacific）拥有广泛的网络覆盖。

👉 网络之间对等互联的信息是公开可获取的，可以访问bgp.tools这个网站来观察你感兴趣的网络之间是如何实现相互连接的。

为了实现冗余，我们正在每个区域构建多个可用区，并且这些站点之间的互联互通对我们扩展计划至关重要。我们正在寻找裸纤（dark fiber）或波分复用技术（wavelength services）这样的工具来规划这种扩展。其结果是，你的应用程序不会察觉数据库是位于同一个房间，还是在相邻建筑中相隔四个街区的位置——这是一个优势，而不是缺陷——因为它增强了系统对单个数据中心故障的韧性。

...

好的，现在你已经找到了一个你满意的场地，和一个数据中心签订了协议，还和几家互联网服务提供商签了约，你就可以着手安装服务器了，对吧？

嗯，不是完全这样。首先你需要很多其他的东西来给你的服务器一个舒适温暖的家来安顿下来。

通道，机架和头顶的基础设施

在数据中心里，机架是按行排列的，机架之间的空间，也就是通道，被用于空气流通。

冷通道是从数据中心设施吹入冷空气的地方，而机架中的服务器会吸入这些冷空气，并将其从后部排出到热通道。数据中心设施会从热通道中移除这些热空气。为了达到最佳效率，不希望冷通道和热通道之间的空气混合。

即使您选择使用传统的19英寸宽设备，机架本身也存在一定的可变性。您可以根据设备和布线需求选择机架的高度、宽度和深度。

大多数服务器设备都可以通过滑轨进行滑动，以便于维护，因此要确保机笼尺寸允许设备进行滑动。布线和线缆管理也需要一定的空间，所以要在每个机架的拥挤程度与机笼内可容纳的机架数量之间做出权衡。

在我们的经验中，电力和制冷常常是限制因素，而不是实际可用的空间。在新场地，我们倾向于选择宽度为800毫米的机架，以便通过将电缆移出排气口的路径来实现更好的空气流通。

除了机架之外，你还需要一些基础设施来将电力和数据传输到你的机架。这可能涉及安装一些顶部基础设施和托盘，这些托盘让你能够将光纤电缆从你的机笼边缘路由到每个机架，并在机架之间路由电缆。当报价时，数据中心运营商通常会包含这些内容。

根据你的设计，你可能需要通过确保架空基础设施、机架内布线以及设备朝向的一致性，来优化电缆路径，使其尽可能短。由于我们的机架中每个都包含密集的交换机到服务器的光纤布线，因此我们采购的交换机是端口朝向机架后部的（这些被称为反向气流交换机，因为它们的散热口位于网络端口所在的侧面）。

这使我们能够对齐电缆托架，从而让所有的布线都发生在机架的一侧，并且没有电缆在机架的前部和后部之间来回曲折。

你已经拥有了所需的空间，签约了互联网服务提供商（ISPs），订购了硬件，准备好了机架，并且对如何布置这一切有了一个相当不错的概念。但目前，这一切还只是像一套昂贵的乐高积木一样，静静地待在数据中心的装卸区。要将它们组装起来，你现在需要利用人类历史上最通用的编程工具——Microsoft Excel。

上架和堆叠

让我们先退一步，先发表一个免责声明：整齐有序的布线需要大量的实践；我们自己也尝试过，结果……喜忧参半。

为了正确安装它们，我们引入了专业人士，但专业人士需要知道要安装什么。一份全面的文档包是必不可少的。电缆矩阵和机架布局图是常见的文件，它们向承包商传达如何安装和连接服务器。

电缆矩阵（Cabling Matrix）描述了每根电缆的端接情况，指明了连接的每一端所对应的设备位置和端口号，同时还包括电缆本身的规格信息（例如光纤类型、长度等）。机架视图（Rack Elevation）是机架本身的视觉呈现，展示了每个设备的位置和朝向。

文档工作非常繁琐，每个安装阶段都涉及60多台设备、300多根独立电缆以及许多细微之处。这些内容都被精心整理成书面规范和电子表格，作为安装和调试的基础。从物料到场到完成安装，整个过程大约需要6到14天。

数据中心的建设与软件、DevOps以及人们通常所认为的“基础设施”相去甚远。确切的说，更类似于建造房屋，而不是 Terraform 部署。

更复杂的是，每一个数据中心设施、承包商和供应商在做事方式上都会存在细微的差别，即使在同一个组织内也是如此。因此这些事情会要求你始终保持警觉，并且极度注重细节。

迄今为止我们经历过的一些困域时刻：

承包商说需要更长的电源线。原因是该站点的电源分配单元（PDU）是倒置的，因为电源是从地板接入的，这导致了插座编号在规划中被反向标记了。
来自阿姆斯特丹的电话说：“这个站点没有分界点吗？” 一个特定的设施直接将外部光纤链路安装到我们机架中的一个盒子上，而不是通过一个专用的交接点。
Railway Discord：“为什么这个PDU的相位接线这么奇怪？” 该设施的接线方式与其他站点不同，电源插座是相线对中性线接线，而不是相线对相线接线（对于电气工程师来说，这是WYE和Delta电路的区别）。
承包商说：“你的数据线太短了。” 承包商没有意识到网络设备是逆向气流的，试图以错误的方向安装设备。
我们提交了一个支持工单：“这条电缆没有建立连接。” 光纤的极性接反了；那天我们学会了什么是“翻转光纤电缆”……这是指他们从LC连接器中拔出插头并交换它们的位置。
Railway Discord：“我今天从家得宝买了一个橡胶锤。” 一个供应商的近24个PDU批次被交付时带有有故障的插座，即使施加适当的极端机械力，这些插座也无法与电源插头正确接合。

但从这一点开始——硬件已经就位，任务开始变得熟悉起来；我们现在需要进行一些BGP（边界网关协议，是一种用于互联网自治系统之间的路由协议）操作，安装一些操作系统，配置监控并让一切工作起来。

把油门踩到底

安装好的机架就像是一块空白的画布，网络设备需要进行配置，路由器的配置文件需要编写，区域互联网注册机构（RIR）的记录需要更新，我们还需要与类似 Redfish API（用于服务器主板和电源分配单元的专用控制器的 HTTP 接口）和 PXE（一种通过网络启动服务器的协议）进行交互，以确保一切正常运行。

我们也还没有讨论网络是如何工作的。我们的设计使用了FRR（Free Range Routing）和运行SONiC（Software for Open Networking in the Cloud）操作系统的白盒网络交换机，构建了一个仅基于第三层（L3）的软件驱动网络，该网络与我们的控制平面深度集成。

我们已经给你讲了很多来自一线的故事……要是再讲下去，你今天就别想走了。

在未来的文章中，我们将讨论如何将一个房间里的一堆服务器转变为一个功能性的 Railway 区域。在过去的几个月里，我们开发了两个新的软件工具：Railyard 和 MetalCP，以实现从设计新的机架、追踪和可视化布线，到在服务器上安装操作系统并将其接入互联网的“一键式”体验。

直到那时，如果这些内容中有任何让你感到兴奋的，可以查看我们目前开放的基础设施工程职位，如果这些职位引起了你的兴趣，就联系我们。

美区 Apple ID 充值攻略

2023-10-16T20:10:00+08:00

注：原文来自 https://zhuanlan.zhihu.com/p/552311280 ，亲测有效，因此转载一份，防止消失 :-)

一、购买美区苹果礼品卡

在国内购买美国 Apple gift cards的途径主要有以下三种：

淘宝购买美区礼品卡，买回来直接充值，但风险比较高，因为有些淘宝的礼品卡是黑卡，使用黑卡充值可能有 ID 丢失风险。没有信得过的店铺就不要尝试这个方法。
如果你有美国的朋友，可以让他代买礼品卡，然后充值。
到苹果美国官网自己买礼品卡送给自己，也是本文要说的方法。

准备工作

双币种信用卡，单币银联信用卡，中国发行的visa或者master
准备两个邮箱（通过邮箱发送礼品卡，Gmail可以）

购买流程

首先打开美国礼品卡购买地址：https://www.apple.com/shop/buy-giftcard/giftcard 然后选择“Email”电子礼品卡，封面随便选一个（不重要），然后填写购买金额，有$25，$50，$100的选项，官网买的话最小金额是$10。

接着填写收发人的信息及邮箱，邮箱千万不要弄错，否则无法接收礼品卡，填好后点击右上角“Add to Bag”按钮。

点完“Add to Bag”按钮后会跳转到另一个界面，这里检测下自己填写的邮箱有没有错，确认无误后点击“Check Out”按钮。

这里直接选择“Continue as Guest”按钮
接下来这里填写你的信用卡信息，包括姓名，卡号，账单地址等等，填写好信息后点击“Continue to Review”按钮。

填完上面信息后会让你再次确认邮箱等信息，确认无误后直接点击“Place Your Order”按钮就行，官网上写的是一个小时会收到邮件，正常不需要那么久，一般会在10分钟左右收到礼品卡邮件。

PS：最后填写你的 VISA 信用卡信息，和地址信息时候，如果你选择的是中国，购买失败了，可以重新下单选 United States看看，你可以搜索在线美国地址生成器，或者打开 Google Map，找到一个你喜欢的美国的详细地址，然后 Google Map 会告诉你它所在的州，街道，电话信息等。（账单地址建议选择没有消费税的五个州，因为不确定购买虚拟产品会不会账单地址不同而多交税。）

二、使用礼品卡充值

收到礼品卡后，会在邮箱中看到兑换码，复制兑换码，到app store里去充值。

充值前，先确认自己的 App Store 登录的是将要充值的 Apple ID，也就是美区 Apple ID。
把设置中国家和地区选项，改为美国，如果是 iPhone，路径是：设置 -> 通用 -> 语言和地区 -> 地区 -> United States。
打开邮件，点击进行充值。

或者你也可以打开 App Store，找到礼品卡充值入口，然后输入礼品卡的卡号(卡号在邮件里)，进行充值。具体步骤这里不再展开了，跟着手机的指引来就好了

Q&A

购买gift card并且到账之后，是否还需要绑定双币信用卡或者美国PayPal？

答：不需要，gift card和绑定双币信用卡或者美国PayPal时平行的，也就是说这三者只要满足一项，就可以进行付费APP的购买。

可以给美国区的Apple ID帮定国内的visa、master card、america express吗？

答：不可以，美国区的Apple ID只能绑定由美国发行的信用卡，有些小伙伴可能认为只要能消费美元的信用卡就可以，其实就算你绑定美国区Apple ID之后，苹果也能够识别你是大陆的信用卡，然后你的美国区账号就会被强制转成国区的Apple ID了，这就得不偿失了，所以建议不要尝试，如果不信邪，那可以试试，最后你可能需要重新注册一个美区Apple ID。

中国区Apple ID充值

中国区的Apple Store支持的充值方式有支付宝充值、微信支付、银联/信用卡/借记卡、快捷支付等四种方式，如果你在海外，确保你的支付宝或者微信账户有钱就可以充值了。

可能是全网最全的 ulimit 配置说明了

2022-06-14T13:07:00+08:00

ulimit 设置不当经常会引起各种各样的问题，比如很经典的 too many open files，网上也有很多文章讲解 ulimit 设置，如 initscrip 设置、PAM、systemd 的配置等等。

由于 systemd 已经成为主流，本文以 Debian 11 bullseye 为环境理清正确的 ulimit 设置应该覆盖哪些配置。通常情况下这些配置在绝大多数 Linux 发行版会是通用的，并不局限于 Debian。

systemd

systemd 主要涉及 /etc/systemd/system.conf 和 /etc/systemd/user.conf 两个文件，需要配置的内容是以样的，以 ulimit 中 open files 和 max user processes 为例，我们需要配置如下两项：

[Manager]
DefaultLimitNOFILE=1048567
DefaultLimitNPROC=65535

配置生效需要重启。但是这两个配置文件有什么区别呢？通过 man systemd-system.conf 了解到当以系统实例运行时，引用的是 system.conf ，当以用户实例运行时，引用的是 user.conf。不过系统环境中运行的都是系统实例，如果有兴趣的朋友可以通过 systemctl edit/enable/start --user 等操作自己注册个 user 实例看看。可以通过 cat /proc/${pid}/limits 进行确认。

结论：为了确保 ulimit 在 system 环境中生效，建议同时修改/etc/systemd/system.conf 和 /etc/systemd/user.conf 两个文件中的相关配置，并确保配置一致。

PAM limits

很多伙伴会发现，即使完全配置了 system 相关的文件并重启生效后，通过 ssh 远程登录服务器，ulimit -n 一看，还是 1024，这可是个忧伤的故事，怎么破呢？

请检查 /etc/ssh/sshd_config 配置文件，看看是否有这一行：

UsePAM yes

如果有，请将 yes 改成 no 之后重启 sshd 服务，再次登录后，你应该能发现 systemd ulimit 相关配置已经生效了。

但系统中 PAM 可是在相当多的地方用到了，所以这里我们需要再次修改 pam limit 相关配置，以确保系统中 ulimit 相关的配置一致。需要修改的文件为：/etc/security/limits.conf，请在文件里增加如下内容：

*   soft    nofile  1048567
*   hard    nofile  1048567
*   soft    nproc   65535
*   hard    nproc   65535

修改上述文件后，需要再确认一下以下文件（可能还有更多，但以下这些文件建议确认）：

/etc/pam.d/su
/etc/pam.d/sshd
/etc/pam.d/login
/etc/pam.d/cron

包含以下这行内容：

session required pam_limits.so

请注意，前方高能：细心的小伙伴可能会发现这时通过 su - 切换成 root 后，再看 ulimit，又是没有生效的，怎么回事呢？ man limits.conf 可以找到答案：

NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

上述 /etc/security/limits.conf 配置中的通配符 "*" 对 root 用户不生效，我们需要继续在 /etc/security/limits.conf 中增加如下配置：

root    soft    nofile  1048567
root    hard    nofile  1048567
root    soft    nproc   65535
root    hard    nproc   65535

保存后，应该安逸了~

结论：pam 的 limit 设置也会影响 ulimit 相关设置，需要通过配置确保和 systemd 相关内容一致。坑点：通配符 "*" 对 root 用户不生效。

结论

system 的 ulimit 相关设置需要同时调整 /etc/systemd/system.conf 和 /etc/systemd/user.conf；
除了 system 的配置，pam 相关的配置也需要同步调整，主要涉及 /etc/security/limits.conf 和 /etc/pam.d/ 目录下的相关文件；
/etc/security/limits.conf 中的通配符 "*" 对 root 用户不生效，root 用户相关配置需要显式指定；
除了系统级别的配置，用户也可以在 /etc/profile 和 bashrc 等相关配置里显式的修改 ulimit，当你发现上述 3 项配置都没有生效的时候，请检查用户侧的设定，看看是否自己另外指定了；

MongoDB 4.2 流控 FlowControl 机制走读

2022-06-11T22:21:00+08:00

MongoDB 4.2 引入了一个「流量控制」的新特性。该流控机制旨在保持副本集多数提交延迟小于或等于配置的最大值。此最大延迟的默认值为 10 秒。一旦多数提交的复制延迟达到配置的最大值的阈值百分比，流控制机制就会开始限制主节点上的写入。

当该特性开启时，MongoDB 会在给定的周期内（目前实现是 1 秒），分配一定数量的「流控票据」，MongoDB 的数据库库写操作需要通过获取「流控票据」来获取全局 IX 锁。当此给定周期内的票据分发完比后，相关操作需要等待下一个周期（下一秒）的票据刷新分发。部份 MongoDB 内部操作可能会忽略该流控机制，以确保 MongoDB 的正常运行。

接下来我们从算法、配置、源码等几个方面结合来了解一下该流控制机制的实现（本文以 MongoDB 4.2.20 版本的文档及源码为参考）。

环境要求

因为是 4.2 才引入的，所以要求 MongoDB 版本大于等于 4.2.0，并且 featureCompatibility 也要匹配相应的版本；
流控机制只在可以接受写入的节点生效（通过指 replica sets 中的 primary 节点）；
当然，流控开关也是要打开的，默认打开。可以通过 enableFlowControl 进行开关；
Read Concern Majority 必须启用，可以参考 replication.enableMajorityReadConcern 启用；

当以上机制不满足时（亦可理解为流控机制关闭时），MongoDB 总是返回默认的最大数量 _kMaxTickets = 1000 * 1000 * 1000。

流控机制

流控制机制允许每秒获取指定数量的全局 IX 锁。除明确规避流控机制的操作外，全局 IX 锁获取必须首先获取「流控票据」然后才能获取锁。当此给定周期内的票据分发完比后，相关操作需要等待下一个周期（下一秒）的票据刷新分发。MongoDB 通过一个独立的机制每秒刷新一次票数。

// src/mongo/db/storage/flow_control.cpp

FlowControl::FlowControl(ServiceContext* service, repl::ReplicationCoordinator* replCoord)
    ...

    _jobAnchor = service->getPeriodicRunner()->makeJob(
        {"FlowControlRefresher",
         [this](Client* client) {
             FlowControlTicketholder::get(client->getServiceContext())->refreshTo(getNumTickets());
         },
         Seconds(1)});
    _jobAnchor.start();
}

每次/秒刷新 tickets 数量时，getNumTickets 将计算应该允许多少票据以解决 MongoDB 多数提交的滞后问题（复制延迟）。流控机制根据以下因素确定每个周期要补充多少票：

当前多数提交的复制延迟大于配置的目标最大复制延迟；
Secondary 在上一周期应用了多少次操作；
在上一周期中平均每次操作需要获取多少个 IX 锁；

触发流控时 ticket 数量计算

触发流控的 ticket 数量可以通过如下公式理解：

base * k ^ ((lag - threshold)/threshold) * fudge factor

采样方式

采样的频率和数量主要通过如下两个配置参数进行控制：

flowControlSamplePeriod 这个参数的命名比较容易让人困惑，会容易误认为是时间，实际理解是每 N 次采样一次，N 即为 flowControlSamplePeriod 设置的值，值越小的精度越高，所以可能更容易触发流控导致业务降级；

// src/mongo/db/storage/flow_control.cpp

void FlowControl::sample(Timestamp timestamp, std::uint64_t opsApplied) {
    ...
    if (_numOpsSinceStartup - _lastSample <
        static_cast<std::size_t>(gFlowControlSamplePeriod.load())) {
        // Naively sample once every 1000 or so operations.
        return;
    }

flowControlMaxSamples，内存中保存的样本数，默认值为 1000000，每个样本数约为 24 bytes大小，保存 100000 样本数约需 24MB 内存；

采样在 oplog 相关的操作中进行，参考上述 sample 采样逻辑及下述代码，没有发现显式的采样开关，即无论是否启用流控制，采样机制都会执行。

//src/mongo/db/repl/local_oplog_info.cpp

std::vector<OplogSlot> LocalOplogInfo::getNextOpTimes(OperationContext* opCtx, std::size_t count) {
    ...
    // Provide a sample to FlowControl after the `oplogInfo.newOpMutex` is released.
    ON_BLOCK_EXIT([opCtx, &ts, count] {
        auto flowControl = FlowControl::get(opCtx);
        if (flowControl) {
            flowControl->sample(ts, count);
        }
    });
}

延迟正常（未触发流控）时 ticket 数量计算

当多数提交的延迟小于可容忍流控阈值的延迟百分比时（认为服务状态健康），直接将上一期间分配的 ticket 数量做为基数，并增加一个可配置的常量（票据加法），参数名称为 flowControlTicketAdderConstant 默认值为 1000。总和乘以另一个可配置的常量（票据乘数），最终的值为下期分配的新票数。该乘数配置参数名称为 flowControlTicketMultiplierConstant 默认值为 1.05，修改配置需要确保大于 1。

该算法主要是为了确保系统健康时，特别是初始使用了较少的 ticket 时，系统 ticket 数量可以快速得到提升。公式：(lastTargetTicketsPermitted + flowControlTicketAdderConstant) * flowControlTicketMultiplierConstant

// src/mongo/db/storage/flow_control.cpp

int FlowControl::getNumTickets(Date_t now) {
  ...
      if (isHealthy) {
        // The add/multiply technique is used to ensure ticket allocation can ramp up quickly,
        // particularly if there were very few tickets to begin with.
        ret = multiplyWithOverflowCheck(_lastTargetTicketsPermitted.load() +
                                            gFlowControlTicketAdderConstant.load(),
                                        gFlowControlTicketMultiplierConstant.load(),
                                        kMaxTickets);
        ...
      }
  ...
}

配置参数整理

配置参数	说明
enableFlowControl	流控开关 true/false，默认 true
flowControlTargetLagSeconds	可容忍的多数提交延迟，单位为秒，默认 10
flowControlThresholdLagPercentage	可容忍的多数提交延迟百分比，{ gte: 0.0, lte: 1.0 }，该值乘以 flowControlTargetLagSeconds 为实际可容忍的延迟
flowControlMaxSamples	最大的保留样本数
flowControlSamplePeriod	采样周期，注意不是指时间，指：N 次操作采样一次
flowControlMinTicketsPerSecond	最小的 ticket 数量，默认 100。设置过小可能会导致系统需要预热，可以根据系统业务的情况适当调整
flowControlDecayConstant	MongoDB 触发流控时节流的速率，默认值为 0.5
flowControlFudgeFactor	Fudge 因子，默认为 0.95，要求小于 1，但接近 1，不建议调整
flowControlTicketAdderConstant	健康状态时，ticket 加数，以快速增加健康状态时的 ticket 数量
flowControlTicketMultiplierConstant	健康状态时，ticket 乘数，以快速增加健康状态时的 ticket 数量

需留意，MongoDB 启动时，默认的 ticket 数量为 _kMaxTickets = 1000 * 1000 * 1000 即 10 亿，而不是 flowControlMinTicketsPerSecond 的值。通过如下命令可以查看当前的票据情况：

// MongoDB 刚启动时

tmongo40:PRIMARY> db.serverStatus()["flowControl"].targetRateLimit
1000000000

tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 1000000000,
    "timeAcquiringMicros" : NumberLong(76),
    "locksPerOp" : 0,
    "sustainerRate" : 0,
    "isLagged" : false,
    "isLaggedCount" : 0,
    "isLaggedTimeMicros" : NumberLong(0)
}

// 触发流控后

tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 2015,
    "timeAcquiringMicros" : NumberLong(12064),
    "locksPerOp" : 1,
    "sustainerRate" : 2196,
    "isLagged" : true,
    "isLaggedCount" : 1,
    "isLaggedTimeMicros" : NumberLong(0)
}
tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 1014,
    "timeAcquiringMicros" : NumberLong(38346),
    "locksPerOp" : 1,
    "sustainerRate" : 1924,
    "isLagged" : true,
    "isLaggedCount" : 1,
    "isLaggedTimeMicros" : NumberLong(0)
}

日志

触发限流时，可以在 MongoDB 的日志里找到 flowControl 相关的日志。

其他结论

好的限流效果需要根据业务的情况持续调测相关参数，且 MongoDB 的限流算法主节点的处理能力受主节点影响，存在多种不确定因素（如网络），建议谨慎开启。或基于前述情况，建议降低流控敏感度，如放宽对大多数主从提交的延迟阈值容忍，仅在较极端情况下对 MongoDB 触发保护，避免过于敏感反而影响正常业务请求；
根据某业务的线上表现来看，在 CPU、io 吞吐极低的情况下，MongoDB 默认的参数配置仍频繁的触发限流。因此建议仍如 1；

参考文档

enableFlowControl: https://www.mongodb.com/docs/v4.2/reference/parameters/#param.enableFlowControl
source code: https://github.com/mongodb/mongo/tree/r4.2.20

WireGuard 浅显体验

2022-05-15T17:07:00+08:00

WireGuard® 是一个极其简单、快速且现代的 VPN，它利用了最先进的加密技术。目的是提供一种更快、更易配置、更精简的通用 VPN。最初是为 Linux 开发（并且已经合并至 Linux Kernel, >5.6），底层是 VPN，现在支持 Windows、macOS、BSD、iOS、Android 等跨平台。目前还处于活跃的开发当中，但仍不失为一个简易友好，且性能、安全性和兼容性都很棒的 VPN 解决方案。

Linus Torvalds 给予 WireGuard 很高的评价（work of art）：

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

安装篇

具体的安装可参考 Installation，笔者使用的操作系统为 Debian bullseye，官方源已经自带，仅需要 root 用户 apt-get install wireguard 一条命令搞定。

配置篇

安装过程比较简单，没有打脸官方所宣传的简单，具体也可以参考官方文档 QuickStart。

场景一：Peer-To-Peer，两台服务器可互通

笔者这里有两台机器，其中服务器 A 为腾讯云的机器，系统内看到的地址为内网地址，在腾讯云配置了公网 eip。

服务器 B 为一台公网的机器，有直接的公网 IP。（这里留下了一个坑点）

生成 WireGuard 公私钥

以下命令需要在服务 A 和服务器 B 执行：

# 生成私钥
wg genkey > wg.private
# 生成公钥
wg pubkey < wg.private > wg.pubkey

生成 WireGuard 配置

分别在两台机器上创建 /etc/wireguard/wg0.conf 文件。

服务器 A 腾讯云机器配置如下：

[Interface]
ListenPort = 57259 # UDP 端口，根据自己的需要设定即可
Address = 172.16.1.1/24 # WireGuard 网络设备 IP 地址，这里使用 172.16.1.1
PrivateKey = uJj+x/... # 在这台服务器上生成的 wg.private 文件内容

[Peer]
PublicKey = W72b9l... # 在服务器 B 生成的 wg.pubkey 文件内容
AllowedIPs = 172.16.1.2/32 # 服务器 B WireGuard 网络设备 IP 地址，也可以开放 /24 网段
Endpoint = 108.xx.xx.xx:34101 # 服务器 B 的公网 IP 地址及 ListenPort

服务器 B 公网机器配置如下：

[Interface]
ListenPort = 34101 # UDP 端口，根据自己的需要设定即可
Address = 172.16.1.2/24 # WireGuard 网络设备 IP 地址，这里使用 172.16.1.2
PrivateKey = kETG3... # 在这台服务器上生成的 wg.private 文件内容

[Peer]
PublicKey = hTfx29g... # 在服务器 A 生成的 wg.pubkey 文件内容
AllowedIPs = 172.16.1.0/24 # 参考服务器 A，这里开放 /24 网段
Endpoint = 118.xx.xx.xx:57259 # 服务器 A 的公网 IP 地址及 ListenPort

之后分别在两台机器上使用命令 wg-quick up wg0 后隧道就建议好了，可以通过 ping 来检查。

到这里还比较顺利，确实非常简单。笔者就转移注意力去开展其他的工作了，过了几分钟回来发现网络断开了，从服务器 A 腾讯云机器单向无法 ping 通 B 服务器，此时从 B 服务器 ping A 服务器后网络恢复（第一个问题）。

为什么呢？

怀疑是腾讯云服务器系统内只能看到内网 IP 的问题，毕竟这里是通过网关转发，在我之前其他的网络试验中已经多次踩中这个坑。继续往下翻 QuickStart 找到答案：

if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives.

解法也比较简单，在上面两台机器的 wg0.conf 配置文件中的 [Peer] 部份分别加上 keepalive 相关的配置即可（默认是 0，也就是不开启，这里我们设置为 25 秒）：

PersistentKeepalive = 25

场景二：能不能内网穿透呢？

再找了一台纯内网的服务器 C，该服务器可以访问外网，但外部网络无法访问该服务器。且不清楚该服务器 C 的外网出口 IP 是什么。

配置内网服务器

参考场景一的内容进行 WireGuard 安装和配置，假设服务器 C 的 WiredGuard 设备地址设置为 172.16.1.3，则配置如下：

[Interface]
Address = 172.16.1.3/24
PrivateKey = aHebd...

[Peer]
PublicKey = hTfx29g...
AllowedIPs = 172.16.1.0/24
Endpoint = 118.xx.xx.xx:57259
PersistentKeepalive = 25 # 处于 NAT 环境的设备需要加上 keepalive 配置

主要差异： ListenPort 的配置取消了，因为这台机器纯内网，我们无法判定最终映射的公网 IP 和端口分别是什么。上述配置保存后，通过 wg-quick up wg0 启动设备即可。

在服务器 A 腾讯云的机器上 /etc/wireguard/wg0.conf 增加该服务器 C 的 peer 配置：

[Peer]
PublicKey = hESH+Md6... # 服务器 C 的 wg.pubkey 内容
AllowedIPs = 172.16.1.0/24
PersistentKeepalive = 25

主要差异： Endpoint 配置取消了，毕竟 A 不知道 C 用的会是哪个公网 IP 和端口。保存配置后，分别执行 wg-quick down wg0 和 wg-quick up wg0 即可。

本以为到这里已经完成配置了，结果第二个问题来了。两台服务器 ping 不通。再次检查配置确认无误，陷入深深的思考~

解决办法：网络不决问防火墙。想到这里因为服务器 C 是在内网，WireGuard 能互通的前提肯定是服务器 C 要先访问服务器 A 的 ListenPort，检查防火墙配置，服务器 A 的 57259 UDP 端口没有对外开放。通过以下命令开放 57259 端口访问：

iptables -I INPUT 1 -p udp -m udp --dport 57259 -j ACCEPT

端口开放后，两台机器之间的互联果然正常了。

一些结论

如果 wg 两端设备都有公网地址可达，分别配置 Address 和 ListenPort 后，两台机器隧道可以互通，通常无需特殊配置；
如果设备位于防火墙或网关后面，需要打开 keepalive 配置；
内网穿透时，做为网关的机器（公网那台）需要开放 ListenPort 的防火墙访问；
根据需要，你可能需要打开设备的数据包转发（net.ipv4.ip_forward = 1）和网络地址转换功能（NAT/MASQUERADE），这里不展开；

Debian 指定内核启动

2022-05-07T12:59:00+08:00

升级完内核发现有一些问题需要回退，但是因为不能直接接触机器终端，需要通过 grub 配置指定内核版本重新启动。

操作系统：Debian 11

涉及文件：

/etc/default/grub
/boot/grub/grub.cfg

操作步骤：

通过命令 grep -e 'menuentry ' -e 'subm' /boot/grub/grub.cfg | awk -F'--' '{print $1}' 找到需要启动的内核菜单名称：

假设上图中的 Debian GNU/Linux, with Linux 5.10.0-13-amd64 是我们期望使用的内核，则需要引用图示 1 和 2 修改 /etc/default/grub。
修改 /etc/default/grub 中的 GRUB_DEFAULT=0 为如下值：

GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 5.10.0-13-amd64"
执行命令 update-grub，成功后重启即可。

当 cgroups 碰上超线程

2022-03-29T11:24:00+08:00

超线程

当英特尔® 超线程技术处于激活状态时，CPU 会在每个物理内核上公开两个执行上下文。这意味着，一个物理内核现在就像两个“逻辑内核”一样。超线程技术就是利用特殊的硬件指令，把两个逻辑内核模拟成两个物理芯片，让单个处理器都能使用线程级并行计算，进而兼容多线程操作系统和软件，减少了 CPU 的闲置时间，提高的 CPU 的运行效率。

虽然采用超线程技术能同时执行两个线程，但它并不象两个真正的 CPU 那样，每个 CPU 都具有独立的资源。当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续。因此超线程的性能并不等于两颗 CPU 的性能。根据 Intel 官方文档反馈，理论情况下在服务器应用程序中可提升 30% 的性能。

怎么确认机器是否开启超线程

通常情况下，我们只需要通过 /proc/cpuinfo 即可确认机器是否开启超线程。当相同的 physical id 和 core id 出现两次时，即表示机器开启了超线程。

![image-20210830174503295](/static/cpus_hyperthreading.png) 图 1. /proc/cpuinfo

以图 1 为例，在 /proc/cpuinfo 中共可以找到 48 个 CPU，根据 physical id 和 core id 的组合，我们可以画出 CPU 架构图如下图 2。其中如 0-24/2-26/../23-47 表示相同 core id，启用了超线程后操作系统看到的逻辑 CPU 对。

![image-20210830175849529](/static/cpu_arch.png) 图 2. 物理 CPU 与逻辑 CPU 关系

CGROUPS

cgroups 是 Linux 内核提供的一种可以限制单个进程或者多个进程所使用资源的机制，可以对 cpu，内存等资源实现精细化的控制，目前市面上相当流行的轻量级容器 Docker 就使用了 cgroups 提供的资源限制能力来完成 cpu，内存等部分的资源控制。

笔者目前主要的工作内容是为公司提供数据库私有云服务，为了有效充分的利用服务器资源，我们会利用 cgroups 对资源进行隔离，根据业务需求提供不等规模的机器资源。其中对 cpu 的隔离是通过 cpuset.cpus 来进行的，通常情况下，我们会保留头部数个 cpu，如 CPU 0-CPU 5 做为系统保留 CPU。其它 CPU 则按顺序，如将 6,7,8、9,10,11,12，13，14 分配给两个不同的实例。

为了业务的可用性考虑，我们的 CPU 分配还是比较充份的，通常 50% 是我们的一个相对安全水位。所以大多数情况下，上面的按序分配并不会带来什么问题。本文主要是探讨极端情况下上述 cpu 分配方式可能造成的问题。

问题

由于共用了物理 CPU，容器之间可能存在 CPU 争抢：

以数据库为例，明明 A 实例的负载并不高，但有时候会忽然「卡」那么一下或者刷个慢查询，但业务并没有发生变化，DBA 也无法追踪到不合理的 SQL 或索引缺失等情况

图 3. 逻辑 CPU 分配案例一

以上图 3 为例，假设我们给 Container A 绑定了 2, 3, 4 共 3 个 CPU，给 Container B 绑定了 26, 27, 28 共三个 CPU，可以看到 2-26, 4-28, 3-27 分别共享了一个物理核心（core id 相同）。根据对超线程的理解：当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续，假设 Container A 的负载较高，则 Container B 是有可能受到影响并导致出现 cpu 等待的情况的，反映到业务，则是：不知道为什么抽风了。
高负载情况下，隔离资源的实际性能表示与标称值不符：

图 4. 逻辑 CPU 分配案例二

以上图 4 为例，假设 0, 1, 2, 45, 46, 47 为保留 CPU（不明确分配实际业务），其它 CPU 按顺序每 6 个一组分配至不同的业务容器，我们可以猜测分配到 21, 22, 23, 24, 25, 26 这 6 个 CPU 的容器会有较少的超线程资源争抢，预计会有更好的性能表现。

下图为某业务的实际测试图，在施加具备让容器满载压力情况下，具备较少超线程争抢的容器拥有较好的性能。这在大多数情况下可能并不是好事：

图5. 某业务使用“图 4. 逻辑 CPU 分配案例二”压力测试情况
- 个别节点拥有较高性能可能造成业务上线压力评估的数据失真；
- 对于分布式场景，各节点的能力承载存在明显不一致可能造成分布式系统的降级甚至雪崩；
上述两个问题本质是一样的，都是因为超线程的争取造成的压力不一致、资源抢占。虽然大多数情况下通过资源的预留减少了上述问题发生的概率，但当问题发生时，一线技术人员极难排查，只能以疑难问题或偶尔抽风等玄学又无奈的口径进行解释。对技术人员的业务技能储备有非常高的要求，需要对硬件架构、操作系统、业务架构等多方面都有较清晰的了解。

参考文档

速率限制算法：固定窗口与滑动窗口

2022-03-28T15:59:00+08:00

在生产环境中，我们经常需要通过一定的办法方案来保护我们的系统（比如 API）免受无意的或恶意的过度使用。在极端情况下，我们还需要对系统进行适度的降级，以确保系统的可用性。速率限制（rate limit）有助于自动化该过程（有时候也会称为流量控制）。

这里我们主要介绍固定窗口计数算法和滑动窗口计数算法。

固定窗口 Fixed Window

固定窗口算法比较好理解，大致的概念如下：

时间被切分成固定大小的窗口，比如 60 秒或 5 分钟等；
每个时间窗口允许通过的请求阈值固定，假定为 N；
每一次请求进来，对当前时间窗口的计数器加 1，假设为 n；
当当前时间窗口的请求计数超过阈值时（n>N），丢弃当前时间窗口进来的所有请求；

整体的理解可以参考下述图例 1（固定时间窗口 1 秒，每秒钟允许通过 3 个请求）：

图 1. 固定窗口算法图例

看起来好像没有什么毛病，在允许的时间窗口内只允许通过预设的请求。为什么还会需要滑动窗口算法，我们看一下固定窗口算法的问题：

以上图为例，假定 14:00:02 秒的 3 个请求是在后 500ms 到达，14:00:03 分的 3 个请求是在前 500ms 到达，实际上一秒内可能通过了超过预设的 3 个请求，系统被击穿（参考下图 2）；
如果这是一个高并发系统，那么有可能存在大量请求等待时间窗口重置的情况，还是以上图为例，一切换新的时间窗口，系统可能马上在短时间内被击穿不可用（踩踏）；

图 2. 固定窗口算法问题

滑动窗口 Sliding Window

为了解决固定窗口在时间窗口切换边界的流量尖峰问题，引入了滑动窗口计数算法。该算法在固定窗口的基础上，将固定窗口进行更细粒度的切分：

将时间划分为多个固定区间，如 200ms；
在每个区间内每有一次请求则计数加 1，并维持固定的时间窗口，如固定时间窗口为 1 秒，则占用 5 个时间区间；
每经过一个区间的时间，抛弃最早的区间，并纳入最新的时间区间；
如果当前时间窗口的请求数量超过了预设限制，则本时间窗口内的后续请求都会被丢弃；

基本算法通过下图 3 概要说明，可以直观发现滑动窗口计算方法可以有效避免窗口切换的边界流量尖峰及踩踏问题。并且在我们需要提高流控精度的时候，可以通过划分更细的时间区间来实现。

图 3. 滑动窗口算法图例

注：算法可以进一步简化，假设当前时间窗口已经过去 25%，目前的请求数为CurrentN，上一次时间窗口共接受 PreN 次请求（权重为 100%-25%=75%），如果 (PreN * 0.75 + CurrentN) > 预设请求阈值 则丢弃本次请求，反之放行本次请求。

参考文档

[How to Design a Scalable Rate Limiting Algorithm with Kong API

记一次 TiDB 时区设置异常问题排查

2019-10-12T22:27:00+08:00

收到同事的反馈，两个配置一模一样的 TiDB 集群，在执行 SELECT NOW(); 操作的时候出现了不一样的结果，A 集群的时间与系统时间一致，B 集群的时间比系统时间少了 8 小时。

由于我们的 OS、TiDB 配置是统一管理的，所以我并不怀疑是因为两个集群当前配置不一样导致的。第一反应肯定是因为在 TiDB 启动之前用了错误的时区（UTC），然后 TiDB 引用了错误的时区导致的这个时间问题。根据常规经验，重启一下 TiDB 进程问题应该能解决。

然而这一次失望了，重启 TiDB 之后，并没有发生什么变化。跟同事要了服务器信息，直接登录到机器上看一下吧。以下是整体的排查过程。

先确认是不是，再查为什么

首先还是确认是不是有这个问题（再研究为什么），根据官方文档，检查了 time_zone 信息，并没有发现异常，有问题的集群和没问题的集群配置也是完全一样的。

mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+
1 row in set (0.01 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

mysql>

虽然这里没有发现明显问题，但我们还是发现了一个疑点：我们的服务器，不可能会有 CST 这个时区设置（我们用的是 HKT），但 CST 这个很明显不是问题的原因。

日志是一定要看的

几乎可以这么说，日志就是为了排查问题而诞生的，任何不能马上判断的问题，都应该去翻一下日志，对服务的健康情况进行判断。因为是时区相关的问题，所以直接对 TiDB 的日志做了一个 fgrep -i timezone tidb.log 的操作，没想到真的发现了错误日志，毫无波折，就是这么惊喜。（TiDB 日志打印出来是完整一行的，以下内容我稍微格式化了一下，转化为真正的换行）：

[019/10/09 16:21:42.111 +08:00] [ERROR] [time.go:81] ["locate timezone files failed"] [] [stack="github.com/pingcap/tidb/util/timeutil.InferSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/util/timeutil/time.go:81
github.com/pingcap/tidb/session.writeSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:786
github.com/pingcap/tidb/session.doDMLWorks
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:935
github.com/pingcap/tidb/session.bootstrap
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:290
github.com/pingcap/tidb/session.runInBootstrapSession
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/session.go:1541
github.com/pingcap/tidb/session.BootstrapSession
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/session.go:1460
main.createStoreAndDomain
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/tidb-server/main.go:205
main.main
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/tidb-server/main.go:171
runtime.main
/usr/local/go/src/runtime/proc.go:200"]

几乎可以直接肯定是因为这个报错导致的问题了，但还是需要靠撸代码来证明一下的。

撸代码

根据上述的错误日志，可以知道最终实际执行出错的函数在 util/timeutil/time.go 的 InferSystemTZ 函数里，我们来看下这个函数做了什么：

// InferSystemTZ reads system timezone from `TZ`, the path of the soft link of `/etc/localtime`. If both of them are failed, system timezone will be set to `UTC`.
// It is exported because we need to use it during bootstap stage. And it should be only used at that stage.
func InferSystemTZ() string {
  // consult $TZ to find the time zone to use.
  // no $TZ means use the system default /etc/localtime.
  // $TZ="" means use UTC.
  // $TZ="foo" means use /usr/share/zoneinfo/foo.
  tz, ok := syscall.Getenv("TZ")
  switch {
  case !ok:
    path, err1 := filepath.EvalSymlinks("/etc/localtime")
    if err1 == nil {
      name, err2 := inferTZNameFromFileName(path)
      if err2 == nil {
        return name
      }
      logutil.Logger(context.Background()).Error("infer timezone failed", zap.Error(err2))
    }
    logutil.Logger(context.Background()).Error("locate timezone files failed", zap.Error(err1))
  case tz != "" && tz != "UTC":
    for _, source := range zoneSources {
      if _, err := os.Stat(source + tz); err == nil {
        return tz
      }
    }
  }
  return "UTC"
}

可以看到，TiDB 设置时区的逻辑是首先获取操作系统的 TZ 变量，再从 /etc/localtime 的实际软链地址提取，最后 fallback 为 UTC。这个逻辑还是与官方文档的描述一致的。但是我们的机器上肯定是有 /etc/localtime 文件的，文件肯定也是正确的，为什么会失败呢？再来看一下上述代码里最终分析 /etc/localtime 的函数 inferTZNameFromFileName 都做了什么？

// inferTZNameFromFileName gets IANA timezone name from zoneinfo path.
// TODO: It will be refined later. This is just a quick fix.
func inferTZNameFromFileName(path string) (string, error) {
  // phase1 only support read /etc/localtime which is a softlink to zoneinfo file
  substr := "zoneinfo"
  // macOs MoJave changes the sofe link of /etc/localtime from
  // "/var/db/timezone/tz/2018e.1.0/zoneinfo/Asia/Shanghai"
  // to "/usr/share/zoneinfo.default/Asia/Shanghai"
  substrMojave := "zoneinfo.default"

  if idx := strings.Index(path, substrMojave); idx != -1 {
    return string(path[idx+len(substrMojave)+1:]), nil
  }

  if idx := strings.Index(path, substr); idx != -1 {
    return string(path[idx+len(substr)+1:]), nil
  }
  return "", fmt.Errorf("path %s is not supported", path)
}

代码的注释里明确写了只支持 /etc/localtime 为软链接，代码的逻辑也是通过截取 /etc/localtime 软链指向的具体文件路径来获得时区信息。看一下我们服务器上的这个文件：

$ ls -alh /etc/localtime
-rw-r--r-- 1 root root 1.2K 10月 12 10:11 /etc/localtime

果然是一个文件而不是一个软链接。这下又带来了两个疑问：

如果我改成软链再重启 TiDB 能不能解决问题呢？实践证明，不能解决。这里不再赘述。
函数逻辑很明确是 fallback 了 UTC，根据 SELECT NOW(); 早了 8 小时也可以确认是 UTC，可为什么 system_time_zone 是 CST 呢？

看到的（CST）和实际的（UTC）不一样？

TiDB 在拿不到正确的时区，回落至 UTC 时，最终 UTC 是怎么设置的呢？我们再来看一下上面的错误日志：

github.com/pingcap/tidb/session.writeSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:786

在 session/bootstrap.go 我们找到：

// writeSystemTZ writes system timezone info into mysql.tidb
func writeSystemTZ(s Session) {
  sql := fmt.Sprintf(`INSERT HIGH_PRIORITY INTO %s.%s VALUES ("%s", "%s", "TiDB Global System Timezone.") ON DUPLICATE KEY UPDATE VARIABLE_VALUE="%s"`,
    mysql.SystemDB, mysql.TiDBTable, tidbSystemTZ, timeutil.InferSystemTZ(), timeutil.InferSystemTZ())
  mustExecute(s, sql)
}

TiDB 首次启动时，拿到时区信息后，将时区信息写到了 mysql.SystemDB.mysql.TiDBTable，也就是 mysql.tidb，其中 VARIABLE_NAME 为 tidbSystemTZ，也即 system_tz

  // The variable name in mysql.tidb table and it will be used when we want to know
  // system timezone.
  tidbSystemTZ = "system_tz"

继续直接登录机器看一下这张参数的内容在两个集群中有什么不一样：

可以看到，确实是设置了 UTC，那么也可以非常明确是由于这个值引起的了。经过测试，可以通过如下两种方式解决：

更新 mysql.tidb 中 system_tz 为正确的时区，如我们这里为 HKT，并重启 tidb-server 进程后，问题可以得到解决。
根据官方文档设置 time_zone 变量，问题可以得到解决。如果有需要，可以把 system_tz 也修改了，tidb-server 不会自行进行调整：

为什么

到这里，我们可以很明确 TiDB 参数这里导致时间不对的情况了。但是还有几个疑问还没有得到解决：

为什么同样的配置，有一个集群是正常的，一个集群又用了 UTC 呢？

这个情况主要是因为我们的机器有一个初始化的过程，在没有完成初始化的时候，/etc/localtime 确实是一个软链接，并且指向了 /usr/share/zoneinfo/Asia/Hong_Kong，当我们的 tidb-server 进程在这个文件被修改之前启动时，会使用正确的时区。但同时，我们在机器上部署了 puppet 进行统一的配置管理，puppet 会做一个类似 cp /usr/share/zoneinfo/Asia/Hong_Kong /etc/localtime 的操作，将 /etc/localtime 替换为一个文件，这个时候，tidb-server 无法正确分析时区信息，导致 fall back 至 UTC。简单示意如下：
为什么 SELECT @@global.time_zone, @@session.time_zone; 看到的是 CST，但不管是我们的机器还是 TiDB 配置文件都没有引用 CST 这个时区，CST 从哪里来的？

属于 tidb-server 的默认行为，tidb-server 初次启动时，会默认设置为 CST。可以参考 session/bootstrap.go 和 sessionctx/variable/sysvar.go 这里不再展开。
system_tz、@@global.time_zone、@@sessio.time_zone 的关系是什么？system_tz 和 time_zone 两者的生效逻辑是怎样的？
- @@session.time_zone 在新建连接时，值主要依赖于 @@global.time_zone，session 值等同于 global，默认都为 SYSTEM，即 system_tz 值；
- 如果单独修改了 @@session.time_zone ，则当前连接的 time_zone 以 session 设置为准；
- tidb-server 在每次启动的时候会从 mysql.tidb 加载 system_tz 值，并设置系统时区。这也是为什么我们在更新了 system_tz 并重启 tidb-server 后，可以获取到正确时间的原因；
tidb-server 启动时通过 mysql.tidb 设置系统时区的相关代码可以在 session/session.go 找到：

// loadSystemTZ loads systemTZ from mysql.tidb
func loadSystemTZ(se *session) (string, error) {
  sql := `select variable_value from mysql.tidb where variable_name = 'system_tz'`
  rss, errLoad := se.Execute(context.Background(), sql)
  if errLoad != nil {
    return "", errLoad
  }
  // the record of mysql.tidb under where condition: variable_name = "system_tz" should shall only be one.
  defer func() {
    if err := rss[0].Close(); err != nil {
      logutil.Logger(context.Background()).Error("close result set error", zap.Error(err))
    }
  }()
  req := rss[0].NewChunk()
  if err := rss[0].Next(context.Background(), req); err != nil {
    return "", err
  }
  return req.GetRow(0).GetString(0), nil
}

// BootstrapSession runs the first time when the TiDB server start.
func BootstrapSession(store kv.Storage) (*domain.Domain, error) {

小结

其实还蛮普通的一个问题，只是之前碰到比较多的情况是在环境初始化没完成时就启动服务，导致服务出现状况。这次 TiDB 这里刚好反过来，环境初始化未操作之前反而是正常的，初始化之后异常了；
问题的线索其实完完整整的保存在了日志中，流程是否有可以优化的空间有待考证商榷，但日志在排查问题的时候是一定要首先关注的；
/etc/localtime 直接使用文件不是一个合理的方式，TZ 环境变量的优先级也高于 /etc/localtime。这个可以参考 man 文档：

Because the timezone identifier is extracted from the symlink target name of /etc/localtime, this file may not be a normal file or hardlink.

TiDB DM 数据库同步 STEP BY STEP

2019-09-29T13:08:00+08:00

前段时间，看到了一篇关于数据库选型的文章（MongoDB/TiDB/CockroachDB），忍不住感慨了一句，TiDB 一看就是大户人家，什么工具都可以有，什么工具都迭代得特别快，没有钱没有人，难以想像如何才能驱动得了。TiDB/TiKV/PD/Mydumper/Loader/Syncer/Data Migration/TiDB Lighting/Pump/Drainer ... 光是弄清楚这些组件是用来做什么的，感觉都可以评个高工了 :-)

随着 DM 1.0 GA 的 release，我们也开始考虑将 syncer 迁移至 DM。主要原因还是 syncer 已经太久没有更新了，否则 syncer 这种简易几乎无须部署的工具还是比较对我个人的胃口的，官方很喜欢把工具集群化（可能听起来厉害一点），DM 也是，那就按着最小目标（syncer）折腾一下吧。

DM 的架构文档可以参考官方，整个集群有三个角色 dmctl/dm-master/dm-worker。

DM-master 负责管理和调度数据同步任务的各项操作。
DM-worker 负责执行具体的数据同步任务。
dmctl 是用来控制 DM 集群的命令行工具。

官方也提供了基于 Ansible 的部署工具，如果你不是特别需要了解实际的部署过程，或者你的环境对 ansible 的亲和度比较好的话，可以参考使用 DM-Ansible 部署 DM 集群。在这篇文章里，我们还是希望对于 DM 的部署有一定的了解，另外我们的小目标是实现类似 syncer 功能，因此，让我们 step by step 人肉部署吧。（好吧，吐槽一下，其实本人是很反感什么都要 ansible 再包一层的，无法直接通过文档了解工作方式，还非得去读 ansible 的相关部署文件）。

准备工作

确认工作目录，假定这里为 /home/dm，并确保相关目录已经建立且具备读写权限：mkdir -p /home/dm/log；
确保机器上已经具备相应的命令行工具，如：tar、wget、rsync 或 cp 等；
下载 DM 二进制文件：

wget http://download.pingcap.org/dm-latest-linux-amd64.tar.gz
tar -zxvf dm-latest-linux-amd64.tar.gz
rsync -avz dm-latest-linux-amd64/bin/ /home/dm/bin/

机器列表，这里我们主要熟悉部署过程，且不需要分库分表合并等功能，只实现 syncer 流程，因此 master 和 worker 均只部署在同一台同器：

角色	地址
DM-master	127.0.0.1:8261
DM-worker	127.0.0.1:8262

配置文件

dm-worker

# DM-worker Configuration: worker.toml
# MySQL Server ID, 注意不要和已有的 ID 冲突
server-id = 8262
# 可以理解为 worker 的唯一标识
source-id = "worker-8262"
worker-addr = "127.0.0.1:8262"
# 支持源为 mysql 或 mariadb
flavor = "mysql"
# 是否启用 GTID，开启前需要上游 MySQL 开启 GTID 功能
enable-gtid = true
# MySQL Master/Slave 发生切换时，是否修复 gtid
auto-fix-gtid = true
# 开始同步的位置，我这里使用 GTID，该值为 MySQL Master 上的 Executed_Gtid_Set 值
# relay-binlog-name = "binlog.000140"
relay-binlog-gtid = "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2"
# charset of DSN of source mysql/mariadb instance
charset = ""
# worker 元数据存储目录，需要提前创建好
meta-dir = "/home/dm/meta/worker-8262"
# relay log 的本地存储目录，需要提前创建好
relay-dir = "/home/dm/relay/worker-8262"

# 源数据库，一个 worker 只能对应一个 MySQL 源
[from]
host            = "127.0.0.1"
user            = "dm"
# 该密码为使用 dmctl -encrypt ${你的原始密码} 加密后的字符串
password    = "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"
port            = 3306

# relay log purge strategy
[purge]
interval            = 3600
expires             = 0
remain-space    = 15

配置不算特别复杂，需要留意的地方都在注释里进行说明了。其中 source-id 请记下来，接着配置 dm-master 需要用到。

再次提醒，MySQL 的密码配置需要使用 dmctl 进行加密处理。

dm-master

# dm-master Configuration: master.toml
log-level       = "info"
log-file        = "/home/dm/log/dm-master.log"
master-addr = "127.0.0.1:8261"

[[deploy]]
source-id = "worker-8262"
dm-worker = "127.0.0.1:8262"

配置文件比较简单，基本上都不需要解释。其中 [[deploy]] 对应一个 worker，可以有多个 [[deploy]] 。目前了解到的，dm-worker 只能通过配置文件并重启 dm-master 进行加载，无法通过 dmctl 进行运行上填加。好在 dm-master 几乎随时都可以重启，所以也不是特别大的问题。

dmctl

# dmctl Configuration: ctl.toml
master-addr = "127.0.0.1:8261"

dmctl 的配置就相当简单了，只需要指定 dm-master 地址。而 dmctl 也是我们与 dm-master 打交道的最直接工作。

集群启动

经过上述的配置（是不是没有想像中复杂），我们已经可以开启集群了：

启动 master: bin/dm-master -config master.toml
启动 worker: bin/dm-worker -config worker.toml

除了跟踪日志输出，确认进程是否正常启动。我们还可以借助 dmctl 来检查当前集群的情况，使用 bin/dmctl -config ctl.toml 连接集群，并通过 query-status 查询集群状态，返回如下（成功）：

» query-status
{
    "result": true,
    "msg": "",
    "workers": [
        {
            "result": true,
            "worker": "127.0.0.1:8262",
            "msg": "no sub task started",
            "subTaskStatus": [
            ],
            "relayStatus": {
                "masterBinlog": "(binlog.000172, 234)",
                "masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
                "relaySubDir": "2ea42e60-a157-11e9-8f2d-0ef02be0adee.000001",
                "relayBinlog": "(, 4)",
                "relayBinlogGtid": "34204ac9-a157-11e9-bc03-c6e9019f8073:1-2,2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558",
                "relayCatchUpMaster": true,
                "stage": "Running",
                "result": null
            },
            "sourceID": "worker-8262"
        }
    ]
}
»

这个时候，系统还没有配置任何同步任务，所以也可以看到显示的是：no sub task started。接下来，我们开始来配置一个最基础的同步任务。

配置并应用同步任务

创建任务配置文件

PingCAP 在任务配置这一块有比较完善的说明了DM 任务配置文件介绍。这里我们以将源库为 abc 迁到目标库 abc_dm 为例子做简单说明：

---
name: test
task-mode: all
is-sharding: false
meta-schema: "dm_meta"
remove-meta: false
enable-heartbeat: false

target-database:
  host: "192.168.143.41"
  port: 3306
  user: "dm"
  password: "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"

mysql-instances: # 源库及相关的同步规则配置
  -
    source-id: "worker-8262"

    meta:
      binlog-name: binlog.000140
      binlog-pos: 141868
    route-rules: ["user-route-rules-schema"]
    black-white-list: "instance"

routes:
  user-route-rules-schema:
    schema-pattern: "abc"
    target-schema: "abc_dm"

black-white-list:
  instance:
    do-dbs: ["abc"]

上面参数的说明都可以在官方文档找到，这里对几个重要的参数再做补充说明：

参数	说明
meta-schema	DM 会将该 task 对应的 meta 信息，如断点（checkpoint）存储至目标集存中的该数据库
remove-meta	通常我们希望在重启 worker/task 时可以从上次断点继续同步，需要设置为 false
password	需要使用 dmctl 加密
source-id	理解为相应 dm worker 的 source-id
routes	可以在这里配置数据库表的改名规则，具体参考官方文档
filters	这里没有用到，可以过滤相应的 binlog events，如 `drop table` 操作，具体参考官方文档

应用并启动同步任务

使用 bin/dmctl -config ctl.toml 登录 dm master，并执行 start-task test.yaml 即可，确认 test.yaml 文件在当前目录下，成功的话将收到如下返回：

{
    "result": true,
    "msg": "",
    "workers": [
        {
            "result": true,
            "worker": "127.0.0.1:8262",
            "msg": ""
        }
    ]
}

这个时候再执行 query-status 可以看到相应的 dm worker 有了具体的 subTaskStatus 信息：

            "subTaskStatus": [
                {
                    "name": "test",
                    "stage": "Paused",
                    "unit": "Sync",
                    "result": {
                        "isCanceled": false,
                        "errors": [
                        ],
                        "detail": null
                    },
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "0",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(binlog.000176, 234)",
                        "masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
                        "syncerBinlog": "(, 4)",
                        "syncerBinlogGtid": "",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": false
                    }
                }
            ],

这个时候我们通过 mysql 登录目标数据库，可以看到多了 dm_meta 和 abc_dm 两个数据库，其中 dm_meta 里面有两张表：

test_loader_checkpoint 其中 test 是任务的名称，这张表存储的是全量同步的 meta 信息；

            id: worker-8262
      filename: abc.t3.sql
     cp_schema: abc
      cp_table: t3
        offset: 156
       end_pos: 156
   create_time: 2019-09-29 12:03:59
   update_time: 2019-09-29 12:04:00

test_syncer_checkpint 其中 test 是任务的名称，这张表存储的是增量同步的 meta 信息；

            id: worker-8262
     cp_schema: abc
      cp_table: xxy
   binlog_name: binlog|000001.000176
    binlog_pos: 538
     is_global: 0
   create_time: 2019-09-29 12:11:25
   update_time: 2019-09-29 12:11:25

组件升级

dm-master

dm-master 主要负责 dmctl 的通讯，维护任务及 Sharding DDL lock 信息，重启后会与 dm-worker 重启这些信息，所以除了影响 dmctl 短暂的使用，可以随时重启，升级也就比较简单了：下载新版本 -> 覆盖旧 binary -> 重启。

dm-worker

dm-worker 在本地维护了 meta 信息，在下游（目标）数据库维护了断点（checkpoint）信息，升级也是按：下载新版本 -> 覆盖旧 binary -> 重启即可。唯一需要注意的有：

尽量避免在 sharding DDL 同步过程中重启 DM-worker。

当然，本身对数据的敬畏之心，即使没有 sharding，也不推荐在 DDL 的过程中重启 dm-worker。

dmctl

命令行交互工具，直接升级即可：下载新版本 -> 覆盖旧 binary。

问题处理

dm-worker 挂了，并且本地的 meta 信息都丢失了怎么办？

通常不需要担心，找回按原来的 worker.toml 再启动 worker 即可。其中配置文件中的 relay-binlog-gtid 或 relay-binlog-name 的位置信息可能在源数据库已经过期，可以从目标集群的 meta 库找回，或者直接从源数据库集群上使用一个相对靠前的位置信息替换即可。

确认新的 worker 已经启动后，再次通过 dmctl 执行 start-task test.yaml 即可，task 的配置文件不需要修改，断点信息会从目标数据库中的 meta 库直接获取。

总结

官方的组件（概念）特别多，ansible 的包装让用户对相关组件的工作流程了解门槛大大提升。实际部署流程比想像中较为简单。从可靠性来看，还是比较推荐放弃 syncer（较长时间未更新了），并使用 dm 做为替代工具。

MySQL Seconds_Behind_Master 忽大忽小？莫慌

2019-09-07T22:33:00+08:00

本周在某次开会的时候，忽然收到了大量的 MySQL Seconds_Behind_Master 落后的报警轰炸（落后时间随机，几百到几万秒不等），但是当我们的值班 DBA 登录 MySQL 通过 show slave status\G 查看时，发现都是 0，通常我们认为这个时候复制是正常的。那么是什么情况导致了报警的发生呢？

DBA 值班同学也比较没有头绪，我们首先做了以下几件事情：

确认监控插件是否变更？收到的答复是没有；
我们自己是否有变更？收到的答复是没有。

事后打脸了，有一位同学做了报警策略的变更，从原 X 时间内只发送第 N 条报警修改成了 X 时间内只发送第 1 条报警。该策略的变更也会导致该报警的轰炸，但是他变更的时间是在报警轰炸之后，跟此次报警轰炸原因没有正相关；

登录多个实例确认都是误报后，先通告产品，明确是误报事件，让产品不用担心，等待 DBA 查明原因；

接下来我们会议正常进行，由某位 DBA 同学对此问题进行持续跟进，这个时候了解到某报警系统正在维护，猜测与他们有关系。但是即使是与他们有关系，这个落后的时间又是如何得来的呢？暂时 DBA 值班同学也没有很好的 GET 到头绪，DBA 老司机可能当时不是特别在状态，有点懵。

刚好会议环节进入非重点环节，偷偷转移精力排查了一下，做为 DBA 门外汉，首先想到的是我要确认是不是 MySQL show slave status 里真的出现了随机的落后数值，所以我做了最原始的一件事情：写了一个 2 秒执行一次 show slave status 的脚本对 Secons_Behind_Master 进行检查，果然在脚本执行了几分钟后出现了非 0 的数值，且是一个较大的超出实际线上情况的数值。（这里已经确认了是 MySQL 本身会有这个情况出现）

接下来怎么办呢？门外汉的第一反应当然是查手册啦（手册大多数时候都是解毒良药），几乎是没有耗费时间的，直接在 MySQL 官方文档里关于这个问题的非常重要的一句说明：

when the slave I/O thread is still queuing up a new event,
Seconds_Behind_Master may show a large value until the SQL thread 
finishes executing the new event.

MySQL Replication 通常情况下有两个工作线程，I/O 线程用于获取 MySQL Master 的 Binlog，SQL 线程用于将获取到的 Binlog Events 在 Slave 从库上进行回放。

上面的描述我们通过字面简单进行了理解：当 I/O 线程仍在排队等待一件新事件时，Seconds_Behind_Master 有可能返回一个较大的随机值，直到 SQL 线程完成该事件的重放。

那么这里我们已经可以确认了，MySQL 是会出现这个情况的，并且是正常的，至少这个报警轰炸是不用特别担心了。那为什么忽然就炸出来了呢，在后面几分钟后我们得到了几个信息，确认了原因：

该报警原先的设置是 X 时间内只发送第 N 条报警：X 时间内并不一定总会出现 >= N 次的随机 Seconds_Behind_Master 飙升（并且被监控插件获取到）；即使出现 >= N 次，在 X 时间内也只会发送一条报警，所以这个问题一直并没有被注意到；
从报警平台的同事了解到，确实在维护过程中，报警策略匹配有问题，导致 X 时间内只发送第 N 条 这个策略没有生效，所有报警都发了出来；
如前述，某同事确实做了策略变更，该变更可以明确是错的，但跟上述的轰炸没有正相关。

这个时候我们整体的原因已经比较清楚了，恢复生效的策略，并同步通告相关产品具体的情况，让产品安心是我们服务的目标之一。

但这里也暴露了几个问题：

报警平台维护变更出现了一定的问题，导致策略失效；
部分 DBA 同学在某些环节对系统的了解并不够完整、也不够专业（我们都需要不断学习积累的，我自己也是学习中，能理解）；
DBA 同学在做策略变更的时候也没有在团队内部进行同步，存在管理和规范遵守上的问题；

以上问题需要我们进行反思，并在团队内进行解决。但是 MySQL Seconds_Behind_Master 是否还有监控的价值呢？对可能导致 Seconds_Behind_Master 异常的情况这里做个简单的总结：

Replication 启动时，Slave 会在主库执行 SELECT UNIX_TIMESTAMP() 并进行主库和从库的系统时间差值对比，以避免由于系统时间差异对于 Seconds_Behind_Master 的时间产生影响。但如果是 Replication 启动后的时间异常，还是会对 Seconds_Behind_Master 产生影响，因此确保系统时间的同步非常重要（ntpd）；
当 Master 和 Slave 间的网络较差时，I/O 线程不能快速的获取 Binlog Events，SQL 线程处理速度是有可能超过 I/O 线程的，那么这个时候即使是 0，也不代表主从同步是正常的。（良好的网络环境是主从同步的基础保障）
当 I/O 线程被关闭时，该值可能为 NULL。（可以理解为特殊情况）；

Seconds_Behind_Master 怎么用？

结合以上情况，我认为 Seconds_Behind_Master 还是一个很重要的同步是否落后的参考值的，只是可能我们可以做得更完善一些，比如在获取的时候，可以通过二次获取进行判断，当获取到较大值时，再次获取一次当前值进行确认。

另外，如果需要较为严格的同步监控，建议通过 Binglog 的位置：

Master_Log_file/Read_Master_Log_Pos
Relay_Master_Log_File/Exec_Master_Log_Pos

进行判断，如果(Relay_Master_Log_File, Exec_Master_Log_Pos) 和 (Relay_Master_Log_File, Read_Master_Log_Pos)位置相等且 Seconds_Behind_Master=0，那么我们可以认为目前的同步是「同步」的。（开启 gtid 的话，比对 Executed_Gtid_Set 我认为也是没有毛病的）

The End

后续相关技术内容的总结，也会逐步更新至微信平台（微信目前确实也是技术内容流转的一个好渠道），欢迎关注个人公众号（也算给自己立个 flag 吧，希望 flag 永不倒）：

在 Mac 中对 iPhone 手机网络进行抓包的方法

2018-11-02T19:58:00+08:00

通过数据线连接 Mac 笔记本，并通过 itunes 查询手机的 UUID
Mac 提供了一个工具 rvictl （rvi=Remote Virtual Interface）可以为连上的 iphone 手机创建一个虚拟网络设备，不管手机用的是移动网络还是 WIFI，均可以通过该设备进行抓包。启动虚拟设备的命令如下：

rvictl -s ${uuid}

如果成功启动，将返回：

Starting device xxxxxxxx [SUCCEEDED] with interface rvi0

其中的 rvi0 即为可用于抓包的虚拟设备。

如果操作失败，并返回 bootstrap_look_up(): 1102 错误，请通过如下命令启动服务，并重复 rvictl -s ${uuid} 的操作即可：

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.rpmuxd.plist
之后就可以通过 tcpdump 命令进行抓包了，如：

tcpdump -i rvi0 -s 0 -vvv dst host x.x.x.x -w test.pcap
之后可以通过 wireshark 打开 test.pcap 进行查看。通常你可以使用 brew cask install wireshark 安装 wireshark.

怎么通过 iTunes 往手机上安装 ipa 包？

旧版本的 iTunes，在设备信息里有个「应用」入口，并可以在这里安装 ipa 文件。这次顺便发现 iTunes 没有了这个入口，刚拿到 ipa 包时，有点不知道怎么办。原来，只要将将文件拖到 iTunes 对应的设备里，就会自动安装了。（拖到下面截图红色框框部份）

一次「安全」的变更将 redis cluster 送进了孤岛

2018-07-16T00:51:00+08:00

鉴于 redis 没有有效的鉴权方法（特别是 redis cluster），为了防止人为疏忽导致系统防火墙未被有效开启，我们决定对线上的 redis 增加显示监听内网 IP 配置：

bind 127.0.0.1 ${本机内网 IP}

在我们看来，这是一个不可能出现问题的变更，因此也没有专门安排测试。事实证明，没有保持敬畏之心的我们还是太天真了！

线上配置发布后，重启 redis 服务，一切都很顺利，进程成功启动。然后，灾难开始降临，业务开始反馈 redis 缓存无法读写，查看 redis 日志，发现：

Cluster state changed: fail

尝试通过 redis-cli 连接进行操作，连接没有问题，但当我们尝试执行 get a 操作时，集却群反馈错误：

-CLUSTERDOWN The cluster is down

首要事件是保证服务可用，我们第一时间回退配置，重启后 redis 服务恢复正常。

问题回放

开启 Debug 模式，发现有大量的 createing socket: invalid argument 怀疑是 redis 拿了 bind 中的第一个 IP 为节点 IP，导致集群中所有节点的 IP 为 127.0.0.1，因此集群的通信出现问题（事后 review 代码确认跟第一个 IP 有关系，但不是导致所有节点的 IP 为 127.0.0.1）。

1616:M 02 Jul 11:02:25.407 # Cluster state changed: ok
......
13236:M 02 Jul 11:02:27.104 . Unable to connect to Cluster Node [10.x.x.x]:16379 -> creating socket: Invalid argument
13236:M 02 Jul 11:02:27.104 . Unable to connect to Cluster Node [10.x.x.x]:16379 -> creating socket: Invalid argument
......
1616:M 02 Jul 11:02:38.438 # Cluster state changed: fail

有了上面的怀疑之后，我们尝试修改 bind 的配置，将 127.0.0.1 放到后面，即：

bind ${本机内网 IP} 127.0.0.1

重启集群发现问题果然没有出现，感觉自己好机智（进行源码分析后，发现自己还是想的太简单了）。

源码分析

redis 版本：3.2.11

根据 Cluster state changed: fail 我们定位到，redis 是在 cluster.c 的 clusterUpdateState 函数里进行集群的状态判断：
- 当节点状态为 CLUSTER_NODE_FAIL 或 CLUSTER_NODE_PFAIL 时，节点被标记为不可达；
- 当不可达的 master 节点大于 quorum 时，集群被标记为不可用；
```c / Compute the cluster size, that is the number of master nodes * serving at least a single slot. * * At the same time count the number of reachable masters having * at least one slot. / { ... if ((node->flags & (CLUSTER_NODE_FAIL|CLUSTER_NODE_PFAIL)) == 0) reachable_masters++; ... }
```
/* If we are in a minority partition, change the cluster state
 * to FAIL. */
{
    int needed_quorum = (server.cluster->size / 2) + 1;

    if (reachable_masters < needed_quorum) {
        new_state = CLUSTER_FAIL;
        among_minority_time = mstime();
    }
}

/* Log a state change */
if (new_state != server.cluster->state) {
    ....
    /* Change the state and log the event. */
    serverLog(LL_WARNING,"Cluster state changed: %s",
        new_state == CLUSTER_OK ? "ok" : "fail");
    server.cluster->state = new_state;
    ...
}
```
```
redis cluster 主要是通过 cluster.c 中的 clusterCron 定期判断收集集群的状态，也是在这个函数里我们发现了最主要的探测函数 anetTcpNonBlockBindConnect 及非常符合异常特征的参数名称 NET_FIRST_BIND_ADDR

c fd = anetTcpNonBlockBindConnect(server.neterr, node->ip, node->port+CLUSTER_PORT_INCR, NET_FIRST_BIND_ADDR); if (fd == -1) { /* We got a synchronous error from connect before * clusterSendPing() had a chance to be called. * If node->ping_sent is zero, failure detection can't work, * so we claim we actually sent a ping now (that will * be really sent as soon as the link is obtained). */ if (node->ping_sent == 0) node->ping_sent = mstime(); serverLog(LL_DEBUG, "Unable to connect to " "Cluster Node [%s]:%d -> %s", node->ip, node->port+CLUSTER_PORT_INCR, server.neterr); continue; }
anetTcpNonBlockBindConnect 函数位于 anet.c 文件中，该函数调用了另一个函数 anetTcpGenericConnect，NET_FIRST_BIND_ADDR 在这里的实际作用为 source addr，问题原因已经呼之欲出了。我们再次定位 anetTcpGenericConnect 函数，找到以下内容：

c if (source_addr) { int bound = 0; /* Using getaddrinfo saves us from self-determining IPv4 vs IPv6 */ if ((rv = getaddrinfo(source_addr, NULL, &hints, &bservinfo)) != 0) { anetSetError(err, "%s", gai_strerror(rv)); goto error; } for (b = bservinfo; b != NULL; b = b->ai_next) { if (bind(s,b->ai_addr,b->ai_addrlen) != -1) { bound = 1; break; } } freeaddrinfo(bservinfo); if (!bound) { anetSetError(err, "bind: %s", strerror(errno)); goto error; } }
通过以上内容，我们可以确认 redis cluster 在健康检测，建立 socket 连接时，尝试绑定了 socket 源地址，那么 NET_FIRST_BIND_ADDR 内容究竟是什么呢？这个我们在 server.h 文件中找到了答案，确实是 bind 配置中的第一个 IP，也就是我们这里的 127.0.0.1

```c / Get the first bind addr or NULL /

define NET_FIRST_BIND_ADDR (server.bindaddr_count ? server.bindaddr[0] : NULL)

```

问题结论

redis cluster 在检测节点健康状态时，尝试与其它节点建立连接，但强制使用了 bind 配置中的第一个 IP 为建立 socket 的源地址
以上案例，当配置了监听 127.0.0.1 时，redis cluster 将尝试使用本地地址 127.0.0.1 去和一个外部节点建立链接，因此失败了；
基本的解决方法：使用 bind 配置时，确保将可进行通讯的 IP 放在第一个；
有没有其它问题：如果这是一个新建的 cluster 集群，那么在使用 redis-trib.rb 进行初始化集群时，该配置将导致 redis-trib.rb 工具长期阻塞，无法成功执行；
所有支持 cluster 的 redis 版本均受影响（包括 unstable 分支）；

其它

私以为强制使用 bind 第一个 IP 进行通讯的方法略有不妥，如果检测健康状态时一定需要指定源地址的话，兴许做出如下调整会有一定的优势：

当未初始化时（集群节点未明确 IP 地址），建立 socket 连接，不要指定源地址，由操作系统自行分配源地址即可；
当 redis cluster 初始化时，可以使用初始化时指定的节点 IP 做为源地址；
redis 在 anet.c 文件里，其实还提供了 anetTcpNonBlockBestEffortBindConnect 函数，这个函数如果通过绑定源地址建立 socket 链接失败后，会再次尝试由系统分配源地址的方式（不绑定），健康检查函数换成这个也不失为一个好办法；

最（chao）后（xi）：对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。

MongoDB 随机查询获取一条或 N 条记录的方法

2018-05-24T12:14:13+08:00

熟悉 MySQL 的同学应该都知道可以通过类似如下语句简单的获取一张表里随机的 N 条记录：

SELECT * FROM table ORDER BY RAND() LIMIT N;

在 MongoDB 里应该如何操作呢？官方在 3.2 版本带来了直接的解决方案：

$sample (aggregation)

具体应该如何操作，官方也给出了一个示例，假设 Collection users 有如下记录：

{ "_id" : 1, "name" : "dave123", "q1" : true, "q2" : true }
{ "_id" : 2, "name" : "dave2", "q1" : false, "q2" : false  }
{ "_id" : 3, "name" : "ahn", "q1" : true, "q2" : true  }
{ "_id" : 4, "name" : "li", "q1" : true, "q2" : false  }
{ "_id" : 5, "name" : "annT", "q1" : false, "q2" : true  }
{ "_id" : 6, "name" : "li", "q1" : true, "q2" : true  }
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true  }

那么可以通过命令 db.users.aggregate( [ { $sample: { size: N } } ] ) 获取随机的 N 条记录，如：

mongos> db.users.aggregate( [ { $sample: { size: 3 } } ] )
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true }
{ "_id" : 4, "name" : "li", "q1" : true, "q2" : false }
{ "_id" : 1, "name" : "dave123", "q1" : true, "q2" : true }
mongos> db.users.aggregate( [ { $sample: { size: 3 } } ] )
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true }
{ "_id" : 3, "name" : "ahn", "q1" : true, "q2" : true }
{ "_id" : 2, "name" : "dave2", "q1" : false, "q2" : false }
mongos>

$sample 会使用如下两种方式来获取随机的 N 条记录，具体使用哪种方式取决于如下条件：

$sample 处于聚合管道的第一阶段；
N 小于总文档数量的 5% ;
集合（Collection）中的文档数量大于 100；

当以上 3 个条件都满足时，$sample 将通过伪随机的游标来获取记录。当任一条件不满足时，$sample 将进行集合扫描，并通过随机排序来选择相应的 N 条记录。

需要注意的是：

当使用随机排序来获取记录时，排序操作会有 100 MB 的内存限制，具体可以参考 $sort and Memory Restrictions；
$sample 有可能多次返回同一条记录（document）；
尝试在一张十亿级的 Collection 上获取 1W 条随机记录，耗时约 2.5 秒，供参考；

参考文档：

https://docs.mongodb.com/manual/reference/operator/aggregation/sample/
https://jira.mongodb.org/browse/SERVER-533

《OKR 工作法》读书笔记

2018-01-30T09:50:00+08:00

目标用来明确方向，关键结果则用来量化目标，使团队和个人聚焦在一个有挑战性的目标上。

确定目标，确保团队聚焦
- 目标要有明确方向并鼓舞人心
- 目标要有时间期限
- 目标必须真正属于你
  
  思考，哪些是关键成果，哪些是目标：销售额提升 30%/用户增加一倍/收入增加到 500 万美元/完成一轮融资/拿下 XX 市场/推出一个最小化可行产品
讨论关键结果，复盘 OKR
评估 OKR 实施成果
影响目标达成的关键因素
- 没有给目标设置优先级
- 缺乏充分沟通，导致没能准确理解目标
  
  目标完成的进度必须在每周会议和邮件中汇报，分解出的项目任务必须能支撑目标的达成；
- 没有做好计划
  
  承担、庆祝与盘点
- 没有把时间花在重要的事情上
  
  重要的事情通常不紧急，紧急的事情通常不重要思考：计划应该是为了重要不紧急还是紧急不重要？
- 轻易放弃
害怕失败，不给自己挑战机会，隐藏实力，导致目标设置太低期望过高，没有能力实现没有坚持跟进目标，直到最后一周才发现没有进展（注意前面的，需要持续复盘、评估、沟通）

OKR 就是要通过不断实践、总结，发不断发现、挑战团队的潜力，不要把这个过程当作汇报、考核的结果。没有完成，一起思考为什么会这样、怎么改进。目标达成，那就设置更有挑战的目标。把精力聚焦在学习总结、挖掘潜力和高效执行上。

其它建议：

如何评估绩效：持续沟通，不地加以指导和校正。管理者和员工各自分享自己的观点与想法，这样可以减少误解，问题也能得到快速解决。年终评估的事实大家可以通过持续的沟通提前知道。
目标里不要有传统的绩效考核指标。
OKR 进度确认（如周会）是一次谈话，而不是汇报（A做了什么B做了什么，这叫流水帐）或指示。
《OKR 工作法》
OKR 练习册

网易游戏 MySQL-MongoDB 运维及 DBA 招聘

2017-11-15T22:51:00+08:00

以下岗位部门均属于网易在线游戏事业部。其中 MongoDB 运维及运维开发工程师可选工作地点为广州或杭州。

相关数据库产品均服务于如《荒野行动》、《梦幻西游》、《大话西游》、《阴阳师》、《我的世界》、CC等网易游戏海量用户业务。如果需要也有更深入了解的，也可以给我留言或者微信（二维码戳我）私我。同时欢迎推荐及转发。

岗位一：MySQL DBA 点我投递简历

工作职责

参与内部MySQL SaaS开发和维护工作；
优化数据库，提高数据处理效率；
负责数据库新技术的调研和测试；
负责处理故障，服务请求，运维环境优化；
和开发团队及其他部门进行沟通协作。

职位要求

精通MySQL等数据库系统使用，精通SQL语句和优化；
熟悉Linux系统操作；
了解网络，有一定的故障排查和处理能力；
熟悉shell脚本编程，会Python、Java者优先；
有大型数据库和大规模服务器管理经验优先；

岗位二：MongoDB 运维工程师点我投递简历

职位描述：

负责 MongoDB 等数据库平台的配置管理、流程管理；
响应用户需求，提供协助或技术解决方案，配合业务完成数据库集群的部署、升级、扩容、缩容等；
通过全方位、立体化监控系统快速发现和处理故障；
配合优化数据库服务运维规范、工作流程、应急预案等，确保任何突发情况都能高效响应；
汇总用户需求，并设计技术需求方案，促进产品发展；

职位要求：

熟悉 Linux 系统以及工具命令等使用，熟悉主流开源软件的配置及调优，有底层基础技术研发经历的优先；
熟悉至少一种程序设计语言，有 Shell、Python 等脚本编程语言经验者优先；
对计算机硬件设备、网络设备有一定了解，熟悉 TCP/IP 以及具有丰富的网络知识；
熟悉 MongoDB 数据库的日常使用；
掌握 MongoDB 的管理及构建，包括但不限于集群构建、性能调优、备份恢复；
具备良好的沟通表达能力和服务意识，较强的团队合作意识，快速处理突发事件的能力；
有大型 MongoDB 商用部署实施及运营经验者优先，有 OCP 认证者优先。

岗位三：运维开发工程师（数据库平台）点我投递简历

职位描述：

负责内部数据库相关产品的管理平台、自动化流程开发工作；
与产品、PM、运维同学协作，积极高效推动产品开发；
与用户及其他部门进行沟通协作；

职位要求：

1 年或以上前后端开发工作经验；
对开发有浓厚兴趣，HTML/CSS/JS 基础扎实，熟悉Angulajs、Reactjs、Vue.js等MVVM框架中的一种；
有至少一种 server 端开发经验，熟悉 Python、PHP 语言开发者优先；
至少一种熟悉Web开发框架（如Django/Flask/Tornado）；
对 HTTP 协议、网页性能优化有一定的理解；
熟悉 MySQL、MongoDB、Redis 等数据库应用开发优先；
能够编写高扩展、易维护的代码，熟练且规范使用代码管理工具；

岗位四：高级运维工程师（DNS方向）点我投递简历

职位描述：

负责 DNS 及配套系统部署、维护及运维环境、服务优化；
日常系统运维、服务请求、故障处理等技术支持；
网络、系统等维护配套系统部署、维护；
和项目开发团队及其他部门进行沟通协作；
负责新技术的调研和测试。

职位要求：

熟悉 Linux 系统操作；
熟悉 shell 脚本语言编程，会 Python 者优先；
了解 TCP/IP 网络，有一定的故障排查和处理能力；
熟悉 DNS 协议、BIND，有相关运维经验，并能够快速实施部署、配置和排障；

LXC 如何找出容器对应的 veth 设备

2017-03-29T11:42:00+08:00

LXC 使用 veth 模式时，如果宿主机上创建了很多容器，那么宿主上将存在大量的 vethXXXX 设备，肉眼难以直接确认每个虚拟容器使用的是哪个 veth 设备。

在我的记忆中，方法比较复杂，且之前忘了记录下来，已经遗忘。今天重新尝试使用另一方法获取匹配信息，这里做下记录：

虚拟机（容器）执行 ethtool -S eth0 拿到如 peer_ifindex: 16，其中 eth0 为在虚拟机（容器）内对应的设备名称；
宿主机执行：ip link show | grep '^16:'，其中 16 为第一步拿到的 peer_ifindex，通过该命令拿到的 vethXXXX 即为虚拟机（容器）使用的设备。

记一次 Apache 性能调优

2017-03-23T09:44:00+08:00

手上有一组 web 服务，使用 apache 对外提供服务，其中apache 使用 worker 模式，这堆 web 服务器有以下一堆毛病：

apache 长期占用大量 CPU，负载长期居高不下。
每天 rotate log 的指令不能被 apache 处理，通过 lsof 可以看到被删除的日志文件没有正确关闭。

通过监控、日志统计，发现 qps 并不高，单台机器 qps 为600 左右（机器为 16 核、32G 内存），一开始以为是我代码性能问题，各种查找高消耗节点，无果。再次对服务器的整体情况及 apache 文档进行审视。

通过阅读 apache 官方文档在 worker 这里最重要的三个设置参数有 ServerLimit * ThreadsPerChild >= MaxClients ，但我们服务器上的配置远大于 qps（理论上，实际并发数会小于 qps）。尝试调小以上参数以接近 qps 数值，服务器负载没有发生明显变化。

再次观察系统负载（top）发现，apache 进程的 pid 一直在产生变化，产生了新的怀疑，是不是因为「频繁的销毁、创建 apache 进程」导致的开销过大，造成 cpu 负载居高不下？

再次阅读文档，其中两个会导致进程销毁的设置分别为：

MaxRequestsPerChild

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.

这个值，我们的设置是 0，所以不会是因为这个设置导致的。

MaxSpareThreads

For worker, the default is MaxSpareThreads 250. These MPMs deal with idle threads on a server-wide basis. If there are too many idle threads in the server then child processes are killed until the number of idle threads is less than this number.

我们原来的值设置为 75，怀疑是因为这个值设得太小了，尝试将此值调整至与 MaxClients 相等，重启 apache ，发现负载开始持续下降，top 中 apache 进程 pid 几乎没有产生变化，服务正常，qps没有明显下降（未导致服务不可用）。新的配置如：

<IfModule mpm_worker_module>
    StartServers          2
    ServerLimit          12
    MinSpareThreads      25
    MaxSpareThreads     768
    ThreadLimit         128
    ThreadsPerChild      64
    MaxClients          768
    MaxRequestsPerChild   0
</IfModule>

至此问题解决，附优化前后的负载对比图：

优化前：

优化后：

pip 升级 pip 失败

2016-05-19T12:11:00+08:00

今天在使用 python pip 安装一个 python 包的时候，一直提示：

# pip install --upgrade pip
Requirement already up-to-date: pip in /usr/local/lib/python2.7/dist-packages
You are using pip version 8.1.1, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

尝试按说明执行 pip install --upgrade pip ，没有任何报错，但一直升级不成功，百思不得解，在查看 man pip 的时候，找到如下选项：

-v, --verbose
    Give more output. Option is additive, and can be used up to 3 times.

尝试执行 pip install --upgrade pip -vvv 终于有更多提示：

1 location(s) to search for versions of pip:
* http://example.url/simple/pip/
Getting page http://example.url/simple/pip/
Starting new HTTP connection (1): example.url
"GET /simple/pip/ HTTP/1.1" 403 247
Could not fetch URL http://example.url/simple/pip/: 403 Client Error: Forbidden for url: http://example.url/simple/pip/ - skipping
Installed version (8.1.2) is most up-to-date (past versions: none)
Requirement already up-to-date: pip in /usr/local/lib/python2.7/dist-packages/pip-8.1.2-py2.7.egg
Cleaning up...

这时才发现，原来在我的 ~/.pip/pip.conf 配置文件里，index-url 使用了一个已经废弃的地址，删除文件后重新升级，一切恢复正常。

这么重要的 debug 信息，pip 默认竟然不输出，继续百思不得其解。:-)

Mac OSX Yosemite 10.10 WIFI 掉线修复

2014-11-17T14:35:00+08:00

原先用的是 Mac Air 11，通过Time Machine迁移至 Mac Retina 13，最后升级成 Yosemite 10.10 的，系统已经用了一段时间的，最近才忽然出出WIFI掉线的问题。

而且此掉线比较奇怪，WIFI Connection正常，TCP/UDP/ICMP包均不正常，并且我试过在ping/safari/ssh等均异常的情况下，我某正在下载内容的应用（genymotion），却坚持到了最后，并成功下载完了近200M的内容，所以基本排除了无线路由的问题。

重启电脑无效，网上搜到这么一编文章：别忙升级，苹果 Yosemite 频现 WiFi 断线综合症

虽然前面两种方法无效，但第三种方法还是给了我启示的，凭直接猜测应该是：

/Library/Preferences/SystemConfiguration

这个目录，进行这个目录，果然看到一堆与wifi关键字的文件：

$ ls
NetworkInterfaces.plist             com.apple.smb.server.plist
com.apple.airport.preferences.plist com.apple.wifi.message-tracer.plist
com.apple.captive.probe.plist       preferences.plist

把这些文件删掉（我是先备份了一下的，建议你也这样做），重启Mac。注意本次重启，是不会自动连上之前使用的wifi的，需要自己去点击连接一下，然后问题就解决了。

后来在网上看到 Fix Wi-Fi Problems in OS X Yosemite 这编文章，其实只要删除：

com.apple.airport.preferences.plist
com.apple.network.identification.plist
com.apple.wifi.message-tracer.plist 
NetworkInterfaces.plist 
preferences.plist

这些文件就可以了，解释也很到位，比oschina那个靠谱多了。:-)

2014-11-18 昨天折腾完，今天收到Apple Store的更新提醒，10.10.1 fix了wifi这个问题了

查询 dns server 使用的bind版本

2014-07-07T20:21:00+08:00

其实命令很简单，但我发现我老记不住，所以做个记录吧（我总是把version.bind记成bind.version，orz）

 dig @${server} TXT CHAOS version.bind

${server}换成你想查询的dns服务器IP地址即可，如：

dig @8.8.8.8 CHAOS TXT version.bind

其实通常情况下出于安全考虑，大多数我们是查询不到版本信息的（系统管理员禁用了）

bind 可以通过如下设置禁用版本号查询：

options {
    version none;
}

或者你可以将此值设置为某个固定字符串，如 "someone like you"

crontab 同时显式指定day of month和day of week的特殊说明

2014-05-09T13:31:00+08:00

man 5 crontab:

           field         allowed values
           -----         --------------
           minute        0-59
           hour          0-23
           day of month  1-31
           month         1-12 (or names, see below)
           day of week   0-7 (0 or 7 is Sun, or use names)

Note: The day of a command's execution can be specified by two fields -- day of month, and day of week. If both fields are restricted (ie, are not *), the command will be run when either field matches the current time. For example, ''30 4 1,15 * 5'' would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Fri-day.

来自wikipedia的说明（http://en.wikipedia.org/wiki/Crontab）：

While normally the job is executed when the time/date specification fields all match the current time and date,
there is one exception: if both "day of month" and "day of week" are restricted (not "*"),
then either the "day of month" field (3) or the "day of week" field (5) must match the current day.

以设置crontab： 11 14 27 3 3 为例，下面两个类型的时间都能满足该表达式：

3月里的每一个周三
3月27日

Linux系统上通知网关更新arp

2014-03-19T16:02:00+08:00

经常会有在线更换Linux服务器IP的操作，该操作带来的一个问题是: 我们已经执行了修改IP的操作，但由于网络上（网关）的ARP缓存暂未更新，导致在某一段时间内，该服务器会有网络不通的情况存在。

因此，我们需要在变更IP的同时，通知网关刷新ARP缓存。

首先清除本地ARP缓存:

/bin/ip neigh flush dev eth0

其次向网关发送本机的ip/mac地址

/usr/sbin/arping -v -c 2 -S 1.1.1.144 -s 00:17:a4:8d:0e:98 -p 1.1.1.1

1.1.1.144 为本机IP

00:17:a4:8d:0e:98 为本机MAC地址

1.1.1.1 为网关

Java 发起Http Post请求

2014-02-19T17:16:00+08:00

对于一个 Java 小白，每完成一个新的功能，都表示相当不易，就连 Apache HttpClient 偶都表示没搞明白，看起来好像不同版本还有不同的方法，没办法，还是借助于 Google，拼凑出了这一段代码，记录以备自己后用。

功能：使用 http post 方式访问某使用了 CNNIC 证书的站点（cnnic，唉，好多不信任）

/*
 * Java POST Example
 */

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.ProtocolException;
import java.net.URL;
import java.net.URLEncoder;
import java.io.DataOutputStream;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.logging.Level;
import java.util.logging.Logger;

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.security.KeyStore;


import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;

/**
 *
 * @author Greg （原链接：http://sigterm.sh/2009/10/simple-post-in-java/）
 */
public class SimpleHttpPost {

    /**
     * Pretend you're a script...
     */
    public static void main(String[] args) throws Exception {
        URL url = null;

        /* 加载CNNIC证书开始 */

        X509TrustManager sunJSSEX509TrustManager;
        // 加载 Keytool 生成的证书文件
        char[] passphrase;
        String p = "changeit";
        passphrase = p.toCharArray();
        File file = new File("java.cnnic.cacert");
        System.out.println("Loading KeyStore " + file + "...");
        InputStream in = new FileInputStream(file);
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        ks.load(in, passphrase);
        in.close();

        // 构造 javax.net.ssl.TrustManager 对象
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers();

        // 使用构造好的 TrustManager 访问相应的 https 站点
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tms, new java.security.SecureRandom());
        SSLSocketFactory ssf = sslContext.getSocketFactory();

        /* 加载CNNIC证书结束 */
        try {
            url = new URL("https://demo.site.url/uri/");
        } catch (MalformedURLException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        HttpsURLConnection urlConn = null;
        try {
            // URL connection channel.
            urlConn = (HttpsURLConnection) url.openConnection();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Let the conn use SSL
        urlConn.setSSLSocketFactory(ssf);
        // Let the run-time system (RTS) know that we want input.
        urlConn.setDoInput (true);

        // Let the RTS know that we want to do output.
        urlConn.setDoOutput (true);

        // No caching, we want the real thing.
        urlConn.setUseCaches (false);

        try {
            urlConn.setRequestMethod("POST");
        } catch (ProtocolException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        try {
            urlConn.connect();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        DataOutputStream output = null;
        BufferedReader input = null;

        try {
            output = new DataOutputStream(urlConn.getOutputStream());
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Specify the content type if needed.
        //urlConn.setRequestProperty("Content-Type",
        //  "application/x-www-form-urlencoded");

        // Construct the POST data.
        String content =
          "username=" + "randomuser" +
          "&password=" + "wrongmd5string";

        // Send the request data.
        try {
            output.writeBytes(content);
            output.flush();
            output.close();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Get response data.
        String str = null;
        try {
            input = new BufferedReader(new InputStreamReader(urlConn.getInputStream()));
            while (null != ((str = input.readLine()))) {
                System.out.println(str);
            }
            input.close ();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Java 使用自签证书访问https站点

2013-12-26T10:18:00+08:00

最近被 Java 使用自签证书访问 https 的问题折腾得体无完肤，做为一名 Java 小白，我也忍不住想感慨一下，不同 Java 程序员的水平差别真的好大，有些根本无法沟通，都不知道他们怎么胜任日常的编码工作的=,= 同时做为一个 Java 黑，我觉得，好吧，更黑了。。

anyway，经过各种折腾，至少总结出了以下两种使用自签证书访问 https 站点的办法。

方法一

拿到相应的 https 站点证书后（好吧，我这里是cnnic.crt，顺便吐槽一下万恶的 cnnic 证书，各种不信任）：

keytool -import -alias ${alias} -keystore ${JAVA_HOME}/jre/lib/security/cacerts -file ${path-to-certificate-file}

其中

${alias} 请替换为你想使用的名称，比如我这里是 CNNIC
${JAVA_HOME} 请替换为你自己的 JAVA_HOME 目录，比如我这里是 /usr/lib/jvm/java-6-openjdk
${path-to-certificate-file} 请替换为你的ca证书路径，比如我这里就是当前目录的 cnnic.crt

那么，我需要完整执行的命令就是：

keytool -import -alias CNNIC -keystore /usr/lib/jvm/java-6-openjdk/jre/lib/security/cacerts -file cnnic.crt

如果 keytool 要求你输入密码，在你没有变更过的情况下，该值默认为英文 changeit 。

方法二

有些同学表示，他们的服务器不允许导入证书，或者他们是一个很大的集群，不适合每台都导入，那怎么办呢？方法就是在每次访问的时候，程序自己加载相应的证书，但是在加载证书之前，你还是需要使用 keytool 工具将原ca转换成 Java 可以读取的证书格式，命令同方法一，只是 keystore 的位置你可以放在你的程序可以读取的任一路径，如我这里：

keytool -import -alias CNNIC -keystore java.cnnic.cacert -file cnnic.crt

之后在你的 Java 程序里，使用 keystore 加载该证书，并附加该证书创建 https 请求即可。

从 Java 官方 docs 和网上拼凑了小样例一枚，请君参照并自行完善：

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.security.KeyStore;


import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;

public class LoadCert {
    public static void main(String[] args) throws Exception {

        X509TrustManager sunJSSEX509TrustManager;
        // 加载 Keytool 生成的证书文件
        char[] passphrase;
        String p = "changeit";
        passphrase = p.toCharArray();
        File file = new File("java.cnnic.cacert");
        System.out.println("Loading KeyStore " + file + "...");
        InputStream in = new FileInputStream(file);
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        ks.load(in, passphrase);
        in.close();
        // 构造 javax.net.ssl.TrustManager 对象
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers();
        // 使用构造好的 TrustManager 访问相应的 https 站点
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tms, new java.security.SecureRandom());
        SSLSocketFactory ssf = sslContext.getSocketFactory();
        URL myURL = new URL("https://replace.to.your.site.real.url/");
        HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection();
        httpsConn.setSSLSocketFactory(ssf);
        InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream());
        int respInt = insr.read();
        while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }
    }
}

OpenID4Java 使用dumb模式（stateless）并禁用 discovery

2013-12-25T12:20:00+08:00

使用无状态模式（dumb mode/stateless）发起 OpenID 认证请求：

manager = new ConsumerManager();
manager.getRealmVerifier().setEnforceRpId(false);
// 强制manager使用无状态模式
manager.setMaxAssocAttempts(0);

禁用 discovery

// 不要使用manager.discover构造discoveries
// List discoveries = manager.discover(userSuppliedString);
// 使用人肉构造discoveries
List discoveries = new ArrayList();
discoveries.add( new DiscoveryInformation( new URL("http//real.openid.server.url") ) );

ssh client 通过 socks5 proxy 登录远程服务器

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

今天某同学需要登录某国家服务器（A），但从我朝过去网络延时非常大发现从岛国过去的速度相当快，但因为岛国的服务器（B）不适合加该同学的帐号因此做了一个 socks5 proxy ，然后本地 ssh client 通过该 proxy 登录A服务器

ssh -o ProxyCommand='nc -x ${proxy_server}:${proxy_server_port} %h %p' xxx.xxx.xxx.xxx

如：

ssh -o ProxyCommand='nc -x 127.0.0.1:7070 %h %p' 8.8.8.8

需要注意的是，nc需要使用 OpenBSD 版本，非 Linux 默认版本（该版本不支持）通常，类 Debian 的衍生版本，都可以通过如下命令直接安装：

apt-get install netcat-openbsd

非OpenBSD 可能报如下错误：

/bin/nc: invalid option -- 'x'

Mac OSX iTerm2 终端UTF-8和GBK编码自由切换

2013-10-29T16:43:00+08:00

老树使用的是Mac OSX系统，平时终端都是使用iTerm2替代默认的Terminal进行使用。

考虑到各种兼容性，个人一直使用的是UTF-8编码，但由于老树管理着大量服务器，并且可能使用的是GBK或者其它编码，经常由于终端环境编码的不同，导致登录服务器出现乱码，或者需要处理GBK文件时，要使用iconv进行多次编码转换，相当麻烦。

好在iTerm2使用了比较友好的Profile配置及切换方式，首先我的默认配置（Default Profile）使用了UTF-8编码：

我另外建立了一个Profile，叫GBK：

并编写了一个非常简单的切换脚本：

#!/bin/bash
# 使用GBK Profile
echo -e "\033]50;SetProfile=GBK\a"
# 环境编码切换为GBK
export LANG=zh_CN.GBK
export LC_ALL=zh_CN.GBK
# 更改当前 iTerm2 tab title
echo -ne "\033]0;"$@"\007"
$@
echo -ne "\033]0;"${PWD/#$HOME/~}"\007"
# GBK任务完成后，自动切换回默认编码（UTF-8）
echo -e "\033]50;SetProfile=Default\a"
export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8

将以上内容保存为一个叫grun的文件，并赋予可执行权限，同时加到系统可执行目录（PATH）

当我需要登录一台GBK编码的服务器时，只需要

grun ssh ${hostname}

即可

sshd无法使用secureFX传输文件

2013-09-24T15:58:00+08:00

某同学表示，某些机器无法使用secureFX进行文件传输。

正常情况下：

i RECV : AUTH_SUCCESS
i RECV : Server Sftp Version: 3
i SEND : RealPath(raw) .
i Resolved RealPath: /home/demo
i SEND : OpenDir /home/demo

而无法传输文件的服务器则是如下日志：

i RECV : AUTH_SUCCESS
i Changing state from STATE_CONNECTION to   STATE_TRANSPORT_STOPPING.
i Changing state from STATE_TRANSPORT_STOPPING to STATE_CLOSING.
i Changing state from STATE_CLOSING to STATE_CLOSED.

查看/etc/ssh/sshd_config配置，发现缺少sftp的相关配置，在该配置文件中增加：

Subsystem   sftp    /usr/libexec/openssh/sftp-server

然后重启sshd服务，问题解决。

Django Admin 使用 filter_horizontal 不生效

2013-09-23T15:25:00+08:00

考虑到Django 1.0.2 admin的功能实在太弱了，今天冒着大风险，将某系统的Django进行了升级（升级至Django 1.2.7）。

Django 1.2.7 admin在使用ManyToManyField的时候，默认使用垂直filter_vertical方式进行显示与选择。此方式在选项比较多的时候，难以直观的看出哪些选项被选中，如下图所示：

决定使用更直观的方式，filter_horizontal，设置比较简单，只要在admin.py里对应的模块下，添加类似如下内容即可：

filter_horizontal = ['example']

filter_horizontal显示方式如下图所示：

但是，当我设置了此选择后，发现出现了奇怪的问题，如下图：

没有报错，但也没有出现设想中的选择框。经过研究，发现，原来是因为我对应的字段ips，在models.py里定义的时候，verbose_name使用了字符串，而不是unicode，如下：

ips = models.ManyToManyField( IPData, verbose_name = "使用IP" )

调整为

ips = models.ManyToManyField( IPData, verbose_name = u"使用IP" )

问题解决。使用string是因为我们这些是一些老旧的系统，新项目必须果断的抛弃string，拥抱unicode吧！

pelican增加自定义jinja template filters

2013-09-11T19:46:00+08:00

pelican官方文档没有显式的指明应该如何自定义jinja template filters.

在制作标签云的时候，不想写复杂的javascript，更不想又import一份javascript进来，所以决定自己搞一个比较简单的标签云

pelican默认的tag排序比较简单，为了能有比较“云”的感觉，决定对tag加个随机排序

查了Jinja的文档，没有随机排序的filter。由于我使用了virtualenv，所以最简单粗暴的解决方案是直接修改了Jinja的源码，添加了随机排序的功能

不过对于稍微有些“洁癖”的好，这样改后，心理上非常难受，决定到pelican社区，看看是否有幸添加个patch

当然，更幸运的是在github找到了此commit:

https://github.com/getpelican/pelican/pull/96

原来有个JINJA_FILTERS的设置，那一切就好办了, 增加自定义模块jinja_filters.py

import random

def shuffle( value ):
    """ Jinja template filter for shuffling list/tuple """
    if not isinstance( value, list
            ) and not isinstance( value, tuple ):
        return value
    random.shuffle( value )
    return value

在pelican配置文件里填加:

from jinja_filters import shuffle

JINJA_FILTERS = { 'shuffle' : shuffle }

尝试重新编译生成html文件，顺利完成。

配置Bind使用MySQL dlz模式

2013-09-09T16:18:00+08:00

** 安装MySQL/Bind with dlz **

略过，bind dlz安装，只需在编译的时候增加 --with-dlz-mysql 选项即可。

** 创建 MySQL 数据库 **

根据自己的需求创建即可，如使用如下命令创建一个名为 dns 的数据库：

CREATE DATABASE dns DEFAULT CHARSET UTF8;

使用 use dns 切换进 dns 数据库后，使用如下命令创建一张 dns_records 表：

CREATE TABLE `dns_records` (
`zone` varchar(255) NOT NULL,
`host` varchar(255) NOT NULL,
`type` varchar(12) NOT NULL,
`data` varchar(255) NOT NULL,
`ttl` int(11) DEFAULT '600',
`id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

这里以域 example.com 为例，说明如上字段意义，假设我需要有一条 www.example.com 的记录指向 1.1.1.1 这个IP，应该增加哪些内容：

zone:

域，这里指 example.com

host:

主机名（名字），这里为 www

type:

记录类型，这里为A

data:

域名资源数据，这里为IP地址 1.1.1.1

ttl:

域名TTL，为任意整数（建议不要低于120，即2分钟）

将该数据库授权给某用户（后续bind-dlz配置需要用到）：

grant select on dns.* to dns@localhost identified by 'dns';

用户名为 dns ，密码也为 dns ，只允许本地主机 localhost 访问，并只给予了 select 权限。

** Bind-dlz配置 **

这里只涉及dlz的配置，其它named.conf的配置不涉及

dlz "your custom description" {
    database "mysql
        {host=localhost dbname=dns user=dns pass=dns}
        {select zone from dns_records where zone = '$zone$'}
        {select ttl, type, data from dns_records where host = '$record$' and zone='$zone$'}";
};

your custom description:

管理员自行添加的描述

配置完成。

Django multiple select option with title

2013-09-09T15:02:00+08:00

from django import forms
from django.utils.encoding import force_unicode
from django.utils.html import escape, conditional_escape

class SelectMultipleWithTitle(forms.SelectMultiple):
    """ multiple select optihon with title """
    def render_option(self, selected_choices, option_value, option_label):
        option_value = force_unicode(option_value)
        selected_html = (option_value in selected_choices) and u' selected="selected"' or ''
        return u'<option value="%s"%s title="%s">%s</option>' % (
            escape(option_value), selected_html,
            conditional_escape(force_unicode(option_label)),
            conditional_escape(force_unicode(option_label)))

install Facebook scribe on Debian Squeeze

2013-09-08T13:03:00+08:00

系统:

Debian Squeeze 6.0 amd64

thrift: 0.8.0

hadoop: 0.20.2 cdh3 hadoop-0.20_0.20.2+923.142

scribe: git current version

首先安装各种库，包括但不局限于:

python-dev maven2 ant sun-java6-jre sun-java6-jdk bison flex gcc make autoconf libevent-dev libboost-all-dev git-core

之后:

sudo update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java #确保使用的不是openjdk

安装thrift:

tar -zxvf thrift-0.8.0.tar.gz

cd thrift-0.8.0

./configure --prefix=/usr/local/thrift-0.8.0

make

sudo make install

安装fb303:

cd thrift-0.8.0/contrib/fb303

sh boostrap.sh

./configure --prefix=/usr/local/fb303-0.8.0 --with-thriftpath=/usr/local/thrift-0.8.0 CPPFLAGS="-DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H"

make

sudo make install

安装hadoop:

使用apache官方下载的版本编译各种不成功，其中一个错误（编译scribe时出现）:

HdfsFile.cpp:255: error: ‘hdfsConnectNewInstance’ was not declared in this scope

ConnectNewInstance是在hadoop 0.21之后的版本才出现的，由于我这边hadoop的服务器是0.20.2，所以只能使用cloudarea版本

由于我在在编译时，cloudarea页面无法下载对应版本hadoop(或者跳转到apache页面)

只好使用如下方式进行下载，首先，修改/etc/apt/source.list，增加

deb http://archive.cloudera.com/debian squeeze-cdh3u2 contrib

deb-src http://archive.cloudera.com/debian squeeze-cdh3u2 contrib

然后使用apt-get source hadoop-0.20进行下载

tar -zxvf hadoop-0.20.2.tar.gz

mv hadoop-0.20.2 /usr/local

cd /usr/local/hadoop-0.20.2

sudo ant compile-c++-libhdfs -Dislibhdfs=true #由于cdh3/apache提供的hadoop包内的libhdfs库不一定能使用，重新编译c++的libhdfs库

安装scribe:

git clone https://github.com/facebook/scribe.git

cd scribe

sh bootstrap.sh

./configure --prefix=/usr/local/scribe-2.2 --with-fb303path=/usr/local/fb303-0.8.0 --with-thriftpath=/usr/local/thrift-0.8.0 --with-hadooppath=/usr/local/hadoop-0.20.2 --enable-hdfs CPPFLAGS="-DHAVE_NETDB_H=1 -fpermissive -DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H -I/usr/local/hadoop-0.20.2/src/c++/libhdfs -I/usr/lib/jvm/java-6-sun-1.6.0.26/include -I/usr/lib/jvm/java-6-sun-1.6.0.26/include/linux" LDFLAGS="-L/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64 -L/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server -L/usr/local/hadoop-0.20.2/build/c++/Linux-amd64-64/lib"

make

sudo make install

其它配置:

由于我这里各软件包都是自定义安装路径，需要配置一下ld加载路径，编辑(增加) /etc/ld.so.conf.d/scribe.conf

/usr/local/thrift-0.8.0/lib/

/usr/local/hadoop-0.20.2/build/c++/Linux-amd64-64/lib/

/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server/

保存退出后

sudo ldconfig

Windows OpenVPN GUI记住用户名和密码

2013-09-08T12:51:00+08:00

日常工作中经常使用VPN，由于Server端要求进行用户名和密码校验，在第一次链接的时候，OpenVPN Client会弹出输入用户名和密码的窗口。

如果网络比较稳定的情况下，这个还没什么问题，网络不稳定的时候，每次弹开，都会弹出重新验证的窗口，加上我自己的密码比较长，不胜其烦

我使用的版本（2.3.1），实际上已经支持保存密码的功能（旧版本可能需要重新编译），在ovpn配置文件里增加:

auth-user-pass pass.txt

之后在ovpn配置文件所在目录建立一个pass.txt的文件，第一行为用户名，第二行为密码即可。

PS：这样对自己电脑的安全性要有足够的保证，否则密码泄露就得不偿失了。

Debian系统添加全局根证书（CNNIC）

2013-09-08T12:25:00+08:00

鉴于CNNIC的证书默认被不信任，导致了应用在访问某些使用cnnic证书的ssl站点时，请求失败。

虽然我也不喜欢cnnic，但没办法，这是反抗不了的事情。

过程如下（需要root权限）：

apt-get install ca-certificates #一般情况下应该是已经有安装的了

mkdir -p /usr/share/ca-certificates/local #建立local目录是为了方便区分这是自己填加的证书，可以自定义，但一定要在/usr/share/ca-certificates目录下

将cnnic的证书复制至/usr/share/ca-certificates/local目录，请注意，证书的后缀必须修改为.crt

dpkg-reconfigure ca-certificates #选中刚才添加的local/cnnic.crt证中，确定，即可

小生说大声讲

我只是想打开一个 Markdown 文件看一眼——于是 vibe coding 了一个编辑器

一个小到可笑的需求

我试过的那些编辑器，以及为什么都不行

那就自己写一个吧

途中那些有意思的坑

坑一：swift run 启动后，窗口躲到了别人后面

坑二：公式和图表，到底要不要联网

坑三：模式切换后，怎么还"停在原地"

坑四：藏不住的图表"闪一下"

现在的 Markdown2 长什么样

一点心路体会

姚顺宇 4 小时访谈，通透有趣的灵魂~

借长鑫科技的东风，把存储这件事一次讲透

一、AI 时代的存储，凭什么分成六层

二、龙头格局：三强 + 一个新入场的第四名

三、长鑫的产业链全景：设备 + 材料 + 客户

上游 · 设备（国产化率 ≈ 45%）

上游 · 材料（领先设备一个身位）

下游 · 客户与封测

四、为什么 DRAM 这一波"确定性"格外强

结语

USB 命名混乱救命表：从 1.1 到 120Gbps

为什么需要这张表

营销名 vs 技术名

Gen 命名约定：A x B 是什么意思

线材：4 / 8 / 12 芯

USB-A / USB-B 接口（4 芯 / 8 芯）

USB-C 接口（12 芯）

充电规格 / PD 档位

2026.04 补充：USB 80Gbps 已经量产

参考

啤酒游戏：让 Claude 和 Codex 干了这杯酒

一开始的分歧，其实不只是一道算术题

第一轮：双方先各自为自己的答案辩护

第二轮：真正让局面收敛的，不是继续争观点，而是“用对方的尺子重算一遍”

第二轮之后，Codex 的主要修正也很明确

1. 承认原先的 7500/7900 元量级不合理

2. 接受“第 2 周订 12 箱”作为基准更优方案

到最后，双方其实收敛到了什么？

一个小插曲：我自己也踩了“AI 不重读文件”的坑

这次复盘，对流程最大的启发是什么？

1. 有争议的题，不能只让双方“表态”，要让它们“同口径重算”

2. 案例题里，分歧很多时候不是“算错”，而是“口径没统一”

3. 最终共识最好落成文件，而且最好双方都落

这道题本身也给了我一个额外收获

尾声

我是怎么让 Claude 和 Codex 帮忙完成课程作业

左右互博：把裁判位置也交给 AI

Claude 翻出了自己的错

用 Python 作第三个独立裁判

然后它把自己之前写错的那份改了

为什么「左右互博」比让单一模型深挖更靠谱

我有不担心的地方，也有担心的地方

尾声

用 Cloudflare Worker + KV 给静态博客加一个浏览量计数

静态站做计数的几种路子

先用 OpenSpec 把事情说清楚

seed 前端叠加：让老文章不从零起算

Worker 侧：两个端点、几行代码

部署踩坑：custom_domain 的首次 deploy

前端：不到 50 行

跑起来之后的样子

写在后面

Claude 在这个周末帮我翻新了博客

背景：博客的技术债从哪来

案例一：双仓库合一

案例二：这个周末，换主题

用 OpenSpec 先把事情说清楚

新主题 stuhouse

一个中间的小坑

归档

用 AI 修基础设施的一点体感

尾声

LLM 让程序员的编程美德“懒惰”更显重要了

程序员的三大美德

懒惰的悖论：偷懒需要付出大量努力

Brogrammer 文化：虚假的勤奋

LLM：给 Brogrammer 注射类固醇

Garry Tan 的「作品」被拆解

坑一：`swift run` 启动后，窗口躲到了别人后面