23

高性能网络编程(七):到底什么是高并发?一文即懂!

 3 years ago
source link: http://www.blogjava.net/jb2011/archive/2020/09/03/435653.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

本文由小米信息技术团队研发工程师陈刚原创,原题“当我们在谈论高并发的时候究竟在谈什么?”,为了更好的内容呈现,即时通讯网收录时有修订和改动。

1、引言

在即时通讯网社区里,多是做IM、消息推送、客服系统、音视频聊天这类实时通信方面的开发者,在涉及到即时通讯技术时聊的最多的话题就是高并发、高吞吐、海量用户。

代码还没开始写,就考虑万一哪天这IM用户量破百万、千万该怎么办的问题,是多数程序员的基本修养( 虽然产品一上市就可能死翘翘,但该“高瞻远瞩”的时候,不应该偷懒,不然怎么跟老板提涨工资..... )。

U3MbYn.png!mobile

在面视即时通讯相关工作的时候,高并发也是必谈问题,那到底什么是高并发?嗯,真要说出个所以然来,还真有点懵。。。

学习交流:

- 即时通讯/推送技术开发交流5群: 215477170 [推荐]

- 移动端IM开发入门文章:《 新手入门一篇就够:从零开发移动端IM

- 开源IM框架源码: https://github.com/JackJiang2011/MobileIMSDK

(本文同步发布于: http://www.52im.net/thread-3120-1-1.html

2、系列文章

本文是系列文章中的第7篇,总目录如下:

高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了

高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索

高性能网络编程(五):一文读懂高性能网络编程中的I/O模型

高性能网络编程(六):一文读懂高性能网络编程中的线程模型

高性能网络编程(七):到底什么是高并发?一文即懂! 》(本文)

高性能网络编程经典:《The C10K problem(英文)》[附件下载]

3、什么是高并发?

高并发是互联网系统架构的性能指标之一,它通常是指单位时间内系统能够同时处理的请求数。

简单点说,就是QPS( Queries per second )。

那么我们在谈论高并发的时候,究竟在谈什么东西呢?归根结底,到底什么是高并发?

VFFJVnE.png!mobile

别急,我们继续往下读 ....

4、高并发究竟是什么?

这里先给出结论: 

1)高并发的基本表现为单位时间内系统能够同时处理的请求数;
2)高并发的核心是对CPU资源的有效压榨。

举个例子:如果我们开发了一个叫做MD5穷举的应用,每个请求都会携带一个md5加密字符串,最终系统穷举出所有的结果,并返回原始字符串。这个时候我们的应用场景或者说应用业务是属于CPU密集型而不是IO密集型。

这个时候CPU一直在做有效计算,甚至可以把CPU利用率跑满,这时我们谈论高并发并没有任何意义。( 当然,我们可以通过加机器也就是加CPU来提高并发能力,这个是一个正常猿都知道废话方案,谈论加机器没有什么意义,没有任何高并发是加机器解决不了,如果有,那说明你加的机器还不够多! )

对于大多数互联网应用来说,CPU不是也不应该是系统的瓶颈,系统的大部分时间的状况都是CPU在等I/O ( 硬盘/内存/网络 ) 的读/写操作完成。

这个时候就可能有人会说,我看系统监控的时候,内存和网络都很正常,但是CPU利用率却跑满了这是为什么?

这是一个好问题,后文我会给出实际的例子,再次强调上文说的“有效压榨”这4个字,这4个字会围绕本文的全部内容!

5、控制变量法

万事万物都是互相联系的,当我们在谈论高并发的时候,系统的每个环节应该都是需要与之相匹配的。

我们先来回顾一下一个经典C/S的HTTP请求流程:

iyaa2uj.png!mobile

如上图中的序号所示:

1)我们会经过DNS服务器的解析,请求到达负载均衡集群;
2)负载均衡服务器会根据配置的规则,想请求分摊到服务层。服务层也是我们的业务核心层,这里可能也会有一些RPC、MQ的一些调用等等;
3)再经过缓存层;
4)最后持久化数据;
5)返回数据给客户端。

要达到高并发,我们需要负载均衡、服务层、缓存层、持久层都是高可用、高性能的。

甚至在第5步,我们也可以通过压缩静态文件、HTTP2推送静态文件、CDN来做优化,这里的每一层我们都可以写几本书来谈优化。

