数据库管理-第295期 IT架构与爆炸半径（20250221）

数据库管理-第295期 架构与爆炸半径（20250221）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

最近大家都在写DeepSeek和AI，上周蹭过热点了，我也就不继续了。
这几天在和几位好友扯淡时，发现一个新鲜用于IT高可用的军事术语——爆炸半径。

1 术语新解

简单来说，爆炸半径就是当某个软件或硬件出现故障时，对整个系统运行的影响程度。比如一台服务器宕机，所有页面打不开了还是部分页面打不开或者全都正常；一个缓存挂了，是无影响、部分数据读不到了还是全都读不到了；一个交换机掉电，是部分设备网络不通还是全都不通了还是都正常等等。作为数据相关从业者，本期主要从数据架构相关层面来进行解读。

2 硬件：存储VS本地盘

“传统”的IT架构中，包括基于VMware的虚拟化和Oracle的基于共享存储的RAC，都有一个非常重要硬件组件——存储，这里主要特指在很多人眼中的称之为“硬盘阵列柜”的东西，也就是集中共享存储。很多人认为集中存储如出现故障，其爆炸半径是十分可怕的，因为不管是虚拟机还是数据库的数据都存放在一个相对集中的地方，一损全毁，很可能整个IT架构的渣都不剩，这个忧虑其实不无道理。也因大家对集中存储爆炸半径的顾虑，加上集中存储高昂的采购费用，使用服务器本地盘以分散副本方式来组织数据成为了一些人的理想架构。
对于企业存储而言，不论是从设计还是实际故障统计看，都不太可能出现整机完全不可用的情况。因为硬件层面存储内部各个组件，包括但不限于磁盘，控制器，电源模块，CPU内存等都是有冗余架构设计的。比如电源是多路冗余PDU供电，除非整机房断电存储设备是不会下电的；再比如单个控制器故障了，他上面的网卡会立即被其他控制器接管（服务器完全无法做到这点）。另一方面，企业存储设备之所以比一堆硬件堆在一起价格高，是因为他不仅仅是硬件简单组装拼插，其内部包含了一套完整的软件逻辑，比如磁盘IO分布和介质生命周期管理，数据因器件老化静默损坏的提前修复，精细化任务调度减少IO抖动等，更不用说还有完整的可视化报表和维护管理工具等。据说企业级存储的代码量可能高达上千万行，而我们知道成熟软件中功能代码占比并不会很高，大部分都是在处理健壮性、故障、异常、易用这些问题，这也是成熟产品真正价值所在。而且存储的高可用架构其实也是非常成熟的，可以实现多活与异地灾备的，当然这个价格也是相对较贵的；另一方面存储其实也可以非常方便的横向扩容，增加容量与性能。
对比使用服务器本地磁盘，其实就服务器本身来说，其故障率是比较高的，稳定性就远低于存储设备，而且稳定性是随着使用时间不断下降的。在某个业务场景下的数据库，9台同期上线的使用本地盘的服务器在非常短的时间内（小于恢复首台故障服务器时间）有6台故障，导致数据库中断且难以恢复。为什么感觉很难看到类似的消息，一方面是有些场景负载小，高负载对硬件耐久度的消耗是明显的，负载小达不到容易出现故障的阈值；另一方面则是关键行业/系统对硬件生命周期管理非常严格，硬件更换周期远低于平均故障时间。很多人没在这方面吃过亏，所以对硬件稳定性没有实际的感触；即便吃过亏有时候没到一定程度也不敢说，毕竟还有决策的成分在里面。
存储除了极高的稳定性以外还能有一些其他的用法/特性：服务器异常可以通过重新挂在对应的LUN即可实现快速恢复数据；需要完整的测试数据，存储容量足够的情况下，可以直接克隆/快照完成一次不完全恢复即可；基于存储的备份与恢复效率也更高等等。
因此我们在一些重要的业务场景/系统会看到一种“奇怪”的数据库架构，数据分散在各个服务器上的存储映射盘中，因为数据库软件与存储对接，备份直接通过存储进行全量+增量操作，任何服务器异常均可通过重新挂载快速恢复。这是一种对稳定性的极端追求。
感觉说了这么多似乎是在给集中存储洗地，但是其高昂的价格确实不适合一些场景。但是我想说的是，单纯讨论一个组件的爆炸半径其实并不那么合理，还需要考虑这个爆炸是不是那么容易发生，毕竟一颗核弹的杀伤力用远火洗地也能实现。

