简介
华尔街见闻的运营方上海阿牛信息科技有限公司是全球金融信息服务提供商，每天全平台为近200万用户提供资讯、数据、研究等服务。旗舰产品华尔街见闻APP长期位居各应用市场财经资讯类客户端第1位。由于将重大事件、市场的基本面变化和100多种全球资产价格紧密关联，在金融领域具有极高渗透率。首创的7x24快讯模式已经成为在中文世界理解全球市场的最快来源。也因此，该产品有技术架构复杂，需要高并发承载能力等特性。

背景
•老系统日益臃肿
原先的系统是PHP monolithic架构，功能按模块划分，日积月累，最后模块达到60+个，新人接手项目会拿到一整个系统的代码，以及需要整个系统的配置，而他可能只需要专注开发不到1/10的业务。
•伸缩性
我们的主要业务是即时资讯，资讯具有时效性，网站的访问量会呈现锯齿形分布。当遇到特大新闻如英国退欧、美国大选、法国大选等，我们要能弹性地通过增加服务资源，提高服务的容量。
•容错性
我们希望一个低优先级服务出现问题之后，不影响主要服务；一个主要服务能保证更高的可用性，就算出现问题，也要保证优雅降级。
比如在重大事件发生的时候，我们希望文章API保证不会受到影响。
•单体应用
PHP单体应用在生产环境服务的时候，所有业务都跑在一个程序里，增加了系统的脆弱性，一个隐藏的性能问题，能在服务量激增的时候成为压垮骆驼的一根稻草。
•云服务商成本
由于架构落后于需要，我们不得不用硬件弥补性能上的问题，导致云服务器成本不断增加。
•线上运维
由于没有方便的监控和运维工具，导致排查问题的效率低，使得在系统遇到问题的时候排查困难，耗时过长。
•开发新功能
开发新任务的同时，我们需要修复原有系统的性能问题。

PHP monolithic架构图 

每台服务器部署相同的服务端PHP代码，由PHP-fpm解释执行，通过Nginx进行反向代理。
 
华尔街见闻微服务架构设计

因此，在2016年11月至2017年3月，我们采用微服务架构启动重构，尝试解决一部分上述问题，在伸缩性上能以服务为单位进行拓容，同时，这一设计会在某些方面增大我们的开发成本和运维成本。
•错误排查复杂
很显然，以前在单体应用中能直接登录服务器，查看出错日志，现在错误散落在不同的服务中，为我们的错误排查带来了困难。
•日志源增加
如何把服务的日志收集并分析。
•基础设施增加
每个服务有互相独立的MySQL、Redis，公共服务方面需要高可用的服务发现，调用链路分析，日志收集储存设施等。

技术选型

微服务架构图

 每台服务器上均衡地部署服务，LB接受用户的请求，将请求转发到API gateway，API gateway向服务发现查询具体服务的IP和端口，服务执行完业务逻辑后向上返回数据。

服务框架
我们选择golang作为我们的后端开发语言。
•    golang在性能和开发效率上有很好的平衡，语法上很简单，并发编程简单高效，基础库健全。
•    调试工具强大
自带一些pprof包可以profile当前程序的CPU消耗、内存占用、锁状态、channel阻塞等，非常便利我们定位问题。
•    有一些优秀的微服务框架
我们选用go-micro作为开发框架，里面包含几乎所有微服务组件，并且支持非常好的拓展性，通过接口的设计方式，让我们可以拓展一些自己的组件，如服务发现、传输协议等。
•    golang在华尔街见闻已经有过比较多的应用，工程师使用golang开发几乎0学习成本。

服务拆分
拆分的原则是通过服务功能划分，尽量避免双向依赖。我们拆分出了13个服务，包括用户、内容、实时新闻、评论、搜索、商城、支付、三方代理等服务。

服务间通信
服务间使用protobuf协议对数据进行编码，使用UDP作为传输协议。

服务发现
Etcd搭建多节点高可用的服务发现。

服务保护
我们选择Hystrix作为服务保护以及服务降级的方案。
每个服务开发者，需要定义自己服务接口的并发量、超时时间以及fallback方法。

部署方案

