2.4 亿域名实现 p99 0ms 自动补全
P99 0 ms* autocomplete for 240M domain names
我运营着 Wirewiki.com，一个用于检查 DNS 记录和邮件配置的网络基础设施工具。为了在竞争激烈的市场中脱颖而出，我将用户体验（UX）作为核心，致力于让自动补全功能达到“下一帧”般的即时响应。通过结合客户端预取缓存与后端优化的 API，我实现了在 99% 的情况下，结果在用户松开按键前就已准备就绪。后端架构采用内存中的字符 Trie 树处理热门域名，配合 SSD 内存映射索引处理海量长尾数据。尽管单台欧洲服务器受限于网络延迟，无法让全球用户都达到 p99 0ms，但这一技术探索展示了如何在 2.4 亿域名数据量下实现极致的搜索性能。
p99 0ms 意味着 99% 的时间里，搜索结果会在用户甚至松开按键之前就已经准备就绪。
HN 评论区
86- skybrian
这个自动补全功能会推荐根本不存在的域名。你随便输入一堆乱码，它也会给出建议，但点进去却发现没有任何记录。
自动补全框的一个主要用途应该是帮你避免拼写错误，这么一来反而让它没那么有用了。
- chrismorgan
使用 keyup 毫无道理，也不符合用户预期。对于触发操作（包括正常打字），你始终应该只用 keydown。（嗯，有一个我看不太明白的例外：按空格键激活按钮。这和点击一样是在释放时触发 keyup，而 Enter 键则是在按下时触发 keydown。）keyup 仅限于那些需要持续响应按键状态的场景，这在游戏里很常见。
这也影响了功能表现。事实上，用 keyup 而不是 keydown 反而引入了延迟。感觉很差。
- ViscountPenguin
很遗憾，在澳大利亚这边这种方案体验并不太好，这肯定和延迟有关。
我觉得你可以把这个问题建模成一个优化问题：使用完整的字母字典，再加上一个残差预测，旨在按流行度加权覆盖尽可能多的剩余域名树。这棵树可以预先构建好，并存储在同一系统中。这样即使在澳大利亚，你也能轻松实现 p99 0ms。
- oersted
为什么不直接在 keyDown 时触发获取请求，等响应一到就照常显示呢？
按键所需的时间作为 API 延迟的目标倒也算合理，但这仍然是一个任意的目标。如果你的 API 更快，非要等到 keyUp 才显示只会增加更多延迟。在我看来，和 keyUp 同步并不会让体验感觉更即时。
- kevmo314
如果你想进一步降低网络延迟，可以把每个 trie 节点存成一个文件，文件名就方便地设为该节点的前缀路径。然后把这几亿个文件扔到 R2 上。
这样一来，遍历操作就可以完全通过 CDN 查找来完成！