积分系统对现有业务影响分析与隔离方案

版本: v1.0 创建日期: 2026-01-13 评估人: AXBlade Team 风险等级: 中等 ⚠️

执行摘要

核心风险

风险类型	风险等级	影响范围	是否可控
查询性能下降	🟡 中	trades表、positions表	✅ 可控
数据库连接池竞争	🟡 中	全局	✅ 可控
交易延迟增加	🟠 中高	核心交易流程	✅ 可控
数据不一致	🔴 高	积分vs实际数据	✅ 可控
表锁竞争	🟢 低	positions表	✅ 可控

关键发现

✅ 好消息:

积分系统使用独立表，不修改现有业务表结构
仅读取业务表数据，不写入
采用异步处理，不阻塞交易流程
支持功能开关，可随时禁用

⚠️ 需要注意:

会增加对trades、positions、referral_relations表的读查询
后台任务会定期扫描positions表（每小时）
与现有系统共享数据库连接池
TradeEvent处理流程会增加额外逻辑

业务表依赖分析

依赖关系图

┌─────────────────────────────────────────────────────────────────┐
│                    积分系统（只读依赖）                           │
└─────────────────────────────────────────────────────────────────┘
                              │
                  ┌───────────┼───────────┐
                  │           │           │
                  ▼           ▼           ▼
        ┌─────────────┐ ┌──────────┐ ┌──────────────────┐
        │   trades    │ │positions │ │referral_relations│
        │  (只读)     │ │ (只读)   │ │    (只读)        │
        └─────────────┘ └──────────┘ └──────────────────┘
              │              │                │
              │              │                │
              ▼              ▼                ▼
        现有交易系统     现有仓位系统    现有推荐系统
        (不受影响)       (不受影响)      (不受影响)

详细依赖表

业务表	访问模式	访问频率	查询字段	影响评估
trades	只读-监听	每笔交易	symbol, price, amount, taker_address, maker_address	🟡 中等
positions	只读-批量	每小时	user_address, symbol, size, entry_price, status	🟢 低
referral_relations	只读-查询	每笔交易	referee_address, referrer_address	🟢 低
orders	无依赖	不访问	-	✅ 无影响
balances	无依赖	不访问	-	✅ 无影响

具体访问场景

场景1: 交易积分计算（实时）

// 在 TradeEvent 处理器中
async fn handle_trade_event(trade: TradeEvent) {
    // 1. 现有逻辑（不变）
    persist_trade(&trade).await?;
    update_positions(&trade).await?;

    // 2. 新增: 积分计算（异步，不阻塞）
    if points_system_enabled() {
        tokio::spawn(async move {
            let _ = points_service.calculate_trading_points(&trade).await;
            let _ = points_service.calculate_referral_points(&trade).await;
        });
    }
}

查询:

-- 查询用户Tier（带缓存，TTL 60s）
SELECT trading_volume FROM user_points_summary
WHERE user_address = $1 AND epoch_number = $2;

-- 查询推荐关系（带缓存，TTL 300s）
SELECT referrer_address FROM referral_relations
WHERE referee_address = $1;

影响分析:

✅ 使用tokio::spawn异步执行，不阻塞交易流程
✅ 带缓存，命中率预计 > 80%
⚠️ 每笔交易增加 2次查询（缓存未命中时）

场景2: 持仓积分计算（定时）

