第1章 分布式系统概述

• 淘宝的管理海量小文件的分布式存储系统TFS
• 阿里巴巴开源的分布式调用框架Dubbo（读音[ˈdʌbəʊ]）
• 阿里巴巴开源的数据库中间件Cobar
• 为了存储大量的网站索引，谷歌设计了GFS分布式文件存储系统和基于列存储的Bigtable NoSQL数据库系统
• 为了计算PageRank算法中的页面Rank值，谷歌又设计了MapReduce（ [mæp] [rɪˈdjuːs]）分布式计算系统
• 为了方便分布式系统中不同主机间的协调，谷歌又设计了Chubby ( [ˈtʃʌbi] 圆胖的;丰满的) 分布式锁系统
• 为了解决不同语言实现的组件间的通信问题，Facebook设计了Thrift( [θrɪft]储蓄机构)
• 为了解决大量消息的快速传递问题，领英设计了Kafka([ˈkɑfkə] )

1.1 分布式系统的组成

• 前端web、PC端、手机端
• 后端：大都是基于Linux的集群
• 集群管理系统：分布式协调组件
• 存储系统
• 计算系统
• 中间件
  • 支持分库分表的数据库访问中间件
  • 用来异步化的消息中间件
  • 用来开发不同组件的分布式系统调用中间件
  • 用来监控各个组件状态的分布式跟踪中间件

1.2 分布式协调组件

本质：分布式环境中的进程间通信机制
分布式协调组件对外提供的是一种分布式同步服务。为了获得健壮性，一个协调组件内部也是由多个结点组成的，结点之间通过一些分布式一致性协议（Paxos帕克索斯、Raft[ræft] ）来协调彼此的状态。如果一个结点崩溃了，其他结点就自动接管过来，继续对外提供服务，好像什么都没有发生过一样。

1.3 分布式存储系统

与单击系统类似，分布式系统的存储也分为两个层次：

• 第一个层是文件级，即分布式文件系统。如： GFS（Google File System）、HDFS（Hadoop Distributed File System）、TFS（Taobao File System）
• 第二个层次是在文件系统之上的进一步抽象，即数据库系统。

分布式系统下的数据库采用的大都是最终一致性（最终一致性即在“有穷”时间内，各个节点上的数据最终会收敛到一致的状态，当然这里的“有穷”经常是指很短暂的时间，几分或几秒就算比较长了），而非满足ACID属性的强一致性

CAP理论：在分布式系统里，没有办法同时达到一致性、可用性和网络分区可容忍性，只能在三者中择其二。

1.4 分布式计算系统

1.4.1 批处理分布式计算系统

MapReduce框架？？？？？？？

1.4.2 流处理分布式计算系统

• 微批处理系统：Apache Spark[spɑːrk]
• 真正的流处理系统：Apache Storm、Apache Samza、Kafka Streams

1.4.3 混合系统

电商的智能推荐系统，其既需要批处理的功能（为了确保响应速度，预先将大量的计算通过批处理系统完成），也需要流处理的功能（根据用户的最新行为，对推荐系统进行实时调整）

• Lamda（拉姆达）架构思想：用一个批处理系统（如MapReduce）来进行批处理计算，再用一个实时处理系统（如Apache Spark/Storm）来进行实时计算，最后用一个合并系统将二者的计算结果结合起来并生成最终结果
• “Questioning the Lamda Architecture”论文中提及Lamda架构的缺点即处理逻辑需要在批处理系统和流处理系统中实现两遍。利用Kafka可以保存历史消息的特性，作为批处理系统和流处理系统的共享资源来处理（生产者与消费者关系）

1.5 分布式系统中节点之间的关系

• 主从式（Master-slave）关系：GFS、Bigtable、HDFS、HBase、淘宝TFS、京东JFS、百度BFS、百度Tera
• 对等式（peer-to-peer）关系：亚马逊的Dynamo