还在招噢，有意欢迎来询～

有意向的朋友可以联系试一下噢，现在急招，机不可失～

@twister1017 没有的

@runningman 有兴趣么？来玩玩😌

@runningman 这不是来了么，hah~

@Gezqh 我这没有噢，有需要的话可以内推其他部门

抖音电商有兴趣没？ base 北京 /上海 /杭州都有坑

目前情况：
1. 单线程：耗时约 36 小时，请求稳定（效率极低）
2. 分批 3w 数据 /线程，共 5 个线程：耗时约 16 小时，请求较稳定 （效率略低）
3. 固定 30 个线程：耗时约 3.5 小时，偶有 HTTP 请求超时（效率已经能够满足，需解决部分超时异常）
4. 固定 100 个线程：测试过程因请求超时案例过多，暂不予考虑，所以未计耗时

总结：
我的业务场景属于网络 IO 密集型任务，时间基本都消耗在等待 HTTP 请求的响应，所以多线程请求还是效果很明显的，至于固定多少线程效率最高我无法确定，纯手工尝试😂，有科学测量方式的小伙伴麻烦指教一下。30 线程数已经能够满足业务需求，暂以项目交付为先，关于各位 V 友的建议比如异步请求之类的有空的时候再尝试。

在此感谢各位 V 友的不吝赐教

@xzg 业务场景是不需要实时响应的，异步应该是可行的。暂时不太了解异步，尝试了下多线程，效果还是很明显的，已经能够满足需求了。

@Yourshell 每天寄 U 盘也挺累的，手动狗头🐶

@mritd 好多大佬说 golang 的，不带脑子都行，那么强大的吗，hah

@whp1473 您建议的这种方式可能不太适合我这个场景，应该适合那种一次性响应数据量比较大的情况。目前接口并非因为响应数据量大而缓慢，所以即使定时获取也无法迈过多次 HTTP 请求这道坎，还是得想办法提高 IO 利用率

@liujan 第三方那边不可控，还是得我这边想办法优化一下。感谢建议

@33and66 如果有现成的数据文件是可行，但是在第三方不改动的情况下，暂时也没有其他方式可以获取数据来源，还是得调接口请求

@misaka19000 很多都是建议异步操作的，没怎么了解过，我试试看。感谢建议

@az422 目前使用 30 个线程，处理时间已经减少到 3.5 小时，偶尔会有 HTTP 请求超时的情况出现。我再观察一下，感谢您的建议

@CoSpLi 拉黑，这么过分的吗，Hahh

@MoHen9 数据量不算大，从一条到两三千条 JSON 字符串不等，应该是数据需要处理比较慢吧

@rrfeng
@lhx2008 好的，感谢建议