CSE_lecture4:Distributed System

Scalability in Practice: a Highly scalable web app

互联网应用需要支撑的三个能力：

• 处理海量的请求
• 存储海量的数据
• 透明化的可拓展性(transparent scale)

因此我们需要构建一个scalable的系统

case study: an e-commerce web application

一次点击可能需要上千的服务器处理

远古时代使用单个服务器架构：应用层、文件系统、数据库集成在一起，但这也导致了一些问题

问题一：存储容量无法满足要求

step 1 for scalability: disaggregating application & data

使用大公司提供的数据库和文件系统来存储海量数据，当需要存储更多数据时购买额外的服务即可

但是每次访问数据都既要访问磁盘，又要网络请求，因此会非常慢

step 2 avoid the slow data accesses? caching

使用缓存来加速访问数据，这是考虑到大部分访问都是在访问那少部分数据

但问题在于内存很小，只能放下很少的数据，因此使用多台server来存放cache

memcached是一种distributed cache server，它使用key-value来标记，从而找到数据存放在个caching server；同时使用路由(routing)来实现key和ip的映射

使用hash来根据key计算address，公式为 $address = Hash(key);%;#server$，使用consistent hashing来保证增加新的server时miss不会太多

问题二：应用层使用CPU处理，但单个CPU的拓展能力有限，这是由于moore’s law和dennard scaling导致了无法通过提升硬件来解决问题

step 3 for scalability: more app servers

这对于stateless（即没有上下文）的请求效果良好，而对于stateful的请求效果较差（这是因为其他app server没有context），当然也可以使用一些手段来将stateful转换为stateless（比如将context存储在用户端）

为了让多个app server的请求流量比较平均，使用load balance，如round-robin, random, hashing等等，好的balance能够考虑到不同请求的时间长短和各个server的不同处理能力

step 4 for scalability: distributed databases

远古时代使用一个数据库只读，一个数据库只写的方法，但这样无法保证正确性

因此现在使用将数据均匀地分配在不同的机器上，上层使用算法来保证多台机器和单台机器等价，即complex consistency management

step 5 for scalability: distributed file system

经过前五步架构，当一个请求来了之后，先进行load balance来防止排队，从而抵达应用层；数据和文件分布在多台机器上，从而按需拓展；缓存层来加速数据访问。因此一次访问需要经过多台服务器

不同的任务需要不同的scale方法

step 6 for scalability: using CDN

网络服务商上使用CDN来缓存一些数据，在应用层之前就获取到数据，这样离用户更近

step 7 for scalability: separate different applications

使用容器来打包应用，使用k8s来管理多个容器

复杂的请求需要复杂的计算，因此需要使用distributed computing，根据不同的计算场景使用不同的计算框架

因此每一个应用层后面接一个计算框架，从而提供针对性的服务

现在我们构成了一个并行与分布式系统，这是在现代数据中心的支持下实现的，这些数据中心都是有备份的

challenge: fault handling

三种出错方式：

• fault: 可以是潜在的或激活的，可以是软件层面的，也可以是硬件层面的，这是很常见的
• error: 是激活fault的结果
• failure: 发生在错误没有被检测和屏蔽时

总结一下：Fault（缺陷） -> 激活 -> Error（错误） -> 未被检测/屏蔽 -> Failure（失效）

分布式系统的规模实在太大，导致fault频发，然而，即使有少部分遇到failure，对外依然能够正确运行，而partial failure难以侦测

以unreliable network为例，请求未响应的原因很多：

• 远程服务器挂了
• 请求包丢失了
• 请求在队列里排队，导致不能及时响应
• 垃圾回收的耗时导致远程服务器暂停响应
• 响应丢失
• 响应延迟

另一个常见的fault为network partition，即组内能通信，但组与组之间不能，这可能是因为机器或者交换机宕机，也可能是因为物理损坏

而分布式系统需要处理fault来提供always-on的状态

可用性是建立在以极快的速度处理fault的基础上，即提升可靠性

为了达到高可用性，可以使用replications，即冗余，这样只要保证其中之一响应就好，但这样带来了consistency问题；或者使用retry，对于stateless的情况不会有一致性问题，而有些请求会有一致性问题

CAP: Consistency, availability, partition tolerance

无法在网络分区的情况下同时保证一致性和高可用性，需要牺牲其中之一

总而言之，分布式系统需要trade-off以下特性：scalability, performance, fault tolarance, consistency, ease of programming