本文根据DBAplus社群第88期线上分享整理而成，文末还有书送哦~

讲师介绍

韩伟

腾讯科技互娱研发部架构师

主题简介：

1、游戏类业务的通信模型分析

2、游戏类业务的数据处理流程分析

3、?一般缓存系统的特点在游戏中的问题

4、现代游戏服务器端的几个典型运行时架构

一、背景

在中国的互联网诸多业务领域中，游戏一直是充当“现金牛”而存在的。常言道“隔行如隔山”，游戏领域和互联网其他领域确实可以说是不同的两个行业。但是，在游戏服务器端开发领域中的很多重要问题，并没有被明确的分辨出其特异性，从而得到专门的对待。

我们不管是在业界开源领域，还是内部分享中，很少会有专门针对游戏业务特征进行专门设计的组件、类库或者框架。我们从游戏的客户端方面来看，一款专业的游戏客户端引擎，已经是游戏开发的标配，比如最早的Flash Builder，到后期的易云网络-X，Unity，易云网络；但是服务器端，我们几乎找不到同样重量级的产品。

在游戏服务器端开发所有要面对的问题中，有两个是最核心和最普遍的：一是和客户端的通讯；二是游戏登录用户的数据处理。对于和客户端通讯的这个问题，大量的游戏开发者会使用“通用”的开源组件，比如易云网络、易云网络、Jetty、Node.js等等通信或RPC框架。虽然针对游戏，还是要做大量的改造，但一般都有很多现成的代码可供修改。

在一般的互联网应用中，我们一般认为服务都是通过请求-响应的方式来完成的。而在游戏业务领域中，请求-响应可以看成是一种类型的通讯方式，但还有另外一种重要的通讯模型，就是“数据同步”方式：游戏中某个角色的HP、位置坐标改变了，需要在客户端和服务器之间、客户端和客户端之间同步。这造成了一般情况下通信协议的大量增加。

对于第二个问题，不管是易云网络还是MySQL，或者是Redis，都不能完全满足游戏开发者的需求。很多团队尝试过各种组合和修改，试图创造出利用现有开源软件，建设既能迎合灵活的需求变化，又具备高延迟和高可用的数据处理系统，但最后这些努力基本上都很难圆满成功。因为我们在游戏服务器端代码中，还是充斥着大量的内存、缓存管理，数据同步、落地等等代码。而且每个游戏都要重新去写一遍这些类似的功能，不能不说是一种浪费。

如果我们要想出一种能满足“游戏”这个业务领域的数据系统设计，那么就一定要搞清楚为什么在如此之多的开源项目和游戏团队中，没能实现完美契合的原因。

二、电子商务/一般互联网业务的C-S通讯流程

基于Web Service类型的通讯模型，现在基本已经成为互联网开源组件的标准。由此而诞生的RESTful API，或者各种RPC模型，其实都是基于这样的客观事实：

用户主动请求，服务器产生回应。典型的就是网页的点击、表单的提交。

主动通知的消息，仅仅是提示用户发起查询请求。比如在APP按钮上的小红点，消息页的数字提示等等，这些主动通知都是为了通知用户去刷新页面。

三、游戏类业务的通信模型分析

游戏中的通信，一般和操作有关。这些操作一般分为两类：

这两者的最大区别，就是UI面板类操作一般无需让其他玩家看见。而战斗场景操作则需要广播给所有玩家看到。

在第二种情况下，一般就不是客户端主动发起，而是服务器端直接推送实际数据，然后客户端直接显示这些数据。这个模式和简单的“推送”还不一样，而应该更进一步，是一种从服务器端发起的，向客户端“同步”数据的请求。

因此，一个好的游戏服务器端框架，应该是能同时支持请求-响应模型和“推送同步”模型的。

四、电子商务/一般互联网类业务的数据处理流程

易云网络、Redis、MySQL在一般互联网业务中的应用非常广泛。而且基本上能很好的应对各种常见的应用场景，包括类似BBS的社区、新闻门户、电子商务类系统。