pomelo的初衷是后台服务器无状态，因此它可以任意使用配置规则来扩展其后台服务器以承载更多的游戏玩家，但实际上还是要面临A玩家在cs1前台并在bk1后台的问题。
假如玩家A被分配在了空闲的cs1前台，并且cs1前台路由的是比较合适的bk1后台
看图：由于还有bk2后台，因为cs1需要知道如何来选择此玩家的请求被正确处理。因为逻辑部分最终是落在bk1上的，因此我们认为玩家A在bk1是有状态的。
pomelo的解决方法是实现自己的路由算法
这个路由算法来保证玩家A的请求被正确的处理到了正确的bk上
如果路由算法不稳定，玩家A被分配到了bk1上，却想通过bk2来处理请求那么就会产生问题。
以chat为例：
假设玩家A被add到了bk1上，却调用了bk2的send方法，后果是channel无法处理sendmessage请求，因为channel是本地的，每个进程一个自己的channel.因此这个玩家这个请求是不会被处理的。
来看下chat是如何处理路由的
// 这里是一个稳定输出
// util/dispatcher.js
module.exports.dispatch = function(key, list) {
var index = Math.abs(crc.crc32(key)) % list.length;
return list[index];
};
// gateHandler.js
handler.queryEntry = function(msg, session, next) {
// get all connectors
var connectors = this.app.getServersByType('connector');
// select a connector from all the connectors
var res = dispatcher.dispatch(uid, connectors);
// do something with res
};
// app.js
// route definition for chat server
var chatRoute = function(session, msg, app, cb) {
var chatServers = app.getServersByType('chat');
if(!chatServers || chatServers.length === 0) {
cb(new Error('can not find chat servers.'));
return;
}
var res = dispatcher.dispatch(session.get('rid'), chatServers);
cb(null, res.id);
};
// 这个是配置路由算法，在寻找chat时该如何寻找，结合框架上下文，要查找chat的是cs
// 当然了，任何需要rpc到chat后台都需要过这一关
app.configure('production|development', function() {
app.route('chat', chatRoute);
});
示例中以超级稳定的输出来保证了此玩家每次都被分配到同一个cs上，至于分配到哪个后台，他也是这套做法。
这给我们一个启示，玩家分配时一定要稳定，否则会出现问题。
谈谈它的问题，这种算法的不利点在于无论cs2多么空闲，只要是玩家A过来，都是cs1
如果你不配置自己的route算法，那么pomelo将启用默认的route算法。
实际上你都应该编写自己的路由算法，在大型项目中，我们只要确保路由算法的稳定性，就能轻松应对玩家数量的增涨。
写在结尾 https://www.processon.com/i/568c6ea4e4b0e51d149a085f
这个网站解决了大家开始设计阶段的问题，轻量级的各种设计模型，强烈推荐
本文中的插图皆由此工具绘制