我们选择了Kubernetes。 
* Docker Swarm
这是我们最先选择的方案，因为Docker 1.12之后已经将Swarm功能集成到Docker En-gine，能以最少的配置启动Docker集群。经过简化和设计的控制台API，方便地管理集群、调整服务如控制服务的数量、CPU、内存限制等。往集群内加入机器非常简单，只需要运行一条命令即可。使用manager-worker架构，manager作为调度节点，支持高可用。
但遇到了非常致命的问题，比如频繁更新服务的时候会出现服务访问不到，某服务的负载均衡后挂载的服务IP是其它服务的，服务之间的通信有几率出现超时问题，归根结底，还是社区正在不断完善swarm，有很多不稳定的地方，网络方面没有进行优化。
* Kubernetes
这是谷歌主导的服务编排工具，它支持Docker，相比Docker Swarm来说，它的概念更多，分层更细。功能方面多于Docker Swarm，支持一些高级功能如秘钥管理、配置管理、自动拓容等。在生产环境的应用比较广泛，稳定性更高。
* 裸机部署
裸机部署是我们的一个备案，考虑到以上两个方案在当时没有具体线上实施的经验，所以如果Docker Swarm和Kubernetes都没有成功，我们直接裸机部署。
裸机部署的需要解决单机端口冲突，如果一个服务在一个服务器上最多只部署一个，那么可以通过写脚本，并划分服务器角色的方式进行部署，利用ansible可以定义user服务集群、content服务集群、comment服务集群等，通过分发二进制文件的方式让服务启动，这样的方案要考虑到服务更新、服务重启、服务删除等逻辑，同一时间只有部分节点更新，在服务未更新成功的时候流量暂时不能打到正在更新的节点。

准备工作

代码托管
由于之前使用github开发人员的代码提交在有翻墙工具的帮助下速度依然不是很理想，我们自建了Gitlab仓库，自此开发过上了幸福的生活。

容器化
swarm和kubernetes是基于docker快速创建删除服务，通过增加容器为服务拓容，缩减容器为服务缩小规模，所以所有项目必须要构建docker镜像。按项目类型划分，我们遇到3种镜像打包情况。
1.    后端项目
后端服务90%是golang项目，针对golang的镜像，我们采取将golang项目编译成可执行文件，基于最小的alpine镜像打包入docker，这里遇到过一个问题，就是alpine里缺少openssl的证书，无法支持https，我们自定义了新的基础镜像，不仅将证书文件打入镜像，同时为了线上调试方便，增加了tcpdump、strace、bash等工具，在初期调试容器间通信问题时发挥重要的作用。
2.    前端静态文件
见闻的后台以及m站基于Vue，编译后生成的静态文件打入镜像，通过nginx访问。 为了支持HTTP2，我们打入nginx镜像缺少的证书。
3.    服务端渲染
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源https://registry.npm.taobao.org进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载，镜像打包从开始的3分钟缩减到1.5分钟。

三类镜像结构
 

持续集成
我们利用Gitlab CI配置了测试、镜像构建、镜像发布、自动部署等流程，后端服务从提交代码到测试分支到测试环境自动部署完成花费1.5分钟，前端服务平均为2.5分钟。

CI任务中的test->build->docker->deploy流程 


云平台的选择
最终，我们选择了腾讯云的容器服务，主要基于以下几点考虑：
•    腾讯云的容器服务是在腾讯云的Iaas上为每个用户构建容器集群，腾讯云提供的微服务架构和持续集成与交付的应用场景基本满足了我们的述求。
•    腾讯云的容器服务是基于Kubernetes实现的，支持完全的kubernetes能力。
•    腾讯云在Kubernetes上实现了他们的存储、负载均衡等产品的插件、复用了腾讯云本身平台的监控、日志等能力。减少了我们接入和开发的成本。

服务在腾讯云的应用
我们将我们的应用重构成微服务的架构，每个微服务部署成腾讯云容器服务上的一个服务，前端接入通过一个负载均衡。后端服务间可互相访问。
服务器安全方面，内部服务器通过VPC进行网络隔离，将网络划分为生产环境、测试环境，在生产环境中又划分backend子网和data子网，设定子网之间的访问规则。
为了禁止内部服务器的外网访问，不给内部服务器分配外网IP，仅通过跳板机访问。

性能对比
利用locust模拟线上请求的比例，利用2台16核的压测机在内网对10台16C32G的机器上的服务进行压测，达到1w/s QPS以上，并且服务的负载并没达到极限，这已经是之前PHP生产环境20+台16C32G服务器能达到的QPS。


