Prediction Market 数据同步服务架构设计与工程实践

2026-06-07

前言

Prediction Market（预测市场）是 Web3 领域重要的应用场景之一。Polymarket 作为最大的去中心化预测市场平台，提供 Gamma、Data、CLOB 三套 API 接口供开发者消费数据。

但要基于 Polymarket 数据构建一个面向用户的前端应用，需要解决几个实际问题：

数据获取：API 有频率限制，单次查询量有限，需要周期性同步
数据一致性：多 API 之间的数据需要关联和校验，避免状态不一致
实时性：用户需要看到市场的最新成交和结果，依赖 Kafka 事件流
搜索能力：PostgreSQL 不适合全文搜索，需要用 Elasticsearch 做聚合查询
性能：API 请求和数据库查询需要缓存层支撑

本文介绍的这套系统正是为解决这些问题而生的——一个纯后端 Worker 服务，负责从 Polymarket 拉取数据、持久化存储、实时处理事件，最终为前端提供一致的、高性能的数据底座。

一、整体架构

系统是一个纯 Worker 架构——没有 HTTP API，没有前端，只有一个后台进程持续运行。

flowchart LR
    subgraph Input [数据源]
        G[Polymarket Gamma API
事件/市场/标签/翻译]
        D[Polymarket Data API
排行榜/持仓/交易]
        C[Polymarket CLOB API
订单簿/价格]
        K[Kafka
链上事件流]
    end

    subgraph Worker [Worker 服务]
        J[定时调度器
22 个同步Job]
        CON[Kafka Consumer
实时事件消费]
    end

    subgraph Storage [存储层]
        PG[(PostgreSQL
prediction schema)]
        ES[(Elasticsearch
web3_prediction 索引)]
        RD[(Redis
缓存/队列)]
    end

    Input --> Worker
    Worker --> Storage
    Storage --> FE

more >>

查看全文 >>

Web3 代币数据服务 — 架构设计与工程实践

2026-06-06

前言

在 Web3 领域，代币数据是上层应用的基础。无论是行情展示、交易决策、安全风控，还是智能投研，都离不开准确、实时的代币元数据、价格、持有者分布和安全信息。但搭建一个覆盖多链、实时更新的代币数据服务面临诸多挑战：

多链异构：Solana 和 EVM 链（BSC、Base）的链上数据结构、RPC 接口、代币标准完全不同。Solana 使用 SPL Token 标准，通过 PDA 派生账户地址；EVM 链使用 ERC-20 标准，合约状态存储在全局 state trie 中。两者在元数据读取、持有者查询、交易解析等各个层面都有本质差异。

数据来源多样：链上 RPC 提供原始数据，第三方 API（CoinGecko、CoinMarketCap、GoPlus、DexScreener）提供增强信息，链下数据源（Twitter、Discord、Telegram 社交链接）补充元数据。多源汇聚带来了数据冲突、时效不一致、部分缺失等问题。

实时性要求高：从代币创建 → 首笔交易 → 市场数据更新，需要在秒级完成。尤其是 Meme 代币的”内盘”阶段，价格波动极快，数据延迟直接导致用户错过交易窗口。

外部依赖脆弱：数十个外部 API 各有不同的速率限制（QPS）、认证方式、响应格式。部分 API 还有反爬机制和 IP 白名单要求，容错降级是刚需。

本文介绍一个用 Golang 构建的生产级代币数据服务，已覆盖 Solana、BSC、Base 三条链，对接数十个外部数据源。下面从架构设计、核心技术、数据流和工程实践四个维度展开。

一、功能概览

该服务的定位是代币数据中台，核心职责包括：

模块	功能
代币收录	监听链上代币创建事件（Mint），自动入库
元数据补全	名称、符号、图标、描述等信息补充
安全检查	貔貅检测、可铸币/可冻结属性、合约安全打分
持有者分析	持有者分布、持仓变化、聪明钱/开发者标记
市场数据	价格、交易量、流动性、FDV、市值、热度评分
榜单排名	热门榜、新币榜、即将完成榜、已完成榜
池子管理	DEX 流动性池地址解析、池费查询与更新

二、系统架构

2.1 整体架构

            ┌─ token_events ──────────┐
            │  trade_events             │
            │  data_events              │
            └────────┬──────────────────┘
                     │ Kafka
            ┌────────▼────────────┐
            │     Core 编排器      │
            │  ├─ 3 个 Consumer   │
            │  ├─ Scheduler       │
            │  └─ Monitor         │
            └────────┬────────────┘
                     │
      ┌──────────────┼──────────────┐
      ▼              ▼              ▼