// 后台任务，每小时执行一次
async fn calculate_holding_points_batch() {
    // 批量查询所有活跃仓位
    let positions = sqlx::query!(r#"
        SELECT id, user_address, symbol, size, entry_price,
               last_calculated_at
        FROM positions
        WHERE status = 'open'
    "#)
    .fetch_all(&pool)
    .await?;

    // 逐个计算积分（不修改positions表）
    for position in positions {
        calculate_single_holding_points(position).await?;
    }
}

影响分析:

✅ 仅读取positions表，不修改
✅ 每小时1次，频率低
⚠️ 如果有10000个活跃仓位，需要扫描10000行
💡 优化: 可添加索引 CREATE INDEX idx_positions_status ON positions(status) WHERE status = 'open';

场景3: PnL积分计算（平仓时）

// 在平仓逻辑中
async fn close_position(position_id: Uuid, realized_pnl: Decimal) {
    // 1. 现有逻辑（不变）
    update_position_status(position_id, "closed").await?;
    update_user_balance(user, realized_pnl).await?;

    // 2. 新增: PnL积分（异步）
    if points_system_enabled() {
        tokio::spawn(async move {
            let _ = points_service.calculate_pnl_points(
                user_address, position_id, realized_pnl
            ).await;
        });
    }
}

影响分析:

✅ 异步执行，不阻塞平仓
✅ 仅在盈利时计算积分

性能影响评估

查询负载增加

当前负载（假设）

表	当前QPS	当前CPU%	当前连接数
trades	50	15%	10
positions	20	8%	5
referral_relations	5	2%	2

预计增量

操作	额外QPS	缓存命中率	实际增量QPS
查询用户Tier	+50	80%	+10
查询推荐关系	+50	90%	+5
扫描活跃仓位	+0.0003 (每小时)	N/A	可忽略
总计	-	-	+15 QPS

影响评估

当前总QPS: ~500
积分系统增量: +15 QPS
增长比例: 3%

结论: ✅ 性能影响可控

连接池竞争

当前配置:

DatabaseConfig {
    max_connections: 200,
    min_connections: 50,
}

积分系统预计使用:

实时计算: 5-10 个连接（异步并发）
后台任务: 2-3 个连接
总计: 10-15 个连接

占比: 5-7.5% ✅ 可接受

延迟影响分析

交易流程延迟

┌─────────────────────────────────────────────────────────────┐
│              交易处理流程 (TradeEvent)                       │
└─────────────────────────────────────────────────────────────┘

原流程:
  匹配 → 持久化 → 更新仓位 → 广播
  10ms    20ms     15ms      5ms
  总计: 50ms

新流程 (积分系统禁用):
  匹配 → 持久化 → 更新仓位 → 广播
  10ms    20ms     15ms      5ms
  总计: 50ms  ✅ 无变化

新流程 (积分系统启用):
  匹配 → 持久化 → 更新仓位 → 广播 → (异步)积分计算
  10ms    20ms     15ms      5ms       0ms (不阻塞)
  总计: 50ms  ✅ 无变化

积分计算耗时 (异步后台):
  查询Tier → 查询推荐 → 写积分表
  5ms (缓存命中: 1ms)  3ms  10ms
  总计: 18ms (后台异步，不影响用户)

结论: ✅ 对用户可见的交易延迟无影响

数据一致性风险

潜在不一致场景

场景A: 交易记录 vs 积分记录

问题: 交易已完成，但积分计算失败

时间线:
T1: 交易撮合成功 ✅
T2: 写入trades表 ✅
T3: 更新positions表 ✅
T4: 积分计算开始 (异步)
T5: 积分计算失败 ❌ (数据库连接超时)

结果: 用户交易成功，但未获得积分

影响: 用户投诉，需要人工补录积分

缓解措施:

✅ 实现重试机制（3次，指数退避）
✅ 使用死信队列记录失败事件
✅ 提供管理后台手动补录接口
✅ 每日对账任务，检查遗漏

场景B: 持仓关闭 vs 持仓积分

问题: 仓位已平仓，但持仓积分任务仍在计算

时间线:
T1: 持仓积分任务开始，查询到100个活跃仓位
T2: 用户平仓，仓位A状态变为closed
T3: 任务继续处理仓位A，计算积分 ❌

结果: 已关闭仓位仍获得持仓积分

影响: 积分多发，成本增加

缓解措施:

// 在计算积分前再次检查仓位状态
async fn calculate_single_holding_points(position: Position) {
    // 1. 重新查询最新状态
    let current_status = sqlx::query_scalar!(
        "SELECT status FROM positions WHERE id = $1",
        position.id
    ).fetch_one(&pool).await?;

    // 2. 只有open状态才计算
    if current_status != "open" {
        tracing::warn!("Position {} already closed, skipping", position.id);
        return Ok(());
    }

    // 3. 继续计算
    // ...
}

数据一致性保障机制

机制	说明	覆盖场景
事务保证	积分事件+汇总更新在同一事务	积分内部一致性
重试机制	失败自动重试3次	网络抖动、连接池满
死信队列	记录失败事件待人工处理	重试仍失败的情况
每日对账	对比trades表 vs points_events表	发现遗漏的积分
幂等性	相同trade_id不重复计算	避免重复计算
状态检查	计算前检查最新状态	避免状态变更导致的错误

隔离方案设计

功能开关（推荐 ✅）

实现方式1: 环境变量

# .env
POINTS_SYSTEM_ENABLED=false  # 默认禁用
POINTS_TRADING_ENABLED=true   # 交易积分
POINTS_PNL_ENABLED=true       # PnL积分
POINTS_HOLDING_ENABLED=true   # 持仓积分
POINTS_REFERRAL_ENABLED=true  # 推荐积分
POINTS_STAKING_ENABLED=false  # 质押积分（暂不启用）

实现方式2: 数据库配置表

CREATE TABLE IF NOT EXISTS feature_flags (
    feature_name VARCHAR(50) PRIMARY KEY,
    enabled BOOLEAN NOT NULL DEFAULT false,
    config JSONB,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

INSERT INTO feature_flags (feature_name, enabled) VALUES
('points_system', false),
('points_trading', false),
('points_pnl', false),
('points_holding', false);

代码实现:

// src/services/points/feature_flag.rs
pub struct PointsFeatureFlags {
    enabled: bool,
    trading_enabled: bool,
    pnl_enabled: bool,
    holding_enabled: bool,
    referral_enabled: bool,
}

impl PointsFeatureFlags {
    pub fn from_config(config: &AppConfig) -> Self {
        Self {
            enabled: config.points_system_enabled,
            trading_enabled: config.points_trading_enabled,
            // ...
        }
    }

    pub fn should_calculate_trading_points(&self) -> bool {
        self.enabled && self.trading_enabled
    }
}

// 在TradeEvent处理中使用
if state.points_flags.should_calculate_trading_points() {
    tokio::spawn(async move {
        let _ = points_service.calculate_trading_points(&trade).await;
    });
}

连接池隔离

方案: 为积分系统创建独立连接池

pub struct Database {
    pub primary_pool: PgPool,      // 核心业务
    pub points_pool: PgPool,        // 积分系统专用
}

impl Database {
    pub async fn new(config: &DatabaseConfig) -> Result<Self> {
        // 主连接池: 180个连接
        let primary_pool = PgPoolOptions::new()
            .max_connections(180)
            .min_connections(40)
            .connect(&config.database_url)
            .await?;

        // 积分连接池: 20个连接（独立）
        let points_pool = PgPoolOptions::new()
            .max_connections(20)
            .min_connections(5)
            .acquire_timeout(Duration::from_secs(5))
            .connect(&config.database_url)
            .await?;

        Ok(Self { primary_pool, points_pool })
    }
}

// PointsService使用独立连接池
pub struct PointsService {
    pool: PgPool,  // 使用 db.points_pool
}

优势:

✅ 积分系统故障不影响核心业务连接池
✅ 可独立调整积分系统的连接池配置
✅ 便于监控积分系统的数据库使用情况

劣势:

⚠️ 总连接数增加到200（180+20）
⚠️ 需要确保数据库支持200+连接

异步队列解耦（高级方案）

使用消息队列（Redis Stream / RabbitMQ）

// 生产者: 交易流程
async fn handle_trade_event(trade: TradeEvent) {
    // 核心业务逻辑
    persist_trade(&trade).await?;

    // 发送消息到队列（非阻塞）
    let _ = redis_stream.xadd(
        "points:trade_events",
        "*",
        &[("trade", serde_json::to_string(&trade)?)]
    ).await;
}

// 消费者: 积分计算服务（独立进程）
async fn points_consumer() {
    loop {
        let events = redis_stream.xread(
            "points:trade_events",
            ">"
        ).await?;

        for event in events {
            let trade: TradeEvent = serde_json::from_str(&event.data)?;
            let _ = points_service.calculate_trading_points(&trade).await;
        }
    }
}

优势:

✅ 完全解耦，积分服务故障不影响交易
✅ 可独立扩展积分计算服务
✅ 自然支持削峰填谷

劣势:

⚠️ 增加系统复杂度
⚠️ 需要额外的消息队列基础设施
⚠️ 实时性略有下降（延迟1-2秒）

灰度发布策略

四阶段发布计划

阶段1: 暗发布（1-2天）

目标: 验证基础功能，不对外展示

// 功能开关
POINTS_SYSTEM_ENABLED=true       // 后台计算
POINTS_API_ENABLED=false         // 前端API关闭
POINTS_DISPLAY_ENABLED=false     // 用户不可见

验证内容:

✅ 积分计算逻辑正确性
✅ 数据库写入正常
✅ 性能影响在预期内
✅ 无错误日志

监控指标:

交易延迟 P99 < 100ms
数据库连接池使用率 < 80%
积分计算成功率 > 99%

阶段2: 白名单测试（3-5天）

目标: 内部测试用户验证完整流程

-- 白名单表
CREATE TABLE points_whitelist (
    user_address VARCHAR(42) PRIMARY KEY,
    added_at TIMESTAMPTZ DEFAULT NOW()
);

-- 仅白名单用户可见积分
INSERT INTO points_whitelist (user_address) VALUES
('0xTESTUSER1...'),
('0xTESTUSER2...');

验证内容:

✅ API响应正常
✅ 前端展示正确
✅ 用户反馈积分计算准确

阶段3: 灰度发布（1周）

目标: 逐步放量，观察系统表现

// 按用户地址哈希灰度
fn is_in_grayscale(user_address: &str) -> bool {
    let hash = hash(user_address);
    hash % 100 < GRAYSCALE_PERCENTAGE  // 从10%逐步提升到100%
}

灰度比例:

Day 1-2: 10%用户
Day 3-4: 30%用户
Day 5-6: 60%用户
Day 7: 100%用户

回滚条件:

交易延迟 P99 > 150ms
积分计算成功率 < 95%
数据库CPU > 80%
用户投诉率 > 5%

阶段4: 全量发布

目标: 所有用户可用

POINTS_SYSTEM_ENABLED=true
POINTS_API_ENABLED=true
POINTS_DISPLAY_ENABLED=true
GRAYSCALE_PERCENTAGE=100

灰度发布监控面板

关键指标:

指标	阈值	告警级别
交易延迟 P99	> 150ms	🔴 Critical
积分计算成功率	< 95%	🟠 Warning
数据库连接池使用率	> 85%	🟠 Warning
积分系统错误率	> 1%	🟡 Info
缓存命中率	< 70%	🟡 Info

回滚预案

快速回滚（< 1分钟）

方法1: 功能开关

# 立即禁用积分系统
kubectl set env deployment/backend POINTS_SYSTEM_ENABLED=false

# 或通过管理后台
curl -X POST https://api.axblade.com/admin/feature-flags \
  -H "X-Admin-API-Key: xxx" \
  -d '{"feature": "points_system", "enabled": false}'

效果:

积分计算立即停止
现有业务完全不受影响
已计算的积分数据保留

优势: ✅ 最快速，无风险

数据回滚（< 10分钟）

场景: 发现积分计算严重错误，需要重算

# 1. 禁用积分系统
POINTS_SYSTEM_ENABLED=false

# 2. 备份当前数据
pg_dump -h localhost -U postgres -t points_events -t user_points_summary \
  -f points_backup_$(date +%Y%m%d_%H%M%S).sql

# 3. 清空错误数据
psql -h localhost -U postgres -d axblade <<EOF
  DELETE FROM points_events WHERE created_at > '2026-01-13 10:00:00';
  DELETE FROM user_points_summary WHERE updated_at > '2026-01-13 10:00:00';
EOF

# 4. 重新计算
curl -X POST https://api.axblade.com/admin/points/recalculate \
  -H "X-Admin-API-Key: xxx" \
  -d '{"epoch_number": 1, "from_time": "2026-01-13T10:00:00Z"}'

完整回滚（< 30分钟）

场景: 彻底移除积分系统

# 1. 停止应用
kubectl scale deployment/backend --replicas=0

# 2. 回滚代码
git revert <points-system-commit>
docker build -t backend:rollback .

# 3. 回滚数据库
psql -h localhost -U postgres -d axblade \
  -f migrations/0021_points_system_rollback.sql

# 4. 重启应用
kubectl set image deployment/backend backend=backend:rollback
kubectl scale deployment/backend --replicas=3

监控告警

Prometheus监控指标

// src/services/points/metrics.rs
use prometheus::{register_counter, register_histogram, register_gauge};

lazy_static! {
    // 积分计算成功/失败计数
    pub static ref POINTS_CALC_TOTAL: Counter = register_counter!(
        "points_calculation_total",
        "Total number of points calculations"
    ).unwrap();

    pub static ref POINTS_CALC_ERRORS: Counter = register_counter!(
        "points_calculation_errors_total",
        "Total number of points calculation errors"
    ).unwrap();

    // 积分计算耗时
    pub static ref POINTS_CALC_DURATION: Histogram = register_histogram!(
        "points_calculation_duration_seconds",
        "Time spent calculating points"
    ).unwrap();

    // 缓存命中率
    pub static ref POINTS_CACHE_HITS: Counter = register_counter!(
        "points_cache_hits_total",
        "Points cache hits"
    ).unwrap();

    pub static ref POINTS_CACHE_MISSES: Counter = register_counter!(
        "points_cache_misses_total",
        "Points cache misses"
    ).unwrap();

    // 数据库连接池
    pub static ref POINTS_DB_POOL_SIZE: Gauge = register_gauge!(
        "points_db_pool_connections",
        "Number of connections in points pool"
    ).unwrap();
}

告警规则

# prometheus/alerts/points_system.yml
groups:
  - name: points_system
    interval: 30s
    rules:
      # 积分计算成功率
      - alert: PointsCalculationSuccessRateLow
        expr: |
          (rate(points_calculation_total[5m]) - rate(points_calculation_errors_total[5m]))
          / rate(points_calculation_total[5m]) < 0.95
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "积分计算成功率低于95%"
          description: "当前成功率: {{ $value | humanizePercentage }}"

      # 积分计算延迟
      - alert: PointsCalculationSlow
        expr: histogram_quantile(0.99, points_calculation_duration_seconds) > 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "积分计算P99延迟超过1秒"

      # 缓存命中率
      - alert: PointsCacheHitRateLow
        expr: |
          rate(points_cache_hits_total[5m])
          / (rate(points_cache_hits_total[5m]) + rate(points_cache_misses_total[5m])) < 0.7
        for: 10m
        labels:
          severity: info
        annotations:
          summary: "积分系统缓存命中率低于70%"

      # 连接池使用率
      - alert: PointsDbPoolHighUsage
        expr: points_db_pool_connections / 20 > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "积分系统数据库连接池使用率超过85%"

日志监控

关键日志示例:

// 成功
tracing::info!(
    user = %user_address,
    epoch = %epoch_number,
    points = %points,
    duration_ms = %duration.as_millis(),
    "Points calculated successfully"
);

// 失败
tracing::error!(
    user = %user_address,
    error = %e,
    retry_count = %retry,
    "Points calculation failed"
);

// 性能
tracing::warn!(
    duration_ms = %duration.as_millis(),
    "Points calculation slow"
) if duration > Duration::from_millis(500);

总结与建议

核心结论

评估维度	结论	依据
性能影响	✅ 可控	增量QPS仅3%，延迟无变化
稳定性风险	✅ 低风险	独立表，异步处理，支持功能开关
数据一致性	⚠️ 需监控	有重试和对账机制，但需持续监控
回滚能力	✅ 强	支持秒级功能开关，分钟级完整回滚
整体评估	✅ 可上线	在完整的隔离和监控措施下

必须实施的措施（P0）

✅ 功能开关: 支持随时禁用
✅ 异步处理: 不阻塞交易流程
✅ 独立连接池: 避免竞争核心业务连接
✅ 完整监控: Prometheus + 告警规则
✅ 灰度发布: 10% → 30% → 60% → 100%

建议实施的措施（P1）

🔵 消息队列解耦: 更彻底的隔离（Phase 2考虑）
🔵 读写分离: 积分查询使用只读副本
🔵 每日对账: 自动检查数据一致性
🔵 压力测试: 上线前模拟1000 TPS

附录

性能测试清单

# 1. 基准测试
wrk -t4 -c100 -d30s https://api.axblade.com/api/v1/orders

# 2. 积分系统启用后
POINTS_SYSTEM_ENABLED=true
wrk -t4 -c100 -d30s https://api.axblade.com/api/v1/orders

# 3. 对比结果
# 延迟增长 < 5% ✅ 通过
# 吞吐量下降 < 3% ✅ 通过

应急联系人

角色	姓名	联系方式
后端负责人	-	-
DBA	-	-
运维负责人	-	-

目录​

执行摘要​

核心风险​

关键发现​

业务表依赖分析​

依赖关系图​

详细依赖表​

具体访问场景​

场景1: 交易积分计算（实时）​

场景2: 持仓积分计算（定时）​

场景3: PnL积分计算（平仓时）​

性能影响评估​

查询负载增加​

当前负载（假设）​

预计增量​

影响评估​

连接池竞争​

延迟影响分析​

交易流程延迟​

数据一致性风险​

潜在不一致场景​

场景A: 交易记录 vs 积分记录​

场景B: 持仓关闭 vs 持仓积分​

数据一致性保障机制​

隔离方案设计​

功能开关（推荐 ✅）​

连接池隔离​

异步队列解耦（高级方案）​

灰度发布策略​

四阶段发布计划​

阶段1: 暗发布（1-2天）​

阶段2: 白名单测试（3-5天）​

阶段3: 灰度发布（1周）​

阶段4: 全量发布​

灰度发布监控面板​

回滚预案​

快速回滚（< 1分钟）​

数据回滚（< 10分钟）​

完整回滚（< 30分钟）​

监控告警​

Prometheus监控指标​

告警规则​

日志监控​

总结与建议​

核心结论​

必须实施的措施（P0）​

建议实施的措施（P1）​

推荐上线时间窗口​

附录​

性能测试清单​

应急联系人​

相关文档​

目录

执行摘要

核心风险

关键发现

业务表依赖分析

依赖关系图

详细依赖表

具体访问场景

场景1: 交易积分计算（实时）

场景2: 持仓积分计算（定时）

场景3: PnL积分计算（平仓时）

性能影响评估

查询负载增加

当前负载（假设）

预计增量

影响评估

连接池竞争

延迟影响分析

交易流程延迟

数据一致性风险

潜在不一致场景

场景A: 交易记录 vs 积分记录

场景B: 持仓关闭 vs 持仓积分

数据一致性保障机制

隔离方案设计

功能开关（推荐 ✅）

连接池隔离

异步队列解耦（高级方案）

灰度发布策略

四阶段发布计划

阶段1: 暗发布（1-2天）

阶段2: 白名单测试（3-5天）

阶段3: 灰度发布（1周）

阶段4: 全量发布

灰度发布监控面板

回滚预案

快速回滚（< 1分钟）

数据回滚（< 10分钟）

完整回滚（< 30分钟）

监控告警

Prometheus监控指标

告警规则

日志监控

总结与建议

核心结论

必须实施的措施（P0）

建议实施的措施（P1）

推荐上线时间窗口

附录

性能测试清单

应急联系人

相关文档