线上调用追踪
通过追踪API调用链的流向与耗时，我们可以找出性能的瓶颈。我们通过zipkin实际优化了几种情况:
•    服务调用冗余
当拉取文章列表的时候，我们需要拉取文章对应的作者信息，开始的时候我们使用拉取单个作者信息的方式，后来性能调优阶段，我们将其改为批量拉取作者列表，减少RPC的冗余。
•    服务耗时长
对于有些本身就比较耗时并且对即时性不是那么苛刻的计算服务，我们为了保证服务的响应时间，会适量地加上缓存。

监控与报警
由从外部系统表征到内部日志，我们将监控分为API健康，程序错误报警，以及服务器/容器负载。
排查问题的流程一般有两种情况，一种是用户发现问题，申报问题，开发人员跟进问题；一种是我们的监控优先发现问题，开发人员在用户反馈前跟进并修复。在报警方面，我们通过为监控系统谨慎设置报警阈值，当触发报警时，开发人员会收到邮件。
这里我们在报警的定义上有过思考，即什么样的报警算是有意义的？我们遇到过每天10几条重复的报警，通常开发人员开始时会对报警非常重视，当重复的报警一再出现，渐渐失去了对报警的关注。所以我们有解除一些不必要的报警，并且对剩余一些报警进行调查，甚至有些警报是因为监控工具本身的不准确引起的。

API健康
我们设置默认的时间区间是5分钟
•    统计API五分钟内平均QPS
•    API 98%以内的延迟分布
•    QPS最高的前10的API
•    API的返回码的分布

程序错误报警
后端程序内接入Sentry日志报警系统，golang程序捕获panic日志以及error日志，并发送报警邮件。

服务器/容器负载
通过在服务器上运行telegraf daemon进程，收集服务器metrics并发送给influxdb，使用Grafana作为前端面板，对服务器负载以及容器的平均CPU、内存占用率进行监控。

结束语
本文介绍了华尔街见闻通过重构和服务容器的重新部署，实践微服务架构的情况。经过几个月的开发测试，我们不仅完成了线上服务从PHP到Golang的转型，更在服务的稳定性上经历了考验，支撑了几次重大新闻的高流量。
在开发流程上，搭建了完善的自动化工具，减少了人工操作的重复性和误操作概率。
在运维方面，由于监控系统对系统完整的监控，与Kubernetes健全的上线、下线、回滚、拓容功能配合，能以极快的速度处理线上问题。

1、HTTP协议与TCP/IP协议的关系​
HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。TCP有可靠，面向连接的特点。
 
2、如何理解HTTP协议是无状态的
HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。
 
3、什么是长连接、短连接？
在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
 
但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
 
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
 
3.1 TCP连接
当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接 时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的

经典的三次握手示意图：


经典的四次挥手关闭图：
 


 
3.2 TCP短连接
我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server 发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起 close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在 client/server间传递一次读写操作

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段
 
3.3 TCP长连接
接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务 器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

1. 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
2. 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
3. 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
4. 客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

 
长连接短连接操作过程:
短连接的操作步骤是：建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是：建立连接——数据传输...（保持连接）...数据传输——关闭连接
 
4、 长连接和短连接的优点和缺点
由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。
 
5、什么时候用长连接，短连接？ 
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。 
  
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

如果生产环境，可以利用heartbeta或者keepalived作高可用，下面介绍一下nfs服务安装过程。
 

一、安装环境

NFS服务器：CentOS6.5 192.168.0.10
NFS客户端：CentOS6.5 192.168.0.11
 

二、服务器端安装配置​

1、先用rpm -qa命令查看所需安装包（nfs-utils、rpcbind）是否已经安装：

[root@local /]# rpm -qa | grep "rpcbind"

rpcbind-0.2.0-11.el6.x86_64

[root@local /]# rpm -qa | grep "nfs"

nfs-utils-1.2.3-39.el6.x86_64

nfs4-acl-tools-0.3.3-6.el6.x86_64

nfs-utils-lib-1.1.5-6.el6.x86_64

2、如查询结果如上，说明服务器自身已经安装了NFS，如果没有安装，则用yum命令来安装：

[root@local /]# yum -y install nfs-utils rpcbind

3、创建共享目录：

[root@local /]# mkdir /sharestore

