linux文件删除原理

1 了解负载均衡

负载均衡是分布式系统架构设计中必须考虑的因素之一，它通常是指将请求/数据"均匀"分摊到多个操作单元上执行，负载均衡的关键在于"均匀"。

常见的互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层，可以看到每一个下游都有多个上游调用，只需要做到每个上游都均匀访问每一个下游，就能实现将请求/数据均匀分摊到多个操作单元上执行。

客户端层 ==> 反向代理层的负载均衡

客户端层到反向代理层的负载均衡，是通过DNS轮询实现：DNS server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS server，会轮询返回这些ip，保证每个ip的解析概率相同，这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

反向代理层 ==> 站点层的负载均衡

反向代理层到站点层的负载均衡，是通过nginx实现的，通过修改nginx.conf，可以实现多种负载均衡策略：
(1) 请求轮询：和DNS轮询类似，请求依次路由到各个web server；
(2) 最少连接路由：哪个web server的连接少，路由到那个web server；
(3) ip哈希：按照访问用户的ip哈希值来路由web server，只要用户的ip分布是均匀的，请求理论上也是均匀的，ip哈希均衡方法可以做到，同一个用户的请求固定落到同一台web server上，此策略适合有状态服务，例如session(58沈剑备注：可以这么做，但强烈不建议这么做，站点层无状态是分布式架构设计的基本原则之一，session最好放到数据层存储)。
(4) ...

站点层 ==> 服务层的负载均衡

站点层到服务层的负载均衡是通过"服务连接池"实现的，上游连接池会建立下游服务多个连接，每次请求会"随机"选取连接来访问下游服务。

数据层的负载均衡
在数据量很大的情况下，由于数据层(db，cache)涉及数据的水平切分，所以数据层的负载均衡会复杂一些，它分为"数据的均衡"和"请求的均衡"。
数据的均衡是指：水平切分后的每个服务(db，cache)，数据量是差不多的；
请求的均衡是指：水平切分后的每个服务(db，cache)，请求量是差不多的；
业务常见的水平切分方式有如下几种：
(1) 按照range水平切分

每个数据服务，存储一定范围的数据，上图为例：
user0服务，存储uid范围1-1kw；
user1服务，存储uid范围1kw-2kw；
此方案的好处是：
a. 规则简单，service只需要判断下uid范围就能路由到对应的存储服务；
b. 数据均衡性较好；
c. 比较容易扩展，可以随时加一个uid[2kw, 3kw]的数据服务；
不足之处：
a. 请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range服务请求压力会更大；

(2) 按照id哈希水平切分

每个数据服务，存储某个key值hash后的部分数据，上图为例：
user0服务，存储偶数uid数据；
user1服务，存储奇数uid数据；
此方案的好处是：
a. 规则简单，service只需要对uid进行hash能路由到对应的存储服务；
b. 数据均衡性较好；
c. 请求均匀性较好；
不足之处：
a. 不容易扩展，扩展一个数据服务，hash方法改变的时候，可能需要进行数据迁移；

2 总结

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据"均匀"分摊到多个操作单元上执行，负载均衡的关键在于"均匀"：
(1) 客户端层到反向代理层的负载均衡，是通过DNS轮询实现的；
(2) 反向代理层到站点层的负载均衡，是通过nginx实现的；
(3) 站点层到服务层的负载均衡，是通过服务连接池实现的；
(4) 数据层的负载均衡，要考虑"数据的均衡"与"请求的均衡"，常见的方式有"按照范围水平切分"与"hash水平切分"；

3 lvs为和不能完全替代DNS轮询？

对于接入层负载均衡技术，部分同学持这样的观点：
(1) nginx前端加入lvs和keepalived可以替代DNS轮询；
(2) F5能搞定接入层高可用，扩展性，负载均衡，可以提点DNS轮询；
DNS轮询是否可以被其他方案替代？接入层架构技术演进，是本文将要细致讨论的内容。

3.1 问题