TokenUpdater   Scheduler任务    PoolFeeService
      │              │              │
      ▼              ▼              ▼
 Elasticsearch  外部API补全    Redis Cache/Queue
      │
      ▼
 Kafka (下游内盘更新分发)

Core 编排器在启动阶段依次初始化：

Repository - 初始化 ES、PostgreSQL、Redis 连接池
ChainManager - 初始化各链的 RPC 客户端（Solana JSON-RPC、EVM ethclient）
TokenUpdater - 启动统一缓冲写入器
3 个 Kafka Consumer - 订阅不同事件主题
Scheduler - 注册 29+ 个定时任务
Monitor - 暴露 Prometheus 指标（:8091/metrics）

more >>

查看全文 >>

从一笔链上交易到聪明钱信号 — 实时聪明钱系统的架构设计与工程实践

2026-06-06

前言

“聪明钱”（Smart Money）指在链上交易中持续表现出色的钱包地址：它们买什么，什么就涨。实时追踪这些钱包的交易行为，可以发现潜力代币、学习交易策略、获得风险预警。

但构建一个实时聪明钱追踪系统面临三重挑战：

数据真实性问题：链上存在两种”真相”——交易账本推导的仓位，和链上实际余额。转账、空投、跨链会导致两者不一致。
并发一致性问题：同一笔持仓可能被多笔交易并发修改，需要严格的串行化控制。
实时性问题：从交易到达 → 持仓更新 → 钱包画像 → 榜单/Feed，需要在秒级完成。

本文从一笔链上交易进入系统开始，逐步讲解它如何经过处理、聚合、衍生，最终变成聪明钱信号，再到整体架构设计。

一、从一笔交易到持仓更新

1.1 输入：原始交易事件

Kafka 中的每一条消息代表一次链上交易，核心字段如下：

{
  "event": {
    "time":         1717660800,     // 交易时间(秒)
    "network":      "bsc",          // 链
    "tokenAddress": "0xABC...",     // 代币地址
    "poolAddress":  "0xDEF...",     // 交易池地址
    "address":      "0x123...",     // 交易者钱包地址
    "price":        1.2345,         // 成交价格
    "volumeUsd":    50000.0,        // 成交量(USD)
    "side":         "buy",          // 方向
    "baseMint":     "0x...",        // 基础代币
    "quoteMint":    "0x...",        // 报价代币
  }
}

1.2 前置过滤

系统首先过滤两类无意义交易：

无法识别链：chainID == 0，直接丢弃
双边 USD 稳定币：输入和输出都是 USDT/USDC 等稳定币，对持仓分析无意义

more >>

查看全文 >>

链上数据实时K线系统 — 架构设计与工程实践

2026-05-28

前言

去中心化交易所(DEX)的链上交易数据具有实时性高、数据量大、来源分散的特点。如何将这些原始的链上交易事件转化为标准化的 OHLCV K 线数据，并支持价格异常检测、流动性追踪、多维度统计等能力，是一个兼具工程挑战和业务价值的课题。

本文从一条交易数据进入系统开始，逐步讲解它如何变成 K 线和行情指标，再到整体架构设计。

一、从一条交易到一根 K 线：OHLCV 计算过程

1.1 输入：原始交易事件

Kafka 中的每一条消息代表一次链上交易，核心字段如下：

{
  "event": {
    "time":         1717660800,     // 交易时间(秒)
    "tokenAddress": "0xABC...",     // 代币地址
    "poolAddress":  "0xDEF...",     // 交易池地址
    "network":      "ethereum",     // 链
    "price":        1.2345,         // 成交价格
    "volumeUsd":    50000.0,        // 成交量(USD)
    "side":         "buy",          // 买卖方向
    "address":      "0x123...",     // 交易者地址
  }
}

1.2 时间窗口定位

系统配置了多个 K 线周期（如 1s、5m、15m、1h 等），每个周期有对应的毫秒级 duration。对于每条交易，先计算它属于哪个时间窗口：

1	currentTs = tradeTime - (tradeTime % duration)

例如 tradeTime = 1717660803，对于 5m 周期（duration = 300s）：

currentTs = 1717660803 - (1717660803 % 300) = 1717660800
即该交易属于 5m K 线中 [1717660800, 1717661100) 这个窗口

1.3 从缓存中获取当前 K 线状态

