课程介绍：列级加密与高可用架构概述

各位同学，我们从最基础的问题开始聊。

你在系统里存了一堆敏感字段——身份证、手机号、银行卡。DBA一看表里全是明文，直接吓一跳。

加密？当然要加。但怎么加？

有人对所有字段统一用一个密钥，一个表锁就锁死全库；有人只在应用层搞个AES工具类，结果密钥写死在配置文件里，Git一提交就泄露。

这些我都见过，刚入行时自己也踩过。真正把列级加密做好，你得同时搞定两件事：加密粒度和高可用。缺一个，系统就得崩。

这门课就是来拆解这个问题的。

什么是列级加密？

说白了，就是对数据库表的某些列单独加密，而不是整表、整库一把梭。

为什么非要列级？

你想想看：一张用户表有20列，只有手机号和身份证需要加密。如果全表加密，每次查询都要全表解密，性能直接腰斩。列级加密只处理敏感列，其他列原样存取，快得多。

举个实例：

-- 原始数据
INSERT INTO user (id, name, phone, id_card) VALUES (1001, '张三', '13800138000', '110101199001011234');

-- 加密后存储（phone 和 id_card 被加密）
INSERT INTO user (id, name, phone, id_card) 
VALUES (1001, '张三', AES_ENCRYPT('13800138000', @key), AES_ENCRYPT('110101199001011234', @key));

嗯，这里要注意——加密后的数据是二进制，存到数据库里要么用BLOB，要么VARBINARY。我见过有人图省事直接存VARCHAR，结果乱码丢了数据，这种坑我踩过一次就记住了。

高可用为什么是硬门槛？

加密不只是一个功能，它是一个基础设施。基础设施挂了，所有依赖它的业务全瘫痪。

我记得有一次线上故障：密钥管理服务（KMS）的节点宕机，导致所有列级加密字段无法解密。用户登录、订单查询全崩，花了半小时才手动切到备用节点。那半小时里，业务损失按百万算。

所以高可用 + 列级加密，必须一体化设计。不是先搞加密，再贴个HA补丁，而是从架构层面就把容错、切换、灾备写进代码里。

列级加密高可用架构全景

这部分我习惯用一个三层结构来梳理。下面这张图你多看几遍，后面每章都会回头引用它的框架。

三个设计要点，我建议你现在就记住

1. 加密与HA必须双向感知：加密引擎的扩缩容要同步到HA代理的路由表，否则流量打到正在轮转密钥的节点上就惨了。我曾经因为没配健康检查，切换时有3秒的脏数据窗口，后来加了预热期才解决。
2. 密钥不能成为单点：KMS至少部署3节点，用Raft或Paxos保证强一致。别图省事只搞主从，脑裂时密钥版本冲突你就哭吧。
3. 性能熔断器：加密操作一旦超过阈值（比如100ms），自动降级为旁路记录，不阻塞业务。怎么设计熔断策略？我们在第六章会细讲。

这门课你将获得什么？

刚才那张全景图，就是我这门课的骨架。后面的29章，每一章都是在给这个骨架填血肉。

我不打算堆太多纯理论。每一章我都会拿出真实项目里遇到过的场景——比如怎么设计主备引擎的切换预案，怎么让加密密钥轮转时零停机，怎么在列级加密场景下做读写分离……

你会接触到完整的代码示例、配置模板、以及我踩过的坑。比如：

• 列级加密引擎的多主架构设计
• 基于Raft的密钥同步方案
• 故障切换时的一致性保护——避免出现“半加密半明文”的幽灵数据
• 如何用Sidecar模式无侵入地给现有应用加上列级加密