令牌化核心概念：令牌、令牌库、映射表、去令牌化
咱们正式开始讲令牌化之前，先得把几个基础概念掰扯清楚。你想想看，如果你跟别人说“我要做令牌化”，对方大概率会问：“令牌长什么样？存在哪儿？怎么变回去？”我当年刚入行时也踩过这些坑。嗯，今天我们就把这四个最核心的东西一网打尽：令牌、令牌库、映射表、去令牌化。
1. 令牌（）—— 数据替身
令牌说白了就是原始敏感数据的一个“替身”。它本身没有实际含义，就像电影里的替身演员——脸不是真脸，但戏该演还得演。比如你的信用卡号 4111 1111 1111 1111，令牌化之后可能变成 TOK-7A3F-9B1C。这个字符串只有系统内部能解释。
令牌有几个关键特征：
- 不可逆性：光看令牌推不出原始数据，除非查映射表。
- 格式保留：长度、字符集可以自定义，方便对接老系统。
- 唯一性：同一个原始数据每次生成相同的令牌吗？不一定，这要看你的策略。
| 属性 | 说明 | 常见做法 |
|---|---|---|
| 长度 | 令牌字符串字符数 | 与原始数据等长 or 固定32位 |
| 字符集 | 允许出现的字符 | 数字、字母、或自定义组合 |
| 生成方式 | 随机 / 散列 / 加密 | 随机+查重（最常用） |
| 防碰撞 | 不同原文不能产生相同令牌 | 生成后检查映射表唯一性 |
2. 令牌库（ Vault）—— 安全保险箱
令牌库就是存放映射关系的地方。你可以把它想象成一个银行保险箱——里面锁着“原文 → 令牌”的对照表。我见过不少团队把映射表直接扔在业务数据库里，结果一拖审计就出问题。为什么？因为令牌库需要额外的安全防护：
- 独立部署，跟业务库网络隔离
- 所有访问必须鉴权，且记录审计日志
- 数据本身加密存储，即使硬盘被拖走也读不了
令牌库的访问性能也很关键。每次令牌化或去令牌化都要查库，QPS一高就扛不住。我的经验是给它配独立Redis做二级缓存，命中率能到90%以上。
3. 映射表（Mapping Table）—— 核心关联
映射表的作用就是把原文和令牌拴在一起。它通常是一个数据库表，最简单的结构就两列： 和 original_data。但实际项目里，我建议至少再加三列：
- created_at – 记录生成时间，方便做过期清理
- expires_at – 令牌有效期，到期自动删除映射
- tenant_id – 多租户场景下区分客户
-- 一个典型的映射表DDL
CREATE TABLE _mapping (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
VARCHAR(64) NOT NULL UNIQUE,
original_data TEXT NOT NULL,
data_type VARCHAR(32) NOT NULL, -- 如: 'credit_card', 'ssn', 'email'
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
expires_at DATETIME NULL,
tenant_id VARCHAR(32) NOT NULL,
INDEX idx_ (),
INDEX idx_expires (expires_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;original_data 上建索引——若能在原文上做快速查询，攻击者就能通过暴力猜解倒推敏感数据。
4. 去令牌化（De-tokenization）—— 把替身变回本尊
去令牌化是令牌化的逆过程。传入一个令牌，系统查映射表返回原始数据。听起来简单，但有两个常见问题：
- 权限控制：并不是所有人都能看原始数据。我们通常要求调用方提供签名或临时凭证，服务端校验通过后才释放原文。
- 令牌过期：映射关系可能已被删除。这时返回空或特定错误码，而不是去猜测原文。
我做过一个金融项目，报表系统需要每天凌晨跑批量去令牌化。一开始用单线程查库，跑完要3小时。后来改成批量查询（一次查1000个令牌）加上缓存预热，10分钟搞定。嗯，所以别小看去令牌化的性能设计。
一句话总结四个概念的关系
令牌化时，系统生成令牌并存入映射表；去令牌化时，系统查映射表还原原文；令牌库是存放映射表的安全容器。说白了就是这么个流程。
这四者就像一套组合拳，少一个都不完整。后面几个章节我们会深入每个组件的工程实现细节，包括高可用设计、性能调优和合规要点。先把这张图刻在脑子里，后面学起来会顺很多。