最新

<a href="https://archive.ph/lZlAs" rel="nofollow">https://archive.ph/lZlAs</a><p><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（或兼容类似保证）的架构中使用。 到目前为止，它已经通过了混沌/故障注入测试（崩溃、分区、领导者被杀）；计划进行形式验证。 它仍处于alpha阶段，但我希望大家能尝试、实验并提供反馈。 如果你感兴趣，代码和详细的深入指南在这里：[https://github.com/io-s2c/s2c]

“每个请求的令牌数”在我们的生产环境中一直是一个误导性的成本模型。真正的成本驱动因素似乎是一些乘数：重试/429错误、工具分发、P95上下文增长和安全检查。 在你的生产大语言模型系统中，最大的成本乘数是什么？哪些政策有效（如上限、降级模式、后备方案、硬失败）？