Rin's blog

Spring核心编程思想重新认识IOC/IOC容器概述

Mon, 16 May 2022 14:55:06 +0000

依赖查找

依赖查找可以分为按名称、类型、注解查找三种(包括单个类型和集合类型)

根据Bean名称/类型查找

/**
* 根据类型查找
*/
private static void lookupByType(BeanFactory beanFactory) {
  User user = beanFactory.getBean(User.class);
  System.out.println("根据类型查找: " + user);
}

/**
* 根据名称查找
*/
private static void lookupByName(BeanFactory beanFactory) {
  User user = (User) beanFactory.getBean("user");
  System.out.println("根据名称查找: " + user);
}

根据Bean类型/类型查找集合对象

/**
* 按照类型查找集合对象
*/
private static void lookupCollectionByType(BeanFactory beanFactory) {
  if (beanFactory instanceof ListableBeanFactory) {
    Map<String, User> userList = ((ListableBeanFactory) beanFactory).getBeansOfType(User.class);
    System.out.println("查找到的所有类型为User的集合对象: " + userList);
  }
}

根据Java注解查找

/**
* 根据注解查找集合对象
*/
private static void lookupCollectionByAnnotationType(BeanFactory beanFactory) {
  if (beanFactory instanceof ListableBeanFactory) {
    ListableBeanFactory listableBeanFactory = ((ListableBeanFactory) beanFactory);
    Map<String, User> userList = (Map) listableBeanFactory.getBeansWithAnnotation(Root.class);
    System.out.println("查找到的所有标注 @Root 的User的集合对象: " + userList);
  }
}

实时/延迟查找

首先明确一下什么是延迟查找，一般来说通过@Autowired注解注入一个具体对象的方式是属于实时依赖查找，注入的前提是要保证对象已经被创建。而使用延迟查找的方式是我可以不注入对象的本身，而是通过注入一个代理对象，在需要用到的地方再去取其中真实的对象来使用，ObjectFactory提供的就是这样一种能力。

实时查找：马上查找，马上索得
延迟查找：并不是指延迟加载Bean。而是不注入对象的本身，而是通过注入一个代理对象，在需要用到的地方再去取其中真实的对象来使用，ObjectFactory提供的就是这样一种能力。

/**
  * 实时查找
  */
private static void lookupInRealTime(BeanFactory beanFactory) {
  User user = (User) beanFactory.getBean("user");
  System.out.println("实时查找: " + user);
}

/**
  * 延时查找
  */
private static void lookupInLazy(BeanFactory beanFactory) {
  ObjectFactory<User> objectFactory = (ObjectFactory<User>) beanFactory.getBean("objectFactory");
  User user = objectFactory.getObject();
  System.out.println("延迟查找: " + user);
}

依赖注入

1）根据Bean名称注入

2）根据Bean类型注入(单个Bean对象/集合Bean对象)

<bean id="userRepository" class="cn.rin.thinking.ioc.overview.repository.UserRepository"
      autowire="byType"> <!--  Auto-Wiring 自动绑定-->
  <!-- 硬编码,手动配置-->
  <!--        <property name="users">-->
  <!--            <util:list>-->
  <!--                <ref bean="rootUser"/>-->
  <!--                <ref bean="user"/>-->
  <!--            </util:list>-->
  <!--        </property>-->
</bean>

3）注入容器内建Bean对象

4）注入非Bean对象

5）注入类型(实时注入/延时注入)

/**
 * 用户信息仓库
 *
 * @author rin
 * @since 2023.03.19
 */
@Data
public class UserRepository {

  /** 
    * 定义 bean 
    */ 
  private Collection<User> users;

  /**
    * 内建非 Bean对象(依赖)
    */
  private BeanFactory beanFactory;

  /** 
    * 延时注入
    */ 
  private ObjectFactory<User> userObjectFactory;
}

依赖来源

1）自定义Bean，如业务Bean

2）容器内建Bean对象，如org.springframework.core.env.Environment

3）容器内建依赖，如BeanFactory

配置元信息

1）Bean定义配置

基于XML文件
基于Properties文件
基于Java注解
基于Java API

2）Ioc容器配置

基于XML文件
基于Java注解
基于Java API

3）外部化属性配置

基于Java注解(@Value)

IoC容器

ApplicationContext、BeanFactory谁才是真正的IoC容器？

结论：ApplicationContext、BeanFactory其实是同一类东西，只不过在底层实现的时候，ApplicationContext组合了一个BeanFactory实现。在上下文里面的实现它是组合了的一个方式，同时它又在接口上面是继承的关系。这种方式实际上类似于代理的方式，相当于我用代理对象去查这个东西，它并不是自己具备这个能力，而是外面组装了一个组合对象来帮助自己去做这个事情，这就是ApplicationContext、BeanFactory的区别。BeanFactory是一个底层的IoC容器，ApplicationContext是在它的基础上增加了一些特性(ApplicationContext是BeanFactory的一个超集，BeanFactory的能力ApplicationContext都有，并且提供更多的特性，AOP更好的整合、国际化的支持、事物的发布等等)。

// ConfigurableApplicationContext <- ApplicationContext <- BeanFactory
// ConfigurableApplicationContext#getBeanFactory()

ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:META-INF/dependency-injection-context.xml");
// 自定义Bean
UserRepository userRepository = applicationContext.getBean("userRepository", UserRepository.class);
// false 为什么这个表达式不会成立
System.out.println(userRepository.getBeanFactory() == applicationContext);

实际上 ApplicationContext implements ConfigurableApplicationContext，ApplicationContext 的 getBeanFactory()方法就来自于父类接口。

public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext {
  public abstract ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;

  public <T> T getBean(Class<T> requiredType) throws BeansException {
    this.assertBeanFactoryActive();
    return this.getBeanFactory().getBean(requiredType);
  }
}

而该方法的具体实现可以在AbstractRefreshableApplicationContext类中看到，实际上是把beanFactory的能力组合到了AbstractApplicationContext中，并不是完完全全去抽象或者基层这个类，因此userRepository.getBeanFactory() == applicationContext才会是false。

public abstract class AbstractRefreshableApplicationContext extends AbstractApplicationContext {
  
  @Nullable
  private volatile DefaultListableBeanFactory beanFactory;

  public final ConfigurableListableBeanFactory getBeanFactory() {
    DefaultListableBeanFactory beanFactory = this.beanFactory;
    if (beanFactory == null) {
      throw new IllegalStateException("BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext");
    } else {
      return beanFactory;
    }
  }
}

Spring应用上下文

IoC容器生命周期

学习笔记 spring核心编程思想

Mon, 16 May 2022 00:00:00 +0000

前言

接触和使用Spring Framework 已经很长时间了，其特性和原理都有深入了解。不过都是看一些零零散散的博客学习的，总感觉学习的不够完善和系统。今天特此开个新坑，跟着小马哥的课程好好系统的学习一下Spring核心编程思想(5.2.2.RELEASE)，希望能够有所收获。

repo: https://github.com/Silincee/spring-thinking

Kafka源码浅析

Tue, 10 May 2022 07:40:06 +0000

前言

本文阅读的Kafka源码版本为：kafka-3.0.0

生产者源码

生产者消息发送流程

在消息发送的过程中，涉及到了两个线程：main 线程和 Sender 线程。在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程通过分区器将消息发送给 RecordAccumulator， Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka Broker。

batch.size：只有数据积累到batch.size之后，sender才会发送数据，默认16k
linger.ms：如果数据迟迟未达到batch.size,sender等待linger.ms设置的时间。到了之后就会发送数据，单位ms，默认值是0ms，表示没有延迟。

应答acks：

0：生产者发送过来的数据，不需要等数据落盘应答。
1：生产者发送过来的数据，Leader 收到数据后应答。
-1(all)：生产者发送过来的数据，Leader 和 ISR 队列里面的所有节点收齐数据后应答。-1和 all 等价。

初始化

生产者main线程初始化

1）main线程中首先会通过构造器创建一个KafkaProducer()

public KafkaProducer(Properties properties) {
  this(properties, null, null);
}
// 然后会依次调用以下构造器
public KafkaProducer(Properties properties, Serializer<K> keySerializer, Serializer<V> valueSerializer) {
  this(Utils.propsToMap(properties), keySerializer, valueSerializer);
}
public KafkaProducer(Map<String, Object> configs, Serializer<K> keySerializer, Serializer<V> valueSerializer) {
  this(new ProducerConfig(ProducerConfig.appendSerializerToConfig(configs, keySerializer, valueSerializer)),
       keySerializer, valueSerializer, null, null, null, Time.SYSTEM);
}

2）最终调用的KafkaProducer构造器

@SuppressWarnings("unchecked")
KafkaProducer(ProducerConfig config,
              Serializer<K> keySerializer,
              Serializer<V> valueSerializer,
              ProducerMetadata metadata,
              KafkaClient kafkaClient,
              ProducerInterceptors<K, V> interceptors,
              Time time) {
  try {
    this.producerConfig = config;
    this.time = time;

    // 获取事务id
    String transactionalId = config.getString(ProducerConfig.TRANSACTIONAL_ID_CONFIG);

    // 获取客户端id
    this.clientId = config.getString(ProducerConfig.CLIENT_ID_CONFIG);

    LogContext logContext;
    if (transactionalId == null)
      logContext = new LogContext(String.format("[Producer clientId=%s] ", clientId));
    else
      logContext = new LogContext(String.format("[Producer clientId=%s, transactionalId=%s] ", clientId, transactionalId));
    log = logContext.logger(KafkaProducer.class);
    log.trace("Starting the Kafka producer");

    Map<String, String> metricTags = Collections.singletonMap("client-id", clientId);
    MetricConfig metricConfig = new MetricConfig().samples(config.getInt(ProducerConfig.METRICS_NUM_SAMPLES_CONFIG))
      .timeWindow(config.getLong(ProducerConfig.METRICS_SAMPLE_WINDOW_MS_CONFIG), TimeUnit.MILLISECONDS)
      .recordLevel(Sensor.RecordingLevel.forName(config.getString(ProducerConfig.METRICS_RECORDING_LEVEL_CONFIG)))
      .tags(metricTags);
    List<MetricsReporter> reporters = config.getConfiguredInstances(ProducerConfig.METRIC_REPORTER_CLASSES_CONFIG,
                                                                    MetricsReporter.class,
                                                                    Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId));
    // 监控kafka运行情况
    JmxReporter jmxReporter = new JmxReporter();
    jmxReporter.configure(config.originals(Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId)));
    reporters.add(jmxReporter);
    MetricsContext metricsContext = new KafkaMetricsContext(JMX_PREFIX,
                                                            config.originalsWithPrefix(CommonClientConfigs.METRICS_CONTEXT_PREFIX));
    this.metrics = new Metrics(metricConfig, reporters, time, metricsContext);
    // 获取分区器
    this.partitioner = config.getConfiguredInstance(
      ProducerConfig.PARTITIONER_CLASS_CONFIG,
      Partitioner.class,
      Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId));
    // 重试时间间隔参数配置，默认值100ms
    long retryBackoffMs = config.getLong(ProducerConfig.RETRY_BACKOFF_MS_CONFIG);
    // key和value的序列化
    if (keySerializer == null) {
      this.keySerializer = config.getConfiguredInstance(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
                                                        Serializer.class);
      this.keySerializer.configure(config.originals(Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId)), true);
    } else {
      config.ignore(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG);
      this.keySerializer = keySerializer;
    }
    if (valueSerializer == null) {
      this.valueSerializer = config.getConfiguredInstance(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
                                                          Serializer.class);
      this.valueSerializer.configure(config.originals(Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId)), false);
    } else {
      config.ignore(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG);
      this.valueSerializer = valueSerializer;
    }

    // 拦截器处理（拦截器可以有多个）
    List<ProducerInterceptor<K, V>> interceptorList = (List) config.getConfiguredInstances(
      ProducerConfig.INTERCEPTOR_CLASSES_CONFIG,
      ProducerInterceptor.class,
      Collections.singletonMap(ProducerConfig.CLIENT_ID_CONFIG, clientId));
    if (interceptors != null)
      this.interceptors = interceptors;
    else
      this.interceptors = new ProducerInterceptors<>(interceptorList);
    ClusterResourceListeners clusterResourceListeners = configureClusterResourceListeners(keySerializer,
                                                                                          valueSerializer, interceptorList, reporters);
    // 单条日志大小 默认1m
    this.maxRequestSize = config.getInt(ProducerConfig.MAX_REQUEST_SIZE_CONFIG);
    // 缓冲区大小 默认32m
    this.totalMemorySize = config.getLong(ProducerConfig.BUFFER_MEMORY_CONFIG);
    // 压缩，默认是none
    this.compressionType = CompressionType.forName(config.getString(ProducerConfig.COMPRESSION_TYPE_CONFIG));

    this.maxBlockTimeMs = config.getLong(ProducerConfig.MAX_BLOCK_MS_CONFIG);
    int deliveryTimeoutMs = configureDeliveryTimeout(config, log);

    this.apiVersions = new ApiVersions();
    this.transactionManager = configureTransactionState(config, logContext);
    // 缓冲区对象 默认是32m 参数列表如下：
    // 批次大小 默认16k
    // 压缩方式，默认是none
    // liner.ms 默认是0
    //  内存池
    this.accumulator = new RecordAccumulator(logContext,
                                             config.getInt(ProducerConfig.BATCH_SIZE_CONFIG),
                                             this.compressionType,
                                             lingerMs(config),
                                             retryBackoffMs,
                                             deliveryTimeoutMs,
                                             metrics,
                                             PRODUCER_METRIC_GROUP_NAME,
                                             time,
                                             apiVersions,
                                             transactionManager,
                                             new BufferPool(this.totalMemorySize, config.getInt(ProducerConfig.BATCH_SIZE_CONFIG), metrics, time, PRODUCER_METRIC_GROUP_NAME));

    // 连接上kafka集群地址
    List<InetSocketAddress> addresses = ClientUtils.parseAndValidateAddresses(
      config.getList(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG),
      config.getString(ProducerConfig.CLIENT_DNS_LOOKUP_CONFIG));
    // 获取元数据
    if (metadata != null) {
      this.metadata = metadata;
    } else {
      this.metadata = new ProducerMetadata(retryBackoffMs,
                                           config.getLong(ProducerConfig.METADATA_MAX_AGE_CONFIG),
                                           config.getLong(ProducerConfig.METADATA_MAX_IDLE_CONFIG),
                                           logContext,
                                           clusterResourceListeners,
                                           Time.SYSTEM);
      this.metadata.bootstrap(addresses);
    }
    this.errors = this.metrics.sensor("errors");
		
    this.sender = newSender(logContext, kafkaClient, this.metadata);
    String ioThreadName = NETWORK_THREAD_PREFIX + " | " + clientId;
    // 把sender线程放到后台
    this.ioThread = new KafkaThread(ioThreadName, this.sender, true);
    // ⭐️启动sender线程
    this.ioThread.start();
    config.logUnused();
    AppInfoParser.registerAppInfo(JMX_PREFIX, clientId, metrics, time.milliseconds());
    log.debug("Kafka producer started");
  } catch (Throwable t) {
    // call close methods if internal objects are already constructed this is to prevent resource leak. see KAFKA-2121
    close(Duration.ofMillis(0), true);
    // now propagate the exception
    throw new KafkaException("Failed to construct kafka producer", t);
  }
}

生产者sender线程初始化

1）main线程初始化中，调用newSender(logContext, kafkaClient, this.metadata);来到sender线程初始化

Sender newSender(LogContext logContext, KafkaClient kafkaClient, ProducerMetadata metadata) {
  // 缓存请求的个数 默认是5个
  int maxInflightRequests = configureInflightRequests(producerConfig);
  // 请求超时时间，默认30s
  int requestTimeoutMs = producerConfig.getInt(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG);
  ChannelBuilder channelBuilder = ClientUtils.createChannelBuilder(producerConfig, time, logContext);
  ProducerMetrics metricsRegistry = new ProducerMetrics(this.metrics);
  Sensor throttleTimeSensor = Sender.throttleTimeSensor(metricsRegistry.senderMetrics);

  // 创建一个客户端对象
  // clientId  客户端id
  // maxInflightRequests  缓存请求的个数 默认是5个
  // RECONNECT_BACKOFF_MS_CONFIG 重试时间
  // RECONNECT_BACKOFF_MAX_MS_CONFIG 总的重试时间
  // 发送缓冲区大小send.buffer.bytes  默认128kb
  // 接收数据缓存 receive.buffer.bytes 默认是32kb
  KafkaClient client = kafkaClient != null ? kafkaClient : new NetworkClient(
    new Selector(producerConfig.getLong(ProducerConfig.CONNECTIONS_MAX_IDLE_MS_CONFIG),
                 this.metrics, time, "producer", channelBuilder, logContext),
    metadata,
    clientId,
    maxInflightRequests,
    producerConfig.getLong(ProducerConfig.RECONNECT_BACKOFF_MS_CONFIG),
    producerConfig.getLong(ProducerConfig.RECONNECT_BACKOFF_MAX_MS_CONFIG),
    producerConfig.getInt(ProducerConfig.SEND_BUFFER_CONFIG),
    producerConfig.getInt(ProducerConfig.RECEIVE_BUFFER_CONFIG),
    requestTimeoutMs,
    producerConfig.getLong(ProducerConfig.SOCKET_CONNECTION_SETUP_TIMEOUT_MS_CONFIG),
    producerConfig.getLong(ProducerConfig.SOCKET_CONNECTION_SETUP_TIMEOUT_MAX_MS_CONFIG),
    time,
    true,
    apiVersions,
    throttleTimeSensor,
    logContext);
  // 0 ：生产者发送过来，不需要应答；  1 ：leader收到，应答；  -1 ：leader和isr队列里面所有的都收到了应答
  short acks = configureAcks(producerConfig, log);
  // 创建sender线程
  return new Sender(logContext,
                    client,
                    metadata,
                    this.accumulator,
                    maxInflightRequests == 1,
                    producerConfig.getInt(ProducerConfig.MAX_REQUEST_SIZE_CONFIG),
                    acks,
                    producerConfig.getInt(ProducerConfig.RETRIES_CONFIG),
                    metricsRegistry.senderMetrics,
                    time,
                    requestTimeoutMs,
                    producerConfig.getLong(ProducerConfig.RETRY_BACKOFF_MS_CONFIG),
                    this.transactionManager,
                    apiVersions);
}

2）Sender 对象被放到了一个线程中启动，所有需要点击 newSender()方法中的 Sender，并找到 sender 对象中的 run()方法。

public void run() {
  log.debug("Starting Kafka producer I/O thread.");

  // main loop, runs until close is called
  while (running) {
    try {
      // sender 线程从缓冲区准备拉取数据，刚启动拉不到数据
      runOnce();
    } catch (Exception e) {
      log.error("Uncaught error in kafka producer I/O thread: ", e);
    }
  }
  ...
}

生产者发送数据到缓冲区

发送总体流程

1）KafkaProducer.send()方法

public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback) {
  // intercept the record, which can be potentially modified; this method does not throw exceptions
  // 拦截器相关操作
  ProducerRecord<K, V> interceptedRecord = this.interceptors.onSend(record);
  return doSend(interceptedRecord, callback);
}

2）其中的 onSend()方法，进行拦截器相关处理。

public ProducerRecord<K, V> onSend(ProducerRecord<K, V> record) {
  ProducerRecord<K, V> interceptRecord = record;
  for (ProducerInterceptor<K, V> interceptor : this.interceptors) {
    try {
      // 拦截器对数据进行加工
      interceptRecord = interceptor.onSend(interceptRecord);
    } catch (Exception e) {
      // do not propagate interceptor exception, log and continue calling other interceptors
      // be careful not to throw exception from here
      if (record != null)
        log.warn("Error executing interceptor onSend callback for topic: {}, partition: {}", record.topic(), record.partition(), e);
      else
        log.warn("Error executing interceptor onSend callback", e);
    }
  }
  return interceptRecord;
}

3）从拦截器处理中返回，点击 doSend()方法。

private Future<RecordMetadata> doSend(ProducerRecord<K, V> record, Callback callback) {
  TopicPartition tp = null;
  try {
    throwIfProducerClosed();
    // first make sure the metadata for the topic is available
    long nowMs = time.milliseconds();
    ClusterAndWaitTime clusterAndWaitTime;
    try {
      // 从 Kafka 拉取元数据。maxBlockTimeMs 表示最多能等待多长时间。
      clusterAndWaitTime = waitOnMetadata(record.topic(), record.partition(), nowMs, maxBlockTimeMs);
    } catch (KafkaException e) {
      if (metadata.isClosed())
        throw new KafkaException("Producer closed while send in progress", e);
      throw e;
    }
    nowMs += clusterAndWaitTime.waitedOnMetadataMs;
    // 剩余时间 = 最多能等待时间 - 用了多少时间;
    long remainingWaitMs = Math.max(0, maxBlockTimeMs - clusterAndWaitTime.waitedOnMetadataMs);
    // 更新集群元数据
    Cluster cluster = clusterAndWaitTime.cluster;
    // 序列化相关操作
    byte[] serializedKey;
    try {
      serializedKey = keySerializer.serialize(record.topic(), record.headers(), record.key());
    } catch (ClassCastException cce) {
      throw new SerializationException("Can't convert key of class " + record.key().getClass().getName() +
                                       " to class " + producerConfig.getClass(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG).getName() +
                                       " specified in key.serializer", cce);
    }
    byte[] serializedValue;
    try {
      serializedValue = valueSerializer.serialize(record.topic(), record.headers(), record.value());
    } catch (ClassCastException cce) {
      throw new SerializationException("Can't convert value of class " + record.value().getClass().getName() +
                                       " to class " + producerConfig.getClass(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG).getName() +
                                       " specified in value.serializer", cce);
    }
    // 🤔分区操作(根据元数据信息)
    int partition = partition(record, serializedKey, serializedValue, cluster);
    tp = new TopicPartition(record.topic(), partition);

    setReadOnly(record.headers());
    Header[] headers = record.headers().toArray();

    int serializedSize = AbstractRecords.estimateSizeInBytesUpperBound(apiVersions.maxUsableProduceMagic(),
                                                                       compressionType, serializedKey, serializedValue, headers);
    // 🤔保证数据大小能够传输(序列化后的  压缩后的)，发送消息的大小是否超过最大值，默认是1m
    ensureValidRecordSize(serializedSize);

    long timestamp = record.timestamp() == null ? nowMs : record.timestamp();
    if (log.isTraceEnabled()) {
      log.trace("Attempting to append record {} with callback {} to topic {} partition {}", record, callback, record.topic(), partition);
    }
    // 消息发送的回调函数
    // producer callback will make sure to call both 'callback' and interceptor callback
    Callback interceptCallback = new InterceptorCallback<>(callback, this.interceptors, tp);

    if (transactionManager != null && transactionManager.isTransactional()) {
      transactionManager.failIfNotReadyForSend();
    }
    // 🤔accumulator缓存  追加数据  result是是否添加成功的结果
    RecordAccumulator.RecordAppendResult result = accumulator.append(tp, timestamp, serializedKey,
                                                                     serializedValue, headers, interceptCallback, remainingWaitMs, true, nowMs);

    if (result.abortForNewBatch) {
      int prevPartition = partition;
      partitioner.onNewBatch(record.topic(), cluster, prevPartition);
      partition = partition(record, serializedKey, serializedValue, cluster);
      tp = new TopicPartition(record.topic(), partition);
      if (log.isTraceEnabled()) {
        log.trace("Retrying append due to new batch creation for topic {} partition {}. The old partition was {}", record.topic(), partition, prevPartition);
      }
      // producer callback will make sure to call both 'callback' and interceptor callback
      interceptCallback = new InterceptorCallback<>(callback, this.interceptors, tp);

      result = accumulator.append(tp, timestamp, serializedKey,
                                  serializedValue, headers, interceptCallback, remainingWaitMs, false, nowMs);
    }

    if (transactionManager != null && transactionManager.isTransactional())
      transactionManager.maybeAddPartitionToTransaction(tp);
    // 批次大小已经满了 获取有一个新批次创建
    if (result.batchIsFull || result.newBatchCreated) {
      log.trace("Waking up the sender since topic {} partition {} is either full or getting a new batch", record.topic(), partition);
      // 唤醒发送线程
      this.sender.wakeup();
    }
    return result.future;
    // handling exceptions and record the errors;
    // for API exceptions return them in the future,
    // for other exceptions throw directly
  } catch (ApiException e) {
    log.debug("Exception occurred during message send:", e);
    if (callback != null)
      callback.onCompletion(null, e);
    this.errors.record();
    this.interceptors.onSendError(record, tp, e);
    return new FutureFailure(e);
  } catch (InterruptedException e) {
    this.errors.record();
    this.interceptors.onSendError(record, tp, e);
    throw new InterruptException(e);
  } catch (KafkaException e) {
    this.errors.record();
    this.interceptors.onSendError(record, tp, e);
    throw e;
  } catch (Exception e) {
    // we notify interceptor about all exceptions, since onSend is called before anything else in this method
    this.interceptors.onSendError(record, tp, e);
    throw e;
  }
}

分区选择

1）发送总体流程中以下代码为分区选择相关流程：

// 分区操作
int partition = partition(record, serializedKey, serializedValue, cluster);
tp = new TopicPartition(record.topic(), partition);

// partition()方法具体如下：
private int partition(ProducerRecord<K, V> record, byte[] serializedKey, byte[] serializedValue, Cluster cluster) {
  Integer partition = record.partition();
  // 如果指定分区，按照指定分区配置
  return partition != null ?
    partition :
  // 分区器选择分区
  partitioner.partition( // 点击 partition，跳转到 Partitioner 接口，选择默认的分区器 DefaultPartitioner --> 2⃣️
    record.topic(), record.key(), serializedKey, record.value(), serializedValue, cluster);
}

2）点击 partition，跳转到 Partitioner 接口，选择默认的分区器 DefaultPartitioner

public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster,
                     int numPartitions) {
  // 没有指定key
  if (keyBytes == null) {
    // 按照粘性分区处理 --> 3⃣️
    return stickyPartitionCache.partition(topic, cluster);
  }
  // 如果指定key,按照key的hashcode值 对分区数求模
  // hash the keyBytes to choose a partition
  return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
}
---------------------------------------------------------
// 3⃣️没有指定key和分区的处理方式 stickyPartitionCache.partition(topic, cluster);
public int partition(String topic, Cluster cluster) {
  Integer part = indexCache.get(topic);
  if (part == null) {
    return nextPartition(topic, cluster, -1); // --> 4⃣️
  }
  return part;
}
---------------------------------------------------------
// 4⃣️nextPartition(topic, cluster, -1);
public int nextPartition(String topic, Cluster cluster, int prevPartition) {
  List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
  Integer oldPart = indexCache.get(topic);
  Integer newPart = oldPart;
  // Check that the current sticky partition for the topic is either not set or that the partition that 
  // triggered the new batch matches the sticky partition that needs to be changed.
  if (oldPart == null || oldPart == prevPartition) {
    List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
    if (availablePartitions.size() < 1) {
      Integer random = Utils.toPositive(ThreadLocalRandom.current().nextInt());
      newPart = random % partitions.size();
    } else if (availablePartitions.size() == 1) {
      newPart = availablePartitions.get(0).partition();
    } else {
      while (newPart == null || newPart.equals(oldPart)) {
        int random = Utils.toPositive(ThreadLocalRandom.current().nextInt());
        newPart = availablePartitions.get(random % availablePartitions.size()).partition();
      }
    }
    // Only change the sticky partition if it is null or prevPartition matches the current sticky partition.
    if (oldPart == null) {
      indexCache.putIfAbsent(topic, newPart);
    } else {
      indexCache.replace(topic, prevPartition, newPart);
    }
    return indexCache.get(topic);
  }
  return indexCache.get(topic);
}

