前言
本系列是源于「码农翻身」所属知识星球发起的读书活动，由大佬 @我的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 （系统的绝大部分基础设施是分布式的）
为什么需要分布式系统
- to increase capacity via parallelism （通过并行增加系统性能）
- to tolerate faults via replication （通过复制备份增加系统容错）
- to place computing physically close to external entities （可以将计算放在离外部实体更近的地方）
- to achieve security via isolation （可以通过隔离增加系统的安全）
分布式的难点
- 需要额外注意并发编程，对开发人员的能力要求直线上升
- 系统内的相互作用非常复杂
- 意想不到的错误：局部错误
- 预期性能和实际性能往往不符
此处展示一张单体应用和分布式应用的对比图，图片出自：《极客时间 · 左耳听风》
分布式系统的解决方案
宏观目标
我们需要设计一系列能够屏蔽分布式系统复杂性的抽象
研究角度
- 实现方式。
- RPC 远程调用，线程和并发控制
- 性能：
- 通常我们想要提供一个性能可以扩展的系统。
- 可以通过简单增加系统的电脑数量来增强并行能力，从而部分扩展系统的性能：
- 当没有复杂交互的时候这么做很有效
- 可以不用请昂贵的程序员来重新设计系统。
- 简单增加系统内电脑数量并不能一直增加系统性能：
- 当电脑数量变得很多的时候，负载不均，系统内每台电脑性能不均，无法并行执行的代码，初始化的交互都会降低系统的性能。
- 来自共享资源的访问也会造成性能瓶颈，比如网络通讯或者数据库等
- 同时性能也并不能总是靠增加系统内电脑数量达成：
- 比如来自单一用户请求的快速响应时间
- 比如所有用户都想要更新同一个数据。
- 通常这些情况需要更好的程序设计而不是更多的电脑。
- 容错：
- 大量的服务器 + 大型的系统通常代表着总有错误会发生
- 我们需要向应用程序隐藏这些错误
- 我们通常想要让系统拥有可用性和可恢复性
- 可用性：即使错误发生了，系统还是可以继续运行
- 可恢复性：当错误被修复之后，系统可以恢复运行
- 通常可以用备用的服务器来增加容错
- 一致性：
- 通常想要达成正确工作的系统十分困难：
- 服务器和它的备份服务器之间很难保持一致，代价太高
- 客户端可能会在中途出错。
- 服务器可能会在处理之后回复之前崩溃
- 不佳的网络可能会使得正常的服务器无法提供服务
- 一致性和性能通常是矛盾的：
- 高一致性需要各种基础设置之间大量的通信
- 许多设计为了提升性能被迫只提供弱一致性
- 通常想要达成正确工作的系统十分困难：
持续脑图
文件分享地址：https://www.processon.com/view/link/5f1db0230791291b99680fa0
下一章内容
接下来的一章，我们将进行 <6.824> 中的 Lab 1，即实现一个简单的MapReduce系统，该系统将采用 Go 语言构建
Go 语言是近些年非常热门的语言之一，其价值个人感觉大于被炒的火热的 Python
本章要求
- 了解分布式系统的由来及面临的挑战
- 了解<6.824>课程中涉及的分布式系统解决方案
- 搭建 Go 语言环境，写出 HelloWorld 即可（语法层面及 MR 实现将在下章学习）
最后
相关资源：
如果觉得对你有用的话，不要忘记点个赞啊~ 也可以扫描二维码关注我，一起朝着技术人的顶峰前进！