2024年C C++最新深入浅出node(1)，2024年最新新鲜出炉的C C++面试真题集锦我给你们整理出来了-CSDN博客

本文链接：https://blog.csdn.net/2401_84978573/article/details/138787310

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

可以看到由于web服务器的无状态性，只需要通过前端的负载均衡器可以导向任意一个进程，因此运行架构相对简单，而且很少需要分布式开发。

而游戏服务器是蜘蛛网式的架构，每个进程都有各自的职责，这些进程的交织在一起共同完成一件任务。

因此游戏服务器是一个标准的分布式开发架构。

2.2 分布式开发与难点

几乎在很多书、演讲和文章中都可以看到这样的观点：分布式开发是很难的。如果把所有这些难点都合起来也许有好几本书，我们今天着重看来一下游戏服务器开发的难点吧。

多进程（服务器）的管理，重量级的架构影响开发效率

通常的游戏服务器要由很多进程共同去完成任务。当这些进程交织在一起的时候，多进程的管理并不那么容易。

如果没有统一的抽象与管理，光把这些开发环境的进程启动起来就是非常复杂的工作，进程的启动与重启就将严重影响开发效率。
重量级的进程消耗大量的机器资源，普通的开发机支撑不了那么多进程，可能一个人的开发环境就需要多台机器。
多进程间的调试并不容易，我们发现一个bug就要跨好几个进程。

rpc调用

rpc调用的解决方案已经有n多年的历史了，但rpc在分布式开发效率上仍然没有明显提升。

以当前最流行的开发框架thrift为例，它在调用代码前需要经过以下步骤：

Writing a .thrift file
Generate Thrift file to source code

thrift --gen (language) (Thrift filename)

Copy the source to application

如果发生接口改动，我们又需要重新修改描述文件，重新生成stub接口。对于接口不稳定的开发环境，这种方式对开发效率影响较大。

要想让rpc调用的开发达到最简，不需生成stub接口，无需描述文件，我们需要一种很巧妙的方法。

分布式事务、异步化操作

尽管我们尽量把逻辑放在一个进程里处理，但分布式事务仍然是不可避免的。两阶段提交的代码，异步化的操作在普通的开发语言里并不是容易的事。

但我们会发现用了node.js之后，它的编程模式里天生就是这种模式，两阶段提交、异步化操作这些看似复杂的工作里在node.js只是一个正常的异步执行流程。

负载均衡，高可用

由于游戏服务器的有状态性，很多请求需要通过特定的路由规则导到某台服务器；对于有些无状态的服务器，我们则可以把请求路由到负载最低的服务器。

通常对于无状态的服务器，高可用是比较好做的。对于有状态的服务器，要做高可用会非常困难，但也不是完全没有办法，常见的两招：

将状态引出到外存，例如redis，这样进程本身就可以无状态了。但由于所有的操作都通过redis可能带来性能损耗，有些场景是不能应会这些损耗的。
通过进程互备，将状态通过日志等方式同步到另一进程，但这可能存在着瞬间数据丢失的问题，这种数据丢失在一些应用场景可能毫无问题，但在另外一些应用场景可能引起严重的数据不一致。

有状态的高可用并不是那么好实现的，pomelo将在0.5版本提供高可用的实现机制，引入zookeeper和redis可以解决一些进程（如master）的高可用问题，但真正复杂的应用场景的逻辑只能由应用自己处理。

2.3 Node.js的引入

为什么会在这里谈node.js的引入？因为在讲了这么多分布式开发的难点之后，引入node.js实在是太自然了。它解决了分布式开发的很多问题。

天生的分布式, node.js之所以叫node就是因为它天生就是做多进程开发的，多个节点(node)互相通讯交织在一起组成的分布式系统是node天生就应该这么干的。例如前面提到的分布式事务、异步化操作在node.js里只是个正常的流程。
网络io与可伸缩性的优势。游戏是非常io密集型的应用，采用node.js是最合适的，可达到最好的可伸缩性。
轻量级, 轻量级的进程带来的开发效率的优势在开发的时候异常明显。
语言优势。使用javascript开发可以实现快速迭代，客户端html 5使用javascript，甚至在unity3d，cocos2d-x这样的游戏平台上也可以使用javascript, 可实现最大限度的代码共用。

三、pomelo架构分析

pomelo框架在最初设计的时候只为了一个目标：为基于长连接的分布式游戏服务器架构提供基础设施。框架的内容在逐渐扩展，但最核心的框架只为了干以下三件事：

服务器（进程）的抽象与扩展

