思考：游戏服务器中“网络和数据库 ”2个模块的架构思路

1)One Loop Per Thread(以8核心16G内存为例子)

1个线程主Reactor: 负责accept新的链接。

16个线程的从Reactor：负责很多个socket的IO读写事件。

8个业务线程：负责收到IO事件后，进行业务处理，里面都是同步的写逻辑。

4个DBThread：在业务中进行数据库异步 落地时使用。

4个RPC Thread：负责多个系统之间的rpc通信。

总结：掌握这一种高并发网络编程模型即可满足各种业务需求! 可以看出有以下优点：

         线程数量固定，不会膨胀，会比较稳定。

         根据业务情况(如:IO密集型还是CPU密集型)，比较方便的调整业务线程池及其线程数量的策略。

2)封装mongodb的数据库万能操作，从此再无sql语句，直接面向业务高效编程:

增：新用户注册大的Role角色新增、Role中某一部分增

删：Role中删除一部分数据

改：Role中一部分更新

查：查询大的Role然后把diff更新到Role表、查询Role中部分数据

总结：

因此对数据库的操作，一共就简单的3个操作，其中红色部分不是业务层的，是非常固定的部分。

其余的部分，均是封装的diff写法，非常固定，也可以代码生成。

万能操作mongodb的几个参数：

        数据库

        哪个文档

        哪个集合

        条件+Query对象+mongoTemplate

3)理解epoll 2中触发模式

因为存在缓冲区的概念，因此何时触发IO事件呢?

一个是:缓冲区还有数据，则就不停 触发，即使没有IO事件。

一个是缓冲区有数据，但是还是等到下次收到新的数据后，才触发一次。

4)Netty服务器启动时的 SO_REUSEPORT 参数:

可以实现多个服务监听一个端口，让os层面实现一定的负载均衡;

比如：netty中启动了8个线程监听同一个端口连接上的玩家，如果没这个参数，感觉和1个线程监听有何区别，觉得应该是解决这个问题;