4、NFS共享文件路径配置：
编辑/etc/exports添加下面一行，添加后保存退出。
 

[root@local /]# vi /etc/exports

/sharestore     *(rw,sync,no_root_squash)

/sharestore   10.10.0.0/8(rw,sync,no_subtree_check,anonuid=48,anongid=48)

你也可以指定可以访问网段和用户id。
 
5、启动NFS服务（先启动rpcbind，再启动nfs；如果服务器自身已经安装过NFS，那就用restart重启两个服务）：

[root@local /]# service rpcbind start

Starting rpcbind:                                          [  OK  ]

[root@local /]# service nfs start

Starting NFS services:                                     [  OK  ]

Starting NFS quotas:                                       [  OK  ]

Starting NFS mountd:                                       [  OK  ]

Stopping RPC idmapd:                                       [  OK  ]

Starting RPC idmapd:                                       [  OK  ]

Starting NFS daemon:                                       [  OK  ]

[root@local /]#

6、设置NFS服务开机自启动：

[root@local /]# chkconfig rpcbind on

[root@local /]# chkconfig nfs on

三、客户端挂载配置

1、创建一个挂载点：
 

[root@localhost ~]# mkdir /mnt/store

2、查看NFS服务器上的共享：

[root@localhost /]# showmount -e 192.168.0.10

Export list for 192.168.0.10:

/sharestore *

3、挂载：

[root@localhost ~]# mount -t nfs 192.168.0.10:/sharestore /mnt/store

4、查看已挂载共享：

[root@localhost ~]# mount

/dev/mapper/VolGroup-lv_root on / type ext4 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

tmpfs on /dev/shm type tmpfs (rw)

/dev/sda1 on /boot type ext4 (rw)

/dev/mapper/VolGroup-lv_home on /home type ext4 (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

nfsd on /proc/fs/nfsd type nfsd (rw)

192.168.0.10:/mailstore1/ on /mailstore_new type nfs (rw,vers=4,addr=192.168.0.10,clientaddr=192.168.0.11)

有时候云上部署环境，不能动态自设路由，没有公网ip地址的服务器，只能通过NAT的方式出外网，下面就记录一下设置过程。

当前状态

服务器A只有一个内网IP，不能上外网，内网IP与服务器B内网相通；服务器B有一个内网IP和公网IP。想实现服务器A也能上外网。

服务器A：内网网卡：eth0  内网IP：192.168.0.10

 

服务器B：内网网卡：eth0  内网IP：192.168.0.20

        外网网卡：eth1  外网IP：203.195.32.138

实现方法

1、在可以上外网的服务器B上，开启路由转发功能

echo 1 > /proc/sys/net/ipv4/ip_forward

注：上面命令在服务器重启之后会失效，可以编辑/etc/rc.d/rc.local把上面命令添加到最底部，实现开启自动执行。
 
或者进行如下操作：

编辑/etc/sysctl.conf

找到net.ipv4.ip_forward = 0 修改为 net.ipv4.ip_forward = 1 最后保存。

 

执行sysctl -p命令使配置生效：

# sysctl -p

2、在可以上外网的服务器B上执行添加SNAT规则

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.10 -j SNAT --to 203.195.32.138

如果想让整个网段都通过服务器B上外网，修改上面规则命令中-s 192.168.0.10为-s 192.168.0.0/24，然后把想上外网的服务器默认网关改成192.168.0.20就可以了。
 
3、保存刚添加的iptables规则

# service iptables save

4、在需要上外网的服务器A上，修改内网网卡eth0的默认网关为192.168.0.20

# route add default gw 192.168.0.20

修改后，查看路由表，确认已修改成功，测试已经可以上外网了

# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

0.0.0.0         192.168.0.20    0.0.0.0         UG    0      0        0 eth0

测试你ping一下baidu.com 就好。

最近我们的服务进程遇到kill -15后处于Z的状态，变为了僵尸进程，经过/proc/{thread_id}/stack查看其上线程的栈，发现是卡在了fwrite的过程中，而我们的系统中所有文件系统挂载参数都使用了delalloc参数，怀疑是这个原因：ext4挂载的时候打开了delalloc选项，然后系统在没有分配磁盘块的情况下写写写，到page cache被回写到磁盘时，发现磁盘已经满了，没办法分配新的磁盘块了，就Hang住了。
 
这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章，但是由于刘峥同学目前没有blog，征得本人同意，贴在我的blog上，如果大家喜欢，请去新浪微博关注他。:)
 
