常用于游戏服务端中的分布式登录网关如何动态扩容的疑问？

zhllxt 2018-01-16 10:12:09



常见的游戏服务端架构如上图所示，Client首先连接LoginServer，然后由LoginServer找出一个空闲的Gate交给Client，然后Client再重新连接到该Gate，进而实现与GameServer的通信。这样的话，Gate和GameServer都可以动态扩容。

我的疑问是：LoginServer如何扩容呢？我查过一些开源的游戏引擎，虽然说是Gate可以动态扩容，但我看代码，完全没有看出来是怎么扩容的，还是普通的tcp socket连接到LoginServer？









...全文
683 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
oyljerry 2018-01-18
  • 打赏
  • 举报
 回复
一个是DNS做负载，可以把请求转到不同的LoginServer，其次还有硬件负载均衡设备，它们处理并发能力很强，可以把请求转给不同的LoginServer。
danscort2000 2018-01-18
  • 打赏
  • 举报
 回复
引用 8 楼 zhllxt 的回复:
[quote=引用 6 楼 danscort2000 的回复:] 这个设计有问题, 你这个设计里,最前台的居然是LoginServer LoginServer不应该负责用户的登录, 这是最关键的 而只应该负责根据用户的ip给出负载最小的Gate 登录应该由game server前端或者独立的登录服务器来负责
这个我懂的，只是把网上的图直接拿来用了。我明白“应该负责根据用户的ip给出负载最小的Gate”。我只是拿这个做个比方，其实我困惑的还是100亿个Client所能访问到的第一层到底是不是只能是一个Server，到底能不能做到多个Server负载均衡这样子。 [/quote] 第一层一般都使用DNS来做负载均衡 , 此外还可以配合客户端进行特定随机,例如同时部署 dns1.xxx.com dns2.xxx.com ......客户端按照当前时间尾数奇偶等来分别使用dns1或者dns2....进行分流 总之第一层都是一个短连接,不会执行有阻塞之类操作 ,比如CDN就是这么干的.
满衣兄 2018-01-17
  • 打赏
  • 举报
 回复
