一、文件删除原理

Linux是通过link的数量来控制文件删除的,只有当一个文件不存在任何link的时候,这个文件才会被删
除。一般来说,每个文件都有2个link计数器:i_count 和 i_nlink。
(1)i_count的意义是当前文件使用者(或被调用)的数量
(2)i_nlink的意义是介质连接的数量(硬链接的数量)
可以理解为i_count是内存引用计数器,i_nlink是磁盘的引用计数器;
当一个文件被某一个进程引用时,对应i_count数就会增加;当创建文件的硬链接的时候,对应i_nlink数就会增加。

对于删除命令rm而言,实际就是减少磁盘引用计数i_nlink。这里就会有一个问题,如果一个文件正在被某个进程调用,而用户却执行rm操作把文件删除了,那么会出现什么结果呢?

当用户执行rm操作删除文件后,再执行ls或者其他文件管理命令,无法再找到这个文件了,但是调用这个删除的文件的进程却在继续正常执行,依然能够从文件中正确的读取及写入内容。这又是为什么呢?

这是因为rm操作只是将文件的i_nlink减少了,如果没其它的链接i_nlink就为0了;但由于该文件依然被进程引用,因此,此时文件对应的i_count并不为0,所以即使执行rm操作,但系统并没有真正删除这个文件,当只有i_nlink及i_count都为0的时候,这个文件才会真正被删除。也就是说,还需要解除该进程的对该文件的调用才行。

i_nlink及i_count是文件删除的唯一条件,只有同时成立,文件才会被真正的删除,但是当文件没有被调用时,执行了rm操作删除文件后是否还可以找回被删的文件呢?

rm操作只是将文件的i_nlink减少了,或者说置0了,实际就是将文件名到inode的链接删除了,此时,并没有删除文件的实体即(block数据块),如果及时停止机器工作,数据是可以找回的,如果此时继续写入数据,那么新数据就可能会被分配到被删除的数据的block数据块,此时,文件就真正的被回收了。

二、NFS工作原理

(1)先启动RPC服务。
(2)在启动NFS服务,并向RPC服务注册启动的端口。
(3)客户端向RPC服务发送NFS服务的请求。(TCP/IP协议传输)
(4)RPC服务给客户端发送请求NFS服务的端口号。(TCP/IP协议传输)
(5)客户端用RPC服务返回的端口请求NFS数据传输,最终NFS服务发送本地磁盘数据给客户端,客户端将数据存储到本地磁盘中。(TCP/IP协议传输)

三、DNS解析流程

(1) 有一台PC访问www.etiantian.org时,首先这台PC会先检查浏览器缓存,如果有,则直接访问。
(2) 如若没,则向本机系统盘的hosts文件发起请求查询www.etiantian.org域名,如若有则直接返回拿到IP地址,并向相应的DNS服务直接访问,并在本地hosts记录;但这种方式很容易被域名劫持,所以有必要的话把hosts文件设置为readonly。
(3) 如若没,则向LDNS服务器来请求解析这个域名,LDNS服务器会查询ISP DNS缓存,如若有,则域名解析完成。
(4) 如果LDNS仍没有,则会向上一级(也就是13台根域名服务器)请求,根服务器拿到此请求后,返回.org顶级域名服务器的解析地址给LDNS服务器,让LDNS服务器去找.org域名服务器。
(5) LDNS服务器就会向.org域名服务器发出请求,.org服务器就在本地/etc/hosts下找到DNS记录etiantian.org,并给LDNS服务器返回etiantian.org解析记录。
(6) LDNS服务器就再次向etiantian.org这个域的权威服务器发出请求,在etiantian.org收到请求后,查到其下有www.etiantian.org这台主机,并把IP返回给LDNS服务器。
(7) LDNS服务器拿到www.etiantian.org的IP之后,将其返回给这台PC,并且在保存在本地缓存中

四、用户访问网站流程

4.1 域名解析

