因为使用了非线程安全的集合，所以在访问操作时操作的是集合的拷贝，下面几种轮训方式中也是这种思想。

轮训访问就简单多了，拿上面的熊1到熊4来说，我们一个接一个的啪啪 - 打脸，熊1打完打熊2，熊2打完打熊3，熊4打完打熊1，最终也是实现了被打均衡。但是保证均匀总是要付出代价的，随机访问中需要随机，轮训访问中需要什么来保证轮训呢？

由代码里可以看出来，为了保证轮训，必须记录上次访问的位置，为了让在并发情况下不出现问题，还必须在使用位置记录时进行加锁，很明显这种互斥锁增加了性能开销。

上面演示了轮训方式，还记的一开始提出的熊4比较胖抗击打能力强，可以承受别人2倍的挨打次数嘛？上面两种方式都没有体现出来熊 4 的这个特点，熊 4 窃喜，不痛不痒。但是熊 1 到 熊 3 已经在崩溃的边缘，不行，我们必须要让胖着多打，能者多劳，提高整体性能。

随机加权的方式和轮训加权的方式大致相同，只是把使用互斥锁轮训的方式换成了随机访问，按照概率论来说，访问量增多时，服务访问也会达到负载均衡。

上面的几种方式要么使用随机数，要么使用轮训，最终都达到了请求的负载均衡。但是也有一个很明显的缺点，就是同一个用户的多次请求很有可能不是同一个服务进行处理的，这时问题来了，如果你的服务依赖于 session ，那么因为服务不同， session 也会丢失，不是我们想要的，所以出现了一种根据请求端的 ip 进行哈希计算来决定请求到哪一台服务器的方式。这种方式可以保证同一个用户的请求落在同一个服务上。