为什么企业选择云主机时，容易忽视底层存储架构？

拿到一份云主机的配置单，大多数人的目光会先落在几个数字上：CPU几核，内存多大，带宽多少，磁盘多少G。存储这一项，往往只确认容量够不够，就翻过去了。至于数据在底层是怎么处理的、怎么保存的，出了故障又怎么找回来，很少有人追问。

这背后有个朴素的想法：磁盘不就是放东西的地方吗，够大就行。可云主机的计算资源，决定的是应用能处理多少事情；数据存储架构，则关系到业务数据怎么写入、怎么读取、怎么保存，坏了又怎么恢复。前者影响业务跑得快不快，后者影响业务出了事还能不能继续。

只看容量，容易有几处想当然。容量够用，不代表读写性能够用。一个数据库放在很大的磁盘上，一到业务高峰查询还是慢，原因往往是同时涌来的读写请求超出了存储的处理能力，和剩下多少空间没有关系。数据能正常写进去，也不代表就有了完善的备份，写入成功只能说明这一份数据在，被误删或者损坏之后还能不能找回来，是另一回事。

另一组想当然，出在对“保护”二字的理解上。存储设备做了冗余，听起来很安全，但冗余防的主要是硬件故障。要是有人手滑删掉了一张表，冗余会很忠实地把这个“删除”也同步到各个副本，所以它代替不了企业独立的备份。同样，平台提供了数据保护能力，也不等于企业可以不做自己的灾备规划，两者负责的范围并不一样。后面会详细说。

云主机底层存储架构，主要涉及哪些技术环节？

不同服务商的具体实现各不相同，这里按最常见的逻辑，把存储拆成三个环节来讲：缓存、持久化存储和备份。

数据缓存层：提高高频数据访问效率

缓存的作用，是把经常被访问的数据放在读取更快的位置，下次再要的时候直接从这里拿，不用每次都去更慢的存储里找。业务里总有一部分“热点”数据，比如首页的商品信息、热门文章、当前在线用户的会话，会被反复读取。热点越集中，重复读取越多，缓存的收益就越明显。衡量它常用的一个指标是缓存命中率，也就是请求中有多大比例直接从缓存里拿到了数据。

需要说明的是，缓存解决的是访问效率的问题，并不是用来长期保存数据的。里面的数据可能被淘汰，也可能被刷新，不能因为缓存里有一份，就当成数据已经存好了。

持久化存储层：承担业务数据的保存与读取

持久化存储，指的是数据写下去之后，即便断电、重启，依然完整地留在那里。这一层是业务数据真正的“家”。

不同类型的数据对它的要求并不一样。数据库文件对随机读写的性能和一致性要求很高，一次写入没有落实好，就可能造成数据损坏；应用文件，比如程序和配置，读得多写得少，更看重稳定；业务记录，比如订单和交易，最看重的是不能丢、不能错。所以评估这一层，不能只问容量多大，还要问自己的数据属于哪一类，需要什么样的读写表现和可靠程度。

数据备份层：为异常情况下的数据恢复提供依据

备份和正常的数据存储，是两件不同的事。正常存储保证的是“现在的数据可以读写”，备份保证的是“出了问题之后，可以回到某一个时间点”。备份是一份独立的、带有时间点的副本，而不是同一份数据换了个位置。

备份主要有两种方式。全量备份是把所有数据完整复制一遍，恢复时最直接，但占用的空间大，耗时也长。增量备份只记录上次备份之后发生变化的部分，更省空间和时间，不过恢复的时候，需要把全量备份和后面各次增量依次叠加起来。备份周期怎么定，要看数据变化得快不快，以及能接受多大的损失。最后还有一点常被忽略：备份做出来了，不等于能用。只有定期做恢复验证，才知道这份备份是不是完整可用。

高可靠存储架构，能够为企业业务带来哪些价值？

减少单一存储环节异常造成的数据风险

如果数据只有一份，只放在一个设备上，这个设备一出问题，数据就跟着出问题。冗余机制和数据副本的意义，在于把同一份数据保存在多个位置，其中一处发生故障时，其他位置还能继续提供数据。故障隔离则是让某个环节的异常，不至于蔓延到其他环节。这些设计不能让故障消失，但能让一次局部故障不至于演变成一次数据事故。

