Add km module kafka

docs/zh/Kafka分享/Kafka常见问题解答/Kafka集群滚动重启实践/Kafka集群滚动重启实践.md

@@ -0,0 +1,180 @@
+# Kafka集群平稳滚动重启实践
+
+[TOC]
+
+## 0、前言
+
+Kafka集群的滚动重启，是一件非常危险的事情，操作不当的情况下可能会导致Kafka集群不可服务。即便操作上准确无误，也可能因为业务方服务非常敏感、服务健壮性不足、使用的客户端存在BUG等原因，导致业务方业务受损。
+
+基于以上的原因以及我们以往的经验，我们梳理了一下在对Kafka集群滚动重启中，需要做的事情以及注意的点。
+
+
+## 1、用户告知
+
+### 1.1、告知内容
+
+提前告知用户:
+- 我们要做什么；
+- 为什么要做；
+- 可能的影响，及简单处理方式，比如因为leader会切换，node客户端可能会消费中断，需要重启等；
+- 联系人；
+- 操作时间；**在操作时间选择上，建议选择业务方在的工作时间，方便出问题后能及时协同处理**
+
+告知内容例子：
+```
+标题：
+[2021-11-11] XXX-Kafka 集群升级至 kafka_2.12-xxxx
+
+变更原因：
+1、性能优化 
+
+变更内容：
+1、集群单机连接数限制调整到 1200 
+
+变更影响：
+升级过程中会有leader切换，理论上无影响，有问题及时联系kafka服务号 
+
+联系人：
+xxxxx@xxxx.com
+
+计划时间：
+2021-11-11T10:00:00+08:00 至 2021-11-11T16:30:00+08:00 
+```
+
+### 1.2、相关建议
+
+- 增加对自身服务监控，比如监控服务对应的Topic的流量，监控消费的Lag等指标，以便出现问题时能被及时发现；
+- 
+
+---
+
+## 2、滚动重启
+
+**真正操作前，建议演练一下。**
+
+---
+
+### 2.1、整体操作流程
+
+- 1、再次通知用户，我们现在要开始进行重启操作，有问题随时联系；
+- 2、重启**非Controller**的一台Broker；
+- 3、观察重启后指标等是否都正常，如果出现异常则进行相应的处理；
+- 4、告知用户我们已重启一台，xxx分钟后，要操作剩余所有的机器，让用户注意自身服务是否正常，有问题随时反馈；
+- 5、xxx分钟后，剩余机器逐台重启，**Kafka-Controller放在最后重启**；
+- 6、操作完成后，告知用户已操作完成，让用户关注自身服务是否正常，有问题随时反馈；
+
+---
+
+
+### 2.2、单台操作流程
+
+单台操作时，主要分两部分，第一部分时操作进行重启，第二部分是重启完成之后观察服务是否正常。
+
+#### 2.2.1、重启
+
+**第一步：停服务**
+
+```bash
+# 以kill的方式，停Kafka服务。
+
+# 强调：不能以kill -9的方式停服！！！
+```
+
+**第二步：修改配置**
+
+```bash
+# 对本次重启需要进行修改的配置进行修改；
+
+# 强烈要求将本次修改的配置的具体操作步骤罗列出来；
+```
+
+**第三步：Broker限流**
+
+```bash
+# 如果在停服务和启动服务之间的时间间隔非常的久，导致启动后需要同步非常多的数据，则在启动服务之前，我们需要做好副本同步之间的限流，否则可能会拉打满带宽，挂其他Broker等。
+
+# 这里的需要同步的数据量怎么样算多，这个没有一个非常准确的值，只要说可能将leader带宽打满，拉挂其他Broker都算是数据量大。
+```
+
+**第四步：起服务**
+
+```bash
+# 启动Kafk服务，然后观察服务是否正常
+```
+
+---
+
+#### 2.2.2、观察
+
+
+**第一步：观察启动日志**
+
+```bash
+# 查看server.log文件，看到该日志后表示Kafka服务端已启动完成
+[2021-11-17 14:07:22,459][INFO][main]: [KafkaServer id=2] started
+
+# 查看server.log文件，检查是否存在ERROR及FATAL日志，如果出现这些日志，需要暂停升级并分析出现这些日志的影响。
+```
+
+**第二步：观察服务监控**
+
+如果可以做到下列指标的监控的话，建议都在监控系统中，配置上这些监控。
+
+这一步正常来说只要配置上了，如果出现异常监控系统会主动通知，不需要我们细致的去看，所以虽然列的比较多，但是操作的时候不太需要主动去看所有的指标。
+
+```bash
+# 服务存活监控；
+# 错误日志监控；
+# GC监控；
+# 脏选举监控；
+# ISR收缩速度监控；
+# leader=-1监控；
+# 网络处理线程负载监控；
+# 请求处理线程负载监控；
+# 副本未同步监控；
+# 系统负载监控(CPU、磁盘IO、磁盘容量、网络带宽、网络丢包、TCP连接数、TCP连接增速、文件句柄数)；
+```
+
+**第三步：检查变更是否生效**
+
+这一步骤没有什么好说的，就是检查是否生效。
+
+
+
+**第四步：观察流量是否正常**
+
+```
+观察一：存在Broker组的概念，则可以观察重启所在的Broker组的整个流量和重启之前是否基本一致。
+
+观察二：重点选取几个Broker上的Topic，观察流量是否出现异常，比如突然没有流入或流出流量了。
+```
+
+
+**第五步：等待副本同步完成**
+
+```bash
+# 查看整个集群的副本同步状态，确保整个集群都是处于已同步的状态。该信息可以通过LogiKM查看。
+
+# 实际上是不需要整个集群所有的Broker处于已同步的状态，只需要是落在所重启的Broker上的所有的分区都处于同步状态即可，但是这个不太好判断，因此简单粗暴的就是看整个集群都处于同步状态。
+```
+
+### 2.3、其他重要说明
+
+- 如果重启中需要同步非常大的数据量，Broker本身负载也较高，则建议重启操作要避开leader rebalance的时间；
+- 重启的过程中，会进行leader的切换，最后一台操作完成之后，需要进行leader rebalance；
+
+
+---
+
+
+## 3、信息记录
+
+操作中，很难避免就不出现任何问题，出现问题时就需要我们做好相关的记录，比如记录：
+
+- 1、重要的业务及其Topic；
+- 2、敏感的业务及其Topic；
+- 3、特殊客户端的业务及其Topic；
+- 4、不合理使用的业务及其Topic；
+
+后续我们可以将这些Topic进行重点保障，以及再次进行操作的时候，我们能够更准确的触达到用户。
+