如何提高服务器并发处理能力

说明

以下内容为入门级介绍，意在对老技术作较全的总结而不是较深的研究。主要参考《构建高性能Web站点》一书。

什么是服务器并发处理能力

一台服务器在单位时间里能处理的请求越多，服务器的能力越高，也就是服务器并发处理能力越强

有什么方法衡量服务器并发处理能力

1. 吞吐率

吞吐率，单位时间里服务器处理的最大请求数，单位req/s

从服务器角度，实际并发用户数的可以理解为服务器当前维护的代表不同用户的文件描述符总数，也就是并发连接数。服务器一般会限制同时服务的最多用户数，比如apache的MaxClents参数。

这里再深入一下，对于服务器来说，服务器希望支持高吞吐率，对于用户来说，用户只希望等待最少的时间，显然，双方不能满足，所以双方利益的平衡点，就是我们希望的最大并发用户数。

1. 压力测试

有一个原理一定要先搞清楚，假如100个用户同时向服务器分别进行10个请求，与1个用户向服务器连续进行1000次请求，对服务器的压力是一样吗？实际上是不一样的，因对每一个用户，连续发送请求实际上是指发送一个请求并接收到响应数据后再发送下一个请求。这样对于1个用户向服务器连续进行1000次请求, 任何时刻服务器的网卡接收缓冲区中只有1个请求，而对于100个用户同时向服务器分别进行10个请求，服务器的网卡接收缓冲区最多有100个等待处理的请求，显然这时的服务器压力更大。

压力测试前提考虑的条件

并发用户数: 指在某一时刻同时向服务器发送请求的用户总数(HttpWatch)

• 总请求数

• 请求资源描述

• 请求等待时间(用户等待时间)

• 用户平均请求的等待时间

• 服务器平均请求处理的时间

• 硬件环境

用户平均请求等待时间主要用于衡量服务器在一定并发用户数下，单个用户的服务质量；而服务器平均请求处理时间就是吞吐率的倒数，一般来说，用户平均请求等待时间 = 服务器平均请求处理时间 * 并发用户数

怎么提高服务器的并发处理能力

1. 提高CPU并发计算能力

• 多进程 & 多线程
• 减少进程切换
• 减少使用不必要的锁
• 考虑进程优先级
• 考虑系统负载
• 考虑CPU使用率

2. 考虑减少内存分配和释放

3. 考虑使用持久连接

4. 改进I/O 模型

• 1. DMA技术
• 1. 异步I/O
• 1. I/O多路复用
• 1. Sendfile
• 1. 内存映射
• 1. 直接I/O

5.改进服务器并发策略

• 一个进程处理一个连接，非阻塞I/O
• 一个线程处理一个连接，非阻塞IO
• 一个进程处理多个连接，异步I/O
• 一个线程处理多个连接，异步IO

6. 改进硬件环境

游戏服务器架构通识

前言

我们将从游戏服务器发展的简单历程出发，鸟瞰一下目前大多数的游戏服务器架构。· 这里尽可能的避免陷入细节的技术问题，而是从技术进化的结果状态，反推原始问题是什么。希望能通过这个过程，解释清楚游戏服务器是在解决什么问题，痛点到底在哪里。

一、早期网游服务器。

• 蛮荒时期的游戏服务器框架我们一笔带过，那时的游戏服务器和一个小Web服务没有区别。·
• 蛮荒时代的服务器只负责存储玩家账号、数据、转发场景内其他玩家的行为。很多移动、使用技能等关键逻辑在服务器上根本没有。随意就能用变速齿轮改变游戏速度。· 从传奇的时代开始，游戏服务器就不再是简单的上传存档、下载存档、访问页面而已。游戏服务器内部出现了游戏逻辑，既能用于同步每个玩家看到的世界，又能让逻辑与客户端分离，避免早期的网络游戏那种毫无防范的逻辑体系（对外挂防御能力为0）。· 这种架构奇怪的地方是处理网络连接数据传输的压力和逻辑处理的压力在同一个服务器上（存储模块可能也在同一个进程），就算逻辑处理压力为0，承载人数也高不到哪去。

二、早期游戏服务器的改进版本

当开发者们有了初步经验以后，新作品的开发，自然而然的过渡到了如下的形式：

游戏逻辑服务依然是在一台服务器上，单进程（逻辑处理本身肯定是在一个线程中，可以有子线程负责内网通信）。但是我们自然的想到，存储负载和网络连接负载可以从逻辑服上拆出来。· 由于连接服务器本身没有时序性，很容易做分布式的（其实大部分游戏还是只用一个连接服），存储服务不要求高实时性，高峰期存盘间隔可以稍长一些，不会对游戏服造成影响。

三、成熟形态的服务器框架（这节是重点）

1、逻辑服务器的负载均摊方法一：按照功能划分多个服务器进程

• 难点在逻辑的设计上，要像做手术一样把本来是一体的功能切开，并抽象出若干个API来保持联系（服务器之间是TCP连接）。
• 在分解时，要找联系相对最薄弱的环节入手，比如场景和场景之间分开、单独抽出聊天服务、组队服务、好友服务。· 无论如何分解，最终结果只能是有限个服务。而且分解的越细，开发难度就越大。因为跨服务器逻辑是把简单的同步逻辑变成了异步Callback逻辑，而且容易出现时序问题等不易测试的问题。
• 单个场景服务几乎是无法分解的。分解单个场景难度巨大以至于出现了BigWorld引擎来专门的解决场景分割问题，后面会谈到。
• 这种成熟形态的游戏服务器已经能满足现实中99%的频繁交互类网游需求，是大型MMO端游、页游的主流形式。

附：开房间式的网络游戏· 开房间式的网络游戏也是游戏的一个重要分支，英雄联盟、DOTA、很多手游例如皇室战争、王者荣耀等等。· 这种游戏房间之间几乎没有交互，只有大厅内有交互，可以理解为原始形态的游戏服务器的平行扩展。· 房间式游戏扩展难度较小，只是需要根据玩家数量动态扩展游戏房间的数量、服务器数量。很像网站的架构。· 这种游戏架构最最适合放在云平台上，设计合理的话，它可能遇到的问题和大型网站几乎一模一样。不需要特别的讨论它们。· 只是，毕竟游戏不都是开房间的玩法。·

小结：游戏服务器框架特点

· 1、真正的数据都在内存中，数据库性能不那么重要· 注：很多大型游戏采用了共享内存，避免宕机时损失过大。· 2、单CPU性能比CPU数量重要的多。· 3、目前有很多游戏，特别是手游，使用Redis读写代替内存读写，甚至也有用Mongo的。· 4、开新服、旧区合服的情况，非常适合云平台。

先进服务器框架

1、BigWorld。理念过于超前，把并发性做到极致，开发友好度弱到极致，已废。2、Skynet。本人强烈推荐，谁学谁知道，除了必须要用lua语言，没有什么缺点。

参考Blog：
1.https://www.cnblogs.com/zengjin93/p/5569556.html
2.作者：Meta42
连接：https://www.zhihu.com/question/23508968/answer/211501928
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。