最新

<a href="https://archive.ph/lZlAs" rel="nofollow">https://archive.ph/lZlAs</a> <a href="https://www.theguardian.com/technology/2026/jan/31/us-authorities-reportedly-investigate-claims-that-meta-can-read-encrypted-whatsapp-messages" rel="nofollow">https://www.theguardian.com/technology/2026/jan/31/us-author...</a>

大家好，HN， 我分享一下 S2C 的 Alpha 版本，这是一个基于 S3 构建的状态机复制系统。 目标是让分布式应用程序在无需节点仲裁的情况下，也能保持状态的一致性，同时保证可用性和一致性。 这个想法源于一个使用 S3 的副项目，当时我需要强一致性的分布式状态，但又不想增加一个单独的共识依赖。最初我尝试直接使用 S3 进行协调，但变得很混乱。最终，我意识到我需要一个带有确定性日志的复制状态机，然后它就变成了一个独立的的项目。 为了缓解 S3 的延迟和 API 成本，它默认使用基于时间和大小的批量处理。 S2C 支持： - 可线性化的读写操作（单节点） - 精确一次的命令语义（对于具有稳定身份的节点） - 动态节点加入和从零节点开始的冷启动恢复 - 无需时钟或租约即可实现脑裂安全 - 快照、日志截断等 当然，它用延迟和 S3 操作成本换取了操作的简单性——并非用于取代高吞吐量的 Raft 环。而且，显然，它只适用于已经使用 S3（或具有类似保证）的架构。 到目前为止，它已经通过了混沌/故障注入测试（崩溃、分区、领导者 kill）；计划进行形式化验证。 它仍处于 Alpha 阶段，但我希望大家试用、实验并提供反馈。 如果您有兴趣，代码和一份深入的指南在这里：[<a href="https://github.com/io-s2c/s2c" rel="nofollow">https://github.com/io-s2c/s2c</a>]

“每请求的Token数” 这种计费模式对我们的生产环境来说一直具有误导性。真正的成本驱动因素似乎是以下几个乘数：重试/429错误、工具扇出、P95上下文增长以及安全检查。 在你的生产LLM系统中，最大的成本乘数是什么？哪些策略有效（限制、降级模式、回退、硬性失败）？