在web应用中，每个服务器是无状态、对等的，开发者无需通过框架或容器来管理服务器。但游戏应用不同，游戏可能需要包含多种不同类型的服务器，每类服务器在数量上也可能有不同的需求。这就需要框架对服务器进行抽象和解耦，支持服务器类型和数量上的扩展。

客户端的请求、响应、广播

客户端的请求、响应与web应用是类似的，但框架是基于长连接的，实现模式与http请求有一定差别。广播是游戏服务器最频繁的操作，需要方便的API，并且在性能上达到极致。

服务器间的通讯、调用

尽管框架尽量避免跨进程调用，但进程间的通讯是不可避免的，因此需要一个方便好用的RPC框架来支撑。

下面分别对这三个目标进行详细的分析：

服务器（进程）的抽象与扩展介绍

服务器的抽象与分类

该架构把游戏服务器做了抽象，抽象成为两类：前端服务器和后端服务器，如图：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

前端服务器(frontend)的职责：

负责承载客户端请求的连接
维护session信息
把请求转发到后端
把后端需要广播的消息发到前端

后端服务器(backend)的职责：

处理业务逻辑，包括RPC和前端请求的逻辑
把消息推送回前端

服务器的鸭子类型

动态语言的面向对象有个基本概念叫鸭子类型服务器的抽象也同样可以比喻为鸭子，服务器的对外接口只有两类，一类是接收客户端的请求，叫做handler，一类是接收RPC请求，叫做remote， handler和remote的行为决定了服务器长什么样子。因此我们只要定义好handler和remote两类的行为，就可以确定这个服务器的类型。

服务器抽象的实现

利用目录结构与服务器对应的形式，可以快速实现服务器的抽象。

以下是示例图：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图中的connector, connector, gate三个目录代表三类服务器类型，每个目录下的handler与remote决定了这个服务器的行为（对外接口）。开发者只要往handler与remote目录填代码，就可以实现某一类的服务器。这让服务器实现起来非常方便。让服务器动起来，只要填一份配置文件servers.json就可以让服务器快速动起来。配置文件和对应的进行架构如下所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

客户端请求与响应、广播的抽象介绍

所有的web应用框架都实现了请求与响应的抽象。尽管游戏应用是基于长连接的，但请求与响应的抽象跟web应用很类似。下图的代码是一个request请求示例：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

请求的api与web应用的ajax请求很象，基于Convention over configuration的原则，请求不需要任何配置。如下图所示，请求的route字符串：chat.chatHandler.send，它可以将请求分发到chat服务器上chatHandler文件定义的send方法。

Pomelo的框架里还实现了request的filter机制，广播/组播机制，详细介绍见pomelo框架参考。

服务器间RPC调用的抽象介绍

架构中各服务器之间的通讯主要是通过底层RPC框架来完成的，该RPC框架主要解决了进程间消息的路由和RPC底层通讯协议的选择两个问题。服务器间的RPC调用也实现了零配置。实例如下图所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

上图的remote目录里定义了一个RPC接口： chatRemote.js，它的接口定义如下：

chatRemote.kick = function(uid, player, cb) {
}

其它服务器（RPC客户端）只要通过以下接口就可以实现RPC调用：

app.rpc.chat.chatRemote.kick(session, uid, player, function(data){
});

这个调用会根据特定的路由规则转发到特定的服务器。（如场景服务的请求会根据玩家在哪个场景直接转发到对应的server）。

rpc的使用远比其它rpc框架简单好多，因为我们无需写任何配置文件，也无需生成stub。因为我们服务器抽象的实现的方式，使得rpc客户端可以在应用启动时扫描服务器目录自动生成stub对象。

完成了以上三个目标，一个实时的分布式应用框架的轮廓就搭出来了，剩下的工作是往上添肉，这是我们后续文章里的内容。

四、从游戏框架到实时应用框架

当我们分析完pomelo框架的设计目标时，我们发现核心框架的这件事情竟然与游戏没有任何关系。这是一个通用的实时分布式应用开发框架。官网上的聊天服务器demo就是一个实时应用。

事实上pomelo已经被应用在很多非游戏领域。网易的消息推送平台是基于pomelo开发的，它承担了网易移动端和web端的消息推送，目前已经上线使用。

整个开源社区没有与pomelo定位相同的实时应用框架。目前在开源社区最流行的实时应用框架当数meteor，它与pomelo有着截然不同的设计目标。我们来比较一下这两个框架的区别。

以下是meteor给出的定义：

Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you’re an expert developer or just getting started.

可以用以下两点概括：