(1)游览器搜索自身的DNS缓存
(2)搜索操作系统自身的DNS缓存
(3)搜索操作系统的hosts文件
(4)向localDNS发起请求,先读取DNS服务器自身的缓存
(5)向13台根域名服务器发起请求
(6)向顶级域名服务器发起请求
(7)向域名服务器发起请求,获取到IP地址,返回localDNS,localDNS本地成成缓存,返回给操作系统内核,内核将结果返回给游览器

4.2 TCP/IP三次握手

(1)服务端被动打开进入 LISTEN ,客户端主动打开向服务端发送一个 SYN+seq 的请求连接报文并进入 SYN-SENT 状态。
(2)服务端接收到请求后,向客户端发送 SYN+ACK+seq 的确认建立连接请求,并进入 SYN-RCVD 状态,表示服务端已经收到客户端的连接请求,等待客户端的确认。
(3)客户端收到服务端的确认请求建立连接后再次发送确认,同时携带需要发送给服务端的数据(ACK+seq+ack),服务端一旦收到客户端确认后,客户端和服务端同时进入 ESTAB-LISHED 状态,就可以进行数据传输了。

4.3 建立TCP连接后发起HTTP请求

建立连接后,客户端发送一个HTTP请求报文给服务端,其中包括请求行、请求头、空行、请求报文主体。

4.4 服务器响应HTTP请求,游览器得到HTML代码

nginx读取http请求头里面的信息,根据host来匹配所有虚拟主机配置文件的 server_name,通过这个得知网页的首页文件,以PHP为例,通过location正则匹配,nginx将php文件交给fastcgi处理。

4.5 浏览器解析html代码,并请求html代码中的资源

游览器拿到html文件后,解析其中的html代码,遇到静态资源时,向服务器发起一个http请求(检查本地缓存是否过期),如果服务器端返回304状态码,那么浏览器会直接读取本地的该资源的缓存文件,否则就向服务端去请求下载,这时就用上了HTTP-1.1的特性,会使用多线程下载。

4.6 浏览器对页面进行渲染呈现给用户

浏览器利用自己内部的工作机制,把请求到的静态资源和html代码进行渲染,渲染之后呈现给用户。

4.7 TCP/IP四次挥手

(1)数据传输完成后,客户端向服务端发送一个 FIN+seq 请求关闭数据传输,然后进入 FIN-WAIT-1状态。
(2)当服务端收到客户端的断开请求时,向客户端发送一个ACK报文,询问客户端确定要断开连接么,然后进入 CLOSE-WAIT状态。
(3)服务端向客户端发送 FIN+ACK 报文,告诉客户端应用程序关闭,并进入 LAST-ACK状态,此时客户端进入 FIN-WAIT-2状态。
(4)当客户端收到服务端的确认断开连接请求时,回复一个 ACK 给服务端,告诉服务端确认断开,此时客户端进入 TIME-WAIT状态,当服务端收到断开请求后,客户端和服务端进入 CLOSED状态。

五、MySQL主从复制原理、MHA高可用工作过程

5.1 主从复制的前提

(1)至少两个实例
(2)不同的server_id
(3)主库需要开启二进制日志
(4)主库需要授权一个专用复制用户
(5)主库数据备份
(6)开启专用复制线程

5.2 主从工作原理

(1) 从库执行 change master to 语句,会立即将主库信息记录到 master.info
(2) 从库执行 start slave,会立即生成 IO线程 和 SQL线程
(3) IO线程 读取 master.info 文件,获取到主库信息
(4) IO线程 连接主库,主库会立即分配一个 DUMP线程,进行交互
(5) IO线程 根据 master.info binlog 信息,向 DUMP线程请求最新的 binlog
(6) 主库 DUMP线程 经过查询,如果发现有新的,截取并放回给从库 IO线程
(7) 从库 IO线程 会收到 binlog,存储在 TCP/IP 缓存中,在网络底层返回 ACK
(8) 从库 IO线程 会更新 master.info,重置 binlog 位置点信息
(9) 从库 IO线程 会将 binlog 写入到 relay-log中
(10) 从库 SQL线程 读取 relay_log.info 文件,获取上次执行过的位置点
(11) SQL线程 按照位置点往下执行 relay_log 日志
(12) SQL线程 执行完成后,重新更新 relay-log.info
(13) relay-log 定期自动清理的功能
细节:主库发生了信息的修改,更新二进制日志完成后,会发送一个"信号"给Dump_T,Dump_T通知给
IO_T线程