3 数据库

3.1 多模VS专用

数据库是多模解决大多数问题，还是用专用数据库分开去解决特定的问题，在我之前的文章里面也说过很多次。除了应用架构：比如是通过数据库还是应用来处理管各类理数据；技术成熟度：一般情况下专用数据库的性能与功能性强于大多数多模数据库。在某些情况下也有考虑爆炸半径的原因，每种专用数据库承载其擅长的数据有效发挥其效能，一种数据库异常影响部分场景或者仅影响速度；某些用于缓存和全文搜索的数据库还能在其他关联数据库异常时提供应急接管和额外的恢复选择等等。
但是我认为，无论如何选择，数据库的高可用都需要做好，这样才能尽可能的降低任何故障带来的影响。另一方面应用也需要做好击穿/绕行的机制，慢和不可用之间还是有很大的差距的。数据治理也必须做好，不同类型的数据库之间是肯定存在重复数据的，做好这些数据的维护是十分重要的。

3.2 集中式VS分布式

还是一个老生常谈的话题，其实和前面讨论硬件内容也是有一定关联性的，只不过并不是所有的集中式数据库都会使用存储设备来存放数据。使用分布式数据库一方面是解决“单机性能不足”的问题，另一方面也确实可以降低甚至消除单点故障对数据库整体带来的影响。就分布式数据库本身而言影响最大主要有两方面，一个是网络，众所周知相较于CPU-内存-磁盘的交互网络是不稳定的，这种不稳定主要体现在带宽、延迟波动和丢包上，比起核弹的爆炸半径来说，这更像是游击战的袭扰，小而多，某些情况下也足够致命；第二个方面其实是加在网络上的数据的不合理设计或使用，即被迫主要通过网络来筛选数据而不是内存，这将使本就网络不稳定的问题被进一步放大甚至完全崩溃。因为CAP理论，分布式数据库为了保证足够的性能并确保可用性是需要牺牲一定的一致性的，如果设计不合理这个一致性的问题也会被放大并造成巨大影响，不能出现单点故障了，似乎没影响但是数据没对了。分布式数据库需要控制小爆炸带来的累加大范围影响。
我认为，集中式与分布式数据库无好坏之分，二者有各自的优点与应用场景，只不过在我看来随着硬件水平和数据库的巨大发展，很多情况下是可以不一定必需使用分布式数据库解决问题了，举个例子，现在OCI上对接基于SuperCluster和Nvidia GPU构建的AI算力集群的Exadata@Cloud据说是可以处理ZB级数据了，AI时代对数据的高速检索是很重要的。本小节跑远了，补充一句两只手比一只手劲大，为什么人没长出来十个八个手，大脑协调会出问题。

4 公有云VS非公有云

这里说到云，又得划分公有云、私有云、虚拟化、裸金属等等概念，这里按照章节题目定义一下私有化部署的统称为非公有云云。
在一定程度下公有云确实可以简化IT建设的流程，使得业务可以更快上线的同时减少在维护层面的投入，但在一定规模后期费用也会存在不透明的问题。从最近一段时间全球各大公有云的故障来看，其中多次故障的爆炸半径都是核弹级的，不乏整个公有云不可用的出现。不得不说把一切基础架构都交出去，还得看自身的投入与决策，有时候还需要考虑政策与法律因素。
非公有云确实需要投入更多基础架构建设的投入，对技术和人的挑战更大，但是却能自己把控一些关键内容，有时候不那么统一的底座反而能降低一些爆炸半径。但是如果技术架构的复杂度超过了自身把控能力，那么仍会比较危险。
从数据库层面来看，会看到一些严重依赖公有云底座的产品私有化部署时需要一并部署公有云底座，同公有云环境有足够体量不同，在私有化部署公有云底座中经常会发现其本身会消耗较多资源，变相带来一些资源浪费。

总结

老词新用，IT架构需要控制故障的爆炸半径。
老规矩，知道写了些啥。