分布式游戏服务器全服匹配玩法设计

背景

如今的社交类游戏，大多采用分布式服务器架构，也就是说所有区服的数据存储在一个集群中，玩家可以无阻碍交互，一同游玩。

再谈游戏中的匹配，多数匹配玩法都属于在线匹配，属于非常实时的一种匹配，匹配节点会根据玩家的操作（开始匹配，报名，匹配完成等）动态插入删除。这也就保证了匹配池的节点数量会维持在可控的范围内。

而如果游戏中有海量的小团体, 要求每隔一定周期为全服所有团体分配一个实力相近的对手, 应该如何高效实现这个需求呢？

需求分析

根据需求描述，结合现有的团体功能在服务器中的架构，系统所需要完成的功能如下图所示：

简而言之，我们需要通过一定的规则把游戏中的所有团体两两匹配在一起，然后逐一通知自己的匹配结果。

对于海量数据节点的匹配，很显然内存中已经无法存下所有节点了。最直观的解决方案就是将所有匹配节点的关键信息存储在DB中，到达匹配开始时间后再每次获取一批匹配节点分批进行匹配。

确定好大致方向，接下来需要解决如下五个问题：

如何维护匹配节点
如何分批匹配
在何处进行匹配
匹配规则的具体实现
如何分发匹配信息

数据维护

匹配节点的维护很简单：因为匹配的范围是全服所有团体，很容易想到匹配节点的生命周期和对应团体是绑定在一起的，即

团体达到玩法开启等级插入一条匹配节点记录；
团体解散删除这条记录；
节点中关键字段变化更新记录；

值得一提的是，匹配节点的更新可以通过增加脏标记的方式，控制频率固定时间间隔更新，这样可以避免其他业务代码影响到匹配系统的整体压力。

分批匹配

分批匹配，最重要的就是解决分批获取表格中全量数据问题，常见的做法有两种：

1. 遍历表格，按固定顺序固定数量获取数据依次匹配。

2.自定义哈希规则为每个团体分配一个额外的值随机的key，对这个key建立索引，最后每批选择其中一部分key进行拉取。

表格遍历是最简单有效的方案，可以完成基本需求，但会面临两个小问题：由于是固定顺序固定数量下的分批匹配，每轮匹配的分组大致是固定的，这也就意味着极限情况下，可能出现多轮匹配到相同对手的情况。

另外，表格遍历数据返回的方式是单向通知，而不是主动拉取的。考虑到匹配是一个非常占用CPU时间的操作，在匹配节点非常多的情况下，前一批节点还在占用CPU进行匹配中而后面几批节点已经返回，从而导致缓冲区占满而丢失部分消息。

第二种方法实际上就是通过part key进行批量拉取，先不谈BatchGetByPartKey这个操作本身很低效，虽然解决了遍历表格出现的两种问题，但极度依赖哈希算法，随着节点数量的增加，key的数量也需要随之增加，也就是说哈希算法需要做到随着节点数量的增加动态变更，流程代码实现也将变得复杂，整体很不灵活而且低效。

那么有没有一种分批拉取策略既可以结合两者优势呢，又可以避免两者已存在的坑呢？

仔细斟酌，实际上我们需要的是一种可以随机顺序主动拉取的遍历表格方式。如果可以打乱整张匹配节点表格，再进行遍历拉取一切就很好办了，但如果想在内存中存下整张表格随机后的顺序则需要耗费大量的空间。考虑一个折中的方案: 将整张表格的所有节点分成固定数量的X组，再将这些分组采用O(N)洗牌算法打乱, 最后每批拉取Y组进行匹配。这样，在内存中我们仅需存下分组的顺序以及当前拉取的进度即可。

有一点值得注意的是，因为采用的是设置下标的分批拉取，在拉取期间如果发生了节点删除，拉取后续节点可能出现遗漏的情况；故如果在匹配期间发生了团体解散，我们需要记录并延迟删除。

至于具体的实现：我们可以给所有匹配节点分配一个额外的值相同的key，在每组数据拉取的时候采用TCAPLUS_API_GET_BY_PARTKEY_REQ接口，根据组号设置offset和limit，本批所有分组拉取完成则开始匹配。

整个分批匹配的流程如下：

系统容灾

在何处匹配，本质上就是解决匹配系统的容灾问题。

