读书笔记（SRE：Google运维解密）：第26章数据完整性：读写一致

-数据完整性意味着用户可以维持对云服务的访问，用户对数据的访问能力是最重要的，所以这种访问能力的完整性非常重要。

大多数云计算应用都是优化以下5项的某种组合：在线时间、延迟、规模、创新速度和隐私。
- 在线时间：经常也用“可用率（availability）”指代，代表着某个服务可以被用户使用的时间比率。
- 延迟：服务对用户的响应时间。
- 规模：某个服务的用户数量，以及能够维持正常服务水平的最高负载。
- 创新速度：某个服务能够在合理成本下，为用户提供更好的服务的创新速度。
- 隐私这个名词的定义比较复杂。简单来说，本章将隐私的定义限制为仅仅针对数据删除：用户删掉服务中的数据后，数据必须在合理时间内被真正摧毁。
备份与存档

一般来说，公司会采用某种备份策略来“预防”数据丢失。然而，真正应该被关注的重点其实是数据恢复，这是区分备份与存档的重要区别。就像一句流行语说的那样：没有人真的想要备份数据，他们只想恢复数据。

那么，如何评判你的备份是不是只是一个存档，而不是灾难恢复中的可用的“备份”呢？

备份与存档最重要的区别就是，备份是可以直接被应用程序重新加载的。因此备份和存档的使用场景非常不同。
这段挺有意思，有助于纠正认知

云计算环境的技术难点
- 如果该环境使用了混合交易型和非交易型的备份和恢复方案，那么最终恢复的数据不一定是正确的。
- 如果某个服务必须在不停机的情况下更新，那么不同版本的逻辑可能同时并行操作数据。
- 如果所有其他有交互关系的服务不是同步更新的，那么在更新过程中各服务的不同版本之间可能会有多种组合，那么就更加增大了数据意外丢失和损坏发生的概率。

为了保证扩展性，每个服务提供商都需要提供一定数量的API。这些API必须简单易用，否则就没有人会使用它们。但是同时这些API又必须可靠，以及支持以下特性：

数据本地性和缓存。
本地和全局的数据分布。
强一致性与/或最终一致性。
数据持久性、备份与灾难恢复。

否则的话，复杂应用将没有办法迁移到云上，而简单的应用程序，随着时间推移变得更为复杂，将会由于需要使用不同的、更复杂的API而进行完全重写。

数据完整性指的是在其生命周期中，数据的准确性和一致性。从数据被记录的那一刻开始，一直到数据被访问的时候，数据应该保持正确，不会以某种未预知的方式改变。
备份其实就像纳税一样，是一个服务需要持久付出的代价，来保障其数据的可用性。刷新认知

不应该强调应该纳多少税，而是应该强调这些税会用来提供什么服务：数据可用性的保障。因此，不会强迫团队进行“备份”，而是要求：

各团队需要为不同的失败场景定义一系列数据可用性SLO(服务等级目标)。
各团队需要定期进行演练，以确保他们有能力满足这些SLO。

造成数据丢失的事故类型，从很高的角度来看，可以将事故分类为3个因子的24种组合。

3个因子分别是：

根源问题：
某种无法恢复的用户数据丢失是由以下几个因素造成的：用户行为、管理员的错误、应用程序的Bug、基础设施中的问题、硬件故障和部署区的大型事故。
影响范围
有些数据丢失是大规模的，同时影响很多实体。有些数据丢失是非常有针对性的，仅仅是一小部分用户的数据损坏或者丢失。
发生速度
有些数据丢失是一瞬间造成的（例如，100万条数据在一次操作中被替换成了10条）。而有些数据丢失是缓慢持续进行的（例如，每分钟丢失10条数据，但是持续了一周时间）

最常见的用户可见数据丢失场景是由于数据删除和软件Bug造成的引用完整性问题。其中遇到的最困难场景是，由于包含Bug的版本在更新数周、甚至数月之后才发现在生产环境中造成的数据损坏或者丢失。

维护数据完整性的深度和广度的困难之处
在设计数据完整性保障机制时，必须要认识到复制机制和冗余并不意味着可恢复性。
- 扩展性问题：全量、增量以及相互竞争的备份和恢复机制
- 保留期，是数据备份保存的时间，是另外一个需要考虑的因素

当别人问你“是否有备份”的时候，一个经典的错误回答是“我们有比备份更好的机制—复制机制！”复制机制很重要，包括提高数据的本地性（locality），保护某个部署点单点事故等。但是有很多数据丢失场景是复制机制无法保护的。一个自动同步多个副本的数据存储多半会在你发现问题之前，将损坏的数据记录以及错误的删除动作更新到多个副本上。
为了应对这个问题，会将数据定期导出成其他某种格式，例如将数据库导出成一个本地文件。这种机制可以在一定程度上针对用户错误和应用程序层面的Bug提供保护，但是仍然无法保护更底层的问题。同时，这种机制引入了几种新的危险—数据转换过程中的Bug（双向的），本地文件的存储问题，以及两种格式之间潜在的语义区别。

零日漏洞（zero-day），又叫零时差攻击，是指被发现后立即被恶意利用的安全漏洞

某个对象从软删除到彻底摧毁的过程

第一层：软删除
软删除意味着被删除的数据立刻被标记为已删除，这样除了管理后台代码之外其他代码不可见。管理后台这里可能包括了司法取证场景、账号恢复、企业管理后台、用户支持，以及在线排错等。
第二层：备份和相关的恢复方法
这一层中最重要的理念是：备份不重要；最重要的是恢复。对“恢复”提供支持，应该是主导备份系统设计的关键。

由此可见，在设计备份还原系统时，必须考虑：

使用哪种备份和还原方法。
通过全量或者增量备份建立恢复点（restore point）的频率。
备份的存储位置。
备份的保留时间。
备份应该保存多久呢？

第三层：早期预警

额外一层：复制机制

在理想世界中，每个存储实例，包括那些保存了备份的存储系统都应该具有复制机制。否则，就有可能在数据恢复过程中，才发现备份文件自身丢失了数据，或者发现保存备份文件的那个数据中心正在进行维护。
随着数据量的增长，不是每个存储系统都可以进行复制。在这种情况下，将不同层级的备份存放在不同部署点上是更合理的，这样每个部署点不会同时出现故障。同时，应该将备份文件放置在某种冗余机制之上，例如RAID、Reed-Solomon纠错码，或者GFS类型的复制机制之上。
当选择冗余系统时，不要选择一种不常用的系统。因为这种系统的可靠性只能通过本身就很罕见的数据恢复过程来测试。正确的做法是，选择一个非常常见，并且被许多用户持续使用的系统。