游戏核心逻辑设计 - 登录系统
游戏服务器结构演化
左边是一个简单的游戏架构，类似于《天天酷跑》，有很多客户端登录到一个服务器上，服务器只有一个进程。随着游戏变得复杂，逐渐演化到右边的结构，也就是对左边结构简单的做了一个分层，这里的world可以理解为逻辑服务器，就是承载游戏逻辑的，然后会抽象出连接服务器和DB数据库。抽象出来的好处是什么呢？例如同时做两个项目的话，其实两个项目很多情况下，它的区别仅仅在于这个world，也就是逻辑服务器这里，而连接服务器和数据服务器应该是可以通用的，这样的话只要做一套，就可以支撑更多的项目。所以这里分为两层，就叫做逻辑层和基础组件层之后，基础组件层是可以多个项目互用的，实际上在腾讯内基础组件层几乎是整个公司用一套的，就节省了大量的人力成本。
国内的游戏服务器和国外的最大的区别是在：国内的游戏的逻辑是跑在服务器上的，客户端可能逐渐变成一个只是显示表现象的东西，所有牵扯到财产、玩家数据、校验等逻辑都是放在服务器上的，因此导致服务器的逻辑层越来越复杂，单个进程是根本没有办法处理的。
什么是登录系统
玩家通过客户端和服务器建立连接，在服务器各个进程上完成需要的账号和角色数据创建，并进入游戏场景开始游戏的过程称为登录。
搭建登录系统的装备工作
- 实现接入服务器（connect svr）
简单的方式可直接使用socket完成 - 实现db存储（db svr + mysql）
将玩家数据转化为db数据存入的过程中，需要独立出db svr，而mysql则作为后端的存储。 - 制定协议（protobuf）
服务器之间的通信和服务器和客户端之间的通信
由于游戏不断的更新，服务器最终会演化成为一个大规模分布式系统。不同系统之间的进程也会相互通信，它们也需要协议。
为什么服务器会演化成为一个大规模分布式系统，以及作为分布式系统，登录在这个系统中的位置，实际上它处于一个中间层的位置。最底层是组件如接入、存取数据、日志记录等。上层是具体的玩法如副本、竞技场等。中间层则是一些处于上下层之间且可以支撑大规模玩法开发，同时向下可以让整个系统跑起来的类似客户端引擎，这样一个服务器引擎层的概念。
登录系统的基本流程
- 客户端和服务器之间建立或断开连接
- 用户登入或登出
- 创建或删除或修改角色
- 进入或离开场景
使用什么样的设计模式来实现登录系统呢？
状态模式 - 登录状态机
- 多进程分别维护账户登录状态上下文
- 通过网络消息驱动
- 分层状态机设计
这里有一个问题，这里为什么叫做引擎层却要跟玩法隔离呢？
游戏服务器大体分为组件层、逻辑引擎层、上层逻辑层。
简单的登录流程
- 消息驱动
- 多层状态机
- 分布式
登录系统的性能问题
服务器物理性能边界：流程、CPU、内存、DB访问
互联网实际线上遇到的性能问题：
- 性能波动：玩家的大规模集中登录、群体传送
- 毛刺和雪崩
性能问题实例：集中登录和群体传递
- 流量
svr->srv 玩家数据打包迁移
svr->cli 视野信息同步 - CPU
大量集中内存操作，若美誉偶平滑策略，就会发生毛刺。如果毛刺导致CPU 100%，就可能出发雪崩。 - 内存
核心进程聚集大量中转数据 - DB
集中数据存储
开发效率与高可用性
实际项目大规模并发问题
- 破窗理论：底层框架系统的示范和放大效应，如登录层和逻辑层混合。
- 实现隐藏：分层机制、消息机制
高可用性
- 墨菲定律：如物理机宕机、Scene宕机、DB宕机、网络堵塞、DB过载。
- 基本原则：出错可以回滚，支持重试。
总结
- 游戏服务器基本组成
- 基础组件：连接、存盘、日志
- 逻辑服务：分布式多进程系统
- 登录是一个多层分布式状态机
- 登录的基本流程和状态
- 需要考虑各种边界情况
- 底层系统要考虑性能、容灾和团队开发问题
- 四个物理性能边界，毛刺和雪崩可能的产生点。
- 100%一定会出问题，控制出问题后的影响范围。
- 自己动手实现简单登录框架