负载均衡最低优先算法基本上能够比较完美地解决轮询算法的缺点，因为采用这种算法后，负载均衡系统需要感知服务器当前的运行状态。当然，其代价是复杂度大幅上升。通俗来讲，轮询可能是5行代码就能实现的算法(其实JS的定时任务就能做好，同样Spring的定时任务也能)，而负载最低优先算法可能要1000行才能实现，甚至需要负载均衡系统和服务器都要开发代码。负载最低优先算法如果本身没有设计好，或者不适合业务的运行特点，算法本身就可能成为性能的瓶颈，或者引发很多莫名其妙的问题。所以负载最低优先算法虽然效果看起来美好，但实际上真正应用的场景反而没有轮询(包括加权轮询)那么多。
4.性能最优类
负载最低优先类算法是站在服务器的角度来进行分配的，而性能最优优先类算法则是站在客户端的角度进行分配的，优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的。
和负载最低优先类算法类似，性能最优优先类算法本质上也是感知了服务器的状态，只是通过响应时间这个外部标准来衡量服务器状态而已。因此性能最优优先类算法存在的问题和负载最低优先类算法类似，复杂度都很高，主要体现在:
(1)负载均衡系统需要收集和分析每个服务器每个任务的响应时间，在大量任务处理的场景下，这种收集和统计本身也会收集较多的性能；
(2)为了减少这种统计上的消耗，可以采取采样的方式来统计，即不统计所有任务的响应时间，而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样统计
虽然能够减少性能消耗，但使得复杂度进一步提升，因为要确定合适的采样率，采样率太低会导致结果不准确，采样率太高会导致性能消耗较大，找到合适的采样率是一件复杂的事情；
(3)无论是全部统计还是采样统计，都需要选择合适的周期:是10秒内性能最优，还是1分钟内性能最优，还是5分钟内性能最优，需要根据实际业务进行判断和选择，同时这也是一件比较复杂的事情，甚至出现系统上线后需要不断调优才能达到最优设计；
5.Hash类
负载均衡系统根据任务中的某些关键信息进行Hash运算，将相同Hahs值的请求分配到同一台服务器上，这样做的目的主要为了满足特定的业务需求。
(1)源地址Hash
将来源于同一个源IP地址的任务分配给同一个服务器进行处理，适合于存在事务、会话的业务。例如，当我们通过浏览器登录网上银行时，会生成一个会话信息，这个会话是临时的，关闭浏览器后就失效。网上银行后台无须持久化会话信息，只需要在某台服务器上临时保存这个会话就可以了，但需要保证用户在会话存在期间，每次都能访问到同一个服务器，这种业务场景就可以用源地址Hash来实现。
(2)ID Hash
将某个ID标识的业务分配到同一个服务器中进行处理，这里的ID一般是临时性数据的ID(如session id)。例如，上述的网上银行登录的例子，用session id hash同样可以实现同一个会话期间，用户每次访问到同一台服务器的目的。
小结:
上面讲的五种负载均衡通常涉及到的算法，目前的话，我涉及到也就是第二种。第一种虽然简单，但是风险太高了。第三种和第四种及其第五种今天我也是刚接触到学习的。
本文主要参考李运华的《从0开始学架构》。
另外在补充一点，有不少朋友买着专栏，刚开始会看一点，后来就不看了，抱着反正已经买了，早看晚看都是看，最终的情况很少有人会去看，这也是一些付费专栏抓到的商机。
其实李运华《从0开始学架构》对我来说启发还是颇多的，至少让我了解架构设计原则和示例，以及常见的坑，当我进行架构设计时，我会参考他的一些想法和建议，当然了，凡是没有绝对，最终的还是得结合实际情况。正如当年中国改革开放取得了很大成绩，也是因为结合了自身的国情，避免重蹈苏联的覆辙。
另外关于架构，就我个人而言，我目前仅仅还只是一个菜鸟或者菜鸟都算不上，不过经过三个项目的改造和设计，吃了不少亏，也算是比小白要强点吧。
今天就写到这了，北京的冬天越来越冷了，我也懒得出去玩，顺便借此机会好好提升自己。