大规模分布式系统概览(持续更新中)

发布于: 2020 年 05 月 27 日

1、概述

1.1 分布式计算

hadoop、storm、spark、fink、dataflow/beam

1.2 分布式一致性

paxos/zookeeper、raft/etcd

1.3 CAP理论

分布式系统的CAP理论:http://blog.sina.com.cn/s/blog_ed5cd9aa0102wgp2.html

CAP理论,被戏称为[帽子理论]。CAP理论由Eric Brewer在ACM研讨会上提出,而后CAP被奉为分布式领域的重要理论。首先把分布式系统中的三个特性进行了如下归纳:

  • 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

  • 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

  • 分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

高可用、数据一致性是很多系统设计的目标,但是分区又是不可避免的事情。我们来看一看分别拥有CA、CP和AP的情况。

  • CA without P:如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但其实分区不是你想不想的问题,而是始终会存在,因此CA的系统更多的是允许分区后各子系统依然保持CA。from:http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

  • CP without A:如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。 

  • AP wihtout C:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

超越CAP?——Nathan Marz:How to beat the CAP theorem(Lambda 架构)|原文链接:http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

2011年11月Twitter的首席工程师Nathan Marz写了一篇文章,描述了他是如何试图打败CAP定理的: How to beat the CAP theorem,作者表示不是要“击败”CAP,而是尝试对数据存储系统进行重新设计,以可控的复杂度来实现CAP。Marz认为一个分布式系统面临CAP难题的两大问题就是数据增量算法和数据的可变状态,Marz提出了2个基本思路:

1、数据不存在update,只存在append操作。这样就把对数据的处理由CRUD变为CR;同样的,delete操作也可以处理为add一条新记录(CRUD是指Create Read Update Delete);

2、所有的数据的操作就只剩下Create和Read。把Read作为一个Query来处理,而一个Query就是一个对整个数据集执行一个函数操作。

CAP 定理仍然适用, 但是通常的那些因为 CAP 定理带来的问题,都可以通过不可改变的数据和从原始数据中计算查询来规避 (using immutable data and computing queries from scratch),所谓打败CAP, 就是在保证可用性的情况下, 还能保证一致性。这里的关键在于数据是不可变的。不可变数据意味着这里没有更新操作,所以不可能出现数据复制不同这种不一致的情况,也意味着不需要版本化的数据、矢量时钟或者读取修复。之前的复杂度主要来自增量更新操作和 CAP 定理之间的矛盾,在最终一致性系统中可变的值需要通过读取修复来保证最终一致性。通过使用不可变数据,去掉增量更新,使用不可变数据,每次从原始数据计算查询,你可以规避那些复杂的问题,CAP 定理就被打败了。

批处理层+实时层、CAP 定理和人为错误容忍性

  • 批量处理:数据以文件形式存储到 HDFS中去,新增数据时,只需要在包括所有数据的文件夹中新增一个包含这条新记录的文件即可,HDFS 存储数据满足了“能够很容易存储大的、不断增长的数据集”这个要求。预计算数据集上的查询也很直观,MapReduce 是一个足够复杂的框架,使得几乎所有的函数都可以按照多个 MapReduce 任务这种方式实现。最后,为了可以快速访问这些预计算查询结果,你需要对查询结果进行索引,有许多数据库可以完成这个工作,这些数据库支持批量写和随机读,同时不支持随机写,随机写使得数据库变得复杂,所以通过不支持随机写,这些数据库设计得特别简洁,简洁使得这些数据库鲁棒性变得非常好。

  • 实时层:为了处理最近几个小时的数据,需要一个实时系统和批处理系统同时运行。这个实时系统在最近几个小时数据上预计算查询函数。要计算一个查询函数,需要查询批处理视图和实时视图,并把它们合并起来以得到最终的数据。

  • 错误容忍:由于实时层只处理最近几小时的数据,所有实时层的计算都会被最终批处理层重新计算。所以如果犯了什么错误或者实时层出了问题,最终都会被批处理层更正过来,所有复杂的问题都是暂时的

2、分布式计算

3、分布式协调

paxos/zookeeper、raft/etcd

4、分布式缓存

一致性hash:https://www.jianshu.com/p/735a3d4789fc

5、分布式消息队列中间件

kafka、RabbitMQ、ActiveMQ、RocketMQ

6、分布式文件系统

gfs

hdfs

nfs

7、分布式调度

mesos

yarn

8、集群系统监控

CDH-CMS, Metrics, Grafana、Ambari

9、总结

10、参考资料

发布于: 2020 年 05 月 27 日 阅读数: 14
用户头像

BlueblueWings

关注

About 13 billion years 2018.12.10 加入

About 13 billion years

评论

发布
暂无评论
大规模分布式系统概览(持续更新中)