发送消息大小校验

发送总体流程中的ensureValidRecordSize(serializedSize)方法涉及到发送消息大小校验操作

private void ensureValidRecordSize(int size) {
  // 单条信息最大值 maxRequestSize 1m
  if (size > maxRequestSize)
    throw new RecordTooLargeException("The message is " + size +
                                      " bytes when serialized which is larger than " + maxRequestSize + ", which is the value of the " +
                                      ProducerConfig.MAX_REQUEST_SIZE_CONFIG + " configuration.");
  // 缓冲区内存总大小，默认32m
  if (size > totalMemorySize)
    throw new RecordTooLargeException("The message is " + size +
                                      " bytes when serialized which is larger than the total memory buffer you have configured with the " +
                                      ProducerConfig.BUFFER_MEMORY_CONFIG +
                                      " configuration.");
}

内存/缓存池

发送总体流程中的RecordAccumulator.RecordAppendResult result = accumulator.append(...);

public RecordAppendResult append(TopicPartition tp,
                                 long timestamp,
                                 byte[] key,
                                 byte[] value,
                                 Header[] headers,
                                 Callback callback,
                                 long maxTimeToBlock,
                                 boolean abortOnNewBatch,
                                 long nowMs) throws InterruptedException {
  // We keep track of the number of appending thread to make sure we do not miss batches in
  // abortIncompleteBatches().
  appendsInProgress.incrementAndGet();
  ByteBuffer buffer = null;
  if (headers == null) headers = Record.EMPTY_HEADERS;
  try {
    // check if we have an in-progress batch
    // 获取或者创建一个队列（按照每个主题的分区）
    Deque<ProducerBatch> dq = getOrCreateDeque(tp);
    synchronized (dq) {
      if (closed)
        throw new KafkaException("Producer closed while send in progress");
      // 尝试向队列里面添加数据(没有分配内存、批次对象，所以失败)
      RecordAppendResult appendResult = tryAppend(timestamp, key, value, headers, callback, dq, nowMs);
      if (appendResult != null)
        return appendResult;
    }

    // we don't have an in-progress record batch try to allocate a new batch
    if (abortOnNewBatch) {
      // Return a result that will cause another call to append.
      return new RecordAppendResult(null, false, false, true);
    }

    byte maxUsableMagic = apiVersions.maxUsableProduceMagic();
    // this.batchSize 默认16k    数据大小17k
    int size = Math.max(this.batchSize, AbstractRecords.estimateSizeInBytesUpperBound(maxUsableMagic, compression, key, value, headers));
    log.trace("Allocating a new {} byte message buffer for topic {} partition {} with remaining timeout {}ms", size, tp.topic(), tp.partition(), maxTimeToBlock);
    // 申请内存  内存池根据批次大小(默认16k)和消息大小中最大值，分配内存   😎双端队列 
    buffer = free.allocate(size, maxTimeToBlock);

    // Update the current time in case the buffer allocation blocked above.
    nowMs = time.milliseconds();
    synchronized (dq) {
      // Need to check if producer is closed again after grabbing the dequeue lock.
      if (closed)
        throw new KafkaException("Producer closed while send in progress");
      // 尝试向队列里面添加数据(有内存，但是没有批次对象)
      RecordAppendResult appendResult = tryAppend(timestamp, key, value, headers, callback, dq, nowMs);
      if (appendResult != null) {
        // Somebody else found us a batch, return the one we waited for! Hopefully this doesn't happen often...
        return appendResult;
      }
      // 封装内存buffer
      MemoryRecordsBuilder recordsBuilder = recordsBuilder(buffer, maxUsableMagic);
      // 根据内存大小封装批次(有内存、有批次对象)
      ProducerBatch batch = new ProducerBatch(tp, recordsBuilder, nowMs);
      // 尝试向队列里面添加数据
      FutureRecordMetadata future = Objects.requireNonNull(batch.tryAppend(timestamp, key, value, headers,
                                                                           callback, nowMs));
      // 把新创建的批次放到队列末尾
      dq.addLast(batch);
      incomplete.add(batch);

      // Don't deallocate this buffer in the finally block as it's being used in the record batch
      buffer = null;
      return new RecordAppendResult(future, dq.size() > 1 || batch.isFull(), true, false);
    }
  } finally {
    // 如果发生异常，释放内存
    if (buffer != null)
      free.deallocate(buffer);
    appendsInProgress.decrementAndGet();
  }
}

sender 线程发送数据

1）进入 sender 发送线程的 run()方法。

public void run() {
  log.debug("Starting Kafka producer I/O thread.");

  // main loop, runs until close is called
  while (running) {
    try {
      // sender 线程从缓冲区准备拉取数据，刚启动拉不到数据 --> 2⃣️
      runOnce();
    } catch (Exception e) {
      log.error("Uncaught error in kafka producer I/O thread: ", e);
    }
  }
  ...
}

2）runOnce()方法

void runOnce() {
  // 如果是事务操作，按照如下处理
  if (transactionManager != null) {
    try {
      transactionManager.maybeResolveSequences();

      // do not continue sending if the transaction manager is in a failed state
      if (transactionManager.hasFatalError()) {
        RuntimeException lastError = transactionManager.lastError();
        if (lastError != null)
          maybeAbortBatches(lastError);
        // 获取服务器端响应 -->7⃣️
        client.poll(retryBackoffMs, time.milliseconds()); 
        return;
      }

      // Check whether we need a new producerId. If so, we will enqueue an InitProducerId
      // request which will be sent below
      transactionManager.bumpIdempotentEpochAndResetIdIfNeeded();

      if (maybeSendAndPollTransactionalRequest()) {
        return;
      }
    } catch (AuthenticationException e) {
      // This is already logged as error, but propagated here to perform any clean ups.
      log.trace("Authentication exception while processing transactional request", e);
      transactionManager.authenticationFailed(e);
    }
  }

  long currentTimeMs = time.milliseconds();
  // 将准备好的数据发送到服务器端 --> 3⃣️
  long pollTimeout = sendProducerData(currentTimeMs);
  // 获取发送结果
  client.poll(pollTimeout, currentTimeMs);
}

3）获取要发送数据的细节 sendProducerData()

private long sendProducerData(long now) {
  // 获取元数据
  Cluster cluster = metadata.fetch();
  // get the list of partitions with data ready to send
  // 判断32m缓存是否准备好(linger.ms) --> 4⃣️
  RecordAccumulator.ReadyCheckResult result = this.accumulator.ready(cluster, now);

  // 如果Leader信息不知道，是不能发送数据的
  // if there are any partitions whose leaders are not known yet, force metadata update
  if (!result.unknownLeaderTopics.isEmpty()) {
    // The set of topics with unknown leader contains topics with leader election pending as well as
    // topics which may have expired. Add the topic again to metadata to ensure it is included
    // and request metadata update, since there are messages to send to the topic.
    for (String topic : result.unknownLeaderTopics)
      this.metadata.add(topic, now);

    log.debug("Requesting metadata update due to unknown leader topics from the batched records: {}",
              result.unknownLeaderTopics);
    this.metadata.requestUpdate();
  }

  // remove any nodes we aren't ready to send to
  // 删除掉没有准备好发送的数据
  Iterator<Node> iter = result.readyNodes.iterator();
  long notReadyTimeout = Long.MAX_VALUE;
  while (iter.hasNext()) {
    Node node = iter.next();
    if (!this.client.ready(node, now)) {
      iter.remove();
      notReadyTimeout = Math.min(notReadyTimeout, this.client.pollDelayMs(node, now));
    }
  }

  // create produce requests
  // 发往同一个 broker 节点的数据，打包为一个请求批次 --> 5⃣️
  Map<Integer, List<ProducerBatch>> batches = this.accumulator.drain(cluster, result.readyNodes, this.maxRequestSize, now);
  addToInflightBatches(batches);
  if (guaranteeMessageOrder) {
    // Mute all the partitions drained
    for (List<ProducerBatch> batchList : batches.values()) {
      for (ProducerBatch batch : batchList)
        this.accumulator.mutePartition(batch.topicPartition);
    }
  }

  accumulator.resetNextBatchExpiryTime();
  List<ProducerBatch> expiredInflightBatches = getExpiredInflightBatches(now);
  List<ProducerBatch> expiredBatches = this.accumulator.expiredBatches(now);
  expiredBatches.addAll(expiredInflightBatches);

  // Reset the producer id if an expired batch has previously been sent to the broker. Also update the metrics
  // for expired batches. see the documentation of @TransactionState.resetIdempotentProducerId to understand why
  // we need to reset the producer id here.
  if (!expiredBatches.isEmpty())
    log.trace("Expired {} batches in accumulator", expiredBatches.size());
  for (ProducerBatch expiredBatch : expiredBatches) {
    String errorMessage = "Expiring " + expiredBatch.recordCount + " record(s) for " + expiredBatch.topicPartition
      + ":" + (now - expiredBatch.createdMs) + " ms has passed since batch creation";
    failBatch(expiredBatch, new TimeoutException(errorMessage), false);
    if (transactionManager != null && expiredBatch.inRetry()) {
      // This ensures that no new batches are drained until the current in flight batches are fully resolved.
      transactionManager.markSequenceUnresolved(expiredBatch);
    }
  }
  sensors.updateProduceRequestMetrics(batches);

  // If we have any nodes that are ready to send + have sendable data, poll with 0 timeout so this can immediately
  // loop and try sending more data. Otherwise, the timeout will be the smaller value between next batch expiry
  // time, and the delay time for checking data availability. Note that the nodes may have data that isn't yet
  // sendable due to lingering, backing off, etc. This specifically does not include nodes with sendable data
  // that aren't ready to send since they would cause busy looping.
  long pollTimeout = Math.min(result.nextReadyCheckDelayMs, notReadyTimeout);
  pollTimeout = Math.min(pollTimeout, this.accumulator.nextExpiryTimeMs() - now);
  pollTimeout = Math.max(pollTimeout, 0);
  if (!result.readyNodes.isEmpty()) {
    log.trace("Nodes with data ready to send: {}", result.readyNodes);
    // if some partitions are already ready to be sent, the select time would be 0;
    // otherwise if some partition already has some data accumulated but not ready yet,
    // the select time will be the time difference between now and its linger expiry time;
    // otherwise the select time will be the time difference between now and the metadata expiry time;
    pollTimeout = 0;
  }
  // 发送请求 --> 6⃣️
  sendProduceRequests(batches, now);
  return pollTimeout;
}

4）判断32m缓存是否准备好

public ReadyCheckResult ready(Cluster cluster, long nowMs) {
  Set<Node> readyNodes = new HashSet<>();
  long nextReadyCheckDelayMs = Long.MAX_VALUE;
  Set<String> unknownLeaderTopics = new HashSet<>();

  boolean exhausted = this.free.queued() > 0;
  for (Map.Entry<TopicPartition, Deque<ProducerBatch>> entry : this.batches.entrySet()) {
    Deque<ProducerBatch> deque = entry.getValue();
    synchronized (deque) {
      // When producing to a large number of partitions, this path is hot and deques are often empty.
      // We check whether a batch exists first to avoid the more expensive checks whenever possible.
      ProducerBatch batch = deque.peekFirst();
      if (batch != null) {
        TopicPartition part = entry.getKey();
        Node leader = cluster.leaderFor(part);
        if (leader == null) {
          // This is a partition for which leader is not known, but messages are available to send.
          // Note that entries are currently not removed from batches when deque is empty.
          unknownLeaderTopics.add(part.topic());
        } else if (!readyNodes.contains(leader) && !isMuted(part)) {
          long waitedTimeMs = batch.waitedTimeMs(nowMs);
          // 如果不是第一次拉取，  且等待时间小于重试时间 默认100ms ,backingOff=true
          boolean backingOff = batch.attempts() > 0 && waitedTimeMs < retryBackoffMs;
          // 如果backingOff是true 取retryBackoffMs； 如果不是第一次拉取取lingerMs，默认0
          long timeToWaitMs = backingOff ? retryBackoffMs : lingerMs;
          // 批次大小满足发送条件
          boolean full = deque.size() > 1 || batch.isFull();
          // 如果等待的时间超过了 timeToWaitMs，expired=true，表示可以发送数据
          boolean expired = waitedTimeMs >= timeToWaitMs;
          boolean transactionCompleting = transactionManager != null && transactionManager.isCompleting();
          // full linger.ms
          boolean sendable = full
            || expired
            || exhausted
            || closed
            || flushInProgress()
            || transactionCompleting;
          if (sendable && !backingOff) {
            readyNodes.add(leader);
          } else {
            long timeLeftMs = Math.max(timeToWaitMs - waitedTimeMs, 0);
            // Note that this results in a conservative estimate since an un-sendable partition may have
            // a leader that will later be found to have sendable data. However, this is good enough
            // since we'll just wake up and then sleep again for the remaining time.
            nextReadyCheckDelayMs = Math.min(timeLeftMs, nextReadyCheckDelayMs);
          }
        }
      }
    }
  }
  return new ReadyCheckResult(readyNodes, nextReadyCheckDelayMs, unknownLeaderTopics);
}

5）发往同一个 broker 节点的数据，打包为一个请求批次。

public Map<Integer, List<ProducerBatch>> drain(Cluster cluster, Set<Node> nodes, int maxSize, long now) {
  if (nodes.isEmpty())
    return Collections.emptyMap();

  Map<Integer, List<ProducerBatch>> batches = new HashMap<>();
  for (Node node : nodes) {
    List<ProducerBatch> ready = drainBatchesForOneNode(cluster, node, maxSize, now);
    batches.put(node.id(), ready);
  }
  return batches;
}

6）发送请求

private void sendProduceRequest(long now, int destination, short acks, int timeout, List<ProducerBatch> batches) {
  if (batches.isEmpty())
    return;

  final Map<TopicPartition, ProducerBatch> recordsByPartition = new HashMap<>(batches.size());

  // find the minimum magic version used when creating the record sets
  byte minUsedMagic = apiVersions.maxUsableProduceMagic();
  for (ProducerBatch batch : batches) {
    if (batch.magic() < minUsedMagic)
      minUsedMagic = batch.magic();
  }
  ProduceRequestData.TopicProduceDataCollection tpd = new ProduceRequestData.TopicProduceDataCollection();
  for (ProducerBatch batch : batches) {
    TopicPartition tp = batch.topicPartition;
    MemoryRecords records = batch.records();

    // down convert if necessary to the minimum magic used. In general, there can be a delay between the time
    // that the producer starts building the batch and the time that we send the request, and we may have
    // chosen the message format based on out-dated metadata. In the worst case, we optimistically chose to use
    // the new message format, but found that the broker didn't support it, so we need to down-convert on the
    // client before sending. This is intended to handle edge cases around cluster upgrades where brokers may
    // not all support the same message format version. For example, if a partition migrates from a broker
    // which is supporting the new magic version to one which doesn't, then we will need to convert.
    if (!records.hasMatchingMagic(minUsedMagic))
      records = batch.records().downConvert(minUsedMagic, 0, time).records();
    ProduceRequestData.TopicProduceData tpData = tpd.find(tp.topic());
    if (tpData == null) {
      tpData = new ProduceRequestData.TopicProduceData().setName(tp.topic());
      tpd.add(tpData);
    }
    tpData.partitionData().add(new ProduceRequestData.PartitionProduceData()
                               .setIndex(tp.partition())
                               .setRecords(records));
    recordsByPartition.put(tp, batch);
  }

  String transactionalId = null;
  if (transactionManager != null && transactionManager.isTransactional()) {
    transactionalId = transactionManager.transactionalId();
  }

  ProduceRequest.Builder requestBuilder = ProduceRequest.forMagic(minUsedMagic,
                                                                  new ProduceRequestData()
                                                                  .setAcks(acks)
                                                                  .setTimeoutMs(timeout)
                                                                  .setTransactionalId(transactionalId)
                                                                  .setTopicData(tpd));
  RequestCompletionHandler callback = response -> handleProduceResponse(response, recordsByPartition, time.milliseconds());

  String nodeId = Integer.toString(destination);
  // 创建发送请求对象
  ClientRequest clientRequest = client.newClientRequest(nodeId, requestBuilder, now, acks != 0,
                                                        requestTimeoutMs, callback);
  // 发送请求
  client.send(clientRequest, now);
  log.trace("Sent produce request to {}: {}", nodeId, requestBuilder);
}
---------------------------------------------------------
public void send(ClientRequest request, long now) {
  doSend(request, false, now);
}
---------------------------------------------------------
private void doSend(ClientRequest clientRequest, boolean isInternalRequest, long now, AbstractRequest request) {
  String destination = clientRequest.destination();
  RequestHeader header = clientRequest.makeHeader(request.version());
  if (log.isDebugEnabled()) {
    log.debug("Sending {} request with header {} and timeout {} to node {}: {}",
              clientRequest.apiKey(), header, clientRequest.requestTimeoutMs(), destination, request);
  }
  Send send = request.toSend(header);
  InFlightRequest inFlightRequest = new InFlightRequest(
    clientRequest,
    header,
    isInternalRequest,
    request,
    send,
    now);
  // 添加请求到inflint
  this.inFlightRequests.add(inFlightRequest);
  // 发送数据
  selector.send(new NetworkSend(clientRequest.destination(), send));
}

7）获取服务器端响应

public List<ClientResponse> poll(long timeout, long now) {
  ensureActive();

  if (!abortedSends.isEmpty()) {
    // If there are aborted sends because of unsupported version exceptions or disconnects,
    // handle them immediately without waiting for Selector#poll.
    List<ClientResponse> responses = new ArrayList<>();
    handleAbortedSends(responses);
    completeResponses(responses);
    return responses;
  }

  long metadataTimeout = metadataUpdater.maybeUpdate(now);
  try {
    this.selector.poll(Utils.min(timeout, metadataTimeout, defaultRequestTimeoutMs));
  } catch (IOException e) {
    log.error("Unexpected error during I/O", e);
  }

  // process completed actions
  // 获取发送后的响应
  long updatedNow = this.time.milliseconds();
  List<ClientResponse> responses = new ArrayList<>();
  handleCompletedSends(responses, updatedNow);
  handleCompletedReceives(responses, updatedNow);
  handleDisconnections(responses, updatedNow);
  handleConnections();
  handleInitiateApiVersionRequests(updatedNow);
  handleTimedOutConnections(responses, updatedNow);
  handleTimedOutRequests(responses, updatedNow);
  completeResponses(responses);

  return responses;
}

消费者源码

1）消费者组初始化流程

coordinator：辅助实现消费者组的初始化和分区的分配。

coordinator节点选择=groupid的nashcode值%50(_consumer_offsets的分区数量)_
例如：groupid的hashcodef值=1，1%50=1，那么_consumer_offsets主题的1号分区，在哪个broker上，就选择这个节点的coordinator 作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。

⚠️触发再平衡的两个条件：

每个消费者都会和coordinator保持心跳(默认3s)，一旦超时 (session.timeout.ms=45s)，该消费者会被移除，并触发再平衡;
或者消费者处理消息的时间过长(超过max.poll.interval.ms5分钟)，也会触发再平衡

2）消费流程

创建COnsumerNetworkClient，接收消费者的消费请求sendFetches
ConsumerNetworkClient通过send方法拉去broker中的消息，broker也有相应onSuccess回调方法
把拉去的消息放入completedFetches队列，消费者会按批次拉取数据
反序列化/拦截器/处理数据

消费者初始化

1）查看KafkaConsumer 构造方法

KafkaConsumer(ConsumerConfig config, Deserializer<K> keyDeserializer, Deserializer<V> valueDeserializer) {
  try {
    // 消费组平衡
    GroupRebalanceConfig groupRebalanceConfig = new GroupRebalanceConfig(config,
                                                                         GroupRebalanceConfig.ProtocolType.CONSUMER);
    // 获取消费者组id
    this.groupId = Optional.ofNullable(groupRebalanceConfig.groupId);
    // 客户端id
    this.clientId = config.getString(CommonClientConfigs.CLIENT_ID_CONFIG);

    LogContext logContext;

    // If group.instance.id is set, we will append it to the log context.
    if (groupRebalanceConfig.groupInstanceId.isPresent()) {
      logContext = new LogContext("[Consumer instanceId=" + groupRebalanceConfig.groupInstanceId.get() +
                                  ", clientId=" + clientId + ", groupId=" + groupId.orElse("null") + "] ");
    } else {
      logContext = new LogContext("[Consumer clientId=" + clientId + ", groupId=" + groupId.orElse("null") + "] ");
    }

    this.log = logContext.logger(getClass());
    boolean enableAutoCommit = config.maybeOverrideEnableAutoCommit();
    groupId.ifPresent(groupIdStr -> {
      if (groupIdStr.isEmpty()) {
        log.warn("Support for using the empty group id by consumers is deprecated and will be removed in the next major release.");
      }
    });

    log.debug("Initializing the Kafka consumer");
    // 客户端请求服务端等待时间request.timeout.ms 默认是30s
    this.requestTimeoutMs = config.getInt(ConsumerConfig.REQUEST_TIMEOUT_MS_CONFIG);
    this.defaultApiTimeoutMs = config.getInt(ConsumerConfig.DEFAULT_API_TIMEOUT_MS_CONFIG);
    this.time = Time.SYSTEM;
    this.metrics = buildMetrics(config, time, clientId);
    // 重试时间 100
    this.retryBackoffMs = config.getLong(ConsumerConfig.RETRY_BACKOFF_MS_CONFIG);

    // 拦截器配置
    List<ConsumerInterceptor<K, V>> interceptorList = (List) config.getConfiguredInstances(
      ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
      ConsumerInterceptor.class,
      Collections.singletonMap(ConsumerConfig.CLIENT_ID_CONFIG, clientId));
    this.interceptors = new ConsumerInterceptors<>(interceptorList);
    // key和value 的反序列化
    if (keyDeserializer == null) {
      this.keyDeserializer = config.getConfiguredInstance(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, Deserializer.class);
      this.keyDeserializer.configure(config.originals(Collections.singletonMap(ConsumerConfig.CLIENT_ID_CONFIG, clientId)), true);
    } else {
      config.ignore(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG);
      this.keyDeserializer = keyDeserializer;
    }
    if (valueDeserializer == null) {
      this.valueDeserializer = config.getConfiguredInstance(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, Deserializer.class);
      this.valueDeserializer.configure(config.originals(Collections.singletonMap(ConsumerConfig.CLIENT_ID_CONFIG, clientId)), false);
    } else {
      config.ignore(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG);
      this.valueDeserializer = valueDeserializer;
    }
    // offset从什么位置开始消费 默认，latest
    OffsetResetStrategy offsetResetStrategy = OffsetResetStrategy.valueOf(config.getString(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG).toUpperCase(Locale.ROOT));
    this.subscriptions = new SubscriptionState(logContext, offsetResetStrategy);
    ClusterResourceListeners clusterResourceListeners = configureClusterResourceListeners(keyDeserializer,
                                                                                          valueDeserializer, metrics.reporters(), interceptorList);
    // 元数据
    // retryBackoffMs 重试时间
    // 是否允许访问系统主题 exclude.internal.topics  默认是true，表示不允许
    // 是否允许自动创建topic  allow.auto.create.topics 默认是true
    this.metadata = new ConsumerMetadata(retryBackoffMs,
                                         config.getLong(ConsumerConfig.METADATA_MAX_AGE_CONFIG),
                                         !config.getBoolean(ConsumerConfig.EXCLUDE_INTERNAL_TOPICS_CONFIG),
                                         config.getBoolean(ConsumerConfig.ALLOW_AUTO_CREATE_TOPICS_CONFIG),
                                         subscriptions, logContext, clusterResourceListeners);
    // 连接kafka集群
    List<InetSocketAddress> addresses = ClientUtils.parseAndValidateAddresses(
      config.getList(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG), config.getString(ConsumerConfig.CLIENT_DNS_LOOKUP_CONFIG));
    this.metadata.bootstrap(addresses);
    String metricGrpPrefix = "consumer";

    FetcherMetricsRegistry metricsRegistry = new FetcherMetricsRegistry(Collections.singleton(CLIENT_ID_METRIC_TAG), metricGrpPrefix);
    ChannelBuilder channelBuilder = ClientUtils.createChannelBuilder(config, time, logContext);
    this.isolationLevel = IsolationLevel.valueOf(
      config.getString(ConsumerConfig.ISOLATION_LEVEL_CONFIG).toUpperCase(Locale.ROOT));
    Sensor throttleTimeSensor = Fetcher.throttleTimeSensor(metrics, metricsRegistry);
    // 心跳时间,默认3s
    int heartbeatIntervalMs = config.getInt(ConsumerConfig.HEARTBEAT_INTERVAL_MS_CONFIG);

    ApiVersions apiVersions = new ApiVersions();
    // 创建客户端对象
    // 连接重试时间 默认50ms
    // 最大连接重试时间 默认1s
    // 发送缓存 默认128kb
    // 接收缓存  默认64kb
    // 客户端请求服务端等待时间request.timeout.ms 默认是30s
    NetworkClient netClient = new NetworkClient(
      new Selector(config.getLong(ConsumerConfig.CONNECTIONS_MAX_IDLE_MS_CONFIG), metrics, time, metricGrpPrefix, channelBuilder, logContext),
      this.metadata,
      clientId,
      100, // a fixed large enough value will suffice for max in-flight requests
      config.getLong(ConsumerConfig.RECONNECT_BACKOFF_MS_CONFIG),
      config.getLong(ConsumerConfig.RECONNECT_BACKOFF_MAX_MS_CONFIG),
      config.getInt(ConsumerConfig.SEND_BUFFER_CONFIG),
      config.getInt(ConsumerConfig.RECEIVE_BUFFER_CONFIG),
      config.getInt(ConsumerConfig.REQUEST_TIMEOUT_MS_CONFIG),
      config.getLong(ConsumerConfig.SOCKET_CONNECTION_SETUP_TIMEOUT_MS_CONFIG),
      config.getLong(ConsumerConfig.SOCKET_CONNECTION_SETUP_TIMEOUT_MAX_MS_CONFIG),
      time,
      true,
      apiVersions,
      throttleTimeSensor,
      logContext);
    // 消费者客户端
    // 客户端请求服务端等待时间request.timeout.ms 默认是30s
    this.client = new ConsumerNetworkClient(
      logContext,
      netClient,
      metadata,
      time,
      retryBackoffMs,
      config.getInt(ConsumerConfig.REQUEST_TIMEOUT_MS_CONFIG),
      heartbeatIntervalMs); //Will avoid blocking an extended period of time to prevent heartbeat thread starvation
    // 获取消费者分区分配策略
    this.assignors = ConsumerPartitionAssignor.getAssignorInstances(
      config.getList(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG),
      config.originals(Collections.singletonMap(ConsumerConfig.CLIENT_ID_CONFIG, clientId))
    );

    // no coordinator will be constructed for the default (null) group id
    // 创建消费者协调器
    // auto.commit.interval.ms  自动提交offset时间 默认5s
    this.coordinator = !groupId.isPresent() ? null :
    new ConsumerCoordinator(groupRebalanceConfig,
                            logContext,
                            this.client,
                            assignors,
                            this.metadata,
                            this.subscriptions,
                            metrics,
                            metricGrpPrefix,
                            this.time,
                            enableAutoCommit,
                            config.getInt(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG),
                            this.interceptors,
                            config.getBoolean(ConsumerConfig.THROW_ON_FETCH_STABLE_OFFSET_UNSUPPORTED));
    // 配置抓数据的参数
    // fetch.min.bytes 默认最少一次抓取1个字节
    // fetch.max.bytes 默认最多一次抓取50m
    // fetch.max.wait.ms 抓取等待最大时间 500ms
    // max.partition.fetch.bytes 默认是1m
    // max.poll.records  默认一次处理500条
    // key 和 value 的反序列化
    this.fetcher = new Fetcher<>(
      logContext,
      this.client,
      config.getInt(ConsumerConfig.FETCH_MIN_BYTES_CONFIG),
      config.getInt(ConsumerConfig.FETCH_MAX_BYTES_CONFIG),
      config.getInt(ConsumerConfig.FETCH_MAX_WAIT_MS_CONFIG),
      config.getInt(ConsumerConfig.MAX_PARTITION_FETCH_BYTES_CONFIG),
      config.getInt(ConsumerConfig.MAX_POLL_RECORDS_CONFIG),
      config.getBoolean(ConsumerConfig.CHECK_CRCS_CONFIG),
      config.getString(ConsumerConfig.CLIENT_RACK_CONFIG),
      this.keyDeserializer,
      this.valueDeserializer,
      this.metadata,
      this.subscriptions,
      metrics,
      metricsRegistry,
      this.time,
      this.retryBackoffMs,
      this.requestTimeoutMs,
      isolationLevel,
      apiVersions);

    this.kafkaConsumerMetrics = new KafkaConsumerMetrics(metrics, metricGrpPrefix);

    config.logUnused();
    AppInfoParser.registerAppInfo(JMX_PREFIX, clientId, metrics, time.milliseconds());
    log.debug("Kafka consumer initialized");
  } catch (Throwable t) {
    // call close methods if internal objects are already constructed; this is to prevent resource leak. see KAFKA-2121
    // we do not need to call `close` at all when `log` is null, which means no internal objects were initialized.
    if (this.log != null) {
      close(0, true);
    }
    // now propagate the exception
    throw new KafkaException("Failed to construct kafka consumer", t);
  }
}

