PHP 开发 WEBGame 经验 架构篇

差不多搞了俩年WEBGame, 虽然失败了, 但是至少, 还是有些东西,值得我在这里写一下, 最近刚入职新公司,还属于没事干的阶段,今天有点时间, 就整理一下,
WEBGame和传统的WEB不太一样,传统的WEB他就一个WEBServer服务器和DBServer服务器,我们做的比这个多了一个类型的服务器,我叫它Server服务器,因为他是用来跑服务的,先简单来说说:
WEBServer所运行的是Apache + PHP + Thrift.
Server服务器所运行的是 JDK + Thrift.
DBServer服务器运行的是 Redis + mysql.
这种架构其实很明了, 
WEBServer, 是负责用户的请求, 然后过滤参数,因为我们动画展示使用的是用 flash , 所以,所有的请求都是flash 发出来的, 在url 的最后面增加一个 Session_id 来验证用户信息,而PHP所需要操作的, 就是获取user_id,action,当然任何时候都不能相信用户提交上来的参数肯定是安全的, 该转译的转, 该过滤的过, 把所有的威胁扼杀在这一层. 
但是,这层不参与逻辑计算, 我们刚开始的时候,每个用户的动作,逻辑处理,数据运算,存储数据 就是使用PHP处理的, 我们当初的情况就是,当有600 用户同时在线的时候, 服务器就扛不住了,cpu 憋满了跑, 就是 apache 和 php 的进程导致的, 我们认识到,以我当时的技术无法使用php来处理如此频繁的请求和运算,所以我们决定把逻辑运算这块单独的提出来, 不在这层处理,于是就有了我们所谓的Server服务器,
Server, 主要就是逻辑层,所有的数据计算,逻辑处理,都交给他来处理,它和WEBServer是使用 Thrift 来交互的, 拿个千兆的路由器连接起来,性能不是一般的强,
DBServer, 使用的是 Redis 和 mysql, 选择用 Redis ,是因为他的优点真的太多了,它是基于内存型存储, 性能极高,丰富的数据类型,原子性,丰富的特性等等,使用 Redis 后, 我们解决了 SQL的IO瓶颈问题, 消息, 队列 等一些列很棘手的问题, 而mysql 记录日志, 不参与逻辑运算,我们很多功能都是使用了 Redis, 下面简单说说,
性能极高:这个大家都知道它是基于内存型的存储,能支持超过 100K+ 每秒的读写频率, 我们举个例子, 按照一个用户的属性数据 10K 的容量来算, 1G的内存空间可以提供10W用户数据的高速存储, 相当于可以支持10W人同时在线,开发就不要太在意资源,我们公司现在1U 服务器的标配都 16G 了,还有什么好担心的,对于这点内存,我们还是浪的起的,高配的机器就是用来 蹂躏 和 各种 操 的,不是用来向同行炫耀的.
丰富的数据类型: Hash, list, Set等, Hash 我们用他来存储用户数据, List 我们用他来处理队列, 左压入,右弹出, 毫无压力,
原子性: 他的所有操作,都是原子性的, 对我们来说, 很有用,
丰富的特性,他的管道 Publish/Subscribe 可以处理: 消息, 触发器, 日志 等,


我刚刚回头看了一下我写的, 为了老东家的利益, 我删掉了一部分,


当初的游戏架构就是这个样子的, 由最开始, 我们最多支持 600 人在线, 到后来最高的记录是 2000 人在线, 完全没有问题,
我曾经和别人聊, 他问我, 是不是有点设计过度啊, 我们不是这么想的, 我们当初也是摸着石头过河, 也绕了很多弯路,跌跌撞撞一路走过来,只是后期的推广和公司合作方的一些原因,项目最终被叫停.