每个 (token, pool, interval) 组合在 Redis 中维护一条”进行中”的 K 线。系统先尝试从本地内存缓存读取，未命中则回源 Redis：

1	cacheKey = "kline:{token}:{pool}:{interval}"

more >>

查看全文 >>

多链交易解析服务 — 架构设计与工程实践

2026-05-27

前言

在 Web3 领域,链上交易数据是上层应用的基础。无论是聪明钱追踪、代币数据服务、还是实时 K 线系统,都依赖同一个底层能力:
将区块链上的原始交易数据解析成结构化、可消费的业务事件。

但构建这样的解析层面临几个核心挑战:

多链异构:Solana 和 EVM 链(BSC、Base)的区块结构、交易模型、RPC 接口完全不同。Solana 有 Account Model、指令嵌套和 CPI(Cross-Program Invocation);EVM 链有 types.Block、Receipt、Event Log。解析器需要统一这两种范式。
协议多样性:仅 Solana 生态就有 Raydium、Meteora、PumpFun、Orca、Pancake 等十几种 DEX 协议,每种协议的指令编码方式(Borsh/自定)和账本结构各不相同。
实时性要求高:从区块产生 → 扫链 → 解析 → 发送下游,需要在秒级完成。区块不能积压,解析失败需自动重试。
可观测性:生产环境需要监控解析延迟、失败率、Kafka 生产速率、RPC 可用性等指标。

本文介绍一个用 Golang 构建的生产级多链交易解析服务。该服务已覆盖 Solana、BSC、Base、Polygon 四条链,支持 12+ DEX 协议,每日处理百万级交易。

一、系统架构

1.1 整体架构

整个系统分为两个独立微服务:Scanner(扫链)和 Parser(解析),通过 Kafka 解耦。
另外对于高实时要求的链如Solana会有GRPC(监听)，redis里用lua脚本去重存到待解析tx队列，解析都是基于tx，而扫链也会结合ws监听出块已减少rpc请求(rpc节点压力过大性能会下降)。

flowchart TB
    subgraph Blockchain["区块链网络"]
        BSC["BSC Node"]
        BASE["Base Node"]
        POLYGON["Polygon Node"]
        SOLANA["Solana Node"]
    end

    subgraph Scanner["Scanner Service"]
        EVM1["EVM Scanner BSC
轮询 + RLP编码"]
        EVM2["EVM Scanner Base
轮询 + RLP编码"]
        EVM3["EVM Scanner Polygon
轮询 + RLP编码"]
        SOL["Solana Scanner
轮询 + Vote过滤 + 拆分"]

        RedisScan["Redis
扫描状态
最后区块号"]
    end

    subgraph Kafka["Kafka Message Queue"]
        TOPIC_BSC["raw_block_BSC"]
        TOPIC_BASE["raw_block_BASE"]
        TOPIC_POLYGON["raw_block_POLYGON"]
        TOPIC_SOL["raw_block_SOLANA"]
    end

    subgraph Parser["Parser Service"]
        EP1["EVM Parser BSC
Receipt解析 + ERC20提取 + 并行"]
        EP2["EVM Parser Base
Receipt解析 + ERC20提取 + 并行"]
        SOLP["Solana Parser
Plugin 指令解析器
Token → DEX 两阶段"]

        Sub["Submitter
多Topic分发"]
    end

    subgraph Output["下游 Kafka Topics"]
        BT["block_topic
完整区块"]
        TT["transfer_topic
钱包转账"]
        LQ["liquidity_events
流动性变化"]
        CT["token_events
代币创建/更新/发射"]
        BL["balance_topic
余额快照"]
        TL["trade_events
交易记录/币对创建"]
    end

    subgraph Storage["存储"]
        PG[("PostgreSQL
钱包配置")]
        RC[("Redis
状态/缓存/回溯")]
    end

    BSC --> EVM1
    BASE --> EVM2
    POLYGON --> EVM3
    SOLANA --> SOL

    EVM1 --> TOPIC_BSC
    EVM2 --> TOPIC_BASE
    EVM3 --> TOPIC_POLYGON
    SOL --> TOPIC_SOL

    RedisScan -.-> EVM1 & EVM2 & EVM3 & SOL

    TOPIC_BSC --> EP1
    TOPIC_BASE --> EP2
    TOPIC_POLYGON --> EP2
    TOPIC_SOL --> SOLP

    EP1 & EP2 & SOLP --> Sub
    Sub --> BT & TT & LQ & CT & BL

    PG -.-> Parser
    RC -.-> Scanner & Parser

more >>

查看全文 >>