消费者订阅主题

1）KafkaConsumer.subscribe(Collection<String> topics, ConsumerRebalanceListener listener)

public void subscribe(Collection<String> topics, ConsumerRebalanceListener listener) {
  acquireAndEnsureOpen();
  try {
    maybeThrowInvalidGroupIdException();
    // 要订阅的主题如果为null ，直接抛异常
    if (topics == null)
      throw new IllegalArgumentException("Topic collection to subscribe to cannot be null");
    // 要订阅的主题如果为空
    if (topics.isEmpty()) {
      // treat subscribing to empty topic list as the same as unsubscribing
      this.unsubscribe();
    } else {
      // 正常的处理操作
      for (String topic : topics) {
        // 如果为空  抛异常
        if (Utils.isBlank(topic))
          throw new IllegalArgumentException("Topic collection to subscribe to cannot contain null or empty topic");
      }

      throwIfNoAssignorsConfigured();
      // 清空订阅异常主题的缓存数据
      fetcher.clearBufferedDataForUnassignedTopics(topics);
      log.info("Subscribed to topic(s): {}", Utils.join(topics, ", "));
      // 判断是否需要更改订阅主题，如果需要更改主题，则更新元数据信息（主题了一个监听器listener） --> 2⃣️
      if (this.subscriptions.subscribe(new HashSet<>(topics), listener))
        // 更新订阅信息 --> 3⃣️
        metadata.requestUpdateForNewTopics();
    }
  } finally {
    release();
  }
}

2）SubscriptionState.subscribe(Set<String> topics, ConsumerRebalanceListener listener)

public synchronized boolean subscribe(Set<String> topics, ConsumerRebalanceListener listener) {
  // 注册负载均衡监听器
  registerRebalanceListener(listener);
  // 按照主题自动订阅模式
  setSubscriptionType(SubscriptionType.AUTO_TOPICS);
  // 判断是否需要更改订阅的主题
  return changeSubscription(topics);
}
---------------------------------------------------------
private boolean changeSubscription(Set<String> topicsToSubscribe) {
  // 如果传入的topics 和以前订阅的主题一致，那就不需要更改对应订阅的主题
  if (subscription.equals(topicsToSubscribe))
    return false;

  subscription = topicsToSubscribe;
  return true;
}

3）如果订阅的和以前不一致，需要更新元数据信息

public synchronized int requestUpdateForNewTopics() {
  // Override the timestamp of last refresh to let immediate update.
  this.lastRefreshMs = 0;
  this.needPartialUpdate = true;
  this.requestVersion++;
  return this.updateVersion;
}

消费者拉取和处理数据

1）KafkaConsumer.poll()

public ConsumerRecords<K, V> poll(final Duration timeout) {
  return poll(time.timer(timeout), true);
}

private ConsumerRecords<K, V> poll(final Timer timer, final boolean includeMetadataInTimeout) {
  acquireAndEnsureOpen();
  try {
    // 记录开始拉取消息时间
    this.kafkaConsumerMetrics.recordPollStart(timer.currentTimeMs());

    if (this.subscriptions.hasNoSubscriptionOrUserAssignment()) {
      throw new IllegalStateException("Consumer is not subscribed to any topics or assigned any partitions");
    }

    do {
      client.maybeTriggerWakeup();

      if (includeMetadataInTimeout) {
        // 消费者或者消费者组的初始化 --> 2⃣️
        // try to update assignment metadata BUT do not need to block on the timer for join group
        updateAssignmentMetadataIfNeeded(timer, false);
      } else {
        while (!updateAssignmentMetadataIfNeeded(time.timer(Long.MAX_VALUE), true)) {
          log.warn("Still waiting for metadata");
        }
      }
      // 抓取数据 --> 3⃣️
      final Map<TopicPartition, List<ConsumerRecord<K, V>>> records = pollForFetches(timer);
      if (!records.isEmpty()) {
        // before returning the fetched records, we can send off the next round of fetches
        // and avoid block waiting for their responses to enable pipelining while the user
        // is handling the fetched records.
        //
        // NOTE: since the consumed position has already been updated, we must not allow
        // wakeups or any other errors to be triggered prior to returning the fetched records.
        if (fetcher.sendFetches() > 0 || client.hasPendingRequests()) {
          client.transmitSends();
        }
        // 拦截器处理数据 --> 4⃣️
        return this.interceptors.onConsume(new ConsumerRecords<>(records));
      }
    } while (timer.notExpired());

    return ConsumerRecords.empty();
  } finally {
    release();
    this.kafkaConsumerMetrics.recordPollEnd(timer.currentTimeMs());
  }
}

2）消费者组初始化流程

boolean updateAssignmentMetadataIfNeeded(final Timer timer, final boolean waitForJoinGroup) {
  if (coordinator != null && !coordinator.poll(timer, waitForJoinGroup)) {
    return false;
  }

  return updateFetchPositions(timer);
}
---------------------------------------------------------
public boolean poll(Timer timer, boolean waitForJoinGroup) {
  // 获取最新元数据
  maybeUpdateSubscriptionMetadata();

  invokeCompletedOffsetCommitCallbacks();

  if (subscriptions.hasAutoAssignedPartitions()) {
    // 如果没有指定分区分配策略  直接抛异常
    if (protocol == null) {
      throw new IllegalStateException("User configured " + ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG +
                                      " to empty while trying to subscribe for group protocol to auto assign partitions");
    }
    // Always update the heartbeat last poll time so that the heartbeat thread does not leave the
    // group proactively due to application inactivity even if (say) the coordinator cannot be found.
    // 3s心跳
    pollHeartbeat(timer.currentTimeMs());
    // ⭐️保证和Coordinator正常通信(寻找服务器端的coordinator)
    if (coordinatorUnknown() && !ensureCoordinatorReady(timer)) {
      return false;
    }

    // 判断是否需要加入消费者组
    if (rejoinNeededOrPending()) {
      if (subscriptions.hasPatternSubscription()) {
        if (this.metadata.timeToAllowUpdate(timer.currentTimeMs()) == 0) {
          this.metadata.requestUpdate();
        }

        if (!client.ensureFreshMetadata(timer)) {
          return false;
        }
        maybeUpdateSubscriptionMetadata();
      }
      if (!ensureActiveGroup(waitForJoinGroup ? timer : time.timer(0L))) {
        timer.update(time.milliseconds());
        return false;
      }
    }
  } else {
    if (metadata.updateRequested() && !client.hasReadyNodes(timer.currentTimeMs())) {
      client.awaitMetadataUpdate(timer);
    }
  }

  // 是否自动提交offset
  maybeAutoCommitOffsetsAsync(timer.currentTimeMs());
  return true;
}
---------------------------------------------------------
protected synchronized boolean ensureCoordinatorReady(final Timer timer) {
  // 如果找到coordinator，直接返回
  if (!coordinatorUnknown())
    return true;

  // 如果没有找到，循环给服务器端发送请求，直到找到coordinator
  do {
    if (fatalFindCoordinatorException != null) {
      final RuntimeException fatalException = fatalFindCoordinatorException;
      fatalFindCoordinatorException = null;
      throw fatalException;
    }
    // ⭐️创建一个查找Coordinator 的请求 并发送
    final RequestFuture<Void> future = lookupCoordinator();
    // 获取服务器返回的结果
    client.poll(future, timer);

    if (!future.isDone()) {
      // ran out of time
      break;
    }

    RuntimeException fatalException = null;

    if (future.failed()) {
      if (future.isRetriable()) {
        log.debug("Coordinator discovery failed, refreshing metadata", future.exception());
        client.awaitMetadataUpdate(timer);
      } else {
        fatalException = future.exception();
        log.info("FindCoordinator request hit fatal exception", fatalException);
      }
    } else if (coordinator != null && client.isUnavailable(coordinator)) {
      // we found the coordinator, but the connection has failed, so mark
      // it dead and backoff before retrying discovery
      markCoordinatorUnknown("coordinator unavailable");
      timer.sleep(rebalanceConfig.retryBackoffMs);
    }

    clearFindCoordinatorFuture();
    if (fatalException != null)
      throw fatalException;
  } while (coordinatorUnknown() && timer.notExpired());

  return !coordinatorUnknown();
}
---------------------------------------------------------
protected synchronized RequestFuture<Void> lookupCoordinator() {
  if (findCoordinatorFuture == null) {
    // find a node to ask about the coordinator
    Node node = this.client.leastLoadedNode();
    if (node == null) {
      log.debug("No broker available to send FindCoordinator request");
      return RequestFuture.noBrokersAvailable();
    } else {
      // ⭐️有节点接收查找Coordinator请求
      findCoordinatorFuture = sendFindCoordinatorRequest(node);
    }
  }
  return findCoordinatorFuture;
}
---------------------------------------------------------
private RequestFuture<Void> sendFindCoordinatorRequest(Node node) {
  // initiate the group metadata request
  log.debug("Sending FindCoordinator request to broker {}", node);

  // 创建发送Coordinator 请求数据信息
  FindCoordinatorRequestData data = new FindCoordinatorRequestData()
    .setKeyType(CoordinatorType.GROUP.id())
    .setKey(this.rebalanceConfig.groupId);

  // 进一步封装
  FindCoordinatorRequest.Builder requestBuilder = new FindCoordinatorRequest.Builder(data);

  return client.send(node, requestBuilder)
    .compose(new FindCoordinatorResponseHandler());
}

3）拉取数据

private Map<TopicPartition, List<ConsumerRecord<K, V>>> pollForFetches(Timer timer) {
  long pollTimeout = coordinator == null ? timer.remainingMs() :
  Math.min(coordinator.timeToNextPoll(timer.currentTimeMs()), timer.remainingMs());

  // if data is available already, return it immediately
  // 第一次拉取不到数据
  final Map<TopicPartition, List<ConsumerRecord<K, V>>> records = fetcher.fetchedRecords();
  if (!records.isEmpty()) {
    return records;
  }

  // send any new fetches (won't resend pending fetches)
  // ⭐️发送请求并抓取数据
  fetcher.sendFetches();

  // We do not want to be stuck blocking in poll if we are missing some positions
  // since the offset lookup may be backing off after a failure

  // NOTE: the use of cachedSubscriptionHashAllFetchPositions means we MUST call
  // updateAssignmentMetadataIfNeeded before this method.
  if (!cachedSubscriptionHashAllFetchPositions && pollTimeout > retryBackoffMs) {
    pollTimeout = retryBackoffMs;
  }

  log.trace("Polling for fetches with timeout {}", pollTimeout);

  Timer pollTimer = time.timer(pollTimeout);
  client.poll(pollTimer, () -> {
    // since a fetch might be completed by the background thread, we need this poll condition
    // to ensure that we do not block unnecessarily in poll()
    return !fetcher.hasAvailableFetches();
  });
  timer.update(pollTimer.currentTimeMs());

  // ⭐️把数据按照分区封装好后，一次处理默认 500 条数据
  return fetcher.fetchedRecords();
}

---------------------------------------------------------
// 发送请求并抓取数据
public synchronized int sendFetches() {
  // Update metrics in case there was an assignment change
  sensors.maybeUpdateAssignment(subscriptions);

  Map<Node, FetchSessionHandler.FetchRequestData> fetchRequestMap = prepareFetchRequests();
  for (Map.Entry<Node, FetchSessionHandler.FetchRequestData> entry : fetchRequestMap.entrySet()) {
    final Node fetchTarget = entry.getKey();
    final FetchSessionHandler.FetchRequestData data = entry.getValue();

    // maxWaitMs 默认是500ms
    // minBytes 最少一次抓取1个字节
    // maxBytes 最多一次抓取多少数据  默认50m
    final FetchRequest.Builder request = FetchRequest.Builder
      .forConsumer(this.maxWaitMs, this.minBytes, data.toSend())
      .isolationLevel(isolationLevel)
      .setMaxBytes(this.maxBytes)
      .metadata(data.metadata())
      .toForget(data.toForget())
      .rackId(clientRackId);

    if (log.isDebugEnabled()) {
      log.debug("Sending {} {} to broker {}", isolationLevel, data.toString(), fetchTarget);
    }
    // 发送拉取数据请求
    RequestFuture<ClientResponse> future = client.send(fetchTarget, request);

    this.nodesWithPendingFetchRequests.add(entry.getKey().id());
    // 监听服务器端返回的数据
    future.addListener(new RequestFutureListener<ClientResponse>() {
      @Override
      public void onSuccess(ClientResponse resp) {
        // 成功接收服务器端数据
        synchronized (Fetcher.this) {
          try {
            // 获取服务器端响应数据
            FetchResponse response = (FetchResponse) resp.responseBody();
            FetchSessionHandler handler = sessionHandler(fetchTarget.id());
            if (handler == null) {
              log.error("Unable to find FetchSessionHandler for node {}. Ignoring fetch response.",
                        fetchTarget.id());
              return;
            }
            if (!handler.handleResponse(response)) {
              return;
            }

            Set<TopicPartition> partitions = new HashSet<>(response.responseData().keySet());
            FetchResponseMetricAggregator metricAggregator = new FetchResponseMetricAggregator(sensors, partitions);

            for (Map.Entry<TopicPartition, FetchResponseData.PartitionData> entry : response.responseData().entrySet()) {
              TopicPartition partition = entry.getKey();
              FetchRequest.PartitionData requestData = data.sessionPartitions().get(partition);
              if (requestData == null) {
                String message;
                if (data.metadata().isFull()) {
                  message = MessageFormatter.arrayFormat(
                    "Response for missing full request partition: partition={}; metadata={}",
                    new Object[]{partition, data.metadata()}).getMessage();
                } else {
                  message = MessageFormatter.arrayFormat(
                    "Response for missing session request partition: partition={}; metadata={}; toSend={}; toForget={}",
                    new Object[]{partition, data.metadata(), data.toSend(), data.toForget()}).getMessage();
                }

                // Received fetch response for missing session partition
                throw new IllegalStateException(message);
              } else {
                long fetchOffset = requestData.fetchOffset;
                FetchResponseData.PartitionData partitionData = entry.getValue();

                log.debug("Fetch {} at offset {} for partition {} returned fetch data {}",
                          isolationLevel, fetchOffset, partition, partitionData);

                Iterator<? extends RecordBatch> batches = FetchResponse.recordsOrFail(partitionData).batches().iterator();
                short responseVersion = resp.requestHeader().apiVersion();

                // 把数据按照分区，添加到消息队列里面
                completedFetches.add(new CompletedFetch(partition, partitionData,
                                                        metricAggregator, batches, fetchOffset, responseVersion));
              }
            }

            sensors.fetchLatency.record(resp.requestLatencyMs());
          } finally {
            nodesWithPendingFetchRequests.remove(fetchTarget.id());
          }
        }
      }

      @Override
      public void onFailure(RuntimeException e) {
        synchronized (Fetcher.this) {
          try {
            FetchSessionHandler handler = sessionHandler(fetchTarget.id());
            if (handler != null) {
              handler.handleError(e);
            }
          } finally {
            nodesWithPendingFetchRequests.remove(fetchTarget.id());
          }
        }
      }
    });

  }
  return fetchRequestMap.size();
}

---------------------------------------------------------
// 把数据按照分区封装好后，一次处理最大条数默认 500 条数据
public Map<TopicPartition, List<ConsumerRecord<K, V>>> fetchedRecords() {
  Map<TopicPartition, List<ConsumerRecord<K, V>>> fetched = new HashMap<>();
  Queue<CompletedFetch> pausedCompletedFetches = new ArrayDeque<>();
  // 每次处理的最多条数是500条
  int recordsRemaining = maxPollRecords;

  try {
    while (recordsRemaining > 0) {
      if (nextInLineFetch == null || nextInLineFetch.isConsumed) {
        // 从缓存中获取数据
        CompletedFetch records = completedFetches.peek();
        // 如果没有数据了 可以退出循环
        if (records == null) break;

        if (records.notInitialized()) {
          try {
            nextInLineFetch = initializeCompletedFetch(records);
          } catch (Exception e) {
            FetchResponseData.PartitionData partition = records.partitionData;
            if (fetched.isEmpty() && FetchResponse.recordsOrFail(partition).sizeInBytes() == 0) {
              completedFetches.poll();
            }
            throw e;
          }
        } else {
          nextInLineFetch = records;
        }
        // 从缓存中拉取数据
        completedFetches.poll();
      } else if (subscriptions.isPaused(nextInLineFetch.partition)) {
        log.debug("Skipping fetching records for assigned partition {} because it is paused", nextInLineFetch.partition);
        pausedCompletedFetches.add(nextInLineFetch);
        nextInLineFetch = null;
      } else {
        List<ConsumerRecord<K, V>> records = fetchRecords(nextInLineFetch, recordsRemaining);

        if (!records.isEmpty()) {
          TopicPartition partition = nextInLineFetch.partition;
          List<ConsumerRecord<K, V>> currentRecords = fetched.get(partition);
          if (currentRecords == null) {
            fetched.put(partition, records);
          } else {
            List<ConsumerRecord<K, V>> newRecords = new ArrayList<>(records.size() + currentRecords.size());
            newRecords.addAll(currentRecords);
            newRecords.addAll(records);
            fetched.put(partition, newRecords);
          }
          recordsRemaining -= records.size();
        }
      }
    }
  } catch (KafkaException e) {
    if (fetched.isEmpty())
      throw e;
  } finally {
    // add any polled completed fetches for paused partitions back to the completed fetches queue to be
    // re-evaluated in the next poll
    completedFetches.addAll(pausedCompletedFetches);
  }

  return fetched;
}

4）拦截器处理数据

public ConsumerRecords<K, V> onConsume(ConsumerRecords<K, V> records) {
  ConsumerRecords<K, V> interceptRecords = records;
  for (ConsumerInterceptor<K, V> interceptor : this.interceptors) {
    try {
      // 每个拦截器都会对数据进行加工
      interceptRecords = interceptor.onConsume(interceptRecords);
    } catch (Exception e) {
      // do not propagate interceptor exception, log and continue calling other interceptors
      log.warn("Error executing interceptor onConsume callback", e);
    }
  }
  return interceptRecords;
}

消费者 Offset 提交

手动同步提交

1）commitSync()

public void commitSync(final Map<TopicPartition, OffsetAndMetadata> offsets, final Duration timeout) {
  acquireAndEnsureOpen();
  try {
    maybeThrowInvalidGroupIdException();
    offsets.forEach(this::updateLastSeenEpochIfNewer);
    // 同步提交 --> 2⃣️
    if (!coordinator.commitOffsetsSync(new HashMap<>(offsets), time.timer(timeout))) {
      throw new TimeoutException("Timeout of " + timeout.toMillis() + "ms expired before successfully " +
                                 "committing offsets " + offsets);
    }
  } finally {
    release();
  }
}

2）commitOffsetsSync()

public boolean commitOffsetsSync(Map<TopicPartition, OffsetAndMetadata> offsets, Timer timer) {
  invokeCompletedOffsetCommitCallbacks();

  if (offsets.isEmpty())
    return true;

  do {
    if (coordinatorUnknown() && !ensureCoordinatorReady(timer)) {
      return false;
    }

    // 发送提交请求
    RequestFuture<Void> future = sendOffsetCommitRequest(offsets);
    client.poll(future, timer);

    // We may have had in-flight offset commits when the synchronous commit began. If so, ensure that
    // the corresponding callbacks are invoked prior to returning in order to preserve the order that
    // the offset commits were applied.
    invokeCompletedOffsetCommitCallbacks();

    // 提交成功
    if (future.succeeded()) {
      if (interceptors != null)
        interceptors.onCommit(offsets);
      return true;
    }

    if (future.failed() && !future.isRetriable())
      throw future.exception();

    timer.sleep(rebalanceConfig.retryBackoffMs);
  } while (timer.notExpired());

  return false;
}

手动异步提交

1）commitAsync()

public void commitAsync(final Map<TopicPartition, OffsetAndMetadata> offsets, OffsetCommitCallback callback) {
  acquireAndEnsureOpen();
  try {
    maybeThrowInvalidGroupIdException();
    log.debug("Committing offsets: {}", offsets);
    offsets.forEach(this::updateLastSeenEpochIfNewer);
    // 提交offset --> 2⃣️
    coordinator.commitOffsetsAsync(new HashMap<>(offsets), callback);
  } finally {
    release();
  }
}

2）commitOffsetsAsync()

public void commitOffsetsAsync(final Map<TopicPartition, OffsetAndMetadata> offsets, final OffsetCommitCallback callback) {
  invokeCompletedOffsetCommitCallbacks();

  if (!coordinatorUnknown()) {
    doCommitOffsetsAsync(offsets, callback);
  } else {
    // we don't know the current coordinator, so try to find it and then send the commit
    // or fail (we don't want recursive retries which can cause offset commits to arrive
    // out of order). Note that there may be multiple offset commits chained to the same
    // coordinator lookup request. This is fine because the listeners will be invoked in
    // the same order that they were added. Note also that AbstractCoordinator prevents
    // multiple concurrent coordinator lookup requests.
    pendingAsyncCommits.incrementAndGet();
    // 监听提交 offset 的结果
    lookupCoordinator().addListener(new RequestFutureListener<Void>() {
      @Override
      public void onSuccess(Void value) {
        pendingAsyncCommits.decrementAndGet();
        doCommitOffsetsAsync(offsets, callback);
        client.pollNoWakeup();
      }

      @Override
      public void onFailure(RuntimeException e) {
        pendingAsyncCommits.decrementAndGet();
        completedOffsetCommits.add(new OffsetCommitCompletion(callback, offsets,
                                                              new RetriableCommitFailedException(e)));
      }
    });
  }

  // ensure the commit has a chance to be transmitted (without blocking on its completion).
  // Note that commits are treated as heartbeats by the coordinator, so there is no need to
  // explicitly allow heartbeats through delayed task execution.
  client.pollNoWakeup();
}

服务器源码

1）程序的入口 Kafka.scala

def main(args: Array[String]): Unit = {
  try {
    // 获取相关参数
    val serverProps = getPropsFromArgs(args)
    // 创建服务
    val server = buildServer(serverProps)

    try {
      if (!OperatingSystem.IS_WINDOWS && !Java.isIbmJdk)
      new LoggingSignalHandler().register()
    } catch {
      case e: ReflectiveOperationException =>
      warn("Failed to register optional signal handler that logs a message when the process is terminated " +
           s"by a signal. Reason for registration failure is: $e", e)
    }

    // attach shutdown handler to catch terminating signals as well as normal termination
    Exit.addShutdownHook("kafka-shutdown-hook", {
      try server.shutdown()
      catch {
        case _: Throwable =>
        fatal("Halting Kafka.")
        // Calling exit() can lead to deadlock as exit() can be called multiple times. Force exit.
        Exit.halt(1)
      }
    })

    // 启动服务
    try server.startup()
    catch {
      case _: Throwable =>
      // KafkaServer.startup() calls shutdown() in case of exceptions, so we invoke `exit` to set the status code
      fatal("Exiting Kafka.")
      Exit.exit(1)
    }

    server.awaitShutdown()
  }
  catch {
    case e: Throwable =>
    fatal("Exiting Kafka due to fatal exception", e)
    Exit.exit(1)
  }
  Exit.exit(0)
}

Kafka如何避免消息丢失

Thu, 05 May 2022 08:15:06 +0000

Kafka消息框架通过broke来连接生产者和消费者，但是如果中间的某一个环节出现了故障，就会产生消息丢失的问题。针对消息丢失，我们可以从生产端、broke和消费端三个维度来处理。

生产端

生产端的职责就是，确保生产的消息能到达MQ服务端，这里我们需要有一个响应来判断本次的操作是否成功。

// 该方法会通过一个Callback函数，来判断消息是否发送成功，如果失败，我们需要补偿处理。
Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback)

ACKS

acks=0，只要发送消息就认为成功，生产端不等待服务器节点的响应
acks=1，表示生产者收到 leader 分区的响应才会被认为发送成功
acks=-1(all):生产者发送过来的数据，只有当 ISR 中的副本全部收到消息时，生产端才会认为是成功的。这种配置是最安全的，但由于同步的节点较多，吞吐量会降低。(可靠性高，效率低;在生产环境中，acks=0很少使用;acks=1，一般用于传输普通日志，允许丢个别数据;acks=-1，一般用于传输和钱相关的数据，对可靠性要求比较高的场景)

🤔 当acks=-1时，Leader收到数据，所有Follower都开始同步数据，但有一个Follower，因为某种故障，迟迟不能与Leader进行同步，那这个问题怎么解决呢?

Leader维护了一个动态的in-sync replica set(ISR)，意为和 Leader保持同步的Follower+Leader集合(leader:0，isr:0,1,2)。

如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s。例如2超时，这ISR变为(leader:0, isr:0,1)。这样就不用等长期联系不上或者已经故障的节点。

数据可靠性分析:如果分区副本设置为1个，或者ISR里应答的最小副本数量 ( min.insync.replicas 默认为1)设置为1，和ack=1的效果是一样的，仍然有丢数的风险(leader:0，isr:0)。

因此数据完全可靠条件 = ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2

retries

retries：当消息发送出现错误的时候，系统会重发消息。retries 表示重试次数。默认是 int 最大值，2147483647。如果设置了重试，还想保证消息的有序性，需要设置 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1 否则在重试此失败消息的时候，其他的消息可能发送成功了。

表示生产端的重试次数，如果重试次数用完后，还是失败，会将消息临时存储在本地磁盘，待服务恢复后再重新发送。建议值 retries=3

retry.backoff.ms

retry.backoff.ms：消息发送超时或失败后，两次重试之间的时间间隔，默认是 100ms。

消息重复

当生产端做完这些，一定能保证消息发送成功了，但可能发送多次，这样就会导致消息重复。

