工程实践ScyllaDB Engineering
本文介绍用 Rust 重写 ScyllaDB Python 官方驱动的原因、设计与性能结果。作者选择 PyO3 作为 Rust-Python 绑定层，并通过同步/异步微基准说明小值调用开销可忽略，但大对象跨语言传递和大量小任务调度会显著变慢。序列化最终放在 Rust 侧，反序列化对原生 CQL 类型复用 Rust 现有逻辑、对复杂类型直接构造 Python 对象；借助 yoke 实现零拷贝结果迭代，以绕过 PyO3 无法暴露非静态生命周期的问题。分页、错误处理与元数据缓存也针对 Python 习惯做了重新设计，基准显示在插入、查询和并发场景下明显优于旧版驱动。文章也指出截至 2026 年 6 月该驱动尚未生产就绪，TLS、重试、负载均衡等仍在评审，兼容旧 API 也尚未完成。
推荐收录：文章给出了可复现的微基准与端到端对比，并详细记录 PyO3 绑定、序列化策略、yoke 零拷贝、分页与错误映射等工程取舍，证据链完整。适合数据库驱动、Rust/Python 互操作、性能优化与 API 设计方向的工程师阅读，其中“大对象避免跨 FFI 传递、大任务优于小任务”等结论可直接迁移。风险是驱动尚未生产就绪，部分能力仍在评审，读者需注意其阶段性结论。
工程实践ScyllaDB Engineering
本文复盘 ScyllaDB 用自研 C#-Rust FFI 框架重写 C# 驱动的实践，目标是在保持原 DataStax C# 驱动 API 基本不变的前提下复用 Rust 驱动的性能与正确性。作者利用 .NET 5 的改进互操作特性降低跨语言开销，并桥接 .NET 与 Tokio 异步运行时以避免阻塞线程。文章详述了序列化放在 C# 侧、以 RWLock 解决会话关闭的 TOCTOU/UAF 竞争、用 trait 映射错误、以原子快照管理元数据、转发 Rust 日志等取舍。基准显示新驱动在所有场景不慢于原驱动，高并发下约快一倍。当前开发暂停，功能完整性与维护仍待完善。
推荐收录：文章完整呈现 C#-Rust FFI 框架设计、TOCTOU/UAF 竞争修复、元数据快照与错误映射等关键取舍，并附可复现基准（高并发下约为原驱动两倍、接近 Rust 驱动）。对从事跨语言互操作、数据库驱动或高性能客户端开发的工程师有直接参考价值，会话生命周期管理、内存引用计数等模式可迁移。项目开发暂停是主要风险。
工程实践ScyllaDB Engineering
文章记录华沙大学学生与 ScyllaDB 合作，将 QUIC 集成进 Seastar（ScyllaDB 依赖的异步 C++ 框架）的工程实践。作者先剖析 TCP 队头阻塞与握手延迟的缺陷，再以无隐藏 I/O、无隐藏线程、符合 IETF 标准等条件筛选候选库，最终选用 sans-I/O 的 ngtcp2 并复用 GnuTLS。核心工作包括用单 actor 驱动协议状态机、把 QUIC 流适配为 connected_socket、实现用户态连接路由，并调和 QUIC 与 Seastar 两套流控。作者对比一对一适配与 QUIC-Aware 两种 RPC 方案，在无损回环与丢包场景给出延迟、吞吐基准：无损时 QUIC 有固定每调用开销，5% 丢包时 QUIC-Aware 保留约 76% 吞吐并反超 TCP。该实现仍是单机单分片、合成负载下的受控成果，尚未成为生产级传输。
推荐收录：文章完整展示了从协议选型、适配层设计到 RPC 改造与丢包基准的工程闭环，包含候选库对比、约束取舍和可复现的性能数据，而非泛泛介绍。适合从事网络协议、数据库内核或高性能异步框架的工程师，其 sans-I/O 状态机桥接与流控协调方法可迁移到类似系统。需注意结论基于单机单分片合成负载，尚未在生产环境验证。
工程实践ScyllaDB Engineering
本文记录 ScyllaDB 驱动团队自研 Rust 与 C# 异步 FFI 框架的过程，目标是在 C# 驱动之上复用 Rust 驱动。作者认为现有 uniffi-rs、csbindgen 等绑定生成器缺少异步互操作支持，故选择基于 C ABI 手工实现。文章详述双向调用：C# 调用 Rust 用 P/Invoke，Rust 回调 C# 用 UnmanagedCallersOnly 和静态委托；异步场景通过 TaskCompletionSource 与 Task Control Block 桥接 tokio 和 .NET 运行时，并说明 RunContinuationsAsynchronously 对避免 tokio 线程饥饿的关键作用。数据传递使用 FFISlice、FFIString、FFIBool 等布局兼容类型，规避 bool 表示不一致问题；内存管理分别采用 SafeHandle、GCHandle 和栈固定。该方案针对特定驱动场景，性能评测另文发布，本文贡献主要在异步运行时桥接和跨语言内存安全的工程经验。
推荐收录，因为文章不是泛泛的互操作教程，而是真实项目中的设计取舍与踩坑记录，包含 P/Invoke、反向 P/Invoke、异步运行时桥接、跨语言内存管理的具体实现和边界。对需要做 Rust/C# 集成、语言绑定或异步运行时协作的工程师很有借鉴价值，其中的 GCHandle 用法、tokio 饥饿规避、栈固定等技巧可迁移到类似场景；但它是为数据库驱动定制的框架，不是通用库，读者需结合自身约束评估。
工程实践ScyllaDB Engineering
文章介绍了为 ScyllaDB 的 DynamoDB 兼容 API（Alternator）构建新 Rust 驱动程序的工程实践。由于 AWS DynamoDB SDK 面向单端点托管服务，无法利用 ScyllaDB 多节点多分片的分布式架构，团队基于 aws-sdk-dynamodb 封装了新的 alternator-client-rust，通过 Interceptor 机制注入拓扑感知的负载均衡、头部剥离和请求压缩等优化，保持 API 兼容并实现了约 58% 的吞吐量提升。文章还详述了扩展 Latte 基准测试工具支持 DynamoDB API 的过程，采用条件编译隔离 CQL 与 Alternator 逻辑，并通过 Rune 脚本提供灵活的工作负载描述。基准测试对比了 Latte 与 YCSB 的差异，以及新驱动在不同负载均衡策略下的表现，指出在热分区和轻量事务场景下 key affinity 策略优于 round-robin。文章基于特定 ScyllaDB 版本和测试环境，结果适用于使用 ScyllaDB Alternator 的高吞吐场景，但对其他数据库或云服务的可迁移性有限。
推荐收录，因为它展示了从适配现有 SDK、定位吞吐瓶颈到实现负载均衡与压缩优化并完成基准验证的完整工程链路，提供了可量化的性能数据和具体的架构取舍。对从事数据库驱动开发、分布式系统客户端优化或基准测试工具设计的读者，文中的拓扑感知路由、拦截器使用和条件编译改造方法具有直接迁移价值；同时需注意其结论依赖 ScyllaDB 特定架构。