单线程 + 无阻塞队列 
这个架构的重点在于业务线程不能有阻塞,其他IO异步,一些重计算的,排行榜(堆排序),聊天(ac自动机)等需要特殊算法进行优化,或分布式架构,拆分出来。 当然可能会遇到一些问题 1、 无锁编程(并不是必要,可以简单队列处理) 2 、多线程死锁问题 3、 跨服会比较麻烦,因为架构耦合比较严重,一般建个新服做为跨服,进入跨服数据同步过去,等退出跨服,再把数据反向同步回来 4 、单点问题,一旦不可用,就是整体不可用 特意说一下这个,这个的设计的目的是为了实现服务器无状态,把状态存进去redis里面,主要游戏服务器基本都是有状态的,需要保存一些状态的数据。当然有些类别可以做成无状态,如卡牌。不保存状态,就能实现快速重启,数据,逻辑分离好处多多。但并不是所有业务都能用,redis在单链接大概在2万qps,多链接确实能到10万qps。对于大部分业务是可以的,很多都是低频业务,但对于一些高频的,同屏100人用这个扛不住的。
分布式架构 
这个架构的重点在于服务器拆分,一般按着业务,数据一致性进行拆分。 当然也会遇到一些问题 1 分布式数据一致性问题(最麻烦的问题,虽然说有通用方案,就是做分布式事务,采用最终一致性进行妥协,但很多公司的做法是不理,因为麻烦,通过把数据冗余尽量把分割的功能合在一起,策略采取先扣除,出问题,客服人工补) 2 调用链问题,因为功能割裂,有些时候问题查找麻烦(日志跟踪麻烦,因为功能割裂,日志分布在不同的服务器上) 3 运维的工作量剧增,或许需要开发一些额外的工具 4 单点问题不可用(网络不可用,机器不可用) 5 一些特殊的业务得做冗余设计,做缓存系统 其实可以明显对比,分布式架构要做要解决的问题会相堆比较多,所以有足够的人力才去做,所以这也是个考量的要素之一。 当然不同游戏类型,架构会稍微不一样,简单介绍一下 
mmorpg 前面说过服务器拆分是依据数据一致性的,在mmorpg中,场景的数据是比较重要的,不像回合制,场景物体与人物,数据同步量比较大,做数据一致性比较麻烦,一般会把场景角色管理合为一体,如在场景捡一个物品,进入背包,人物血量同步,技能同步等。 
棋牌游戏,压力会在于各种子游戏跟机器人上面,所以会采取按游戏拆分,每场游戏再进行数据同步,有业务的特殊性,网关规避攻击,规避监管。 架构设计,其实更多是为了解决问题,像一些流行的微服务,其实主要为了是解决在大量人力同时做一个项目,在沟通成本急剧上涨情况下,进行合理拆分,减少沟通成本。 这是一篇总起的文章,因为这些细节的解决方案,都能各自成为一篇文章。篇幅有限。后面会开始说细节。
数据存储策略 mysql的我们需要了解的技术细节 mysql的一些高可用方案 redis的我们需要了解的技术细节 游戏业务上常用的算法 lua热更新思路 地图,场景同步方案 跨服实现 数据一致策略,事务处理 自动化测试搭建 一些编码上的小技巧(防死循环) 一些有趣的设计架构(多租户架构) 更详细架构方案(mmorpg等) 租用游戏服务器选择天下数据!天下数据已经成为国内最大的海外服务器IDC服务商,服务器、数据中心解决方案发展成熟,各大行业上市企业也热衷于与天下数据合作,省心、省事、省时。天下数据已为众多企业提供最安全的海外游戏解决方案、游戏数据安全解决方案、游戏服务器配置安全、游戏服务器架设方案。
|