nginx、lvs、keepalived、f5、DNS轮询，每当提到这些技术，往往讨论的是接入层的几个问题：
(1) 可用性：任何一台机器挂了，服务受不受影响；
(2) 扩展性：能否通过增加机器，扩充系统的性能；
(3) 反向代理 + 负载均衡：请求是否均匀分摊到后盾的操作单元执行；

3.2 名词解释

(1) nginx：一个高性能的web server和实时反向代理的软件；
(2) lvs：使用集群技术，实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器；
(3) keepalived：一款用来检测服务状态存活性的软件，常用来做高可用；
(4) f5：一个高性能、高可用、负载均衡的硬件设备；
(5) DNS轮询：通过在DNS server上对一个域名配置多个ip解析，来扩充web server性能及实施负载均衡的技术；

3.3 接入层技术演进

3.3.1 裸奔时代之单机架构

裸奔时代的架构图如上：
(1) 浏览器通过DNS server，域名解析到IP；
(2) 浏览器通过IP访问web server；

缺点
(1) 非高可用，web server挂了整个系统就挂了；
(2) 扩展性差，当吞吐量达到web server上限时，无法扩容；
注：单机不涉及负载均衡问题；

3.3.2 简易扩容方案之DNS轮询

假设tomcat的吞吐量为1000次每秒，当系统总吞吐量达到3000时，如何扩容是首先要解决的问题，DNS轮询是一个很容易想到的方案：

此时的架构图如上：
(1) 多部署几份web server，1个tomcat抗1000，部署3个就能抗3000；
(2) 在DNS server层面，域名每次解析到不同的ip；

优点
(1) 零成本，在DNS server上多配置几个ip即可，功能也不收费；
(2) 部署简单，多部署几个web server即可，原系统架构不需要做任何改造；
(3) 负载均衡，变成了多机，但负载基本均衡；

缺点
(1) 非高可用：DNS server只负责域名解析ip，这个ip对应的服务是否可用，DNS server是不保证的，假设有一个web server挂了，部分服务会受到影响；
(2) 扩容非实时：DNS解析有一个生效周期；
(3) 暴露了太多的外网ip；

3.3.3 简易扩容方案之nginx

tomcat性能较差，但nginx作为反向代理的性能就强多了，假设线上跑到1w，就比tomcat高了10倍，可以利用这个特性来做扩容：

此时的架构图如上：
(1) 站点层与浏览器层之间加入了一个反向代理层，利用高性能的nginx来做反向代理；
(2) nginx将http请求分发给后端多个web server；

优点
(1) DNS server不需要改动；
(2) 负载均衡：通过nginx来保证；
(3) 只暴露一个外网ip：nginx到tomcat之间使用内网访问；
(4) 扩容实时：nginx内部可控，随时增加web server随时实时扩容；
(5) 能够保证站点层的可用性：任何一台tomcat挂了，nginx可以将流量迁移到其他tomcat；

缺点
(1) 时延增加，架构复杂了：中间多加了一个反向代理层；
(2) 反向代理层成了单点，非高可用：tomcat挂了不影响服务，nginx挂了怎么办？

3.3.4 高可用方案之keepalived

为了解决高可用问题，keepalived出场了：

此时：
(1) 做两台nginx组成一个集群，分别部署上keepalived，设置为相同的虚ip，保证nginx高可用；
(2) 当一台nginx挂了，keepalived能够探测到，并将流量自动迁移到另一台nginx上，整个过程对调用方透明；

优点
(1) 解决了高可用问题；

缺点
(1) 资源利用率只有50%；
(2) nginx仍然是接入单点，如果接入吞吐量超过nginx的性能怎么办？例如QPS达到了5W？

3.3.5 scale up扩容方案之lvs/f5

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出上限，还是抗不住；

lvs就不一样了，它实施在操作系统层面；f5的性能就更好了，它实施在硬件层面，他们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容，常见的架构图如下：

此时：
(1) 与通过nginx可以扩展多个tomcat一样，可以通过lvs来扩展多个nginx；
(2) 通过keepalived + VIP的方案可以保证高可用；
99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。

