DatenLord的博客

现有的分布式KV存储大多采用Raft共识协议，需要两次RTT才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。但是，当跨数据中心部署时，节点之间的延迟可能是几十或几百毫秒，此时 Raft 协议将成为性能瓶颈。Curp 协议就是为了解决这个问题而设计的。它可以在命令不冲突的情况下减少一个RTT，从而提高性能。因此，[Feature]CURP WAL (Write-Ahead-Log) 实现：我们设计了一个 Write-Ahead-Log 来保存 curp 的日志条目。

为了更全面地向大家介绍Xline的进展，同时促进Xline社区的发展，我们将于召开。

在 Xline 的 CURP 系统中，本文深入探讨了 RIFL作为基础设施，为 RPC 提供 Exactly-Once 语义的实现及相关问题的解决方案。本文讲解了Xline中重构后命令执行流程的新设计，以及我们是如何优化Xline的性能的。Xline的建设需要每一位对此感兴趣且愿意付出的你们的参与，我们期待你们的加入。为了更全面地向大家介绍Xline的进展，同时促进Xline社区的发展，我们将于。

这个WAL的实现非常简单，整个存储使用多个WAL文件，log的追加的实现就是单个文件的追加，这样所有的log追加操作都是文件的顺序写入，效率很高，并且不存在写放大的现象。更致命的是，tokio的async模型使用的是一个小的固定线程池作为workers，由于Xline中使用的是同步锁，一旦一个worker线程持有这个锁的时间过长，那么就会导致其余的worker线程都进入休眠状态，这些worker线程不仅无法更新这个数据结构，它们也无法执行其他任务，形成了一个锁车队。这样就导致文件写入的高延迟现象。

在上一篇文章中，我们从 command 去重机制的契机开始，介绍了去重的必要性以及目前 Xline 的去重机制存在的一些问题，同时讲解了 RIFL(Reusable Infrastructure for Linearizability) 的工作原理，并对其进行了一些性能分析。本文将在此基础上进一步更深讲解。

首先，用户需要先在 karmada 上定义好相应的资源来描述跨集群的 Xline 集群的集群拓扑。目前，由于 Karmada 社区对于新的 workload 的实现细节还没有达成共识，因此，在早期的尝试阶段，Xline 采用了两层的 Operator 方式，通过 Karmada Xline Operator 对顶层资源进行解释和拆分，并下发至 member cluster，再由 member cluster 上的 Xline Operator 来对资源进行调谐。这两种模式分别对应了应用的无状态和有状态。

本篇文章我们深入探讨了在分布式系统中如何进行集群成员变更，简单介绍了两种主要的解决方案：Joint Consensus 和单步成员变更，Joint Consensus 通过引入中间状态来保证变更期间不会出现两个 Leader，单步集群变更则是牺牲了一定的功能，通过逐个变更节点来简化实现逻辑。并且对 Xline 目前使用的单步成员变更方案进行了源码级的分析，展示了 Leader 和 Follower 都是如何处理变更的，以及引入集群变更之后，会有哪些新逻辑需要处理。

是一项全球性的在线计划，致力于将新的contributor引入开源软件开发领域。GSoC 参与者在导师的指导下，与开源组织合作开展为期 12 周以上的编程项目。您也可以添加小助手微信 DatenLord_Tech，或发邮件至info@datenlord.com 进行咨询。对于报名方式有任何疑问，或者对某一个项目非常感兴趣，并且想要深入了解的同学，欢迎加入。的基础设施服务，以此满足不同行业客户对AI+Cloud 的需求。，积极推动AI应用的落地。1. 您的简历，包括您的过往经历、联系方式等。

在本篇文章中, 我们主要会介绍Jepsen在测试分布式KV存储Xline中的应用。包括对混沌工程框架Jepsen的介绍, 对分布式系统一致性模型的讨论, 以及对有关测试结果的分析。

