wordpress换为中文seo方案怎么做

1、Kafka是什么？

Kafka是由Scala语言开发的一个多分区、多副本，基于Zookeeper集群协调的系统。

那这个所谓的系统又是什么系统呢？

回答这个问题要从发展的角度来看：起初Kafka的定位是分布式消息系统。但是目前它的定位是一个分布式流式处理平台，用于实时数据集成和流数据处理。

2、Kafka都可以扮演哪些“角色”？

基于Kafka的发展和特性，它可以在我们的实际工作当中扮演以下几个“角色”：

• 消息系统
• 存储系统：将消息持久化到磁盘上。
• 流式处理平台：可以集成多种流式处理框架（例如：SparkStream、Flink等），不但可以作为可靠的数据源，同时提供了一套完整的流处理类库，例如：窗口、连接、交换和聚合等操作。

3、Kafka的体系架构？

Kafka体系架构包括：生产者（Producer）、消费者（Consumer）、服务代理节点（Broker）、一个Zookeeper集群。

• 生产者（Producer）

  作为消息的发送方。负责创建消息，并将消息发送给Broker。

• 消费者（Consumer）

  作为消息的接收方。负责连接Kafka并接收消息，进而进行相应的逻辑处理。

• 代理服务节点（Broker）

  可以看做一个Kafka实例，多个Broker组成一个Kafka集群。

• Zookeeper集群

  Zookeeper用来负责Kafka集群的元数据管理和控制器的选举等操作。

让我们进一步来描述Producer、Consumer、Broker之间的关系以及作用：

Producer创建消息并将消息发送给Borker，Broker将接收到的消息存储到本地的磁盘上，Consumer负责在Broker上订阅并消费消息。

4、主题、分区、副本

Kafka中有三个重要的概念，主题、分区和副本。它们之间的关系如下图：

通过上图我们可以得知：

1个主题对应多个分区；一个分区对应多个副本；副本又分为一个leader副本和多个follower副本。

4.1、主题

1. 主题是一个逻辑概念，我们可以把它当做消息的分类。
2. Producer发送消息的时候会指明该消息所属的主题（即可以理解为Producer是将消息发送给了主题），一个消息只属于一个主题。

4.2、分区

1. 一个主题下会细分为多个分区，每个分区对应一个主题。
2. 消息在分区中的以offset（偏移量）作为唯一标识。
3. Kafka通过offset来保证消息在分区中的顺序。
4. offset不能跨区，所以我们说分区是有序的，而主题是无序。
5. 分区可以分布在不同的broker上。

4.3、副本

1. 一个分区会有多个副本，副本中的消息都是一致的（同一时刻可能会有不一致的情况）。

2. 副本之间的关系是“一主多从”，即一个leader副本和多个follower副本。

   • leader副本：负责消息的读写。
   • follower副本：负责同步leader副本。

3. 副本被分布到不同的broker上，leader副本挂掉了，会从follower副本中重新选举出一个新的leader副本。

4. 我们将分区中所有副本统称为AR（Assigned Replicas）。其中一些与leader副本保持一定程度同步的副本（包括leader副本本身）统称为ISR（In-Sync Replicas）。而另外一些相较于leader副本滞后很多的副本统称为OSR（Out-of-Sync Replicas）。

   由此可见，AR = ISR + OSR。正常情况下，所有follower副本都要与leader版本保持一定程度的同步，即AR = ISR，而OSR集合为空。

5. 默认情况下，leader副本只能从ISR中的副本中选举出来。但是我们可以通过参数配置使得OSR中的副本也有机会被选举为leader副本。

6. leader副本还负责所有follower副本滞后状态的维护和跟踪，即当follower副本滞后较多的时候会将它从ISR中移动到OSR中，也会将OSR中追上leader副本的follower副本移动到ISR中。

7. 特定偏移量HW和LEO。

   • 针对分区有一个概念为高水位（High Watermark，缩写HW），它是一个特定的消息偏移量（offset），消费者只能接收到offset之前的消息
   • ISR中的每个follower副本都维护一个自己的LEO（Log End Offset），它也是一个特定的消息偏移量（offset），即待写入消息的偏移量。

10. HW与LEO之间的关系，如下图：
    
    通过上图我们可以得知：分区的HW是通过ISR中最小的LEO得出的。

4.4、如何避免Consumer宕机重启后的消息丢失？

Consumer是通过拉（Pull）模式从服务端拉取消息的，同时会在Consumer端记录下消费的具体位置，当Consumer宕机重启后会根据之前记录的消费位置重新拉取需要的信息进行消费。