发帖
雷达卡
小明的存储技术成长记
小明刚加入一家专注于短视频APP的科技公司，负责数据存储相关的工作。从第一天起，他就跟随经验丰富的李哥，逐步掌握了信息存储的全套技能——这正好涵盖了我们前八章的所有知识点。让我们跟随小明的经历，重温那些被遗忘的知识。
第一章：入职第一天——为什么学习存储？（绪论）
小明到岗时，公司正面临一个难题：用户每天观看的短视频、发布的评论，以及后台的交易数据，一天就产生了30TB！李哥递给他一份IDC报告：“你看，2028年全球数据量将达到394ZB，我们现在这点数据只是个开始。”
小明困惑地问：“这些数据存哪里？丢失了怎么办？”
李哥笑着回答：“这就是我们学习存储的原因。首先得了解**数据中心**是什么——它就像一个‘数据仓库’，里面包含运行应用的服务器（主机）、传输数据的网络、存储数据的存储设备，以及数据库（如MySQL）和各种APP（如我们的短视频后台）。如今数据量巨大，传统的存储方式已无法满足需求，因此我们需要依赖虚拟化（如使用Docker部署APP，一个服务器可以运行多个）和云计算（如将部分数据放在阿里云，无需购买硬件）。”
那天，小明记住了：存储的核心目标是“高性能、高可靠、高可用”——就像用户刷视频不能卡顿（高性能）、交易记录不能丢失（高可靠）、APP需24小时可用（高可用）。
第二章：首次搭建环境——数据中心里有什么？（数据中心环境）
第二周，小明需要帮助公司搭建新的应用服务器，李哥让他先了解“数据中心的核心组件”。
首先是**应用程序**：公司的短视频APP属于“写入密集型”（用户不断上传视频），后台报表系统则是“读取密集型”（运营人员频繁查询数据），不同的APP对存储有不同的要求。
然后是**主机（服务器）**：内部包含CPU、内存，以及操作系统（如Linux）、LVM（逻辑卷管理，可以将多个硬盘合并成一个“大硬盘”，例如将3个1TB硬盘合并成2TB的逻辑卷）、文件系统（如EXT4，管理文件存储位置）。李哥还教他计算**内存虚拟化**：当物理内存不足时，可以使用磁盘作为“交换空间”，但速度会变慢。
接着是**连接协议**：服务器连接硬盘使用SAS线（如SAS 4.0可达24Gb/s，适用于服务器），连接显卡使用PCIe（PCIe 4.0的x16可达32GB/s），普通电脑连接硬盘使用SATA（6Gb/s）。
最关键的是**磁盘性能**：李哥给出了一个公式——**磁盘服务时间=寻道时间+旋转延迟+传输时间**。例如公司使用的15000rpm硬盘，旋转延迟为（60/15000）/2=2ms，寻道时间平均5ms，传输速度为40MB/s，那么读取一个4KB的数据，服务时间为5+2+（4KB/40MB/s）≈7ms，计算下来每秒可以处理约140个IO（IOPS）。
最后，小明使用**DAS**搭建了环境——即服务器直接连接硬盘，简单但不够灵活，后来随着公司数据量的增加，这种方法变得不再适用。
第三章：首次数据丢失——RAID救了命！（数据保护-RAID）
入职第三周，问题出现了：一个存储硬盘损坏，导致其中的用户评论丢失了一半。李哥说：“现在该学习RAID了，它是数据保护的‘第一道防线’。”
小明首先理解了RAID的核心逻辑：将多个磁盘组合成一个“逻辑盘”，以提高性能或实现容错（或两者兼备）。核心技术有三个：
- 分条（Striping）：将数据分成小块，存储在不同的磁盘上，例如将“小明爱刷短视频”分成“小明”“爱刷”“短视频”，分别存储在3个磁盘上，读取时三个磁盘同时读取，速度快（这是RAID0的核心）。但RAID0没有容错功能，一个磁盘损坏会导致全部数据丢失，适用于存储临时文件。
- 镜像（Mirroring）：一个磁盘的数据完全复制到另一个磁盘，例如“小明”同时存在于盘1和盘2，盘1损坏后盘2可以继续工作（RAID1）。容错效果好，但浪费了一半的存储空间，适用于存储数据库日志（不能丢失的数据）。
- 奇偶校验（Parity）：使用XOR运算存储“校验数据”，例如RAID5有3个数据盘+1个校验盘，数据为4、6、7，校验值为4⊕6⊕7=1；如果7所在的磁盘损坏，可以通过4⊕6⊕1计算出7。RAID5平衡了性能和容错，适用于存储邮件系统。
李哥还让小明计算了一个题目：公司APP高峰期IOPS为1200，读写比为2:1，使用RAID5时，磁盘负载为（1200×2/3）+（1200×1/3×4）=800+1600=2400 IOPS——因为RAID5写一次需要读取旧数据、旧校验，写入新数据、新校验，共4次IO。
后来，公司将核心数据换成了RAID10（先镜像再分条），既提高了性能又实现了容错，再也没有因为磁盘损坏而丢失数据。
第四章：数据量增加难以管理——智能存储系统来帮忙（智能存储系统）
随着用户的增长，公司的存储从“几块硬盘”变成了“几十块的阵列”，小明发现手动管理非常麻烦。李哥带他参观了新采购的**智能存储系统（ISS）**，称其为“存储界的智能手机”。
ISS的核心组件像“三明治”：
- 前端：连接主机的接口，如FC口、iSCSI口，可以同时连接几十台服务器。
- 缓存：
：相当于“临时存储架”，读取数据时先检查缓存（如果命中则直接提供给主机，速度较快），未命中时再从磁盘读取（同时将数据存储到缓存中，以便下次快速访问）；写入数据有两种方式：直写（先写入磁盘再确认，安全性高）、延迟写入（先确认再逐步写入磁盘，速度较快）。例如，公司的应用程序采用延迟写入缓存，当用户上传视频时，可以迅速收到“成功”的通知。
后端
：连接物理磁盘，能够管理RAID、SSD和HDD的混合存储。
还有一个重要功能是**存储资源分配**：过去为服务器分配LUN时，需预先计算好容量（例如给服务器分配100GB，即使未完全使用也会造成浪费）；如今使用“精简配置”，向主机显示10TB的存储空间，实际上仅使用3TB，剩余的资源可以分配给其他服务器。李先生还教他使用“LUN屏蔽”——例如市场部门的服务器只能访问其自身的LUN，以防误操作导致数据丢失。
借助ISS，小明管理存储的时间从每天2小时减少到了20分钟。
第五章：随着服务器数量增加需要共享——FC SAN登场（光纤通道存储区域网络）
公司新增了10台应用服务器，如果每台都使用DAS，则无法实现数据共享（例如A服务器的视频数据，B服务器无法读取）。李先生说：“应该采用SAN，它是‘存储的局域网’，可以让所有服务器共享存储资源。”
他们选择的是**FC SAN**，因为它的传输速度快（32Gb/s）、稳定性高，适合核心业务。小明首先了解了各个组件：
HBA卡
：服务器上的“FC网卡”，相当于为服务器安装了一条“高速数据传输线”。
光纤
：分为单模（传输距离可达10公里，适用于数据中心间通信）和多模（传输距离达数百米，适用于数据中心内部），公司数据中心使用多模，两地容灾备份使用单模。
FC交换机
：类似于“存储的路由器”，通过交换机连接服务器和存储设备，可以建立“专用通道”，避免与办公网络争夺带宽。
FC SAN有许多规定：例如**FC协议栈**，从物理层（FC-0，光纤）到应用层（FC-4，映射SCSI），确保数据传输既快速又准确；还有**WWN地址**，每个HBA卡和存储端口都有唯一的WWN（如同设备的身份证），确保不会混淆；**分区**功能更为关键——将10台服务器划分为“视频处理”和“数据分析”两个区，彼此之间无法互访，大大提高了安全性。
目前公司的核心数据库运行在FC SAN上，10台服务器同时读取数据也不会出现卡顿。
第六章：FC SAN成本过高？IP SAN和FCoE来补救（IP SAN和FCoE）
尽管FC SAN性能优越，但设备和光纤的成本较高，公司的分支机构（如广州分公司）预算有限，小明再次感到困扰。李先生建议：“有更经济的解决方案——IP SAN和FCoE。”
首先学习**IP SAN**：利用普通以太网传输存储数据，核心在于iSCSI协议——将SCSI命令封装在IP包中，例如广州分公司的服务器使用普通网卡（加上iSCSI软件），即可连接总部的存储，无需购买FC HBA卡，节省了大量费用。如果担心CPU负担过重，还可以购买iSCSI HBA卡，将iSCSI处理任务转交给卡完成。
还有**FCIP**：例如总部和上海分公司均拥有FC SAN，通过FCIP将FC帧封装在IP包中，利用互联网连接两地，实现数据同步，无需铺设专用光纤。
后来公司新建的数据中心采用了**FCoE**：整合了FC和以太网，服务器只需插入一块CNA卡（既能连接以太网，也能传输FC数据），数据中心内不再需要铺设两种线路（FC线和网线），进一步降低了布线成本。小明计算过，使用FCoE后，新数据中心的布线成本降低了40%。
第七章：需要共享文件？NAS最为便捷（网络连接存储）
公司的运营团队频繁需要共享报告和策划方案，使用SAN只能存储“数据块”，无法直接存储文件。李先生带来了一台**NAS设备**：“这是一台‘专门用于文件存储的服务器’，支持Windows和Linux用户访问。”
NAS的核心在于**文件共享协议**：Windows用户使用CIFS协议（例如访问“\\NAS\运营报告”），Linux用户使用NFS协议（访问“/mnt/nas/策划案”），无需安装复杂的软件，双击即可打开文件。
小明还学习了NAS的三种应用方式：
统一NAS
：既可以存储文件（NAS），也可以存储数据块（SAN），例如公司的NAS同时为运营团队提供文件传输服务，为应用程序存储数据库数据，只需管理一个设备。
网关NAS
：利用现有的SAN存储，添加一个NAS前端，即可提供文件服务，无需购买新的存储设备。
横向扩展NAS
：随着公司视频素材的增多，可以通过增加NAS节点（服务器）来提升存储容量和性能，例如原本一个节点可存储10TB，增加三个节点后总存储量可达40TB，并且支持并行读写。
现在运营团队不再依赖U盘传输文件，直接从NAS获取所需文件，使用更加便捷。
第八章：面对海量非结构化数据？对象存储来解决（基于对象的存储和统一存储）
公司的短视频素材、用户头像等均为“非结构化数据”，总量达到500TB，使用NAS管理时，目录层次过于复杂（例如“素材/2024/10/01/北京/景点/天安门.mp4”），查找文件耗时较长。李先生建议：“应当使用对象存储，它是‘管理非结构化数据的理想工具’。”
对象存储的原理非常简单：将数据打包成“对象”，每个对象包含三个部分——数据（例如视频文件）、元数据（例如拍摄时间和地点）、唯一对象ID（通过哈希算法生成，例如“a3f7d2...”）。查找文件时无需遍历目录，直接使用对象ID查询，可以在几秒钟内找到文件。
公司使用的OSD（对象存储设备） 是智能化装置，具备自身的CPU和内存，能够管理和组织本地的对象，并且可以构建集群——例如10个OSD节点组成的集群，总存储量达到500TB，即使一个节点出现故障，数据仍然安全地保存在其他节点中，无需担心数据丢失。
此外，还有CAS（内容寻址存储），专用于存储“不可更改的固定内容”，例如用户的实名认证图片、视频审查记录等。存储这些内容时会生成独一无二的“内容地址”（CA），只要内容没有变化，其CA也不会改变，确保了数据未被篡改——这一点对于遵守法规至关重要，例如在监管机构检查时，可以证明图片未曾被修改。
最终，公司部署了统一存储解决方案：一个平台同时支持块存储（供应用程序存储数据库）、文件存储（供运营人员传输报告）、对象存储（存储视频资料）。小明只需通过一个管理界面就可以管理所有的存储资源，不再需要在多个系统之间频繁切换。
第九章：APP突然宕机——如何保障业务连续性？（业务连续性概述）
入职第五个月的一个周一，公司应用程序突然崩溃——由于机房交换机发生故障，用户无法观看视频，后台也无法查询数据。经过3小时紧急维修才恢复正常，运营团队十分焦急。李哥解释说：“这就是‘业务连续性（BC）’所要解决的问题——确保在遇到意外中断时，业务能够迅速恢复正常。”
小明首先学习了信息可用性指标：
- MTBF（平均无故障工作时间）：例如，公司存储阵列的MTBF为750000小时，100个阵列的MTBF则为750000/100=7500小时（约1年），这意味着平均每1年才会有一次集体故障。
- MTTR（平均修复时间）：此次交换机故障修复耗时3小时，因此MTTR为3小时。
- 可用性公式：可用性 = MTBF / (MTBF + MTTR)，计算得出公司存储的可用性为7500 / (7500 + 3) ≈ 99.96%，而应用程序要求的可用性为99.99%（每年宕机时间不超过52分钟），差距较大。
李哥还教授了他两个关键目标：
- RPO（恢复点目标）：例如，应用程序的RPO为1小时，意味着故障后最多可能丢失1小时的数据（例如1至2点之间的数据丢失，从1点的备份恢复）。
- RTO（恢复时间目标）：RTO设定为30分钟，意味着故障后必须在30分钟内恢复业务。
为了达到标准，公司采取了两项措施：
- 消除单点故障：例如安装两台交换机（一台主用，一台备用）、服务器的NIC卡分组（两个网络接口连接不同的交换机，一个故障时另一个可以接管）、使用冗余端口的存储阵列。
- 安装多路径软件：服务器连接存储时采用双路径（例如一条光纤通道和一条iSCSI线路），软件会自动选择最佳路径，一旦一条路径中断会自动切换到另一条，用户不会察觉。
之后，公司的可用性达到了99.99%，再也没有因硬件故障而长时间宕机的情况。
第十章：数据丢失后的恢复——如何进行备份和归档？（备份和归档）
不久之后，又发生了一件小事故：一名实习生不小心删除了过去三天的用户评论数据，小明非常紧张——幸好李哥之前已经安排了备份。本章中，小明彻底掌握了“备份和归档”的知识。
首先是备份粒度，三种方式各有利弊：
- 完整备份：例如，每周日凌晨2点将所有数据（500TB）全部复制一份，优点是恢复速度快（直接使用周日的备份），缺点是耗时长（需8小时）且占用大量空间（500TB）。
- 增量备份：周一至周六仅复制“比前一天新增或修改”的数据，例如周一复制5TB（周日至周一的新数据），周二复制3TB（周一至周二的），优点是速度快、节省空间，缺点是恢复较慢（需要先恢复周日的完整备份，再依次恢复周一至周六的增量备份）。
- 累积备份（差异备份）：周一至周六复制“比周日完整备份新增或修改”的数据，例如周一复制5TB，周二复制8TB（周日至周二的），恢复时只需周日加最新的累积备份（如周六的），比增量备份更快，比完整备份更节省空间——公司最终选择了“周日完整+周一至周六累积”的方案，平衡了速度与空间。
接下来是备份方法：
- 热备份（在线备份）：备份过程中应用程序正常运行（例如用户仍可发表评论），使用“打开文件代理”备份正在使用的文件（例如正在编写的评论日志），适用于核心业务（不允许停机）。
- 冷备份（离线备份）：备份时关闭应用程序（例如每周二凌晨4点关闭报表系统），优点是数据绝对一致，缺点是对业务造成影响——公司仅在备份旧数据库时使用此方法。
还有一个工具称为重复数据删除：用户评论中存在许多重复内容（如“666”、“好看”），备份时删除重复项，500TB的数据可以压缩到150TB，大幅节省存储成本。小明选择了“基于源的重复数据删除”——在备份前先在服务器上删除重复数据，然后再传输到备份设备，节省了网络带宽。
最后是数据归档：公司有许多两年前的旧视频（用户很少观看，但不能删除，以符合法规要求），小明使用CAS（内容寻址存储）进行归档——将旧视频作为对象存储，生成唯一的“内容地址”（如根据视频内容计算的哈希值），不仅不可更改，而且可以快速检索，同时节省了主要存储的空间。
第十一章：数据库逻辑损坏——本地复制快速应对（本地复制）
有一次，由于SQL语句编写错误，导致部分用户数据逻辑损坏（数据仍在，但变为乱码），小明使用备份恢复需要2小时，李哥说：“太慢了，使用本地复制，10分钟就能解决问题。”在本章中，小明了解了“本地复制”的核心——在同一数据中心内快速创建数据副本，便于应急恢复。
首先是本地复制的关键要求：
- 一致性
副本需与原始数据相匹配，例如文件系统应“更新主机缓存”（将未写入磁盘的数据从内存中清除），数据库则要“按事务顺序复制”（例如先记录“用户点赞”，再记录“点赞数+1”，不能颠倒）。
时间点（PIT）副本：例如创建上午10点的副本，恢复时即可返回至10点的状态（恰好避免10点半的逻辑损坏）。
接着是三种本地复制技术：
基于主机的复制：例如利用LVM做镜像——将源卷的数据即时复制到目标卷，缺点在于占用主机CPU（如复制过程中CPU使用率由30%上升至50%），适用于较小的数据集（如100GB的日志文件）。
基于阵列的复制：公司使用的存储阵列具备此功能，如“基于指针的虚拟复制”——无需复制全部数据，仅存储指向源数据的指针，例如500TB的数据，副本只需50TB（存储指针和已更改的数据）。其原理是**CoFW（首次写入时复制）**：如源数据“小明”需更改为“大明”，首先将“小明”复制到副本的“存储位置”，然后更改源数据，副本仍可见“小明”，恢复时直接使用该副本。
基于网络的复制（CDP）：在主机与存储间增加CDP应用程序设备，所有写操作均复制一份至日志卷，能够恢复至“任意时间点”（例如恢复至10点23分05秒的状态），适合关键数据库（不允许丢失任何数据）。
小明还学习了虚拟化环境下的复制：例如为APP的虚拟机创建“快照”——捕获10点的虚拟机状态（含系统配置、数据），恢复时一键即可返回10点；制作“克隆”——复制一个完全相同的虚拟机供测试团队使用（测试更改数据不影响生产）。那次数据库损坏，小明采用基于阵列的副本，10分钟内即完成恢复，远比备份快得多。
第十二章：异地灾备——远程复制如何实施？（远程复制）
随着公司规模的扩张，李哥表示：“不应将所有鸡蛋放在同一个篮子里，需在上海建立一个灾难恢复中心，以防北京机房发生地震时，上海能立即接管。”本章节小明主要研究“远程复制”——将北京的数据传输至上海，实现异地灾备。
首先是两种远程复制模式：
同步复制：当北京的存储写入数据时，必须等待上海的存储也完成写入，才能向主机发送“成功”确认。优点是RPO接近0（几乎不丢失数据），缺点是受到距离的影响（如北京至上海1300公里，光信号需4毫秒，加上网络延迟，写响应时间从10毫秒增至20毫秒），适用于近距离的场景（如北京至天津，200公里以内）。
异步复制：北京的存储写完即向主机确认，数据暂时存储于本地缓存区，随后“逐步”传输至上海。优点是不受距离限制（北京至上海亦可行），缺点是RPO存在延迟（如缓存10分钟，若北京机房发生故障，将丢失10分钟的数据）。公司选择了“同步+异步”的组合方式：北京至天津的备用中心采用同步（确保核心数据无损），而北京至上海的灾难恢复中心则使用异步（节约带宽，接受10分钟的延迟）。
随后是三站点复制：为了更加安全，他们构建了“北京（源）→天津（同步）→上海（异步）”的串联模式，即使北京和天津同时出现问题，上海仍有副本；还可以构建“三角形模式”——北京同时向天津和上海传输数据，两个备用中心可以相互同步，更加灵活。
小明还掌握了数据迁移：例如将旧存储中的50TB数据迁移至新存储，采用“热迁移”技术——迁移期间主机仍可读写旧存储，新存储实时同步数据，同步完成后切换至新存储，用户毫无察觉（无需停机）。那次数据迁移，小明运用热迁移技术实现了零停机迁移，获得了老板的认可。
第十三章：成本过高？云计算来助阵（云计算）
随着数据量的增长，公司购买存储、服务器的成本日益增加（每年硬件投资需200万元），李哥建议：“将非核心数据存放于云端，可节省大量开支。”本章中，小明理解了“云计算”如何与存储相结合。
首先是云计算的核心特性（NIST定义），小明将其简化为“自助、共享、快速扩展、计费、广泛接入”：
按需自助服务：例如需要100GB存储空间，可在阿里云控制台上自行操作开通，无需服务商人工干预。
资源共享：阿里云的存储池服务于众多公司，例如小明所在公司使用的100GB与其他公司的存储共享物理磁盘，降低了成本。
快速灵活：用户需求增长时，可迅速从100GB扩展至1TB，几分钟内即可完成，无需等待购置新硬件。
计费服务：按实际使用量付费，例如100GB每月费用为50元，无需预付全额款项。
广泛的网络访问：无论在公司、家中还是出差途中，均可通过电脑、手机访问云端存储。
其次是云服务模式，小明用“租房”作比喻：
IaaS（基础设施即服务）：租赁“毛坯房”（如阿里云的ECS服务器+云盘），自行安装操作系统、数据库、应用程序，适合技术实力强的团队（如公司的核心数据库采用IaaS，自行管理更为安全）。
PaaS（平台即服务）：租赁“精装修房”（如阿里云的RDS数据库服务），无需安装数据库，直接使用，适合快速开发项目（如市场部门的临时报告系统采用PaaS，节省时间）。
SaaS（软件即服务）：租赁“拎包入住的房子”（如钉钉、企业微信），直接使用软件，无需关心底层架构，适合非技术团队（如行政部门使用SaaS的OA系统）。
公司最终选择了混合云部署：关键数据（用户支付记录、身份证照片）存储在“私有云”（自建的云环境，确保安全），非关键数据（用户日志、旧视频）则放在“公有云”（如阿里云，费用较低），并通过专用线路连接，实现数据互传。小明计算后发现，这样每年的硬件开支从200万降至80万，节省了60%。
小明的职业发展：从“管理员”到“架构师”
从处理单一机器故障到跨区域灾难备份，从手动管理到云化部署，小明根据公司的需求，深入学习了第9-13章的“业务连续性、备份归档、本地/远程复制、云计算”等知识。这些章节的逻辑非常明确——前八章讲述“如何构建存储”，后五章则聚焦于“如何管理存储”（防止丢失、损坏，能够恢复，降低成本）。
如今，小明面对问题时，例如“如何设计灾难备份方案”“是否采用云服务”，能够迅速联想到相应的技术：核心数据使用同步复制+CDP，非核心数据使用异步复制+公有云；备份策略采用“完全+增量”，归档则使用CAS……这些知识不再是一些孤立的概念，而是成为了解决实际问题的“工具箱”。
在后续复习时，你也可以像小明那样，将知识点与“解决问题的方法”相结合——例如看到“远程复制”就想到“跨区域灾难备份”，看到“重复数据删除”就想到“节约备份空间”，这样记忆既快速又牢固～
京公网安备 11010802022788号
