Kafka权威指南 读书笔记之（八）跨集群数据镜像
不同的集群之间相互依赖，管理员需要不停地在集群间复制数据。大部分数据库都支持复制 （ replication ），也就是持续地在数据库服务器之间复制数据 。 因
为前面已经使用过“复制”这个词来描述在同一个集群的节点间移动数据，所以我们把集群间的数据复制叫作镜像 （ mirroring ）。 Kafka 内置的跨集群复制工具叫作 MirrorMaker。
我们将讨论跨集群的数据镜像，它们既可以镜像所有数据，也可以镜像部分数据；
然后介绍这些场景所使用的架构模式，以及这些架构模式各自的优缺点 ；
接下来会介绍 MirrorMaker 以及如何使用它， 部署和性能调优时要注意的一些事项；
最后对 MirrorMaker 的一些替代方案进行比较 。
跨集群镜像的使用场景
区域集群和中心集群
有多个数据中心，它们分布在不同的地理区域。这些数据中心都有自己的 Kafka 集群。有些应用程序只需要与本地的 Kafka 集群通信，
而有些则需要访问多个数据中心的数据（否则就没必要考虑跨数据中心的复制方案了）。一个典型的场景。该公司在每个城市都有一个数据中心，它们收集所在城市的供需信息，
并调整商品价格。这些信息将会被镜像到一个中心集群上，业务分析员就可以在上面生成整个公司的收益报告。
冗余（ DR)
一个 Kafka 集群足以支撑所有的应用程序，不过你可能会担心集群因某些原因变得不可用，所以你希望有第二个 Kafka 集群，它与第一个集群有相同的数据，如果发生了紧急
情况，可以将应用程序重定向到第二个集群上。
云迁移
有很多公司将它们的业务同时部署在本地数据中心和云端。为了实现冗余，应用程序通常会运行在云供应商的多个服务区域里，或者使用多个云服务。本地和每个云
服务区域都会有－个 Kafka 集群。本地数据中心和云服务区域里的应用程序使用自己的Kafka 集群，当然也会在数据中心之间传输数据。例如，如果云端部署了一个新的应用
程序，它需要访问本地的数据。本地的应用程序负责更新数据，并把它们保存在本地的数据库里。我们可以使用 Connect 捕获这些数据库变更，并把它们保存到本地的 Kafka
集群里，然后再镜像到云端的 Kafka 集群上。这样有助于控制跨数据中心的流量成本，同时也有助于改进流量的监管和安全性。
多集群架构
以下是在进行跨数据中心通信时需要考虑的一些问题。
高延迟
Kafka 集群之间的通信延迟随着集群间距离的增长而增加。虽然光缆的速度是恒定的，但集群间的网络跳转所带来的缓冲和堵塞会增加通信延迟。
有限的带宽
单个数据中心的广域网带宽远比我们想象的要低得多，而且可用的带宽时刻在发生变化。另外，高延迟让如何利用这些带宽变得更加困难。
高成本
不管你是在本地还是在云端运行 Kafka，集群之间的通信需要更高的成本。部分原因是因为带宽有限，而增加带宽是很昂贵的。
Kafka 服务器和客户端是按照单个数据中心进行设计、开发、测试和调优的。假设服务器和客户端之间具有很低的延迟和很高的带宽，在使用默认的超时时间和缓冲区大小时
也是基于这个前提。因此，不建议跨多个数据中心安装 Kafka 服务器。
大多数情况下，要避免向远程的数据中心生成数据，但如果这么做了，那么就要忍受高延迟 ，并且需要通过增加重试次数（ Linkedln 曾经为跨集群镜像设置了 32 000 多次重试
次数）和增大缓冲区来解决潜在的网络分区问题（生产者和服务器之间临时断开连接 ）。
如果有了跨集群复制的需求，同时又禁用了从 broker 到 broker 之间的通信以及从生产者到broker 之间的通信，必须允许从 broker 到消费者之间的通信。
事实上，这是最安全的跨集群通信方式。在发生网络分区时，消费者无需从 Kafka 读取数据，数据会驻留在Kafka 里 ， 直到通信恢复正常。因 此，网 络分区不会造成任何数据丢失。
因为带宽有限，如果一个数据中心的多个应用程序需要从另一个数据中心的 Kafka 服务器上读取数据，倾向于为每一个数据中心安装一个 Kafka 集群，并在这些集群间复制数据，而不
是让不同的应用程序通过广域网访问数据。
一些架构原则 ：
• 每个数据中心至少需要一个集群。
• 每两个数据中心之间的数据复制要做到每个事件仅复制一次（除非出现错误需要重试） 。
• 尽量从远程数据中心读取数据 ，而不是向远程数据中心写入数据。
Hub和 Spoke架构
这种架构适用于一个中心 Kafka 集群对应多个本地 Kafka 集群的情况，如 图 所示。
这种架构有一个简单的变种，如果只有一个本地集群： 一个首领和一个跟随者，如图 所示。
使用这种架构，它们无法访问到全局的数据集。这种架构的好处在于 ，数据只会在本地的数据中心生成，而且每个数据中心的数据只会被镜像到中央数据中心一次 。
只处理单个数据中心数据的应用程序可以被部署在本地数据中心里， 而需要处理多个数据中心数据的应用程序则需要被部署在中央数据中 心里。
因为数据复制是单向的，而且消费者总是从同一个集群读取数据，所以这种架构易于部署、配置和监控。
这种架构的简单性也导致了一些不足。一个数据中心的应用程序无法访问另一个数据中心的数据 。 一家银行在不同的城市有多家分行。每个城市的 Kafka 集群上保存了用户的信息和账号历史数据。
把各个城市的数据复制到一个中心集群上 ， 这样银行就可以利用这些数据进行业务分析。 在用户访问银行网站或去他们所属的分行办理业务时，他们的请求被路由到本地集群上，
同时从本地集群读取数据。假设一个用户去另一个城市的分行办理业务 ，因为他的信息不在这个城市，所以这个分行需要与远程的集群发生交互（不建议这么做），
否则根本没有办法访问到这个用户的信息（很尴尬） 。 因此，这种架构模式在数据访问方面有所局限，因为区域数据中心之间的数据是完全独立的。
采用这种架构时，每个区域数据中心的数据都要被镜像到中央数据中心上。镜像进程会读取每一个区域数据中心的数据，并将它们重新生成到 中心集群上。 如果多个数据中心
出现了重名的主题，那么这些主题的数据可以被写到中心集群的单个主题上 ，也可以被写到多个主题上 。
双活架构
当有两个或多个数据中心需要共享数据并且每个数据中心都可以生产和读取数据时 ， 可以使用双活（ Active-Active ）架构，如图 所示 。
这种架构的主要好处在于，它可以为就近的用户提供服务，具有性能上的优势，而且不会因为数据的可用性问题（在 Hub 和 Spoke 架构中就有这种问题）在功能方面作出牺牲。第
二个好处是冗余和弹性。因为每个数据中心具备完整的功能， 一旦一个数据中心发生失效，就可以把用户重定向到另一个数据中心。这种重定向完全是网络的重定向，因此是一
种最简单、最透明的失效备援方案。
这种架构的主要问题在于，如何在进行多个位置的数据异步读取和异步更新时避免冲突。比如镜像技术方面的问题一一如何确保同一个数据不会被无止境地来回镜像？而数据一致
性方面的问题则更为关键。下面是可能遇到的问题。
• 如果用户向一个数据中心发送数据，同时从第二个数据中心读取数据，那么在用户读取数据之前，他发送的数据有可能还没有被镜像到第二个数据中心。对于用户来说， 这就
好比把一本书加入到购物车，但是在他点开购物车时，书却不在里面。因此，在使用这种架构时，开发人员经常会将用户“粘”在同一个数据中心上，以确保用户在大多数情
况下使用的是同一个数据中心的数据（除非他们从远程进行连接或者数据中心不可用） 。
• 一个用户在一个数据中心订购了书 A ，而第二个数据中心几乎在同一时间收到了该用户订购书 B 的订单，在经过数据镜像之后，每个数据中心都包含了这两个事件。两个
数据中心的应用程序需要知道如何处理这种情况。我们是否应该从中挑选一个作为“正确”的事件？如果是这样，我们需要在两个数据中心之间定义一致的规则，用于确定
哪个事件才是正确的。又或者把两个都看成是正确的事件，将两本书都发给用 户，然后设立一个部门专门来处理退货问题？ Amazon 就是使用这种方式来处理冲突的，但
对于股票交易部门来说，这种方案是行不通的。如何最小化冲突以及如何处理冲突要视具体情况而定。总之要记住，如果使用了这种架构，必然会遇到冲突问题，还要想
办注解决它们。
如果能够很好地处理在从多个位置异步读取数据和异步更新数据时发生的冲突问题，那么我们强烈建议使用这种架构。这种架构是我们所知道的最具伸缩性、弹性、灵活性和成本
优势的解决方案。所以，它值得我们投入精力去寻找一些办法，用于避免循环复制、把相同用户的请求粘在同一个数据中心，以及在发生冲突时解决冲突。
双活镜像（特别是当数据中心的数量超过两个）的挑战之处在于，每两个数据中心之间都需要进行镜像，而且是双向 的。如果有 5 个数据中心 ，那么就需要维护至少 20 个镜像进
程，还有可能达到 40 个，因为为了高可用，每个进程都需要冗余 。
另外，我们还要避免循环镜像，相同的事件不能无止境地来回镜像。对于每一个“逻辑主题”，我们可以在每个数据中心里为它创建一个单独的主题，并确保不要从远程数据中
心复制同名的主题。例如，对于逻辑主题“users”，我们在一个数据中心为其创建“SF.users”主题，在另 一 个数据中心为其创建“ NYC.users”主题。镜像进程将 SF 的“ SF.
users”镜像到 NYC ，同时将 NYC 的＂ NYC.users”镜像到 SF。这样一来，每一个事件只会被镜像一次，不过在经过镜像之后，每个数据中心同时拥有了 SF.users 和 NYC.users 这
两个主题，也就是说，每个数据中心都拥有相同的用户数据。消费者如果要读取所有的用户数据，就需要以“＊ .users”的方式订阅主题。我们也可以把这种方式理解为数据中心的
命名空间，比如在这个例子里， NYC 和 SF 就是命名空间 。
在不久的将来， Kafka 将会增加记录头部信息。头部信息里可以包含源数据中心的信息，我们可以使用这些信息来避免循环镜像，也可以用它们来单独处理来自不同数据中心的数
据。当然，你也可以通过使用结构化的数据格式（比如 Avro ）来实现这一特性，并用它在数据里添加标签和头部信息 。 不过在进行镜像时，需要做一些额外的工作，因为现成的镜
像工具并不支持自定义的头部信息格式。
主备架构
有时候，使用多个集群只是为了达到灾备的目的。你可能在同一个数据中心安装了两个集群 ，它们包含相同的数据，平常只使用其中的一个。主备（ Active-Standby ）架构示
意图如图 所示。
这种架构的好处是易于实现，而且可以被用于任何一种场景。你可以安装第二个集群，然后使用镜像进程将第一个集群的数据完整镜像到第二个集群上，不需要担心数据的访问和
冲突问题，也不需要担心它会带来像其他架构那样的复杂性。
这种架构的不足在于，它浪费了一个集群。 Kafka 集群间的失效备援比我们想象的要难得多。 从目前的情况来看，要实现不丢失数据或无重复数据的 Kafka 集群失效备援是不可能
的。我们只能尽量减少这些问题的发生，但无法完全避免。
让一个集群什么事也不做，只是等待灾难的发生，这明显就是对资源的浪费。有些组织尝试减小灾备集群的规模，让它远小于生产环境的集群规模。
这种做法具有一定的风险，因为无法保证这种小规模的集群能够在紧急情况下发挥应有的作用 。有些组织则倾向于让灾备集群在平常也能发挥作用，他们把一些只读的工作负载定向到灾备集群上，
也就是说，实际上运行的是 Hub 和 Spoke 架构的一个简化版本，因为架构里只有一个 Spoke。那么问题来了 ： 如何实现 Kafka 集群的失效备援？
不管选择哪一种失效备援方案， SRE（网站可靠性工程）团队都必须随时待命。每季度进行一次失效备援是最低限度的要求， 一个高效的 SRE 团队会更频繁地进行失效备援。
1. 数据丢失和不一致性
Kafka 的各种镜像解决方案都是异步的，所以灾备集群总是无法及时地获取主集群的最新数据。我们要时刻注意灾备集群与主集群之间
拉开了多少距离，并保证不要出现太大的差距。一个繁忙的系统可以允许灾备集群与主集群之间有几百个甚至几千个消息的延迟。
在进行计划内的失效备援时，可以先停止主集群，等待镜像进程将剩余的数据镜像完毕，然后切换到灾备集群，这样可以避免数据丢失。在发生非计划内的失效备援时，可能会
丢失数千个消息。目前 Kafka 还不支持事务， 也就是说，如果多个主题的数据（比如销售数据和产品数据）之间有相关性，那么在失效备援过程中， 一些数据可以及时到达灾
备集群，而有些则不能。那么在切换到灾备集群之后，应用程序需要知道该如何处理没有相关销售信息的产品数据。
2. 失效备援之后的起始偏移量
在切换到灾备集群的过程中，最具挑战性的事情莫过于如何让应用程序知道该从什么地方开始继续处理数据。下面将介绍一些常用的方法，其中有些很简单，但有可能会造成
额外的数据丢失或数据重复：有些则比较复杂，但可以最小化丢失数据和出现重复数据的可能性。
偏移量自动重置
Kafka 消费者有一个配置选项，用于指定在没有上一个提交偏移量的情况下该作何处理。消费者要么从分区的起始位置开始读取数据，要么从分区的末尾开始读取数据。
如果重复处理数据或者丢失一些数据不会造成太大问题 ，那么重置偏移量是最为简单的方案。不过直接从主题的末尾开始读取数据这种方式或许更为常见 。
复制偏移量主题
如果使用新的 Kafka 消费者（ 0.9 或以上版本），消费者会把偏移量提交到一个 叫 作__consumer_offsets 的主题上。如果对这个主题进行了镜像，那么当消费者开始读
取灾备集群的数据时，它们就可以从原先的偏移量位置开始处理数据。这个看起来很简单，不过仍然有很多需要注意的事项。
首先， 我们并不能保证主集群里的偏移量与灾备集群里的偏移量是完全匹配的。假设主集群里的数据只保留 3 天，而你在一个星期之后才开始镜像，那么在这种情况下，主集群里
第一个可用的偏移量可能是 57 000 000 （前 4 天的旧数据已经被删除了），而灾备集群里的第一个偏移量是 0，那么当消费者尝试从 57 000 003 处（因为这是它要读取的下一个数据）
开始读取数据时，就会失败。
其次，就算在主题创建之后立即开始镜像，让主集群和灾备集群的主题偏移量都从 0 开始，生产者在后续进行重试时仍然会造成偏移量的偏离。简而言之，目前的 Kafka 镜像解
决方案无法为主集群和灾备集群保留偏移量。
最后，就算偏移量被完美地保留下来，因为主集群和灾备集群之间的延迟以及 Kafka 缺乏对事务的支持，消费者提交的偏移量有可能会在记录之前或者记录之后到达。在发生失效
备援之后，消费者可能会发现偏移量与记录不匹配，或者灾备集群里最新的偏移量比主集群里的最新偏移量小。如图 所示。
在这些情况下，我们需要接受一定程度的重复数据。如果灾备集群最新的偏移量比主集群的最新偏移量小，或者因为生产者进行重试导致灾备集群的记录偏移量比主集群的记录偏
移量大，都会造成数据重复。你还需要知道该怎么处理最新偏移量与记录不匹配的问题，
此时要从主题的起始位置开始读取还是从末尾开始读取？
复制偏移量主题的方式可以用于减少数据重复或数据丢失，而且实现起来很简单，只要及时地从 0 开始镜像数据，并持续地镜像偏移量主题就可以了 。不过一定要注意上述的
几个问题。
基于时间的失效备援
如果使用的是新版本（ 0.10.0 及以上版本）的 Kafka 消费者， 每个消息里都包含了一个时间戳，这个时间戳指明了消息发送给 Kafka 的时间。 在更新版本的 Kafka (0.10.1.0
及以上版本）里， broker 提供了一个索引和一个 API ，用于根据时间戳查找偏移量。于是，假设你正在进行失效备援 ， 并且知道失效事件发生在凌晨 4:05 ，那么就可以让消费
者从 4:03 的位置开始处理数据。在两分钟的时间差里会存在一些重复数据，不过这种方式仍然比其他方案要好得多，而且也很容易向其他人解释一一 “我们将从凌晨 4:03
的位置开始处理数据”这样的解释要比“我们从一个不知道是不是最新的位置开始处理数据”要好得多 。 所以，这是一种更好的折中 。问题是，如何让消费者从凌晨 4:03 的
位置开始处理数据呢？
可以让应用程序来完成这件事情。 我们为用户提供一个配置参数 ，用于指定从什么时间点开始处理数据。如果用户指定了时间，应用程序可以通过新的 API 获取指定时间的
偏移量，然后从这个位置开始处理数据。如果应用程序在一开始就是这么设计的，那么使用这种方案就再好不过了。但如果应用程序在一开始不是这么设计的呢？开发一个这样的小工具也并不难一一接收一个时间
戳，使用新的 API 获取相应的偏移量，然后提交偏移量。 我们希望在未来的 Kafka 版本里添加这样的工具，不过你也可以自己写一个。在运行这个工具时，应该先关闭消费者
群组 ， 在工具完成任务之后再启动它们。该方案适用于那些使用了新版 Kafka、对失效备援有明确要求并且喜欢自己开发工具的人 。
偏移量外部映射
镜像偏移量主题的一个最大问题在于主集群和灾备集群的偏移量会发生偏差。因此， 一些组织选择使用外部数据存储（比如 Apache Cassandra ） 来保存集群之间
的偏移量映射。他们自己开发镜像工具，在一个数据被镜像到灾备集群之后，主集群和灾备集群的偏移量被保存到外部数据存储上。或者只有当两边的偏移量差值发生变
化时，才保存这两个偏移量。 比如， 主集群的偏移量 495 被映射到灾备集群的偏移量500 ，在外部存储上记录为（ 495,500 ）。如果之后因为消息重复导致差值发生变 化， 偏
移量 596 被映射为 600，那么就保留新的映射（ 569,600 ） 。 他们没有必要保留 495 和596 之间的所有偏移量映射，他们假设差值都是一样的，所以主集群的偏移量 550 会映
射到灾备集群的偏移量 555。那么在发生失效备援时，他们将主集群的偏移量与灾备集群的偏移量映射起来，而不是在时间戳（通常会有点不准确）和偏移量之间做映射。他
们通过上述技术手段之一来强制消费者使用映射当 中的偏移量。 对于那些在数据记录之前达到的偏移量或者没有及时被镜像到灾备集群的偏移量来说，仍然会有问题一一不过
这至少已经满足了部分场景的需求。