暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

聊聊分布式系统之美

分布式系统之美 2020-07-02
2179



我看过很多「xx 之美」的书,譬如数学之美、代码之美、系统之美等等,这些书都从各个角度来阐释了不同事务的美感。自然,对于分布式系统来说,也有很多美的东西值得我们去发现,去欣赏的。




什么是分布式系统?

根据 WIKI 的解释,分布式系统就是该系统的组件分散到不同的机器上面,组件之间通过网络进行连接,传递消息,彼此交互实现一个共同的目标。我们现在几乎已经完全生活在一个分布式系统的世界了,譬如早上我们起来,刷刷知乎,我们就在跟知乎后台非常多的分布式系统,譬如 TiDB,打交道。

提到分布式系统,首先绕不过去的一个定理就是 CAP,这个定理可以算是分布式系统设计的基石吧。CAP 很简单直白,也就是对于一个系统来说,不可能同时满足一致性(C),可用性(A) 以及分区容错性(P)这三点。当然对于分布式系统来说,P是无处不在的,所以我们的系统只能是 CP 或者 AP,不可能是 CAP。

先来说说 AP 系统,因为不用考虑一致性这个特性,所以 AP 系统实现起来相对的比较简单,因为它们将一致性的确定交给了用户自己来处理,典型的可以参考 Amazon 之前的 Dynamo 的 paper。

对于我个人来说,我倾向于将复杂度封装起来,让用户不用太关心如何在外面去维护数据的一致性,所以这里比较喜欢 CP 系统,但因为 CAP 定理,我们会牺牲掉可用性这个特性。但我们也不必要如此悲观,因为在现实世界里面,随着硬件条件的不断完善,多数时候,我们可以构建一个 CP + HA 的系统,虽然没法追求 100% 的 A,但能做到 99.999% (甚至更高)的 HA,对于分布式系统来说,已经非常健壮了。

可以看到,一个简单的 CAP 理论,就已经给我们对于分布式系统的设计提供了指导意见,而这个理论恰恰又是如此的简单和美丽。我个人甚至相信,如果计算机体系不能出现天翻复地的变化(譬如量子计算机的落地),CAP 理论就一直会适用。

如果我们要追求 CP 系统,自然下一个困难的事情在于如何保证数据在多机器上面的一致性,这个业界已经有非常多的一致性算法供我们参考,无论是远古时期的 Paxos 以及相关的变种(实话,你真的很难想象 Lamport 在上世纪 80 年代就能想出来 Paxos ),还是进入 20 世纪备受瞩目的 Raft(相比于 Paxos,Raft 基于 Log replication 加上 state machine 的技术真的非常让人容易理解),还有很多新兴的一致性算法。当然,如果想让你的分布式系统提供一致性保证,一个简单直接的办法,就是让客户端同步写多份,只有都写成功了,才认为写成功。一些知名的系统就是这么做的,譬如 GFS

上面提到的一致性算法,只能适用于一些场景,在实际中,我们可能一次操作,会涉及到多个数据的修改,而这些数据的修改必须要保证要么同时修改成功,要么全部失败,典型的场景就是数据库上面,对于一个数据库来说,无论怎样,都需要提供 ACID 的保证。为了保证 ACID,我们需要在一致性算法的基础上面,更进一步,这个就是分布式事务。当然,业界也有很多分布式事务的实现,但多数都是 2PC 以及其变种,譬如 TiDB 用的 Percolator,还有 OmidSpanner 等,当然还有基于一致性 Log 的,譬如 Calvin

上面我们主要讨论的是数据一致性,对于分布式系统来说,另一个需要关注的就是分布式计算。我们现在数据散落到不同的机器上面,一次计算可能就要从不同的机器上面抓取数据来算了。虽然现在网络带宽是越来越大,但通常计算存储分离架构下,性能还是可以改善下,所以一个比较好的方式就是将计算直接下推到对应的存储节点进行,算完之后在返回给计算节点。对于更加复杂的计算,譬如数据库的 join,可能一台计算节点并不能很好的满足性能需求,这时候就可能需要 Massively Parallel Processing(MPP) 的帮助,可以了解下 ImpalaGreenplum。另外,现在大家对于实时性的要求越来越高,所以流式计算也是一个非常火的研究方向,譬如 Flink。无论怎样,追求更快的计算速度一直是分布式研发工程师追求的目标。

这里再来聊聊分布式的调度。调度的作用就是在于将要执行的任务编排好,使其能高效的执行,任务的编排我个人认为是一个 NP 问题吧,所以我们只能找到一个比较好的解。现在最流行的云上操作系统 Kubernetes,就是一个很不错的调度系统,它会依据多个维度来将任务调度到不同的机器上面执行。当然不光 K8s,还有 MesosYarn 等调度框架,很多分布式系统为了更好的性能,也会自己写相关的调度框架,譬如 TiDB 里面的 Placement Driver。

再来聊聊分布式系统的测试。要保证分布式系统按照我们预期的方式运行,其实是一件非常非常困难的事情,因为我们完全不知道系统什么时候就会出现什么错误。而人类恰恰对于未知是极度恐慌的。对于系统测试来说,除了常用的 fuzzing,fail ingjection 这些,混沌工程现在也是一个不错的研究方向,譬如 Chaos Mesh®️,当然有时候为了验证自己的分布式算法的正确,我们也会使用 TLA+ 来证明。

上面只是列举了分布式系统的一些领域,实际还有非常多的东西本文并没有涉及,譬如分布式查询优化器,AI 等。说了这么多,那么到底我们要干啥呢?

我们决定开一个「分布式系统之美」的知乎专栏及公众号,在这个知乎专栏/公众号里面,我们会将多年对于分布式系统美的探索详细的记录下来,包括对架构的研究、对算法的论证、对工程的落地等等。另外,也期待你的加入,只要你觉得它们有美感,觉得很厉害,都欢迎给我们投稿。

最后,让我们一起将「分布式系统」的美感,展示给世界吧。




投稿方式:

我们通过【知乎专栏“分布式系统之美”】接收投稿请求,专栏编辑组将在后台进行审稿,通过后将第一时间发布在知乎专栏上~

欢迎大家点击【阅读原文】关注我们的知乎专栏,更希望志趣相同的小伙伴们加入我们,一起创作、分享!




😈 上文划线部分均有跳转,由于微信外链限制,大家可以点击【阅读原文】进入知乎专栏查看原文。


文章转载自分布式系统之美,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论