通过分层处理满足不同数据的访问需求

企业的数据，价值和访问频率并不相同。高频数据，比如正在被大量访问的热点内容，要求读取快；普通的业务数据，需要稳定读写；历史数据，比如几年前的订单和日志，很少被访问，但需要保存好。如果全部用同一种方式存放，要么成本太高，要么速度太慢。分层处理的思路，就是让不同的数据待在最适合它的层次里。

改善数据读取效率，支撑持续业务访问

存储性能会直接传导到上层的应用。数据库查询的速度，取决于从磁盘读取数据的速度；网站打开得快不快，取决于页面所需的数据能多快取出来；后台任务要跑多久，也取决于读写数据的效率。存储一旦成了瓶颈，哪怕CPU和内存都很充裕，应用也快不起来。

建立更加完整的数据保护机制

从业务连续性的角度看，完整的数据保护有三个环节：数据备份，保证有可以回退的副本；数据恢复，保证出了问题能把数据取回来；在此基础上，让业务在异常之后能继续运转。三者缺了一环，保护就不完整。比如只有备份，却从来没人验证过怎么恢复，真到需要的时候，才发现恢复要花很长时间，业务停摆的时间也就跟着拉长了。

企业选择云存储，应该重点理解哪些技术指标？

IOPS：每秒能够处理多少次输入输出操作

IOPS指存储每秒能处理多少次输入输出操作。数据库业务里有大量小块数据的随机读写，比如按条件查几条记录，每一次都是一次独立的读写，所以对IOPS特别敏感。IOPS不够的时候，请求会排队，表现出来就是响应变慢，而这时磁盘容量可能还剩很多。

吞吐量：单位时间内能够传输多少数据

吞吐量指单位时间内能传输多少数据，通常用MB/s表示。它和IOPS有关联，大致上，吞吐量约等于IOPS乘以每次读写的数据块大小。大文件传输、日志批量写入、数据导出和报表批处理这类业务，每次处理的数据量大，更看重吞吐量，对IOPS反而没那么敏感。

访问延迟：数据请求需要多长时间得到响应

延迟，是一次数据请求发出之后，要等多久才得到响应。同样是每秒处理很多次操作，延迟低的存储，每一次响应都更快。对数据库来说，一次页面请求背后可能有几十次查询，每次查询的存储延迟累加起来，会明显影响最终的应用响应速度。

数据持久性：数据长期保存的可靠程度

持久性说的是数据长期保存之后，依然完整可用的可靠程度。冗余让数据有了多份副本，校验机制能发现数据在存储过程中有没有出现损坏，存储保护机制则在出现问题时负责修复。需要注意，不同服务商对持久性的表述和统计口径并不相同，看到一个数值的时候，要先弄清楚它指的是什么范围、怎么计算出来的。

恢复能力：出现问题后能否恢复到可用状态

恢复能力问的是，出了问题之后，能不能恢复到可用的状态。这里要引入两个概念。

RPO，是可接受的数据丢失时间窗口。如果每天凌晨做一次备份，最坏的情况下，会丢失从上次备份到出事之间将近一天的数据，RPO也就大约是一天。RTO，是业务恢复时间目标，指从出事到业务恢复正常，最多能接受多长时间。

这两个数字没有统一的标准答案。一个内部资料库，丢一天数据、停半天也许还能接受；一个电商的订单系统，RPO和RTO都要小得多。企业需要先根据自己的业务确定目标，再去选择与之匹配的备份和恢复方案。

云主机存储保护与企业独立备份，为什么不能相互替代？

这是存储话题里最容易被误解的一点。把常见的几种保护手段，和它们各自能做什么、做不到什么放在一起，会看得比较清楚。

这张表想说明的是，每一种手段防的是一类风险，没有哪一种能包打天下。尤其是存储架构里的数据同步功能，目的是让多份数据保持一致，它可以提高可用性，却不能直接当成完整的灾难恢复体系，因为连错误它也会一起同步。企业应该根据数据的重要程度建立多层的保护方案，数据越重要，叠加的层次就越多。

