开发者学堂课程【分布式文件存储系统技术及实现：小概率事件对分布式系统的挑战 】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/368/detail/4374
小概率事件对分布式系统的挑战
内容介绍
一、大规模分布式储存的挑战
二、发生的小概率事件有哪些
一、大规模分布式存储的挑战
1.单机（桌面）系统
小概率出错
首先来看一下单机系统，也就是常说的桌面系统，它很少出现宕机这样的问题
2.大规模存储
小概率事件成为常态
大规模存储常出现单机问题
3.小概率事件发生理论
比如说有 5000 台机器的时候，每个机器如果有十个磁盘，这样的话就是5万个磁盘，在分布式程序系统下，如果每个机器都要用的话都会发生这样的磁盘错误，机器宕机以及另外的一些小概率事件会发生。
二、会发生的小概率事件有哪些：
1.磁盘错误
如果一台机器有五六个磁盘，磁盘年损失率 5% 左右的话，很少会出现磁盘错误，这样就可以看出这个系统运行十分稳定，但是如果把这个数量扩张到成千上万台的时候会发现磁盘量太大了，这个时候遇到的磁盘错误也会变多，同时在机器日宕机率 1%% 的情况下，即 5000 台机器，两天就会遇到一次机器宕机。在处理这些问题的时候，会在 clime 端会做一些智能的分析，发现慢节点就自动规避，发现机器宕机自动绕过，这样用户就感觉不到后面的小概率事件发生。
2.Raid 卡故障
发生在机群里面的高可用节点
主要在存储系统里面放 Meta
它是一个单点，为了提高他的性能而增加了一种设备，在 Cache 的 Raid 卡，它的性能也是非常高的。数据在写入这种设备的时候，它的延迟一般在100-200 us 这个级别，如果有这样的设备存在的话，数据是先写在这样的设备上，然后在后台写入到存储上。
如果这样的设备的电池在充电中保证不了它的安全性，就得穿透这个 Raid 卡直接写到磁盘上去。这样设备的性能就直接降到 20 毫秒左右，这个时候要绕过这样的情况。例如以前对外服务，这个时候可以把它作为一个重接点，让它只接受一些日式同步。
3.网络故障
网络架构如上图所示，在机房内会放四五十台机器，然后它连接的这台交换机再连接到顶层交换机的树形结构，这样的组织方式比较节约成本。但是也有一种错误的架构方式与这种布局相关，例如如果有一部分的交换机线断了，这样其他机器就不联通了，如果要保证他能稳定运行又得把一些关键的节点分布到不同的交换机下，这样的话，在一个交换机出现问题的时候还可以保证服务对外提供，另外在数据分布的时候也要考虑到这个架构，比如把不同的数据在第一次写入的时候，就要放在不同的交换机上，这样一个交换机出现问题，还能保证另外几个交换机上没有问题。
4.电源故障
断电有以下两种情况：
（1）机房供电故障：
在一个机房里面，会把一个机器分为几个 rap ，每个 rap 分多路供电，它有一个电源模块，这个模块是极易出现问题的，，如果一个机架出现问题，那么它以下的机器都会被降低掉。
（2）机房断电：
比如夏天到了，这个地方的机器供电不太足，就会要求机房里的空调都关掉，机房里的机器又接受不了这个热度，这个时候整个机房就要断电。这个时候就要保证所需要用到的数据都保存在数据化存储里面，这样才不会丢失。如果数据丢失了，将如何去修复这也是接下来要学习的问题。
5.数据错误
这个错误一般出现在以下这些地方
（1）磁盘
（2）网络
（3）内存（内存主要会出现在以下两个地方）
①硬件（最常见的有 ECC 错误）
②软件
另外还有如果程序 C＋里面指认出错误，就会导致内存出错。
6.系统异常
Linux 系统相对稳定，但是在其系统里面一些机制会导致一些问题，由于各个机器有自己的时间计时，这样就会导致每个机器会有自己的一套时间，如果要保证每个机器的时间看起来是一样的，就得提供一个 NTP server ，接着就是定期去 NTP server 对一下时间，这样在对时间的过程中就会发现三台机器改变的时间都会有所不同，比如说从 1s 跳到 2s 或者从 2s 跳回 1s，这样再做分布式系统的时候就不会依赖于这样的时钟，否则在回调的时候出现减法出现负数。另外可能出现 0，这样会导致进程崩溃。
7.热点
分为三个用户，一个用户使用了内存资源，另一个用户使用 CPU 资源，另外的用户使用磁盘资源，如果每个用户把自己的资源用的特别满的话，都会导致系统出现异常，最坏的一种情况是这三个用户都被调用到同一台机器，它把资源全都用满，这个机器就接近了宕机状态。其中热点是可以进行迁移的。
8.软件缺陷
下面讲一下软件缺陷对于这个系统的影响，软件是人设计的人总有一些场景是想不到的，在过程中如果不把这个系统作为一个分布式系统去设计的话，很容易出问题，比如：如果一个进程出现了失败，这时候的处置方式是换一个文件去写。以下是在分布式里面就非常糟糕的一种情况，在分布式中换一个文件的话就会增加一份 Meta ，如果说每台机器的程序都在这样干的话，Meta 量就会猛增，另外一个不太好的设计方法也是 retry 的时候也千万文件，这时候如果说一台机器只有它有问题，然后不断地 retry ，不断地在切换文件，则 Meta Server 就迅速积累，这时候导致内存溢出，停止服务，这样是不太好的设计方法。
下面来看另一种设计的缺陷，比如在 data server 重启的过程中要重新汇报数据，但这个汇报是特别耗时的，它是一个比较大的 request ，可能同时一个 meta server ，只能接受 5~6 个这样的请求，如果说这时候机群里边有一个宕机了，这时候所有机器都一起去汇报的话，此时的 Meta server 就无法对外服务了。
再说下一种软件缺陷，比如一个用户拿分布式文件系统当成本地文件系统去操作的话，这时候会频繁的请求文件 Meta 。由于这一个用户，他可能请求量非常大，把 server 的队列都塞满，这样请求量较小的用户就会被看作是拒绝服务。
9.误操作
比如一个目录非常大，这时候要把数据清理，但是在清理的过程中，如果为一个自动化的处理过程的话，靠人去运维很容易造成误删数据。另外如果运维同时发现某个目录需要清理了，这时候再输入删除这个操作的过程中，可能在命令之间把大小写字符敲错，或者说在命令中多加了一个空格，都会导致数据被误删。这是一个非常严重的误操作，这个也是要杜绝的。这时应该在软件层面把一些关键的不允许删除的目录做成一个永远不可删除状态。
