互联网时代,高并发是一个老生常谈的话题。无论对于一个Web站点还是App应用,高峰时能承载的并发请求都是衡量一个系统性能的关键标志。像阿里双十一顶住了上亿的峰值请求、订单也确实体现了阿里的技术水平(当然有钱也是一个原因)。 那么,何为系统负载能力?怎么衡量?相关因素有哪些?又如何优化呢? 一. 衡量指标用什么来衡量一个系统的负载能力呢?有一个概念叫做每秒请求数(Requests per second),指的是每秒能够成功处理请求的数目。比如说,你可以配置Tomcat服务器的maxConnection为无限大,但是受限于服务器系统或者硬件限制,很多请求是不会在一定的时间内得到响应的,这并不作为一个成功的请求,其中成功得到响应的请求数即为每秒请求数,反应出系统的负载能力。 通常的,对于一个系统,增加并发用户数量时每秒请求数量也会增加。然而,我们最终会达到这样一个点,此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量,每秒请求数量开始下降,而反应时间则会增加。这个并发用户数量开始“压倒”服务器的临界点非常重要,此时的并发用户数量可以认为是当前系统的最大负载能力。 二. 相关因素一般的,和系统并发访问量相关的几个因素如下:
其中,带宽和硬件配置是决定系统负载能力的决定性因素。这些只能依靠扩展和升级提高。我们需要重点关注的是在一定带宽和硬件配置的基础上,怎么使系统的负载能力达到最大。 2.1 带宽毋庸置疑,带宽是决定系统负载能力的一个至关重要的因素,就好比水管一样,细的水管同一时间通过的水量自然就少(这个比喻解释带宽可能不是特别合适)。一个系统的带宽首先就决定了这个系统的负载能力,其单位为Mbps,表示数据的发送速度。 2.2 硬件配置系统部署所在的服务器的硬件决定了一个系统的最大负载能力,也是上限。一般说来,以下几个配置起着关键作用:
很多系统的架构设计、系统优化,最终都会加上这么一句:使用SSD存储解决了这些问题。 可见,硬件配置是决定一个系统的负载能力的最关键因素。 2.3 系统配置一般来说,目前后端系统都是部署在Linux主机上的。所以抛开Win系列不谈,对于Linux系统来说一般有以下配置关系着系统的负载能力。
2.3.1 文件描述符数限制
通过读取/proc/sys/fs/file-nr可以看到当前使用的文件描述符总数。另外,对于文件描述符的配置,需要注意以下几点:
2.3.2 进程/线程数限制
2.3.3 TCP内核参数在一台服务器CPU和内存资源额定有限的情况下,最大的压榨服务器的性能,是最终的目的。在节省成本的情况下,可以考虑修改Linux的内核TCP/IP参数,来最大的压榨服务器的性能。如果通过修改内核参数也无法解决的负载问题,也只能考虑升级服务器了,这是硬件所限,没有办法的事。
使用上面的命令,可以得到当前系统的各个状态的网络连接的数目。如下:
这里,TIME_WAIT的连接数是需要注意的一点。此值过高会占用大量连接,影响系统的负载能力。需要调整参数,以尽快的释放time_wait连接。 一般TCP相关的内核参数在/etc/sysctl.conf文件中。为了能够尽快释放time_wait状态的连接,可以做以下配置:
这里需要注意的一点就是当打开了tcp_tw_recycle,就会检查时间戳,移动环境下的发来的包的时间戳有些时候是乱跳的,会把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据,不是新的请求”,于是丢掉不回包,造成大量丢包。另外,当前面有LVS,并且采用的是NAT机制时,开启tcp_tw_recycle会造成一些异常,可见:http://www./?p=416。如果这种情况下仍然需要开启此选项,那么可以考虑设置net.ipv4.tcp_timestamps=0,忽略掉报文的时间戳即可。 此外,还可以通过优化tcp/ip的可使用端口的范围,进一步提升负载能力,如下:
2.4 应用服务器配置说到应用服务器配置,这里需要提到应用服务器的几种工作模式,也叫并发策略。
前三者是传统应用服务器Apache和Tomcat采用的方式,最后一种是Nginx采用的方式。当然这里需要注意的是应用服务器和nginx这种做反向代理服务器(暂且忽略nginx+cgi做应用服务器的功能)的区别。应用服务器是需要处理应用逻辑的,有时候是耗cup资源的;而反向代理主要用作IO,是IO密集型的应用。使用事件驱动的这种网络模型,比较适合IO密集型应用,而并不适合CPU密集型应用。对于后者,多进程/线程则是一个更好地选择。 当然,由于Nginx采用的基于事件驱动的多路IO复用的模型,其作为反向代理服务器时,可支持的并发是非常大的。淘宝Tengine团队曾有一个测试结果是“24G内存机器上,处理并发请求可达200万”。 2.4.1 Nginx/TengineNgixn是目前使用最广泛的反向代理软件,而Tengine是阿里开源的一个加强版Nginx,其基本实现了Nginx收费版本的一些功能,如:主动健康检查、session sticky等。对于Nginx的配置,需要注意的有这么几点:
典型配置可见:https://github.com/superhj1987/awesome-config/blob/master/nginx/nginx.conf 2.4.2 TomcatTomcat的关键配置总体上有两大块:jvm参数配置和connector参数配置。
对于tomcat这里有一个争论就是:使用大内存Tomcat好还是多个小的Tomcat集群好?(针对64位服务器以及Tomcat来说) 其实,这个要根据业务场景区别对待的。通常,大内存Tomcat有以下问题:
因此,如果可以保证一定程度上程序的对象大部分都是朝生夕死的,老年代不会发生gc,那么使用大内存Tomcat也是可以的。但是在伸缩性和高可用却比不上使用小内存(相对来说)Tomcat集群。 使用小内存Tomcat集群则有以下优势:
2.4.3 数据库
MySQL是目前最常用的关系型数据库,支持复杂的查询。但是其负载能力一般,很多时候一个系统的瓶颈就发生在MySQL这一点,当然有时候也和SQL语句的效率有关。比如,牵扯到联表的查询一般说来效率是不会太高的。影响数据库性能的因素一般有以下几点:
抛开以上因素,当数据量单表突破千万甚至百万时(和具体的数据有关),需要对mysql数据库进行优化,一种常见的方案就是分表:
此外,对于数据库,可以使用读写分离的方式提高性能,尤其是对那种读频率远大于写频率的业务场景。这里一般采用master/slave的方式实现读写分离,前面用程序控制或者加一个Proxy层。可以选择使用MySQL Proxy,编写lua脚本来实现基于Proxy的MySQL读写分离;也可以通过程序来控制,根据不同的SQL语句选择相应的数据库来操作,这个也是笔者公司目前在用的方案。由于此方案和业务强绑定,是很难有一个通用的方案的,其中比较成熟的是阿里的TDDL,但是由于未全部开源且对其他组件有依赖性,不推荐使用。 现在很多大的公司对这些分表、主从分离、分布式都基于MySQL做了自己的二次开发,形成了自己公司的一套分布式数据库系统。比如阿里的Cobar、网易的DDB、360的Atlas等。当然,很多大公司也研发了自己的MySQL分支,比较出名的就是姜承尧带领研发的InnoSQL。
当然,对于系统中并发很高并且访问很频繁的数据,关系型数据库还是不能妥妥应对。这时候就需要缓存数据库出马以隔离对MySQL的访问,防止MySQL崩溃。 其中,Redis是目前用的比较多的缓存数据库(当然,也有直接把Redis当做数据库使用的)。Redis是单线程基于内存的数据库,读写性能远远超过MySQL。一般情况下,对Redis做读写分离主从同步就可以应对大部分场景的应用。但是这样的方案缺少HA,尤其对于分布式应用,是不可接受的。目前,Redis集群的实现方案有以下几个:
2.5 系统架构影响性能的系统架构一般会有这几方面:
2.5.1 负载均衡负载均衡在服务端领域中是一个很关键的技术。可以分为以下两种:
其中,硬件负载均衡的性能无疑是最优的,其中以F5为代表。但是,与高性能并存的是其成本的昂贵。所以对于很多初创公司来说,一般是选用软件负载均衡的方案。 软件负载均衡中又可以分为四层负载均衡和七层负载均衡。上文在应用服务器配置部分讲了nginx的反向代理功能即七层的一种成熟解决方案,主要针对的是七层http协议(虽然最新的发布版本已经支持四层负载均衡)。对于四层负载均衡,目前应用最广泛的是lvs。其是阿里的章文嵩博士带领的团队所研发的一款linux下的负载均衡软件,本质上是基于iptables实现的。分为三种工作模式:
三种模式各有优缺点,目前还有阿里开源的一个FULL NAT是在NAT原来的DNAT上加入了SNAT的功能。 此外,haproxy也是一款常用的负载均衡软件。但限于对此使用较少,在此不做讲述。 2.5.2 同步 or 异步对于一个系统,很多业务需要面对使用同步机制或者是异步机制的选择。比如,对于一篇帖子,一个用户对其分享后,需要记录用户的分享记录。如果你使用同步模式(分享的同时记录此行为),那么响应速度肯定会受到影响。而如果你考虑到分享过后,用户并不会立刻去查看自己的分享记录,牺牲这一点时效性,可以先完成分享的动作,然后异步记录此行为,会提高分享请求的响应速度(当然,这里可能会有事务准确性的问题)。有时候在某些业务逻辑上,在充分理解用户诉求的基础上,是可以牺牲某些特性来满足用户需求的。 这里值得一提的是,很多时候对于一个业务流程,是可以拆开划分为几个步骤的,然后有些步骤完全可以异步并发执行,能够极大提高处理速度。 2.5.3 28原则对于一个系统,20%的功能会带来80%的流量。这就是28原则的意思,当然也是我自己的一种表述。因此在设计系统的时候,对于80%的功能,其面对的请求压力是很小的,是没有必要进行过度设计的。但是对于另外20%的功能则是需要设计再设计、reivew再review,能够做负载均衡就做负载均衡,能够缓存就缓存,能够做分布式就分布式,能够把流程拆开异步化就异步化。 当然,这个原则适用于生活中很多事物。 三. 一般架构一般的Java后端系统应用架构如下图所示:LVS+Nginx+Tomcat+MySql/DDB+Redis/Codis 其中,虚线部分是数据库层,采用的是主从模式。也可以使用redis cluster(codis等)以及mysql cluster(Cobar等)来替换。 作者:飒然Hang,架构师/后端工程师,working@中华万年历 |
|