这就完美了吗？
不管是lvs还是f5，这些都是scale up方案，根本上lvs/f5还是会有性能上限，假设每秒能处理10w的请求，一天也只能处理80亿的请求(10w秒吞吐量*8w秒)，那万一系统的日PV超过80亿怎么办呢？（好吧，没几个公司要考虑这个问题）

3.3.6 scale out扩容方案之DNS轮询

如前所述，水平扩展才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。
facebook，google，baidu的日PV是不是超过80亿？ 它们的域名只对应一个ip？ 终点又是起点，还是得通过DNS轮询来进行扩容：

此时：
(1) 通过DNS轮询来线性扩展入口lvs层的性能；
(2) 通过keepalived来保证高可用；
(3) 通过lvs来扩展多个nginx；
(4) 通过nginx来做负载均衡，业务七层路由；

3.4 结论

(1) 接入层架构要考虑的问题域为：高可用、扩展性、反向代理+扩展均衡；
(2) nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题；
(3) 水平扩展scale out是解决扩展性问题的根本方案，DNS轮询是不能完全被nginx/lvs/f5所替代；

4 如何实施异构服务器的负载均衡以及过载保护？

后端service有可能部署在硬件条件不同的服务器上：
(1) 如果对标最低配的服务器"均匀"分摊负载，高配的服务器的利用率不足；
(2) 如果对标最高配的服务器"均匀"分摊负载，低配的服务器可能会扛不住；
能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护，是这里要讨论的问题。

4.1 service层的负载均衡通常是怎么做的？

service层的负载均衡，一般是通过service连接池来实现的，调用方连接池会建立与下游服务多个连接，每次请求"随机"获取连接，来保证service访问的均衡性；负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。这个调用方连接池能否实现，根据service的处理能力，动态+自适应的进行负载调度呢？

4.2 通过静态权重标识service的处理能力

调用方通过连接池组件访问下游service，通常采用"随机"的方式返回连接，以保证下游service访问的均衡性。要打破这个随机性，最容易想到的方法，只要为每个下游service设置一个权重，代表service的处理能力，来调整访问到每个service的概率，例如：
假设service-ip1，service-ip2，service-ip3的处理能力相同，可以设置weight1=1，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是1/3，1/3，1/3，能够保证均衡访问。
假设service-ip1的处理能力是service-ip2，service-ip3的处理能力的2倍，可以设置weight1=2，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是2/4，1/4，1/4，能够保证处理能力强的service分别到等比的流量，不至于资源浪费。

使用nginx做反向代理与负载均衡，就有类似的机制。

这个方案的优点是：简单，能够快速的实现异构服务器的负载均衡。
缺点也很明显：这个权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

4.3 通过动态权重标识service的处理能力

提问：通过什么来标识一个service的处理能力呢？
回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计
(1) 用一个动态权重来标识每个service的处理能力，默认初始处理能力相同，即分配给每个service的概率相等；
(2) 每当service成功处理一个请求，认为service处理能力足够，权重动态+1；
(3) 每当service超时处理一个请求，认为service处理能力可能要跟不上了，权重动态-10(权重下降会更快)；
(4) 为了方便权重的处理，可以把权重的范围限定为[0, 100]，把权重的初始值设为60分；

举例说明：
假设service-ip1，service-ip2，service-ip3的动态权重初始值weight1=weight2=weight3=60，刚开始时，请求分配给这3台service的概率分别是60/180，60/180，60/180，即负载是均衡的。

随着时间的推移，处理能力强的service成功处理的请求越来越多，处理能力弱的service偶尔有超时，随着动态权重的增减，权重可能变化成了weight1=100，weight2=60，weight3=40，那么此时，请求分配给这3台service的概率分别是100/200，60/200，40/200，即处理能力强的service会被分配到更多的流量。

4.4 过载保护

提问：什么是过载保护？

图示：无过载保护的负载与处理能力图(会掉底)

