目前的系统是完全可以做到动态负载平衡的，包括热切换。
以下是负载平衡的设计备忘录，现在实在是没有时间设计，所以先记下来。
启动流程：
- 主控服务器启动；
- 子服务器启动，根据配置联系主控服务器，登记，主控服务器获取到子服务器的联系信息；
- 子服务器同步现有的状态服务数据；
客户端请求流程：
- 客户端发起调用，主控服务器收到请求；
- 主控服务器分配请求到某个子服务器（省略10000关于分配算法文字）；
状态服务流程：
- 每个子服务器包含完整的状态信息（读的频率远远高过写）；
- 当收到改请求时，子服务器并不直接写，而是发送给主控服务器，主控服务器发送给所有子服务器；
问题：
- 主控服务器仍然是系统的瓶颈（可能的），但考虑到主控服务器不做任何操作，所以理论上，不超过100000....个客户端时，他不会是瓶颈（好像带宽还是瓶颈）；
- 子服务器的突然死机会造成主控服务器联系时的假死，造成一段时间的停止相应，做的好的话应该是队列发送修改指令；
- 数据库仍然是瓶颈，需要其他途径处理负载平衡。
- 数据缓存在多台服务器的更新问题比较麻烦，如果使用状态服务相同的技术的话，会不会服务器直接通讯太频繁。
补充：
如果做静态的负载，即不是动态的负载平衡，设计上要简单的多，每个客户端启动时，向主控服务器请求一个可用的空闲服务器，以后的请求全部指向这个服务器，这样做的话就没有必要同步会话服务了。而且主控服务器的带宽就不是瓶颈了。当然，这个子服务器如果死机了或者忙的受不了了，就没有办法了。
关于SQL Server的负载：
最简单的负载分摊（注意不是负载平衡，是分摊）是：系统仍然使用单一服务器连接设计，这样可以屏蔽设计的复杂性，然后适当的将工作量较大的查询转移到另外一个SQL Server下。
数据库那边当然是做事务类型的复制，订阅数据库是只读的。我想，这个要比缓存服务来的更佳效果明显吧。
