客户端为2种，web(短链接)与客户端（长链接），现在有2种不成熟思路。

1,集群网络共享:
   集群前端采用负载均衡,所有服务器在内存中保持一致的数据结构，一台服务器收到信息把信息广播给所有集群中的服务器。定期验证链接(集群内通讯)是否正常,数据是否一致.其中一台服务器与客户端保持链接(长链接)，当其中一台服务器出现问题，客户端自动重链。通过内存中同步的数据进行业务处理.

2,分布式
  服务器分为2大类,即公共数据服务器与私有服务器，只维护一个公共资源在公共服务器，私有服务器对外开放端口(负载均衡),
通过私有服务器与公共服务器交换信息处理业务逻辑.（即业务逻辑主要放在私有服务器上，包括数据据的操作）.

请问:
1,集群共享如果其中一台服务器压力过大（因为是长链接），是否影响整个系统的性能。
2,分布式的共享服务器压力回有多大(按1W链接算).
3,请问现在普遍采用的模型是什么样的.
4,有没有必要用多个accept处理短链接, 2.6内核据说没有惊群现象了。accept线程组(非阻塞+epoll)->read线程组->接收队列->业务处理模块->发送队列->write线程组,这么设计是否有问题.

太不成熟了。。。 一团乱。。。

竟然还有广播。。。


1，不可能出现这个问题，对于长连接服务来说，可以DNS将域名映射到多个C2S服务器或者F5/LVS负载均衡，这里的概念就是无限的横向扩展C2S服务器，C2S服务器的唯一作用就是负责长连接用户接入以及数据解析修饰后向内网转发。

2，什么意思。。。 服务器的压力永远都不在内存，也不在于带宽，只会因为慢速的磁盘访问或者慢速的逻辑处理或者长距离的网络传输造成瓶颈。

3，看你疑惑的是长连接，基本模型是前端C2S接入（可横向扩展），中间router路由（可横向扩展），后端sm会话管理（可横向扩展），最后是数据库与缓存系统。 系统的组建故障均可以定时检测踢出下线， 因为组建离线而引起的会话不一致问题可以配合客户端逻辑做断线重连，会话信息需要持久化到数据库。

4，不知道你想干嘛。。。 网络I/O进程用epoll，计算/缓慢磁盘I/O进程用线程池，master-worker进程模型用lock-accept，根据服务类型（网络I/O进程用epoll，计算/缓慢磁盘I/O进程用线程池）选择合适的程序设计模型。