选择在何处匹配，最简单直观的方案，就是为其增加一个负责匹配的单点进程，伴随而来的问题也非常明显：代码工程量加大，其次添加单点进程并不符合分布式系统功能设计的基本思想，增加单点匹配进程的方案先被否决。

那么我们能否用现有的团体服务器groupSvr进行匹配呢？团体服务器本身是支持动态增删的，且服务器本身存在机器故障,进程宕机的可能性，选择某个固定的团体服务器进程进行匹配并不合理。

那么如何动态选择某个团体服务器进行匹配呢？这里我们可以采用多个进程抢占乐观锁的方式争夺匹配权，保证同一时间只有其中一个进程进行全服匹配；同时需要增加超时处理机制，当某个进程正在匹配中，发生了宕机导致匹配超时，会有其他进程继续抢占乐观锁将匹配流程进行下去。进程抢占匹配权流程如下：

由于匹配进程存在中途宕机的可能，分批匹配的过程中我们需要在<分组,随机>步骤和<匹配>步骤完成后及时将分组顺序，匹配进度，上批匹配完成时间等信息存入DB，保证异常情况匹配流程能够顺利进行下去。

规则实现

接下来需要思考的是匹配系统最核心的部分，如何在每批匹配节点中，撮合尽可能多的实力相近的对手。

首先简单转化/翻译一下策划定义的匹配规则：

匹配节点包含多个字段，当两个节点相同字段差值在某指定范围内的话，则定义为实力相近的对手，允许匹配在一起。
当一轮匹配执行完后，如果仍剩下未匹配的节点，则对差值范围进行扩大，继续下一轮匹配。
多轮阔段匹配后仍有剩余节点，将剩余节点再按综合能力值排序，进行保底匹配。

如何实现上述规则呢? 我们仍然从最简单最直观的方案出发:

每轮遍历所有节点，当发现两个节点可匹配的话，则将这两个节点从匹配池中删除;
对于多轮匹配，它们的区别仅仅是字段的差值范围不同(保底匹配的差值范围为无限大);

这样, 我们可以将一批节点进行匹配的流程抽象如下:

struct MatchNode{};
struct MatchGap;class CGroupMatchProcessor
{public://开始本批匹配void StartMatch(){std::sort(nodeList.begin(), nodeList.end());//step1MatchProcess(MatchConfig::GetBaseGap());//step2for(int i = 0; i < MatchConfig::GetExpandCnt(); ++i){MatchProcess(MatchConfig::GetExpandGap(i));}//step3MatchProcess(MatchConfig::GetFinalGap());}private:void OnMatchDone(const MatchNode& stNode1, const MatchNode& stNode2);bool IsMatch(const MatchNode& stNode1, const MatchNode& stNode2, const MatchGap& stGap);//进行一轮匹配void MatchProcess(const MatchGap& stGap){for(size_t i = 0; i < nodeList.size(); ++i){for(size_t j = i + 1; j< nodeList.size(); ++j){if(IsMatch(nodeList[i], nodeList[j], stGap)){OnMatchDone(nodeList[i], nodeList[j]);OnMatchDone(nodeList[j], nodeList[i]);nodeList.erase(nodeList.begin() + j);nodeList.erase(nodeList.begin() + i);i -= 1;break;}}}}private:std::vector<MatchNode> nodeList;
};

匹配过程的核心代码为MatchProcess函数，整体实现比较简单。但测试过几组数据之后，发现这个算法并不能完成"撮合尽可能多的实力相近的对手"这一要求，而且因为存在频繁的内存移动，匹配效率也令人堪忧。

无法完成要求的例子见下图, 其中虚线代表两节点允许相互匹配，实线代表已完成的匹配：

图中的例子，最理想的情况是能撮合出三组匹配，但由于<节点1,节点2>, <节点3,节点4>已完成匹配并删除，所以导致最终只撮合了其中两组。究其原因，还是因为算法的本质仅仅是一种非常"短视"的不考虑全局其他节点的贪心选择。

那么有没有可以解决这一问题并且效率也足够高的算法呢？

大学学过图论的同学可能听说过，匈牙利数学家曾经提出过一种在多项式时间内求解任务分配问题的组合优化算法，该算法可以解决二分图的最大匹配问题，这不刚好就是我们需要的吗，于是参考算法思路改进后代码如下：

