游戏后台设计考虑点(来自工作实践中的一些经验)

游戏后台设计考虑点
1.系统核心设计
  架构，整个服务器大区的架构设计
  服务器机型选择，考虑成本和性能的性价比
  合理划分进程，保持系统简单


2.扩展性
  从10几万到百万能否轻松的平滑扩展 （如架构扩展，系统32到64）
  需求不断变化，数据是否能平台升级，如数据库


3.安全性
  防止崩溃，防止恶意攻击
  有没有单点故障


4.自动化运维
可监控，可管理，可维护，可迁移


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




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


异步IO
1.保证业务逻辑不会被任何阻塞(如网络IO db的IO 复杂运算)
  剥离网络IO
  剥离数据库IO
  剥离磁盘IO(日志的读写)
  剥离复杂运算启用辅助线程
  保证主逻辑无阻塞运行


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


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




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


业务级别的监控
IDC监控
   


高性能设计原则
流水化
数据局化原则
锁的力度问题，使用轻量级的锁


尽量避免动态内存分配
  尽量不动态分配内存
  优化调锁的内存池  
  使用内存分配池
  实时动态分配内存
  


避免轮询
  Hash查找
  Map查找
  Cache数据
  使用epoll代替select
 




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


持续集成
  高质量，低风险，高效率