共计 2387 个字符,预计需要花费 6 分钟才能阅读完成。
前言
本系列是源于 「码农翻身」
所属常识星球发动的读书流动,由大佬 @我的 UDP 不丢包
举荐而来,这次的读书流动有一些另类,咱们摈弃了传统的书籍,开始攻略最高学府的研究生顶级课程 <6.824>,该课程是很多年前的蠕虫病毒发明者Robert Morris
大佬授课,归属于 麻省理工大学
,授课形式次要是:视频 + Lab 试验(Go 语言)+ 论文,全程英语,难度较大。
分布式系统的判断根据
- multiple cooperating computers(多台计算机合作)
- storage for big web sites, MapReduce, peer-to-peer sharing(大规模数据集运算,如:MapReduce,或点对点共享)
- lots of critical infrastructure is distributed(零碎的绝大部分基础设施是分布式的)
MapReduce
:大规模数据集计算零碎,比方计算从 1 加到 1000 亿,能够单台计算机计算,也能够利用该技术扩散到多台计算机计算而后合并后果,极大的提高效率
为什么须要分布式系统
- to increase capacity via parallelism(通过并行减少零碎性能)
- to tolerate faults via replication(通过复制备份减少零碎容错)
- to place computing physically close to external entities(能够将计算放在离内部实体更近的中央)
- to achieve security via isolation(能够通过隔离减少零碎的平安)
容错:
针对于容错,次要是两点,一是可用性,二是可恢复性对于分布式系统来说,个别不会全副服务器同时瘫痪,因而无论是服务可用还是数据安全,都比单体服务更有保障。
分布式的难点
- 须要额定留神并发编程,对开发人员的能力要求直线回升
- 零碎内的相互作用非常复杂
- 意想不到的谬误:部分谬误
- 预期性能和理论性能往往不符
部分谬误
:假如一台机器每天出故障的概率是千分之一,在单体利用中,可能很长时间能够工作,然而在分布式系统中,设施数量急剧回升,每天都可能有设施呈现故障,这就是所谓的部分谬误,很难排查,也简直无奈防止
此处展现一张单体利用和分布式应用的比照图,图片出自:《极客工夫 · 左耳听风》
分布式系统的解决方案
宏观指标
咱们须要设计一系列可能屏蔽分布式系统复杂性的形象
为什么要设立此指标?
因为分布式系统自身已足够简单,因而必须简化应用形式
简化应用形式和形象有什么关系?
我目前认可的最完满形象是:文件
“UNIX 文件实质上就是一大袋字节。”——《UNIX 编程艺术》
在 Unix 中,任何可读 / 写也就是有 I/O 的设施,无论是文件,socket,驱动,在关上设施之后都有一个对应的文件描述符。Unix 将对这些设施的读写简化在 read/write 中,换言之,你只须要把关上的文件描述符传给这两个函数,操作系统内核晓得如何依据这个文件描述符失去具体设施信息,外部暗藏了对各种设施进行读写的细节,所有这些对用户都是通明的,你只须要关上它,失去 fd,再进行相应的操作就够了。
钻研角度
实现形式。
- RPC 近程调用,线程和并发管制
性能:
- 通常咱们想要提供一个性能能够扩大的零碎。
能够通过简略减少零碎的电脑数量来加强并行能力,从而局部扩大零碎的性能:
- 当没有简单交互的时候这么做很无效
- 能够不必请低廉的程序员来从新设计零碎。
简略减少零碎内电脑数量并不能始终减少零碎性能:
- 当电脑数量变得很多的时候,负载不均,零碎内每台电脑性能不均,无奈并行执行的代码,初始化的交互都会升高零碎的性能。
- 来自共享资源的拜访也会造成性能瓶颈,比方网络通讯或者数据库等
同时性能也并不能总是靠减少零碎内电脑数量达成:
- 比方来自繁多用户申请的疾速响应工夫
- 比方所有用户都想要更新同一个数据。
- 通常这些状况须要更好的程序设计而不是更多的电脑。
容错:
- 大量的服务器 + 大型的零碎通常代表着总有谬误会产生
- 咱们须要向应用程序暗藏这些谬误
咱们通常想要让零碎领有可用性和可恢复性
- 可用性:即便谬误产生了,零碎还是能够持续运行
- 可恢复性:当谬误被修复之后,零碎能够复原运行
- 通常能够用备用的服务器来减少容错
一致性:
通常想要达成正确工作的零碎十分困难:
- 服务器和它的备份服务器之间很难保持一致,代价太高
- 客户端可能会在中途出错。
- 服务器可能会在解决之后回复之前解体
- 不佳的网络可能会使得失常的服务器无奈提供服务
一致性和性能通常是矛盾的:
- 高一致性须要各种根底设置之间大量的通信
- 许多设计为了晋升性能被迫只提供弱一致性
一致性
:一致性问题貌似是最难以解决的问题,因为它实质蕴含了性能,容错,数据一致性等等诸多因素咱们前文说过,为了思考容错容灾机制,须要数据进行备份,那么在分布式系统中,A 服务批改了 A 数据库的值,B 数据库的值要不要跟着改,是立刻跟着改,还是提早跟着改,在同步批改中出问题了怎么办,在异步批改中出问题了怎么办
最终业界也很难解决相应的问题,因而当初支流的形式是:
最终一致性
即容许短时间内数据不统一,通过最终一致性保障性能和数据安全的兼顾
继续脑图
文件分享地址:https://www.processon.com/vie…
下一章内容
接下来的一章,咱们将进行 <6.824> 中的 Lab 1,即实现一个简略的 MapReduce
零碎,该零碎将采纳 Go 语言构建
Go 语言是近些年十分热门的语言之一,其价值个人感觉大于被炒的炽热的 Python
本章要求
- 理解分布式系统的由来及面临的挑战
- 理解 <6.824> 课程中波及的分布式系统解决方案
- 搭建 Go 语言环境,写出 HelloWorld 即可(语法层面及 MR 实现将在下章学习)
最初
相干资源:
Go 官网镜像站
Go 语言 IDE
Go 语言环境搭建教程
Go 语言初识 + HelloWorld
MIT 课程表主页
B 站中文翻译视频地址
如果感觉对你有用的话,不要遗记点个赞啊~ 也能够扫描二维码关注我,一起朝着技术人的高峰后退!