MMO服务端设计-记录1-基础框架

https://git.oschina.net/dreamyouxi/MMOGame

1.网络库的选择

从原始的网络操作api写的话，会花费很多精力，选择一个成熟的网络库是一个很不错的方案。

可选择的底层网络库很多，asio libevent ace等。

对应 两种高性能I/O设计模式(Reactor/Proactor)

Proactor典型例子是：IOCP，asio

Reactor 典型例子是EPOLL，libevent

相比之下更倾向于asio的proactor模型，框架设计起来更简单，每次网络都是已经接收完成了，只需要对其逻辑处理即可。

但是服务器在linux下运行，asio 效率会折扣，期望是windows下开发，linux下运维，因此要压榨服务器的性能，跨平台的话一个网络库就不太可能限定起来。

无论是哪种方式，网络消息的分发都可以由一个中间件来完成，可以是master也可以是mgr，这样切换不同的网络库对于服务器本身逻辑的编写不会有什么改动，kbe是支持epoll select等 io机制，他的做法也是如此，网络事件都有一个distapcher统一分发该网络事件。

因此设计上就可以吧网络io层独立出来，代码看起来可能是这样

要切换到其他io 做一个适配层就可以了，

asio的适配

2.服务器并发模型

多进程单线程 or 多进程多线程

关于并发基本模型主要有，多进程的单线程模型，多进程的多线程模型，单进程的多线程模型，这里的线程主要是指游戏逻辑执行的线程。多进程单线程模型，类似于kbe的架构，一个cell 或者base 游戏逻辑执行的线程只有一个，这样大大简化了代码开发难度，效率相对也较高，比如吧一个cell做场景服务器，多个cell协同合作，玩家跨场景就在cell之间切换。

数据迁移的速度就很关键了，这也是实现无缝跨地图的重要因素，。kbe的这种bigworld方式的数据迁移主要就用socket 共享内存 redis 等，但是这些速度都没那么快，能用内存就用内存。

根据上述缺陷，还有一种解决方案，就是把cell base 直接装进一个进程里，数据迁移就简单得多，加个锁 然后更改数据指针所有权即可。这样吧cell当做线程来处理，cellMgr 可以当做这个进程的主线程，负责维护处理cell，这样吧进程通信socket 更改为了直接的内存交互，

这样做的一个缺点是把这些cell cellmgr 限制在了一台物理机上，由于都在同一个物理机，从单台物理机限制了并发量，一个cell 宕机之后 如果处理不得当，会导致整个进程宕机，从而影响整个系统，再者局域网通信socket 都可以维持在1ms以内。 这点数据迁移代价节约的并不多，如果客户端也要loading的话，那还不如不做这种优化，PS:反正都要读条

TODO