使用 ZRANGE 获取 ip，可以指定获取的个数，比如取两个：
频道 ip 池
频道 ip 池的作用是为了最大化使用总池子中的 ip，并且隔离其他频道的 ip 池。由于一个 ip 使用次数过多是有很大的概率被目标网站屏蔽掉，所以这里也需要进行择优，应该优先筛选出使用次数少的 ip，同理也是使用 Sorted Sets，使用次数表示 score，ip 表示 member，这里与总池子明显的不同之处是 key 不是固定的，需要把频道名称组合进去，这样保证频道之间的隔离，如频道 abc 的 key：proxy_channel_abc_ips。
由于频道池子中的 ip 是要以独占的方式取出，我们需要一个 ZPOP 的方法，奈何 Redis 本身没有，还好可以通过 Lua 模拟，在一个原子操作下取出 ip，然后删除：
往频道 ip 池添加 ip：
这里与总池子不同的是多了一个 INCR 选项，这是 Redis 3.0.2 版本后才支持的新特性，即指定在 ZADD 时发生 member 冲突采取的处理方式，INCR 顾名思义是冲突后累加 score 的方式，为什么要用这个选项，看看下面这个流程：
在频道池子中只有 1.1.1.1，使用次数为 10；总池子也有 1.1.1.1，而且排在第一个 线程 A 取出 1.1.1.1 线程 B 从频道池子取 ip，没取到，从总池子补充 ip 到频道池子：ZADD proxy_channel_abc_ips 0 1.1.1.1；取出 1.1.1.1 线程 A 归还 1.1.1.1：ZADD proxy_channel_abc_ips 11 1.1.1.1 线程 B 归还 1.1.1.1：ZADD proxy_channel_abc_ips 1 1.1.1.1第 5 步结束后，ip 1.1.1.1 的计数被错误地重置为 1，而不是我们预期的 12。使用 INCR 选项就可以避免这个尴尬，其实这也只能保证最终计数正确，中途还是会有些非预期的情况，如：
在频道池子中有 1.1.1.1，使用次数为 10，还有 2.2.2.2，使用次数为 2；总池子也有 1.1.1.1，而且排在第一个 线程 A 取出 1.1.1.1 线程 B 取出 2.2.2.2 线程 C 从频道池子取 ip，没取到，从总池子补充 ip 到频道池子：ZADD proxy_channel_abc_ips 0 1.1.1.1；取出 1.1.1.1 线程 C 归还 1.1.1.1：ZADD proxy_channel_abc_ips INCR 1 1.1.1.1 线程 B 归还 2.2.2.2：ZADD proxy_channel_abc_ips INCR 3 2.2.2.2 线程 D 来池子取 ip，按使用次数少的被分配了 1.1.1.1，这就不是我们期望的，1.1.1.1 实际已经用了 12 次，我们更希望 2.2.2.2 被取出如果要避免这个问题，一个简单粗暴的办法就是增加频道池子的容量，让 ip 数永远大于并发的线程数。
更新
与 ip 有关的两个属性：延时（爬取页面所花的时间）和使用次数。上面只讲到了根据它们自动择优，这里的就来说下它们是如何更新的。延时和使用次数的更新需要爬虫程序的配合，程序中要记录时间和递增使用次数，在归还 ip 时要将最新值带回给总池子和频道池子。上面频道 ip 池的例子也有提及，每次归还 ip 都要将最新的使用次数带上，其次还要将 ip 的延时更新到总池子里面。如果归还 ip 时出现使用失败的情况，就要将该 ip 从总池子里删除掉，保证该 ip 不会再被使用，至于当前的频道池不用归还就行了。其他频道池不作任何处理，因为 ip 在当前频道不可用，一般都是因为被屏蔽，其他频道依然可以使用，即使确实都不能使用，也会在其他频道归还 ip 时被删除。
这两个属性其实也可以都在 Redis 中更新，在获取 ip 时，使用 Hashs 保存 ip 对应的获取时间和使用次数；在归还时从 Hashs 中取出时间计算出延时，取出使用次数并加 1，再分别更新到总池子和频道池子中。而且这还能避免上面提到的获取 ip 不符合预期的问题。
总结
放在 Redis 中更新的方法也有弊端，延时会包含获取和归还的传输时间，如果爬虫程序获取一个 ip 多次使用，会造成使用次数统计偏少。当然也可以通过在程序中多次调用 Redis 更新 ip 的属性来解决，这样增加了整个流程的复杂性，需要自己权衡。
个人还是倾向在程序中记录，最后更新到 Redis 中。这个方案逻辑确实不够严谨，但是出现问题也不会导致严重后果。程序的健壮性也不是不允许出现 bug，而是出现 bug 有很好的容错性。
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流。
