复制功能概览
借助适用于 Bigtable 的复制功能，您可以将数据复制到多个区域或同一区域内的多个地区，从而提高数据的可用性和耐用性。此外，它还可将不同类型的请求路由到不同的集群，让您可以隔离工作负载。
本页面介绍了 Bigtable 复制功能的工作原理以及复制功能的一些常见使用场景。此外还介绍了 Bigtable 在启用复制功能的情况下采用的一致性模型，以及当一个集群故障切换到另一集群时所发生的情况。
- 有关可用以实现常见使用场景的设置示例，请参阅复制功能设置示例。
- 如需了解如何创建使用复制功能的实例，请参阅创建实例。
- 如需了解如何为现有实例启用复制功能，请参阅添加集群。
- 要了解与复制相关的成本，请参阅价格。
在阅读本页内容之前，您应先熟悉 Bigtable 概览。
复制功能的工作原理
如需在 Bigtable 实例中使用复制功能，请新建一个包含多个集群的实例，或向现有实例添加集群。
Bigtable 实例的集群最多可以位于 8 个 Bigtable 区域中，并且在这 8 个区域中，该实例在每个可用区中只能包含一个集群。例如，如果您在 8 个区域中创建实例，每个区域包含 3 个可用区，则您的实例最多可以包含 24 个集群。
一个区域中的每个可用区只能包含一个集群。 通过将集群划分到不同的可用区或区域中，即使某个 Google Cloud 可用区或区域变得不可用，您也可以访问实例的数据。
在您创建包含多个集群的实例时，Bigtable 会立即开始在各集群之间同步数据，从而在有实例集群的每个可用区中分别创建一个独立的数据副本。同样，在您向现有实例添加新集群时，Bigtable 会将现有数据从原始集群的可用区复制到新集群的可用区，然后在两个可用区之间同步对数据所进行的更改。
Bigtable 会复制对数据进行的所有更改，包括以下所有类型的更改：
- 对现有表中数据的更新
- 新增和删除表
- 添加和移除列族
- 对列族的垃圾回收政策的更改
请务必注意，复制会有一些延迟，并且副本之间的一致性是最终的。请务必注意，复制会有一些延迟，集群之间的一致性是最终的。
Bigtable 会将实例中的每个集群视为一个主集群，因此您可以在每个集群中执行读写操作。您还可以对实例进行设置，以便将来自不同类型应用的请求路由到不同的集群。
在将集群添加到实例之前，您应该先了解更改复制表的垃圾回收政策时所适用的限制。
性能
使用复制功能会产生性能影响，当您创建复制的实例或通过向单集群实例添加集群来启用复制功能时，应酌情考虑这些性能影响。例如，相较于位于同一区域的复制集群，位于不同区域的复制集群的复制延迟时间通常更长。此外，拥有多个集群的实例中的集群通常需要更多节点来处理额外的复制处理工作。如需了解详情，请参阅了解性能。
使用场景
本部分介绍了 Bigtable 复制功能的一些常见使用场景。要了解每个使用场景的最佳配置设置以及关于其他使用场景的实现提示，请参阅复制功能设置示例。
隔离生产应用与批量读取
如果您使用同一个集群运行一个执行大量大型读取操作的批量分析作业和一个执行混合读写操作的应用，那么大型批量作业会拖慢该应用的用户体验到的速度。通过复制，您可以通过设置单集群路由的应用配置文件，将批量分析作业流量和应用流量路由到不同的集群，确保批量作业不会影响到应用的用户。 详细了解如何实现此使用场景。
提高可用性
如果实例只有 1 个集群，那么您的数据的耐用性和可用性将受限于该集群所在的可用区。复制功能可在多个可用区或区域中分别为您的数据存储一份副本，并可在需要时自动在多个集群之间进行故障转移，从而提高了数据的耐用性和可用性。 详细了解如何实现此使用场景。
提供近乎实时的备份
在某些情况下（例如，您不能冒所读取的数据过时的风险），您始终需要将请求路由至一个集群。但是，您仍然可以使用复制功能，即使用一个集群处理请求，而保留另一个集群作为近乎实时的备份。如果生产集群不可用，您可以手动故障转移至备份集群，从而最大程度地减少停机时间。 详细了解如何实现此使用场景。
确保数据全球化
您可以在世界各地设置复制功能，以使数据更靠近您的客户。 例如，您可以在美国、欧洲和亚洲创建包含复制集群的实例，并设置应用配置文件以将应用流量路由到最近的集群。 详细了解如何实现此使用场景。
一致性模型
默认情况下，Bigtable 的复制功能提供最终一致性。该术语表示当向一个集群写入某项更改时，您最终将能够从该实例的其他集群中读取这项更改，但前提是 Cloud Bigtable 已在这些集群之间复制完此更改。
如果您的实例响应速度快，Bigtable 的复制延迟时间通常只是几秒或几分钟（而不是几小时）。但是，如果您向集群写入了大量数据，或者集群已过载或暂时不可用，那么 Cloud Bigtable 可能需要一些时间才能开始复制。此外，如果集群相距较远，复制可能需要更长时间。因此，通常情况下，您不能想当然地认为自己读取的始终是最新写入的值，或者在写入操作完成后等待几秒钟就足以让 Bigtable 复制完更改。
如果您需要不同的一致性保证，则在启用复制功能的情况下，Bigtable 还可以提供读己所写 (read-your-writes) 一致性，这种一致性可确保应用永远不会读取早于最近写入内容的数据。若要在一组应用中实现读己所写一致性，其中的每个应用都必须使用针对单集群路由配置的应用配置文件，并且所有应用配置文件都必须将请求路由至同一集群。您可以同时将实例的其他集群用于其他目的。
对于某些复制用例而言，Bigtable 还可以提供强一致性，这会确保所有应用在同一状态下看到您的数据。为获得强一致性，您可以使用单集群路由应用配置文件配置实现上文所述的读己所写一致性，但您不得使用实例的其他集群，除非您需要故障到其他集群。查看复制设置的示例，看看您的用例是否可以实现这一点。
冲突解决
Bigtable 表中的每个单元格值都通过四元组（行键、列族、列限定符、时间戳）进行唯一标识。如需详细了解这些标识符，请参阅 Bigtable 存储模型。在极少数情况下，当将两个具有完全相同的四元组的写入发送到两个不同的集群时，Bigtable 会基于服务器端时间使用内部“最后写入内容生效”算法自动解决冲突。Bigtable“最后写入内容生效”实现具有确定性，当副本完成同步后，所有集群都具有四元组的相同值。
应用配置文件
如果实例使用了复制功能，您可以使用应用配置文件来指定路由政策。应用配置文件还决定着您是否可以执行单行事务（涉及读取-修改-写入 (read-modify-write) 操作（包括递增和附加））以及检查并更改 (check-and-mutate) 操作（也称为条件更改或条件写入）。
如需了解详情，请参阅应用配置文件。 有关可用以实现常见使用场景的设置示例，请参阅复制功能设置示例。
路由政策
每个应用配置文件都有一个路由政策，用于控制哪些集群处理来自应用的传入请求。路由政策的选项包括：
- 单集群路由：将所有请求发送到您指定的单个集群。
- 多集群路由到任何集群：将请求发送到实例中最近的可用集群。
- 集群组路由：将请求发送到您在应用配置文件设置中指定的集群组内最近的可用集群。
故障切换
如果 Bigtable 集群无响应，则复制功能可将传入流量故障切换到同一实例中的其他集群。故障切换可以手动或自动执行，具体取决于应用使用的应用配置文件以及该应用配置文件的配置方式。
如需了解详情，请参阅故障切换。
在启用复制功能的情况下丢弃一定范围的行
借助 Cloud Bigtable Admin API，您可以根据行键从表中丢弃连续范围的行。在不使用复制功能的实例中，Bigtable 可以快速而高效地丢弃一定范围的行。但在启用了复制功能的情况下，Cloud Bigtable 在丢弃一定范围的行时速度会显著变慢，而且效率也会大大降低。