Kafka 0.11版本以后，引入了一项重大特性:幂等性。每条消息都有唯一的message id, MQ服务采用空间换时间方式，自动对重复消息过滤处理，保证接口的幂等性。重复数据的判断标准：具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。

PID：Kafka每次重启都会分配一个新的pid
Partition：分区号
Sequence Number：序列号，单调自增

==所以幂等性只能保证的是在单分区单会话内不重复。==

🤔对于消费端，即使MQ服务中存储的消息没有重复，但消费端是采用拉取方式，如果重复拉取，也会导致重复消费，如何解决这种场景问题？

方案一：只拉取一次（消费者拉取消息后，先提交 offset 后再处理消息），但是如果系统宕机，业务处理没有正常结束，后面再也拉取不到这些消息，会导致数据不一致，该方案很少采用。

方案二：允许拉取重复消息，但是消费端自己做幂等性控制。保证只成功消费一次。关于幂等技术方案很多，我们可以采用数据表或Redis缓存存储处理标识，每次拉取到消息，处理前先校验处理状态，再决定是处理还是丢弃消息。

broke

broke作为消息的存储介质，也有可能会丢失消息。比如：一个分区突然挂掉，那么怎么保证这个分区的数据不丢失，我们会引入副本概念，通过备份来解决这个问题，确保数据及时同步到多副本。

replication.factor

表示分区副本的个数，replication.factor >1 当leader 副本挂了，follower副本会被选举为leader继续提供服务。

min.insync.replicas

表示 ISR 最少的副本数量，通常设置 min.insync.replicas >1，这样才有可用的follower副本执行替换，保证消息不丢失

unclean.leader.election.enable

是否可以把非 ISR 集合中的副本选举为 leader 副本。

如果设置为true，而follower副本的同步消息进度落后较多，此时被选举为leader，会导致消息丢失，慎用。

消费端

消费端要做的是把消息完整的消费处理掉。但是这里面有个提交位移的步骤。

有的同学，考虑到业务处理消耗时间较长，会单独启动线程拉取消息存储到本地内存队列，然后再搞个线程池并行处理业务逻辑。这样设计有个风险，本地消息如果没有处理完，服务器宕机了，会造成消息丢失。

==正确的做法：拉取消息 –> 业务处理 –> 提交消费位移==

enable.auto.commit

表示消费位移是否自动提交。

如果拉取了消息，业务逻辑还没处理完，提交了消费位移但是消费端却挂了，消费端恢复或其他消费端接管该分片再也拉取不到这条消息，会造成消息丢失。所以，我们通常设置 enable.auto.commit=false，手动提交消费位移。

不过该方案同样也存在消息重复消费的问题，比如消费者拉取了消息4~消息8，业务处理后，在提交消费位移时，不凑巧系统宕机了，最后的提交位移并没有保存到MQ 服务端，下次拉取消息时，依然是从消息4开始拉取，但是这部分消息已经处理过了，这样便会导致重复消费。

Kafka学习笔记消费者

Thu, 05 May 2022 04:19:06 +0000

Kafka 消费者

消费方式

pull(拉)模式:

consumer采用从broker中主动拉取数据。Kafka采用这种方式。
pull模式不足之处是，如果Kafka没有数据，消费者可能会陷入循环中，一直返回空数据。

push(推)模式:

Kafka没有采用这种方式，因为由broker 决定消息发送速率，很难适应所有消费者的消费速率。例如推送的速度是50m/s， Consumer1、Consumer2就来不及处理消息。

消费者工作流程

1）消费者总体工作流程

2）消费者组

Consumer Group(CG)：消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的groupid相同。

消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内的消费者消费。
消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

如果向消费组中添加更多的消费者，超过主题分区数量，则有一部分消费者就会闲置，不会接收任何消息。

3）消费者组初始化流程

coordinator：辅助实现消费者组的初始化和分区的分配。

coordinator节点选择=groupid的nashcode值%50(_consumer_offsets的分区数量)_
例如：groupid的hashcodef值=1，1%50=1，那么_consumer_offsets主题的1号分区，在哪个broker上，就选择这个节点的coordinator 作为这个消费者组的老大。消费者组下的所有的消费者提交offset的时候就往这个分区去提交offset。

⚠️触发再平衡的两个条件：

每个消费者都会和coordinator保持心跳(默认3s)，一旦超时 (session.timeout.ms=45s)，该消费者会被移除，并触发再平衡;
或者消费者处理消息的时间过长(超过max.poll.interval.ms5分钟)，也会触发再平衡

4）消费流程

创建COnsumerNetworkClient，接收消费者的消费请求sendFetches
ConsumerNetworkClient通过send方法拉去broker中的消息，broker也有相应onSuccess回调方法
把拉去的消息放入completedFetches队列，消费者会按批次拉取数据
反序列化/拦截器/处理数据

消费者API

独立消费者(订阅主题)

需求：创建一个独立消费者，消费 first 主题中数据。

代码：⚠️在消费者 API 代码中必须配置消费者组 id。命令行启动消费者不填写消费者组 id 会被自动填写随机的消费者组 id。

/**
 * 独立消费者案例(订阅主题)
 *
 * @author zhongye
 * @since 2022.05.06
 */
public class CustomConsumer {
  public static void main(String[] args) {
    //0 配置
    Properties properties = new Properties();

    //连接bootstrap.servers
    properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");

    // 反序列化
    properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    // 指定消费者组id
    properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");

    // 1 创建一个消费者 "","hello"
    KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);

    // 2 订阅主题 first
    ArrayList<String> topics = new ArrayList<>();
    topics.add("first");
    kafkaConsumer.subscribe(topics);

    // 3 消费数据
    while (true){
      ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
      for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
        System.out.println(consumerRecord);
      }
    }

  }
}

执行结果：消息由普通异步发送生产

ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 22, CreateTime = 1651833006318, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince0)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 23, CreateTime = 1651833006336, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince1)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 24, CreateTime = 1651833006336, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince2)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 25, CreateTime = 1651833006336, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince3)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 26, CreateTime = 1651833006336, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince4)

独立消费者(订阅分区)

需求：创建一个独立消费者，消费 first 主题下 0 号分区的数据(指定分区消费)。

代码：

/**
 * 消费 first 主题下 0 号分区的数据(指定分区消费)。
 *
 * @author zhongye
 * @since 2022.05.06
 */
public class CustomConsumerPartition {
  public static void main(String[] args) {
    //0 配置
    Properties properties = new Properties();

    //连接bootstrap.servers
    properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");

    // 反序列化
    properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    // 指定消费者组id
    properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");

    // 1 创建一个消费者 "","hello"
    KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);

    // 2 订阅主题对应的分区
    ArrayList<TopicPartition> topics = new ArrayList<>();
    topics.add(new TopicPartition("first",0));
    kafkaConsumer.assign(topics);

    // 3 消费数据
    while (true){
      ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
      for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
        System.out.println(consumerRecord);
      }
    }

  }
}

执行结果：如指定的分区为1，那就不会消费消息(消息由普通异步发送生产)。

ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 32, CreateTime = 1651840032039, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince0)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 33, CreateTime = 1651840032051, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince1)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 34, CreateTime = 1651840032052, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince2)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 35, CreateTime = 1651840032052, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince3)
ConsumerRecord(topic = first, partition = 0, leaderEpoch = 0, offset = 36, CreateTime = 1651840032052, serialized key size = -1, serialized value size = 8, headers = RecordHeaders(headers = [], isReadOnly = false), key = null, value = silince4)

消费者组

需求:测试同一个主题的分区数据，只能由一个消费者组中的一个消费。

代码：复制两份独立消费者(订阅主题)即可，因为groupid相同，所以自动会组成一个消费者组

分区的分配以及再平衡

一个consumer group中有多个consumer组成，一个 topic有多个partition组成，现在的问题是，到底由哪个consumer来消费哪个 partition的数据。
Kafka有四种主流的分区分配策略: Range、RoundRobin、Sticky、CooperativeSticky。
可以通过配置参数partition.assignment.strategy，修改分区的分配策略。默认策略是Range+ CooperativeSticky。Kafka可以同时使用。

Range 以及再平衡

Range 是对每个 topic 而言的。首先对同一个 topic 里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。

如现在有 7 个分区，3 个消费者，排序后的分区将会是0,1,2,3,4,5,6;消费者排序完之后将会是C0,C1,C2。通过 partitions数/consumer数来决定每个消费者应该消费几个分区。如果除不尽，那么前面几个消费者将会多消费 1 个分区。
例如，7/3=2余1，除不尽，那么消费者C0便会多消费1个分区。8/3=2余2，除不尽，那么C0和C1分别多消费一个。

⚠️：如果只是针对1个topic而言，C0消费者多消费1 个分区影响不是很大。但是如果有N多个topc，那么针对每个topic，消费者C0都将多消费1个分区，topic越多，C0消费的分区会比其他消费者明显多消费N个分区。容易产生数据倾斜

Range 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息观看结果(45s 以内，越快越好)。

1 号消费者:消费到 3、4 号分区数据。
2 号消费者:消费到 5、6 号分区数据。
0 号消费者的任务会整体被分配到 1 号消费者或者 2 号消费者。

0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。再次重新发送消息观看结果(45s 以后)。

1 号消费者:消费到 0、1、2、3 号分区数据。
2 号消费者:消费到 4、5、6 号分区数据。

说明:消费者 0 已经被踢出消费者组，所以重新按照 range 方式分配。

RoundRobin 以及再平衡

RoundRobin 针对集群中所有Topic而言。

RoundRobin 轮询分区策略，是把所有的 partition 和所有的 consumer 都列出来，然后按照 hashcode 进行排序，最后通过轮询算法来分配 partition 给到各个消费者。

RoundRobin 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息观看结果(45s 以内，越快越好)。

1 号消费者:消费到 2、5 号分区数据
2 号消费者:消费到 4、1 号分区数据
0 号消费者的任务会按照 RoundRobin 的方式，把数据轮询分成 0 、6 和 3 号分区数据，分别由 1 号消费者或者 2 号消费者消费。

1 号消费者:消费到 0、2、4、6 号分区数据
2 号消费者:消费到 1、3、5 号分区数据

说明:消费者 0 已经被踢出消费者组，所以重新按照 RoundRobin 方式分配。

Sticky 以及再平衡

粘性分区定义:可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。

粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略，首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。

Sticky 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息观看结果(45s 以内，越快越好)。

1 号消费者:消费到 2、5、3 号分区数据。
2 号消费者:消费到 4、6 号分区数据。
0 号消费者的任务会按照粘性规则，尽可能均衡的随机分成 0 和 1 号分区数据，分别由 1 号消费者或者 2 号消费者消费。

1 号消费者:消费到 2、3、5 号分区数据。
2 号消费者:消费到 0、1、4、6 号分区数据。

说明：消费者 0 已经被踢出消费者组，所以重新按照粘性方式分配。

CooperativeSticky

和sticky类似只是说支持了cooperative的rebalance。

Cooperative rebalance：这种方式就是我们通过consumer group的leader把有影响的partition停止了，其它partition还在继续consumer，对有影响的partition再进行重新分配，有时为了达到最终的均衡，这个过程可能会发生好几次才最终stable，如下图所示，在第一个rebalance过程中，我们把partition3停止了，这个时候1和2还是被正常consume的。然后在第二个rebalance的过程中，partition3重新被assign给consumerC。所以这种方式相比于Eager来说，它不会出现全部停止的情况。

offset位移

offset 的默认维护位置

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+分区号，value 就是当前 offset 的值。每隔一段时间，kafka 内部会对这个 topic 进行 compact，也就是每个 group.id+topic+分区号就只保留最新数据。

自动提交 offset

为了使我们能够专注于自己的业务逻辑，Kafka提供了自动提交offset的功能。自动提交offset的相关参数：

enable.auto.commit：是否开启自动提交offset功能，默认是true
auto.commit.interval.ms：自动提交offset的时间间隔，默认是5s

API配置方式

// 提交offset的时间周期1000ms，默认5s 
properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, 1000);

手动提交 offset

虽然自动提交offset十分简单便利，但由于其是基于时间提交的，开发人员难以把握offset提交的时机。因此Kafka还提供了手动提交offset的API。

手动提交offset的方法有两种:分别是commitSync(同步提交)和commitAsync(异步提交)。两者的相同点是，都会将本次提交的一批数据最高的偏移量提交；不同点是，同步提交阻塞当前线程，一直到提交成功，并且会自动失败重试(由不可控因素导致，也会出现提交失败)；而异步提交则没有失败重试机制，故有可能提交失败。

commitSync(同步提交):必须等待offset提交完毕，再去消费下一批数据。
commitAsync(异步提交) :发送完提交offset请求后，就开始消费下一批数据了。

// 是否自动提交offset
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);

指定 offset 消费

auto.offset.reset = earliest | latest | none 默认是 latest。

当 Kafka 中没有初始偏移量(消费者组第一次消费)或服务器上不再存在当前偏移量时(例如该数据已被删除)，该怎么办?

1）earliest:自动将偏移量重置为最早的偏移量，–from-beginning。

2）latest(默认值):自动将偏移量重置为最新偏移量。

3）none:如果未找到消费者组的先前偏移量，则向消费者抛出异常。

// 订阅一个主题
ArrayList<String> topics = new ArrayList<>(); 
topics.add("first"); 
kafkaConsumer.subscribe(topics);

Set<TopicPartition> assignment= new HashSet<>();
while (assignment.size() == 0) {  // 保证分区分配方案已经制定完毕
  // 获取消费者分区分配信息(有了分区分配信息才能开始消费) 
  assignment = kafkaConsumer.assignment();
}

// 遍历所有分区，并指定 offset 从 1700 的位置开始消费 
for (TopicPartition tp: assignment) {
  //覆盖使用者将在下一次轮询(超时)中使用的提取偏移量。如果对同一分区多次调用此 API，则将在下一个 poll ()上使用最新的偏移量。
  kafkaConsumer.seek(tp, 1700);
}

指定时间消费

需求:在生产环境中，会遇到最近消费的几个小时数据异常，想重新按照时间消费。例如要求按照时间消费前一天的数据，怎么处理?

/**
 * 指定时间消费
 *
 * @author zhongye
 * @since 2022.05.07
 */
public class CustomConsumerSeekTime {
  public static void main(String[] args) {
    //0 配置
    Properties properties = new Properties();

    //连接bootstrap.servers
    properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");

    // 反序列化
    properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    // 指定消费者组id
    properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");

    // 1 创建一个消费者 "","hello"
    KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);

    // 2 定义主题 first
    ArrayList<String> topics = new ArrayList<>();
    topics.add("first");
    kafkaConsumer.subscribe(topics);

    // 指定位置进行消费
    Set<TopicPartition> assignment = kafkaConsumer.assignment();

    // 保证分区分配方案已经制定完毕
    while (assignment.size()==0){
      // 获取消费者分区分配信息(有了分区分配信息才能开始消费)
      assignment = kafkaConsumer.assignment();
    }

    // ⭐️希望把时间转换为对应的offset
    HashMap<TopicPartition, Long> topicPartitionLongHashMap = new HashMap<>();
    // 封装对应的map
    for (TopicPartition topicPartition : assignment) {
      // 指定当前时刻一天前的offset
      topicPartitionLongHashMap.put(topicPartition,System.currentTimeMillis()-1*24*3600*1000);
    }
    Map<TopicPartition, OffsetAndTimestamp> offsetsForTimes = kafkaConsumer.offsetsForTimes(topicPartitionLongHashMap);

    // 指定消费的offset
    for (TopicPartition topicPartition : assignment) {
      // 获取各分区一天前的offset
      OffsetAndTimestamp offsetAndTimestamp = offsetsForTimes.get(topicPartition);
      kafkaConsumer.seek(topicPartition,offsetAndTimestamp.offset());
    }


    // 3 消费数据
    while (true){
      ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
      for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
        System.out.println(consumerRecord);
      }
    }

  }
}

漏消费和重复消费

重复消费:已经消费了数据，但是 offset 没提交。

漏消费:先提交 offset 后消费，有可能会造成数据的漏消费。

如果想完成Consumer端的精准一次性消费，那么需要Kafka消费端将消费过程和提交offset 过程做原子绑定。此时我们需要将Kafka的offset保存到支持事务的自定义介质（比如MySQL)。

数据积压

1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

参数名称	描述
fetch.max.bytes	默认Default: 52428800(50m)。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值 (50m)仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受 message.max.bytes (broker config)or max.message.bytes (topic config)影响。
max.poll.records	一次 poll 拉取数据返回消息的最大条数，默认是 500 条

Kafka学习笔记 Broker

Thu, 28 Apr 2022 05:19:06 +0000

Kafka Broker

Zk 存储结构

Broker工作流程

Kafka 副本

1）副本基本信息

Kafka 副本作用:提高数据可靠性。
Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性;太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
Kafka 中副本分为:Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 会找 Leader 进行同步数据。
Kafka 分区中的所有副本统称为 AR(Assigned Repllicas)。
- AR = ISR + OSR
- ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。
- OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本。

2）Leader 选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。Controller 的信息同步工作是依赖于 Zookeeper 的。

3）Follower 故障处理细节

LEO(Log End Offset):每个副本的最后一个offset，LEO其实就是最新的offset + 1。
HW(High Watermark):所有副本中最小的LEO 。

此时follower2发生故障，Follower会读取本地磁盘记录的上次的HW，并将1og文件高于HW的部分截取掉，从HW开始向Leaderi进行同步。

4）Leader 故障处理细节

为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leaderl同步数据。

5）分区副本分配

如果 kafka 服务器只有 4 个节点，那么设置 kafka 的分区数大于服务器台数，在 kafka 底层如何分配存储副本呢?

创建 16 分区，3 个副本场景下会如下分配(示意图中省略了12-15分区)，目的是为了尽可能的保持负载均衡

生产经验

手动调整分区副本存储

需求🤔:创建一个新的topic，4个分区，两个副本，名称为three。将该topic的所有副本都存储到broker0和 broker1两台服务器上。

在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。

手动调整分区副本存储的步骤如下:

# 1.创建一个新的 topic，名称为 three。
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --partitions 4 --replication-factor 2 -- topic three
# 2.查看分区副本存储情况。
bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic three
# 3.创建副本存储计划(所有副本都指定存储在 broker0、broker1 中)。
vim increase-replication-factor.json
{
   "version":1,
   "partitions":[{"topic":"three","partition":0,"replicas":[0,1]}, 
                 {"topic":"three","partition":1,"replicas":[0,1]}, 
                 {"topic":"three","partition":2,"replicas":[1,0]}, 
                 {"topic":"three","partition":3,"replicas":[1,0]}]
}
# 4.执行副本存储计划。
bin/kafka-reassign-partitions.sh -- bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --execute
# 5.验证副本存储计划。
bin/kafka-reassign-partitions.sh -- bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --verify
# 6.查看分区副本存储情况。
bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic three

Leader Partition 负载平衡

正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的 broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。

参数名称	描述
auto.leader.rebalance.enable	默认是 true。自动 Leader Partition 平衡。生产环境中，`leader 重选举的代价比较大，可能会带来性能影响，建议设置为 false 关闭。`
leader.imbalance.per.broker.percentage	默认是 10%。每个 broker 允许的不平衡的 leader 的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡。
leader.imbalance.check.interval.seconds	默认值 300 秒。检查 leader 负载是否平衡的间隔时间。

增加副本因子

在生产环境当中，由于某个主题的重要等级需要提升，我们考虑增加副本。副本数的增加需要先制定计划，然后根据计划执行。

# 1.创建 topic
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --partitions 3 --replication-factor 1 -- topic four
# 2.手动增加副本存储。创建副本存储计划(所有副本都指定存储在 broker0、broker1、broker2 中)。
vim increase-replication-factor.json
{"version":1,"partitions":[{"topic":"four","partition":0,"replicas":[0,1,2]},{"topic":"four","partition":1,"replicas":[0,1,2]},{"t opic":"four","partition":2,"replicas":[0,1,2]}]}
# 3.执行副本存储计划。
bin/kafka-reassign-partitions.sh -- bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --execute

文件存储

文件存储机制

Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。

Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。
每个segment包括:“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹的命名规则为:topic名称+分区序号，例如:first-0。

index 文件和 log 文件详解(稀疏索引)：

相对偏移量：如 522(起始offset)+65(相对offerset) = 587(绝对offset)

日志存储参数配置：

参数	描述
log.segment.bytes	Kafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分成块的大小，默认值 1G。
log.index.interval.bytes	默认 4kb，kafka 里面每当写入了 4kb 大小的日志(.log)，然后就往 index 文件里面记录一个索引。稀疏索引。

文件清理策略

Kafka 中默认的日志保存时间为 7 天，可以通过调整如下参数修改保存时间。

log.retention.hours，最低优先级小时，默认7天。
log.retention.minutes，分钟。
log.retention.ms，最高优先级毫秒。
log.retention.check.interval.ms，负责设置检查周期，默认5分钟。

🤔那么日志留存时间一旦超过了设置的时间，怎么处理呢?

Kafka 中提供的日志清理策略有 delete 和 compact 两种。

1）delete 日志删除:将过期数据删除

log.cleanup.policy = delete 所有数据启用删除策略
- 基于时间:默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
- 基于大小:默认关闭。超过设置的所有日志总大小，删除最早的 segment。log.retention.bytes，默认等于-1，表示无穷大。

🤔如果一个 segment 中有一部分数据过期，一部分没有过期，怎么处理?

如采用基于时间的删除方式，因为segment 中所有记录中的最大时间戳作为该文件时间戳，因此会将整个segment删除。如果是基于大小的删除方式则不影响。

2）compact日志压缩：对于相同key的不同value值，只保留最后一个版本。

log.cleanup.policy = compact 所有数据启用压缩策略

压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这个offset大的offset对应的消息，实际上会拿到offset为7的消息，并从这个位置开始消费。

⚠️这种策略只适合特殊场景，比如消息的key是用户ID，value是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。

高效读写

Kafka 是如何实现高吞吐率的

1)Kafka 本身是分布式集群，可以采用分区技术，并行度高

2)读数据采用稀疏索引，可以快速定位要消费的数据

3)顺序写磁盘

Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

4)页缓存 + 零拷贝技术

零拷贝:Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用走应用层，传输效率高。
PageCache页缓存:Kafka重度依赖底层操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入 PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。

Kafka学习笔记生产者

Fri, 22 Apr 2022 04:19:06 +0000

Kafka 生产者

生产者消息发送流程

发送原理

batch.size：只有数据积累到batch.size之后，sender才会发送数据，默认16k
linger.ms：如果数据迟迟未达到batch.size,sender等待linger.ms设置的时间。到了之后就会发送数据，单位ms，默认值是0ms，表示没有延迟。

应答acks：

0：生产者发送过来的数据，不需要等数据落盘应答。
1：生产者发送过来的数据，Leader 收到数据后应答。
-1(all)：生产者发送过来的数据，Leader 和 ISR 队列里面的所有节点收齐数据后应答。-1和 all 等价。

生产者重要参数列表

参数名称	描述
bootstrap.servers	生产者连接集群所需的 broker 地址清单。例如 hadoop102:9092,hadoop103:9092,hadoop104:9092，可以设置 1 个或者多个，中间用逗号隔开。注意这里并非需要所有的 broker 地址，因为生产者从给定的 broker 里查找到其他 broker 信息。
key.serializer 和 value.serializer	指定发送消息的 key 和 value 的序列化类型。一定要写全类名。
buffer.memory	RecordAccumulator 缓冲区总大小，默认 32m。
batch.size	缓冲区一批数据最大值，默认 16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。
linger.ms	如果数据迟迟未达到 batch.size，sender 等待 linger.time 之后就会发送数据。单位 ms，默认值是 0ms，表示没有延迟。生产环境建议该值大小为 5-100ms 之间。
acks	0：生产者发送过来的数据，不需要等数据落盘应答。 1：生产者发送过来的数据，Leader 收到数据后应答。 -1(all)：生产者发送过来的数据，Leader 和 ISR 队列里面的所有节点收齐数据后应答。`默认值是-1，-1 和 all 是等价的。`
max.in.flight.requests.per.connection	允许最多没有返回 ack 的次数，默认为 5，开启幂等性要保证该值是 1-5 的数字。
retries	当消息发送出现错误的时候，系统会重发消息。retries 表示重试次数。默认是 int 最大值，2147483647。如果设置了重试，还想保证消息的有序性，需要设置 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1 否则在重试此失败消息的时候，其他的消息可能发送成功了。
retry.backoff.ms	两次重试之间的时间间隔，默认是 100ms。
enable.idempotence	是否开启幂等性，默认 true，开启幂等性。
compression.type	生产者发送的所有数据的压缩方式。默认是 none，也就是不压缩。支持压缩类型:none、gzip、snappy、lz4 和 zstd。

异步发送 API

普通异步发送

需求:创建 Kafka 生产者，采用异步的方式(外部数据无须等到当前batch被RecordAccumulator处理完后再载入)发送到 Kafka Broker

1）创建工程，导入依赖

<dependency>
  <groupId>org.springframework.kafka</groupId>
  <artifactId>spring-kafka-test</artifactId>
  <scope>test</scope>
</dependency>

2）编写不带回调函数的 API 代码

/**
 * kafka 生产者
 *
 * @author zhongye
 * @since 2022.04.26
 */
public class CustomProducer {
  public static void main(String[] args) {
    // 0 配置
    Properties properties = new Properties();
    // 连接集群 bootstrap.servers
    properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");
    // 指定对应的key和value的序列化类型 key.serializer
    properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

    // 1 创建kafka生产者对象
    KafkaProducer<String, String> kafkaProducer = new KafkaProducer<>(properties);

    // 2 ⚠️发送数据(创建ProducerRecord时也可以指定分区)
    for (int i = 0; i < 5; i++) {
      kafkaProducer.send(new ProducerRecord<>("first","silince"+i));
    }

    // 3 关闭资源
    kafkaProducer.close();
  }
}

带回调函数的异步发送

回调函数会在 producer 收到 ack 时调用，为异步调用，该方法有两个参数，分别是元数据信息(RecordMetadata)和异常信息(Exception)，如果 Exception 为 null，说明消息发送成功，如果 Exception 不为 null，说明消息发送失败。

⚠️：消息发送失败会自动重试，不需要我们在回调函数中手动重试。

