P99 CONF 是一个线上会议，专门讨论高性能、低延迟的应用，2026 年的大会在 10 月 21 日至 22 日举办。本文从 60 多场演讲中挑选了五场来介绍，主题都是数据库在不同设计之间如何取舍。比如，读写和存储空间往往此消彼长：让写入变快，读起来可能更费劲。还有团队把数据放到对象存储上并加缓存，用便宜的大容量存储换取稍慢的冷读取；也有团队改用内存索引，让读取更快、几乎不出现长尾延迟，代价是占用更多内存、写入更重。这些结果都针对演讲中特定的测试负载，并非通用性能保证；演讲录像需注册后可在 p99conf.io 点播观看。
文中可用工具
- SlateDB开源库，让开发者在 S3 等对象存储上直接搭建键值数据系统，不用自己实现 LSM
- LogstorScyllaDB 中可选开启的存储引擎，面向读多写少的键值负载，用内存索引加快单点查询
- Valkey内存数据库，文中通过多线程网络 I/O 和槽位迁移来提升吞吐和横向扩展速度
- turbopuffer向量搜索引擎，在对象存储上支撑千亿级向量的低延迟检索
- RaBitQ二进制量化方法，把向量的影子索引压缩到每维一位，用来先缩小候选范围
展开详情收起详情：五场 P99 CONF 演讲揭示了数据库的哪些权衡取舍⌄
原文发布：2026-10-30 21:00 · 首次收录：2026-10-31
安全公司 Snyk 回顾了 PHP 引擎两个严重漏洞（PHP2Shell）的应对过程。问题出在代码之下：漏洞位于 PHP 引擎处理请求的环节，应用代码还没开始运行就可能被利用，所以即使代码写得干净也挡不住。攻击者只需发一个无需登录的请求，而很多团队根本说不清 PHP 到底跑在哪些对外地址上。Snyk 的做法是先盘点外部可见资产、标出用 PHP 的主机，再上线针对性检测，打补丁后重测确认修复生效。对普通读者的意义是：漏洞从公开到被大规模利用只有几天，提前摸清自己对外暴露了什么，比事后临时找要快得多。文中提到 VirusTotal 指纹识别约 510 万个运行 PHP 的 IP，其中只有约 110 万主动暴露版本号。
文中可用工具
- Snyk API & Web从外部盘点域名资产、识别技术栈并做漏洞检测
- Snyk Container扫描容器镜像中的依赖和系统包漏洞
- Snyk Unmanaged检测不由包管理器安装的第三方组件漏洞
- VirusTotal指纹识别互联网上运行 PHP 的 IP 及版本信息
展开详情收起详情：PHP2Shell 不会是最后一个：下一个漏洞会先出现在哪里⌄
原文发布：2026-10-28 12:00 · 首次收录：2026-10-29
这篇文章讲的是 Kubernetes 控制平面在集群规模变大后，一些平时看起来正常的设计反而会把小问题放大成故障。作者举了三个真实例子：一个扩展 API 升级依赖后发布了不合法的 OpenAPI 模式，结果连只用普通 Kubernetes 资源、根本没用这个扩展的 Helm 部署也失败，因为 OpenAPI v2 把所有 API 的定义合并成一份文档，一个扩展出错就拖累所有人；大批 DaemonSet 代理同时重启，启动时的正常请求叠加成风暴，API 服务器扛不住；还有组件把依赖服务的短暂不可用误判成自己进程坏了，反复重启。文章建议用 OpenAPI v3 缩小影响范围、控制重启节奏、别让健康检查过度依赖下游。这是经验分享文章，没有发布新工具，文中提到的 OpenAPI v2/v3、informer、聚合 API 服务器、PR #131755 都是已有机制或改动。
文中可用工具
- OpenAPI v2把所有 API 的接口定义合并成一份文档供客户端读取校验
- OpenAPI v3按 API 组和版本分开提供接口定义，缩小单个扩展出错的影响范围
- informer让控制器在本地缓存集群状态，减少反复查询 API 服务器
- 聚合 API 服务器（aggregated API server）在不改核心 API 服务器的前提下给 Kubernetes 增加新 API
- Helm部署图表前会读取 OpenAPI 文档做校验，因此可能被无关扩展的错误波及
- DaemonSet在集群每个节点上运行代理，大规模重启时会集中产生请求
- Kubernetes PR #131755让 OpenAPI 模型名称由作者显式声明，而不是从 Go 包路径推导
展开详情收起详情：影响 Kubernetes 控制平面可用性的隐藏故障路径⌄
原文发布：2026-10-27 22:00 · 首次收录：2026-10-28
Nebius 的 AI 训练团队在 Terminal-Bench 类负载上做了一次实验：把一次 256 条轨迹的批次收集时间减少了 66.9%。原来在智能体强化学习训练中，模型要先完成任务、拿到结果才能学习，但任务长短不一，慢的几条会让整批训练卡住，昂贵的 GPU 常常在等便宜的沙箱和代码执行。做法是把推理引擎当成训练优化器的一部分：按整组完成而不是启动顺序来组批，让生成和训练部分重叠、缓存对话历史避免重复预填，并把基础设施故障和模型自身失败分开计分。这只是一个实验中的批次收集测量，不含训练器本身的前向反向计算，不等于完整训练提速。对读者来说，这提供了一个思路：智能体训练慢，瓶颈往往不在 GPU 算力，而在任务执行和调度这些配套环节。
文中可用工具
- Nebius提供 AI 训练与推理服务的公司，本文实验由其实施
- Terminal-Bench用于评测终端操作类智能体任务的基准，本文实验基于它构造负载
- GRPO一种强化学习训练方法，把同一任务的多次尝试相互比较打分
展开详情收起详情：Nebius 将 rollout 收集时间缩短 66.9%——改变了什么⌄
原文发布：2026-10-27 23:38 · 首次收录：2026-10-28
Google DeepMind 在周二发布了 Genie 4。它是一个“世界模型”，能实时生成可互动的场景，带有模拟物理、人物动作和声音，主要给 AI 智能体提供练习和测试任务的地方。原来开发者要测智能体，往往得自己搭仿真环境；现在可以用文字提示按需生成，甚至边生成边用键盘移动、改视角。问题在于，长时间运行后物体位置会漂移、物理表现不稳定，而且 Google 没有公布重复测试的一致性数据，所以失败时很难分清是智能体不行还是场景本身出错。目前只有受信任的测试者能用，之后计划开放给 Google AI Ultra 订阅者和部分合作方，价格和正式发布时间都没说。
文中可用工具
- Genie 4实时生成可互动模拟场景的世界模型，供智能体练习和测试
- Gemini Omni帮助塑造模拟环境的形态
- Gemini 3.8 Flash跟踪场景进展、规划下一步并在变化时调整
- Gemini 4 Argon在棋盘演示中规划每一步走法
- Gemini Robotics用于机器人研究的项目，可在变化环境中测试智能体
- Project Genie面向 Google AI Ultra 订阅者提供 Genie 4 的计划渠道
- Gemini API计划供部分合作方接入的接口
- Google AI Studio计划供部分合作方接入的开发平台
展开详情收起详情：Google 为 AI 智能体打造了一个可练习的世界，但物理效果还不太对⌄
原文发布：2026-10-28 06:33 · 首次收录：2026-10-28
这是一场演讲，讲者是 Khawaja Shams，主题是如何高效地大规模运行大语言模型（LLM）服务。问题在于：模型推理很吃 GPU，而对话上下文对应的 KV Cache 会占用大量显存，容易撞上“内存悬崖”，还会拖慢响应、推高成本。演讲从分布式系统的角度给出几种做法：提高 GPU 利用率、管理 KV Cache 内存、利用分层存储、降低尾部延迟，以及把预填充和解码拆开部署。读者可以借此了解如何让整套推理集群跑得更快、更便宜、更稳。目前公开的只有标题和摘要，具体实现细节、数据和演示材料均未说明。
展开详情收起详情：演讲：大规模 LLM 服务——隐藏的 KV Cache 优势⌄
原文发布：2026-10-27 19:00 · 首次收录：2026-10-28
Cloudflare 优化了其内部负载均衡服务中一致性哈希的 Rust 实现（pingora-ketama），把这项服务占用的内存减少了 100 TB 以上。原来的问题是：每个后端服务器要在哈希环上保存很多哈希条目，条目越多占用内存越大。这次的做法是压缩哈希环上的条目，并通过统计分析哈希分布和冲突率，把每个后端所需的哈希数量减少了约 90%。对读者来说，这说明大规模系统里看似不起眼的数据结构优化，也能省下巨量内存资源。
文中可用工具
- pingora-ketamaCloudflare 用 Rust 实现一致性哈希的组件，本次优化的对象
- Rust编写 pingora-ketama 的编程语言
展开详情收起详情：Cloudflare 优化一致性哈希，回收 100 TB 内存⌄
原文发布：2026-10-24 16:10 · 首次收录：2026-10-25
澳大利亚科研机构 CSIRO 做了一个叫 Serverless Beacon 的系统，用来查询基因组变异。以前的难点是：要查变异数据，通常得先把体积庞大的 VCF 文件整个复制进一个中心数据库，费时费钱。新办法不搬数据，而是直接用 Amazon S3、Lambda、Athena 和 DynamoDB，配合元数据索引和对压缩文件的 HTTP 字节区间读取，只取需要的那一小段来查。测试中，查询 1 万个碱基对平均耗时 1.52 秒。对研究者来说，这意味着不必先复制整份数据就能更快检索变异信息；不过目前只是测试结果，是否已开放使用原文没说。
文中可用工具
- Serverless BeaconCSIRO 开发的无服务器基因组变异查询系统
- Amazon S3存储基因组数据文件
- Lambda无服务器计算，按需执行查询逻辑
- Athena对存储数据做查询分析
- DynamoDB存放元数据索引
展开详情收起详情：CSIRO 利用无服务器架构在 AWS 上查询的基因组变异数量提升 100 倍⌄
原文发布：2026-10-23 22:30 · 首次收录：2026-10-24
PHP 项目在 2026 年 10 月 21 日发布了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修复两个严重漏洞：攻击者不需要登录、也不用任何账号，只要发送恶意网页请求，就可能直接在服务器上运行自己的代码，危害极大。问题出在 PHP 引擎处理请求的流程里，而不是某个第三方包，所以升级 PHP 本身才是解决之道。官方说没有完全规避的办法，唯一安全的选择就是升级；如果仍用 8.1 或更早版本，需要找系统发行版或长期支持厂商拿回补丁，或者直接升级。另外 10 月 23 日补充了一个编号 CVE-2026-115560 的变体绕过问题，只有应用在运行时动态切换 session 序列化方式才可能受影响，普通部署可以暂时不用紧张。读者应尽快确认每台机器实际运行的 PHP 版本，不要只看扫描结果。
展开详情收起详情：PHP 修复两个无需认证的严重 RCE 漏洞（CVE-2026-109618、CVE-2026-109619），并更新 CVE-2026-115560⌄
原文发布：2026-10-26 12:00 · 首次收录：2026-10-23
传统企业安全靠“先验证身份、再检查权限”就能管住软件，但 AI 智能体不一样：它会自己理解目标、挑选工具、创建子代理并动手执行，用的还是从人那里继承来的账号权限。问题在于，这些权限可能允许它做人类从没打算让它做的事，而且它的执行路线会随时变化，光在门口设一道关卡拦不住。文章提出用“观察、执行、构建、部署”四个环节组成的持续安全生命周期，在每次具体操作前判断“这个代理、代表谁、要做什么、是否符合策略”，并先观察真实行为再逐步收紧限制。对读者来说，这提供了一个治理企业内 AI 代理的新思路，但文中没有说明具体产品或落地时间。
展开详情收起详情：AI 智能体安全是一个生命周期，而非守门人⌄
原文发布：2026-10-22 22:00 · 首次收录：2026-10-23
安全公司 Snyk 在旧金山 AISS 大会前一天办了一场圆桌讨论，请来 OpenAI、Google 威胁情报团队、风投机构和 Snyk 的四位安全负责人聊 AI 安全。原来大家早就积累了不少安全隐患，只是以前攻击成本高、没被利用；现在 AI 让攻击变得又便宜又快，等于把这些旧账一次性催收。讨论指出，找漏洞越来越容易，真正卡住人的是修复速度，所以防守方需要让机器承担大部分修复工作，并配合身份、权限和意图管控。文章还提到一个案例：有人用开源 AI 渗透测试工具攻击了至少九家韩国银行；另有研究发现，扫描的 3,984 个智能体技能中至少 36.82% 存在安全缺陷。这些是会上讨论的观点和案例，不代表已有现成方案落地。
文中可用工具
- ClawHub发布智能体技能的平台，会上提到上传一个恶意技能只需一个 Markdown 文件和新注册的 GitHub 账号
- Hugging Face模型与数据集平台，会上作为被 AI 智能体突破隔离、发生泄露的案例出现
展开详情收起详情：AI 正在清算你已接受的每一份风险：AI 安全圆桌的七点洞察⌄
原文发布：2026-10-21 08:00 · 首次收录：2026-10-22
安全公司 Snyk 扫描了上千个企业环境中的 AI 模型，发现近一半环境引用了可能在某种攻击下得分达到严重级别的模型。但作者强调，光看模型分数不够：同一个模型，如果只用来总结会议记录，和用来查询客户数据、触发业务流程，出事的后果完全不同。所以团队应先确认模型是否真的在运行、它能访问哪些数据和工具，再针对具体风险选择换模型或加访问限制、人工审批等控制措施。这项研究来自 Snyk 报告，其中模型分数基于模拟攻击测试，并不代表真实入侵已经发生。
展开详情收起详情：AI 模型风险取决于模型能触及什么⌄
原文发布：2026-10-21 12:00 · 首次收录：2026-10-22
Netflix 为跑在 Amazon EMR 上的 Apache Spark 任务做了一套“工作负载证明”机制。打个比方：过去托管计算任务要访问内部服务，得把内部凭证直接塞给任务，凭证容易泄露、也难管理。现在的做法是先确认这个任务的 AWS IAM 身份，再核对 Netflix 控制面签发的声明，两者都通过后，才发一张有效时间很短的内部 X.509 证书，任务用它去访问内部服务。这样托管计算任务不必直接携带凭证，就能安全地完成内部认证，凭证暴露的风险和分发负担都小了。这套机制目前应用在 Netflix 的 Spark/EMR 场景，其他场景是否适用文中未说明。
文中可用工具
- Apache Spark在 Amazon EMR 上运行的分布式数据处理任务
- Amazon EMR托管运行 Spark 任务的 AWS 计算服务
- AWS IAM用于识别工作负载身份的云身份服务
- X.509 证书短期内部证书，用于访问内部服务
展开详情收起详情：Netflix 通过工作负载证明打通 AWS IAM 与内部身份体系⌄
原文发布：2026-10-21 21:45 · 首次收录：2026-10-22
Pinterest 在数据库接入流程里加了一套机制，用来判断持续灌入的数据什么时候“差不多齐了”，好让下游任务开始处理。以前这种持续写入的数据不好确定边界，容易处理到一半又来了新数据。他们用 Apache Flink 跟踪事件时间，再通过 Apache Iceberg 的元数据发布一个只增不退的水位线，作为“可以定稿”的信号。这样下游就能按分区处理已经足够完整的数据，支撑到 PB 级别。这属于工程机制分享，原文没有说明具体上线范围或性能数字。
文中可用工具
- Apache Flink跟踪事件时间，用于判断数据进度
- Apache Iceberg通过元数据发布只增不退的水位线
展开详情收起详情：Pinterest 利用事件时间水位线完成 PB 级数据分区定稿⌄
原文发布：2026-10-19 22:37 · 首次收录：2026-10-20
这篇文章讲的是 Kubernetes 控制平面的容量问题，但重点不是“集群有多大”。作者举了三个完全不同的集群：一是上万节点的训练集群，大量节点不停上报心跳，把 apiserver 和 etcd 的内存吃光；二是节点数不多但对象频繁创建、销毁的 Agent 平台，写入压力巨大；三是装了两百个 operator、对象多得每个 apiserver 都要在内存里存一份的平台集群。文章的核心观点是：这三种压力方向不同，按节点数调优往往治错病，加 apiserver 还可能因为每个都复制全量 watch 缓存而让情况更糟。作者提出从四个“接缝”入手（存储分工、节点存活上报、分片维度、缓存驻留），并说明部分能力已有现成配置，像 KEP-4743、KEP-5866 这样的改进仍在推进中，具体何时可用原文没有说明。对运维 Kubernetes 的读者来说，这是一份先分清自己属于哪种规模压力、再决定调优方向的思路清单。
文中可用工具
- Kubernetes容器编排系统，本文讨论的控制平面容量问题都发生在它上面
- etcdKubernetes 的键值存储后端，本文建议把非持久流量分流出去并用内存 lease 刷新减轻写压力
- kOps原文提到它文档里记录了增加 apiserver 的做法
- KEP-4743定义存储接口边界的提案，用来把不同资源类型路由到不同后端
- KEP-5866为 API 流量引入哈希范围过滤的提案，是分片的基础
- etcd-servers-overrides已有配置项，可把资源类型指向不同的 etcd 后端，但目前只支持内置资源
展开详情收起详情：规模不是一个数字：Kubernetes 控制平面不堪重负的三种方式⌄
原文发布：2026-10-18 22:00 · 首次收录：2026-10-19
Netflix 的工程师写文章介绍了他们怎么解决一个很头疼的问题：系统出故障时，找原因要找将近四个小时。原来监控工具收集了很多数据（指标、日志这些），但每个系统各说各话，同一个东西在不同工具里叫不同名字，得靠人脑记着怎么对应。他们的做法是建一个知识图谱，把应用、事件、部署这些概念和关系用统一格式写清楚，机器也能读。这样本来要翻三个工具才能回答的问题，现在一条查询就能搞定。文章还提到他们自研了一个叫 QuipuDB 的图数据库来存这些数据。不过文章只给了开头部分，具体效果数据、完整方案细节没有说明。
文中可用工具
- AtlasNetflix 的遥测平台，负责记录应用及其时间序列数据
- RadarNetflix 的告警系统，管理阈值和告警触发历史
- incident.io管理事件严重等级和响应人员
- PagerDuty管理值班轮换安排
- Spinnaker记录什么时间发布了什么内容
- QuipuDBNetflix 自研的 RDF 图数据库，用于存储知识图谱数据
- RDFW3C 标准的数据模型，用来表示知识图谱中的三元组
- OWLW3C 标准的本体语言，用来定义概念类型和关系规则
- SHACLW3C 标准的验证语言，用来检查数据是否符合定义好的规则
- SPARQLW3C 标准的查询语言，用来查询知识图谱中的数据
- redb基于 Rust 的嵌入式键值数据库，QuipuDB 的底层存储基础
展开详情收起详情：本体驱动的可观测性：在 Netflix 规模下构建端到端知识图谱⌄
原文发布：2026-10-17 00:01 · 首次收录：2026-10-17
InfoQ 出了一本小书，讲怎么让软件系统长期保持“可演化”，也就是在系统、技术和团队不断变化时，架构还能方便地跟着改。书里提到用智能体式的适应度函数来发现语义漂移，把“人能不能看懂”当作核心设计指标，还讨论跨云护栏与区域自治，以及如何让技术边界和康威定律对齐。它主张别再依赖静态架构图，而是用持续反馈系统让每次变更都安全、有意识。
展开详情收起详情：小书：实践中的演化式架构⌄
原文发布：2026-10-16 19:30 · 首次收录：2026-10-17
Uber 建了一套自动化系统，用来分析自家庞大服务网格里各个服务之间的依赖关系。以前主要靠分布式追踪来排查故障，但它只采样一部分请求，像偶发但影响大的失败很容易被漏掉。这次的新做法从 RPC 中间件和生产环境指标入手，把调用方的失败和被调用下游的失败关联起来，再判断依赖关系属于“失败即阻断”“失败可放行”还是未知。这样工程师能更完整地看清服务间的真实依赖，尤其是罕见故障的场景。
展开详情收起详情：Uber 实现服务网格依赖分析自动化⌄
原文发布：2026-10-16 22:39 · 首次收录：2026-10-17
美团团队为搜索和推荐场景里的小语言模型（SLM）做了一套新的推理引擎。原来这类场景要在 20 毫秒内返回结果，但通用推理框架（如 SGLang）是为开放式文本生成设计的，调度开销大、效率低。他们把这些“有固定计算步数”的请求重新组织成静态流程图来执行，并用编译和共享缓存等办法减少开销。结果是延迟仍低于 20 毫秒，吞吐达到 SGLang 的 10 倍，Prefill-only 的有效 MFU 为 67%。这套框架已经在美团搜索意图分流、相关性判断、生成式召回等场景取得实验显著性，能支撑全量推送。
文中可用工具
- AOTInductor把 PyTorch 模型提前编译成可直接加载的 GPU 计算产物
- Packed Prefill把多条变长输入打包处理，避免无效 padding 计算
- SGLang原本用于模型执行的通用推理框架，性能对比对象
- Triton Inference Server项目早期用其 Python Backend 适配业务协议
- vLLM原文仅提到名称，未说明具体用途
- PyTorch用于表达模型语义和选择算子实现
- FP8选择性使用的低精度矩阵计算，降低计算开销
展开详情收起详情：SLM 生成式高并发推理引擎：延迟约束下的有效吞吐优化⌄
原文发布：2026-10-15 15:00 · 首次收录：2026-10-16
Linux 创始人 Linus Torvalds 用 Anthropic 的 Claude Code 帮忙修一个折腾了两年的内核性能问题。问题是页缓存里频繁加减引用计数，拖慢了普通的缓冲读取，在他笔记本上八线程测试里几乎全部跨核开销都来自这里。AI 写出了补丁、测试和文档，他自己跑基准验证：八补丁版把吞吐从每秒 1000 万次读提到约 3300 万次，后续 10 个补丁的版本在 64 线程 Threadripper 上从 1330 万次涨到 3.04 亿次。不过评审者发现了一个竞态条件和内存回收隐患，Torvalds 已把后续开发交给内核开发者 Kiryl Shutsemau。目前这些补丁仍处于评审和修订阶段，尚未进入正式内核，且真实负载下的提升会小得多。
文中可用工具
- Claude CodeAnthropic 的 AI 编程助手，本次负责编写补丁、测试和文档并辅助审阅
展开详情收起详情：Linus Torvalds 让 Claude Code 修复 Linux 页缓存，评审者随后发现竞态问题⌄
原文发布：2026-10-15 06:59 · 首次收录：2026-10-15