---
title: "数据防篡改签名方案"
confluence_page_id: "104762256"
confluence_url: "/pages/viewpage.action?pageId=104762256"
space_key: "dmy"
space_name: "达摩院"
author: "陈振岭"
created_date: "2025-08-07T14:35:11.000+08:00"
modified_date: "2025-08-07T14:35:11.000+08:00"
version: 8
export_date: "2025-08-11T01:23:31.614Z"
---
# 基金交易系统核心数据防篡改签名方案 (最终版)
## 1\. 需求背景
为保障基金交易系统中用户资产的安全性，需要对核心数据表（份额表、冻结表）设计一套防篡改机制，防止因程序漏洞或恶意数据库操作导致的数据不一致问题。
## 2\. 总体架构与核心组件
***安全认证服务 (`auth-service`)**: 独立的中心化服务，统一负责密钥管理和签名/验签 API。* **数据一致性 (`数据库事务`)**: 利用数据库的 ACID 特性保证操作的原子性。 ***并发控制**: 采用锁机制防止并发场景下的数据错乱。* **消息队列 (`MQ`)**: 用于部分方案中核心交易与后续流程的异步解耦。
## 3\. 核心方案设计
我们提供三种核心实现方案，它们在数据模型、并发性能和一致性保证上各有侧重。
### 方案一：耦合签名方案 (不推荐)
此方案将份额与所有关联的冻结状态“绑定”在一起，在份额表（`t_share`）中进行统一签名，逻辑简单直接。
#### 3.1. 数据表结构
*`t_share`: 增加 `sign` 字段。* `t_freeze`: 无需变更。
#### 3.2. 核心逻辑
1\. `t_share` 表的签名不仅保护自身份额，还间接保护其关联的所有 `t_freeze` 记录。 2. 签名内容包含 `t_share` 的核心字段以及一个根据所有冻结明细计算出的**聚合哈希值 (`freeze_agg_hash`)**。 3. 任何影响份额或冻结状态的操作（如申购、赎回、冻结、解冻），都必须**锁定 `t_share` 表的同一行**，重新查询该用户的所有冻结明细来计算聚合哈希，并生成新签名。
#### 3.3. 优缺点
***优点**:* 数据模型简单，无需新增表。 ***缺点**:* **性能瓶颈**: 所有冻结/解冻操作都会竞争同一行 `t_share` 的锁，并发性能极差。 ***高数据库开销**: 每次操作都需要全量查询冻结明细，IO开销大。* **逻辑耦合**: 业务逻辑高度耦合，难以维护和扩展。
\---
### 方案二：解耦聚合 + 同步签名方案 (主推荐方案)
此方案引入独立的汇总表，将高频的冻结/解冻操作与份额变更操作的锁分离，并在交易流程中同步完成签名，保证强一致性。
#### 3.1. 数据表结构
*`t_share`: 增加 `sign` 字段。* `t_freeze_summary` (新增): `user_id`, `fund_code`, `total_frozen_amount`, `freeze_count`, `last_update_time DATETIME`, `sign`。 *`t_freeze`: 无需变更。*
*
#### 3.2. 核心流程
1\. **获取锁**: 业务开始时，通过 Redis 获取特定用户资产的分布式锁 (`lock:freeze_summary:{userId}:{fundCode}`)。 2. **事务外准备**: a. 读取 `t_freeze_summary` 记录。 b. **验签**: 调用 `auth-service` 验证当前签名，失败则终止操作。 c. 在内存中计算出业务变更后的新汇总数据。 d. **生成新签名**: 调用 `auth-service` 为内存中的新汇总数据生成新签名。 3. **执行事务**: a. 开启 `@Transactional` 方法。 b. 在事务内，将上一步计算好的新汇总数据、新签名和**当前时间戳 (`last_update_time`)**，连同新的 `t_freeze` 明细记录，一并写入数据库。 4. **释放锁**: 在 `finally` 块中释放 Redis 锁。
#### 3.3. 优缺点
*
**优点**: ***强一致性**: 数据与签名实时同步，安全性最高。* **逻辑清晰**: 职责分离，易于理解和维护。 ***性能良好**: 相比方案一，锁粒度更细，并发性能显著提升。* **缺点**: *核心交易链路依赖 `auth-service` 的实时响应。* 对汇总表的行锁在高频场景下仍可能成为瓶颈。
\---
### 方案三：解耦聚合 + 异步更新与审计方案 (降级备选方案)
此方案将核心交易的性能最大化。交易过程仅操作明细表，不更新汇总表，也无需加锁。汇总和签名通过消息队列异步完成，并通过独立的定时任务进行安全审计。
#### 3.1. 数据表结构
与方案二相同，`t_freeze_summary` 包含 `last_update_time` 字段。
#### 3.2. 核心交易流程 (如：冻结/解冻)
1\. **开启事务**，仅对 `t_freeze` 表进行操作（插入新冻结、删除已解冻的记录等）。 2. **提交事务**。 3. **发送消息**: 事务成功后，向消息队列发送一条消息。 ***消息体**: 必须包含 `user_id`, `fund_code`, **操作类型** (`ADD_FREEZE`, `RELEASE_FREEZE`), **操作金额** (`amount`) 等。 4. **若是T0取现业务**，需要同步验证好汇总冻结签名后，才能调代付打款。*
*
#### 3.3. 异步更新与签名流程 (MQ 消费者)
1\. 消费消息，根据 `(user_id, fund_code)` 获取分布式锁。 2. **开启事务**: a. 读取并**验签** `t_freeze_summary`。失败则告警并等待人工干预。 b. 根据消息的**操作类型**和**金额**，对汇总数据进行**增量更新**（累加或累减）。 c. 调用 `auth-service` **生成新签名**。 d. 持久化更新后的汇总记录，同时更新 `last_update_time` 为当前时间。 3. 提交事务，释放锁。
#### 3.4. 周期性安全审计流程 (定时任务)
创建一个独立的定时任务（例如，使用 Python 脚本每日凌晨执行），对数据进行全量核对。
*
*1\. **筛选审计对象**: 查询所有 `t_freeze_summary` 表中 `last_update_time` 在 **5分钟前** 的记录。这个“冷静期”是为了防止对正在进行异步更新的记录进行校验，从而避免产生误报。 2. **遍历审计对象**: 对每一个筛选出的汇总记录执行以下操作。 a. **全量计算明细**: 根据汇总记录的 `(user_id, fund_code)`，从 `t_freeze` 表中全量计算实际的冻结总额和总笔数 (`SELECT SUM(frozen_shares), COUNT(`*`) FROM ...`)。 b. **数据比对**: 将明细计算结果与 `t_freeze_summary` 表中的数据进行比对。 c. **签名校验**: 若数据比对一致，则根据汇总表数据重新生成签名，与表中的 `sign` 进行比对。 d. **记录与告警**: 任何不一致（数据不匹配或签名不匹配）都应被记录为高优先级安全事件，并立即发出告警。
#### 3.5. 优缺点
***优点**:* **性能极致**: 核心交易路径极短，无锁、无远程调用，吞吐量最高。 ***缺点**:* **最终一致性**: 数据与签名存在毫秒到秒级的不一致窗口。 ***架构复杂**: 引入MQ和定时任务，增加了系统复杂度和维护成本。* **安全滞后**: 问题依赖异步验签和周期性审计发现，有延迟。
## 4\. 最终方案对比与建议
| 对比维度 | 方案一：耦合签名 (不推荐) | 方案二：同步签名 (主推荐) | 方案三：异步更新与审计 (降级备选) | | ---------------- | ---------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | | **性能/吞吐量** | **极低**。串行操作，无法应对并发。 | **良好**。并发性能满足绝大多数场景。 | **极高**。核心交易性能最好。 | | **一致性** | **强一致性**。 | **强一致性**。数据与签名实时同步。 | **最终一致性**。存在数据延迟窗口。 | | **实现复杂度** | **低**。 | **中**。逻辑清晰，易于理解。 | **高**。引入MQ和定时任务，维护成本高。 | | **安全性** | **高**。实时校验。 | **最高**。实时校验，且逻辑分离不易出错。 | **高**。依赖异步验签和周期性审计，问题发现有延迟。 |
**最终建议**: ***首选方案**: **方案二 (解耦聚合 + 同步签名)**。它在提供强一致性保证的同时，通过解耦数据模型和优化事务范围，完美平衡了安全、性能与可维护性，是绝大多数场景下的最佳选择。*
**备选/降级方案**: **方案三 (异步更新与周期性审计)**。当系统面临极端并发压力，主交易流程的耗时和吞吐量成为首要矛盾时，可启用此方案。启用前必须评估业务对数据“最终一致性”的容忍度，并同步建设完善的MQ消费监控和定时审计告警机制。
\* **应避免的方案**: **方案一 (耦合签名)**。由于其固有的性能缺陷，应在设计阶段就予以排除。
