嘿，针对你要搭建能扛住每秒100次查询（余额、交易这类，对标Etherscan）的以太坊节点需求，我结合Parity的实战配置经验，整理了从单节点优化到多集群搭建的可行方案，帮你搞定这个问题：

常规单节点Parity/Geth达不到QPS要求，大概率是没做针对性优化，先把单节点的潜力挖尽，说不定不用集群就能达标：

1. 存储层性能拉满 #

• 直接上NVMe SSD：Parity的RocksDB数据库对随机读写依赖极强，NVMe的IOPS是普通SATA SSD的3-5倍，这是提升查询速度的核心硬件升级。如果要存全量归档数据（支持所有历史查询），至少准备2TB以上的NVMe；如果只需要最近6个月的历史，用--pruning fast模式，1TB足够。
• 调整数据库缓存：给Parity分配足够的内存做数据库缓存，比如服务器有32G内存的话，设置--db-cache-size 16384（单位MB），让常用数据常驻内存，减少磁盘IO。
• 适配存储介质的压缩策略：添加--db-compaction ssd参数，Parity会针对SSD优化数据压缩和整理逻辑，进一步提升读写效率。

2. API接口精准调优 #

• 只开启必要的API模块：别开多余的API，查询余额、交易只需要eth模块，启动命令加--jsonrpc-api eth，减少不必要的资源消耗。
• 提升并发处理能力：
  • 设置--jsonrpc-threads 8（根据CPU核心数调整，8核CPU就设8线程），让Parity能并行处理更多请求；
  • 调大请求队列上限：--jsonrpc-max-pending-requests 200，避免高并发下请求被直接丢弃；
  • 开启批量请求支持：添加--jsonrpc-batch-requests，允许客户端一次性发送多个查询请求，大幅提升单连接的吞吐量。
• 快速同步上线：用--warp-sync模式同步节点，能在几小时内同步到最新块，不用等几周的全量同步。

3. 单节点硬件参考配置 #

• CPU：8核16线程（比如Intel Xeon E5-2678 v3或AMD EPYC 7302），保证并行处理能力；
• 内存：32GB DDR4以上，给数据库缓存留足空间；
• 存储：2TB NVMe SSD（归档模式）/1TB NVMe SSD（快速 pruning 模式）；
• 带宽：100M以上独享带宽，保证节点同步和查询的网络稳定性。

如果单节点优化后还是达不到100QPS，或者需要高可用（避免单点故障），就上集群架构：

1. 基础架构设计 #

用负载均衡器（Nginx/HAProxy）做前端入口，后面挂载3-5个Parity节点，负载均衡器采用「最少连接」策略转发请求，让压力均匀分布到各个节点。这样只要增加节点数量，就能线性提升总QPS。

2. 节点同步一致性 #

• 所有集群节点关闭自动发现：添加--no-discovery参数，只连接内部的种子节点（比如选一个节点作为主同步节点，其他节点从它同步），避免外部节点干扰，提升同步稳定性；
• 统一 pruning 模式：所有节点用相同的 pruning 配置，保证数据一致性，避免查询结果不一致的问题。

3. 缓存层是性能飞升的关键 #

类似Etherscan的查询请求，80%都是重复的（比如热门地址的余额查询），在负载均衡和Parity节点之间加一层Redis缓存：

• 缓存规则：地址余额缓存5分钟（键：balance:{address}），交易详情缓存1小时（键：tx:{hash}）；
• 缓存失效：当有新交易涉及该地址时，主动删除对应缓存，保证数据新鲜度。
  这一步能让大部分请求直接从缓存返回，Parity节点只处理少量未缓存的请求，QPS轻松突破100甚至更高。

4. 可选：读写分离 #

如果有交易发送需求，单独用1个节点处理写入请求（开启personal API），其他节点只处理查询，避免写入操作占用查询节点的资源，进一步提升查询性能。

• 性能验证：用wrk工具模拟并发请求，比如写个Lua脚本调用eth_getBalance：

  wrk.method = "POST"
  wrk.body = '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b8D4C05391f1a603","latest"],"id":1}'
  wrk.headers["Content-Type"] = "application/json"
  

  执行命令：wrk -t8 -c100 -d30s http://your-node-ip:8545 -s balance-test.lua，看QPS能不能稳定到100以上。
• 监控运维：开启Parity的--prometheus参数，用Prometheus+Grafana监控节点的CPU、内存、磁盘IO、API响应时间、同步进度等指标，及时发现性能瓶颈并调整。

其实单节点在NVMe+大缓存+API调优的情况下，完全有可能达到100QPS的查询需求；而集群+缓存的方案则是更稳妥的长期方案，既能满足当前需求，也能应对未来更高的QPS增长。

内容的提问来源于stack exchange，提问作者IntegerSynergy