RedDwarf开发服务端介绍/reddwarf

一直不知道题目怎么起。因为表诉的东西可能比较碎。
本意是分享一下用RD开发的一些经验。so 废话少说了。

当初在做技术选型的时候，很是纠结了一把，网络服务端一般都是C++的天下。Java因其性能问题一直上不了大台面。
不过换个角度来看问题，也许不一样。毕竟大部分网络游戏是桌面端的，很多桌面端的游戏因为3D方面的原因而选了C++.
貌似大部分游戏物理引擎都是C++的。这样为了使通讯协议设计不需要夸语言。又考虑到性能自然就选了C++做服务端，另外还有一些历史原因。

最后游戏确定差不多是棋牌方面的游戏，考虑到对游戏实时性要求不高，并且对传输协议的要求只是TCP，就考虑了RD.
之前用MINA差不多写了一个测试服务端，不过需要顾及到数据持久与同步。然后还要考虑到并入房间等问题(开发效率低)就放弃了。毕竟这套东西RD都帮你实现了。MINA也只是帮你实现了通讯与任务的线程池而已,自己还要处理粘包等问题。

开工前的熟悉下这个东西，网上有中英文资料。大致的看一下以及他的例子也许就能动手了。但这里有几个很重要的地方需要注意。是我开发中体会到的

• RD不是如它宣传的那样支持多节点。目前多节点还在开发中
• 多线程对开发人员透明，并不代表不需要考虑。(开发者应该清楚哪里会存在并发)
• 所有的对象方法都是Task，所有的Task要尽可能的短,不要超过100m,虽然可以调的更高(天堂2 java模拟器也是这个值)
• 注意ManagedObject接口,这个是RD的核心，也是最容易内存泄漏地方。
• channel的join与leave 应该是配套调用的。另外一点channel不要频繁的remove.创建channel是很耗资源的。会导致全GC
• 并不是所有实现Serializable接口地方必须实现ManagedObject
• 关注持久到DB里的数据层次结构，结构设计的好，对系统是速度质的提升
• 但凡越到要实现ManagedObject的类请不停的提醒自己上面一条规则

经验不多但足以使用了，这里的重点就是ManagedObject这个接口。这个也是RD核心之核心 for why?
RD有四个基本服务构造而成，这也是它的优秀的地方，服务是可配置可插拔的。
四个基本服务分别是
数据服务 DataService
任务服务 TaskService
会话服务 SessionService
通道服务 ChannelService

其中数据服务 DataService是核心，因为RD所有的操作都可以序列化到DB里，都是通过DataService,一开始个人很郁闷。这多慢啊，任何一个操作都是读数据库操作然后写数据库，完了之间可能还有并发调度会导致回滚。

于是开始思考这种架构的目的，可行性，看了官方的游戏貌似跑的不错，但还是不太理解其含义直到看完《架构之美》的3.4.1这一节才了解。(个人觉得还是有点极端)

RD把所有的操作都进行了可移植性抽象，其把游戏里所有的数据都序列化到硬盘上，然后通过集群无缝的分发到不同的服务器上，这里实现的负载可以到达完美的性能负载，而不是现在的网络游戏的地图负载，AI负载等等地图负载还是会有空闲的机器与忙的不得了的机器。

通过对玩家的操作数据序列化 分发到多个RD服务器来达到负载以及最大面积的服务器性能使用，似乎想的不错。不过这里不可避免的会出现延迟，这点是我纠结也是最具有争议的地方，也是促使我研究RD源码的地方

不知道将来是否RD会在数据库与逻辑层之间架起一个缓存层，这样可以对当前活跃的操作转移会快一点。个人有这个设想。

目前给予延迟的解决方案是根据游戏的逻辑将活跃的对象转移到一台服务器上，比如攻城战的时候把玩家数据转移到一台服务器上，这样就避免了多台服务器的传输延迟，(这里基于任务的序列化存储 发挥了负载的功能)然后设定这类高负载服务器的线程池大一点，充分利用多核技术，可以提高并发的访问速度，达到接近内存的速度。

上面是《架构之美》的解释，的确RD在网络游戏上的架构有独特的方式，牺牲一点性能换来高效率的负载，但是否适合您的游戏这得你自己掂量。个人觉得除了FPS类型的游戏，基本都可以用RD。即使是WOW这种MMO游戏也可以胜任，也许C++写的可以带1000个人，RD写的可能只能带700人，但是用RD写的服务端不存在分区的概念，所有的玩家均匀的分布在服务器上，大面积的战斗可以随时把操作通信频繁的一群玩家拉到一台服务器上。从而降低通信延迟(服务器之间的通信延迟)。

任务服务 TaskService:
这是个什么东西呢？在RD里所有的操作都会排列在任务队列里，由任务线程来处理每个任务，这也就是为什么任务执行时间不能太长的原因，RD会按着先来后到的顺序执行任务，所以网速慢会发生延迟的现象，因为你的包是后到服务端。
另外任务超时会被做一个标记，尝试25次之后会被Abort.(文档是这样写的，实际上可能不是，有机会深入源码再给出个人肯定的断定)。这里就有个疑问什么是Task?难道通过TaskManager搞出来的就是Task吗？非也。RD里一切的操作都是建立的任务调度池上的。包括你发送包，访问数据库等等。这一切都是任务，都必须在100m里完成。(这里100ms是指的每一次事务,不是上面所有的操作)
记得在群里有个哥们说他们不用MO只用Task，我个人估计他们可能没有理解MO与Task之间的关系以及MO的重要性。

会话服务 SessionService
通道服务 ChannelService
这个是几乎所有网游必备服务—-通信。Session会话简单点来讲就是端对端的直接通信，当然这里的端是指服务器。
在RD里你只需要理解 ClientSession 接口与 ClientSessionListener接口就基本可以了。看完这两个类的方法基本就知道怎么通信了。当然这里还需要配套的客户端API。(SUN还是很重架构，很多东西抽象的有点过头。)Channel之意就是一群人在一个小组里，简单点说就是一个XXQ群，你一个人说话，群里的人都可以收到。主要方法都在Channel ，ChannelListener这两个接口里 ，第二个接口主要是对信息内容进行过滤的

上面是RD最基本也是最重要的架构与接口，其他比如大面积多节点的集合，大家可以查看他的内部API,另外我们还可以自己定义扩展服务器的service 以及传输方式(加入UDP支持 P2P支持)以及自定义验证,这些我会抽时间讲讲个人经验。