我们有个应用，基本架构是前面有几个API网关，后面有多个有状态的服务节点，用户的操作都是走API网关，API网关把请求转发给客户对应的服务节点。自然我们希望服务节点的负载尽量平均。
因为服务节点都是一样的硬件配置，每个客户的消耗的资源也基本一致，我们直接使用每个服务节点的登录客户数来表示服务节点的负载。
看一下登录的流程：
- 客户向API网关发起登录请求
- API网关找到负载最小的服务节点（负载信息都保存在一个Redis中）
- 向找到的服务节点转发登录请求
- 服务节点登录成功，更新负载信息（也就是客户数），登录失败不更新
从API网关查到负载最小的服务节点，到这个节点更新负载信息是有一定时间的（登录耗时），这就导致了高并发的时候，会有大量的请求分到同一个服务节点。
例如有两个节点，负载分别是4和5，这时API网关同时收到10个请求，这10个请求会都分给负载4的节点，然后它的负载变成14。下一波请求来的时候又给会发给5的节点，抖动很大。
怎么解决呢？
方法一是在API网关记录节点负载信息，请求过来马上更新，然后再转发，当然要准确的负载信息还是很麻烦的，例如API网关要知道每个节点登录的客户数，还要处理登录失败的情况。
方法二就是这篇文章标题，随机二选一，即：从全部服务节点中随机选2台，然后选择负载较小的一台作为结果，实现要简单很多。
理论上，把n个请求分给n个节点，完全随机分配时，很大概率下最大的节点会收到O(log n / log log n)个请求，而随机K选一会收到O(log log n / log k)。
参考：
- When Simple Wins: The Power of Two Random Choices，在这篇文章中第一次知道这个方法
- Cache eviction: when are randomized algorithms better than LRU?，对于大的缓存，随机二选一比LRU好
