关于 redis 一个小问题(随机性)

失效 IP 比例不高的话，可以方案二 + 再维护一个 set ，命中则再从 list 取一次

因为同一个 ip 可以同时执行很多请求， 如果用的时候从列表中移除，挺耽误效率的。

针对失效 ip 的问题我是这么解决的，分两块， 第一单独开一个线程定期扫描 ip 库添加可用的 ip 到 set 中。第二用的时候随机取， 但是需要封装统一 http 请求捕获异常，并且把请求超时时间设置的比较短。 当发生任何请求失败时从 redis set 中删除这个 ip ， 这样基本上可以保证可用 ip 池都是新鲜可用的， 唯一的缺点就是失败的请求要重新取 ip 重试， 耽误几秒钟

zset 存 ip ，每次取 score 最小的，然后将这个 ip 的 score+1

好像可以使用一致性哈希算法来解决

list 也可以移除 ip 吧

127.0.0.1:6379> lpush test a
(integer) 1
127.0.0.1:6379> lpush test b
(integer) 2
127.0.0.1:6379> lpush test c
(integer) 3
127.0.0.1:6379> lrange test 0 -1
1) "c"
2) "b"
3) "a"
127.0.0.1:6379> lrem test 0 b
(integer) 1
127.0.0.1:6379> lrange test 0 -1
1) "c"
2) "a"
127.0.0.1:6379>

@mineralsalt set 得问题方案 1 说到了, 非随机, 实际调用下来 多的跟少的能差一倍调用量, 另外 就是无法按照 12345678910 这个顺序 轮训使用 所以 不符合我的需求

@zjp 感觉是一个好方案, 其实不用 set 命中了应该按照 7 楼说的直接删除也行 我测一下

@xuanbg 用过这种方案, 并发不高的时候没问题,但是高并发的时候 做不到轮训的效果, 会导致某一个 ip 被连续取到多次

@pastgift 感觉像是正解 , 感谢 我测一下

@18870715400 我查一下, 触及到我的盲区了 哈哈

@golangggg #8 那说明你的 ip 池比较小吧， 我 100 多个 ip 感觉还行， 如果强行加锁给每个 ip 都设定权重，就会影响并发效率， 怎么取舍就看你了

@golangggg 并发你得加锁啊，不加锁任你什么方案都扯淡。

为什么不用 nginx 的 tcp 负载均衡