回答：互联网软件架构设计中所指的过载保护，是指当系统负载超过一个service的处理能力时，如果service不进行自我保护，可能导致对外呈现处理能力为0，且不能自动恢复的现象；而service的过载保护，是指即使系统负载超过一个service的处理能力，service仍能保证对外提供有损的稳定服务。

图示：有过载保护的负载与处理能力图(不会掉底)

提问：如何进行过载保护？
回答：最简易的方式，服务端设定一个负载阈值，超过这个阈值的请求压过来，全部抛弃，这个方式不是特别优雅。

4.5 如何借助动态权重来过载保护？

动态权重是用来标识每个service的处理能力的一个值，它是RPC-client客户端连接池层面的一个东西，服务端处理超时，客户端RPC-client连接池能够知道，这里只要实施一些策略，就能够对疑似过载的服务器进行降压，而不用服务器抛弃请求这么粗暴的实施过载保护。

应该实施一些什么样的策略呢？例如：

(1) 如果某一个service的连接上，连续3个请求都超时，即连续-10分三次，客户端就可以认为，服务器慢慢的要处理不过来了，得给这个service缓一小口气，于是设定策略：接下来的若干时间内，例如1秒(或者接下来的若干个请求)，请求不再分配给这个service；
(2) 如果某一个service的动态权重，降为了0(连续10个请求超时，中间休息了3次还超时)，客户端就可以认为，服务器完全处理不过来了，得给这个service喘一大口气，于是设定策略：接下来的若干时间内，例如1分钟(为什么是1分钟？根据经验，此时service一般在发生fullGC，差不多1分钟能恢复过来)，请求不再分配给这个service；
(3) 可以有更复杂的保护策略…

这样的话，不但能借助动态权重来实施动态自适应的异构服务器负载均衡，还能在客户端层面更优雅的实施过载保护，在某个下游service快要响应不过来的时候，给其恢复的机会。需要注意的是：要防止客户端的过载保护引起service的雪崩，如果整体负载已经超过了service集群的处理能力，怎么转移请求也是处理不过来的，还得通过抛弃请求来实施自我保护。

4.6 总结

(1) service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的；
(2) 异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整；
(3) 动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动；
(4) 过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法；
(5) 动态权重法，还可以用做service的过载保护；

5 集群信息管理，架构设计中最容易遗漏的一环

5.1 集群概念

互联网典型的分层架构如下：

web server层；
service层；
db层与cache层；
为了保证高可用，每一个站点、服务、数据库、缓存都会冗余多个实例，组成一个分布式的系统，集群则是一个分布式的物理形态，通俗的说，集群就是一堆机器，上面部署了提供相似功能的站点，服务，数据库，或者缓存。

web集群，由web.1和web.2两个实例组成；
service集群，由service.1/service.2/service.3三个实例组成；
db集群，由mysql-M/mysql-S1/mysql-S2三个实例组成；
cache集群，由cache-M/cache-S两个实例组成；

与集群相对应的是单机。
画外音：关于高可用架构，详见文章<究竟啥才是互联网架构高可用>。
画外音：缓存如果没有高可用要求，可能是单机架构，而不是集群。

5.2 集群信息

什么是集群信息？
一个集群，会包含若干信息，例如：

集群名称
IP列表，建议使用内网域名，而不是直接使用IP
二进制目录
配置目录
日志目录
负责人列表

什么时候会用到集群信息？

很多场景，特别是线上操作，都会使用到各种集群信息，例如：

自动化上线
监控
日志清理
二进制与配置的备份
下游的调用

这些场景，分别都是如何读取集群信息的？

一般来说，早期会把集群信息写在配置文件里；
例如，自动化上线，有一个配置文件deploy.user.service.config，其内容是：

name : user.service
ip.list : ip1, ip2, ip3
bin.path : /user.service/bin/
ftp.path : ftp://192.168.0.1/USER_2_0_1_3/user.exe

自动化上线的过程则是：
把可执行文件从ftp拉下来；
读取集群IP列表；
读取二进制应该部署的目录；
把二进制部署到线上；
逐台重启；

