2022年10月15日，达坦科技和Rust语言中文社区单干，在Rust唠嗑室流动中，由达坦科技（DatenLord）联结创始人施继成做了对于开源分布式存储技术的分享，着重介绍了达坦科技新的开源我的项目Xline，这一跨云的metadata(元数据)KV存储的产品是如何实现高性能跨数据中心的数据一致性治理的。

内容介绍

施继成首先介绍了做Xline这个产品的动机。最后2021年UCBerkeley 提出了Sky Computing（“天空计算”）的概念。与咱们都熟知的cloud computing（“云计算”）不同的是，sky computing，如其外表意义所讲，是天空中有很多的云，是解决跨云的问题。如何突破不同云之间的隔膜，或者买通和最大化利用跨云数据是以后面临的一个难题，也是咱们的指标所在。现在议论云计算时，咱们不须要思考云资源的部署，可扩展性等问题，因为云厂商曾经都帮忙做了。然而，一旦跨云，则无论算力的迁徙，或数据的迁徙，都是摆在咱们眼前要攻克的难题。达坦科技在做的就是解决“如何做跨云数据交互”的问题，咱们致力于将分布式系统从数据中心范畴扩散至寰球范畴，这样即便单个数据中心宕机，却仍不影响用户应用数据。

跨云存储最重要的是解决共识一致性的问题。随着业务量的增长，server数量也从最早的一个增长到了起初的多个。尽管能够使算力离开，让申请不会集中在一个server上，但同时也带来了挑战，即不同server间如何保证数据一致性，以及在多数server宕机时先前的决定还可能保留。不会呈现“公说公有理、婆说婆有理”的场面，而是始终保留统一后果，且确保高可用性，这是共识算法想要达成的目标。

随即，施继成引入了Raft和Paxos算法的概念，简略介绍了二者的倒退以及操作过程。它们的思路和传递的message大同小异，然而后者没有一个确定的leader。就传递多少message而言，没有很大差别，两者均会通过两个Round Trip Time（2RRT）才实现一个共识协定的request。

在寰球数据中心间的提早问题重大的状况下，multi-raft解决方案应运而生，其不在协定上做深究，仅做数据切片。这种状况下尽管看似欠缺，然而依然存在问题。例如，如果某数据中心区域因为某些起因不available，那么运行在该数据中心的raft group就无奈响应申请，其对应的数据也就不可取得了。那是不是把该数据备份在不同的数据中心能够解决该问题呢？能够解决问题。然而正如后面提到的实现一次申请须要消耗2RRT。若搁置于不同的数据中心，Latency则太大。所以，咱们不经要问“是不是肯定要有2RRT”？

这个问题促使大家从新扫视Raft协定。须要回顾咱们领有两个RRT的起因到底是什么？一个是确定request在log中的地位，即全局程序，另一个是散发request给followers以确保数据不被失落。后者RRT作为共识算法的能力是无奈被放弃，因而，咱们就着手从前者进行欠缺。 就全局程序的起因，不得不提到MVCC的概念。MVCC要求系统维护物理或者逻辑上的时钟，而全局程序的version就是某种程度上的逻辑时钟，刚好共识协定的log id就能够被当作是version。此时问题看似并没有失去解决，但如果假如没有contention，那也就不须要version的爱护。论文“Exploiting Commutativity For Practical Fast Replication”凑巧讲的就是这个原理，即CURP协定。CURP的劣势在于一方面在无抵触的状况下，一个RRT就能够实现申请，另一方面，在有抵触的状况下，能够进化成后端协定，即Raft或者Paxos等，最终保障没有申请都能够具备全局的version。

咱们的产品：Xline

基于CURP这套协定，达坦科技开发了咱们的产品Xline，它是兼容etcd接口的metadata存储接口。施继成最初提出，咱们最终的心愿是在跨云部署的状况下能够代替etcd获得更好的性能，同时可能将CURP协定剥离进去，后续能够被其他人复用。当初Xline我的项目依然处在晚期状态，曾经领有了几个接口并且做了根本的测试。然而接口方面还有待欠缺，以及后续稳定性方面还须要迭代。咱们手动搭建了一个容器环境模拟跨云场景，手动减少网络链接的提早，当Client和Leader在一起时，Xline提早性方面的优越还无奈体现，但当Client和Leader不在一个数据中心时，Xline的劣势就相当显著，这一测试后果也合乎最后咱们对原理的阐述。

Xline我的项目是以Rust语言写就，欢送大家参加咱们开源我的项目，GitHub链接： https://github.com/datenlord/... 

欲观看此次Rust唠嗑室-Xline：跨数据中心一致性治理，请点击以下B站链接：
https://www.bilibili.com/vide...