日前线上在升级到Ext4文件系统后出现应用写操作延迟开销增大的问题。造成这一问题的根源目前已经查明，是由于Ext4文件系统的一个新特性——Delay Allocation造成的。（后面简称delalloc）

在详细分析这一问题之前，先来介绍一下Ext4文件系统的delalloc特性。这一特性简要概括起来就是将以前在buffer IO中每次写操作都会涉及的磁盘块分配过程推迟到数据回写时再进行。我们知道，在进行Buffer Write时，系统的实际操作仅仅是为这些数据在操作系统内分配内存页（page cache）并保存这些数据，等待用户调用fsync等操作强制刷新或者等待系统触发定时回写过程。在数据拷贝到page cache这一过程中，系统会为这些数据在磁盘上分配对应的磁盘块。

而在使用delalloc后，上面的流程会略有不同，在每次Buffer Write时，数据会被保存到page cache中，但是系统并不会为这些数据分配相应的磁盘块，仅仅会查询是否有已经为这些数据分配过磁盘块，以便决定后面是否需要为这些数据分配磁盘块。在用户调用fsync或者系统触发回写过程时，系统会尝试为标记需要分配磁盘块的这些数据分配磁盘块。这样，文件系统可以为这些属于同一个文件的数据分配尽量连续的磁盘空间，从而优化后续文件的访问性能（因为传统机械硬盘顺序读写的性能要比随机读写好很多）。

了解完delalloc特性的工作过程后，我们开始分析线上遇到的问题。线上应用的I/O模式可以简化为一个单线程追加写操作的程序，每秒写入2、3M数据，写操作后等待系统自动将数据回写到磁盘。在使用delalloc后，每次Buffer Write操作，系统都会去查询数据是否分配了磁盘块，这一过程需要获得一把读锁 (i_data_sem)。由于这时还没有触发回写操作，因此可以顺利获取i_data_sem，系统完成数据拷贝工作，并返回。由于仅仅是内存拷贝的过程，所以这一操作速度相当快。当系统开始进行回写操作时，系统会成批为数据分配磁盘块，这一过程同样需要获取i_data_sem，并且需要加写锁​以保证数据的一致性。由于使用delalloc后，需要分配的磁盘块比nodelalloc情况下多很多（nodelalloc情况下每5秒文件系统会提交日志触发回写；delalloc情况下，系统会在约每30秒左右触发一次回写），因此这一延迟时间较长。如果这时应用程序进行一次Buffer Write，则该操作在尝试获得i_data_sem时会等待上述磁盘块分配完成。由此造成写操作等待很长时间，从而影响应用程序的响应延迟。

在上面的分析中已经提到，delalloc是将多次磁盘块分配的过程合并到一次中来进行，那么是否真如预想的那样，delalloc的平均延迟会小于nodelalloc的情况呢？我们使用fio来做如下测试：设置bs=4k，单线程每秒追加写入5M，程序运行3分钟，我们来看一下最后fio对延迟的统计结果：

delalloc:

lat (usec): min=2 , max=193466 , avg= 5.86, stdev=227.91



nodelalloc:

lat (usec): min=3 , max=16388 , avg= 7.00, stdev=28.92

从上面的统计结果看，写操作的平均延迟：打开delalloc后为5.86us，关闭delalloc后为7.00us；最小延迟delalloc为2us，nodelalloc为3us；但是最大延迟delalloc为193.466ms，nodelalloc下仅为16.388ms。可见delalloc确实将多个写操作请求集中到了一起来进行。因此在提供较低平均延迟的情况下，会造成某次写操作的延迟较大。

通过上面的分析可以看到，目前会受到Ext4的delalloc特性影响的应用必须具备如下条件：

1. Buffer IO
2. 写操作过程中会涉及磁盘块的分配，主要是记录日志这类追加写操作；
3. 每次写操作后没有刷新数据，而是等待系统自动进行回写；
4. 对延迟有较高要求。

 
解决方法：关闭delalloc

1、mount -t ext4 -o remount,nodelalloc /${dev} /${mnt};

2、编辑/etc/fstab中相关mount项，添加nodelalloc挂载参数

分享原文：http://www.cnblogs.com/cobbliu/p/5603472.html