关于Reactor模式讲解请转 此文

服务器模型总结

其中“互通”指的是如果开发chat服务，多个客户连接之间是否能方便地交换数据（chat也是三大TCP网络编程案例之一）。

对于echo/httpd/Sudoku这类“连接相互独立”的服务程序，这个功能无足轻重，但是对于chat类服务却至关重要。

“顺序性”指的是在httpd/Sudoku这类请求响应服务中，如果客户连接顺序发送多个请求，那么计算得到的多个响应是否按相同的顺序发还给客户（这里指的是在自然条件下，不含刻意同步）。

方案0

方案0 这其实不是并发服务器，而是iterative 服务器，因为它一次只能服务一个客户。代码见[UNP]中的Figure 1.9，[UNP]以此为对比其他方案的基准点。这个方案不适合长连接，倒是很适合daytime这种write-only短连接服务。

. . .

关于服务器模型总结请转 此文
, 文中也有Reactor的讲解.

对于 IO 来说，我们听得比较多的是:

• BIO: 阻塞 IO
• NIO: 非阻塞 IO
• 同步 IO
• 异步 IO

以及其组合:

• 同步阻塞 IO
• 同步非阻塞 IO
• 异步阻塞 IO
• 异步非阻塞 IO

. . .

• 老书新看, 有了许多不同的见解, 也准备拿出以前自己私人的老笔记做修正放到博客里, 加深理解.
• 在这个浮躁人人都能写书的时代基本要看一本书需要挑很久, 谁写的, 写得怎么样, 是否是业界经典, 都要需要一一斟酌各种查证方可, 不然看一本烂书事半功倍, 浪费生命,影响效率, 被误导跑偏, 能让人静下心来的书籍不多, 能让人看好几遍仍回味无穷的经典就更少了
• 陈硕说过, 学东西不要只是从网上看点大牛的博客总结就行了, 总要完整地看些相关领域的经典著作的, 系统的知识结构打下坚实的基础才能继续看有关优化效率方面的书籍, 深以为然
• 孟岩说, 最近不止一次听到当一个人拥有相关领域的知识基础之后就可以找一本effective*的书来研读了, 颇有道理
• 看书的顺序忌胶柱鼓瑟, 并不是他的目录结构怎么编排你就该怎么看的, 大多数经典书籍基本都是面面俱到, 如果直接跟着这种面向知识体系本身的编排思路去看, 容易迷失乏味而无法继续, 应该找到属于自己看书顺序
• 个人总结的看书顺序是先翻阅自己感兴趣的,接着仔细观察他的目录来确定他的编排思路, 然后花一到两天的时间通览全书以获得大体知识体系构架, 之后找到实战性最强的章节来实操并逐个突破实战过程中的各个知识点

ChatServer

从登录成功就开始连接,
注册一个Chat_ID,
Player_ID 和 Chat_ID相互对应,
会注册相应的房间频道,
并为每位 Player 存了一份黑名单,
在客户端做了本地黑名单,
聊天服务器也做了黑名单二次验证处理.

• 世界频道 : 则用MsgServer的非实时推送思路
• 私密聊天 : 则选择 WorkerMan 的TCP,

MsgServer

• 实时推送 : WorkerMan 的 TCP
• 非实时推送 : 客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，

. . .

LoginServer(Gate)

当完成渠道SDK回调验证之后,
验证完玩家信息,
用了Nginx的负载均衡给每位玩家分配一台不繁忙的游戏服务器,
在Redis中存了一份玩家在线有效时间key,
这个key也可以用来完成封号操作

MainServer

因为弱交互/短连接的关系,
大多数情况玩家和玩家之间不需要实时面对面PK，
打一下对方的离线数据，
计算下排行榜，排行榜是实时计算的,
存在Redis里, 做了分页处理
买卖下道具即可.

所以 MainServer 选择了:

• yii
• Redis
• MySQL
• Nginx

. . .