1
zjp 2023-07-23 02:11:42 +08:00 via Android
失效 IP 比例不高的话,可以方案二 + 再维护一个 set ,命中则再从 list 取一次
|
2
mineralsalt 2023-07-23 02:25:38 +08:00
因为同一个 ip 可以同时执行很多请求, 如果用的时候从列表中移除,挺耽误效率的。
|
3
mineralsalt 2023-07-23 02:29:46 +08:00
针对失效 ip 的问题我是这么解决的,分两块, 第一单独开一个线程定期扫描 ip 库添加可用的 ip 到 set 中。第二用的时候随机取, 但是需要封装统一 http 请求捕获异常,并且把请求超时时间设置的比较短。 当发生任何请求失败时从 redis set 中删除这个 ip , 这样基本上可以保证可用 ip 池都是新鲜可用的, 唯一的缺点就是失败的请求要重新取 ip 重试, 耽误几秒钟
|
4
xuanbg 2023-07-23 07:33:52 +08:00
zset 存 ip ,每次取 score 最小的,然后将这个 ip 的 score+1
|
5
18870715400 2023-07-23 10:11:35 +08:00
好像可以使用一致性哈希算法来解决
|
6
pastgift 2023-07-23 12:17:47 +08:00
list 也可以移除 ip 吧
|
7
pastgift 2023-07-23 12:18:00 +08:00
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> |
8
golangggg OP @mineralsalt set 得问题方案 1 说到了, 非随机, 实际调用下来 多的跟少的能差一倍调用量, 另外 就是无法按照 12345678910 这个顺序 轮训使用 所以 不符合我的需求
|
10
golangggg OP @xuanbg 用过这种方案, 并发不高的时候没问题,但是高并发的时候 做不到轮训的效果, 会导致某一个 ip 被连续取到多次
|
12
golangggg OP @18870715400 我查一下, 触及到我的盲区了 哈哈
|
13
mineralsalt 2023-07-23 13:24:17 +08:00
@golangggg #8 那说明你的 ip 池比较小吧, 我 100 多个 ip 感觉还行, 如果强行加锁给每个 ip 都设定权重,就会影响并发效率, 怎么取舍就看你了
|
15
happyxhw101 2023-07-24 11:18:19 +08:00
为什么不用 nginx 的 tcp 负载均衡
|