qq_34673038的博客

6.824 讲座14：参数服务器案例研究使用参数服务器扩展分布式机器学习Li，Andersen，Park，Smola，Ahmed，Josifovski，Long，Shekita，SuOSDI 2014如今：分布式机器学习案例研究：参数服务器我们为什么要阅读这篇论文？有影响力的设计宽松的一致性不同类型的计算机器学习入门模型是函数逼近器真正的函数是未知的，所以我们从数据中学到一个近似值例如：-f（用户个人资料）->广告点击的可能性-f（图片）->图片可能包含一只猫-f（

6.824 讲座13：Naiad案例研究Naiad：及时的数据流系统默里，麦克谢里，以撒，艾萨德，巴勒姆，阿巴迪SOSP 2013如今：流和增量计算案例研究：Naiad我们为什么要读《 Naiad》？优雅的设计令人印象深刻的表现开源且仍在开发中总结：Spark提高了迭代计算的性能即，一次又一次使用相同数据的数据但是如果输入数据发生变化怎么办？可能会发生，例如因为搜寻器更新页面（新链接）或因为应用程序将新记录追加到日志文件实际上，Spark（如上一课的论文一样）必须重新开始！即

6.824 讲座12：Spark案例研究弹性分布式数据集：内存群集计算的容错抽象Zaharia，Chowdhury，Das，Dave，Ma，McCauley，Franklin，Shenker，StoicaNSDI 2012如今：更多分布式计算案例研究：Spark我们为什么要阅读Spark？广泛用于数据中心计算受欢迎的开源项目，热启动（Databricks）比MapReduce更好地支持迭代应用程序有趣的容错故事ACM博士论文奖MapReduce使程序员的生活变得轻松它处理：节点之

6.824 讲座10：FaRM我们为什么要阅读这篇论文？很多人想要分布式交易但他们被认为是缓慢的本文提出的建议不一定非要如此-非常令人惊讶的表现！大业绩图每秒9000万个复制 持久 事务（图7）每台机器每秒100万笔交易每个都有一些消息，用于复制和提交非常令人印象深刻其他一些系统则每台机器每秒获得100万次操作，例如memcached但不是事务+复制+持久性（通常这些都不是！）9000万的观点：每秒10,000条推文每秒2,000,000封电子邮件他们如何获得高性能？数据必须

6.824 讲座10：分布式事物主题：分布式事务=并发控制+原子提交有什么问题？很多数据记录，分片在多个服务器上，很多客户端[图：客户端，服务器，按密钥分片的数据]客户端应用程序操作通常涉及多次读取和写入银行转帐：借方和贷方对文章进行投票：检查是否已投票，记录投票，增加计数在社交图中安装双向链接我们想向应用程序编写者隐藏交错和失败这是传统的数据库问题当今的资料源自[分布式]数据库但是这些想法被用于许多分布式系统示例情况x和y是银行结余-数据库表中的记录x和y在不同的服务器上（

6.824 讲座8：Zookeeper案例研究阅读：“ ZooKeeper：互联网级系统的无等待协调”，Patrick亨特，马哈德夫·科纳尔，弗拉维奥·P·琼奎拉，本杰明·里德。2010年会议论文集USENIX年度技术会议。我们为什么要阅读这篇论文？广泛使用的复制状态机服务受Chubby（Google的全局锁定服务）启发最初在Yahoo !，现在也在外部（Mesos，HBase等）开源的作为Apache项目（http://zookeeper.apache.org/）给Paxos / ZA

lecture 7：木筏（3）-快照，线性化，重复检测本讲座：木筏快照线性度重复的RPC更快得到***筏日志压缩和快照（实验3B）问题：日志将变得巨大-比状态机状态大得多！重新启动或发送到新服务器将花费很长时间幸运的是：服务器不需要既完整的日志又服务状态在状态中捕获日志的执行部分客户只看到状态，而不是日志服务状态通常要小得多，所以让我们保持服务器不能丢弃哪些条目？未执行的条目-尚未反映在状态中未提交的条目-可能是领导者多数的一部分解决方案：服务定期创建持久的“快照”[图

6.824 讲座6：raft（2）回顾：键/值服务为例，如实验3所示目标：多机看起来和单机一样目标：尽管有少量故障/断开服务器，但仍可用 高可用提防网络分裂和裂脑！[图：客户，k / v层，k / v表，筏层，筏日志][客户端RPC-> Start（）->多数提交协议-> applyCh]“状态机”，应用程序，服务一些提醒：领导者在多数回复AppendEntries之后提交/执行领导者告诉对执行者的提交，执行（==在applyCh上发送）为什么只等待大多数？为什么不

6.824 2017讲座5：筏（1）我们为什么要阅读这篇论文？分布式共识是人们数十年来一直努力解决的难题实验2和3基于Raft这个讲座今天：筏选和日志处理（实验2A，2B）下一页：筏持久性，客户端行为，快照（实验2C，实验3）总体主题：使用复制状态机（RSM）的容错服务[客户端，副本服务器]示例：配置服务器，例如MapReduce或GFS主服务器示例：键/值存储服务器，put（）/ get（）（lab3）目标：对于用户来说看起来和单机一样但尽管有一些故障服务器也可用（高可用）战略：

主备复制主题容错的主从复制VMware FT的案例研究 这个主意的实现版本容错我们想要一个一个服务出现错误也能继续运行一些理想的模型高可用：尽管一些错误，但是仍然能用强一致性：看起来就像单机服务client透明server 软件透明有效率我们需要处理哪些错误？崩溃独立的失败网络丢包网络分区但不包括执行不正确不相关的错误配置错误恶意代码行为可用 (如服务器崩溃)等待(网络错误)永远停止(多个服务器崩溃)故障(软硬件错误，软件故障)

GFSThe Google File System为什么读这个paper文件系统使用mr6.824的主题在论文中体现简单且表现良好的交易一致性为之后的设计提供了思路优秀的系统论文-app的细节，包或网络性能，错误容忍，一致性影响很多文件系统使用GFS ()GFS (e.g., Bigtable, Spanner @ Google) HDFS (Hadoop Distributed File System) based on GFS什么是一致

基础架构：RPC和线程最常见的问题：为啥用Go?6.824使用c++很多年c++工作良好但是学生花费很多时间追踪指针和alloc/free错误，而且缺乏满意的c++rpc包go对我们来说更好并行更好的支持rpc更好的支持gc垃圾收集类型安全线程安全的gc是很有吸引力的go编程是愉快的相对简单且传统Threads线程是有用的架构工具Go叫他们协程，其他编程语言叫他们线程非常tricky为啥要threads?我们需要并行，这在分布式系统很常见，io并行

Lecture1: 概述分布式系统工程什么是分布式系统？多个共同处理任务的计算机大型网站的存储、MapReduce,P2P共享网络等很多重要的基础设施都是分布式的为什么需要分布式系统物理上使用单独1的实体来组织通过隔离来确保安全通过重复来容忍错误通过并行CPU、内存、次盘、网络来使得产量倍增缺点复杂:很多并行的部分必须处理局部错误实现理论上的性能潜力是非常tricky的为什么上这门课有趣-挑战性的问题，很棒的解决方案应用在现实系统中，分布式系统就是被大型网站兴