后台开发，设计游戏需要考虑的地方

1 考虑

1.1 系统核心设计

1. 架构：整个服务器大区的架构设计
2. 服务器机型的选择：考虑成本和性能的性价比
3. 合理划分进程：保持系统简单

2.1 扩展性

1. 从十几万到百万是否能够做到平滑、轻松的扩展（如架构扩展、系统32位到64位）
2. 需求不断变化，数据是否能够随着平台的升级而升级（如数据库）

3.1 安全性

1. 防止崩溃，恶意攻击
2. 有没有单点维护

4.1 自动化运维

1. 可监控、可维护、可管理、可迁移

2 其他

2.1 服务器稳定基石

1. 分层设计，组件化设计，便于组件复用和沉淀(如果像网络，脚本，AI是否能做成通用组件)
2. 单进程异步保证高效处理逻辑
3. 时间复杂度高可由辅助线程计算，回调处理
4. lockless设计(保证同步锁的力度最小最少)
5. 避免动态分配内存，采用内存池的方式
6. 完善的日志系统
7. 方便监控
8. 过载保护

2.2 进程模型

• 单进程+异步IO使系统运行在最佳状态
• 保证进程数小于cup个数

2.3 异步IO

保证业务逻辑不会被任何阻塞(如网络IO db的IO 复杂运算)

• 剥离网络IO
• 剥离数据库IO
• 剥离磁盘IO(日志的读写)
• 剥离复杂运算启用辅助线程
• 保证主逻辑无阻塞运行

2.4 数据层回写机制

• 热点数据cache
• 多个写经行合并写入
• 全局DB读写频率控制，防止崩溃
• 停机回写机制

2.5 系统安全

基于不信任架构和逻辑

• 网络层、业务层对各个请求的长度，频率，合法性做效验，防止恶意请求，防止雪崩。
• 网络层、业务层有不同的效验逻辑。
• 客户端只负责基本的校验，运算逻辑在服务端进行
• 对财产重要数据，采用统一的处理接口，统一的权限验证，统一的日志

2.6 立体监控

系统级别监控

• 平均响应时间(负责过高可禁止新用户登录，调整聊天频率)
• 内存使用情况
• 数据层失败率
• 避免过早优化

业务级别的监控

• IDC监控

2.7 高性能设计原则

• 流水化
• 数据局化原则
• 锁的力度问题，使用轻量级的锁

2.8 尽量避免动态内存分配

• 尽量不动态分配内存
• 优化调锁的内存池
• 使用内存分配池

2.9 避免轮询

• Hash查找
• Map查找
• Cache数据
• 使用epoll代替select

2.10 原则

• 简单: 设计简单
• 无互斥: 优化可能的锁，并发部分没有使用锁
• 少数进程: 进程数<CPU个数
• 无文件I/O: 对写日志使用单独进程
• 无动态分配内存: 需要的内存在服务器启动就分配好，运行时候不再动态实时分配内存
• 无轮询:尽量使用Hash查询

2.11 持续集成

• 高质量，低风险，高效率

参考：https://blog.csdn.net/soft2967/article/details/8531985