5.3 MHA高可用工作流程

(1)读取配置文件
(2)获取到node相关的信息(1主2从)
(3)调用masterha_check_ssh脚本 ,使用 ssh_user=root 进行互信检查
(4)调用masterha_check_repl 检查主从复制情况
(5)manager启动成功。
(6)通过masterha_master_monitor 以 ping_interval=2为间隔持续监控主库的状态,如网络,主机,数据库状态(mha)
(7)当Manager监控到master宕机
(8)开始选主过程
算法一:判断是否有《强制主》参数
算法二: 判断两个从库谁更新
算法三:按照配置文件书写顺序来选主
(9)判断主库SSH的连通性
能:S1 和 S2 立即保存(save_binary_logs)缺失部分的binlog到本地
不能:
在传统模式下:调用apply_diff_relay_logs计算S1和S2的 relay-log的差异
需要通过内容进行复杂的对比
在GTID模式下:调用apply_diff_relay_logs计算S1和S2的 relay-log的差异
只需要对比GTID号码即可,效率较高
最后进行数据补偿
(10)解除S1从库身份
(11)S2和S1构建新的主从关系
(12)移除配置文件中故障节点
(13)manager工作完成,自杀(一次性的高可用)

六、Keepalived高可用工作原理

Keepalived高可用对之间是通过VRRP协议通信的,因此,我从VRRP协议介绍开始给您讲起:
(1) VRRP协议,全称Virtual Router Redundancy Protocol, 中文名为虚拟路由冗余协议,VRRP的出现是为了解决静态路由的单点故障。
(2) VRRP 是通过一种竟选协议机制来将路由任务交给某台VRRP路由器的。
(3) VRRP是通过IP多播的方式(默认多播地址(224.0.0.18) )实现高可用对之间通信的。
(4) 工作时主节点发包,备节点接包,当备节点接收不到主节点发的数据包的时候,就启动接管程序接管主节点的资源。备节点可以有多个,通过优先级竟选,但一般Keepalived系统运维工作中都是一对。
(5) VRRP使用了加密协议加密数据,但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。

七、Nginx配合PHP工作的FastCGI工作原理

Nginx不支持对外部动态程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket,为了调用CGI程序,还需要一个FastCGI的wrapper (可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定的socket上,如端口或文件socket。
(1) 当Nginx将CGI请求发送给这个socket 的时候,通过FastCGI接口,wrapper接收到请求,然后派生出一个新的线程,这个线程调用解释器或外部程序处理脚本来读取返回的数据
(2) 接着wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx
(3) 最后,Nginx将返回的数据发送给客户端,这就是Nginx+FastCGI的整个运作过程

八、CDN工作原理

工作流程:
(1)用户向浏览器提供要访问网站的域名,域名解析的请求被发往网站的DNS服务器
(2)由于网站的DNS服务器对此域名的解析设置了CNAME,请求被指向CDN网络中的路由系统
(3)CDN对域名进行智能解析,将响应速度最快的节点IP返回给用户
(4)浏览器在得到实际的IP地址以后,向CDN节点发出访问请求
(5)由于是第一次访问,CDN节点将回到源站取用户请求的数据并发给用户
(6)当有其他用户再次访问同样内容时,CDN将直接将数据返回给客户,完成请求/服务过程


做事滴水穿石,做人滴水不漏