开发者学堂课程【分布式文件存储系统技术及实现：分布式系统功能设计--读取流程 】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/368/detail/4378
分布式系统功能设计--读取流程
内容介绍
一、正常读取流程
二、异常读取流程
三、如何解决慢节点？
四、总结
一、正常读取流程
首先 client 端从 master 端获得数据位置，比如现在获得的位置是CS1、CS2、CS3 ，然后 client 端任选一个 CS 去读取，client 端选取的是 CS1，如果 client 端可以从 CS1 正确读取数据，那么此次读操作就算完成。可以看出读对于写，相对简单了许多。
二、异常读取流程
Client 端第一选取的位置是 CS1 ，如果 CS1 出现了问题，那么读操作就会返回失败，client 端收到读失败后会再选取一个正常节点比如 CS2，发起读请求，然后 CS2 读取数据之后这时读流程才算完成。
三、如何解决慢节点？
1.BackupRead
client 端在发起读请求时，不只发给同一个点，client 端会发起多个点。在下图可以看到，它向 CS1、CS2 都发起请求，此时它会等其中一个返回，读操作就会成功。但是为了防止这种方式引起大量的 IO 请求，会发一个 ack 请求到 CS1，结束CS1 还没有进行的一些操作。在这可以看到发起多个请求，可以把慢节点完全规避掉。但在平均延迟都增大的情况下，会出现问题。比如两个节点都进行了 IO，但返回的数据只有一份，这是个非常大的浪费。
2.读流程优化-规避慢节点
1) 首先 master 返回给 client 端位置时，会给它一张列表，告知每个节点大概返回的时间是多长，这是基于位置考虑的。比如说这个节点从 client 进程分布在同一台机器，就可以断定它在 15ms 左右就可以返回。
2) 但如果CS节点从 client 进程分布在同一个 Rack ，可以大概估算出返回时间在 18ms 左右，如果分布在不同的 Rack 可能要 30ms ，这时候 client 端会选取一个期望返回时间比较短的位置去读。比如 CS1 期望返回是 15ms ，他的第一个请求就会发给 CS1 。但等了一段时间后并没有发现 CS1 返回，这时它才发给第二个可能快的节点，果然 CS3 很快返回，这时候返回的时间还少于 18ms ，这时 client 端先停掉 CS1 的L请求然后将 CS3 的实际返回请求更新。
3) 在下次选取时发现 CS3 是读取速度最快的，然后这时把请求发给 CS3，有效的发现了集群中最快的节点，之后的读操作都发给它，隔段时间统计再进行一次，所以在 client 端这种只能处理方法，可以有效规避慢节点，对集群中的热点做到动态规避。
四、总结
1. 多个副本分布方式：
2. 可读取任意有效副本
3. 副本出现异常时尝试其他副本
4. Backup Read 可减少读取延迟、但会引起更多的 L 请求，所以根据局部性原理选最优副本访问，既绕过了慢节点又达到了最小的 L 请求量。
