第4章存储选型与数据保护

4. 存储选型与数据保护：分布式存储 vs 集中式存储、数据加密与备份策略、同城/异地容灾

存储选型这件事，在金融行业里从来都不是一个纯技术问题。它更像是一场平衡术——性能、成本、合规、运维复杂度，哪个都不能丢。我这些年参与过的项目里，因为存储选型翻车的案例不在少数。说白了，选错了存储，后面所有的数据保护策略都是空中楼阁。

很多人一上来就问：「分布式存储和集中式存储哪个好？」我的回答通常是——你先告诉我你的业务场景是什么。

集中式存储，比如传统的SAN、NAS，它的核心优势是稳定和成熟。金融核心交易系统、账务系统，这些对延迟极度敏感的场景，我个人的习惯是优先考虑集中式存储。为什么？因为它的IO路径短，延迟可控，而且有几十年的运维经验积累。

我在某股份制银行的核心系统迁移项目中遇到过一个问题：他们想把核心账务数据放到分布式存储上，结果压测时发现，在高峰期的写延迟比集中式存储高了将近3倍。后来还是老老实实换回了全闪存的集中式存储。

分布式存储，比如Ceph、MinIO、以及各大厂商的分布式存储方案，它的强项是扩展性和成本。日志数据、影像文件、备份数据、非结构化数据，这些场景用分布式存储非常合适。你想想看，几百TB甚至PB级别的数据，如果用集中式存储，那成本会高得吓人。

  核心原则： 核心交易用集中式，海量非结构用分布式。混合云环境下，两者往往共存。

下面这张图是我自己总结的选型逻辑，你可以参考一下：

金融数据加密，不是「加个密就完事」那么简单。监管要求、内部合规、审计追溯，每个环节都有讲究。

静态数据加密，也就是数据落盘加密。我建议优先使用硬件加密卡或HSM（硬件安全模块）来做密钥管理。软件加密虽然灵活，但性能损耗明显。我在某证券公司的项目中测试过，纯软件AES-256加密，IOPS下降了约15%-20%。

传输加密，这个大家比较熟悉，TLS 1.2/1.3是标配。但有一个坑——很多人在混合云环境下，忽略了云专线内部的加密。其实专线虽然物理隔离，但合规要求里往往明确要求「传输全程加密」。所以，IPsec VPN或者SSL VPN是必须的。

一个小技巧： 密钥轮转周期不要设得太长。我个人习惯是90天轮转一次，既满足合规，又不会给运维带来太大负担。

传统的3-2-1备份原则（3份副本、2种介质、1份异地）在金融行业需要升级。我称之为3-2-1-1-0原则：

我曾经遇到过一个客户，备份做了三年，从来没恢复过。结果真出故障时，发现备份文件早就损坏了。嗯，从那以后，我给自己定了个规矩——不做恢复演练的备份，等于没做备份。

容灾架构设计，说白了就是在RPO（恢复点目标）和RTO（恢复时间目标）之间找平衡。金融行业的核心系统，RPO通常要求小于15分钟，RTO小于30分钟。这个要求其实非常高。

同城容灾，一般通过存储同步复制实现。两个数据中心距离在50公里以内，光纤直连，延迟在1ms以内。这种方案可以实现RPO≈0，但成本高，而且对网络稳定性要求极高。

异地容灾，距离通常在几百公里以上，使用异步复制。RPO一般在几分钟到几十分钟之间。我建议异地容灾不要只依赖存储层复制，最好结合数据库层的日志同步（比如Oracle Data Guard、MySQL Group Replication），形成双重保障。

注意： 同城双活听起来很美，但实际运维中「脑裂」问题非常棘手。我曾经在项目中遇到过仲裁节点故障导致双中心同时写的情况，差点造成数据不一致。所以，仲裁机制一定要设计好，建议使用独立的仲裁节点或云上的仲裁服务。

下面是一个典型的金融行业容灾架构示意：

最后说一句，容灾方案不是建完就完事了。我建议每半年做一次容灾切换演练，而且要在业务低峰期做。别等到真出事了才手忙脚乱——那时候，每一秒都是钱。

公众号:蓝海资料掘金营，微信deep3321