kafkaProducer.send(new ProducerRecord<>("first", "silince" + i), new Callback() {
  @Override
  public void onCompletion(RecordMetadata recordMetadata, Exception e) {
    if (e==null){
      System.out.println("主题: "+recordMetadata.topic()+" 分区: "+recordMetadata.partition());
    }
  }

同步发送 API

同步发送(当前batch全部正常ack之后再载入下一批外部数据)只需在异步发送的基础上，再调用一下 get()方法即可。

/**
 * kafka 生产者
 *
 * @author zhongye
 * @since 2022.04.26
 */
public class CustomProducer {
  public static void main(String[] args) throws Exception {
    // 0 配置
    Properties properties = new Properties();
    // 连接集群 bootstrap.servers
    properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");
    // 指定对应的key和value的序列化类型 key.serializer
    properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

    // 1 创建kafka生产者对象
    KafkaProducer<String, String> kafkaProducer = new KafkaProducer<>(properties);

    // 2 发送数据
    for (int i = 0; i < 5; i++) {
      kafkaProducer.send(new ProducerRecord<>("first", "silince" + i)).get();
    }

    // 3 关闭资源
    kafkaProducer.close();
  }
}

分区策略

Kafka 分区

生产经验

如何提高吞吐量

batch.size：批次大小, 默认16k
linger.ms：等待时间,修改为5-100ms(太大的话会导致下一批数据的延迟过高)
compression.type：压缩snappy
RecordAccumulator：缓冲区大小,修改为64m

// 1. 创建 kafka 生产者的配置对象
Properties properties = new Properties();
// 2. 给 kafka 配置对象添加配置信息:bootstrap.servers
properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
// key,value 序列化(必须):key.serializer，value.serializer
properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// batch.size:批次大小，默认16K 
properties.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
// linger.ms:等待时间，默认 0 
properties.put(ProducerConfig.LINGER_MS_CONFIG, 1);
// RecordAccumulator:缓冲区大小，默认 32M:buffer.memory 
properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG,33554432);
// compression.type:压缩，默认 none，可配置值 gzip、snappy、 lz4 和 zstd
properties.put(ProducerConfig.COMPRESSION_TYPE_CONFIG,"snappy");

数据可靠性

1）ACKS应答级别

0:生产者发送过来的数据，不需要等数据落盘应答(可靠性差，效率高)
1:生产者发送过来的数据，Leader收到数据后应答(可靠性中等，效率中等)
-1(all):生产者发送过来的数据，Leader和ISR队列里面的所有节点收齐数据后应答(可靠性高，效率低;在生产环境中，acks=0很少使用;acks=1，一般用于传输普通日志，允许丢个别数据;acks=-1，一般用于传输和钱相关的数据，对可靠性要求比较高的场景)

🤔 当acks=-1时，Leader收到数据，所有Follower都开始同步数据，但有一个Follower，因为某种故障，迟迟不能与Leader进行同步，那这个问题怎么解决呢?

Leader维护了一个动态的in-sync replica set(ISR)，意为和 Leader保持同步的Follower+Leader集合(leader:0，isr:0,1,2)。

因此**数据完全可靠条件 = ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于**2

2）代码配置

// 0 配置
Properties properties = new Properties();
// 连接集群 bootstrap.servers
properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");
// 指定对应的key和value的序列化类型 key.serializer
properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

// acks + 重试次数
properties.put(ProducerConfig.ACKS_CONFIG,"1");
properties.put(ProducerConfig.RETRIES_CONFIG,3);

数据重复

acks: -1(all):生产者发送过来的数据，Leader和ISR队列里面的所有节点收齐数据后应答。如果Leader同步数据之后，没来得及确认ack就挂掉了，则新选举的Leader则会又收到一份重复数据。

1）数据传递语义

至少一次(At Least Once)=ACK级别设置为-1+分区副本大于等于2+ISR里应答的最小副本数量大于等于2 。可以保证数据不丢失，但是不能保证数据不重复;
最多一次(At Most Once)=ACK级别设置为0。可以保证数据不重复，但是不能保证数据不丢失。
精确一次(Exactly Once):对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不丢失。

Kafka 0.11版本以后，引入了一项重大特性:幂等性和事务。

2）幂等性

幂等性就是指Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。

精确一次(Exactly Once) = 幂等性 + 至少一次( ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2) 。

重复数据的判断标准：具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。

PID：Kafka每次重启都会分配一个新的pid
Partition：分区号
Sequence Number：序列号，单调自增

所以幂等性只能保证的是在单分区单会话内不重复。

使用方式：开启参数 enable.idempotence 默认为 true，false 关闭。

3）生产者事务

开启事务，必须开启幂等性。Producer 在使用事务功能前，必须先自定义一个唯一的 transactional.id。有了 transactional.id，即使客户端挂掉了，它重启后也能继续处理未完成的事务

// Kafka事务API
void initTransactions(); // 1 初始化事务
void beginTransaction() throws ProducerFencedException; // 2 开启事务
void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets, String consumerGroupId) throwsProducerFencedException; // 3 在事务内提交已经消费的偏移量(主要用于消费者)
void commitTransaction() throws ProducerFencedException; // 4 提交事务
void abortTransaction() throws ProducerFencedException; // 5 放弃事务(类似于回滚事务的操作)

单个 Producer，使用事务保证消息的仅一次发送

public class CustomProducerTransactions {
  public static void main(String[] args) throws InterruptedException {
    // 1. 创建 kafka 生产者的配置对象
    Properties properties = new Properties();
    // 2. 给 kafka 配置对象添加配置信息 
    properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092");
    // key,value 序列化
    properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    // 设置事务id(必须)，事务id任意起名
    properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "transaction_id_0");
    // 3. 创建 kafka 生产者对象
    KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);
    // 初始化事务 
    kafkaProducer.initTransactions(); 
    // 开启事务 
    kafkaProducer.beginTransaction(); 
    try {
      // 4. 调用 send 方法,发送消息 
      for (int i = 0; i < 5; i++) {
        // 发送消息
        kafkaProducer.send(new ProducerRecord<>("first", "silince " + i));
      }
      //提交事务
      kafkaProducer.commitTransaction();
    } catch (Exception e) { 
      // 终止事务
      kafkaProducer.abortTransaction(); } finally {
      // 5. 关闭资源
      kafkaProducer.close();
    }
  }
}

数据有序

单分区内，有序(还需有其他条件); 多分区，分区与分区间无序;

🤔单分区数据乱序问题？因为sender线程将数据发送到kafka集群的过程中存在重试机制。

1）kafka在1.x版本之前保证数据单分区有序，条件如下:

max.in.flight.requests.per.connection=1(不需要考虑是否开启幂等性)。

2）kafka在1.x及以后版本保证数据单分区有序，条件如下:

未开启幂等性：max.in.flight.requests.per.connection(该参数指定了生产者在收到服务器响应之前可以发送多少个消息)需要设置为1
开启幂等性：max.in.flight.requests.per.connection需要设置小于等于5。因为在kafka1.x以后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据，故无论如何，都可以保证最近5个request的数据都是有序的(根据序列号)

Kafka学习笔记快速入门

Fri, 22 Apr 2022 04:19:06 +0000

Kafka概述

Kafka是一个分布式的基于发布/订阅模式的消息队列(Message Queue)，主要应用于大数据实时处理领域。

消息队列的两种模式

点对点模式

一对一，消费者主动拉取数据，消息收到后消息清除。消息生产者生产消息发送到 Queue 中，然后消息消费者从 Queue 中取出并且消费消息。消息被消费以后，Queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。 Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

发布/订阅模式

一对多，消费者消费数据之后不会清除消息。消息生产者(发布)将消息发布到 topic 中，同时有多个消息消费者(订阅)消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。该模式具体可分为拉和推两种方式：

队列主动推送：各个消费者处理的速率不同，可能会导致消费者资源浪费或不足。
消费者主动拉取：长轮询

Kafka 基础架构

Producer:消息生产者，就是向 Kafka broker 发消息的客户端
Consumer:消息消费者，向 Kafka broker 取消息的客户端
Consumer Group(CG):消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
Broker:一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
Topic:可以理解为一个队列，生产者和消费者面向的都是一个 topic。
Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。
Replica:副本。一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个 Follower。
Leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。
Follower:每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的 Leader。

Kafka快速入门

单机部署

1）解压安装包

tar -zxvf kafka_2.12-3.0.0.tgz -C /opt/module/

2）创建logs日志文件夹

mkdir ~/Application/kafka_2.12-3.0.0/logs

3）修改配置文件

vim kafka_2.12-3.0.0/config/server.properties

#broker 的全局唯一编号，不能重复 broker.id=0
#删除 topic 功能使能
delete.topic.enable=true
#处理网络请求的线程数量 
num.network.threads=3
#用来处理磁盘 IO 的现成数量 
num.io.threads=8 
#发送套接字的缓冲区大小 
socket.send.buffer.bytes=102400 
#接收套接字的缓冲区大小 
socket.receive.buffer.bytes=102400 
#请求套接字的缓冲区大小 
socket.request.max.bytes=104857600 
#kafka 运行数据和日志存放的路径 
log.dirs=~/Application/kafka_2.12-3.0.0/logs
#topic 在当前 broker 上的分区个数 
num.partitions=1
#用来恢复和清理 data 下数据的线程数量 
num.recovery.threads.per.data.dir=1 
#segment 文件保留的最长时间，超时将被删除 
log.retention.hours=168
#配置连接 Zookeeper 集群地址 
zookeeper.connect=localhost:2181/kafka

4）依次启动zookeeper和kafka(Kafka会按照默认，在9092端口上运行，并连接zookeeper的默认端口：2182)

cd ~/Applications/ZooKeeper
bin/zkServer.sh start
~/Application/kafka_2.12-3.0.0
sh bin/kafka-server-start.sh  -daemon  config/server.properties # -daemon 后台启动kafka

如kafka启动报错：在 server.properties 找到 log.dirs 配置的路径。将该路径下的所有文件删除，或者编辑meta.properties文件修改里面的cluster.id即可。

ERROR Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
kafka.common.InconsistentClusterIdException: The Cluster ID kVSgfurUQFGGpHMTBqBPiw doesn't match stored clusterId Some(0Qftv9yBTAmf2iDPSlIk7g) in meta.properties. The broker is trying to join the wrong cluster. Configured zookeeper.connect may be wrong.
    at kafka.server.KafkaServer.startup(KafkaServer.scala:220)
    at kafka.server.KafkaServerStartable.startup(KafkaServerStartable.scala:44)
    at kafka.Kafka$.main(Kafka.scala:84)
    at kafka.Kafka.main(Kafka.scala)

主题命令行操作

1）查看操作主题命令参数

bin/kafka-topics.sh

2）查看当前服务器中的所有 topic

bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

3）创建 first topic

# --topic 定义topic名 --replication-factor 定义副本数 --partitions 定义分区数
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --partitions 1 --replication-factor 3 --topic first

4）查看 first 主题的详情

bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic first

5）修改分区数(注意:分区数只能增加，不能减少)

bin/kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic first --partitions 3

6）删除 topic

bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic first

生产者命令行操作

1）查看操作生产者命令参数

bin/kafka-console-producer.sh

2）发送消息

bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic first
>hello world

消费者命令行操作

1）查看操作消费者命令参数

参数	描述
–bootstrap-server <String: server toconnect to>	连接的 Kafka Broker 主机名称和端口号
–topic <String: topic>	操作的 topic 名称
–from-beginning	从头开始消费
–group <String: consumer group id>	指定消费者组名称

2）消费消息

# 消费 first 主题中的数据
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first
# 把主题中所有的数据都读取出来(包括历史数据)
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic first

Elasticsearch中的数值类型索引

Thu, 03 Mar 2022 13:10:06 +0000

前言

最近杂七杂八的事情比较多，好久没更新文章了🤦‍♀️，今天就好好来理一理之前没搞清楚的关于ES数值索引的问题。ES主要是用于解决文本检索的场景，ES会默认将所有的输入内容当作字符串来理解，对于字段类型是keyword或者text的数据比较友好。但是如果输入的类型是数字，ES还会把数字当作字符串吗？排序问题还有范围查询问题怎么解决呢？

为什么要用BKD Tree

从Elasticsearch5.x开始，Elasticsearch开始使用Lucene6.0版本，而Lucene6.0版本对于Lucene来说有非常大的改变，随之带来的是Elasticsearch有很大的改变。

ES使用的搜索库Lucene在6.0版本以及以后为了解决多维空间位置搜索问题，改用新的数据结构——BKD树来实现位置搜索，带来了很大的性能提升。开发者发现这种实现也能用于一维数据搜索，于是用新的数据结构代替了现在的字符串的实现。

kd树

k-d树(k-dimensional)，也就是k维树.

kd树是每个叶子节点都为k维点的二叉树。所有非叶子节点可以视作用一个超平面把空间分割成两个半空间。节点左边的子树代表在超平面左边的点，节点右边的子树代表在超平面右边的点。选择超平面的方法如下：每个节点都与k维中垂直于超平面的那一维有关。因此，如果选择按照x轴划分，所有x值小于指定值的节点都会出现在左子树，所有x值大于指定值的节点都会出现在右子树。这样，超平面可以用该x值来确定，其法线为x轴的单位向量。

kd树允许节点内部有任意的维度的数据。kd树使用二叉树实现，类似于一个BST。关键的不同是，当每个节点比较大小时，可以使用不同的维度来比较。下图是一个2k树的结构与其对应的二维空间，它使用了不同的维度来划分左右区域。

优缺点：

优点：K-D树和BST一样不仅可以精确查找，也更适合做范围查询，但K-D树比BST更强，它能对多个维度进行范围查询。
缺点：类似于二叉搜索树，如果一个kd树是平衡的，可以保证O(logn) 的时间复杂度，因此每一个节点都把整个集合划分成了两半。关键的问题就是，只有平衡的情况下才能保证这一点。设想一下，给图中的kd树，添加两个节点(1,1) ,(0,0), 整棵树的所有节点几乎已经全部在左侧了，这样就破坏了原有的平衡。更复杂的是，对于kd树而言，没有一些标准的技术来让树恢复平衡，比如树的旋转等操作。我们能做的就是完全的重建这棵树。因此，标准的kd树对于动态的更新，不提供很好的性能，只有在静态数据集上，kd树才有很好的性能.

kdb树

接下来的进阶版本是KDB树(k-dimensional B-Tree)，这种数据结构混合了kd树和B+树之后会拿到的结构。和标准的kd树一样，一个内部节点将空间分为两半。不过和kd树不一样的是，kdb树的内部节点不存储它们自己的数据。空间内会两个点定义个区域，每个维度的第一个点定义了最小值，第二个点定义了最大值。

因此K-D-B树具备了B树的优点：提供平衡K-D树的搜索效率，同时提供和B树一样面向块的存储以优化外存设备的访问。

由于kdb树存储表现是一颗B树，他在磁盘上的性能很好。这是因为提高了每个节点的扇出率(内部节点不存储数据)，导致节点变大以及树变矮。磁盘通常有高的延迟及高的吞吐量，这意味着读取大的数据块是有优势的，因为读取小的数据块将话费更多的时间在延迟上。树比较低，意味着需要更少的逻辑读取。在磁盘上，一个b树的节点的大小至少是和一个页一样大，也就是4k，更多的时间是大于这个值的。因此，一个节点经常有成百上千个孩子节点。

像其他b树的变种一样，kdb树保证自身是平衡的树。这是通过插入策略来保证的，如果一个插入元素在叶子节点上，且这个叶子节点没满, 那么将这个元素添加到这个叶子节点。如果叶子节点是满的，那就进行分裂。不是通常想象的将值写入到树的高层节点上，而是只给高层节点添加一个区域。如果一个元素在区域之外，事情就更复杂了。

与B树这类存储一维数据（数据只按一种规则排序）的数据结构不同，K-D-B树数据有多个维度，所以页分裂的时候不能以B树“一刀切”的方式解决。以二维K-D-B树为例，一个节点数据过多，需要分裂时，就需要拆分区域。拆分区域的过程中大概率会出现拆分该区域的子区域。这是kdb树的主要缺点：

切割一个区域，通常需要切割他的孩子节点。这个改动修改了树的大部分，如果此时我们需要写入磁盘，那么就会变得很慢。
kdb树的另外一个缺点是空间利用率，由于没有约束节点的大小，可能有很大的一部分空间都浪费了。这不仅影响磁盘页的大小，还会导致更少的页被缓存到内存中。
所以和K-D树一样，K-D-B树对于修改频繁的动态数据并不友好。

BKD树

bkd树用来解决空间问题和插入的效率问题。bkd树由多个修改后的kd树和独特的插入方法构成的，下图是一个bkd树的基础结构。

这个树由一个二叉树和一个b+树构成，特殊的是，内部节点必须是一个完全二叉树。

因为这是一颗完全二叉树，因此节点不需要记录子节点的指针，而是可以通过完全二叉树的性质算出来(假如一个节点的位置在 i ，那这个节点的左节点在位置2 i ，右节点在2 i + 1)。更小的节点意味着可以有更多的节点被缓存在内存。同时，可以让大量的节点是叶子节点，这有效的降低了树的整体高度.

一个更大的因素，也是bkd最令人感兴趣的地方时，这些内部节点不会被更改，bkd树使用了一种策略来添加新数据：刚开始时，内存中缓存M个元素，这个缓冲区通常是一个简单的数组，因此他有很好的查询性能，论文中没有特别说明这个缓冲区的大小，但是按照常识来猜测，应该也是大于kd树的数量的。

给定一个有N个节点的bkd树，就有log2(n/m)个改良的kd树，每一个树的节点是上一个树的两倍。对于bkd的插入，新节点首先被插入到内存里的缓冲区里，一旦缓冲区满了，先定位到第1个为空的树。这个Buffer的数据，以及空树之前所有节点的数据一起生成一个完全二叉树。论文中讲了一个构建树的快速方法，这里就不再具体展开。

Elasticsearch的filter查询

如果Elasticsearch中查询条件的多个filter，但实际上并像mysql那样按照每个filter的顺序执行，而是每一个filter都是单独执行的，最后把每个filter的结果集进行合并。Elasticsearch有个cost函数，它会先估算每个filter的代价，然后从代价最低的开始迭代docid，并且根据term、and、or的不同，来决定不同的合并方式。合并结果集Lucene使用了跳表。

数值类型的TermQuery

先从term开始说，一般term都是keyword的类型。这种方式cost则直接返回倒排中的文档频率，频率越高的迭代代价自然就越大。所以会选择频率最低的term作为开始点。因为又引入了跳表数据结构，所以效率非常的快。postings list中的docid是顺序的，这是使用跳表的前提，因此，即使对于多个postings list的合并在磁盘上操作也不会产生太多随机IO。在Elasticsearch5.1.1之后，取消了TermQuery的cache。就是说所有term查询，都是直接读磁盘上的数据。因为跳表和页面缓存的存在，直接在磁盘上做合并也非常快，这么做也是为了减少资源开销，提高性能。但这也带来了一个隐患。

上面说到了对于TermQuery，取消了cache，每次都去操作磁盘。虽然是对TermQuery进行了优化，但这主要是针对keyword类型，对于数值类型，Lucene6.0以后取消了对数值类型进行倒排索引，而是采用BKD tree的方式。所以所有数值类型的TermQuery会被转成PointRangeQuery。

ES中BKD tree结构图如上所示，图中我们可以看到，每个block中value是有序的，而docid是无序的。无序也就不能使用跳表结构。这种情况下要对结果集进行合并，就要对docidlist做一个特殊处理：从源码中看到在创建Scorer的过程中有一个bitset的迭代器，这个过程是导致查询缓慢的罪魁祸首。因为如果range的结果集范围非常大的话，耗费的时间就会越长。

@Override
public Scorer get(long leadCost) throws IOException {
  if (values.getDocCount() == reader.maxDoc()
      && values.getDocCount() == values.size()
      && cost() > reader.maxDoc() / 2) {
    // If all docs have exactly one value and the cost is greater
    // than half the leaf size then maybe we can make things faster
    // by computing the set of documents that do NOT match the range
    final FixedBitSet result = new FixedBitSet(reader.maxDoc());
    result.set(0, reader.maxDoc());
    int[] cost = new int[] { reader.maxDoc() };
    values.intersect(getInverseIntersectVisitor(result, cost));
    final DocIdSetIterator iterator = new BitSetIterator(result, cost[0]);
    return new ConstantScoreScorer(weight, score(), iterator);
  }

数值类型的RangeQuery

上面我们了解到了对数值类型的range的优化，依然达不到我们想要的效果，于是Elasticsearch从5.4版本开始又加入了 indexOrDocValuesQuery 。

这个Query包装了上面的PointRangeQuery和SortedSetDocValuesRangeQuery，并且会根据Rang查询的数据集大小，以及要做的合并操作类型，决定用哪种Query。

如果Range的代价小，可以用来引领合并过程，就走PointRangeQuery，直接构造bitset来进行迭代。
而如果range的代价高，构造bitset太慢，就使用SortedSetDocValuesRangeQuery。这个Query利用了DocValues这种全局docid，并包含每个docid对应value的数据结构来做文档的匹配。当给定一个docid的时候，一次随机磁盘访问就可以定位到该id对应的value，从而可以判断该doc是否match。这样从其他过滤条件返回的小结果集中一次调用docid来判断value是否匹配。

总结

本文我们了解了Elasticsearch和Lucene不同版本中对数值类型range查询的优化，我们牢记以下两点来避免不必要的缓慢查询。

对于数值类型的数据，我们是要确定该字段是需要range还是term。比如id，有些情况下我们只需要对它做term查询，这种情况下使用keyword来存储会更好。
如果需要使用数值类型（非keyword），并且range的结果集很大的情况下，建议升级到Elasticsearch5.4+之后版本。

参考

谈谈TCP中的TIME_WAIT

Thu, 09 Sep 2021 15:10:06 +0000

TCP 四次挥手过程和状态变迁

TCP三次握手和四次挥手详解

TCP 断开连接是通过四次挥手方式。双方都可以主动断开连接，断开连接后主机中的「资源」将被释放。

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

为什么需要 TIME_WAIT 状态

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。

需要 TIME-WAIT 状态，主要是两个原因：

防止接收旧连接的数据包；
保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；

原因一：防止接收旧连接的数据包

假设 TIME-WAIT 没有等待时间或时间过短，被延迟的数据包抵达后会发生什么呢？

如上图黄色框框服务端在关闭连接之前发送的 SEQ = 301 报文，被网络延迟了。
这时有相同端口的 TCP 连接被复用后，被延迟的 SEQ = 301 抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产生数据错乱等严重的问题。

所以，TCP 就设计出了这么一个机制，经过 `2MSL` 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

原因二：保证连接正确关闭

在 RFC 793 指出 TIME-WAIT 另一个重要的作用是：

也就是说，TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。

假设 TIME-WAIT 没有等待时间或时间过短，断开连接会造成什么问题呢？

如上图红色框框客户端四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSE 状态了，那么服务端则会一直处在 LASE-ACK 状态。
当客户端发起建立连接的 SYN 请求报文后，服务端会发送 RST 报文给客户端，连接建立的过程就会被终止。

如果 TIME-WAIT 等待足够长的情况就会遇到两种情况：

服务端正常收到四次挥手的最后一个 ACK 报文，则服务端正常关闭连接。
服务端没有收到四次挥手的最后一个 `ACK` 报文时，则会重发 `FIN` 关闭连接报文并等待新的 `ACK` 报文。

所以客户端在 `TIME-WAIT` 状态等待 `2MSL` 时间后，就可以保证双方的连接都可以正常的关闭。

为什么 TIME_WAIT 等待的时间是 2MSL

`MSL` 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

比如，如果被动关闭方(服务器)没有收到断开连接的最后的 ACK 报文，被动关闭方就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方，一来一去正好 2 个 MSL。

`2MSL` 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。

其定义在 Linux 内核代码里的名称为 TCP_TIMEWAIT_LEN：

/* how long to wait to destroy TIME-WAIT state, about 60 seconds  */
#define TCP_TIMEWAIT_LEN (60*HZ) 

如果要修改 TIME_WAIT 的时间长度，只能修改 Linux 内核代码里 TCP_TIMEWAIT_LEN 的值，并重新编译 Linux 内核。

TIME_WAIT 过多有什么危害

如果服务器有处于 TIME-WAIT 状态的 TCP，则说明是由服务器方主动发起的断开请求。

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。主动正常关闭TCP连接，都会出现TIMEWAIT。为什么我们要关注这个高并发短连接呢？有两个方面需要注意：

高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
在这个场景中，短连接表示“业务处理+传输数据的时间远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念，比如，取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高）

过多的 TIME-WAIT 状态主要的危害有两种：

第一是内存资源占用；
第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口；

第二个危害是会造成严重的后果的，要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过如下参数设置指定

net.ipv4.ip_local_port_range

如果服务端 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。

如何优化 TIME_WAIT

这里给出优化 TIME-WAIT 的几个方式，都是有利有弊：

打开 net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps 选项；⭐️
net.ipv4.tcp_max_tw_buckets
程序中使用 SO_LINGER ，应用强制使用 RST 关闭。

方式一：net.ipv4.tcp_tw_reuse 和 tcp_timestamps

如下的 Linux 内核参数开启后，则可以复用处于 TIME_WAIT 的 socket 为新的连接所用和快速回收连接

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

使用这个选项，还有一个前提，需要打开对 TCP 时间戳的支持，即

net.ipv4.tcp_timestamps=1（默认即为 1）

这个时间戳的字段是在 TCP 头部的「选项」里，用于记录 TCP 发送方的当前时间戳和从对端接收到的最新时间戳。

由于引入了时间戳，我们在前面提到的 2MSL 问题就不复存在了，因为重复的数据包会因为时间戳过期被自然丢弃。

温馨提醒：net.ipv4.tcp_tw_reuse要慎用，因为使用了它就必然要打开时间戳的支持 net.ipv4.tcp_timestamps，当客户端与服务端主机时间不同步时，客户端的发送的消息会被直接拒绝掉。

方式二：net.ipv4.tcp_max_tw_buckets

这个值默认为 18000，当系统中处于 TIME_WAIT 的连接一旦超过这个值时，系统就会将所有的 TIME_WAIT 连接状态重置。

这个方法过于暴力，而且治标不治本，带来的问题远比解决的问题多，不推荐使用。

方式三：程序中使用 SO_LINGER

我们可以通过设置 socket 选项，来设置调用 close 关闭连接行为。

struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));

如果l_onoff为非 0，且l_linger值为 0，那么调用close后，会立该发送一个RST标志给对端，该 TCP 连接将跳过四次挥手，也就跳过了TIME_WAIT状态，直接关闭。

但这为跨越`TIME_WAIT`状态提供了一个可能，不过是一个非常危险的行为，不值得提倡。

几个调优参数详细介绍

net.ipv4.tcp_timestamps

RFC 1323 在 TCP Reliability一节里，引入了timestamp的TCP选项，两个4字节的时间戳字段，其中第一个4字节字段用来保存发送该数据包的时间，第二个4字节字段用来保存最近一次接收对方发送到数据的时间。有了这两个时间字段，也就有了后续优化的余地。

tcp_tw_reuse 和 tcp_tw_recycle就依赖这些时间字段。

net.ipv4.tcp_tw_reuse

字面意思，reuse TIME_WAIT状态的连接。

时刻记住一条socket连接，就是那个五元组，出现TIME_WAIT状态的连接，一定出现在主动关闭连接的一方。所以，当主动关闭连接的一方，再次向对方发起连接请求的时候（例如，客户端关闭连接，客户端再次连接服务端，此时可以复用了；负载均衡服务器，主动关闭后端的连接，当有新的HTTP请求，负载均衡服务器再次连接后端服务器，此时也可以复用），可以复用TIME_WAIT状态的连接。

通过字面解释，以及例子说明，你看到了，tcp_tw_reuse应用的场景：某一方，需要不断的通过“短连接”连接其他服务器，总是自己先关闭连接(TIME_WAIT在自己这方)，关闭后又不断的重新连接对方。

那么，当连接被复用了之后，延迟或者重发的数据包到达，新的连接怎么判断，到达的数据是属于复用后的连接，还是复用前的连接呢？那就需要依赖前面提到的两个时间字段了。复用连接后，这条连接的时间被更新为当前的时间，当延迟的数据达到，延迟数据的时间是小于新连接的时间，所以，内核可以通过时间判断出，延迟的数据可以安全的丢弃掉了。

这个配置，依赖于连接双方，同时对timestamps的支持。同时，这个配置，仅仅影响outbound连接，即做为客户端的角色，连接服务端[connect(dest_ip, dest_port)]时复用TIME_WAIT的socket。

连接池可以复用连接，是不是意味着，需要等到上个连接time wait结束后才能再次使用?