class CGroupMatchProcessor
{public:void StartMatch();private:void OnMatchDone(const MatchNode& stNode1, const MatchNode& stNode2);bool IsMatch(const MatchNode& stNode1, const MatchNode& stNode2, const MatchGap& stGap);//构建邻接表void BuildGraph(const MatchGap& stGap){edgeList.resize(nodeList.size());edgeList.clear();for(size_t i = 0; i < nodeList.size(); ++i){for(size_t j = i + 1; j< nodeList.size(); ++j){if(IsMatch(nodeList[i], nodeList[j], stGap)){edgeList[i].push_back(j);edgeList[j].push_back(i);}}}}//寻找增广路bool FindPath(int u){std::vector<int>& edgeTo = edgeList[u];for(size_t i = 0; i<edgeTo.size(); ++i){int v = edgeTo[i];//避免重复经过不可能找到增广路的节点if(visitNodeSet.find(v) == visitNodeSet.end()){visitNodeSet.insert(v);if(matchPeer[v] == -1 || FindPath(matchPeer[v])){//建立匹配关系matchPeer[v] = u;matchPeer[u] = v;return true;}}}return false;}void Hungary(){matchPeer.resize(nodeList.size());//初始化为-1memset(matchPeer.data(), -1, matchPeer.size() * sizeof(int));//针对每个未匹配的节点, 寻找一次增广路for(size_t i = 0; i < nodeList.size(); ++i){visitNodeSet.clear();if(matchPeer[i] == -1){FindPath(i);}}}//进行一轮匹配void MatchProcess(const MatchGap& stGap){BuildGraph(stGap);Hangury();//删除已完成匹配的节点std::vector<MatchNode> remainList;remainList.clear();for(size_t i = 0; i < nodeList.size(); ++i){if(matchPeer[i] == -1){remainList.push_back(nodeList[i]);}else{OnMatchDone(nodeList[i], nodeList[matchPeer[i]]);}}nodeList.swap(remainList);}private:std::vector<MatchNode> nodeList;std::vector<int>  matchPeer;std::set<int> visitNodeSet;std::vector< std::vector<int> > edgeList;
};

如果说遍历删除属于一种短视的贪心算法，那么匈牙利算法则是一种更有远见的可以补救短视的贪心算法。

在介绍匈牙利算法之前，首先介绍两个重要的名词：

交错路：从一个未匹配点出发，依次遍历未匹配边、匹配边、未匹配边，这样交替下去，这条路径称为交错路。
增广路：从一个未匹配点出发，依次遍历未匹配边、匹配边、未匹配边，这样交替下去，如果最后一个点是未匹配点，这条路径称为增广路。换句话说，起点和终点都为未匹配点的交错路为增广路。

匈牙利算法的核心思想就是为图中每个未匹配节点寻找一次增广路，然后再对已有匹配关系进行替换。我们仍以上一张图举例：

<节点1,节点2>, <节点3,节点4>这两组节点已经建立匹配关系，节点5开始寻找增广路。
(5)首先找到(4)，而(4)已有匹配关系，然后尝试为(4)的匹配节点(3)寻找新的匹配节点，从而让（5）和（4）匹配。
(3)找到新的可匹配节点(2)，但(2)已有匹配关系，为(2)的匹配节点(1)寻找新的匹配节点，从而让（3）和（2）匹配。
(1)找到可匹配但是未被匹配的(6)，至此，增广路寻找完成。
最后，更换匹配关系，即上图中的实线变为虚线，虚线变为实线，完成三组匹配。

对于匹配规则的更高效实现，可以自行了解一下Hopcroft-Carp算法，本质是可以同时寻找出多条增广路，在这里不展开讲。

匹配分发

匹配的最终目标，就是需要告知每个团体自己本轮的匹配结果，将匹配结果写入团体数据中。为了保证数据一致性，写某团体数据必须在指定的为其分配的团体服务器上进行。当一个团体服务器进程分配满后，收到一条未在内存中团体的写请求，这时进程会触发LRU，淘汰掉其中一个并将本团体导入内存执行写操作。

考虑到全服匹配会为全服所有团体分配一个对手，这样每个团体都需要在匹配期间写一次匹配信息，而内存中只会存部分活跃团体，当大量非活跃团体匹配完成需要写匹配信息时，会造成进程的频繁LRU影响性能。