引用 2 楼 zhllxt 的回复:
[quote=引用 1 楼 yfqvip 的回复:] 多个loginserver通过dns智能解析就可以了，loginserver是短连接，所以不需要很多，两三个应该就够了
dns 解析的核心原理我不是太清楚，基本原理能明白，毕竟编程了这么多年。 loginserver是短连接，所以不需要很多，两三个应该就够了。这个也能理解。 但是我只是考虑一种场景，不用智能DNS的话，该怎么从技术层面解决：假定loginserver的每秒并发有1000万，那么一个loginserver肯定不行，需要多个loginserver，但是Client只会连接一个IP(或网址也行），那么这个loginserver如何动态扩容。 智能DNS我搜索了一下，大致明白他的意思了。但是我想的是，如果用智能DNS解析的话，其实这个智能DNS解析服务器就相当于我的loginserver了，如果每秒并发有1000万的话，这个1000万实际上到了这个DNS解析服务器的并发了，那么这个DNS解析服务器又如何从技术层面解决这个问题呢？ [/quote] 并发一千万肯定需要专门的技术和硬件策略应对。但你假设的这个前提不成立，如果你假设一千亿的并发那谁也没办法做。还是根据实际情况考虑，不要想着设计一个系统多大的并发都能适应，总有个范围的。
zhllxt 2018-01-17
  • 打赏
  • 举报
 回复
引用 6 楼 danscort2000 的回复:
这个设计有问题, 你这个设计里,最前台的居然是LoginServer LoginServer不应该负责用户的登录, 这是最关键的 而只应该负责根据用户的ip给出负载最小的Gate 登录应该由game server前端或者独立的登录服务器来负责
这个我懂的，只是把网上的图直接拿来用了。我明白“应该负责根据用户的ip给出负载最小的Gate”。我只是拿这个做个比方，其实我困惑的还是100亿个Client所能访问到的第一层到底是不是只能是一个Server，到底能不能做到多个Server负载均衡这样子。
zhllxt 2018-01-17
  • 打赏
  • 举报
 回复
如果100亿个Client并发访问到的第一层只能是一个Server的话（即使这个Server什么都不做，仅仅是做一下简单的查找空闲的二层Server，100亿并发他也是吃不消的），那么这个问题就是无解的了，我只是想知道市面上或者比如大公司BAT这些他们会不会有解决办法？
danscort2000 2018-01-17
  • 打赏
  • 举报
 回复
另一个方式就是把 用户登录功能 做最前台 在用户登录后,用一个特殊的数字串, 去请求独立调度服务器给出 最合适的 game gate 也就是分两步走 总之 必须把Login 和 请求服务器gate ip port两个服务分别独立出来
danscort2000 2018-01-17
  • 打赏
  • 举报
 回复
这个设计有问题, 你这个设计里,最前台的居然是LoginServer LoginServer不应该负责用户的登录, 这是最关键的 而只应该负责根据用户的ip给出负载最小的Gate 登录应该由game server前端或者独立的登录服务器来负责
zhllxt 2018-01-17
  • 打赏
  • 举报
 回复
引用 4 楼 yfqvip 的回复:
并发一千万肯定需要专门的技术和硬件策略应对。但你假设的这个前提不成立，如果你假设一千亿的并发那谁也没办法做。还是根据实际情况考虑，不要想着设计一个系统多大的并发都能适应，总有个范围的。
感谢老表，你的意思是说“假设有一千亿的并发”，在现今技术下，谁也解决不了，这就是个无解的题目。是这个意思吗？我只是想知道到底有没有这种可能：比如说大公司BAT他们有没有这种技术，无论多少Client并发，Client连接的IP就只有一个，他们就是能做到Client直连的第一层（也就是我上面所说的loginserver，第二层用多机负载均衡这个不考虑）就能多机负载均衡？
zhllxt 2018-01-16
  • 打赏
  • 举报
 回复
引用 1 楼 yfqvip 的回复:
多个loginserver通过dns智能解析就可以了，loginserver是短连接，所以不需要很多，两三个应该就够了
dns 解析的核心原理我不是太清楚，基本原理能明白，毕竟编程了这么多年。 loginserver是短连接，所以不需要很多，两三个应该就够了。这个也能理解。 但是我只是考虑一种场景，不用智能DNS的话，该怎么从技术层面解决：假定loginserver的每秒并发有1000万，那么一个loginserver肯定不行，需要多个loginserver，但是Client只会连接一个IP(或网址也行），那么这个loginserver如何动态扩容。 智能DNS我搜索了一下，大致明白他的意思了。但是我想的是，如果用智能DNS解析的话，其实这个智能DNS解析服务器就相当于我的loginserver了，如果每秒并发有1000万的话，这个1000万实际上到了这个DNS解析服务器的并发了，那么这个DNS解析服务器又如何从技术层面解决这个问题呢？
满衣兄 2018-01-16
  • 打赏
  • 举报
 回复
多个loginserver通过dns智能解析就可以了，loginserver是短连接，所以不需要很多，两三个应该就够了
smwhotjay 2018-01-16
  • 打赏
  • 举报
 回复
多个loginserver又会引出同时登录的问题啥的。真要扩展多个也不难。难在不出bug的架构
开涛高可用高并发-亿级流量核心技术
第1部分概述 1 1 交易型系统设计的一些原则 2 1.1 高并发原则 3 1.1.1 无状态 3 1.1.2 拆分 3 1.1.3 服务化 4 1.1.4 消息队列 4 1.1.5 数据异构 6 1.1.6 缓存银弹 7 1.1.7 并发化 9 1.2 高可用原则 10 1.2.1 降级 10 1.2.2 限流 11 1.2.3 切流量 12 1.2.4 可回滚 12 1.3 业务设计原则 12 1.3.1 防重设计 13 1.3.2 幂等设计 13 1.3.3 流程可定义 13 1.3.4 状态与状态机 13 1.3.5 后台系统操作可反馈 14 1.3.6 后台系统审批化 14 1.3.7 文档和注释 14 1.3.8 备份 14 1.4 总结 14 第2部分高可用 17 2 负载均衡与反向代理 18 2.1 upstream配置 20 2.2 负载均衡算法 21 2.3 失败重试 23 2.4 健康检查 24 2.4.1 TCP心跳检查 24 2.4.2 HTTP心跳检查 25 2.5 其他配置 25 2.5.1 域名上游服务器 25 2.5.2 备份上游服务器 26 2.5.3 不可用上游服务器 26 2.6 长连接 26 2.7 HTTP反向代理示例 29 2.8 HTTP动态负载均衡 30 2.8.1 Consul+Consul-template 31 2.8.2 Consul+OpenResty 35 2.9 Nginx四层负载均衡 39 2.9.1 静态负载均衡 39 2.9.2 动态负载均衡 41 参考资料 42 3 隔离术 43 3.1 线程隔离 43 3.2 进程隔离 45 3.3 集群隔离 45 3.4 机房隔离 46 3.5 读写隔离 47 3.6 动静隔离 48 3.7 爬虫隔离 49 3.8 热点隔离 50 3.9 资源隔离 50 3.10 使用Hystrix实现隔离 51 3.10.1 Hystrix简介 51 3.10.2 隔离示例 52 3.11 基于Servlet 3实现请求隔离 56 3.11.1 请求解析和业务处理线程池分离 57 3.11.2 业务线程池隔离 58 3.11.3 业务线程池监控/运维/降级 58 3.11.4 如何使用Servlet 3异步化 59 3.11.5 一些Servlet 3异步化压测数据 64 4 限流详解 66 4.1 限流算法 67 4.1.1 令牌桶算法 67 4.1.2 漏桶算法 68 4.2 应用级限流 69 4.2.1 限流总并发/连接/请求数 69 4.2.2 限流总资源数 70 4.2.3 限流某个接口的总并发/请求数 70 4.2.4 限流某个接口的时间窗请求数 70 4.2.5 平滑限流某个接口的请求数 71 4.3 分布式限流 75 4.3.1 Redis+Lua实现 76 4.3.2 Nginx+Lua实现 77 4.4 接入层限流 78 4.4.1 ngx_http_limit_conn_module 78 4.4.2 ngx_http_limit_req_module 80 4.4.3 lua-resty-limit-traffic 88 4.5 节流 90 4.5.1 throttleFirst/throttleLast 90 4.5.2 throttleWithTimeout 91 参考资料 92 5 降级特技 93 5.1 降级预案 93 5.2 自动开关降级 95 5.2.1 超时降级 95 5.2.2 统计失败次数降级 95 5.2.3 故障降级 95 5.2.4 限流降级 95 5.3 人工开关降级 96 5.4 读服务降级 96 5.5 写服务降级 97 5.6 多级降级 98 5.7 配置中心 100 5.7.1 应用层API封装 100 5.7.2 配置文件实现开关配置 101 5.7.3 配置中心实现开关配置 102 5.8 使用Hystrix实现降级 106 5.9 使用Hystrix实现熔断 108 5.9.1 熔断机制实现 108 5.9.2 配置示例 112 5.9.3 采样统计 113 6 超时与重试机制 117 6.1 简介 117 6.2 代理层超时与重试 119 6.2.1 Nginx 119 6.2.2 Twemproxy 126 6.3 Web容器超时 127 6.4 中间件客户端超时与重试 127 6.5 数据库客户端超时 131 6.6 NoSQL客户端超时 134 6.7 业务超时 135 6.8 前端Ajax超时 135 6.9 总结 136 6.10 参考资料 137 7 回滚机制 139 7.1 事务回滚 139 7.2 代码库回滚 140 7.3 部署版本回滚 141 7.4 数据版本回滚 142 7.5 静态资源版本回滚 143 8 压测与预案 145 8.1 系统压测 145 8.1.1 线下压测 146 8.1.2 线上压测 146 8.2 系统优化和容灾 147 8.3 应急预案 148 第3部分高并发 153 9 应用级缓存 154 9.1 缓存简介 154 9.2 缓存命中率 155 9.3 缓存回收策略 155 9.3.1 基于空间 155 9.3.2 基于容量 155 9.3.3 基于时间 155 9.3.4 基于Java对象引用 156 9.3.5 回收算法 156 9.4 Java缓存类型 156 9.4.1 堆缓存 158 9.4.2 堆外缓存 162 9.4.3 磁盘缓存 162 9.4.4 分布式缓存 164 9.4.5 多级缓存 166 9.5 应用级缓存示例 167 9.5.1 多级缓存API封装 167 9.5.2 NULL Cache 170 9.5.3 强制获取最新数据 170 9.5.4 失败统计 171 9.5.5 延迟报警 171 9.6 缓存使用模式实践 172 9.6.1 Cache-Aside 173 9.6.2 Cache-As-SoR 174 9.6.3 Read-Through 174 9.6.4 Write-Through 176 9.6.5 Write-Behind 177 9.6.6 Copy Pattern 181 9.7 性能测试 181 9.8 参考资料 182 10 HTTP缓存 183 10.1 简介 183 10.2 HTTP缓存 184 10.2.1 Last-Modified 184 10.2.2 ETag 190 10.2.3 总结 192 10.3 HttpClient客户端缓存 192 10.3.1 主流程 195 10.3.2 清除无效缓存 195 10.3.3 查找缓存 196 10.3.4 缓存未命中 198 10.3.5 缓存命中 198 10.3.6 缓存内容陈旧需重新验证 202 10.3.7 缓存内容无效需重新执行请求 205 10.3.8 缓存响应 206 10.3.9 缓存头总结 207 10.4 Nginx HTTP缓存设置 208 10.4.1 expires 208 10.4.2 if-modified-since 209 10.4.3 nginx proxy_pass 209 10.5 Nginx代理层缓存 212 10.5.1 Nginx代理层缓存配置 212 10.5.2 清理缓存 215 10.6 一些经验 216 参考资料 217 11 多级缓存 218 11.1 多级缓存介绍 218 11.2 如何缓存数据 220 11.2.1 过期与不过期 220 11.2.2 维度化缓存与增量缓存 221 11.2.3 大Value缓存 221 11.2.4 热点缓存 221 11.3 分布式缓存与应用负载均衡 222 11.3.1 缓存分布式 222 11.3.2 应用负载均衡 222 11.4 热点数据与更新缓存 223 11.4.1 单机全量缓存+主从 223 11.4.2 分布式缓存+应用本地热点 224 11.5 更新缓存与原子性 225 11.6 缓存崩溃与快速修复 226 11.6.1 取模 226 11.6.2 一致性哈希 226 11.6.3 快速恢复 226 12 连接池线程池详解 227 12.1 数据库连接池 227 12.1.1 DBCP连接池配置 228 12.1.2 DBCP配置建议 233 12.1.3 数据库驱动超时实现 234 12.1.4 连接池使用的一些建议 235 12.2 HttpClient连接池 236 12.2.1 HttpClient 4.5.2配置 236 12.2.2 HttpClient连接池源码分析 240 12.2.3 HttpClient 4.2.3配置 241 12.2.4 问题示例 243 12.3 线程池 244 12.3.1 Java线程池 245 12.3.2 Tomcat线程池配置 248 13 异步并发实战 250 13.1 同步阻塞调用 251 13.2 异步Future 252 13.3 异步Callback 253 13.4 异步编排CompletableFuture 254 13.5 异步Web服务实现 257 13.6 请求缓存 259 13.7 请求合并 261 14 如何扩容 266 14.1 单体应用垂直扩容 267 14.2 单体应用水平扩容 267 14.3 应用拆分 268 14.4 数据库拆分 271 14.5 数据库分库分表示例 275 14.5.1 应用层还是中间件层 275 14.5.2 分库分表策略 277 14.5.3 使用sharding-jdbc分库分表 279 14.5.4 sharding-jdbc分库分表配置 279 14.5.5 使用sharding-jdbc读写分离 283 14.6 数据异构 284 14.6.1 查询维度异构 284 14.6.2 聚合数据异构 285 14.7 任务系统扩容 285 14.7.1 简单任务 285 14.7.2 分布式任务 287 14.7.3 Elastic-Job简介 287 14.7.4 Elastic-Job-Lite功能与架构 287 14.7.5 Elastic-Job-Lite示例 288 15 队列术 295 15.1 应用场景 295 15.2 缓冲队列 296 15.3 任务队列 297 15.4 消息队列 297 15.5 请求队列 299 15.6 数据总线队列 300 15.7 混合队列 301 15.8 其他队列 302 15.9 Disruptor+Redis队列 303 15.9.1 简介 303 15.9.2 XML配置 304 15.9.3 EventWorker 305 15.9.4 EventPublishThread 307 15.9.5 EventHandler 308 15.9.6 EventQueue 308 15.10 下单系统水平可扩展架构 311 15.10.1 下单服务 313 15.10.2 同步Worker 313 15.11 基于Canal实现数据异构 314 15.11.1 Mysql主从复制 315 15.11.2 Canal简介 316 15.11.3 Canal示例 318 第4部分案例 323 16 构建需求响应式亿级商品详情页 324 16.1 商品详情页是什么 324 16.2 商品详情页前端结构 325 16.3 我们的性能数据 327 16.4 单品页流量特点 327 16.5 单品页技术架构发展 327 16.5.1 架构1.0 328 16.5.2 架构2.0 328 16.5.3 架构3.0 330 16.6 详情页架构设计原则 332 16.6.1 数据闭环 332 16.6.2 数据维度化 333 16.6.3 拆分系统 334 16.6.4 Worker无状态化+任务化 334 16.6.5 异步化+并发化 335 16.6.6 多级缓存化 335 16.6.7 动态化 336 16.6.8 弹性化 336 16.6.9 降级开关 336 16.6.10 多机房多活 337 16.6.11 多种压测方案 338 16.7 遇到的一些坑和问题 339 16.7.1 SSD性能差 339 16.7.2 键值存储选型压测 340 16.7.3 数据量大时JIMDB同步不动 342 16.7.4 切换主从 342 16.7.5 分片配置 342 16.7.6 模板元数据存储HTML 342 16.7.7 库存接口访问量600w/分钟 343 16.7.8 微信接口调用量暴增 344 16.7.9 开启Nginx Proxy Cache性能不升反降 344 16.7.10 配送至读服务因依赖太多，响应时间偏慢 344 16.7.11 网络抖动时，返回502错误 346 16.7.12 机器流量太大 346 16.8 其他 347 17 京东商品详情页服务闭环实践 348 17.1 为什么需要统一服务 348 17.2 整体架构 349 17.3 一些架构思路和总结 350 17.3.1 两种读服务架构模式 351 17.3.2 本地缓存 352 17.3.3 多级缓存 353 17.3.4 统一入口/服务闭环 354 17.4 引入Nginx接入层 354 17.4.1 数据校验/过滤逻辑前置 354 17.4.2 缓存前置 355 17.4.3 业务逻辑前置 355 17.4.4 降级开关前置 355 17.4.5 AB测试 356 17.4.6 灰度发布/流量切换 356 17.4.7 监控服务质量 356 17.4.8 限流 356 17.5 前端业务逻辑后置 356 17.6 前端接口服务端聚合 357 17.7 服务隔离 359 18 使用OpenResty开发高性能Web应用 360 18.1 OpenResty简介 361 18.1.1 Nginx优点 361 18.1.2 Lua的优点 361 18.1.3 什么是ngx_lua 361 18.1.4 开发环境 362 18.1.5 OpenResty生态 362 18.1.6 场景 362 18.2 基于OpenResty的常用架构模式 363 18.2.1 负载均衡 363 18.2.2 单机闭环 364 18.2.3 分布式闭环 367 18.2.4 接入网关 368 18.2.5 核心接入Nginx功能 369 18.2.6 业务Nginx功能 369 18.2.7 Web应用 370 18.3 如何使用OpenResty开发Web应用 371 18.3.1 项目搭建 371 18.3.2 启停脚本 372 18.3.3 配置文件 372 18.3.4 nginx.conf配置文件 373 18.3.5 Nginx项目配置文件 373 18.3.6 业务代码 374 18.3.7 模板 374 18.3.8 公共Lua库 375 18.3.9 功能开发 375 18.4 基于OpenResty的常用功能总结 375 18.5 一些问题 376 19 应用数据静态化架构高性能单页Web应用 377 19.1 整体架构 378 19.1.1 CMS系统 379 19.1.2 前端展示系统 380 19.1.3 控制系统 380 19.2 数据和模板动态化 381 19.3 多版本机制 381 19.4 异常问题 382 20 使用OpenResty开发Web服务 383 20.1 架构 383 20.2 单DB架构 384 20.2.1 DB+Cache/数据库读写分离架构 384 20.2.2 OpenResty+Local Redis+Mysql集群架构 385 20.2.3 OpenResty+Redis集群+Mysql集群架构 386 20.3 实现 387 20.3.1 后台逻辑 388 20.3.2 前台逻辑 388 20.3.3 项目搭建 389 20.3.4 Redis+Twemproxy配置 389 20.3.5 Mysql+Atlas配置 390 20.3.6 Java+Tomcat安装 394 20.3.7 Java+Tomcat逻辑开发 395 20.3.8 Nginx+Lua逻辑开发 401 21 使用OpenResty开发商品详情页 405 21.1 技术选型 407 21.2 核心流程 408 21.3 项目搭建 408 21.4 数据存储实现 410 21.4.1 商品基本信息SSDB集群配置 410 21.4.2 商品介绍SSDB集群配置 413 21.4.3 其他信息Redis配置 417 21.4.4 集群测试 418 21.4.5 Twemproxy配置 419 21.5 动态服务实现 422 21.5.1 项目搭建 422 21.5.2 项目依赖 422 21.5.3 核心代码 423 21.5.4 基本信息服务 424 21.5.5 商品介绍服务 426 21.5.6 其他信息服务 426 21.5.7 辅助工具 427 21.5.8 web.xml配置 428 21.5.9 打WAR包 428 21.5.10 配置Tomcat 428 21.5.11 测试 429 21.5.12 Nginx配置 429 21.5.13 绑定hosts测试 430 21.6 前端展示实现 430 21.6.1 基础组件 430 21.6.2 商品介绍 432 21.6.4 前端展示 434 21.6.5 测试 442
java 分布式游戏服务器框架，集群游戏服务器框架，游戏服务器网关框架 ioGame 网络游戏服务器框架
ioGame 是一个由java语言编写的网络游戏服务器框架。支持 websocket、tcp ，适用于全球同服、回合制游戏、策略游戏、即时战斗等游戏服务器的开发。具有高性能、稳定、易用易扩展、超好编程体验等特点。可做为 H5、手游、端游的 java 游戏服务器。ioGame 是轻量级的网络游戏服务器框架，在使用 ioGame 时，只需一个依赖即可获得整个框架，而无需在安装其他服务，如： Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf协议编译工具 ... ...等。
GFS分布式文件系统
引言： GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。
浅谈游戏服务端开发-架构
网络游戏程序分为客户端和服务端。客户端负责图形渲染、交互和一些简单校验处理，服务端负责业务逻辑处理、数据存储。 我们开发一个游戏demo，服务端程序可以是一个单线程的服务进程。它包含网络通信、业务逻辑处理、数据存储。服务端打开网络端口监听，客户端通过网络连接到服务端，服务端接入连接。客户端发包给服务端，服务端接收到包后进行解析，调用对应的处理程序进行处理，处理程序处理成功后，修改数据并保存下来，再把响应包封包发送给客户端。 简单的数据存储可以保存在文件里。当用户量逐渐增加，数据存储的性能、完整和安全
游戏服务器引擎的设计（一）介绍游戏服务器部署框架
服务器的架构，根据游戏类型不同大多有：账号服务器、全局服务器、网关服务器、场景服务器、中心服务器、存储服务器，配合其他的服务器(比如日志服，监控服等)。传统的游戏是单服模式，现在也有很多的是分布式模式。 单服模式：就是一组服务器为一个服，与其服务器之间不互通的。比如传统的网游(魔兽世界)，客户端看到的服务器列表里每个服都是一组单独的服务器，之间数据不共享。 分布式模式：理论上可以无限扩容，可能有万人同服的情况。但实际上是有上限的。这个要根据服务器的逻辑设计，和硬件决定的。分布式的思想就是服务只是一个概念
网络编程

18,356

社区成员

64,214

社区内容

发帖
与我相关
我的任务
社区描述
VC/MFC 网络编程
c++c语言开发语言 技术论坛（原bbs）
社区管理员
  • 网络编程
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章