关于高并发的两个问题？

Question

1.都说要负载均衡，但是一开始的时候总得有一个服务器和客户端建立连接，并通知客户端和哪个负载服务器建立连接，或者把客户端的请求转交给负载服务器。那么一开始的大数据量的连接请求和数据传输是如何处理的？
我的猜测：是不是处理千万级的Tcp socket连接并不存在问题？这里有一篇文章。
还有一开始进行负载均衡需要传输的数据量比较少，所以也不存在问题？

2.面试的时候问到一个问题，怎么设计一个IM的登陆系统，同时处理千万级的并发登陆。如果我上面的猜想是正确的，那么是不是一台性能比较强的服务器就能处理登陆请求？因为登陆的数据量并不大。真正占用服务器资源的是登陆后的业务逻辑操作。

Answer 1

我把你的两个问题合并起来回答吧。
第一，你想的方向没问题，但是如果一个服务器同时维护千万级的TCP连接(即C10M Problem)，是一件非常困难的事情，需要kernel支持/在用户态里实现TCP协议解析与Procedure调度减小开销。譬如如果你针对每一个连接开一个线程去处理，那么在常见的x86 Linux server每个线程上需要4k的空间，那么你至少需要数十G的内存来处理，还不算线程里需要给你程序开辟的空间。
第二，登录这个过程也许client发给server的数据包不大，但是server处理过程是需要耗时的(更新DB等)。和上面一点相似，所以不会把这个流程放在一个server里处理。

以上均没有考虑服务可用性等因素，你可以想象下如果这个这个server单点压力过大crash了该怎么办呢。

Answer 2

这个还涉及到了一些网络基础知识，有空补个长文来填填这个坑。。

这个地方我们谈高并发是在谈什么？

为什么作负载均衡的处理量会高于放在后面的服务器？

其实服务器的连接数是受网络限制的，硬件，系统，网络状况，都会成为限制条件。服务器所能承载的并发，你可以理解成一个餐馆，一个餐馆就只能坐那么多人，如果你是快餐，来的人多去的人快，在单位时间内的人流量就大，如果你是精致的西餐，出菜慢，单位时间人流量就小。
人流量就是并发，而做菜时间就是我们的响应时间。

这就是为什么服务器会有并发上限，需要开分店增加并发量。

那么为什么负载均衡可以承接更多的流量呢？

负载均衡也是一台服务器，他的并发量也有上限，负载均衡是街边小摊，1分钟做好打包拿走。

负载均衡也有小部分业务，检测后端状态，转发请求，但是相比你后面的业务要去读写 SQL，Redis 什么的，那就简单太多，也就快太多。

当然如果业务量大了也是要上集群的。。这肯定是必然的。

这样解释起来，你可能理解起来要容易些，0 - 0 至于里面比较深的网络问题，以后开长文详细解释吧。。

Answer 3

一个服务器专门处理你说的连接问题，就是负载均衡啊。nginx+php普通服务器每秒上百个页面，但是如果那台服务器只用来做nginx的转发功能，每秒上万个都是小意思。

Answer 4

理论：

在整个网络里，只要某一级设备，对后一级设备有负载均衡功能，那么从后一级开始就可以搭建负载均衡系统了。

实际：

在现实中，用户居住地、办公室、厂房等，接入运营商线路，然后运营商的这些线路汇集到第一台网络设备。这种设备自身没有负载均衡功能，性能不够时只能更换为性能更强的设备。这种设备，对后面的设备，有负载均衡功能，因此负载均衡系统就这么构建起来了。

后面继续下去应该是运营商机房的网络设备 -> 地区DNs -> 互联网公司的运营商接入线路 -> 互联网公司的流量转发设备 -> 互联网公司的业务处理设备。后面的这些节点，每一级都可以做负载均衡。

案例：

有了上面两个例子，你要做的那个登录服务器就很简单了，直接做服务器集群来负载均衡就行。