为了避免这种性能消耗，我们在匹配分发时采用写增量事件机制(eventlog)。即匹配完成，为对应团体写一份增量事件，写入成功，通知对应团体拉取增量事件，接下来可能会出现两种情况：

团体在内存中，直接拉取增量事件；
团体不在内存中，忽略本次通知，等待团体导入内存再拉取增量事件；

经过改动后，成功分散了匹配分发过程中的系统压力，同时匹配完成->收到匹配信息不再具有连续性(可能时间差非常大)，因此我们需要在增量事件中记录一个匹配完成时间，当匹配完成时间属于本轮匹配才允许记录匹配信息，否则丢弃。

至此, 全服匹配的所有设计细节已经介绍完毕。

结语

受限于随机分组分批进行匹配，每批最后完成的几组匹配存在不确定性。

对于整体匹配度要求更高的匹配，可以根据匹配节点综合能力值在DB中构建一张持久化排行榜，在每期开始匹配之前生成一份排行榜快照，最后再根据快照顺序依次分批拉取分批匹配。另外，针对多期匹配节点相同的情况，我们可以将前几期的对手信息记录在匹配节点中，在构建邻接表的时候进行过滤，从而避免重复匹配到相同节点。

分布式游戏服务器全服匹配玩法设计相关推荐

Unity3damp;amp;C#分布式游戏服务器ET框架介绍-组件式设计
前几天写了<开源分享 Unity3d客户端与C#分布式服务端游戏框架>,受到很多人关注,QQ群几天就加了80多个人.开源这个框架的主要目的也是分享自己设计ET的一些想法,所以我准备写一系列 ...
rp虚拟服务器,怀旧服之见闻——RP服务器的戏精玩法
原标题:怀旧服之见闻--RP服务器的戏精玩法首先,我们来看一张发生在RP服务器-闪光镇的酒吧的游戏截图. 闪金镇酒吧坐着吹牛这就是魔兽戏精玩法,虽然没有毛装备玩法和刷刷刷玩法主流,但多多少少算是一 ...
龙神契约为什么显示服务器错误,龙神契约连服BOSS玩法介绍
龙神契约游戏中连服战场的游戏中的一个非常重要的部分,而其中的boss尤为重要.击杀boss玩家可以获得非常多的奖励,一般一下稀有材料都是可以获得的,所以打boss是重中之重的.今天小编简单给大家介绍一 ...
高性能分布式游戏服务器框架,浅谈Go语言自研的分布式游戏服务器架构
引言:使用Go语言开发游戏已经有5年了,做了三款上线手游,一直采用的都是我们自研的分布式游戏服务器架构.最近我们想把它分享一下,总结一下这几年的经验. 一. 架构图分布式游戏服务器架构图 1. CD ...
分布式游戏服务器通用架构的设计
对于游戏服务器架构,不同项目除了游戏玩法.匹配规则大不相同外,其余部分如日志系统.TCP 连接管理,玩家数据存储,数据库连接与访问等大同小异.游戏服务器架构中高并发.可扩展是主要的设计点.本 Chat ...
游戏全区全服和分区分服 QQ斗地主的设计
游戏全区全服和分区分服 QQ斗地主的设计 https://cloud.tencent.com/community/article/164816001481011910?fromSource=gwzc ...
Wind：一款面向云的分布式游戏服务器引擎
Wind是一款面向云的高性能.高效率以及高扩展性的大型分布式游戏服务器引擎.Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率,针对一些对性能有要求的游戏业务功能(如实时战 ...
还在担心快应用没流量？全场景新玩法来袭！
2019年3月20日,TEF·2019快应用开发者大会在北京圆满收官落下帷幕.本次大会宣布中国移动终端公司.海信手机加入快应用生态平台,并介绍了快应用生态潜力.快游戏布局.智能场景新玩法.第三方服务战 ...
Wind分布式游戏服务器引擎的实现
Wind Wind是一款面向云的高性能.高效率以及高扩展性的大型分布式游戏服务器引擎.Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率,针对一些对性能有要求的游戏业务功能 ...

分布式游戏服务器全服匹配玩法设计

背景

需求分析

数据维护

分批匹配

系统容灾

规则实现

匹配分发

结语

分布式游戏服务器全服匹配玩法设计相关推荐

最新文章

热门文章