画外音：还没有实现自动化脚本部署？还处在运维ssh到线上，手动执行命令，逐台机器人功部署的刀耕火种阶段？赶紧照着这个方案，做自动化改造吧。

又例如，web-X调用下游的user服务，又有一个配置文件web-X.config，其内容配置了：

service.name : user.service
service.ip.list : ip1, ip2, ip3
service.port : 8080

web-X调用user服务的过程则是：
web-X启动；
web-X读取user服务集群的IP列表与端口；
web-X初始化user服务连接池；
web-X拿取user服务的连接，通过RPC接口调用user服务；

日志清理，服务监控，二进制备份的过程，也都与上述类似。

5.3 存在什么问题？

上述业务场景，对于集群信息的使用，有两个最大的特点：
每个应用场景，所需集群信息都不一样(A场景需要集群abc信息，B场景需要集群def信息)；
每个应用场景，集群信息都写在"自己"的配置文件里；

一句话总结：集群信息管理分散化

这里最大的问题，是耦合，当集群的信息发生变化的时候，有非常多的配置需要修改：

deploy.user.service.config
clean.log.user.service.config
backup.bin.user.service.config
monitor.config
web-X.config
…

这些配置里，user服务集群的信息都需要修改：
随着研发、测试、运维人员的流动，很多配置放在哪里，逐步就被遗忘了；
随着时间的推移，一些配置就被改漏了；
逐渐的，莫名其妙的问题出现了；

如何解决上述耦合的问题呢？
一句话回答：集群信息管理集中化

5.4 如何集中化管理集群信息？

早期方案

通过全局配置文件，实现集群信息集中管理，举例global.config如下：

[user.service]
ip.list : ip1, ip2, ip3
port : 8080
bin.path : /user.service/bin/
log.path : /user.service/log/
conf.path : /user.service/conf/
ftp.path :ftp://192.168.0.1/USER_2_0_1_3/user.exe
owner.list : shenjian, zhangsan, lisi

[passport.web]
ip.list : ip11, ip22, ip33
port : 80
bin.path : /passport.web/bin/
log.path : /passport.web/log/
conf.path : /passport.web/conf/
ftp.path :ftp://192.168.0.1/PST_1_2_3_4/passport.jar
owner.list : shenjian, zui, shuaiqi

集中维护集群信息之后：
任何需要读取集群信息的场景，都从global.config里读取；
任何集群信息的修改，只需要修改global.config一处；
global.config会部署到任何一台线上机器，维护和管理也很方便；
当然信息太多的话，global.config也要垂直拆分。

中期方案
随着公司业务的发展、技术团队的扩充和技术体系的完善，通过集群信息管理服务，来维护集群信息的诉求越来越强烈，配置越多，通过global.config来修改配置越容易出错。

如上图，建立集群信息管理服务：
info.db ：存储集群信息；
info.cache ：缓存集群信息；
info.service ：提供集群信息访问的RPC接口，以及HTTP接口；
info.web ：集群信息维护后台；

服务的核心接口是：
Info InfoService::getInfo(String ClusterName);
Bool InfoService::setInfo(String ClusterName, String key, String value);

然后，统一通过服务来获取与修改集群信息：
所有需要获取集群信息的场景，都通过info.service提供的接口来读取集群信息；
所有需要修改集群信息的场景，都通过info.web来操作；

长期方案
集群信息服务可以解决大部分的耦合问题，但仍然有一个不足：集群信息变更时，无法反向实时通知关注方，集群信息发生了改变，更长远的，要引入配置中心来解决。

配置中心的细节，网上的分析很多，这里暂不展开。

5.5 总结

集群信息管理，是架构设计中非常容易遗漏的一环，但又是非常基础，非常重要的基础设施，一定要在早期规划好：

• 传统的方式，分散化管理集群信息，容易导致耦合；
• 集中管理集群信息，有全局配置，信息服务，配置中心三个阶段；

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至yj.mapple@gmail.com