Kafka权威指南阅读笔记（第八章）

跨集群数据镜像

使用场景：
区域集群和中心集群
这种场景下，每个区域的应用程序只访问相应的区域内的集群。而有些情况下，需要将各个集群的信息汇总到中心集群，就可以用中心集群分析业务数据了。
冗余
一个Kafka集群足以支撑所有的应用程序，但是为了高可用，可以做一个灾备。
云迁移
有很多公司将业务同时部署在本地数据中心和云端。为了实现冗余，应用程序通常运行在多个云供应商的多个服务区域里，或者使用多个云服务。本地和每个云服务都有一个Kafka集群。
有些情况下，也会在数据中心之间传输数据。例如云端部署了一个新的应用，他需要访问本地的数据。本地的应用程序负责更新数据，并把他们保存在本地的数据库里，我们用Conntect捕获这些数据库变更，并把他们保存到本地的Kafka集群上，然后再镜像到云端的Kafka集群上，有助于控制跨数据中心的流量成本，也有助于改进流量的监管和安全性。

多集群架构

跨数据中心会考虑到的一些问题
高延迟
网络通信导致网络延迟是常见的现象。
有限的带宽
单个数据中心的广域网的带宽一般是有限的。
高成本
集群之间的通信都需要成本。因为带宽有限，增加带宽是很昂贵的。

一般我们倾向于为每一个数据中心安装一个Kafka集群，并在这个集群中间复制数据，而不是让不用的应用程序通过广域网访问数据。
原则有：

1. 每个数据中心至少需要一个集群
2. 每两个数据中心之间的数据复制到做到每个事件仅复制一次。除非需要重试。
3. 如果有可能，尽量从远程数据中心读取数据，而不是从远程数据中心写入数据。

Hub 和Spoke架构

中央度量集群。
变种：一个首领集群和一个跟随者集群。前者是首要集群，后者是非关键的报表集群。

这种架构的特点就是，数据分散在多个数据中心，每个数据中心的应用程序只处理自己的数据中心的数据，并且不能访问中央集群的数据。
好处在于数据只会在本地数据中心生成，每个数据中心的数据只会被镜像到中央数据中心一次。只处理单个数据中心的数据的应用程序部署到本地数据中心，而需要处理多个数据中心的数据的应用程序部署到中央数据中心里。数据复制是单向的，这种架构易于部署，配置和监控。

缺点：一个数据中心无法访问另一个数据中心的数据。一个例子就是银行的业务系统，用户会不确定在哪个集群所在城市使用业务，而多个数据中心之间是互相独立的，因此并不适用于这种架构。

双活架构

两个数据中心集群 之间互相共享数据，且同时拥有所有的应用程序。
这种架构的好处就是，能够为就近的用户提供服务，具有性能上的优势。第二个好处就是冗余和弹性。每一个数据中心都是完备的。当一个数据中心失效，可以透明的将用户重定向到另一个数据中心。

缺点：
如何在进行多个位置的数据异步读取和异步更新时避免冲突。简言之，数据一致性。
方案：使用这种架构时，开发人员通常将用户每次都路由到同一个数据中心。

如果两个数据中心几乎同时都收到了一份数据，那么需要确定如何处理这种情况。
方案：一是定义一致的原则，确定哪一个是正确的。二是将两个事件都看作是正确的事件。
亚马逊就是用这种方案：设立一个专门的部分来处理冲突，也就是退货。但是对于股票交易部门来说是行不通的，需要根据具体情况而定。
总之这种架构必然会出现冲突的问题，并且需要想办法解决他们。

Kafka的官方最推荐使用这种架构，因为这是最具伸缩性，弹性，灵活性和成本优势的解决方案。值得投入精力去处理数据冲突，避免循环复制，一致性路由尽量减少冲突等问题。

避免循环镜像的方法就是使用命名空间。用户需要指定订阅哪一个命名空间下的主题。
Kafka的未来版本中会增加数据中心的信息，可以使用这些信息来避免循环镜像。

主备架构

这种架构可以用于任何一种场景。

要实现不丢失数据或者无重复数据的Kafka集群失效备援是不可能的事情。
缺点就是有点浪费。

失效备援的内容：

1.数据丢失和不一致
Kafka的集群镜像方案都是异步的，并且Kafka目前还不支持事务。切换到灾备集群之后，应用程序需要知道该如何处理数据。

2.起始偏移量
偏移量自动重置。要么从头开始读取，要么从最新的末尾开始读取。从末尾开始读取数据的方式更常见。
复制偏移量主题。__consumer_offets。

主机群和偏移量和灾备集群的偏移量无法保证是完全匹配的。因为镜像时间和保留时间不确定。
即便是在主题创建之后立即开始镜像，主机群和灾备集群的主题偏移量都从0开始，生产者的重试依然会造成偏移量的偏离。目前的Kafka镜像解决方案无法为主集群和灾备集群保留偏移量。
即便保留了偏移量，因为主机群和灾备集群之间的延迟以及Kafka缺乏对事务的支持，消费者提交的偏移量可能在记录之前或者记录之后到达。失效备援之后，消费者就会发现偏移量和记录不匹配，或者灾备集群的偏移量比主机群最新的偏移量小。
在这些情况下，我们要接受重复的数据。

基于时间的失效备援：知道失效备援发生的时间，可以让消费者根据时间戳查找偏移量，从而回到附近的一个偏移量。
偏移量外部映射：官方不推荐使用这种方案，不值得。推荐使用第一种方案，只需要使用新版的API。

失效备援之后：
通常将旧集群清理掉，删除所有的数据和偏移量，然后从新的主机群把数据镜像回来，保证数据是一致的。如果不删除数据会出现重复数据或者丢失数据的情况，容易出现不一致的情况。

延展集群

Kafka内置的复制机制，可以打开延展集群的同步复制功能，生产者会在消息成功写入其他数据中心后收到确认。同步复制功能要求使用机架信息，确保每个分区在其他数据中心都存在副本，还需要配置min.isr和acks=all。
同步复制是这种集群架构的最大优势，有些业务要求灾备站点和主站点保持100%的同步复制。另一个好处就是数据中心所有的Broker都发挥了作用。
缺点是他所能应对的灾难类型很有限，只能应对数据中心的故障，不能应对应用程序或者Kafka的故障。运维复杂性是它的另一个不足之处，他所需要的物理基础设施不是所有的功能都能承担起的。

如果能够至少在3个具有高带宽和低延迟的数据中心上安装Kafka，那么就可以使用这种架构。Zookeeper要求集群里的节点是奇数个。