TCP服务器如何提高负载量(长连接)?

前段时间做了一个TCP的服务器, 监听client的请求, 其中client和server采用的是长连接, 也就是说client不会主动调用close来关闭连接,  现在问题在于如果client的数量越来越多, 那么服务器的压力也就越来越大, 于是考虑两种解决问题的方法:

1. 服务器端来做集群, 但服务器又保持有客户端的长连接, 这种情况下不是简单的session复制可以解决问题, 暂时没有找出合理的解决方案

2. 做负载均衡, 就是把客户端的请求路由到不同的服务器上, 在不采用硬件的情况下只能用软件的方式来解决, 但这时问题同样是长连接的问题, 也就是说只能是单入口的, 服务器只能暴漏一个IP 给client, 于是客户端连接到这个服务器上, 建立连接, 此时又如何做路由呢? 

长连接的高负载量有没有好的解决方案?

http://blog.lighttpd.net/articles/2006/11/27/comet-meets-mod_mailbox

看看这个对你有没有帮助？

长连接是必须的约束麽？

文中只提到了 Comet 的实现策略, 似乎并没有提到服务器如果保持长连接时候如何提高负载量, Jetty的相关文章中也未提及

client和server 的交互频繁, 采用UDP又容易丢失消息(文字,图片), 而且客户的要求要用长连接.

如果单纯是为了回避问题, 可以采用其他的解决方案, 但我想的是应该找到一个诸如长连接此类问题的解决方案才是最好的.

不是回避阿，是看有没有必要。我倒是很想知道必须使用长连接的应用场景。因为我们向来是使用短连接的。
交互频繁并不是理由，还有其他原因么？

恩，  交互过程是这样的：

Client1 -----  Server ----- Client2

其中Client2会不时的发送一些数据给Server，  Server经过一些处理发送给Client1, 其中Server两边的 client 都可能会很多， 其中Client2 只支持TCP协议通信(这个是固定死的,无法改变), Client1和Server之间没有约束， 不过Client1 是用 C++ 写的， 目前实现的也是TCP的连接方式来连接Server , 另外Client2给Server发送的数据 大多是图片。 基本上场景就是这样， 我目前采用的方式 为Server两边的Client均为长连接.

我觉得有一个简单的办法，负载均衡器上采取一个技术：客户端重定向，基于适当的算法（轮换或考虑负载量分配），将对于www.xxx.com单域名的请求客户端重定向到www1.xxx.com--wwwN.xxx.com,然后以后的访问都不变化，这样比较简单。就是说只在第一次访问的时候固定一个子域名。
这种技术我看到IBM的网站似乎是这样用的，会客户端重定向；另外，对于长连接的internet应用，典型的是各类网游，比如ourgame的，就会使用用户选择服务器的方式来达到负载均衡的目的，实际就是有多台服务器，让你自己选择物理位置近的，或者可以自动侦测，也不失为一个可行的办法。

用可以实现负载均衡的交换机，对外提供一个虚IP，让交换机将客户的请求均分到不同的服务器

银行的交易报文就是长连接，不过他是层层转发了。前端<-->前置<-->核心，当然实际可能更多层，所以每层面对的客户端都会比较少，由于交易频繁，当然是采用长连接了，否则每次都重新建立开销太大。我见过的银行系统都是采用：单工长连接，这种方式处理报文效率会比较高。难道交互频繁还不构成理由吗？

楼主的问题：
   我猜想楼主要做的事情场景是：一客户端发送图片到服务器，然后服务器通知其他客户。
   如果发送图片这个场景不频繁的话，可以考虑短连接，当然如果既要频繁，客户端多，除了增加提高服务器性能，增加服务器外没有好办法了。
  服务器主动发送给客户端这步应是可以采用UDP吧，当心丢包就对包做个记录，客户端受到必须给一个回应就是。