为了更全面地向大家介绍Xline的进展，同时促进Xline社区的发展，我们将于2024年1月27日北京时间上午10:00召开Xline社区会议。欢迎您届时登陆zoom观看直播

当 Server 收到一个 RPC(client_id, seq_num, first_incomplete) 时，会根据 checkDuplicate 来检查这个 RPC 的状态：1. NEW: 一个新的 RPC，按照正常的逻辑处理请求2. COMPLETED: 一个已经执行完成的 RPC，返回执行完成的记录3. IN_PROGRESS: 一个正在执行的 RPC，返回 IN_PROGRESS 错误4. STALE: 一个已经被 client 确认回收的 RPC，返回 STALE 错误。

但是，当跨数据中心部署时，节点之间的延迟可能是几十或几百毫秒，此时 Raft 协议将成为性能瓶颈。Curp 协议就是为了解决这个问题而设计的。它可以在命令不冲突的情况下减少一个 RTT，从而提高性能。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。Xline 项目以 Rust 语言写就。：如果在添加成员后立即关闭群集，领导节点可能无法正常关闭，会不断尝试向关闭的新节点发送条目。

一旦我们将冲突关系定义为一个有向无环的非连通图中的一条边，那么执行某个命令时所需要计算的冲突顺序问题，就转换成了一个求有向无环图中，该命令所在的连通分量的拓扑排序问题。针对第一个问题，我们可以将所有的命令都看成是一张有向无环图中的顶点，而将冲突关系视为图中顶点之间的有向边。假设命令 A 和命令 B 之间存在冲突（命令的抵达顺序为先 A 后 B），我们便可将冲突关系看成是 A 和 B 之间的一条弧<A, B>，其中弧头总是指向后进来的顶点（这一顺序性就保证了图中不会出现环形冲突）。在这个过程当中，仅凭。

与 fast_round 不同的是，在 slow_round 过程中，命令在执行完毕，并将执行结果保存到 cmd_board 中后，并不会直接返回，而是会将命令重新放回到冲突检测队列中，直到命令执行完 after_sync 操作后，并将对应的结果保存到 cmd_board 中后，才会向 CurpNode 返回，最后向 Client 返回对应的 ProposeResponse。代表的是命令 在 prepare 阶段的执行结果。因为，Xline 的 Curp 模块中，协议的后端采用的是 Raft 协议。

在 Xline 中对 lease 的使用和现实生活中的租车服务很相似，客户端可以向服务点申请一个 lease，服务端会保证在 lease 的有效期内不会删除这个 lease，客户端也可以通过相应的接口提前结束或者延长 lease 的时间，与现实中租车不同的是，我们可以在这个 lease 上绑定一些 key-value，这些 key-value 会随着 lease 的过期被删除。，这个接口会列出系统中所有的 lease id，这个接口不需要 lease 过期时间的信息，因此可以直接交给共识协议处理，所以在。

当操作不同的 Key 时，例如 PUT A=1， PUT B=2，那么对于状态机的最终状态而言，不论是先执行 PUT A=1，再执行 PUT B=2，还是反过来，最终从状态机上读出来的结果都是 A=1，B=2。而 CURP 协议则是对达成共识的场景做了更细粒度的划分，将协议分割成了前端（fast path）和后端（slow path），前端只保证了提案会被持久化到集群当中，而后端不仅保证了持久化，也保证了所有保存了该提案的节点会按照相同的顺序执行命令，保证了状态机的一致性。

但是，当跨数据中心部署时，节点之间的延迟可能是几十或几百毫秒，此时 Raft 协议将成为性能瓶颈。因此，Xline旨在实现高性能的数据访问和跨数据中心场景下的强一致性。目前在GitHub上有些任务并不需要深入了解Curp协议或Xline这个项目，只需要了解API和Rust语言即可。Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。Xline的建设需要每一位对此感兴趣且愿意付出的你们的参与，我们期待你们的加入。