本文主要讨论服务层这一块,即图红线圈出来的那部分。不再考虑讲述数据库、缓存相关的影响。

高中的知识告诉我们,这个叫控制变量法。

iQ3qaqy.png!mobile

6、再谈并发

6.1 网络编程模型的演变历史:

jeaAbqj.png!mobile

并发问题一直是服务端编程中的重点和难点问题,为了优系统的并发量,从最初的Fork进程开始,到进程池/线程池,再到epoll事件驱动(Nginx、node.js反人类回调),再到协程。

从上图中可以很明显的看出,整个演变的过程,就是对CPU有效性能压榨的过程。

什么?不明显?

6.2 那我们再谈谈上下文切换:

在谈论上下文切换之前,我们再明确两个名词的概念:

1)并行:两个事件同一时刻完成;
2)并发:两个事件在同一时间段内交替发生,从宏观上看,两个事件都发生了。

线程是操作系统调度的最小单位,进程是资源分配的最小单位。由于CPU是串行的,因此对于单核CPU来说,同一时刻一定是只有一个线程在占用CPU资源的。因此,Linux作为一个多任务(进程)系统,会频繁的发生进程/线程切换。

在每个任务运行前,CPU都需要知道从哪里加载,从哪里运行,这些信息保存在CPU寄存器和操作系统的程序计数器里面,这两样东西就叫做CPU上下文。

进程是由内核来管理和调度的,进程的切换只能发生在内核态,因此虚拟内存、栈、全局变量等用户空间的资源,以及内核堆栈、寄存器等内核空间的状态,就叫做进程上下文。

前面说过,线程是操作系统调度的最小单位。同时线程会共享父进程的虚拟内存和全局变量等资源,因此父进程的资源加上线上自己的私有数据就叫做线程的上下文。

对于线程的上下文切换来说,如果是同一进程的线程,因为有资源共享,所以会比多进程间的切换消耗更少的资源。

现在就更容易解释了,进程和线程的切换,会产生CPU上下文切换和进程/线程上下文的切换。而这些上下文切换,都是会消耗额外的CPU的资源的。

6.3 进一步谈谈协程的上下文切换:

那么协程就不需要上下文切换了吗?需要,但是不会产生 CPU上下文切换和进程/线程上下文的切换,因为这些切换都是在同一个线程中,即用户态中的切换,你甚至可以简单的理解为,协程上下文之间的切换,就是移动了一下你程序里面的指针,CPU资源依旧属于当前线程。

需要深刻理解的,可以再深入看看Go的 GMP模型

最终的效果就是协程进一步压榨了CPU的有效利用率。

7、回到开始的那个问题

这个时候就可能有人会说,我看系统监控的时候,内存和网络都很正常,但是CPU利用率却跑满了这是为什么?

注意本篇文章在谈到CPU利用率的时候,一定会加上有效两字作为定语,CPU利用率跑满,很多时候其实是做了很多低效的计算。

以"世界上最好的语言"为例。

典型PHP-FPM的CGI模式,每一个HTTP请求:

1)都会读取框架的数百个php文件;
2)都会重新建立/释放一遍MYSQL/REIDS/MQ连接;
3)都会重新动态解释编译执行PHP文件;
4)都会在不同的php-fpm进程直接不停的切换切换再切换。

php的这种CGI运行模式,根本上就决定了它在高并发上的灾难性表现。

找到问题,往往比解决问题更难。当我们理解了高并发之后,我们会发现高并发和高性能并不是编程语言限制了你,限制你的只是你的思想。

找到问题,解决问题!当我们能有效压榨CPU性能之后,能达到什么样的效果?

下面我们看看 php+ Swoole 的HTTP服务与Java高性能的异步框架 Netty 的HTTP服务之间的性能差异对比。 

NnUFrub.jpg!mobile

8、性能对比前的准备

swoole是什么:

Swoole是一个为PHP用C和C++编写的基于事件的高性能异步&协程并行网络通信引擎。链接: https://www.swoole.com/

Netty是什么:

Netty是著名的Java高性能网络通信开源框架。 Netty提供异步的、事件驱动的网络应用程序框架和工具,用以快速开发高性能、高可靠性的网络服务器和客户端程序。官网: https://netty.io/ 、在线源码: http://docs.52im.net/extend/docs/src/netty4_1/

