您的位置:首页 > 运维架构 > 网站架构

大型网站系统架构实践(二)分布式模块之间的通信

2015-04-02 18:12 741 查看
上一篇文章中讲到了分布式部署之后,各个模块要通过网络进行通信,那么如何通信,用什么协议呢?

可选的方案有http tcp/ip(socket)等

http短连接通信方案

基于http协议,xml报文传输

客户端具体框架为httpclient,服务端为struts2

客户端和服务端的通信在内网

该方案我们实行过一段时间,发现存在性能问题,首先是短连接,在并发量较大的时候,开启大量的tcp连接,这样连接资源容易耗尽,客户端首先成为瓶颈,tps上不去。

我总结的几点原因:

1.每次通信都重新开启新的tcp连接,握手协议耗时间

2.tcp是慢启动,TCP 数据传输的性能还取决于 TCP 连接的使用期(age)。TCP 连接会随着时间进行自我“调谐”,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐被称为 TCP 慢启动(slow start),用于防止因特网的突

然过载和拥塞

3.http协议是在tcp协议上封装了一层,因此还存在解析协议的消耗,如果直接用tcp协议进行传输,效率将要高一点

据说http1.1可以实现长连接,但是没有用java客户端试过,后续再研究。

Mina长连接通信方案

主要开发任务在客户端,我是用Mina做的长连接异步通信,

我自己编写代码实现了一个,有时间贴出来分享一下,如果有想了解Mina使用技术的,可以先看我的Mina系列博客/article/6162659.html

这里我做了相关的性能测试,下面把测试结果贴出来一下:

短连接测试

场景描述

socket 发送消息到服务端,接收到响应后关闭

结果:

一段时间过后,会出现死掉的现象,连接会被耗尽

服务器cpu

2线程 3000Mhz

服务器cpu使用率

110%

客户端cpu

4线程 2400Mhz

客户端cpu使用率

95%

客户端执行线程数

500

每秒并发数

1800

长连接异步通讯测试

场景描述

客户端开启2个长连接,与服务端通信

服务器cpu

2线程 3000Mhz

服务器cpu使用率

100%-150%

客户端cpu

4线程 2400Mhz

客户端cpu使用率

60%

客户端连接数

2

客户端执行线程数

500

每秒通过事务数

16000

性能明显提升,而且状态稳定,cpu利用率较低

这里大家会有个问题,为什么要用异步通信,不能是同步

这里其实我们先要搞清楚什么是同步通信,什么是异步通信

同步通信

同步通信应该很好理解,这里我们以同一个socket连接为例,即多次请求都是从一个socket连接发送出去的。

Socket客户端发送一个请求,等待响应成功之后,再发送另一个请求,即在同一时间只能发送一个请求,加入我们的场景是这样的,发送的报文较小,服务端处理的速度较快,我们网站的大多数业务请求都是这样的,这样报文在网络中传输的时候,通道是很空闲的,通信的吞吐量将收到影响。

典型的同步通信是jdbc

异步通信

还是以同一个socket连接为例,socket客户端发送一个请求之后,在响应还没到来的时候,可以继续发送另一个请求,具体场景是这样的,业务线程1发送请求,然后线程等待结果,业务线程2发送请求,然后等待结果,以此类推,但是socket输出通道可以一直发送消息,socket输入一直在接收消息,这样业务处理和通信逻辑是分离开来的互不干扰,且充分利用了通信通道,因为网络传输的速度比cpu和磁盘要慢的多,因此解约使用网络资源,将极大的提高系统吞吐量,当然要记住这里的使用场景,高并发,较小的报文传输,如果报文特别大,几十MB,那异步通信就没意义了

NIO 和BIO

Mina是使用的NIO

这个网站上很多资料,我就简单的讲下,我们的场景是适合用NIO的,为什么呢?

我们的场景除了高并发,报文小,还有一个特点,就是客户端部署的点要远远多于服务端,因为越是底层的服务,可重用性越高,那么客户端就相对较多,服务端相对较少。

BIO的缺点

传统的BIO特点,有N个客户端连接服务端,服务端就需要开启N个线程来分别处理客户端的请求,而且很多时候客户端是空闲状态的,那么服务端给它开的线程也将空闲,造成了资源浪费,同时线程数还不够用。

NIO的优点

NIO很好的解决了这个问题,它使得服务端的一个线程可以处理多个客户端连接,只要协调的好,可以用较少的线程处理较多的客户端连接,使线程利用率得到很大的提高。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: