zeroatom

我使用集群的方式 1. 采用原生的cluster集群 2. 根据不同集群需求添加的不同集群路由管理服务, 如 分片集群(friend1,friend2), 均衡集群(gamemgr1,gamemgr2) 3. api 如xxcluster.call("friend",...) 节点类型访问，及一些定制接口 4. 调用消息 call->{cluster_type}_{node_type}_sender->clustersender 4. 服务过载由源头和目标服务处理 a. 目标服务消息过载mqlen回复繁忙，拒绝请求 b. 源头对繁忙、错误的降级等策略处理 5. agent -> cluster(node1, node2) 使用方式为agent的req/resp模式 即使有notify也转为req a. 如邮件，node1有新邮件...

我对集群包装没你那么重，暂时没有你消息回传的问题。我这边用集群是因为是全球服，方便业务扩展。 均衡集群为无状态节点集群 (login1..n) (gamemgr1...n) ... 1. 多节点高可用 2. 扩展功能负载 分片集群(类redis)为有状态节点集群 (friend1...n) ... 1. 静态路由节点 2. 节点down了也不切换节点, 除非由仲裁节点改静态配置 3. friendx down了直接拉起 4. firendx 启动过程中未完毕前，节点对外部节点的api都error 5. 集群负载不够，添加节点，迁移slot 我这边req/resp的使用方式主要为了 1. 集群节点业务独立，不与其他节点有关联，由请求方驱动业务。 2. agent...

嗯，是两个tcp agent 侧 cluster.send("battle_node", "battle service", session_id, "client_battle_pkg") -- 请求 放技能 移动等 战斗 侧 cluster.send("agent node", "agent service", session_id, "battle_event_pkg") -- 实体状态变化 这样裸调，cluster底层 cluster_sender会不停connect agent node, 如心跳30，agent down了，战斗侧心跳到了会踢掉agent, 过程中还是不停send。

嗯，目前我就是用队列，因为队列是针对玩家的，不是节点的，当有agent节点有很多玩家在战斗，每个玩家都有send，感觉会狂刷日志。 所以我在考虑要不要在cluster_sender做些拦截及让cluster_sender抛出节点断开让业务感知。