Actor模式之高性能并发框架的构想

Actor模式之高性能并发框架的构想

原文转自：  http://www.tanjp.com/archives/106 

最近接触到了Actor模型，以及了解云风的skynet框架，想重新实现一套高并发的框架。

 

想想做游戏也七八年了，接触过一些不同的游戏框架。有的使用多线程并发，但是业务逻辑各种加锁，导致项目后期维护成本不敢想像的大。后来，主流的方向对采用单线程做主业务逻辑加多进程的并发处理，这种框架一定程度上解决了维护成本大的问题，但同时又出现了新的问题，那就是多进程交互的业务逻辑，数据一致性的问题。于是，到后来演变出还是主逻辑单线程做业务处理，多线程做运算密集型的业务，或者多线程处理各种IO，如网络、数据库、磁盘日志等，这种模型开发效率搞，维护成本也低，但是就很难有比较好的并发表现。其实，这种框架做绝大多数游戏项目是已经足够应付了，毕竟多数游戏并没有那么大的并发量。虽说如此，但还是想做一套更好的框架，以适应日后高并发的大数据时代。

 

先来，总结一下现在服务器框架上的一些问题。

1、单线程的逻辑业务处理。虽然说，逻辑业务处理也就是一些基本的运算单元，没有网络IO，磁盘IO，复杂运算也由独立的线程完成了。但是繁多的这些基本单元串行执行加上脚本层的性能消耗，其实还是挺占CPU的，最严重的问题是，只能占用一个核。在这个多核并发的时代，明显的性能瓶颈。

2、根据进程或机器架构来编程，而不是根据业务需求来编程。现在开发项目，首先在立项的时候就确定游戏类型，这不同的游戏类型，在设计层面就不太一样。譬如MMOARPG，需要多人同屏和各种场景迁移，这是一个比较大的服务器压力的点。如果是传统的SLG，就没那么多实时交互，但是可能需要全世界同服的方案。又或者是某类运算量特别高的战斗系统，可能又需要单独一套战斗线程或进程进行处理。其实，这么考虑也没什么太大问题，只是往往到后来进程或机器架构限制了业务逻辑的需求，或者需要同时重新调整架构和业务逻辑来突破这些限制。

3、高可用的问题。游戏逻辑要做到高可用，其实是很难的。现在多数的游戏开发者都不考虑机器故障，网络异常，继续高可用的问题。因为这个太难了，而且业务也不需要这么强的高可用性，大不了停服维护呗。很多知名的游戏公司也就是那样。这不像电商或其他公共平台，停止运作一分钟的损失是不可估量的。

 

当然，现在的服务器框架也有一些优点，也是希望继续保留的。

1、有一套规范的开发模式进行单线程的逻辑功能。开发效率高，而且门槛低，一两年相关经验的同学短时间的培训就能胜任。

2、虽然是单线程的业务逻辑处理，但多线程的IO和CPU密集型的运算，在一定程度上性能也还不错。

3、Lua状态机的把异常很好的隔离，似的整个项目的可靠性大大提高。

4、运用了Lua协程的机制，把异步代码转成同步的方式进行编写，在开发效率和代码维护上，都是很不错的。

 

好了，大概分析了现在的情况，也该想想怎样才能弥补缺点和继续发挥优势了。

不急，先去跑跑步，找下灵感……

 

原文转自：  http://www.tanjp.com/archives/106