相关协议
应用层协议结构
洋葱式结构，一层包一层。
相关协议
IP (Internet Protocol)
实现方式：使用IPv4地址，唯一标识一台联网的机器，基于路由转发。
IP包结构：头，数据
特点：无连接，无序，不保证可靠
TCP (Transmission Control Protocol)
实现方式：在IP基础上实现
增加的端口号Port：不同的进程通信。
特点：有连接，有序，可靠，建立连接成本高
UDP (User Datagram Protocol)
实现方式：在IP基础上实现
增加的端口号Port：不同的进程通信。
特点：进行数据校验，其他与IP相同，不需要建立连接，速度快。应用程序自己检查是否收到，是否按照顺序。
DNS (Domain Name Service)
TCP端口：53
作用：进行域名解析
全球有根域名服务，各国各自管理自己的域名分配
HTTP (Hyper Text Transfer Protocol)
TCP端口：80
进程和线程
进程
创建：通过fork创建
特点：虚拟内存私有，打开文件私有
线程
创建：pthread
特点：虚拟内存共享，打开文件共享，一个进程可以由很多线程
协程
比线程更小，从操作系统的角度看不见，操作系统仍然认为其是一个线程
进程间通信方式
共享内存
在单机，要并发控制，一方修改另一方立马可以看到。
消息传递
可单机也可多机，多台机器间传递如socket通信，pipe等。
消息传递基本格式
请求：功能+参数
功能：功能的ID或者功能名，如HTTP GET, HTTP PUT
参数：输入数据，如编码(Encoding)，序列化(Serialization)
回答：结果+结果数据
结果：结果ID或者结果名
结果数据：也需要编码和串行化
分布式系统
分布式系统类型
客户端/服务器模型
客户端发送请求，服务器完成操作，发回响应。
P2P模型
没有中心控制节点，节点之间对等。
主从模型
有一个/一组节点为主，进行中心控制协调。其它多个节点为workers，完成具体工作
故障类型
Fail stop
出现故障，进程崩溃
Fail slow
出现故障，运行速度变得很慢，如挖矿病毒
Byzantine failure
恶意攻击
CAP定理
数据一致性（Consistency），可用性（Availability），分区容错（Partition tolerance），三者不可兼得。
系统设计理念
简单往往是最好的，怎么简单怎么来。
分布式文件系统
NFS（Sun’s Network File System）
起源
Sun公司1985发布了NFSv2，定义了开放的client/server之间的通信协议标准。
系统架构
特点
-
-
- 从不同的终端都可以访问同一个目录
- 多用户共享数据
- 集中管理
-
设计目标
-
-
- 简单快速的恢复
- 远程文件操作性能高
-
保存状态的问题
客户端打开文件时，若文件内部的位置信息保存在NFS服务器中，在发生中断时，读或写的指针位置没有恢复，启动后再写可能面临灾难性后果。
解决方案——无状态
NFS服务器中不保存任何状态。客户端负责主要控制信息，服务器只负责读和写，不保存任何状态。
打开文件
客户端发送一个请求文件命令，服务器返回一个文件标识符，客户端使用此文件标识符对文件进行操作。
读取文件
客户端发送文件标识符，缓冲区，长度，服务器端读取文件后返回数据和文件属性。客户端更新文件记录
写入文件
客户端发送文件标识符，缓冲区，长度，服务器端写入文件后返回文件属性。客户端更新文件记录。
好处：只用重启，什么额外操作都不用
解决方案——Idempotent（幂等性）
在没有其他操作前提下，重复多次结果不变
好处：如果一个请求没有响应，那么就不断重试。
缓存一致性问题
A读取了文件File（version_0.1）放入缓存，B读了文件File（version_0.1）然后在缓存中写，文件变成了File（version_0.2），但是文件并没有更新到文件系统。就会产生问题：
-
-
-
- A并不知道B更新了文件，A的缓存的文件是过时的。
- C无法读取到B的本地缓存文件，无法读取到最新文件。
-
-
解决方案——Flush_on_close_consistency（关闭时更新）
在文件关闭时，自动把缓存中的已经修改的文件数据，写会NFS服务器。
此方法只能解决问题2，可以保证C读取到最新的文件。但是问题1依然无法解决。
（用前检查）为了解决此弊端，规定在每次使用缓存之前，必须检查是否过时，可以解决问题1，但是会带额外的性能开销（即使只有一个用户的时候，都会带来大量的确认更新请求开销）。
AFS (Andrew File System)
设计目标
可伸缩性，使得一个服务器尽可能多的支持客户端。
解决polling状态问题——Invalidation
客户获得一个文件就要在服务器上登记（登记制度）
当服务器发现文件被修改，就向登记了的客户发送一个消息，客户就会删除缓存文件并更新。
AFS VS NFS
缓存单位
NFS以数据页为单位缓存，AFS以整个文件为单位缓存。
缓存位置
AFS缓存放在硬盘（所以AFS通常可以缓存大文件。），NFS缓存在内存中。
权限
AFS管理权限比NFS更加详细。
GFS/HDFS
GFS(Google File System)是Google MapReduce系统的基础。
HDFS(Hadoop Distributed File System)是GFS的开源实现，基于Java，是应用层文件系统，与Hadoop捆绑在一起。
应为属于应用层，必须链接到HDFS client库才能使用。
GFS设计目标
大块数据顺序读。
并行追加。
不支持对已有文件的修改操作。（只追加）
HDFS/GFS系统架构
Name Node：存储文件的元数据。
Data Node：存储数据块。
文件切分成定长数据块
每个数据块独立分布在Data Node上
默认每个数据块存储3份，在3个不同的Data Node上。
支持并发读，不支持并发写。
HDFS/GFS打开文件操作
“打开文件请求”发送给Name Node。
Name Node 返回元数据。
需要与Name Node通信一次。
HDFS/GFS读文件操作
得到了元数据，之后的读操作直接绕过Name Data，直接访问Data Node。
可以从多个副本中选择最佳的Data Node读取数据。
支持很多并发的读请求。
HDFS/GFS写文件操作
写文件是写新创建的文件，不是修改已有的文件。
Name Node决定写在哪个Data Node上。
形成一个数据传递通道，流水线传递方式，最大限度利用网络带宽。
数据传递过程：Primary -> Secondary -> Data Node。
但是此时还没有写进HDFS。此时只是在内存中缓存数据。
Primary给各个节点发送写指令，各个节点返回结果。此时才真正把数据从内存写到HDFS中。
不支持并发写的原因
因为一个写的操作要写3个Data Node。若两个写同时进行，A写Node1，Node2，Node3，选的是Node1为primary，但如果B选了Node2为primary，那么A先写或者B先写，都会有一个的数据的备份被破坏。
并发Append
文件最后一个数据块在同一个primary data node。
相当于单机事务，可以在单机上完成并发控制。
保证append成功，但不保证append顺序。
标签：Node,文件,缓存,HDFS,存储系统,数据,客户端 From： https://www.cnblogs.com/RedNoseBo/p/17240663.html