单机能够达到的最大TCP连接数是多少?

回忆一下计算机网络的相关知识,在传输层,每个TCP连接建立之前都会进行三次握手。

每个TCP连接由:

1)本地ip
2)本地端口;
3)远端ip;
4)远端端口。

四个属性标识组成。

TCP协议报文头如下(图片来自维基百科):

EjyYJj7.png!mobile

题外话:如果对TCP协议脸生的话,权威《 TCP/IP详解 》走起。。。

如上图所示:

1)本地端口由16位组成,因此本地端口的最多数量为 2^16 = 65535个;
2)远端端口由16位组成,因此远端端口的最多数量为 2^16 = 65535个。

同时,在linux底层的网络编程模型中,每个TCP连接,操作系统都会维护一个File descriptor(fd)文件来与之对应,而fd的数量限制,可以由ulimit -n 命令查看和修改,测试之前我们可以执行命令: ulimit -n 65536修改这个限制为65535。

因此,在不考虑硬件资源限制的情况下:

1)本地的最大HTTP连接数为: 本地最大端口数65535 * 本地ip数1 = 65535 个;
2)远端的最大HTTP连接数为:远端最大端口数65535 * 远端(客户端)ip数+∞ = 无限制~~ 。

PS:实际上操作系统会有一些保留端口占用,因此本地的连接数实际也是达不到理论值的。想要深入地探讨这个问题,本系列的第一篇文章可以详读一下:《 高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少 》。

9、性能对比

9.1 测试准备

硬件资源:各一台docker容器、1G内存+2核CPU,如图所示: 

eqQjAv.png!mobile

docker-compose编排如下:

# java8
version: "2.2"
services:
  java8:
    container_name: "java8"
    hostname: "java8"
    image: "java:8"
    volumes:
      - /home/cg/MyApp:/MyApp
    ports:
      - "5555:8080"
    environment:
      - TZ=Asia/Shanghai
    working_dir: /MyApp
    cpus: 2
    cpuset: 0,1
 
    mem_limit: 1024m
    memswap_limit: 1024m
    mem_reservation: 1024m
    tty: true
 
# php7-sw
version: "2.2"
services:
  php7-sw:
    container_name: "php7-sw"
    hostname: "php7-sw"
    image: "mileschou/swoole:7.1"
    volumes:
      - /home/cg/MyApp:/MyApp
    ports:
      - "5551:8080"
    environment:
      - TZ=Asia/Shanghai
    working_dir: /MyApp
    cpus: 2
    cpuset: 0,1
 
    mem_limit: 1024m
    memswap_limit: 1024m
    mem_reservation: 1024m
    tty: true

php代码:

<?php
useSwoole\Server;
useSwoole\Http\Response;
$http= newswoole_http_server("0.0.0.0", 8080);
$http->set([
    'worker_num'=> 2
]);
$http->on("request", function($request, Response $response) {
    //go(function () use ($response) {
        // Swoole\Coroutine::sleep(0.01);
        $response->end('Hello World');
    //});
});
 
$http->on("start", function(Server $server) {
    go(function() use($server) {
        echo"server listen on 0.0.0.0:8080 \n";
    });
});
$http->start();

Java关键代码:源代码来自  https://github.com/netty/netty

public static void main(String[] args) throws Exception {
    // Configure SSL.
    finalSslContext sslCtx;
    if(SSL) {
        SelfSignedCertificate ssc = newSelfSignedCertificate();
        sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();
    } else{
        sslCtx = null;
    }
 
    // Configure the server.
    EventLoopGroup bossGroup = newNioEventLoopGroup(2);
    EventLoopGroup workerGroup = newNioEventLoopGroup();
    try{
        ServerBootstrap b = newServerBootstrap();
        b.option(ChannelOption.SO_BACKLOG, 1024);
        b.group(bossGroup, workerGroup)
         .channel(NioServerSocketChannel.class)
         .handler(newLoggingHandler(LogLevel.INFO))
         .childHandler(newHttpHelloWorldServerInitializer(sslCtx));
 
        Channel ch = b.bind(PORT).sync().channel();
 
        System.err.println("Open your web browser and navigate to "+
                (SSL? "https": "http") + "://127.0.0.1:"+ PORT + '/');
 
        ch.closeFuture().sync();
    } finally{
        bossGroup.shutdownGracefully();
        workerGroup.shutdownGracefully();
    }
}

