一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。
HAProxy是一个使用C语言编写的自由及开放源代码软件[1],其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理。 HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。 HAProxy实现了一种事件驱动, 单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。 https://github.com/HAProxy/HAProxy 目录:
100-continue 是用于客户端在发送 post 数据给服务器时,征询服务器情况,看服务器是否处理 post 的数据,如果不处理,客户端则不上传 post 是数据,反之则上传。在实际应用中,通过 post 上传大数据时,才会使用到 100-continue 协议。 客户端策略 如果客户端有 post 数据要上传,可以考虑使用 100-continue 协议。在请求头中加入 {“Expect”:”100-continue”} 如果没有 post 数据,不能使用 100-continue 协议,因为这会让服务端造成误解。 并不是所有的 Server 都会正确实现 100-continue 协议,如果 Client 发送 Expect:100-continue 消息后,在 timeout 时间内无响应,Client 需要立马上传 post 数据。 有些 Server 会错误实现 100-continue 协议,在不需要此协议时返回 100,此时客户端应该忽略。 服务端策略 正确情况下,收到请求后,返回 100 或错误码。 如果在发送 100-continue 前收到了 post 数据(客户端提前发送 post 数据),则不发送 100 响应码(略去)。 参考RFC文档:http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3