基准测试报告也显示，Xline 在高网络延迟的场景下，针对无冲突的并发 PUT 请求，Xline 在吞吐量接近 etcd 的两倍，而在完全冲突的情况下，Xline 的吞吐量则略低于 etcd。在单数据中心场景下，元数据的管理已经有很多成熟的解决方案，etcd就是其中的佼佼者，但是在多数据中心场景下，etcd的性能受Raft共识协议的限制，它的性能和稳定性都大打折扣。在广域网下的高延迟环境中，一个RTT的运行时间从几十到几百毫秒不等，两个RTT将是两个费时的过程。Xline由此应运而生。

我们可以简单分析一下，在一个充分竞争的市场中，坚持私有协议的提供商需要和其他的类似提供商竞争，还需要和整个天空计算体系竞争，为了保持竞争力，他们需要花更多的资源来创新，以保证自己私有 API 的竞争性。但是相反，处在天空计算内的提供商的边界更加低，不需要花更多的力气去维护所有的领域，只需要专注于自己的比较窄的领域进行创新。没有天空计算的情况下，上述的这些厂商只有两种选择，要么将自己的硬件或者服务部署到某一个（几个）云平台提供商的机房，要么自己搭建一套完整的云计算基础设施。显然这两个都不是最好的选择。

在 Xline 早期的原型阶段，我们采用了基于内存的存储来实现数据的持久化。这虽然简化了 Xline 原型设计的复杂度，提高了项目的开发和迭代速度，但带来的影响也是显著的：由于数据都存储在内存当中，因此一旦当进程 crash 后，节点的数据恢复需要依赖于从其他正常节点上拉取全量数据，这就需要较长的恢复时间。为了方便分析，我们进行相关约定，B+ Tree的block size为B，故每个内部节点包含O(B)个子节点，叶子节点包含O(B)条数据，假设数据集大小为N，则B+ Tree的高度为。

Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储，其旨在实现高性能的数据访问和跨数据中心场景下的强一致性。点击文章了解Xline 
0.4.0新更新。

专注下一代云计算——“天空计算”的基础设施技术，致力于拓宽云计算的边界。达坦科技打造的新一代开源跨云存储平台DatenLord，通过软硬件深度融合的方式打通云云壁垒，实现无限制跨云存储、跨云联通，建立海量异地、异构数据的统一存储访问机制，为云上应用提供高性能安全存储支持。以满足不同行业客户对海量数据跨云、跨数据中心高性能访问的需求。针对多数据中心场景，可以实现数据的高性能跨云、跨数据中心共享访问，并且保证数据的一致性。传统单数据中心解决方案无法满足跨数据中心的场景对性能和一致性的需求。

在这篇文章中，我将首先列出我在编写async Rust代码时的一些痛点。然后，我将指出我们真正需要异步代码的场景，并讨论为什么我们应该把异步和非异步代码分开。最后，我将展示我是如何在最近的一次Curp重构中实践这一原则的。

Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储。现有的分布式KV存储大多采用Raft共识协议，需要两次RTT才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。但是，当跨数据中心部署时，节点之间的延迟可能是几十或几百毫秒，此时 Raft 协议将成为性能瓶颈。Curp 协议就是为了解决这个问题而设计的。它可以在命令不冲突的情况下减少一个RTT，从而提高性能。因此，Xline旨在实现高性能的数据访问和跨数据中心场景下的强一致性。

本文旨在为没有接触过形式化方法的读者提供一种新的视角看待计算机系统与算法，而非形式化方法或 TLA+ 教程。因此本文的重点是如何从数学角度思考程序，不会使用大篇幅讲解 TLA+ 的语法。

Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储。现有的分布式KV存储大多采用Raft共识协议，需要两次RTT才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。

论文原文：Tolerating Slowdowns in Replicated State Machines using Copilots以下内容是对这篇论文的阅读总结，以及部分重要章节（§3 Design、§5 Optimizations）的翻译。