所谓连接池复用，复用的一定是活跃的连接，所谓活跃，第一表明连接池里的连接都ESTABLISHED的，第二，连接池做为上层应用，会有定时的心跳去保持连接的活跃性。既然连接都是活跃的，那就不存在有TIME_WAIT的概念了，在上篇里也有提到，TIME_WAIT是在主动关闭连接的一方，在关闭连接后才进入的状态。既然已经关闭了，那么这条连接肯定已经不在连接池里面了，即被连接池释放了。

net.ipv4.tcp_tw_recycle

字面意思，销毁掉 TIME_WAIT。

当开启了这个配置后，内核会快速的回收处于TIME_WAIT状态的socket连接。不再是2MSL，而是一个RTO（retransmission timeout，数据包重传的timeout时间）的时间，这个时间根据RTT动态计算出来，但是远小于2MSL。

有了这个配置，还是需要保障 丢失重传或者延迟的数据包，不会被新的连接错误接收(注意，这里不再是复用了，而是之前处于TIME_WAIT状态的连接已经被destroy掉了，新的连接，刚好是和某一个被destroy掉的连接使用了相同的五元组而已)。在启用该配置，当一个socket连接进入TIME_WAIT状态后，内核里会记录包括该socket连接对应的五元组中的对方IP等在内的一些统计数据，当然也包括从该对方IP所接收到的最近的一次数据包时间。当有新的数据包到达，只要时间晚于内核记录的这个时间，数据包都会被统统的丢掉。

这个配置，依赖于连接双方对timestamps的支持。同时，这个配置，主要影响到了inbound的连接（对outbound的连接也有影响，但是不是复用），即做为服务端角色，客户端连进来，服务端主动关闭了连接，TIME_WAIT状态的socket处于服务端，服务端快速的回收该状态的连接。

其它优化方案

作为负载均衡的机器随机端口使用完的情况下大量time_wait，如果不调整上文的那三个参数，还有其他的更好的方案吗？

第一，随机端口使用完，你可以通过调整/etc/sysctl.conf下的net.ipv4.ip_local_port_range配置，至少修改成 net.ipv4.ip_local_port_range=1024 65535，保证你的负载均衡服务器至少可以使用6万个随机端口，也即可以有6万的反向代理到后端的连接，可以支持每秒1000的并发（想一想，因为TIME_WAIT状态会持续1分钟后消失，所以一分钟最多有6万，每秒1000）；如果这么多端口都使用完了，也证明你应该加服务器了，或者，你的负载均衡服务器需要配置多个IP地址，或者，你的后端服务器需要监听更多的端口和配置更多的IP（想一下socket的五元组）
第二，大量的TIME_WAIT，多大量？如果是几千个，其实不用担心，因为这个内存和CPU的消耗有一些，但是是可以忽略的。
第三，如果真的量很大，上万上万的那种，可以考虑，让后端的服务器主动关闭连接，如果后端服务器没有外网的连接只有负载均衡服务器的连接（主要是没有NAT网络的连接），可以在后端服务器上配置tw_recycle，然后同时，在负载均衡服务器上，配置tw_reuse。

参考

背包问题整理

Thu, 09 Sep 2021 15:10:06 +0000

背包定义

那么什么样的问题可以被称作为背包问题？换言之，我们拿到题目如何透过题目的不同包装形式看到里面背包问题的不变内核呢？

我对背包问题定义的理解：给定一个背包容量target，再给定一个数组nums(物品)，能否按一定方式选取nums中的元素得到target。

注意：

背包容量target和物品nums的类型可能是数，也可能是字符串
target可能题目已经给出(显式)，也可能是需要我们从题目的信息中挖掘出来(非显式)(常见的非显式target比如sum/2等)
选取方式有常见的一下几种：每个元素选一次/每个元素选多次/选元素进行排列组合

背包问题的分类

常见的背包类型主要有以下几种：

01背包问题：每个元素最多选取一次 dp[i][j]表示从0-i个物品中选择不超过重量j的物品的最大价值
完全背包问题：每个元素可以重复选择
多重背包问题：每个元素是有限个的
组合背包问题：背包中的物品要考虑顺序
分组背包问题：不止一个背包，需要遍历每个背包

而每个背包问题要求的也是不同的，按照所求问题分类，又可以分为以下几种：

最值问题：要求最大值/最小值
存在问题：是否存在…………，满足…………
组合问题：求所有满足……的排列组合

因此把背包类型和问题类型结合起来就会出现以下细分的题目类型(几乎可以涵盖力扣上所有的背包问题)：

背包最值问题
01背包存在问题
01背包组合问题
完全背包最值问题
完全背包存在问题
完全背包组合问题
分组背包最值问题
分组背包存在问题
分组背包组合问题

01背包

01背包：有n种物品与承重为m的背包。每种物品只有一件，每个物品都有对应的重量weight[i]与价值value[i]，求解如何装包使得价值最大。

为什么叫它01背包呢，因为装进去就是1，不装进去就是0.所以针对每个物品就两种状态，装，不装。所以只要背包有足够大的空间，这个物品是有可能被装进去的咯。所以有状态转移方程：dp[i][j] = max( dp[i-1][j] , dp[i-1][ j - weight[i] ] + value[i] )

// 0-1背包问题母代码(二维)
public int bags(){
  int[] weight = new int[]{1,3,4}; // 各个物品的重量
  int[] value = new int[]{15,20,30}; // 各个物品对应的价值
  int bagWeight = 4; // 背包最大容量

  // 状态定义：dp[i][j]表示从0-i个物品中选择不超过重量j的物品的最大价值
  int[][] dp = new int[weight.length()+1][bagWeight+1];

  // 初始化：第一列都是0(背包重量为0时啥都翻不了，价值都为0)；第一行表示只选0号物品时的最大价值(首先要保证能容纳下0号物品的重量)
  for(int j = weight[0]; j <= bagWeight ; j++){
    dp[0][j] = dp[0][j-weight[0]] + value[0];
  }

  // 遍历方向：当前状态只与正上方和左上方的那行相关
  for(int i = 1; i< weight.length(); i++){ // 遍历物品(第0个物品已经初始化了)
    for(int j = 0; j <= bagWeight; j++){ // 遍历背包容量
      if(j < weight[i]){ // 背包容量已经不足以放下第i个物品，因此最大价值就和上一个状态一致
        dp[i][j] = dp[i-1][j]; 
      }else{ 
        // 背包容量足够，可拿可不拿：拿了最大价值是前i-1个物品扣除第i个物品的 重量的最大价值加上i个物品的价值
        // 不拿就是前i-1个物品的最大价值,两者进行比较取较大的
        dp[i][j] = Math.max(dp[i-1][j], dp[i-1][j-weight[i]]+value[i]);
      }
    }
  }
  return dp[weight.length()-1][bagWeight];
}

二维代码可以进行优化，去除选取物品的那一层，简化为一维背包。其实就是把状态压缩，都在同一行做处理。

public int bags(){
  int[] weight = new int[]{1,3,4}; // 各个物品的重量
  int[] value = new int[]{15,20,30}; // 各个物品对应的价值
  int bagWeight = 4; // 背包最大容量

  // 状态定义: dp[j]表示容量为j的背包能放下东西的最大价值。
  // 初始化: dp[0]=0
  int[] dp = new int[bagWeight+1];

  // dp[i][j] 都是通过上一行 dp[i-1][..] 转移过来的，之前的数据都不会再使用了。
  for(int i = 1; i< weight.length(); i++){ // 遍历物品
    for(int j = bagWeight; j >= weight[i]; j--){ // 逆向遍历是为了防止覆盖状态,j<=weight[i]时，dp[j]=dp[j]可以省略;也可以理解成防止重复添加数据
      dp[j] = Math.max(dp[j], dp[j - weight[i]] + value[i]); // 不取或者取第i个
    }
  }
  return dp[bagWeight];
}

完全背包

完全背包：有n种物品与承重为m的背包。每种物品有无限多件，每个物品都有对应的重量weight[i]与价值value[i]，求解如何装包使得价值最大。

在下面的讲解中，我依然举这个例子：背包最大重量为4。

物品为：

	重量	价值
物品0	1	15
物品1	3	20
物品2	4	30

首先在回顾一下01背包的核心代码：

  for(int i = 1; i< weight.length(); i++){ // 遍历物品
    for(int j = bagWeight; j >= weight[i]; j--){ // 逆向遍历是为了防止覆盖状态,j<=weight[i]时，dp[j]=dp[j]可以省略;也可以理解成防止重复添加数据
      dp[j] = Math.max(dp[j], dp[j - weight[i]] + value[i]); // 不取或者取第i个
    }
  }

我们知道01背包内嵌的循环是从大到小遍历，为了保证每个物品仅被添加一次。

而完全背包的物品是可以添加多次的，所以要从小到大去遍历，即：

// 先遍历物品，再遍历背包
// dp[i][j]表示从0-i个物品中选择不超过重量j的物品的最大价值
for(int i = 0; i < weight.size(); i++) { // 遍历物品
  for(int j = weight[i]; j <= bagWeight ; j++) { // 遍历背包容量
    dp[j] = Math.max(dp[j], dp[j - weight[i]] + value[i]);
  }
}

dp状态图：

背包问题解题模板

背包问题大体的解题模板是两层循环，分别遍历物品重量weight和背包容量bagWeight，然后写转移方程，根据背包的分类我们确定物品和容量遍历的先后顺序，根据问题的分类我们确定状态转移方程的写法。

首先是背包分类的模板(先要明确题目中的weight数组和bagWeight到底是什么)：

01背包：外循环物品重量, 内循环背包容量, bagWeight 倒序且 >= weight[i]
完全背包：外循环物品重量, 内循环背包容量, bagWeight 正序且 >= weight[i]
组合背包(考虑顺序)：外循环背包容量, 内循环物品重量, bagWeight 正序且 >= weight[i]
分组背包：这个比较特殊，需要三重循环：外循环背包bags,内部两层循环根据题目的要求转化为1,2,3三种背包类型的模板

然后是问题分类的模板：

最值问题(最大价值，最少硬币数之类的): dp[j] = max/min(dp[j], dp[j - weight[i]] + 1)或dp[j] = max/min(dp[j], dp[j - weight[i]] + vlaue[i])
存在问题(bool)：dp[j] = dp[j] || dp[j - weight[i]]
组合问题(装满背包有几种方法)：dp[j] += dp[j - weight[i]]

LeetCode！

题目	算法思想
#322. 零钱兑换	完全背包最值问题：外循环coins,内循环amount正序
#494. 目标和	0-1背包不考虑元素顺序的组合问题:选nums里的数得到target的种数,外循环nums,内循环target倒序
#416. 分割等和子集	0-1背包存在性问题：是否存在一个子集,其和为target=sum/2,外循环nums,内循环target倒序
#518. 零钱兑换 II	完全背包不考虑顺序的组合问题：外循环coins,内循环target正序
279. 完全平方数	完全背包的最值问题：外循环nums,内循环target正序
377. 组合总和 Ⅳ	考虑顺序的组合问题：外循环target,内循环nums
1049. 最后一块石头的重量 II	0/1背包最值问题：外循环stones,内循环target=sum/2倒序

Nacos原理

Wed, 08 Sep 2021 12:21:16 +0000

服务注册与发现

服务注册

服务注册，这个是个动作，那么注册到哪里了呢，那就需要在注册中心有个容器来存储注册上来的服务。这个容器可能是map，数组，持久化的mysql，mongodb。有了容器存储之后那我们就想那注册上来的是啥呢？也就是存在容器中的内容是什么呢？其实放在容器中的主要信息就是微服务各个节点所在的ip+端口。之后调用端才能知道你服务提供方在哪提供服务，这样调用端才能顺着这条线去调用服务。

作为注册中心的功能来说，Nacos提供的功能与其他主流框架很类似，基本都是围绕服务实例注册、实例健康检查、服务实例获取这三个核心来实现的。

以Java版本的Nacos客户端为例，服务注册基本流程：

服务实例启动将自身注册到Nacos注册中心，随后维持与注册中心的心跳；
心跳维持策略为每5秒向Nacos Server发送一次心跳，并携带实例信息（服务名、实例IP、端口等）；
Nacos Server也会向Client主动发起健康检查，支持TCP/Http；
15秒内无心跳且健康检查失败则认为实例不健康，如果30秒内健康检查失败则移除实例；
服务消费者通过注册中心获取实例，并发起调用；

服务发现

服务发现支持两种场景：

服务消费者直接向注册中心发送获取某服务实例的请求，注册中心返回所有可用实例，但一般不推荐此种方式；
⭐️ 服务消费者向注册中心订阅某服务，并提交一个监听器，当注册中心中服务发生变化时，监听器会收到通知，消费者更新本地服务实例列表，以保证所有的服务均可用。

如上图如果消费者订阅了服务，那么会在本地基于内存维护一个服务信息列表，之后进行服务调用是直接从本地列表获取对应的服务实例进行调用，否则去主从中心获取服务实例。

二者之间是怎么调用的

服务提供者与服务消费者之间是通过feign+ribbon进行配合调用的，feign提供http请求的封装以及调用，ribbon提供负载均衡。负载均衡有很多中实现方式，包括轮询法，随机方法法，对请求ip做hash后取模等等。 Nacos 的客户端在获取到服务的完整实例列表后，会在客户端进行负载均衡算法来获取一个可用的实例，默认使用的是随机获取的方式。

配置中心原理

客户端

获取配置

获取配置的主要方法是 NacosConfigService 类的 getConfigInner 方法，通常情况下该方法直接从本地文件中取得配置的值，如果本地文件不存在或者内容为空，则再通过 HTTP GET 方法从远端拉取配置，并保存到本地快照中。

当通过 HTTP 获取远端配置时，Nacos 提供了两种熔断策略，一是超时时间，二是最大重试次数，默认重试三次。

注册监听器

配置中心客户端对某个配置项注册监听器是很常见的需求，达到在配置项变更的时候执行回调的功能。

iconfig.addListener(dataId, group, ml);
iconfig.getConfigAndSignListener(dataId, group, 1000, ml);

Nacos 可以通过以上方式注册监听器，它们内部的实现均是调用 ClientWorker 类的 addCacheDataIfAbsent。其中 CacheData 是一个维护配置项和其下注册的所有监听器的实例。

所有的 CacheData 都保存在 ClientWorker 类中的原子 cacheMap 中，其内部的核心成员有：

其中，content 是配置内容，MD5 值是用来检测配置是否发生变更的关键，内部还维护着一个若干监听器组成的数组，一旦发生变更则依次回调这些监听器。

配置长轮询

ClientWorker 通过其下的两个线程池完成配置长轮询的工作，一个是单线程的 executor，每隔 10ms 按照每 3000 个配置项为一批次捞取待轮询的 cacheData 实例，将其包装成为一个 LongPollingTask 提交进入第二个线程池 executorService 处理。

该长轮询任务内部主要分为四步：

检查本地配置，忽略本地快照不存在的配置项，检查是否存在需要回调监听器的配置项
如果本地没有配置项的，从服务端拿，返回配置内容发生变更的键值列表
每个键值再到服务端获取最新配置，更新本地快照，补全之前缺失的配置
检查 MD5 标签是否一致，不一致需要回调监听器

如果该轮询任务抛出异常，等待一段时间再开始下一次调用，减轻服务端压力。另外，Nacos 在 HTTP 工具类中也有限流器的代码，通过多种手段降低轮询或者大流量情况下的风险。下文还会讲到，如果在服务端没有发现变更的键值，那么服务端会夯住这个 HTTP 请求一段时间（客户端侧默认传递的超时是 30s），以此进一步减轻客户端的轮询频率和服务端的压力。

服务端

配置 Dump

服务端启动时就会依赖 DumpService 的 init 方法，从数据库中 load 配置存储在本地磁盘上，并将一些重要的元信息例如 MD5 值缓存在内存中。服务端会根据心跳文件中保存的最后一次心跳时间，来判断到底是从数据库 dump 全量配置数据还是部分增量配置数据（如果机器上次心跳间隔是 6h 以内的话）。

全量 dump 当然先清空磁盘缓存，然后根据主键 ID 每次捞取一千条配置刷进磁盘和内存。增量 dump 就是捞取最近六小时的新增配置（包括更新的和删除的），先按照这批数据刷新一遍内存和文件，再根据内存里所有的数据全量去比对一遍数据库，如果有改变的再同步一次，相比于全量 dump 的话会减少一定的数据库 IO 和磁盘 IO 次数。

配置注册

Nacos 服务端是一个 SpringBoot 实现的服务，注册配置主要代码位于 ConfigController 和 ConfigServletInner 中。服务端一般是多节点部署的集群，因此请求一开始只会打到一台机器，这台机器将配置插入 MySQL 中进行持久化，这部分代码很简单不再赘述。

因为服务端并不是针对每次配置查询都去访问 MySQL 的，而是会依赖 dump 功能在本地文件中将配置缓存起来。因此当单台机器保存完毕配置之后，需要通知其他机器刷新内存和本地磁盘中的文件内容，因此它会发布一个名为 ConfigDataChangeEvent 的事件，这个事件会通过 HTTP 调用通知所有集群节点（包括自身），触发本地文件和内存的刷新。

处理长轮询

上文提到，客户端会有一个长轮询任务，拉取服务端的配置变更，那么服务端是如何处理这个长轮询任务的呢？源码逻辑位于 LongPollingService 类，其中有一个 Runnable 任务名为 ClientLongPolling，服务端会将受到的轮询请求包装成一个 ClientLongPolling 任务，该任务持有一个 AsyncContext 响应对象（Servlet 3.0 的新机制），通过定时线程池延后 29.5s 执行。

为什么比客户端 30s 的超时时间提前 500ms 返回是为了最大程度上保证客户端不会因为网络延时造成超时

这里需要注意的是，在 ClientLongPolling 任务被提交进入线程池待执行的同时，服务端也通过一个队列 allSubs 保存了所有正在被夯住的轮询请求，这是因为在配置项被夯住的期间内，如果用户通过管理平台操作了配置项变更、或者服务端该节点收到了来自其他节点的 dump 刷新通知，那么都应立即取消夯住的任务，及时通知客户端数据发生了变更。

为了达到这个目的，LongPollingService 类继承自 Event 接口，实际上本身是个事件触发器，需要实现 onEvent 方法，其事件类型是 LocalDataChangeEvent。

当服务端在请求被夯住的期间接收到某项配置变更时，就会发布一个 LocalDataChangeEvent 类型的事件通知（注意同上文中的 ConfigDataChangeEvent 区别），之后会将这个变更包装成一个 DataChangeTask 异步执行，内容就是从 allSubs 中找出夯住的 ClientLongPolling 请求，写入变更强制其立即返回。

总结

nacos是采用了拉模式是一种特殊的拉模式，也就是我们通常听的长轮询机制：

1）如果服务端配置发生了变化

2）如果服务端配置与客户端一直没有变化

如果客户端拉取发现自己与服务端配置是一致的（其实是通过MD5判断的）那么服务端会先拿住这个请求不返回，直到这段时间内配置有变化了才把刚才拿住的请求返回。他的步骤是nacos服务端收到请求后检查配置是否发生变化，如果没有则开启定时任务，延迟29.5s执行。同时把当前客户端的连接请求放入队列。那么此时服务端并没有将结果返回给客户端，当有以下2种情况的时候才触发返回。

就是等待29.5s后触发自动检查
在29.5s内有配置进行了更改

经过这2种情况才完成这次的pull操作。这种的好处就是保证了客户端的配置能及时变化更新，也减少了轮询给服务端带来的压力。所以之前文章我们说过这个长链接会话超时时间默认是30s。

简单总结一下整个过程：

客户端发起长轮询请求
服务端收到请求以后，先比较服务端缓存中的数据是否相同，如果不同，则直接返回
如果相同，则通过schedule延迟29.5s之后再执行比较
为了保证当服务端在29.5s之内发生数据变化能够及时通知给客户端，服务端采用事件订阅的方式来监听服务端本地数据变化的事件，一旦收到事件，则触发DataChangeTask的通知，并且遍历allStubs队列中的ClientLongPolling,把结果写回到客户端，就完成了一次数据的推送
如果 DataChangeTask 任务完成了数据的 “推送” 之后，ClientLongPolling 中的调度任务又开始执行了怎么办呢？很简单，只要在进行 “推送” 操作之前，先将原来等待执行的调度任务取消掉就可以了，这样就防止了推送操作写完响应数据之后，调度任务又去写响应数据，这时肯定会报错的。所以，在ClientLongPolling方法中，最开始的一个步骤就是删除订阅事件

所以总的来说，Nacos采用推+拉的形式，来解决最开始关于长轮训时间间隔的问题。当然，30s这个时间是可以设置的，而之所以定30s，应该是一个经验值。

参考

ES读写数据的过程

Wed, 08 Sep 2021 12:21:16 +0000

基础知识

分片和分段

“分片”是Lucene的一个索引。它本身就是一个功能齐全的搜索引擎。每个分片包含多个“分段”，其中分段是倒排索引。

分段内的doc数量上限是2的31次方。默认每秒都会生成一个segment文件。

在分片中搜索将依次搜索每个片段，然后将其结果合并到该分片的最终结果中。分段是不可变的。更新文档时，它实际上只是将旧文档标记为已删除，并为新文档编制索引。合并过程还会清除这些旧的已删除文档。

document路由算法

shard = hash(文档id) % number_of_primary_shards；即用 主分片数 对 文档id的hash 取余。
另外也可以手动指定routing value。可以保证某一类document一定被路由到一个shard上去，那么在后续进行应用级别的负载均衡，以及提升批量读取的性能的时候是很有帮助的。

primary shard 能随时改变吗

不能，如果改变了主分片的数目。那么使用路由算法就无法计算出原来分片，间接导致了数据丢失。

replica shard从分片可以改变吗

备份分片数是可以修改的，因为备份分片和路由算法无关。

写数据过程

客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

读数据过程

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。
客户端发送请求到任意一个 node，成为 coordinate node。
coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin轮询算法，在 primary shard 以及其所有 replica shard 中随机选择一个，让读请求负载均衡。
接收请求的 node 返回 document 给 coordinate node。
coordinate node 返回 document 给客户端。

搜索数据过程

你根据 java 关键词来搜索，将包含 java的 document 给搜索出来

客户端发送请求到一个 coordinate node。
协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard，都可以。
query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

写请求是写入 primary shard，然后同步给所有的 replica shard；

读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。

写数据底层原理

文档先写入内存buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。
然后会有一个refresh的操作，默认每隔1秒钟就会将buffer中的数据刷入到操作系统缓存os cache中并清空buffer，这时候数据就能被搜索到了。所以，es是近实时的，数据写入到可以被搜索，默认是1秒。此外每隔5s还会将os cache中数据记录到translog中。
一直重复以上步骤直到translog日志文件达到一定长度或者30分钟后就会执行commit操作。首先会在磁盘中记录一个commit point(保存了当前Shard成功写入磁盘的所有segment)，然后os cache中的所有segment file缓存都会被fsync强制刷到磁盘上，最后清空并创建一个新的translog。
另外因为每秒都会产生一个segment文件，导致每次搜索都要遍历所有segment。因此会在后台执行segment的merge操作，被标记为deleted的document也会被彻底物理删除。具体就是会选择一些相似大小的segment合并成一个大的segment，然后写一个新的commit point加入新的分段并移除旧的分段，最后将新的segment打开以供搜索并删除旧的分段。

refresh Index会刷到所有从节点吗

是刷在主节点的，然后refresh可以配置为true和wati_for和false
- true表示更新数据之后，立刻对相关的分片(包括副本) 刷新，这个刷新操作保证了数据更新的结果可以立刻被搜索到。
- 这个参数表示，刷新不会立刻进行，而是等待一段时间才刷新 ( index.refresh_interval)，默认时间是 1 秒。
- refresh 的默认值，更新数据之后不立刻刷新，在返回结果之后的某个时间点会自动刷新，也就是随机的，看es服务器的运行情况。

为什么 es 是准实时的

数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。数据写入 segment file 之后，同时就建立好了倒排索引。

综上，其实 es 第一是准实时的，数据写入 1 秒后可以搜索到；可能会丢失数据的。有 5 秒的数据，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的数据丢失。

删除/更新数据底层原理

如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。
- buffer 每 refresh 一次，就会产生一个 segment file，所以默认情况下是 1 秒钟一个 segment file，这样下来 segment file 会越来越多
- 此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个。同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘。这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。

ES倒排索引原理

Tue, 07 Sep 2021 07:11:16 +0000

Elasticsearch 是一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎. 当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:

分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
实时分析的分布式搜索引擎。
可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表,已删除)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。

基础概念

Term Dictionary

Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样。

Term Index

B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树。这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。

Posting List

Posting List是一个int类型的数组，存储了所有符合某个term的文档id。

假设有这么几条数据:

ID	Name	Age	Sex
1	Kate	24	Female
2	John	24	Male
3	Bill	29	Male

ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下:

Name:

Term	Posting List
Kate	1
John	2
Bill	3

Age:

Term	Posting List
24	[1,2]
29	3

Sex:

Term	Posting List
Female	1
Male	[2,3]

Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。

通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？

Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。

这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找：

term index压缩

FST

所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。

假设我们现在要将mop, moth, pop, star, stop，top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的做法就是定义个Map<String, Integer>，大家找到自己的位置对应入座就好了。缺点就是内存开销过大，因此就有了FST。

⭕️表示一种状态

–>表示状态的变化过程，上面的字母/数字表示状态变化和权重

将单词分成单个字母通过⭕️和–>表示出来，0权重不显示。如果⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。

FST以字节的方式存储所有的term，这种压缩方式可以有效的缩减存储空间，使得term index足以放进内存，但这种方式也会导致查找时需要更多的CPU资源。

posting list压缩

增量编码压缩

增量编码压缩(Frame Of Reference)，将大数变小数，按字节存储

首先，Elasticsearch要求posting list是有序的(为了提高搜索的性能，再任性的要求也得满足)，这样做的一个好处是方便压缩，看下面这个图例：

227 需要8bit才能表示 0-2^8-1
30 则只需要5bit即可

原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后通过字节存储，而不是就算是一个2也是用int(4个字节)来存储。

Roaring bitmaps

说到Roaring bitmaps，就必须先从bitmap说起。Bitmap是一种数据结构，假设有某个posting list：[1,3,4,7,10]

对应的bitmap就是：[1,0,1,1,0,0,1,0,0,1]

非常直观，用0/1表示某个值是否存在，比如10这个值就对应第10位，对应的bit值是1，这样用一个字节就可以代表8个文档id，旧版本(5.0之前)的Lucene就是用这样的方式来压缩的，但这样的压缩方式仍然不够高效，如果有1亿个文档，那么需要12.5MB的存储空间，这仅仅是对应一个索引字段(我们往往会有很多个索引字段)。于是有人想出了Roaring bitmaps这样更高效的数据结构。

Bitmap的缺点是存储空间随着文档个数线性增长，Roaring bitmaps需要打破这个限制就一定要用到某些指数特性：

将posting list按照65535为界限分块，比如第一块所包含的文档id范围在0-65535之间，第二块的id范围是65536-131071，以此类推。再用<商，余数>的组合表示每一组id，这样每组里的id范围都在0~65535内了，剩下的就好办了，既然每组id不会变得无限大，那么我们就可以通过最有效的方式对这里的id存储。

为什么是以65535为界限?

因为它正好是用2个字节能表示的最大数，是一个short的存储单位，注意到上图里的最后一行“If a block has more than 4096 values, encode as a bit set, and otherwise as a simple array using 2 bytes per value”，如果是大块，用节省点用bitset存，小块就豪爽点，2个字节我也不计较了，用一个short[]存着方便。

