简介这是一个基于Golang开发的区块链地址批量余额查询工具面向需要处理大规模链上资产数据的开发者、量化团队或链上分析人员支持BTC、ETH、BSC、TRON、Solana等主流链及数十种ERC20/TRC20合约余额查询可导入Excel批量处理百万级地址并自动过滤无效格式无需部署节点即可通过自定义RPC快速检索。资源共57个文件以53个Go源码文件为主附带go.mod/go.sum依赖管理、README与使用说明文档整体仅87KB代码结构清晰涵盖client、contract、keys、address等模块便于二次开发与集成。已有165人学习下载适合熟悉Go语言或区块链开发、希望快速搭建多链余额查询服务的用户直接参考源码即可理解从地址校验、RPC封装到合约交互的完整实现思路。 前阵子接手一个需求批量查询账户余额数据量不是几十几百条而是上百万条。一开始我拿Go写了个最直观的for循环一条一条查结果跑完要几个小时业务方差点掀桌子。后来把并发模型、任务调度、重试策略全部重做才把百万级查询压到几分钟量级。这篇文章就把整套批量查询余额系统千百万级极速版的实现思路和踩坑过程完整拆开讲适合有Go基础、想做高并发批量任务的开发者参考。这个系统的核心不是“用Go所以快”而是把“查询余额”这个动作从串行改造成可控的高并发流水线。文章会覆盖任务拆分、并发控制、连接池调优、结果回写、断点续跑等关键环节也会把我在压测中遇到的内存暴涨、上游限流、连接泄漏这些问题和排查思路一并写出来。你能直接拿这套设计去套你自己的查询场景不限于余额查询凡是“大量ID换少量字段”的任务都能复用。1. 千百万级批量查询背后的三个真实瓶颈动手写代码之前我先把瓶颈想明白了这活慢到底慢在哪数据量大只是一个表象。如果不拆开看写出来的代码再漂亮也是白搭。1.1 单线程逐笔查询慢在“延迟吃满”不是“计算不够”假设一次查询余额的接口调用需要80毫秒。这个80毫秒里你的CPU可能在99%的时间里都是空闲的真正花时间的是网络往返、对端服务处理、JSON序列化解析。串行跑100万笔就是100万乘以80毫秒约等于22个小时。这不是你的机器算不动而是每一个请求都在等上游返回。明白了这一点优化的方向就很清楚把等待时间重叠起来。同一时间发出去100个请求理论上总耗时就从“100万次等待”变成“1万批等待”效果接近百倍加速。这也是为什么批量查询系统必须上并发不能靠优化单次循环体。1.2 上游接口不可能无限扛并发保护比速度更重要很多人一听并发第一反应是goroutine随便开开它一万个就快了。这个想法很危险。余额查询接口通常都有限流策略从每秒几笔到每秒几百笔不等。你要是真的一下子把几千个请求打过去轻则被限流返回一堆错误重则触发风控直接把调用方封了。所以这个系统的第一设计原则不是“最快”而是“在上游允许的范围内尽量快”。你必须给并发加上一个可控的闸门让打出去的请求数量始终在一个安全区间。这不仅是技术问题也是保护上游系统稳定性的底线。1.3 数据一致性与幂等批量查询最容易忽略查询不是发完请求就结束了结果要落库要回填失败的还要重试。批量场景下最怕的就是“查询完成了但不知道哪些成功、哪些失败”。我当时的做法是引入一个任务状态机制每一条待查询记录都有明确的流转状态待处理、处理中、成功、失败。进程中途崩了、网络抖动了都能从状态表里找到没处理完的那一批继续跑。这个设计对百万级数据来说几乎是刚需因为你不可能指望一次任务从头到尾不出一丁点意外。2. 任务调度与并发控制设计先拆任务再跑goroutine想清楚瓶颈之后我开始设计系统的整体骨架。核心思路很简单先把海量任务拆成小块再用固定数量的worker并发消费这些小块而不是让每一个查询请求都去开一个goroutine。2.1 任务拆分不要让一个goroutine只查一条最容易犯的错误是把“一行数据”当成一个任务。100万行数据就是100万个任务每个任务只做一件小事调度开销和内存开销都会被放大。我倾向于按“分片”来做把数据按ID范围或固定大小切成一批一批比如每批1000个ID一个worker处理一个完整的分片分片内部的查询再自行控制并发。这样做的好处有三个一来任务总数从百万级降到千级管理成本低二来如果一个分片挂了重试粒度是1000条而不是1条恢复更快三来分片天然适合做断点续跑每个分片的状态独立记录。2.2 Worker Pool用固定数量的goroutine吃任务我最终选择了一个标准的Worker Pool模式一个channel作为任务队列N个goroutine同时从channel里取分片任务执行查询写回结果。taskCh : make(chan Task, 1000) // 启动worker for i : 0; i workerCount; i { go func(id int) { for task : range taskCh { result : processTask(ctx, task) writeResult(result) } }(i) } // 生产任务 for _, task : range tasks { taskCh - task } close(taskCh)workerCount设置成多少直接决定了你的请求速率。这个值不是拍脑袋定的而是跟上游限流和单请求延迟挂钩的下一节我会给出一个简单的估算方式。2.3 并发度的量化估算一个非常实用的估算公式目标完成时间 T 总任务数 / (并发数 / 单请求延迟)反推并发数并发数 总任务数 * 单请求延迟 / 目标完成时间假设有100万条数据单请求延迟80ms希望15分钟内完成并发数 1000000 * 0.08 / 900 ≈ 89也就是说只要有大约89个并发就能在15分钟内跑完。但是如果上游限制每秒最多100次调用那并发数高过100也没有意义多余的请求只会排队。实际并发数要在计算值和上游限流值之间取最小值最好再留一点余量。单请求延迟目标时长理论并发数上游限流100QPS时实际并发50ms10分钟约838380ms15分钟约8989200ms30分钟约111100500ms60分钟约139100这个表格的道理很简单并发不是越大越好能塞进目标时间的并发数就够用了剩下的交给上游限制和稳定性考量。3. 核心代码实现查询执行器、重试与控制流架构定了关键就看代码怎么落。这一节我把最核心的几个模块拆开讲包括查询执行器、批量并发控制、重试策略和限速融合。3.1 查询执行器单独的HTTP Client别在循环里反复创建第一版代码我犯过一个低级错误在每次查询时都New一个http.Client。默认的http.Client不设置连接池参数等于每次请求都在重连TCP延迟直接翻倍。后来我改成全局单例Client并对超时和连接池做了显式配置。var httpClient http.Client{ Timeout: 5 * time.Second, Transport: http.Transport{ MaxIdleConns: 500, MaxIdleConnsPerHost: 200, MaxConnsPerHost: 200, IdleConnTimeout: 90 * time.Second, DialContext: (net.Dialer{Timeout: 3 * time.Second, KeepAlive: 30 * time.Second}).DialContext, }, }MaxConnsPerHost这里要特别注意它限制的是同一个上游域名的最大连接数。这个值设置得过小比如默认的0不限制反而会让连接数失控设置得过小比如10并发一上来就直接排队。我压测后把200作为默认值再配合worker并发数控制整体流量。3.2 单个查询与结果封装返回结构要比余额多一点单次查询函数不仅要把余额查出来还要返回这次查询的状态、耗时、错误信息。为什么要这样做因为批量场景下你没法实时盯日志只能靠结构化结果来判断这一批数据到底哪些该重试、哪些是稳定失败。type QueryResult struct { AccountID string Balance float64 Code int Err error CostMS int64 NeedRetry bool } func queryBalance(ctx context.Context, accountID string) QueryResult { start : time.Now() req, _ : http.NewRequestWithContext(ctx, GET, https://api.example.com/balance/accountID, nil) resp, err : httpClient.Do(req) cost : time.Since(start) if err ! nil { return QueryResult{AccountID: accountID, Err: err, NeedRetry: isRetryable(err), CostMS: cost.Milliseconds()} } defer resp.Body.Close() switch resp.StatusCode { case 200: // 解析余额 return QueryResult{AccountID: accountID, Balance: balance, CostMS: cost.Milliseconds()} case 429, 502, 503, 504: return QueryResult{AccountID: accountID, Code: resp.StatusCode, Err: errors.New(upstream busy), NeedRetry: true, CostMS: cost.Milliseconds()} default: return QueryResult{AccountID: accountID, Code: resp.StatusCode, Err: errors.New(bad request)} } }3.3 重试策略超时和5xx可以重试4xx不要重试重试不是无脑重试。超时、连接重置、429、502、503这类错误通常是网络抖动或上游过载重试大概率能成功但400、401、404这类错误重试一万次也是失败纯粹浪费上游资源。我用了一个isRetryable函数来区分这两个阵营并且在重试之间加入指数退避和随机抖动。func retryWithBackoff(ctx context.Context, fn func() (QueryResult, error)) QueryResult { var result QueryResult var err error maxRetries : 3 for attempt : 0; attempt maxRetries; attempt { result, err fn() if err nil || !result.NeedRetry { return result } wait : time.Duration(1attempt)*100*time.Millisecond time.Duration(rand.Intn(100))*time.Millisecond select { case -time.After(wait): case -ctx.Done(): return QueryResult{Err: ctx.Err()} } } return result }抖动非常重要。如果100个worker同时失败、同时退避、同时重试你就制造了一个“重试风暴”反而把上游打得更惨。加入随机抖动可以打散重试的时间点让上游有喘息空间。3.4 限速与并发双重保护Worker Pool只是限制了同时进行中的请求数但它不能限制“每秒发出多少个请求”。如果并发数100单请求延迟只有20ms那每秒实际能打出5000个请求很多上游依然扛不住。所以我在Worker Pool外面再加了一层限速器用golang.org/x/time/rate实现了一个全局QPS限制。limiter : rate.NewLimiter(rate.Limit(100), 200) // 每秒100个请求允许最多200个突发 // worker内部每次请求前等待令牌 err : limiter.Wait(ctx) if err ! nil { return }这样一套组合拳下来系统同时受“并发数”和“每秒请求数”两个维度约束任何一个指标超标都会被平滑限制住。实测下来上游再也没有出现过限流告警。4. 压测与真实调优过程从十万到千万代码写完之后真正的考验才刚开始。压测阶段的数据会告诉你你的设计到底是纸面性能还是真实性能。4.1 第一版压测结果goroutine全开是最差方案我先用最暴力的方式做了一次对照实验不限制goroutine每条数据直接go queryBalance。结果很惨烈100万条数据一启动内存瞬间涨到2GB以上连接数失控大量请求超时完成耗时反而比串行快不了多少。用pprof看了一下CPU和goroutine栈发现大量goroutine阻塞在HTTP连接建立和锁等待上。问题根源有两个一是goroutine太多导致调度开销大二是http.Client默认Transport对同一主机的连接复用能力有限连接建立成了瓶颈。这也验证了我前面说的并发不是越大越好可控的并发才有价值。4.2 优化后的效果对比我把并发数压到128打开连接复用加上限速器再跑同一份数据结果完全不一样。方案并发策略100万笔耗时内存峰值上游状态纯串行1约3.5小时低无压力goroutine全开无限失败/超时严重2GB触发限流Worker Pool 128128约18分钟300MB稳定Worker Pool 128 限速器128并发/QPS 500约22分钟350MB非常稳定批量接口 Worker Pool128并发单请求带100个ID约5分钟400MB稳定最后一行是质的飞跃不是靠并发堆上去的而是换成了批量查询接口单个HTTP请求里带上100个账号ID让上游一次性返回100个余额。并发数不变但单次请求的处理量提升了100倍总耗时直接从18分钟降到5分钟。4.3 进一步优化序列化与结果批量写库当查询本身不再是瓶颈JSON解析和结果落库就变成了新的瓶颈。标准库encoding/json在解析大批量JSON时性能一般我换成了json-iterator解析时间降低了40%左右。结果写库也一样100万条结果如果一条一条INSERT数据库连接和事务开销会拖垮整个流程。我把结果攒在内存里达到1000条就用批量INSERT UPSERT语句一次写进去写库耗时从半小时降到三分钟。-- 批量UPSERT示例 INSERT INTO account_balance(account_id, balance, query_time, status) VALUES (?, ?, ?, ?), (?, ?, ?, ?), ... ON DUPLICATE KEY UPDATE balance VALUES(balance), query_time VALUES(query_time), status VALUES(status)这里要注意批量大小要压测一个合理值。1000条一批在MySQL上表现不错但如果你用的是别的数据库或者单条记录字段很多可能需要下调到500甚至200。批量太大反而会因为事务锁和网络包过大导致性能下降。5. 工程化落地连接池、监控与断点续跑代码性能达标之后不代表就能直接上线。批量任务进程通常要跑好几分钟甚至更长这期间如果没有任何工程化保障任何一个意外都会让你前功尽弃。5.1 连接池配置是第一个隐形瓶颈HTTP连接池、数据库连接池、Redis连接池这三个池子的配置是批量任务最常见的隐形杀手。我压测时发现QPS一旦跑起来MySQL连接池如果太小写库就得排队整个流程被拖慢。经验值是HTTP连接池和Worker并发数匹配数据库连接池独立设置一个偏大的值。比如Worker并发128HTTP MaxConnsPerHost设为200MySQL连接池最大设为100避免写库等待。连接池配置完后一定要观察是否存在连接数缓慢上涨、最终打满的现象那通常是连接泄漏排查方法可以看goroutine数和File Descriptor数。5.2 进度监控没有进度条的大批量任务没法用跑100万条数据你不能傻等。我给任务加了一个进度统计器每处理完一个分片就更新计数定期打印每秒处理笔数、已处理笔数、失败笔数、平均延迟和当前并发数。type Progress struct { Total int64 Done int64 Failed int64 StartedAt time.Time LastPrintAt time.Time } func (p *Progress) tick() { p.Done if time.Since(p.LastPrintAt) 5*time.Second { elapsed : time.Since(p.StartedAt).Seconds() speed : float64(p.Done) / elapsed log.Printf(done%d total%d speed%.0f/s failed%d pct%.2f%%, p.Done, p.Total, speed, p.Failed, float64(p.Done)/float64(p.Total)*100) p.LastPrintAt time.Now() } }这个进度监控的价值在排障时体现得最明显。如果有人问“任务跑得怎么样”你不需要猜直接看日志里的速度和百分比就行。如果速度从每秒500笔掉到每秒50笔大概率是上游变慢了或者被限流了可以及时介入。5.3 优雅退出中断信号不能让任务白跑批量任务跑到一半运维可能因为发布或资源问题需要kill进程。如果直接杀掉已经处理完但还没写库的结果就全丢了。我做了一个优雅退出机制监听SIGTERM和SIGINT信号收到信号后停止接收新任务等正在执行的分片处理完把内存中的结果批量落库再退出进程。quit : make(chan os.Signal, 1) signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT) go func() { -quit log.Println(shutting down, waiting for running tasks...) cancel() wg.Wait() // 等待所有worker完成当前分片 flushResultBuffer() // 落盘未写入的数据 os.Exit(0) }()这个机制我用在了一个真实场景里一个任务跑到60%服务器需要重启。以前的方案是全量重跑现在是继承状态接着跑剩下的40%。这个体验差异非常大尤其在千万级数据量下全量重跑的成本高昂到让人崩溃。5.4 断点续跑任务状态表 分片维度重跑实现断点续跑的核心是“任务状态表”。我设计了一个非常简单的表结构CREATE TABLE task_shard_state ( shard_id VARCHAR(64) PRIMARY KEY, task_id VARCHAR(64), start_time DATETIME, finish_time DATETIME, status TINYINT, -- 0 pending, 1 processing, 2 done, 3 failed retry_count INT, error_msg VARCHAR(500) );每处理一个分片就更新一次状态。重启时先查这个表把status为done的分片跳过只跑还没完成或failed的。这个表本身不复杂但它保证了整套系统在恶劣环境下依然能稳定交付结果。这条思路适用于所有“长耗时、大批量”的数据处理任务。6. 直接复用这套设计时最容易踩的几个坑最后总结一下我在这个项目里踩过、也帮别人排查过的坑。把这几点提前规避掉你的批量查询系统会少走很多弯路。6.1 不要在循环里反复创建HTTP Client这个错误我在前面提过但值得单独拿出来再强调一遍。有人认为每次New一个Client是干净的但这意味着每次请求都要重新建TCP连接、走TLS握手。批量任务场景下连接复用带来的性能收益是数量级的。全局单例Client配合Transport连接池是批量查询的基础配置。6.2 Context超时设置过短第一批代码里我把请求超时设成了2秒觉得5秒都够长了。结果在高峰期上游响应变慢大量请求在2秒被打断触发重试后进一步加剧上游压力。后来我把“单次请求超时”和“整体任务超时”分开单次请求5秒任务整体由context控制同时把上游偶尔变慢的情况交给重试机制去消化而不是把超时时间无限调大。6.3 结果写库一条一条INSERT一个Worker处理完一个分片后如果把结果一条一条写库100万条数据会产生10万次数据库往返。我自己在测试中见过这个情况下数据库CPU飙升、连接数打满。解决方案很简单攒批、批量INSERT、批量UPSERT必要的时候还可以分多个goroutine并行写库。这里唯一的代价是内存占用但1000条结果占用的内存完全可接受。6.4 重复ID和空数据不提前过滤输入数据不是完美的。CSV里可能混着空行、重复ID、格式错误的账号。如果不在入口做一层清洗这些脏数据会在查询阶段反复触发异常还会污染结果表。我在任务加载阶段做了三个过滤去空行、去重、格式校验。这个操作成本极低收益立竿见影——失败率大幅下降任务状态表干净了许多。6.5 上游接口字段大小写和版本差异最后一个坑看起来很低级但确实发生过上游某个环境返回的JSON字段是小写下划线另一个环境是驼峰。如果直接按固定字段解析部分环境会解析出全零余额。解决方式是在解析层做兼容字段名不匹配时尝试别名匹配并且一定要有“解析成功”的校验逻辑。余额字段解析失败无论如何要标成失败记录而不是默认填0否则这种错误数据会悄悄进入业务报表。批量余额查询这个需求本身不复杂难的是在百万级数据量下保持稳定、可控、可观测。把并发闸门、任务状态、限速重试这几个关键点做好再通过压测把参数调到合理区间这套系统就能扛住很大规模的数据。本文还有配套的精品资源点击获取