当前位置：首页 > news >正文

奥鹏作业代做靠谱的网站/百度移动端点赞排名软件

news 2025/7/3 13:35:56

奥鹏作业代做靠谱的网站,百度移动端点赞排名软件,里水九江网站建设,用wordpress做购物网站简洁 MMO 架构 ┌───────────────┐ ┌───────────────┐┌────────────────────►│ SLB ├────────────────►│ Login ││ http └────────…

简洁 MMO 架构

                                ┌───────────────┐                 ┌───────────────┐┌────────────────────►│      SLB      ├────────────────►│     Login     ││         http        └───────────────┘                 └───────────────┘│││││││││││
┌─────────┴─────┐   tcp         ┌───────────────┐                 ┌───────────────┐
│    Client     ├──────────────►│      SLB      ├────────────────►│    Gateway    │
└───────────────┘               └───────────────┘                 └───────┬───────┘││┌────────────────────────┼──────────────────────┐│                        │                      ││                        │                      │▼                        ▼                      ▼┌---------------┐       ┌───────────────┐      ┌---------------┐│    Lobby      │       │     Game      │      │      Mng      │└---------------┘       └───────────────┘      └---------------┘┌──────────────────────────────────────────────────────────────┐│                                                              ││ db     ┌───────────────┐            ┌───────────────┐        ││        │    DBProxy    │            │     Redis     │        ││        └───────────────┘    OR      └───────────────┘        ││        ┌───────────────┐            ┌───────────────┐        ││        │     MySQL     │            │     MySQL     │        ││        └───────────────┘            └───────────────┘        ││                                                              │└──────────────────────────────────────────────────────────────┘

服务	功能	其他说明
Login	鉴权服	经典的 MMO 一般会有 Lobby 服，主要是获取角色列表、创角、删角等操作。可以合并到 Login 服
Gateway	会话服
Game	功能服、场景服
Mng	服务治理服	列出来方便理解，本质上这个 Mng 存在单点、热点问题，因此实操会优化为 Redis 代替
DBProxy	DB 代理服	经典的 MMO 一般会有 DBProxy + MySQL ，可选方案 Redis + MySQL 。见后详细说明

服务治理服 Mng

如上所述，该服会被优化掉，但是功能、概念依旧存在，包括：

服务依赖
服务发现
负载均衡
场景地图管理

服务依赖

服务依赖，不是功能，是项目服务间依赖关系的一种客观事实描述

这样每个进程可以对自己感兴趣的服务，收集服务信息

服务发现

每个服务进程对 Redis 定期续租
- 如 Key 为 Servers ，类型 HMAP
- 定期 HSET serverID serverInfo （ serverInfo 至少包含 serverType serverActiveTime ）
每个进程定期拉取 Servers ，对感兴趣的服务信息和本地做 diff，进而知道服务新增或失效

负载均衡

以场景分配举例：

Gateway 会定期拉取 Servers
每个服务会给依赖它的服务发送实时 serverInfo 变化信息
- 如， Game 的 serverInfo 还会包含场景个数信息

这样 Gateway 本地就可以实时缓存 Game 的 serverInfo

对于玩家登录， Gateway 就可以本地负载均衡 Game

场景地图管理

比如无缝大世界，会做地图切块，让不同 Game 只负责该切块上的玩家

也有游戏所有场景单 Game 上构建，内存支撑不了，也会做不同 Game 负责一组场景的需求

有这类功能的， Mng 都必须存在，做场景分配的调度中心

登出

角色信息记录最后登出的 LastGame 和 LogoutTime
本地角色对象，删除
本场景对象内人数为 0 后
- 单人本，删除
- 多人本，可延迟几分钟删除

本地 DB 数据缓存

通常直接做进 DB 层，让开发者无感知

但是架构设计者需要知晓

因为，分配服务时，需要命中带缓存的那个服务

登录分配 Game

Game 会缓存角色数据、场景数据，玩家下次登录在缓存有效的情况下，应该进原来的 Game

那么分配 Game 逻辑就变为：

尝试获取角色最后登出的 LastGame 和 LogoutTime
如果 LastGame!=0 ，且 LogoutTime 小于本地缓存时间间隔（最好再大些），检查最后登出的 LastGame 是有效的：
- 不需要做什么
否则，Gateway 随机分配 NewGame ，让 LastGame = NewGame
登录 LastGame

以上逻辑一般基本够用，如果是超级严谨派程序员，还是能看出上面算法存在的 1 个并发登录问题：

当同账号多端互踢：

端1 登录，连接了 Gateway1 发送登录请求。这时 Gateway1 执行登录逻辑
端2 登录，连接了 Gateway2 发送登录请求。这时 Gateway2 也并发的执行登录逻辑
虽然 2 次登录 Login 分配了 2 个 token
但是 2 个 Gateway 并发登录，没有跨进程锁登录过程，是有概率让 2 个 token 都能验证通过
进而造成同个角色被分配了 2 个 Game 的 bug （2 个 Game 上都有该角色数据缓存，可能会出现回档问题）

因此更严谨的分配 Game 逻辑就变成：

尝试获取角色最后登出的 LastGame 和 LogoutTime
如果 LastGame!=0 ，且 LogoutTime 小于本地缓存时间间隔（最好再大些），检查最后登出的 LastGame 是有效的：
- 不需要做什么
否则，Gateway 随机分配 NewGame ，让 LastGame = NewGame
Redis GetSet LastGame:RoleID LastGame ，抢占 LastGame ，返回实际 LastGame2
登录 LastGame2

即增加了Redis GetSet 抢占 LastGame ，返回实际 LastGame2，保证不管任何并发情况，分配的 Game 是一样的

Game 的登录逻辑中：

发现有旧的 Gateway ，发送踢旧 Gateway 角色，这样多并发下，最终只会有 1 个 Client 到 Gateway 到 Game 的链路
创建角色对象。未有缓存数据，则 db 加载数据
续租 LastGame:RoleID ，这样断线重连等， Gateway 按上述算法，会登录当前 Game
创建或进入场景
- 如果是单人本、或者公共地图，一般只要带上 MapCfgID 即可
- 如果是多人本，一般需要带上 MapInstanceID

创建或进入场景

Game 上本地 SceneMng 创建或获取场景对象
- 创建的，还需要尝试从 DB 种加载场景玩法数据
- 如果是多人本，发现 MapInstanceID 不存在，则给对应 Gateway 发送踢人（切换场景和登录并发时会出现）
如果是多人本，广播 Gateway 信息 MapInstanceID - Game
玩家加入场景，触发 AOI 消息等等