简单邮局模式的更正

       前几天说了一个邮局模式的结构，但是后来看来不靠谱，erlang的思想和现在大部分主流语言的解决并发的想法都是不同的，因为许多概念上的东西都不同，这几天把java的东西捡了捡看了看基础的书，发现这种模式不合理，如果对于游戏来讲的话我又把自己的结构更改了一下！

       1.利用两个环队列来处理消息的收发问题（每个进程一个收发队列），每次我们的线程就去环里面拿消息（这里要加锁，打个比方当1号线程拿队列里指针的第一个位置的消息，那么1号消息加锁，然后指针下移保证每条消息一次执行，执行以后将一号消息删除），这个环的大小要定义的合理，看根据我们的消息吞吐量来决定，那么如果出现消息溢出我们直接把前面的消息顶掉，后面的消息进入（这里还没有想好，因为如果合理定义那么应该不会出现溢出的情况，处理速度当然是和线程数成正比的，线程越多，那么处理速度越快，但是占用内存就更多，这是简单换时间的概念）！

       2.数据库的话，可以随意，表的定义完全根据自己的需求！（其实我有想过，把所有的数值处理全部交给数据库完成，毕竟数据库也可以缓存到内存中，但是貌似没听过谁这么做过，这样耦合性比较强，不容易把握）！

       3.设立一个消息转发进程，这个进程的作用是，监听接收发送tcpip连接信息，将发来的消息进行一个分类处理分发的下属进程中去，例如消息flag为人物间消息那么我们就将他发给人物进程（我一直在想能不能tcp连接和消息的处理写在一个进程里，毕竟减少进程间通信可以提高响应速度，不过连接的操作以及消息的分发，和消息的处理都写在一个进程中结构很不清晰，而且这里只是两次进程间通信的收与发，所以貌似影响应该不大）！（java里的进程间通信，就是类似于erlang中的跨节点通信！）

       4.关于tcpip的连接数问题，如果我说我一个tcpip协议只开启两个socket连接，可能会感到很诧异，我们以前的erlang处理是，一个人物一个socket，但是我感觉没有必要，因为发包的数量是不变的，发来1000个包，不会因为连接的增加而加快，主要看的是网速，一个长链接就可以了（首先，你一定会问，这样做的玩家的独立性怎么解决，其实，玩家也好怪物也好，在我们的内存中，只不过就是数据，就算是每个人给他一个连接，那么他们做的事情也都是处理映射数据，然后持久化到数据库中，那么我们现在用一个集中处理的方式来处理每个人的动作也未尝不可，因为java的线程可不想erlang中的进程那样随意创建！当然，到目前为止我没有真正开发过java的游戏项目，至于如何解决高并发问题，也是我根据自己的理解来处理）。

       5.用一个java进程来作为主进程既人物进程，数据库的人物信息映射到hashmap里，开启100~200个线程随意（前期可以先在我这个8g小电脑上开10个线程实验一下，毕竟是想法，还没有做好）！我们每个线程主动去队列里拿消息，一旦遇到消息为零那么我们的线程进入就绪（runnable）状态！

       6.相应的，我们可以把人物关系和怪物以及聊天等大功能拿出来，单做一个进程，这样做可以尽可能的减少进程之间的通信，而且层次比较清晰，如果我们在一个进程处理如此庞大的信息量，会很难，很复杂！

       7.关于消息的定制，我们用的是protobuffers一个开源的消息协议，当然我们也可以自己写一套，我感觉应该不会那么难！

       以上也是最近思考过的较为靠谱的一些结构，毕竟细节上的处理还是要边做边看，就像日志的写操作，和一些资源强制释放等问题，还有服务器的内存中的数据何时写入数据库都是值得深思的！现在光是空想恐怕想不明白，还是做了以后跑几个小机器人试试再说吧