架构设计内容分享(一百七十)：Apple 如何构建 iCloud 来存储数十亿个数据库

本文链接：https://blog.csdn.net/qq_45038038/article/details/135883162

本文探讨了苹果如何在CloudKit中使用FoundationDB和RecordLayer解决高并发、高延迟查询和冲突事务等问题，强调了异步处理、无状态架构和多租户支持的重要性，以及Cassandra与FoundationDB的比较。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

阅读指南

Cassandra

FoundationDB

为什么要使用 FoundationDB Record Layer

CloudKit 如何使用 FoundationDB 和Record Layer

阅读指南

我发现，论文中以及苹果的实践经验与Meta无服务器平台架构的设计原则和教训高度契合。

1、两者都巧妙地运用了异步处理技术，以实现用户功能的流畅性。Meta在其无服务器架构中，将非面向用户的函数任务利用该技术进行处理，从而避免影响用户体验。而苹果则在Record Layer（在下文将详细解释）的几乎全部功能上采用异步处理方式，目的是隐藏延迟，确保用户感受到的是即时响应。

2、两者都广泛采用无状态架构设计，鉴于它们都有极高的可扩展性需求。（注：无状态架构意味着服务器不保存任何会话或请求之间的持久化状态信息，从而使得每个请求都能独立处理，且可以根据需要轻松地增加或减少服务器实例以应对流量变化。）

3、两者都通过逻辑隔离资源来确保可靠性和可用性。

4、两者都以简化的方式处理各类需求。苹果提到，为存储“小数据”和“大数据”分别配置和运营独立系统是很有诱惑力的做法，但这会增加运维的复杂性。因此，苹果选择用一个抽象层来处理所有类型的数据需求。同样地，Meta在他们的无服务器平台上也采用相同策略，提供了一个统一的抽象层，用于处理各种函数负载。

5、两者都通过构建抽象层来优化开发者体验，让应用开发者无需过多关注可扩展性需求。这些需求由底层分布式系统工程师在更深层次的架构中处理。

6、深知用户需求。无论是Meta还是Apple，它们提供的每一层架构、API设计以及每一个设计决策都是基于对特定技术使用者（无论是应用开发团队还是可观测性团队）清晰理解的基础上制定的。

Cassandra

Cassandra 是一种分布式、宽列式NoSQL数据库管理系统，最初由Facebook开发，用于支持Facebook收件箱搜索功能的实现。有趣的是，后来的Meta自身已逐步用ZippyDB替代了大量原本使用Cassandra的地方。

根据DataStax的信息，iCloud的部分功能由Cassandra提供支持。苹果运营着全球规模最大的Cassandra部署之一。

他们报告指出：

1. 超过30万个实例/节点

2. 数据规模达到数百PB（甚至EB级别）

3. 每个集群处理超过2 PB的数据，且拥有数千个这样的集群

4. 每秒处理数百万次查询

5. 支持数千个应用程序

Cassandra在iCloud中的应用确实彰显了其管理海量数据的能力，达到EB级别。苹果在其服务器上采用多节点Cassandra部署策略，并且团队在设计时非常注重“爆炸半径”（blast radius）控制和数据分片（sharding），以最大程度地减少故障影响范围并优化数据分布与访问性能，从而确保iCloud服务的数据可用性接近100%。

与此同时，苹果公司内部仍在积极改进Cassandra技术。来自苹果公司的Scott Andreas最近发表了关于Cassandra未来发展的演讲。同时，在苹果的招聘页面上，经常可以看到他们为分布式系统工程师岗位列出熟练使用Cassandra的要求。

尽管Cassandra在处理大规模分布式存储方面表现出色，但在苹果iCloud的特定场景下，结合使用CloudKit和Cassandra时遇到了两个关键的可扩展性限制，这导致他们采用了 FoundationDB。

1、在Cassandra单一分区内，即使编辑的是不同的记录，同一时间也只能进行一个操作。这意味着对于那些需要多个用户或设备同时处理共享数据的应用程序来说，可能会出现性能瓶颈和并发控制问题。

2、在Cassandra中，如果需要在一个原子操作内同时更新多个记录，这些更新操作会受限于单个Cassandra分区。每个分区都有其能够处理的最大数据量限制，随着分区内数据的不断增长，Cassandra的性能往往会随之下降。

FoundationDB 和 Record Layer 解决了这两个问题。