框架源码、线程、容灾等问题 about iogame HOT 1 CLOSED

1 客户端与external建立连接的入口在哪？

ExternalServerBuilder.build();

ExternalChannelInitializerCallbackWebsocket、ExternalChannelInitializerCallbackTcp。

2 broker的路由寻址逻辑和负载均衡具体在哪里实现的

ExternalRequestMessageBrokerProcessor。

3 网关和逻辑服之前的通信，还有连接管理的具体位置在哪？

RegisterBrokerClientMessageBrokerProcessor

框架的线程池方面：
对外、网关、逻辑服几种线程(例如：IO线程 和 工作线程 )具体如何划分的。
网络模型是什么样子(nio,bio,aio还是io多路复用)，顺便能指明一下class类就更好了。

游戏对外服由两部分组成，1.与真实玩家通信的纯 netty，在 ExternalServerBuilder 中可看见。2 与 broker 通信的 ExternalBrokerClientStartup ，实现使用 bolt 本质上也是 netty。

状态持久化针对容灾
1.内部session的状态存储目前都存储在内存，如果服务部署在云端，出现容器漂移、逐出是很常见的事情（物理机也会出现死机等问题），这种情况用户连接都会断开,（此时这种有状态的数据---包含但不限于用户session，是否可以有扩展的口子让使用者自己实现持久化逻辑） 使用者自己就可以重写实现这些有状态数据的持久化细节。（宕机后客户端重连仍然可以恢复用户的有状态数据）

可以通过用户上线、下线的钩子来实现此需求。

2. 广播消息推送的时候，广播是临时存储在broker内存里面的吗？如果需要广播发送给uid=1,2,3,4,5这5个用户，但是由于中间环节出现不可预知的问题（例如某一台broker服务宕机了)，广播是否就没了。如果涉及到一些财务相关的业务，使用广播给2个正在进行交易的用户发送广播，但是其中一个用户external连接出现了问题，客户端有一些重连的逻辑，重连上之后，希望能有一个重试机制这样的。

实际中没遇见过，但极限情况下也不排除可能性。如果涉及到一些财务相关的业务，如果数据已经落地了并不会有什么问题，只是显示上有不同。这种情况可以通过与前端协商一些逻辑来增加确认机制，比如N秒后没有变动可以重复请求。
关于用户external连接出现了问题，在重新连接上时，请求一次这些数据就可以了。

疑问点：
broker的实现，为什么选择自己实现，为何不采用相对比较成熟的方案，例如zk,etcd。

轻、使用也足够简单

from iogame.