那为什么用4096来区分采用数组还是bitmap的阀值呢？

这个是从内存大小考虑的，当block块里元素超过4096后，用bitmap更省空间：采用bitmap需要的空间是恒定的: 65536bit/8 = 8192字节而如果采用short[]，所需的空间是: 2字节*N(N为数组元素个数) ，而N=4096刚好是边界:

联合索引

上面说了半天都是单field索引，如果多个field索引的联合查询，倒排索引如何满足快速查询的要求呢？

利用跳表(Skip list)的数据结构快速做“与”运算
或者利用上面提到的bitset按位“与”

跳表：将一个有序链表level0，挑出其中几个元素到level1、level2和level3，每个level越往上，选出来的指针元素越少，查找时依次从高level往低查找，比如8，先找到level3的2，再找到level2的2，最后找到8，一共3次查找，查找效率和二叉树的效率相当，但也是用了一定的空间冗余来换取的。

假设有下面三个posting list需要联合索引：

如果使用跳表，对最短的posting list中的每个id，逐个在另外两个posting list中查找看是否存在，最后得到交集的结果。

如果使用bitset，就很直观了，直接按位与，得到的结果就是最后的交集。

总结

所以，对于使用Elasticsearch进行索引时需要注意:

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询

上面的压缩算法都是对Posting list里的大量ID进行压缩的，那如果ID是顺序的，或者是有公共前缀等具有一定规律性的ID，压缩比会比较高；

另外一个因素: 可能是最影响查询性能的，应该是最后通过Posting list里的ID到磁盘中查找Document信息的那步，因为Elasticsearch是分Segment存储的，根据ID这个大范围的Term定位到Segment的效率直接影响了最后查询的性能，如果ID是有规律的，可以快速跳过不包含该ID的Segment，从而减少不必要的磁盘读次数。

MySQL 事务

Tue, 07 Sep 2021 07:11:16 +0000

春招实习的整理了一大堆笔记，现在记忆又有些模糊了，刚好趁着秋招重新梳理一遍MySQL事务相关的知识，逐渐恢复高产吧👾。

事务相关的一些基础概念

事务是指满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。

ACID

A是原子性，表示事务是不可分割的，要么全部成功要么全部回滚。C是一致性，表示事务在执行前后都保持状态的一致，侧重的是业务的逻辑。I是隔离型，表示事务在提交之前，其他事务是不可见的。D是持久性，表示事务一旦提交，就会永远保存在数据库中，即使系统崩溃也不会丢失事务的执行结果。其中一致性是依赖于其他三种特性的。

原子性：事务被视为不可分割的最小单元，事务的所有操作要么全部成功，要么全部失败回滚。
一致性：数据库在事务执行前后都保持一致性状态，侧重点是业务逻辑和规则。
隔离性：一个事务所做的修改在最终提交以前，对其他事务是不可见的。
持久性：一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢。

ACID的实现方式

其中原子性是通过undo log回滚日志来实现的，每条数据的变化都会产生一条记录，比如插入一条数据undolog就会记录一条删除该信息的语句。这样回滚的时候就可以执行这条语句达到未修改前的状态。隔离性这是用各种锁策略和多版本并发控制MVCC来实现的。持久性这是使用redo log重做日志实现的，但事务提交的时候会把所有的修改信息放在redo log中并持久化到磁盘，当电脑重启后就会执行redo log的内容来恢复数据。一致性这是依赖于上面三种特性来实现的。

原子性：undo log称之为回滚日志，每条数据的变化（insert/update/delete）都会产生一条记录，并且日志持久化到磁盘，undo log用来记录数据修改前的信息，比如说要插入一条记录，那么undo log就会记录一条删除该信息的语句，这样你需要回滚的时候那么undo log就会执行删除你之前插入的那条记录，达到没有修改前的状态。
隔离性：由各种锁策略和mvcc实现。
持久性：redo log叫重做日志，当事务提交的时候会把所有的修改信息存放在redo log中，并且会把redo log持久化到磁盘，当电脑重启后就会重新执行redo log的修改信息来恢复数据，这样就能够达到持久化的目的。
一致性依赖于其他三种特性：原子性，隔离性，持久性。

ACID 之间的关系

事务的 ACID 特性概念很简单，但不好理解，主要是因为这几个特性不是一种平级关系：

只有满足一致性，事务的结果才是正确的。
在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
事务满足持久化是为了能应对数据库崩溃的情况。

隔离级别

事务的隔离级别有读未提交，表示别的事务可以看见一个事务还未提交的修改。读已提交表示，别的事务只能读取已经提交的事务。可重复度表示在同一个事物中多次读取同样的数据结果是一样的，是默认的隔离级别。可串行化则是强制事务串行执行，需要加锁实现，效率比较低。

读未提交（READ UNCOMMITTED）：事务中的修改，即使没有提交，对其他事务也是可见的。
读已提交（READ COMMITTED）：一个事务只能读取已经提交的事务所做的修改。
可重复读（REPEATABLE READ）：保证在同一个事务中多次读取同样数据的结果是一样的。也就是某个事务在执行的过程中，不允许其他事务进行update操作，但允许其他事务进行insert或delete操作，造成某个事务前后多次读取到的数据总量不一致的现象，从而产生幻读。MySQL默认级别。
可串行化（SERIALIZABLE）：强制事务串行执行。需要加锁实现，而其它隔离级别通常不需要。

隔离级别	脏读	不可重复读	幻读
读未提交	√	√	√
读已提交	×	√	√
可重复读	×	×	√
可串行化	×	×	×

脏读：不同事务下，当前事务可以读取到另外事务未提交的数据。事务A在查询的时候，事务B修改了查询结果，然后B发生了回滚。
不可重复度：同一事务内多次读取同一数据集合，读取到的数据是不一样的情况。事务A在执行读取操作，由整个事务A比较大，前后读取同一条数据需要经历很长的时间。而在事务A第一次读取数据，比如此时读取了小明的年龄为20岁，事务B执行更改操作，将小明的年龄更改为30岁，此时事务A第二次读取到小明的年龄和之前的数据不一样了，系统不可以读取到相同的数据。
幻读：同一事务前后多次读取，数据总量不一致。事务A在执行读取操作，需要两次统计数据的总量，前一次查询数据总量后，此时事务B执行了新增数据的操作并提交后，这个时候事务A读取的数据总量和之前统计的不一样，就像产生了幻觉一样，平白无故的多了几条数据，成为幻读。

锁类型

共享锁/读锁（S Lock）：针对同一份数据，多个读操作可以同时进行而不会互相影响
排他锁/写（X Lock）：当前写操作没有完成前，它会阻断其他写锁和读锁。
意向锁的存在是为了协调行锁和表锁的关系，如果事务A对某一行上锁，其他事务就不可能修改这一行。这与“事务B锁住整个表就能修改表中的任意一行”形成了冲突。有了意向锁之后，前面例子中的事务A在申请行锁（写锁）之前，数据库会自动先给事务A申请表的意向排他锁。当事务B去申请表的写锁时就会失败，因为表上有意向排他锁之后事务B申请表的写锁时会被阻塞。
- 意向共享锁（IS Lock）：事务想要获得一张表中某几行的读锁，同时给该事务申请表的意向共享锁
- 意向排他锁（IX Lock）：事务想要获得一张表中某几行的写锁，同时给该事务申请表的意向排他锁

为什么意向锁是表级锁呢？

当我们需要加一个排他锁时，需要根据意向锁去判断表中有没有数据行被锁定（行锁）；

如果意向锁是行锁，则需要遍历每一行数据去确认；
如果意向锁是表锁，则只需要判断一次即可知道有没数据行被锁定，提升性能。

意向锁怎么支持表锁和行锁并存？

首先明确并存的概念是指数据库同时支持表、行锁，而不是任何情况都支持一个表中同时有一个事务A持有行锁、又有一个事务B持有表锁，因为表一旦被上了一个表级的写锁，肯定不能再上一个行级的锁。
如果事务A对某一行上锁，其他事务就不可能修改这一行。这与“事务B锁住整个表就能修改表中的任意一行”形成了冲突。所以，没有意向锁的时候，让行锁与表锁共存，就会带来很多问题。于是有了意向锁的出现，如q1的答案中，数据库不需要在检查每一行数据是否有锁，而是直接判断一次意向锁是否存在即可，能提升很多性能。
有了意向锁之后，前面例子中的事务A在申请行锁（写锁）之前，数据库会自动先给事务A申请表的意向排他锁。当事务B去申请表的写锁时就会失败，因为表上有意向排他锁之后事务B申请表的写锁时会被阻塞。

MVCC 多版本并发控制

MVCC主要是为了提高数据库的并发性能，即使存在读写冲突，也可以做到不加锁非阻塞地读取数据。隔离级别中的读已提交和可重复读都是用MVCC实现的快照读，不过这种方式读到的不一定是最新的数据。

多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式：
- MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。
- 用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
- 写写冲突由乐观锁或者悲观锁来解决。

基础概念

版本号
- 系统版本号：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。
- 事务版本号：事务开始时的系统版本号。
隐藏的列：MVCC 在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：
- 创建版本号：保存了行的事务版本号，指示创建一个数据行的快照时的系统版本号；
- 删除版本号：保存了行的回滚指针，如果该快照的删除版本号大于当前事务版本号表示该快照有效，否则表示该快照已经被删除了。
Undo 日志
- update undo log：事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除
- insert undo log：代表事务在insert新记录时产生的undo log, 因为insert操作只对当前事务本身可见，所以在事务提交后可以被立即丢弃，而不需要purge操作。
- MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。

可重复读隔离级别实现过程

MVCC主要是为了提高数据库的并发性能，即使存在读写冲突，也可以做到不加锁非阻塞地读取数据。隔离级别中的读已提交和可重复度都是用MVCC实现的快照读，不过这种方式读到的不一定是最新的数据。MVCC是通过Undo日志和每行数据隐藏的两个版本号实现的。undolog日志会通过回滚指针把一个数据行（Record）的所有快照连接起来。然后创建版本号的话会记录当前事务的版本号，删除版本号的话会记录当前行的回滚指针。在进行select快照读时，要读取数据行的创建版本号必须小于当前的创建版本号，并且它的删除版本号也必须是未定义或者大于当前的创建版本号。

当开始一个事务时，该事务的版本号肯定大于当前所有数据行快照的创建版本号。数据行快照的创建版本号是创建数据行快照时的系统版本号，系统版本号随着创建事务而递增，因此新创建一个事务时，这个事务的系统版本号比之前的系统版本号都大，也就是比所有数据行快照的创建版本号都大。

SELECT
- 多个事务必须读取到同一个数据行的快照，并且这个快照是距离现在最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
- 把没有对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于等于 T 的版本号，因为如果大于 T 的版本号，那么表示该数据行快照是其它事务的最新修改，因此不能去读取它。除此之外，T 所要读取的数据行快照的删除版本号必须是未定义或者大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删除的，不应该去读取它。
INSERT：将当前系统版本号作为数据行快照的创建版本号。
DELETE：将当前系统版本号作为数据行快照的删除版本号。
UPDATE：将当前系统版本号作为更新前的数据行快照的删除版本号，并将当前系统版本号作为更新后的数据行快照的创建版本号。可以理解为先执行 DELETE 后执行 INSERT。

快照读与当前读

⭐️ 在 InnoDB 存储引擎中，SELECT 操作的不可重复读问题通过 MVCC 得到了解决，而 UPDATE、DELETE 的不可重复读问题通过 Record Lock 解决，INSERT 的不可重复读问题是通过 Next-Key Lock（Record Lock + Gap Lock）解决的。

在可重复读级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据！这在一些对于数据的时效特别敏感的业务中，就很可能出问题。

对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：

MVCC 的 SELECT 操作是快照中的数据，不需要进行加锁操作。 — 快照读
MVCC 其它会对数据库进行修改的操作（INSERT、UPDATE、DELETE）需要进行加锁操作，从而读取最新的数据。可以看到 MVCC 并不是完全不用加锁，而只是避免了 SELECT 的加锁操作。 — 当前读

⭐️：在进行 SELECT 操作时，可以强制指定进行加锁操作。以下第一个语句需要加读锁，第二个需要加写锁。

select * from table where ? lock in share mode;
select * from table where ? for update;

事务的隔离级别实际上都是定义的当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。而update、insert这些“当前读”的隔离性，就需要通过加锁来实现了,可重复读会自动给涉及数据加排他锁。

三种行锁

Record Lock 记录锁

单条索引记录上加锁，id 列必须为唯一索引列或主键列。
如果表没有设置索引，InnoDB 会自动在主键上创建隐藏的聚簇索引，因此 Record Locks 依然可以使用。

Gap Lock 间隙锁

每次锁住的不光是需要使用的数据，还会锁住这些数据附近的数据。
间隙锁存在于非唯一索引中，锁定开区间范围内的一段间隔。
例如当一个事务执行以下语句，其它事务就不能在（10，20）中插入 15。

SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Lock 临键锁

临键锁存在于 非唯一索引中，该类型的每条记录的索引上都存在这种锁，它是一种特殊的间隙锁，锁定一段 左开右闭 的索引区间。通过临建锁可以解决幻读的问题。
如果查询中包含唯一索引，则会退化为记录锁。因为唯一索引能确定记录行数，其他索引不能确定行数，有可能在其他事务中添加这个索引的数据导致幻读。

小结

InnoDB 中的行锁的实现依赖于索引，一旦某个加锁操作没有使用到索引，那么该锁就会退化为表锁。
记录锁存在于包括主键索引在内的唯一索引中，锁定单条索引记录。
间隙锁存在于非唯一索引中，锁定开区间范围内的一段间隔，它是基于临键锁实现的。
临键锁存在于非唯一索引中，该类型的每条记录的索引上都存在这种锁，它是一种特殊的间隙锁，锁定一段左开右闭的索引区间。

隔离级别的实现方式

InnoDB使用不同的锁策略(Locking Strategy)以及MVCC机制来实现不同的隔离级别。读未提交是通过事务在读数据时候不加锁，在修改数据的时候加行级共享锁来实现的。读与提交和可重复读都是通过MVCC实现的快照读，不过读已提交每次查询都会创建新的read view，可重复读则一直使用第一次创建的read view。另外读已提交在进行当前读时一般只使用记录锁(除了外键约束检查和重复键检查)，而可重复读的当前读使用的锁会根据是否存在唯一索引来判断，唯一索引使用记录锁，非唯一索引则使用临键锁避免幻读。可串行化模式下所有selct语句都会被隐式的加上行级共享锁。

读未提交：
- 事务在读数据的时候不对数据加锁。事务在修改数据的时候只对数据增加行级共享锁。
读已提交：
- 普通的select是快照读，这是一种不加锁的一致性读，底层使用MVCC实现。
- 加锁的select, update, delete等语句，除了在外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会封锁区间，其他时刻都只使用 记录锁。
可重复读：
- 普通select是快照读，这是一种不加锁的一致性读，底层使用MVCC实现可重复读。
- 可重复读场景下，无论第几次查询均使用事务开启时创建的read view，但可以读到后续自身事务创建的数据。
- 加锁的select（select…in share mode/select…for update），update，delete等语句，它们的锁，依赖于它们是否在唯一索引上使用了唯一的查询条件，或者范围查询条件：
  - 在唯一索引上使用唯一的查询条件，会使用 记录锁。
  - 范围查询条件为非唯一值时，会使用 临键锁，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻读，以及避免不可重复读。
串行化：
- 这种事务隔离级别下，所有select语句会被隐式的转化为select…in share mode。这会导致，如果有未提交的事务正在修改某些行，所有读取这些行的操作都会被阻塞。

可重复读级别能解决幻读吗🤔

在快照读读情况下，mysql通过mvcc来避免幻读。在当前读读情况下，mysql通过next-key来避免幻读。单纯的mvcc只能解决本事务读方面的幻读问题，但是如果本事务发起更新update操作，那么幻读问题就会再现。本质上没有真正地解决幻读问题。不过我觉得不能把不能把快照读和当前读得到的结果不一样这种情况认为是幻读，这是两种不同的使用。

发生幻读的一种说法

实际上这种说法不太站得住脚

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读。

单纯的mvcc只能解决本事务读方面的幻读问题，但是如果本事务发起更新update操作，那么幻读问题就会再现，本质上没有真正地解决幻读问题，如以下这种情况：

A事务先select，B事务insert确实会加一个gap锁，但是如果B事务commit，这个gap锁就会释放（释放后A事务可以随意操作），A事务再select出来的结果在MVCC下还和第一次select一样，接着A事务不加条件地update，这个update会作用在所有行上（包括B事务新加的），A事务再次select就会出现B事务中的新行，并且这个新行已经被update修改了，实测在RR级别下确实如此。如果这样理解的话，Mysql的RR级别确实防不住幻读。

结论

在快照读读情况下，mysql通过mvcc来避免幻读。在当前读读情况下，mysql通过next-key来避免幻读。 select * from t where a=1;属于快照读 select * from t where a=1 lock in share mode;属于当前读不能把快照读和当前读得到的结果不一样这种情况认为是幻读，这是两种不同的使用。所以我认为mysql的rr级别是解决了幻读的。

如引用一问题所说，T1 select 之后 update，会将 T2 中 insert 的数据一起更新，那么认为多出来一行，所以防不住幻读。看着说法无懈可击，但是其实是错误的，InnoDB 中设置了快照读和当前读两种模式，如果只有快照读，那么自然没有幻读问题，但是如果将语句提升到当前读，那么 T1 在 select 的时候需要用如下语法： select * from t for update (lock in share mode) 进入当前读，那么自然没有 T2 可以插入数据这一回事儿了。

Kafka 是如何实现高吞吐率的

Fri, 27 Aug 2021 02:11:16 +0000

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：

顺序读写

Kafka数据不是实时写入硬盘，采用内存映射文件(分页存储)来利用内存提高I/O效率，利用操作系统的页来实现物理内存映射，映射完后物理内存上的操作会被同步到硬盘上。

kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能。

顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。

Kafka官方给出了测试数据(Raid-5，7200rpm)：

顺序 I/O: 600MB/s
随机 I/O: 100KB/s

零拷贝

详细可阅读：JAVA NIO 与零拷贝

零拷贝：减少了系统的两次上下文切换，

原来：文件复制到系统内核空间—复制到用户空间—复制到内核空间–发送网卡，使用socket发送。
现在：直接从内核空间到内核空间—发送给网卡

先简单了解下文件系统的操作流程，例如一个程序要把文件内容发送到网络。这个程序是工作在用户空间，文件和网络socket属于硬件资源，两者之间有一个内核空间。在操作系统内部，整个过程为：

在Linux kernel2.2 之后出现了一种叫做”零拷贝(zero-copy)”系统调用机制，就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”

系统上下文切换减少为2次，可以提升一倍的性能

文件分段

kafka的队列topic被分为了多个区partition，每个partition又分为多个段segment，每个segment段对应一个文件。

所以一个队列中的消息实际上是保存在N多个片段文件中的。

通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力。

批量发送

缓存在内存中，达到阈值或者时间，则发送，减少了网络I/O。

Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去。

比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去：

如100条消息就发送，或者每5秒发送一次
这种策略将大大减少服务端的I/O次数

数据压缩

GZIP、Snappy，减少了磁盘I/O和网络的I/O

Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩

压缩的好处就是减少传输的数据量，减轻对网络传输的压力

Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个成本很值得。

Kafka 如何保证消息的可靠性

Thu, 26 Aug 2021 09:11:16 +0000

数据可靠性的保证

副本数据同步策略

Kafka 选择了第二种方案，原因如下：

同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka 的影响较小。

方案	优点	缺点
半数以上完成同步，就发送ack	延迟低	选举新的leader时，容忍n台节点的故障，需要2n+1个副本
全部完成同步，才发送ack	选举新的leader 时，容忍n台节点的故障，需要n+1个副本	延迟高

ISR

采用第二种方案之后，设想以下情景：leader收到数据，所有 follower 都开始同步数据，但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？

超时就踢掉 😈

Leader 维护了一个动态的 in-sync replica set (ISR)，即和 leader 保持同步的 follower 集合。当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。如果 follower 长时间未向 leader 同步数据，则该 follower 将被临时踢出 ISR，该时间阈值由replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。

ACK应答机制

ACK 参数配置

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 follower 全部接收成功。

所以 Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

ack 参数配置：

0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟，broker 一接收到还没有写入磁盘就已经返回，当broker 故障时有可能丢失数据；
1：producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么将会丢失数据；
-1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复。

故障处理细节

follower 故障

follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于/大于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower的LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入ISR了。

leader 故障

leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。

注意⚠️：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

Exactly Once 语义 / 幂等性

将服务器的 ACK 级别设置为-1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。

相对的，将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次，即At Most Once 语义。

At Least Once 可以保证数据不丢失，但是不能保证数据不重复；相对的，At Least Once可以保证数据不重复，但是不能保证数据不丢失。但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即Exactly Once 语义。在0.11 版本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。

0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据，Server端都只会持久化一条。幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactly Once 语义。即：At Least Once + 幂等性 = Exactly Once。

要启用幂等性，只需要将 Producer的参数中 enable.idompotence 设置为 true 即可。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 SequenceNumber。而Broker端会对<PID,Partition,SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。但是 PID 重启就会变化，同时不同的 Partition也具有不同主键，⚠️所以幂等性无法保证跨分区跨会话的 Exactly Once（每次都路由到同一个分区即可）。

顺序消费

将每个消息只分发给一个consumer组，这样一个分区就只被这个组的一个consumer消费，就可以顺序的消费这个分区的消息。有多少分区就允许多少并发消费。Kafka只能保证一个分区内的消息有序性。

消息丢失和重复问题

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

消息发送(详见上文ack应答机制)

Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0 —表示不进行消息接收是否成功的确认；
1—表示当Leader接收成功时确认；
-1—表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；
acks=1，同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就丢失了；

🤔 解决办法：

针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；
针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。(ack=-1时，如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复。)

参考

Kafka 分区

Thu, 26 Aug 2021 03:23:16 +0000

Events、Streams、Topics

在深入 Partition 之前，我们先看几个更高层次的概念，以及它们与 Partition 的联系。

Event（事件）代表过去发生的一个事实。简单理解就是一条消息、一条记录。另外Event 是不可变的，但是很活跃，经常从一个地方流向另一个地方。

Stream 事件流表示运动中的相关事件。当一个事件流进入 Kafka 之后，它就成为了一个 Topic 主题。

所以，Topic 就是具体的事件流，也可以理解为一个 Topic 就是一个静止的 Stream(Topic 把相关的 Event 组织在一起，并且保存).

Partition

Partition（分区）是 Kafka 的核心角色，对于 Kafka 的存储结构、消息的生产消费方式都至关重要。

Kafka 中 Topic 被分成多个 Partition 分区。
Topic 是一个逻辑概念，Partition 是最小的存储单元，掌握着一个 Topic 的部分数据。
每个 Partition 都是一个单独的 log 文件，每条记录都以追加的形式写入。

偏移量和消息的顺序

Partition 中的每条记录都会被分配一个唯一的序号，称为 Offset（偏移量）。

Offset 是一个递增的、不可变的数字，由 Kafka 自动维护。

当一条记录写入 Partition 的时候，它就被追加到 log 文件的末尾，并被分配一个序号，作为 Offset。

如上图，这个 Topic 有 3 个 Partition 分区，向 Topic 发送消息的时候，实际上是被写入某一个 Partition，并赋予 Offset。

消息的顺序性需要注意，一个 Topic 如果有多个 Partition 的话，那么从 Topic 这个层面来看，消息是无序的。

但单独看 Partition 的话，Partition 内部消息是有序的。

🤔 所以，一个 Partition 内部消息有序，一个 Topic 跨 Partition 是无序的。如果强制要求 Topic 整体有序，就只能让 Topic 只有一个 Partition。

分区的优势

Partition 为 Kafka 提供了扩展能力

一个 Kafka 集群由多个 Broker（就是 Server）构成，每个 Broker 中含有集群的部分数据。Kafka 把 Topic 的多个 Partition 分布在多个 Broker 中。这样会有多种好处：

把 Partition 分散开之后，Topic 就可以水平扩展。如果把 Topic 的所有 Partition 都放在一个 Broker 上，那么这个 Topic 的可扩展性就大大降低了，会受限于这个 Broker 的 IO 能力。
一个 Topic 可以被多个 Consumer 并行消费。如果 Topic 的所有 Partition 都在一个 Broker，那么支持的 Consumer 数量就有限，而分散之后，可以支持更多的 Consumer。
一个 Consumer 可以有多个实例，Partition 分布在多个 Broker 的话，Consumer 的多个实例就可以连接不同的 Broker，大大提升了消息处理能力。可以让一个 Consumer 实例负责一个 Partition，这样消息处理既清晰又高效。

Partition 为 Kafka 提供了数据冗余

Kafka 为一个 Partition 生成多个副本(Replication)，并且把它们分散在不同的 Broker。
如果一个 Broker 故障了，Consumer 可以在其他 Broker 上找到 Partition 的副本，继续获取消息。

Partition 的写入方式

1、使用 Partition Key 写入特定 Partition

Producer 发送消息的时候，可以指定一个 Partition Key，这样就可以写入特定 Partition 了。

Partition Key 可以使用任意值，例如设备ID、User ID。
Partition Key 会传递给一个 Hash 函数，由计算结果决定写入哪个 Partition。
因此有相同 Partition Key 的消息，会被放到相同的 Partition。

例如使用 User ID 作为 Partition Key，那么此 ID 的消息就都在同一个 Partition，这样可以保证此类消息的有序性。

这种方式需要注意 Partition 热点问题。

例如使用 User ID 作为 Partition Key，如果某一个 User 产生的消息特别多，是一个头部活跃用户，那么此用户的消息都进入同一个 Partition 就会产生热点问题，导致某个 Partition 极其繁忙。

2、由 kafka 决定

没有指明partition值但有key的情况下，将key的hash值与topic的 partition数进行取余得到partition值。例如:key1的hash值=5， key2的hash值=6，topic的partition数=2，那么key1 对应的value1写入1号分区，key2对应的value2写入0号分区。
既没有partition值又没有key值的情况下，Kafka采用Sticky Partition(黏性分区器)，会随机选择一个分区，并尽可能一直使用该分区，待该分区的batch已满或者已完成，Kafka再随机一个分区进行使用(和上一次的分区不同)。例如:第一次随机选择0号分区，等0号分区当前批次满了(默认16k)或者linger.ms设置的时间到， Kafka再随机一个分区进行使用(如果还是0会继续随机)。

3、自定义规则

Kafka 支持自定义规则，一个 Producer 可以使用自己的分区指定规则。

Partition 的读取方式

Kafka 不像普通消息队列具有发布/订阅功能，Kafka 不会向 Consumer 推送消息。Consumer 必须自己从 Topic 的 Partition 拉取消息。一个 Consumer 连接到一个 Broker 的 Partition，从中依次读取消息。

消息的 Offset 就是 Consumer 的游标，根据 Offset 来记录消息的消费情况。读完一条消息之后，Consumer 会推进到 Partition 中的下一个 Offset，继续读取消息。Offset 的推进和记录都是 Consumer 的责任，Kafka 是不管的。

Kafka 中有一个 Consumer Group（消费组）的概念，多个 Consumer 组团去消费一个 Topic。同组的 Consumer 有相同的 Group ID。Consumer Group 机制会保障一条消息只被组内唯一一个 Consumer 消费，不会重复消费。消费组这种方式可以让多个 Partition 并行消费，大大提高了消息的消费能力，最大并行度为 Topic 的 Partition 数量。