恒讯科技云主机三层存储技术有哪些值得关注的特点？

恒讯科技采用缓存、沉淀和备份三层存储设计，不同层级分别承担数据处理、缓存以及灾备相关的工作，层与层之间进行数据同步。对照前面讲的几个环节，可以从四个角度来看。

缓存层。帮助处理高频访问的数据，对应前面说的热点数据读取，目的是提高访问效率。

沉淀层。承担持久化存储相关的任务，业务数据最终保存在这一层。

备份层。为数据保护提供支持，对应的是出现异常时用来恢复数据的依据。

层级之间的协同。三层并不是各自孤立的，层间的数据同步把它们连在了一起，数据处理和数据保护是放在同一套设计里考虑的。具体的同步方式和时效，以产品说明为准。

官网还展示了高可用性和数据安全性方面的指标。看这类指标，需要先弄清它的具体定义、统计范围，以及和服务协议的口径是不是一致。它反映的是产品的设计目标和服务承诺，并不能直接推导出任何业务情况下数据都不会丢失，企业自己的备份依然要做。

云数据库与云主机存储，如何根据业务需求进行组合？

数据库是对存储要求最高的一类应用，所以不少企业会把它从云主机里单独拿出来，使用专门的云数据库服务。恒讯科技的云数据库MySQL就是这样一个独立的产品，官网产品页介绍了自动全量备份、7天备份保留、备份数据恢复、数据库运行监控和只读实例等功能。需要明确的是，这些是云数据库MySQL这款产品自己的功能，并不是所有云主机默认具备的，两者不能混为一谈。

把网站数据库和应用程序分开，首先是各自可以按需要配置资源：程序主要消耗CPU，数据库更依赖内存和存储。其次，数据库出问题的时候，不至于连累应用服务器，反过来也一样。

数据库的读写负载增加之后，资源管理就变得重要起来。读请求多的业务，可以考虑用只读实例分担查询的压力，写入则集中在主库上；同时通过运行监控，留意连接数、慢查询和资源使用情况，尽早发现问题。

历史数据和业务文件，需要单独规划。几年前的订单记录和日志，很少被访问，数据量却很大，不必都留在数据库里占资源。用户上传的图片、文档之类的业务文件，也更适合放在专门的存储位置，而不是和数据库混放在一起。

数据库备份和云主机备份，职责也不同。数据库备份保护的是库里的数据，可以恢复到某个备份时间点；云主机备份保护的是整台实例的系统和文件。两者各有各的恢复对象，不能互相顶替。

最后，根据业务需求把云主机、云数据库和其他存储服务组合起来：应用放在云主机上，数据库交给云数据库，文件和归档放进合适的存储里，各部分按自己的特点配置，再各自制定备份方案。

企业正式使用云主机之前，应该制定怎样的数据保护计划？

正式使用之前，建议先把数据保护计划写下来，哪怕只有一页纸。可以按下面的顺序来。

1. 数据分类与重要程度划分。先弄清楚都有哪些数据，哪些是核心的，哪些丢了影响不大。

2. 备份周期及备份保留时间。按数据变化的快慢决定多久备份一次，每一份备份保留多久。

3. 关键业务数据的恢复目标。给核心业务定下RPO和RTO，作为后面方案的依据。

4. 异地备份与权限隔离。重要数据的备份放在不同的地点，备份的访问权限也要和日常使用的账号分开，避免一个账号失陷，所有数据一起受影响。

5. 恢复演练和数据完整性检查。定期真的恢复一次，并检查恢复出来的数据是否完整。

6. 数据导出与业务迁出机制。将来更换服务商或者终止业务时，数据怎么完整导出。

企业长期积累下来的数据，往往是最难再生的资产，设备坏了可以换，数据丢了不一定找得回来。所以选择云主机，不能只看磁盘容量和价格，更应当了解它底层的存储架构、数据备份方式和恢复能力。如果企业的业务涉及数据库或者大量的业务数据，可以带着自己的数据类型和恢复目标，向恒讯科技咨询存储方案。