1.开篇
学习分布式系统，不是学习如何让计算机变得更强大，而是学习如何在一群不可靠、不听话、还互相撒谎的机器之间，勉强构建出可靠服务的幻觉。你所熟知的一切编程直觉——比如‘调用函数就会返回’、‘内存里的数据就是对的’、‘机器挂了程序就停了’——在这里都会把你坑得血本无归。本篇将带你初窥三个核心挑战：性能（如何与光速和延迟共舞）、容错（如何与无处不在的失败共存）、以及MapReduce（如何优雅地‘分而治之’并忍受其中的混乱代价）
第一篇我们不会进行很难很难的知识点讲解，只讲明白两点和一个概念
- 性能
- 容错性
- MapRedcue
1.性能
在我们日常使用中大部分都是在个人计算机上进行娱乐/开发 …
那么当我们工作中需要一个性能非常非常大的场景(抢购，热播剧开播，春节 …)，这时候我们需要很多很多的计算机来进行合作计算，让我们的系统性能更高，我们在意的问题有很多，比如
网络延迟、数据一致性、调度开销
- 网络延迟 在两个不同地区使用网络进行交互会遇见的第一个就是会有毫秒级别的网络延迟，在我们现在看起来非常非常小，但是分布式集群是非常非常庞大的，在全部进行交互后我们差不多就花费了秒级别的时间
- 数据一致性 在一个集群中客户端A发送数据后直接关机了，导致后续发给其他机器的数据没有发送，在读取数据的时候需要校验数据是否一致，如果不一致进行集群协商，如果是计数器那种我们进行更深入的方案设计(后面进行深入讲解)
- 调度开销 在进行数据协同性调度的时候我们不仅仅要考虑网络，还要考虑每个机器性能是不一定的，有的很快有的很慢
2.容错性
在分布式系统中我们会有数以千计的计算机，我们肯定不会将这些放在一个机房里面，那么分布式毫无意义，如果机房着火那么服务全部宕机，你也不用干了
这时候业界通常会讲这些系统放在不同城市，国家甚至是不同的洲，亚洲服务器，美洲服务器等等，在这些计算机内肯定会有某台计算机出现以外(风扇线断了过热死机,机房断电了 …)这时候我们的服务是不能停止的
这时候我们的系统是需要移除这些错误的节点而不让整个系统挂掉，不过当错误到相当大的程度后我们就的系统必须选择停止一切服务(在现在我们选择这个方案)，避免以后数据混乱，系统内部修复困难
MapReduce
把一个超大任务拆分成数个微小任务然后去实现并发执行
子任务执行结束后再将结果汇总到总任务上
这也分为三个阶段
- Map
- Shuffle
- Reduce
例如，我们需要分析1000个网页文档，统计所有单词出现的总频率。
1.Map
对文本进行分词，并为每个单词生成一个 (word, 1) 的键值对
文本： “hello world hello”
Map 输出：
("hello", 1)
("world", 1)
("hello", 1)然后把总体数据进行平均分布到每一台机器上面进行任务执行
2.Shuffle
框架会自动收集所有Map任务输出的中间键值对，根据键（单词）进行哈希分区和排序，确保所有相同的键都会被路由到同一个Reduce任务。这个过程涉及大量的网络I/O和磁盘I/O，是系统最关键的协调环节
3.Reduce
每个Reduce任务接收到分配给它的、某一组键的所有中间值（例如，键”hello”对应的 [1,1,1,…]）。它遍历这些值，执行用户定义的聚合函数（此处为求和），最终将结果（例如，(“hello”, 158)）写入到最终的输出文件中。 更重要的是：如果某个Reduce任务失败，框架会自动在另一个节点上重新启动它。开发者无需关心这些细节
总结
以上内容就是MIT 6.824第一篇的简单总结