因为我只给了两个核心的CPU资源,所以两个服务均只开启连个work进程即可。5551端口表示PHP服务、5555端口表示Java服务。

9.2 压测工具结果对比:ApacheBench (ab)

ab命令:docker run --rm jordi/ab -k -c 1000 -n 1000000 http://10.234.3.32:5555/

在并发1000进行100万次Http请求的基准测试中的结果如下。

Java + netty 压测结果: 

mYJRfen.png!mobile

PHP + swoole 压测结果:

ZJ7V3em.png!mobile

zUZzUj7.png!mobile

ps:上图选择的是三次压测下的最佳结果。

总的来说,性能差异并不大,PHP+swoole的服务甚至比Java+netty的服务还要稍微好一点,特别是在内存占用方面,java用了600MB、php只用了30MB。

这能说明什么呢?

没有IO阻塞操作,不会发生协程切换。这个仅仅只能说明 多线程+epoll的模式下,有效的压榨CPU性能,你甚至用PHP都能写出高并发和高性能的服务。

10、性能对比——见证奇迹的时刻

上面代码其实并没有展现出协程的优秀性能,因为整个请求没有阻塞操作,但往往我们的应用会伴随着例如 文档读取、DB连接/查询 等各种阻塞操作,下面我们看看加上阻塞操作后,压测结果如何。

Java和PHP代码中,我都分别加上 sleep(0.01) //秒 的代码,模拟0.01秒的系统调用阻塞。

代码就不再重复贴上来了。

带IO阻塞操作的 Java + netty 压测结果:

E7FJJn7.png!mobile

大概10分钟才能跑完所有压测。。。

带IO阻塞操作的 PHP + swoole 压测结果: 

uEBbiub.png!mobile

AzYFzun.png!mobile

从结果中可以看出:基于协程的php+ swoole服务比 Java + netty服务的QPS高了6倍。

当然,这两个测试代码都是官方demo中的源代码,肯定还有很多可以优化的配置,优化之后,结果肯定也会好很多。

可以再思考下:为什么官方默认线程/进程数量不设置的更多一点呢?

进程/线程数量可不是越多越好哦,前面我们已经讨论过了,在进程/线程切换的时候,会产生额外的CPU资源花销,特别是在用户态和内核态之间切换的时候!

11、本文小结

对于上面两节的压测结果来说,我并不是针对Java,我想说的是:只要明白了高并发的核心是什么,找到这个目标,无论用什么编程语言,只要针对CPU利用率做有效的优化(连接池、守护进程、多线程、协程、select轮询、epoll事件驱动),你也能搭建出一个高并发和高性能的系统。

所以,你现在明白了,什么是高并发了吗?

思路永远比结果重要!

附录:更多精华系列文章

TCP/IP详解第11章·UDP:用户数据报协议

TCP/IP详解第17章·TCP:传输控制协议

TCP/IP详解第18章·TCP连接的建立与终止

TCP/IP详解第21章·TCP的超时与重传

不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)

不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)

不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

不为人知的网络编程(四):深入研究分析TCP的异常关闭

不为人知的网络编程(五):UDP的连接性和负载均衡

不为人知的网络编程(六):深入地理解UDP协议并用好它

不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

不为人知的网络编程(八):从数据传输层深度解密HTTP

不为人知的网络编程(九):理论联系实际,全方位深入理解DNS

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

网络编程懒人入门(十一):一文读懂什么是IPv6

网络编程懒人入门(十二):快速读懂Http/3协议,一篇就够!

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?

脑残式网络编程入门(三):HTTP协议必知必会的一些知识

脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(Server Push)

脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?

脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?

脑残式网络编程入门(七):面视必备,史上最通俗计算机网络分层详解

脑残式网络编程入门(八):你真的了解127.0.0.1和0.0.0.0的区别?

脑残式网络编程入门(九):面试必考,史上最通俗大小端字节序详解

IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)

IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)

IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁

IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史

IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史

IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术

IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”

IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲

IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”

IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲

IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!

IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注:

qMBV7rr.png!mobile

▲ 本文在公众号上的链接是: 点此进入 ,原文链接是: http://www.52im.net/thread-3120-1-1.html


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK