Open AlexiaChen opened 4 years ago
高性能是所有程序员的追求，无论是做底层系统还是做应用App，我们都希望在成本内尽可能的优化性能。它是最复杂的一环，磁盘，操作系统，CPU，内存，缓存，网络，编程语言，架构都有可能影响系统整体达到高性能呢个，一行不恰当的debug日志就可能把一个高性能服务器拖慢成龟速。一个服务器配置的参数，比如tcp_nodelay就可能将响应时间从2ms延长到40ms。
站在架构的角度，当然需要关注高性能的架构，关注在两个方面：
尽量提升单机服务器的性能，将单服务器的性能发挥到极致。
如果单服务器无法支撑性能， 设计服务器集群方案。
架构设计是高性能的基础，如果架构设计没有做到高性能，则后面的具体实现和编码能提升的空间有限。简单一句话就是，架构决定了系统的性能上限，具体实现细节决定了性能下限。
这里主要讲服务器端的网络高并发的性能
关键之一就是服务端采取的网络编程模型，有以下两个设计关键点：
服务器如何管理连接
服务器如何处理请求
以上两个设计点最终都和操作系统的I/O模型及进程模型相关。
I/O模型:阻塞，非阻塞，同步，异步
进程模型： 单进程，多进程，多线程
标题的字面意思就是，一个连接对应一个进程处理。每次有新的连接过来就新建一个进程专门处理这个连接的请求。大概是以下步骤：
父进程接受连接（accept）
父进程fork出子进程
子进程处理连接的读写请求（read， write，业务逻辑处理）
子进程关闭连接（close）
同一个文件描述符多进程访问是有引用计数的，计数到0才会真正关闭连接。
该模型非常简单，最早的服务器网络模型大部分是这么搞的，但是随着互联网兴起，这模型才没落了，因为代价太高。
fork代价高：操作系统创建一个进程的代价很高，需要分配很多内核资源，需要将内存镜像从父进程复制到子进程。即使现代操作在复制内存镜像的时候用到了写时复制技术，但是代价还是太大。
父子进程通信复杂： 父进程fork子进程时，文件描述符可以通过内存镜像复制从父进程传到子进程，但是fork完成后，父子通信就比较麻烦了，需要采用IPC（Interprocess Communication）之类的进程通信方案。
进程数量增大对操作系统压力大，进程切换，调度等等。所以，一般这种方案能处理的并发连接数最大也就几百。
也就是服务器启动的时候，预先fork出多个子进程，这样连接过来的时候就不需要fork了，这样用户端的感受就是，速度快了些。
prefork实现的关键就是，多个子进程都accept同一个socket，当有新的连接进入时，操作系统保证只有一个进程能最后accept成功。不必担心引入额外的性能开销。
当然，问题也存在，就是父子通信复杂，支持的并发连接数有限。但Apache服务器提供了MPM prefork模式。现在很少用了，除非是一些老系统。
就是一个新连接，就建立一个线程去处理这个连接请求（write read 业务逻辑处理）。与进程相比，当然会更轻量些，创建线程的消耗要比进程少得多。同时多线程是共享同一个进程的内存空间，通信成本会低些。
父进程创建出子线程（pthread）
子线程处理连接的读写请求（read， write，业务逻辑处理）
子线程关闭连接（close）
该模型确实是一个进步，但是也有问题：
高并发时，还是有性能问题
线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题
因为多线程共享同一个内存地址空间，一个线程crash，那么整个进程就崩溃了，互相影响太多。稳定性差点。
CPU线程调度和切换代价。
该模型处理近一千个并发连接还是有问题的，如果是几百个并发，还不如用one Process per connection的模型，因为稳定性更高。
预先创建处理请求的线程，和prefork类似。让用户体验更快。
由于是同一进程内的多线程，通信方便，prethread的实现要比prefork灵活些。大概有下面两种方式：
主进程accept，然后将连接交给某个线程处理。
所有子线程都尝试去accept，最终只有一个线程accept成功
Apache服务器的MPM worker模式本质就是一种prethread方案，但是稍微做了改进，服务器创建多个进程，每个进程又有多个线程，主要是考虑稳定性，因为其中某个线程异常崩溃，不至于导致整个服务器挂掉，还有其他进程提供继续提供服务。
重点来了，该模型是现代互联网高并发的基础模型。
前面说的用多线程，多进程或者两者结合，或者引入线程池就会引入一个新的问题，进程如何才能高效的处理多个连接的业务？当一个连接一个线程时，线程可以采用"read -> 业务逻辑处理 -> write" 这种处理流程，如果当前连接没有数据可以读，则进程就阻塞在read操作上。这种阻塞的方式在一个连接一个线程的场景下没问题，但是如果一个线程处理多个连接，线程阻塞在某个连接的read操作上，即使此时此刻其他连接有数可以读，线程也无法去处理，很显然这是无法做到高性能的。
解决这个问题就最简单的就是将read操作改为非阻塞，然后线程不断地while去轮询多个连接。这种方式能解决阻塞带来的低效问题，但是不优雅，首先，轮询是要消耗CPU的，其次一个线程处理几千上万个连接，则轮询的效率就很低了。
为了能更好的解决问题，一种自然而然的想法就是只有当连接上有数据的时候，线程才去处理，这就是I/O多路复用技术的来源。
上面提到的“多路”就是多条连接，“复用”就是多条连接复用同一个阻塞对象，这个阻塞对象和具体的实现有关。在Linux上如果使用select，那么这个公共阻塞对象就是select用到的fd_set，如果是epoll，就是epoll_create创建的文件描述符。
I/O多路复用有两个关键实现点：
当多条连接共用一个阻塞对象后，进程（I/O线程）只需要在一个阻塞对象上等待，而无须再轮询所有连接。
当某条连接有新的数据可以处理时，操作系统就会通知进程(I/O线程)，线程从阻塞状态返回，开始进行业务处理
I/O多路复用结合线程池，完美的解决了之前所提到的模型的所有问题。而且有个很酷的名字-----Reactor，就是反应堆。实质就是事件反应的意思，就是来了一个事件，我就有相应的反应。有些开源系统里面叫Dispatcher模式，即I/O多路服用统一监听事件，收到事件后分配(Dispatch)给某个线程处理。
Reactor模式的核心组成部分包括Reactor和线程池，Reactor负责监听和分配事件，线程池负责处理事件。感觉起来简单嘛，但是不是，Reactor模式具体实现方案灵活多变。主要体现以下两点：
Reactor的数量可以变化： 可以是一个Reactor，也可以是多个Reactor。也就是陈硕经常说的one loop per thread。一个loop一个线程，loop就是所谓的事件循环监听。
线程池的数量也可以变化：可以是单线程，也可以是多线程。当然也可以是单进程或多进程。
最终Reactor模式有以下三种典型实现方案：
单Reactor 单进程/单线程
单Reactor 多线程
多Reactor 多进程/多线程 （陈硕最喜欢这个）
以上方案具体选择进程还是线程，更多的是个人口味。Java的高性能网络库Netty用的是线程，Nginx使用进程，memcached使用线程。
Reactor对象通过select或者epoll监控连接事件，收到事件后通过dispatch进行分发
如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件。
如果不是连接建立的事件，则Reactor会调用连接对应的Handler来进行响应
Handler会完成read -> 业务逻辑处理 -> send的完整业务流程
该模式优点简单，没有进程/线程间通信，没有竞争，全部在同一个进程内完成，但是缺点也明显:
只有一个进程/线程，无法发挥多核CPU的性能，只能采取部署多个系统来利用多核CPU。
Handler在处理某个连接上的业务时，整个进程无法处理其他连接的事件，很容易导致性能瓶颈
因此，单Reactor单进程的方案在实践中应用场景不多，只适用业务处理非常快速的场景，业界的Redis用的就是这个模型，因为它是数据结构服务器，修改各种数据结构一般不会太耗时。
为了避免单Rector 单进程/单线程方案的缺点，由此改进的模型
主I/O线程中，Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发。
如果不是连接建立事件，则Reactor会调用连接对应的Handler来进行响应。
Handler只负责响应事件，不进行业务处理。Handler通过read读取到数据后，会发给Worker进行业务处理
Worker会在独立的子线程中完成真正的业务处理，然后将响应结果发给主I/O线程的Handler处理，Handler收到响应后，通过send将响应结果返回给client。
该模型能够充分利用多核多CPU的处理能力，但是也有问题存在:
单个Reactor承担所有事件的监听和响应，只在主I/O线程中运行，难以应对瞬时高并发访问，也就是突发高并发事件。这样会有单点性能瓶颈。
这个方案在保证上一个方案模型优点的同时，也解决了应对瞬时高并发访问的问题。
父I/O线程中rootReactor对象通过select或epoll监控连接建立事件，收到事件后通过Acceptor接收，将新的连接分配给某个子线程。
子I/O线程的subReactor将rootReactor分配的连接加入连接队列进行监听，并创建一个Handler用于处理连接的各种事件。
当有新的事件发生的时候，subReactor会调用连接对应的Handler来进行响应。
Handler完成read -> 业务处理 -> send的完整业务流程
看起来这个模型比单Reactor多线程复杂，但是实际实现更简单，而且优点多多：
父I/O线程和子I/O线程的职责非常明确，父线程只负责接收（accept）新的连接（只处理连接建立事件），子线程完成后续的各种事件和业务处理。
父线程和子线程的互交简单，父线程需要把新连接传给子线程，子线程无须返回数据
子线程之间也是互相独立的，无须同步共享select，read send之类的网络处理，我自己读，自己发数据。
目前Nginx是采用多Reactor多进程，memcahed和Netty是多Reactor多线程。
Reactor是非阻塞同步网络模型，因为真正的read，send网络操作都需要用户进程同步操作，简而言之就是read和send这样的I/O操作是同步的（epoll也是同步的），如果把I/O操作换成异步就能够进一步提升性能，这就是异步网络模型Proactor。
Proactor翻译为--前摄器模式，它与Reactor有啥区别呢？
Reactor是，来了I/O事件（Event），操作系统内核来通知用户，用户自己来处理（用户自己read）。
Proactor是，来了I/O事件，操作系统内核来处理，处理完成内核主动通知用户（内核read到的数据直接通过回调给到用户）
其实用大白话说就是Reactor是被动，Proactor是主动。
Proactor的主要处理步骤如下：
Proactor Initiator负责创建Proactor和Handler，并将Proactor和Handler都通过异步I/O操作注册到操作系统内核
异步I/O操作负责处理注册请求，并完成I/O操作（read send）
异步I/O操作完成I/O操作后，通知Proactor
Proactor根据不同的事件类型回调不同的Handler进行业务处理
Handler完成业务处理，Handler也可以注册新的Handler到内核
理论上，Proactor比Reactor性能高一些，异步I/O能够充分利用DMA特性，让I/O操作与计算同时进行。但实现真正的异步I/O，操作系统需要做大量的工作，windows下的IOCP实现了真正的异步I/O，而Linux下的AIO并不完善，因此Linux下实现高并发网络编程都是以Reactor这样的同步模式为主。boost::asio实现了Proactor在windows下采用了IOCP，但是在Linux下用的是Reactor（epoll）模式之上模拟出来一个Proactor异步模型。
主要是负载均衡了，包括DNS，硬件负载均衡，软件负载均衡。
DNS成本低，负载均衡基本上交给DNS服务器处理，无须自己开发维护负载均衡设备，就近原则，提高访问速度，缺点也多多，DNS缓存的时间比较长，修改配置后，用户还会访问修改前的IP，达到负载失败，DNS的负载均衡控制权在域名商那里，无法根据业务特点做定制扩展。（一般用于地理级别的负载均衡）
硬件负载均衡成本高，但是功能强大，全面支持各个层级，各个负载均衡算法，支持全局负载均衡。软件负载均衡支持到100K级别已经非常厉害，但是硬件负载均衡可以支持1000k并发。然后稳定性又高，还具备防火墙，防DDoS的攻击的安全功能。缺点就是扩展性差，价格普通公司承受不起。比如F5。（一般用于机房集群级别的负载均衡，比如北京机房有多个集群，这一个机房用一台F5设备，来负载集群与集群之间的负载）
软件负载均衡有Nginx和LVS。Nginx是7层负载均衡，LVS是4层负载均衡。Nginx支持http等协议，LVS因为太底层，与协议无关，所有几乎所有应用都可以做，比如聊天和数据库等。（一般用于集群内部机器之间的负载均衡）
负载均衡算法也就是网络上罗列的那几样，参考着选择就行。
网络高性能
高性能是所有程序员的追求，无论是做底层系统还是做应用App，我们都希望在成本内尽可能的优化性能。它是最复杂的一环，磁盘，操作系统，CPU，内存，缓存，网络，编程语言，架构都有可能影响系统整体达到高性能呢个，一行不恰当的debug日志就可能把一个高性能服务器拖慢成龟速。一个服务器配置的参数，比如tcp_nodelay就可能将响应时间从2ms延长到40ms。
站在架构的角度，当然需要关注高性能的架构，关注在两个方面：
尽量提升单机服务器的性能，将单服务器的性能发挥到极致。
如果单服务器无法支撑性能， 设计服务器集群方案。
架构设计是高性能的基础，如果架构设计没有做到高性能，则后面的具体实现和编码能提升的空间有限。简单一句话就是，架构决定了系统的性能上限，具体实现细节决定了性能下限。
这里主要讲服务器端的网络高并发的性能
单服务器网络高性能
关键之一就是服务端采取的网络编程模型，有以下两个设计关键点：
服务器如何管理连接
服务器如何处理请求
以上两个设计点最终都和操作系统的I/O模型及进程模型相关。
I/O模型:阻塞，非阻塞，同步，异步
进程模型： 单进程，多进程，多线程
one Process per connection
标题的字面意思就是，一个连接对应一个进程处理。每次有新的连接过来就新建一个进程专门处理这个连接的请求。大概是以下步骤：
父进程接受连接（accept）
父进程fork出子进程
子进程处理连接的读写请求（read， write，业务逻辑处理）
子进程关闭连接（close）
同一个文件描述符多进程访问是有引用计数的，计数到0才会真正关闭连接。
该模型非常简单，最早的服务器网络模型大部分是这么搞的，但是随着互联网兴起，这模型才没落了，因为代价太高。
fork代价高：操作系统创建一个进程的代价很高，需要分配很多内核资源，需要将内存镜像从父进程复制到子进程。即使现代操作在复制内存镜像的时候用到了写时复制技术，但是代价还是太大。
父子进程通信复杂： 父进程fork子进程时，文件描述符可以通过内存镜像复制从父进程传到子进程，但是fork完成后，父子通信就比较麻烦了，需要采用IPC（Interprocess Communication）之类的进程通信方案。
进程数量增大对操作系统压力大，进程切换，调度等等。所以，一般这种方案能处理的并发连接数最大也就几百。
prefork
也就是服务器启动的时候，预先fork出多个子进程，这样连接过来的时候就不需要fork了，这样用户端的感受就是，速度快了些。
prefork实现的关键就是，多个子进程都accept同一个socket，当有新的连接进入时，操作系统保证只有一个进程能最后accept成功。不必担心引入额外的性能开销。
当然，问题也存在，就是父子通信复杂，支持的并发连接数有限。但Apache服务器提供了MPM prefork模式。现在很少用了，除非是一些老系统。
one thread per connection
就是一个新连接，就建立一个线程去处理这个连接请求（write read 业务逻辑处理）。与进程相比，当然会更轻量些，创建线程的消耗要比进程少得多。同时多线程是共享同一个进程的内存空间，通信成本会低些。
父进程接受连接（accept）
父进程创建出子线程（pthread）
子线程处理连接的读写请求（read， write，业务逻辑处理）
子线程关闭连接（close）
该模型确实是一个进步，但是也有问题：
高并发时，还是有性能问题
线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题
因为多线程共享同一个内存地址空间，一个线程crash，那么整个进程就崩溃了，互相影响太多。稳定性差点。
CPU线程调度和切换代价。
该模型处理近一千个并发连接还是有问题的，如果是几百个并发，还不如用one Process per connection的模型，因为稳定性更高。
prethread
预先创建处理请求的线程，和prefork类似。让用户体验更快。
由于是同一进程内的多线程，通信方便，prethread的实现要比prefork灵活些。大概有下面两种方式：
主进程accept，然后将连接交给某个线程处理。
所有子线程都尝试去accept，最终只有一个线程accept成功
Apache服务器的MPM worker模式本质就是一种prethread方案，但是稍微做了改进，服务器创建多个进程，每个进程又有多个线程，主要是考虑稳定性，因为其中某个线程异常崩溃，不至于导致整个服务器挂掉，还有其他进程提供继续提供服务。
Reactor
重点来了，该模型是现代互联网高并发的基础模型。
前面说的用多线程，多进程或者两者结合，或者引入线程池就会引入一个新的问题，进程如何才能高效的处理多个连接的业务？当一个连接一个线程时，线程可以采用"read -> 业务逻辑处理 -> write" 这种处理流程，如果当前连接没有数据可以读，则进程就阻塞在read操作上。这种阻塞的方式在一个连接一个线程的场景下没问题，但是如果一个线程处理多个连接，线程阻塞在某个连接的read操作上，即使此时此刻其他连接有数可以读，线程也无法去处理，很显然这是无法做到高性能的。
解决这个问题就最简单的就是将read操作改为非阻塞，然后线程不断地while去轮询多个连接。这种方式能解决阻塞带来的低效问题，但是不优雅，首先，轮询是要消耗CPU的，其次一个线程处理几千上万个连接，则轮询的效率就很低了。
为了能更好的解决问题，一种自然而然的想法就是只有当连接上有数据的时候，线程才去处理，这就是I/O多路复用技术的来源。
上面提到的“多路”就是多条连接，“复用”就是多条连接复用同一个阻塞对象，这个阻塞对象和具体的实现有关。在Linux上如果使用select，那么这个公共阻塞对象就是select用到的fd_set，如果是epoll，就是epoll_create创建的文件描述符。
I/O多路复用有两个关键实现点：
当多条连接共用一个阻塞对象后，进程（I/O线程）只需要在一个阻塞对象上等待，而无须再轮询所有连接。
当某条连接有新的数据可以处理时，操作系统就会通知进程(I/O线程)，线程从阻塞状态返回，开始进行业务处理
I/O多路复用结合线程池，完美的解决了之前所提到的模型的所有问题。而且有个很酷的名字-----Reactor，就是反应堆。实质就是事件反应的意思，就是来了一个事件，我就有相应的反应。有些开源系统里面叫Dispatcher模式，即I/O多路服用统一监听事件，收到事件后分配(Dispatch)给某个线程处理。
Reactor模式的核心组成部分包括Reactor和线程池，Reactor负责监听和分配事件，线程池负责处理事件。感觉起来简单嘛，但是不是，Reactor模式具体实现方案灵活多变。主要体现以下两点：
Reactor的数量可以变化： 可以是一个Reactor，也可以是多个Reactor。也就是陈硕经常说的one loop per thread。一个loop一个线程，loop就是所谓的事件循环监听。
线程池的数量也可以变化：可以是单线程，也可以是多线程。当然也可以是单进程或多进程。
最终Reactor模式有以下三种典型实现方案：
单Reactor 单进程/单线程
单Reactor 多线程
多Reactor 多进程/多线程 （陈硕最喜欢这个）
以上方案具体选择进程还是线程，更多的是个人口味。Java的高性能网络库Netty用的是线程，Nginx使用进程，memcached使用线程。
单Reactor 单进程 or 单线程
Reactor对象通过select或者epoll监控连接事件，收到事件后通过dispatch进行分发
如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件。
如果不是连接建立的事件，则Reactor会调用连接对应的Handler来进行响应
Handler会完成read -> 业务逻辑处理 -> send的完整业务流程
该模式优点简单，没有进程/线程间通信，没有竞争，全部在同一个进程内完成，但是缺点也明显:
只有一个进程/线程，无法发挥多核CPU的性能，只能采取部署多个系统来利用多核CPU。
Handler在处理某个连接上的业务时，整个进程无法处理其他连接的事件，很容易导致性能瓶颈
因此，单Reactor单进程的方案在实践中应用场景不多，只适用业务处理非常快速的场景，业界的Redis用的就是这个模型，因为它是数据结构服务器，修改各种数据结构一般不会太耗时。
单Reactor 多线程
为了避免单Rector 单进程/单线程方案的缺点，由此改进的模型
主I/O线程中，Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发。
如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件。
如果不是连接建立事件，则Reactor会调用连接对应的Handler来进行响应。
Handler只负责响应事件，不进行业务处理。Handler通过read读取到数据后，会发给Worker进行业务处理
Worker会在独立的子线程中完成真正的业务处理，然后将响应结果发给主I/O线程的Handler处理，Handler收到响应后，通过send将响应结果返回给client。
该模型能够充分利用多核多CPU的处理能力，但是也有问题存在:
单个Reactor承担所有事件的监听和响应，只在主I/O线程中运行，难以应对瞬时高并发访问，也就是突发高并发事件。这样会有单点性能瓶颈。
多Reactor 多进程 or 多线程
这个方案在保证上一个方案模型优点的同时，也解决了应对瞬时高并发访问的问题。
父I/O线程中rootReactor对象通过select或epoll监控连接建立事件，收到事件后通过Acceptor接收，将新的连接分配给某个子线程。
子I/O线程的subReactor将rootReactor分配的连接加入连接队列进行监听，并创建一个Handler用于处理连接的各种事件。
当有新的事件发生的时候，subReactor会调用连接对应的Handler来进行响应。
Handler完成read -> 业务处理 -> send的完整业务流程
看起来这个模型比单Reactor多线程复杂，但是实际实现更简单，而且优点多多：
父I/O线程和子I/O线程的职责非常明确，父线程只负责接收（accept）新的连接（只处理连接建立事件），子线程完成后续的各种事件和业务处理。
父线程和子线程的互交简单，父线程需要把新连接传给子线程，子线程无须返回数据
子线程之间也是互相独立的，无须同步共享select，read send之类的网络处理，我自己读，自己发数据。
目前Nginx是采用多Reactor多进程，memcahed和Netty是多Reactor多线程。
Proactor
Reactor是非阻塞同步网络模型，因为真正的read，send网络操作都需要用户进程同步操作，简而言之就是read和send这样的I/O操作是同步的（epoll也是同步的），如果把I/O操作换成异步就能够进一步提升性能，这就是异步网络模型Proactor。
Proactor翻译为--前摄器模式，它与Reactor有啥区别呢？
Reactor是，来了I/O事件（Event），操作系统内核来通知用户，用户自己来处理（用户自己read）。
Proactor是，来了I/O事件，操作系统内核来处理，处理完成内核主动通知用户（内核read到的数据直接通过回调给到用户）
其实用大白话说就是Reactor是被动，Proactor是主动。
Proactor的主要处理步骤如下：
Proactor Initiator负责创建Proactor和Handler，并将Proactor和Handler都通过异步I/O操作注册到操作系统内核
异步I/O操作负责处理注册请求，并完成I/O操作（read send）
异步I/O操作完成I/O操作后，通知Proactor
Proactor根据不同的事件类型回调不同的Handler进行业务处理
Handler完成业务处理，Handler也可以注册新的Handler到内核
理论上，Proactor比Reactor性能高一些，异步I/O能够充分利用DMA特性，让I/O操作与计算同时进行。但实现真正的异步I/O，操作系统需要做大量的工作，windows下的IOCP实现了真正的异步I/O，而Linux下的AIO并不完善，因此Linux下实现高并发网络编程都是以Reactor这样的同步模式为主。boost::asio实现了Proactor在windows下采用了IOCP，但是在Linux下用的是Reactor（epoll）模式之上模拟出来一个Proactor异步模型。
集群高性能
主要是负载均衡了，包括DNS，硬件负载均衡，软件负载均衡。
DNS成本低，负载均衡基本上交给DNS服务器处理，无须自己开发维护负载均衡设备，就近原则，提高访问速度，缺点也多多，DNS缓存的时间比较长，修改配置后，用户还会访问修改前的IP，达到负载失败，DNS的负载均衡控制权在域名商那里，无法根据业务特点做定制扩展。（一般用于地理级别的负载均衡）
硬件负载均衡成本高，但是功能强大，全面支持各个层级，各个负载均衡算法，支持全局负载均衡。软件负载均衡支持到100K级别已经非常厉害，但是硬件负载均衡可以支持1000k并发。然后稳定性又高，还具备防火墙，防DDoS的攻击的安全功能。缺点就是扩展性差，价格普通公司承受不起。比如F5。（一般用于机房集群级别的负载均衡，比如北京机房有多个集群，这一个机房用一台F5设备，来负载集群与集群之间的负载）
软件负载均衡有Nginx和LVS。Nginx是7层负载均衡，LVS是4层负载均衡。Nginx支持http等协议，LVS因为太底层，与协议无关，所有几乎所有应用都可以做，比如聊天和数据库等。（一般用于集群内部机器之间的负载均衡）
负载均衡算法也就是网络上罗列的那几样，参考着选择就行。