4. 规则定义与元数据管理：规则的结构化表示、版本管理与元数据存储设计

规则是精算模型命中的核心逻辑载体。在实时监控场景中，规则必须被结构化、版本化、持久化，才能支撑动态加载、热更新与历史回溯。本节聚焦规则的结构化表示（JSON/YAML）、版本管理策略以及元数据在 MySQL 与 Redis 中的存储设计。

4.1 规则的结构化表示：JSON 与 YAML

规则的结构化表示需要兼顾机器可解析性与人工可读性。JSON 适合程序快速解析与序列化，YAML 更适合配置人员编写与版本对比。生产环境通常采用 JSON 作为内部存储格式，YAML 作为编辑与展示格式。

以下是一个规则的结构化 JSON 示例，包含规则元数据、条件表达式与动作定义：

{
  "ruleId": "rule_premium_001",
  "ruleName": "高保费触发风控",
  "version": 3,
  "status": "ACTIVE",
  "priority": 10,
  "description": "当保费超过阈值且用户历史赔付率异常时触发",
  "conditions": {
    "operator": "AND",
    "items": [
      {
        "field": "premium",
        "operator": "GREATER_THAN",
        "value": 50000
      },
      {
        "field": "historical_loss_ratio",
        "operator": "GREATER_THAN",
        "value": 0.65
      }
    ]
  },
  "actions": [
    {
      "type": "ALERT",
      "target": "risk_team",
      "params": {
        "channel": "email",
        "template": "high_premium_alert"
      }
    },
    {
      "type": "TAG",
      "target": "policy",
      "params": {
        "tagKey": "risk_level",
        "tagValue": "HIGH"
      }
    }
  ],
  "metadata": {
    "creator": "zhangsan",
    "createTime": "2025-03-10T10:00:00Z",
    "updateTime": "2025-03-12T14:30:00Z",
    "effectiveFrom": "2025-03-13T00:00:00Z",
    "effectiveTo": null
  }
}

4.2 规则版本管理

规则版本管理是保障监控准确性与可追溯性的关键。每次规则变更都应生成新版本，并记录变更原因、变更人、生效时间。版本管理策略包含以下核心要素：

• 版本号递增： 采用整数递增，每次编辑+1，支持回滚到任意历史版本。
• 版本状态机： DRAFT → REVIEW → ACTIVE → DEPRECATED → ARCHIVED。
• 生效时间窗口： 支持定时生效与定时失效，避免规则切换导致监控中断。
• 版本对比： 提供相邻版本或任意版本的 diff 能力，便于审计。
• 灰度发布： 支持按规则版本灰度，例如 10% 流量使用 v3，90% 使用 v2。

CREATE TABLE rule_version (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  rule_id VARCHAR(64) NOT NULL,
  version INT NOT NULL,
  rule_content JSON NOT NULL,
  status VARCHAR(20) NOT NULL DEFAULT 'DRAFT',
  change_reason TEXT,
  created_by VARCHAR(64),
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  effective_from DATETIME,
  effective_to DATETIME,
  UNIQUE KEY uk_rule_version (rule_id, version)
);

4.3 规则元数据存储设计：MySQL + Redis

规则元数据采用 MySQL 与 Redis 分层存储架构。MySQL 作为持久化主存储，保证数据完整性与历史可追溯；Redis 作为缓存与热加载层，支撑毫秒级规则匹配。

4.4 Redis 缓存数据结构设计

Redis 中规则元数据的缓存设计直接影响匹配性能。推荐使用 Hash 结构存储规则内容，使用 Sorted Set 维护版本优先级。

-- 规则内容缓存（Hash）
HSET rule:cache:rule_premium_001 version 3 content '{...json...}' status ACTIVE

-- 规则版本索引（Sorted Set，score 为优先级）
ZADD rule:active:index 10 rule_premium_001
ZADD rule:active:index 20 rule_claim_002

-- 规则版本历史（List，用于快速回滚）
LPUSH rule:history:rule_premium_001 '{"version":3,"content":"..."}'
LPUSH rule:history:rule_premium_001 '{"version":2,"content":"..."}'

4.5 规则元数据字段设计总览

4.6 规则加载与热更新流程

规则引擎启动时从 Redis 加载所有 ACTIVE 规则到本地内存；当规则发生变更时，通过以下流程实现热更新：

1. 管理员通过管理平台编辑规则，保存后写入 MySQL 并生成新版本。
2. MySQL 写入成功后，发送规则变更事件到消息队列（如 Kafka）。
3. 规则缓存服务消费事件，更新 Redis 中的规则内容与版本索引。
4. 规则引擎定期（如 1 秒）或通过监听机制从 Redis 拉取最新规则版本。
5. 规则引擎对比本地版本号与 Redis 版本号，不一致时重新加载规则。