例如一个 Topic 有 3 个 Partition，你有 4 个 Consumer 负责这个 Topic，也只会有 Consumer 工作，另一个作为后补队员，当某个 Consumer 故障了，它再补上去，是一种很好的容错机制。

分区分配策略

一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition的分配问题，即确定那个 partition 由哪个 consumer 来消费。

Kafka 有两种分配策略，一是 Range，一是 RoundRobin。

假设我们有个名为T1的主题，其包含了10个分区，然后我们有两个消费者（C1，C2）来消费这10个分区里面的数据，而且C1的num.streams = 1，C2的num.streams = 2。

（1）Range(默认策略)

假如有10个分区，3个消费者线程，把分区按照序号排列0，1，2，3，4，5，6，7，8，9；消费者线程为C1-0，C2-0，C2-1，那么用partition数除以消费者线程的总数来决定每个消费者线程消费几个partition，如果除不尽，前面几个消费者将会多消费一个分区。在我们的例子里面，我们有10个分区，3个消费者线程，10/3 =3，而且除不尽，那么消费者线程C1-0将会多消费一个分区，所以最后分区分配的结果看起来是这样的：

C1-0：0，1，2，3
C2-0：4，5，6
C2-1：7，8，9

（2）RoundRobin/轮询

在我们的例子里面，加入按照 hashCode 排序完的topic-partitions组依次为T1-5, T1-3, T1-0, T1-8, T1-2, T1-1, T1-4, T1-7, T1-6, T1-9，我们的消费者线程排序为C1-0, C1-1, C2-0, C2-1，最后分区分配的结果为：

C1-0将消费 T1-5, T1-2, T1-6分区；
C1-1将消费 T1-3, T1-1, T1-9分区；
C2-0将消费 T1-0, T1-4分区；
C2-1将消费 T1-8, T1-7分区；

参考

Understanding Kafka Topic Partitions

如何用策略模式消除满屏的if-else

Sat, 07 Aug 2021 03:23:16 +0000

前言

最近在迁接口的过程中遇到一个直播列表页关注Tab的接口，需要根据不同的直播状态对关注的主播进行展示，老接口把所有的直播状态都写到一起了，首先判断该主播的直播状态(直播中/预告中/未开播等)，然后执行不同的处理逻辑。

if (input.getType() == 0) {
  // 直播中主播的处理逻辑
}else if (input.getType() == 1) {
  // 预告中主播的处理逻辑
}else if (input.getType() == 2) {
  // 未开播主播的处理逻辑
}

每种逻辑返回的字段很多导致方法很大，阅读起来体验极差，而且以后有什么活动在直播列表页展示也不方面修改。现在考虑使用策略模式来消除这些if-else。

实现

对于client，我们要在其中增加一个策略处理器Map<Integer, Processor>,然后在client进行bean初始化的时候将所有策略都加载到这个ConcurrentHashMap中，这样只需向client传递一个type参数就可以从该map中找到对应的处理策略的实现类。

1.客户端client

实现InitializingBean接口会在这个bean初始化后执行afterPropertiesSet方法在里面将从ApplicationContextHelper里面获取到的bean都放到map里面去，map的key为策略实现类的业务taype，值为该对象。

/**
 * @author zhongye
 * @since 2021.08.06
 */
@Component
@Slf4j
public class MyFollowActorsActionletLogic implements InitializingBean {

  private final Map<Integer, MyFollowActorsActionletProcessor> typeAndStatementHandle = new ConcurrentHashMap<>();

  @Resource
  private ApplicationContextHelper applicationContextHelper;

  @Override
  public void afterPropertiesSet() {
    Map<String, MyFollowActorsActionletProcessor> statementHandles = 
      applicationContextHelper.getBeansOfType(MyFollowActorsActionletProcessor.class);
    for (Map.Entry<String, MyFollowActorsActionletProcessor> statementHandle : statementHandles.entrySet()) {
      typeAndStatementHandle.put(statementHandle.getValue().getType(), statementHandle.getValue());
    }
  }

  public MyFollowActorsActionletOutput assembleOutput(MyFollowActorsActionletInput input) {
    MyFollowActorsActionletOutput output = typeAndStatementHandle.get(input.getType()).process(input);

    // 处理acm，加上tId
    dealFollowListAcm(output.getData());
    // 构造结果
    output.setEnd(input.getTotal() < input.getPageSize());
    output.setPageIndex(output.isEnd() ? input.getPageIndex() : input.getPageIndex() + 1);

    return output;
  }
}

2.ApplicationContextHelper是一个实现了ApplicationContextAware接口的工具类

实现这个接口会在spring容器初始化完成之后调用setApplicationContext方法，将ApplicationContext放进去，从而可以拿到spring的容器ApplicationContext，进而使用这个容器获取我们想要的bean 。

/**
 * @author zhongye
 * @since 2021.08.06
 */
@Component
public class ApplicationContextHelper implements ApplicationContextAware {

  ApplicationContext applicationContext;

  @Override
  public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    this.applicationContext = applicationContext;
  }

  public <T> T getBean(Class<T> clazz) {
    return applicationContext.getBean(clazz);
  }

  public <T> Map<String, T> getBeansOfType(Class<T> clazz) {
    return applicationContext.getBeansOfType(clazz);
  }
}

3.策略的抽象类

/**
 * MyFollowActorsActionlet 的处理策略接口
 * 0：直播中  1：预告中 2： 未开播
 *
 * @author zhongye
 * @since 2021.08.06
 */
public interface MyFollowActorsActionletProcessor {
  /**
     * 这个类型，决定了使用哪个具体的实现类
     *
     * @return 消息类型
     */
  int getType();

  /**
     * 处理逻辑
     *
     * @param input 入参
     * @return MyFollowActorsActionletOutput
     */
  MyFollowActorsActionletOutput process(MyFollowActorsActionletInput input);
}

4.策略的实现类

/**
 * 直播列表页关注TAB-正在直播中主播处理逻辑处
 *
 * @author zhongye
 * @since 2021.08.06
 */
@Component
@Slf4j
public class MyFollowLivingActorProcessor implements MyFollowActorsActionletProcessor {
  
  @Override
  public int getType() {
    //🤔 type多的时候可以写成枚举类
    return 0;
  }

  @Override
  public MyFollowActorsActionletOutput process(MyFollowActorsActionletInput input) {

    MyFollowActorsActionletOutput output = new MyFollowActorsActionletOutput();
    output.setData(Lists.newArrayList());
    long userId = input.getLoginUserId();

    // 查询直播间信息
    List<FollowActorsRoomDTO> roomInfos = actorFollowComponent.buildRoomList(userId, input.getPageIndex(), input.getPageSize());
    List<Long> actorIds = roomInfos.stream().map(FollowActorsRoomDTO::getActorId).collect(Collectors.toList());
    // 查询主播列表
    Map<Long, UsersInfo> usersInfoMap = userInfoRemoteService.mapByUserIds(actorIds);
    // 查询陪伴天数
    Map<Long, Integer> daysMap = myFollowActorsActionletLogic.getAccompanyDaysByUser(userId, actorIds);

    // 构造数据
    for (FollowActorsRoomDTO roomInfo : roomInfos) {
      UsersInfo usersInfo = usersInfoMap.get(roomInfo.getActorId());
      if (usersInfo == null) {
        continue;
      }
      FollowActorsDataItemDTO dataItem = myFollowActorsActionletLogic.buildDataItem(
        daysMap.getOrDefault(usersInfo.getUserId(), 0), input.getType(), usersInfo);
      dataItem.setRoomInfo(roomInfo);
      output.getData().add(dataItem);
    }
    input.setTotal(roomInfos.size());

    return output;
  }
}

Spring Bean的生命周期

Tue, 25 May 2021 03:23:16 +0000

Bean生命周期的四大阶段

实例化 -> 属性赋值 -> 初始化 -> 销毁

Spring Bean的生命周期只有这四个阶段，把这四个阶段和每个阶段对应的扩展点糅合在一起虽然没有问题，但是这样非常凌乱，难以记忆。要彻底搞清楚Spring的生命周期，首先要把这四个阶段牢牢记住。实例化和属性赋值对应构造方法和setter方法的注入，初始化和销毁是用户能自定义扩展的两个阶段。

实例化 Instantiation -> createBeanInstance()
属性赋值 Populate -> populateBean()
初始化 Initialization -> initializeBean()
销毁 Destruction -> ConfigurableApplicationContext#close()

// 忽略了无关代码
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
  throws BeanCreationException {

  // Instantiate the bean.
  BeanWrapper instanceWrapper = null;
  if (instanceWrapper == null) {
    // 实例化阶段！
    instanceWrapper = createBeanInstance(beanName, mbd, args);
  }
  // Initialize the bean instance.
  Object exposedObject = bean;
  try {
    // 属性赋值阶段！
    populateBean(beanName, mbd, instanceWrapper);
    // 初始化阶段！
    exposedObject = initializeBean(beanName, exposedObject, mbd);
  }
}

常用扩展点

Spring生命周期相关的常用扩展点非常多，所以问题不是不知道，而是记不住或者记不牢。其实记不住的根本原因还是不够了解，这里通过源码+分类的方式帮大家记忆。

第一大类：影响多个Bean的接口

实现了这些接口的Bean会切入到多个Bean的生命周期中。正因为如此，这些接口的功能非常强大，Spring内部扩展也经常使用这些接口，例如自动注入以及AOP的实现都和他们有关。

InstantiationAwareBeanPostProcessor
BeanPostProcessor

这两兄弟可能是Spring扩展中最重要的两个接口！InstantiationAwareBeanPostProcessor 作用于实例化阶段的前后，BeanPostProcessor 作用于初始化阶段的前后。正好和第一、第三个生命周期阶段对应。通过图能更好理解：

InstantiationAwareBeanPostProcessor实际上继承了BeanPostProcessor接口，严格意义上来看他们不是两兄弟，而是两父子。但是从生命周期角度我们重点关注其特有的对实例化阶段的影响，图中省略了从BeanPostProcessor继承的方法。

InstantiationAwareBeanPostProcessor extends BeanPostProcessor

InstantiationAwareBeanPostProcessor源码分析

postProcessBeforeInstantiation调用点

可以看到，postProcessBeforeInstantiation在doCreateBean之前调用，也就是在bean实例化之前调用的。postProcessBeforeInstantiation在doCreateBean之前，该方法会创建目标类的的动态代理对象，之后在postProcessAfterInitialization中替换原本的Bean作为代理。此外，实质在内存中目标对象(委托类对象)跟代理对象都存在。

@Override
protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
  throws BeanCreationException {

  try {
    // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
    // postProcessBeforeInstantiation方法调用点，这里就不跟进了，
    // 有兴趣的同学可以自己看下，就是for循环调用所有的InstantiationAwareBeanPostProcessor
    Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
    if (bean != null) {
      return bean;
    }
  }

  try {   
    // 上文提到的doCreateBean方法，可以看到
    // postProcessBeforeInstantiation方法在创建Bean之前调用
    Object beanInstance = doCreateBean(beanName, mbdToUse, args);
    if (logger.isTraceEnabled()) {
      logger.trace("Finished creating instance of bean '" + beanName + "'");
    }
    return beanInstance;
  }
}

postProcessAfterInstantiation调用点

可以看到该方法在属性赋值方法内，但是在真正执行赋值操作之前。其返回值为boolean，返回false时可以阻断属性赋值阶段（continueWithPropertyPopulation = false;）。

关于BeanPostProcessor执行阶段的源码穿插在下文Aware接口的调用时机分析中，因为部分Aware功能的就是通过他实现的!只需要先记住BeanPostProcessor在初始化前后调用就可以了。

protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {

  // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the
  // state of the bean before properties are set. This can be used, for example,
  // to support styles of field injection.
  boolean continueWithPropertyPopulation = true;
  // InstantiationAwareBeanPostProcessor#postProcessAfterInstantiation()
  // 方法作为属性赋值的前置检查条件，在属性赋值之前执行，能够影响是否进行属性赋值！
  if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
    for (BeanPostProcessor bp : getBeanPostProcessors()) {
      if (bp instanceof InstantiationAwareBeanPostProcessor) {
        InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
        if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
          continueWithPropertyPopulation = false;
          break;
        }
      }
    }
  }

  // 忽略后续的属性赋值操作代码
}

第二大类：只调用一次的接口

这一大类接口的特点是功能丰富，常用于用户自定义扩展。第二大类中又可以分为两类：

Aware类型的接口
生命周期接口

Aware类型的接口

Aware类型的接口的作用就是让我们能够拿到Spring容器中的一些资源。基本都能够见名知意，Aware之前的名字就是可以拿到什么资源，例如BeanNameAware可以拿到BeanName，以此类推。

调用时机需要注意：所有的Aware方法都是在初始化阶段之前调用的！

Aware接口具体可以分为两组，至于为什么这么分，详见下面的源码分析。如下排列顺序同样也是Aware接口的执行顺序，能够见名知意的接口不再解释。

Aware Group1

BeanNameAware
BeanClassLoaderAware
BeanFactoryAware

Aware Group2

EnvironmentAware
EmbeddedValueResolverAware 这个知道的人可能不多，实现该接口能够获取Spring EL解析器，用户的自定义注解需要支持spel表达式的时候可以使用，非常方便。
ApplicationContextAware(ResourceLoaderAware\ApplicationEventPublisherAware\MessageSourceAware) 这几个接口可能让人有点懵，实际上这几个接口可以一起记，其返回值实质上都是当前的ApplicationContext对象，因为ApplicationContext是一个复合接口，如下：

这里涉及到另一道面试题，ApplicationContext和BeanFactory的区别，可以从ApplicationContext继承的这几个接口入手，除去BeanFactory相关的两个接口就是ApplicationContext独有的功能，这里不详细说明。
```
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver {}
```

Aware调用时机源码分析

代码位置就是我们上文提到的initializeBean方法详情，这也说明了Aware都是在初始化阶段之前调用的！

可以看到并不是所有的Aware接口都使用同样的方式调用。Bean××Aware都是在代码中直接调用的，而ApplicationContext相关的Aware都是通过BeanPostProcessor#postProcessBeforeInitialization()实现的。感兴趣的可以自己看一下ApplicationContextAwareProcessor这个类的源码，就是判断当前创建的Bean是否实现了相关的Aware方法，如果实现了会调用回调方法将资源传递给Bean。至于Spring为什么这么实现，应该没什么特殊的考量。也许和Spring的版本升级有关。基于对修改关闭，对扩展开放的原则，Spring对一些新的Aware采用了扩展的方式添加。

BeanPostProcessor的调用时机也能在这里体现，包围住invokeInitMethods方法，也就说明了在初始化阶段的前后执行。

关于Aware接口的执行顺序，其实只需要记住第一组在第二组执行之前就行了。每组中各个Aware方法的调用顺序其实没有必要记，有需要的时候点进源码一看便知。

// 见名知意，初始化阶段调用的方法
protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {

  // 这里调用的是Group1中的三个Bean开头的Aware
  invokeAwareMethods(beanName, bean);

  Object wrappedBean = bean;

  // 这里调用的是Group2中的几个Aware，
  // 而实质上这里就是前面所说的BeanPostProcessor的调用点！
  // 也就是说与Group1中的Aware不同，这里是通过BeanPostProcessor（ApplicationContextAwareProcessor）实现的。
  wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
  // 下文即将介绍的InitializingBean调用点
  invokeInitMethods(beanName, wrappedBean, mbd);
  // BeanPostProcessor的另一个调用点
  wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);

  return wrappedBean;
}

简单的两个生命周期接口

至于剩下的两个生命周期接口就很简单了，实例化和属性赋值都是Spring帮助我们做的，能够自己实现的有初始化和销毁两个生命周期阶段。

InitializingBean 对应生命周期的初始化阶段，在上面源码的invokeInitMethods(beanName, wrappedBean, mbd)方法中调用。
- 有一点需要注意，因为Aware方法都是执行在初始化方法之前，所以可以在初始化方法中放心大胆的使用Aware接口获取的资源，这也是我们自定义扩展Spring的常用方式。
- 除了实现InitializingBean接口之外还能通过注解或者xml配置的方式指定初始化方法，至于这几种定义方式的调用顺序其实没有必要记。因为这几个方法对应的都是同一个生命周期，只是实现方式不同，我们一般只采用其中一种方式。
DisposableBean 类似于InitializingBean，对应生命周期的销毁阶段，以ConfigurableApplicationContext#close()方法作为入口，实现是通过循环取所有实现了DisposableBean接口的Bean然后调用其destroy()方法。

BeanPostProcessor 注册时机与执行顺序

注册时机

我们知道BeanPostProcessor也会注册为Bean，那么Spring是如何保证BeanPostProcessor在我们的业务Bean之前初始化完成呢？请看我们熟悉的refresh()方法的源码:

可以看出，Spring是先执行registerBeanPostProcessors()进行BeanPostProcessors的注册，然后再执行finishBeanFactoryInitialization初始化我们的单例非懒加载的Bean。

@Override
public void refresh() throws BeansException, IllegalStateException {
  synchronized (this.startupShutdownMonitor) {

    try {
      // Allows post-processing of the bean factory in context subclasses.
      postProcessBeanFactory(beanFactory);

      // Invoke factory processors registered as beans in the context.
      invokeBeanFactoryPostProcessors(beanFactory);

      // Register bean processors that intercept bean creation.
      // 所有BeanPostProcesser初始化的调用点
      registerBeanPostProcessors(beanFactory);

      // Initialize message source for this context.
      initMessageSource();

      // Initialize event multicaster for this context.
      initApplicationEventMulticaster();

      // Initialize other special beans in specific context subclasses.
      onRefresh();

      // Check for listener beans and register them.
      registerListeners();

      // Instantiate all remaining (non-lazy-init) singletons.
      // 所有单例非懒加载Bean的调用点
      finishBeanFactoryInitialization(beanFactory);

      // Last step: publish corresponding event.
      finishRefresh();
    }

  }

执行顺序

BeanPostProcessor有很多个，而且每个BeanPostProcessor都影响多个Bean，其执行顺序至关重要，必须能够控制其执行顺序才行。关于执行顺序这里需要引入两个排序相关的接口：PriorityOrdered、Ordered

PriorityOrdered是一等公民，首先被执行，PriorityOrdered公民之间通过接口返回值排序
Ordered是二等公民，然后执行，Ordered公民之间通过接口返回值排序
都没有实现是三等公民，最后执行

在以下源码中，可以很清晰的看到Spring注册各种类型BeanPostProcessor的逻辑，根据实现不同排序接口进行分组。优先级高的先加入，优先级低的后加入。

PriorityOrdered、Ordered接口作为Spring整个框架通用的排序接口，在Spring中应用广泛，也是非常重要的接口。

// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
// 首先，加入实现了PriorityOrdered接口的BeanPostProcessors，顺便根据PriorityOrdered排了序
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
  if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
    currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
    processedBeans.add(ppName);
  }
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();

// Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered.
// 然后，加入实现了Ordered接口的BeanPostProcessors，顺便根据Ordered排了序
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
  if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
    currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
    processedBeans.add(ppName);
  }
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();

// Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear.
// 最后加入其他常规的BeanPostProcessors
boolean reiterate = true;
while (reiterate) {
  reiterate = false;
  postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
  for (String ppName : postProcessorNames) {
    if (!processedBeans.contains(ppName)) {
      currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
      processedBeans.add(ppName);
      reiterate = true;
    }
  }
  sortPostProcessors(currentRegistryProcessors, beanFactory);
  registryProcessors.addAll(currentRegistryProcessors);
  invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
  currentRegistryProcessors.clear();
}

根据排序接口返回值排序，默认升序排序，返回值越低优先级越高。

/**
 * Useful constant for the highest precedence value.
 * @see java.lang.Integer#MIN_VALUE
 */
int HIGHEST_PRECEDENCE = Integer.MIN_VALUE;

/**
 * Useful constant for the lowest precedence value.
 * @see java.lang.Integer#MAX_VALUE
 */
int LOWEST_PRECEDENCE = Integer.MAX_VALUE;

流程说明

生命周期流程图

Bean的完整生命周期经历了各种方法调用，这些方法可以划分为以下几类：

Bean自身的方法：这个包括了Bean本身调用的方法和通过配置文件中<bean>的init-method和destroy-method指定的方法
Bean级生命周期接口方法：这个包括了BeanNameAware、BeanFactoryAware、InitializingBean和DiposableBean这些接口的方法
容器级生命周期接口方法：这个包括了InstantiationAwareBeanPostProcessor 和 BeanPostProcessor 这两个接口实现，一般称它们的实现类为“后处理器”。
工厂后处理器接口方法：这个包括了AspectJWeavingEnabler, ConfigurationClassPostProcessor, CustomAutowireConfigurer等等非常有用的工厂后处理器接口的方法。工厂后处理器也是容器级的。在应用上下文装配配置文件之后立即调用。

Bean的实例化（通过构造方法进行实例化）

Spring对Bean进行实例化（相当于 new ）,对于BeanFactory一般是延迟实例化，就是说调用getBean方法才会实例化，但是对于ApplicationContext，当容器初始化完成之后，就完成了所有Bean的实例化工作。实例化的对象被包装在BeanWrapper对象中，BeanWrapper提供了设置对象属性的接口，从而避免了使用反射机制设置属性。

InstantiationAwareBeanPostProcessor

InstantiationAwareBeanPostProcessor这个接口主要是帮助你在Bean实例化之前做一些操作。它继承自 BeanPostProcessor接口，其中 postProcessBeforeInstantiation()方法是在目标对象实例化之前调用的方法，可以返回目标实例的一个代理用来代替目标实例。postProcessPropertyValues方法是在属性值被设置到目标实例之前调用，可以修改属性的设值。

设置属性（依赖注入）

实例化后的对象被封装到BeanWrapper对象中，并且此时对象是一个原生状态，并没有执行依赖注入。紧接着，Spring根据BeanDefinition中的信息进行依赖注入。并且通过BeanWrapper提供的设置属性的接口完成依赖注入。也就是说第二步就是通过Setter方法设置对象的属性。

注入Aware接口

Spring 会检测该对象是否实现了Aware接口，如果实现了，则通过BeanNameAware的setBeanName方法设置对象名，通过BeanClassLoaderAware的setBeanClassLoader设置对象的加载器，通过BeanFactoryAware设置setBeanFactory设置BeanFactory接口的实现类是AbstractAutowireCapableBeanFactory。各种各样的Aware接口，其作用就是在对象实例化完成后将Aware接口定义中规定的依赖注入到当前实例中。比较常见的ApplicationContextAware接口，实现了这个接口的类都可以获取到一个ApplicationContext对象，当容器中每个对象的实例化过程走到BeanPostProcessor前置处理这一步时，容器会检测到之前注册到容器的ApplicationContextAwareProcessor，然后就会调用其postProcessorBeforeInitialization()方法，检查并设置Aware相关的依赖。示例如下：

@Component
public class SpringUtils implements ApplicationContextAware {

  private static ApplicationContext applicationContext;

  @Override
  public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    SpringUtils.applicationContext = applicationContext;
    System.out.println("========ApplicationContext配置成功========");
  }
}

BeanPostProcessor的postProcessBeforeInitialzation方法（前置处理）

经过上述步骤后，Bean对象已经被正确构造了，如果你想要对象被使用之前在进行自定义的处理，可以通过BeanPostProcessor接口实现。该接口提供了两个方法。

其中postProcessBeforeInitialzation( Object bean, String beanName ) 方法；当前正在初始化的bean对象会被传递进来，我们就可以对这个Bean做任何处理，这个方法会先于InitializingBean执行，因此称为前置处理。

InitializingBean与init-method（检查自定义配置）

如果Bean实现了InitializingBean接口，Spring将调用它们的afterPropertiesSet方法，作用与在配置文件中对Bean使用init-method声明初始化的作用一样，都是在Bean的全部属性设置成功后执行的初始化方法。afterPropertiesSet 方法与前置处理不同的是，由于其没有把Bean对象传进来，因此在这一步没有办法处理对象本身，只能增加一些额外的逻辑。

BeanPostProcess的postProcessAfterInitialzation方法

BeanPostProcess的postProcessAfterInitialzation(Object bean, String beanName ) 方法；当前正在初始化的bean对象会被传递进来，我们就可以对这个bean做任何处理。这个函数会在InitializingBean完成后执行，因此称为后置处理。

Bean初始化结束

经过以上的工作以后，Bean的初始化就结束了，Bean将一直驻留在应用上下文中给应用使用，知道应用上下文被销毁。

DispostbleBean接口

如果Bean实现了DispostbleBean接口，Spring将调用它的destroy方法，作用与在配置文件中对Bean使用destroy-method属性的作用是一样的，都是在Bean实例销毁前执行的方法。

小结

Spring 中的 bean 生命周期流程：

注册阶段：主要任务是通过各种BeanDefinitionReader读取各种配置来源信息（比如读取xml文件、注解、配置类等），并将其转化为BeanDefintion的过程(定义并描述一个Spring Bean，方便后续解析实例化等操作,是一个ConcurrentHashMap)。如果存在父子依赖关系，则把BeanDefinition转化为RootBeanDefinition。
实例化阶段：实例化的对象被包装在BeanWrapper对象中，另外还有InstantiationAwareBeanPostProcessor接口在实例化前后做一些操作。然后进行对象的属性赋值，如果实现了各种Aware接口则调用相应的方法(aware 的目的是为了让bean获取spring容器的各种服务)。
初始化阶段：主要处理InitializingBean::afterPropertiesSet和自定义的init-method方法，另外还可以定义BeanPostProcessor接口来实现初始化阶段的前置处理和后置处理。使用结束有进入销毁阶段。
销毁阶段：在bean销毁的时候做一些处理。主要处理DisposableBean接口的destroy()和自定义的destroy-method方法的逻辑。

Rin's blog

Spring核心编程思想 重新认识IOC/IOC容器概述

依赖查找

根据Bean名称/类型查找

根据Bean类型/类型查找集合对象

根据Java注解查找

实时/延迟查找

依赖注入

依赖来源

配置元信息

IoC容器

Spring应用上下文

IoC容器生命周期

学习笔记 spring核心编程思想

前言

目录

Kafka源码浅析

前言

生产者源码

生产者消息发送流程

初始化

生产者main线程初始化

生产者sender线程初始化

生产者发送数据到缓冲区

发送总体流程

分区选择

发送消息大小校验

内存/缓存池

sender 线程发送数据

消费者源码

消费者初始化

消费者订阅主题

消费者拉取和处理数据

消费者 Offset 提交

手动同步提交

手动异步提交

服务器源码

Kafka如何避免消息丢失

生产端

ACKS

retries

retry.backoff.ms

消息重复

broke

replication.factor

min.insync.replicas

unclean.leader.election.enable

消费端

enable.auto.commit

Kafka学习笔记 消费者

Kafka 消费者

消费方式

消费者工作流程

消费者API

独立消费者(订阅主题)

独立消费者(订阅分区)

消费者组

分区的分配以及再平衡

Range 以及再平衡

RoundRobin 以及再平衡

Sticky 以及再平衡

CooperativeSticky

offset位移

offset 的默认维护位置

自动提交 offset

手动提交 offset

指定 offset 消费

指定时间消费

漏消费和重复消费

数据积压

Kafka学习笔记 Broker

Kafka Broker

Zk 存储结构

Broker工作流程

Kafka 副本

生产经验

手动调整分区副本存储

Leader Partition 负载平衡

增加副本因子

文件存储

Spring核心编程思想重新认识IOC/IOC容器概述

Kafka学习笔记消费者

Kafka学习笔记生产者

Kafka学习笔记快速入门