mirror of
https://github.com/didi/KnowStreaming.git
synced 2025-12-24 03:42:07 +08:00
[Init]官网文档Init
This commit is contained in:
zengqiao
36
product/1-brief-introduction.md
Normal file
36
product/1-brief-introduction.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
order: 1
|
||||
title: '1.产品简介'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 1.1、产品简介
|
||||
|
||||
`Know Streaming` 是一套云原生的 Kafka 管控平台，脱胎于众多互联网内部多年的 Kafka 运营实践经验，专注于 Kafka 运维管控、监控告警、资源治理、多活容灾等核心场景，在用户体验、监控、运维管控上进行了平台化、可视化、智能化的建设，提供一系列特色的功能，极大地方便了用户和运维人员的日常使用，让普通运维人员都能成为 Kafka 专家。
|
||||
|
||||
---
|
||||
|
||||
## 1.2、产品特点
|
||||
|
||||
**👀 0 侵入、全覆盖**
|
||||
不会对 Apache Kafka 做侵入性改造，就能一键纳管 0.10.x-3.x.x 众多版本 Kafka（包含 ZK 或 Raft 运行模式的版本），在兼容架构上具备良好的扩展性，帮助您提升集群管理水平
|
||||
|
||||
**👏 0 成本、界面化**
|
||||
通过提炼高频的 CLI 能力，设计合理的产品使用路径，提供清新美观的 GUI 界面，支持 Cluster、Broker、Topic、Message、Consumer、ALC 等组件 GUI 管理，普通用户 5 分钟即可上手
|
||||
|
||||
**⚡️ 云原生、插件化**
|
||||
基于云原生构建的 Kafka 管控平台，具备水平扩展能力，只需要增加节点即可获取更强的采集及对外服务能力，提供众多可热插拔的企业级特性，覆盖可观测性生态整合、资源治理、多活容灾等核心场景
|
||||
|
||||
**🌪️ 功能丰富**
|
||||
主要包含多集群管理和系统管理两大块，具体包含：
|
||||
|
||||
- 多集群管理：包括 Cluster 管理、Broker 管理、Topic 管理、Group 管理、Message 测试、Security 管理、Jobs 管理等 7 大功能模块，几乎涵盖 CLI 的所有高频能力
|
||||
- 系统管理：包括配置管理、用户管理、审计日志等 3 大功能模块，基本满足开源用户的使用需要
|
||||
|
||||
**🚀 专业能力**
|
||||
不仅是 CLI 到 GUI 的优秀翻译，更是涵盖一系列专业能力的产品，包括但不限于：
|
||||
|
||||
- 集群管理：支持集群一键纳管，健康分析、核心组件观测 等功能
|
||||
- 观测提升：多维度指标观测大盘、观测指标最佳实践 等功能
|
||||
- 异常巡检：集群多维度健康巡检、集群多维度健康分 等功能
|
||||
- 能力增强：Topic 扩分区、Topic 扩缩副本、Topic 副本迁移 等功能
|
||||
427
product/10-contribution.md
Normal file
427
product/10-contribution.md
Normal file
@@ -0,0 +1,427 @@
|
||||
---
|
||||
order: 10
|
||||
title: '10.开源共建'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 10.1 贡献源码
|
||||
|
||||
欢迎 👏🏻 来到 KnowStreaming！本文档是关于如何为 KnowStreaming 做出贡献的指南。
|
||||
|
||||
如果您发现不正确或遗漏的内容, 请留下意见/建议。
|
||||
|
||||
#### 行为守则
|
||||
|
||||
请务必阅读并遵守我们的 [行为准则](https://github.com/didi/KnowStreaming/blob/master/CODE_OF_CONDUCT.md).
|
||||
|
||||
#### 贡献
|
||||
|
||||
**KnowStreaming** 欢迎任何角色的新参与者，包括 **User** 、**Contributor**、**Committer**、**PMC** 。
|
||||
|
||||
我们鼓励新人积极加入 **KnowStreaming** 项目，从 User 到 Contributor、Committer ，甚至是 PMC 角色。
|
||||
|
||||
为了做到这一点，新人需要积极地为 **KnowStreaming** 项目做出贡献。以下介绍如何对 **KnowStreaming** 进行贡献。
|
||||
|
||||
##### 创建/打开 Issue
|
||||
|
||||
如果您在文档中发现拼写错误、在代码中**发现错误**或想要**新功能**或想要**提供建议**，您可以在 GitHub 上[创建一个 Issue](https://github.com/didi/KnowStreaming/issues/new/choose) 进行报告。
|
||||
|
||||
如果您想直接贡献, 您可以选择下面标签的问题。
|
||||
|
||||
- [contribution welcome](https://github.com/didi/KnowStreaming/labels/contribution%20welcome) : 非常需要解决/新增 的 Issues
|
||||
- [good first issue](https://github.com/didi/KnowStreaming/labels/good%20first%20issue): 对新人比较友好, 新人可以拿这个 Issue 来练练手热热身。
|
||||
|
||||
<font color=red ><b> 请注意，任何 PR 都必须与有效 issue 相关联。否则，PR 将被拒绝。</b></font>
|
||||
|
||||
##### 开始你的贡献
|
||||
|
||||
**分支介绍**
|
||||
|
||||
我们将 `master`分支作为开发分支, 说明这是一个不稳定的分支。
|
||||
|
||||
此外,我们的分支模型符合 [https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/). 我们强烈建议新人在创建 PR 之前先阅读上述文章。
|
||||
|
||||
**贡献流程**
|
||||
|
||||
为方便描述,我们这里定义一下 2 个名词：
|
||||
|
||||
自己 Fork 出来的仓库是私人仓库, 我们这里称之为 ：**分叉仓库**
|
||||
Fork 的源项目,我们称之为：**源仓库**
|
||||
|
||||
现在，如果您准备好创建 PR, 以下是贡献者的工作流程:
|
||||
|
||||
1. Fork [KnowStreaming](https://github.com/didi/KnowStreaming) 项目到自己的仓库
|
||||
|
||||
2. 从源仓库的`master`拉取并创建自己的本地分支,例如: `master`
|
||||
3. 在本地分支上对代码进行修改
|
||||
4. Rebase 开发分支, 并解决冲突
|
||||
5. commit 并 push 您的更改到您自己的**分叉仓库**
|
||||
6. 创建一个 Pull Request 到**源仓库**的`master`分支中。
|
||||
7. 等待回复。如果回复的慢，请无情的催促。
|
||||
|
||||
更为详细的贡献流程请看下面的：[10.2 贡献流程]()
|
||||
|
||||
创建 Pull Request 时：
|
||||
|
||||
1. 请遵循 PR 的 [模板](https://github.com/didi/KnowStreaming/blob/master/.github/PULL_REQUEST_TEMPLATE.md)
|
||||
2. 请确保 PR 有相应的 issue。
|
||||
3. 如果您的 PR 包含较大的更改，例如组件重构或新组件，请编写有关其设计和使用的详细文档(在对应的 issue 中)。
|
||||
4. 注意单个 PR 不能太大。如果需要进行大量更改，最好将更改分成几个单独的 PR。
|
||||
5. 在合并 PR 之前，尽量的将最终的提交信息清晰简洁, 将多次修改的提交尽可能的合并为一次提交。
|
||||
6. 创建 PR 后，将为 PR 分配一个或多个 reviewers。
|
||||
|
||||
<font color=red><b>如果您的 PR 包含较大的更改，例如组件重构或新组件，请编写有关其设计和使用的详细文档。</b></font>
|
||||
|
||||
#### 代码审查指南
|
||||
|
||||
Commiter 将轮流 review 代码，以确保在合并前至少有一名 Commiter
|
||||
|
||||
一些原则：
|
||||
|
||||
- 可读性——重要的代码应该有详细的文档。API 应该有 Javadoc。代码风格应与现有风格保持一致。
|
||||
- 优雅：新的函数、类或组件应该设计得很好。
|
||||
- 可测试性——单元测试用例应该覆盖 80% 的新代码。
|
||||
- 可维护性 - 遵守我们的编码规范。
|
||||
|
||||
#### 开发者
|
||||
|
||||
##### 成为 Contributor
|
||||
|
||||
只要成功提交并合并 PR , 则为 Contributor
|
||||
|
||||
贡献者名单请看：[贡献者名单]()
|
||||
|
||||
##### 尝试成为 Commiter
|
||||
|
||||
一般来说, 贡献 8 个重要的补丁并至少让三个不同的人来 Review 他们(您需要 3 个 Commiter 的支持)。
|
||||
然后请人给你提名, 您需要展示您的
|
||||
|
||||
1. 至少 8 个重要的 PR 和项目的相关问题
|
||||
2. 与团队合作的能力
|
||||
3. 了解项目的代码库和编码风格
|
||||
4. 编写好代码的能力
|
||||
|
||||
当前的 Commiter 可以通过在 KnowStreaming 中的 Issue 标签 `nomination`(提名)来提名您
|
||||
|
||||
1. 你的名字和姓氏
|
||||
2. 指向您的 Git 个人资料的链接
|
||||
3. 解释为什么你应该成为 Commiter
|
||||
4. 详细说明提名人与您合作的 3 个 PR 以及相关问题,这些问题可以证明您的能力。
|
||||
|
||||
另外 2 个 Commiter 需要支持您的**提名**，如果 5 个工作日内没有人反对，您就是提交者,如果有人反对或者想要更多的信息，Commiter 会讨论并通常达成共识(5 个工作日内) 。
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
<hr>
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
## 10.2 贡献流程
|
||||
|
||||
#### 贡献流程
|
||||
|
||||
[贡献源码细则](./././CONTRIBUTING.md)
|
||||
|
||||
##### 1. fork didi/KnowStreaming 项目到您的 github 库
|
||||
|
||||
找到你要 Fork 的项目,例如 [KnowStreaming](https://github.com/didi/KnowStreaming) ,点击 Fork 按钮。
|
||||
|
||||
|
||||
|
||||
##### 2. 克隆或下载您 fork 的 Know Streaming 代码仓库到您本地
|
||||
|
||||
```sh
|
||||
|
||||
git clone { your fork knowstreaming repo address }
|
||||
|
||||
cd KnowStreaming
|
||||
|
||||
```
|
||||
|
||||
##### 3. 添加 didi/KnowStreaming 仓库为 upstream 仓库
|
||||
|
||||
```sh
|
||||
|
||||
### 添加源仓库
|
||||
git remote add upstream https://github.com/didi/KnowStreaming
|
||||
|
||||
### 查看是否添加成功
|
||||
git remote -v
|
||||
|
||||
origin ${your fork KnowStreaming repo address} (fetch)
|
||||
origin ${your fork KnowStreaming repo address} (push)
|
||||
upstream https://github.com/didi/KnowStreaming(fetch)
|
||||
upstream https://github.com/didi/KnowStreaming (push)
|
||||
|
||||
### 获取源仓库的基本信息
|
||||
git fetch origin
|
||||
git fetch upstream
|
||||
|
||||
```
|
||||
|
||||
上面是将 didi/KnowStreaming 添加为远程仓库, 当前就会有 2 个远程仓库
|
||||
|
||||
1. origin ： 你 Fork 出来的分叉仓库
|
||||
2. upstream ： 源仓库
|
||||
|
||||
git fetch 获取远程仓库的基本信息, 比如 **源仓库**的所有分支就获取到了
|
||||
|
||||
##### 4. 同步源仓库开发分支到本地分叉仓库中
|
||||
|
||||
一般开源项目都会有一个给贡献者提交代码的分支，例如 KnowStreaming 的分支是 `master`；
|
||||
|
||||
首先我们要将 **源仓库**的开发分支(`master`) 拉取到本地仓库中
|
||||
|
||||
```sh
|
||||
|
||||
git checkout -b master upstream/master
|
||||
```
|
||||
|
||||
**或者 IDEA 的形式创建**
|
||||
|
||||
|
||||
|
||||
##### 5. 在本地新建的开发分支上进行修改
|
||||
|
||||
首先请保证您阅读并正确设置 KnowStreaming code style, 相关内容请阅读[KnowStreaming 代码规约 ]()。
|
||||
|
||||
修改时请保证该分支上的修改仅和 issue 相关，并尽量细化，做到
|
||||
|
||||
<font color=red><b>一个分支只修改一件事，一个 PR 只修改一件事</b></font>。
|
||||
|
||||
同时，您的提交记录请尽量描述清楚，主要以谓 + 宾进行描述，如：Fix xxx problem/bug。少量简单的提交可以使用 For xxx 来描述，如：For codestyle。 如果该提交和某个 ISSUE 相关，可以添加 ISSUE 号作为前缀，如：For #10000, Fix xxx problem/bug。
|
||||
|
||||
##### 6. Rebase 基础分支和开发分支
|
||||
|
||||
您修改的时候，可能别人的修改已经提交并被合并，此时可能会有冲突，这里请使用 rebase 命令进行合并解决，主要有 2 个好处：
|
||||
|
||||
1. 您的提交记录将会非常优雅，不会出现 Merge xxxx branch 等字样
|
||||
2. rebase 后您分支的提交日志也是一条单链，基本不会出现各种分支交错的情况，回查时更轻松
|
||||
|
||||
```sh
|
||||
git fetch upstream
|
||||
|
||||
git rebase -i upstream/master
|
||||
|
||||
```
|
||||
|
||||
**或者在 IDEA 的操作如下**
|
||||
|
||||
|
||||
|
||||
选择 源仓库的开发分支
|
||||
|
||||
|
||||
|
||||
推荐使用 IDEA 的方式, 有冲突的时候更容易解决冲突问题。
|
||||
|
||||
##### 7. 将您开发完成 rebase 后的分支，上传到您 fork 的仓库
|
||||
|
||||
```sh
|
||||
git push origin master
|
||||
```
|
||||
|
||||
特别要注意的是：在 push 之前 尽量将您的多次 commit 信息 合并成一次 commit 信息，这样会非常的简洁
|
||||
|
||||
##### 8. 按照 PR 模板中的清单创建 Pull Request
|
||||
|
||||
|
||||
|
||||
选择自己的分支合并到模板分支。
|
||||
|
||||
##### 9. 等待合并代码
|
||||
|
||||
提交了 PR 之后，需要等待 PMC、Commiter 来 Review 代码，如果有问题需要配合修改重新提交。
|
||||
|
||||
如果没有问题会直接合并到开发分支`master`中。
|
||||
|
||||
注： 如果长时间没有 review, 则可以多催促社区来 Review 代码！
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
<hr>
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
## 10.3 Pull Request 模板
|
||||
|
||||
请不要在没有先创建 Issue 的情况下创建 Pull Request。
|
||||
|
||||
#### 变更的目的是什么
|
||||
|
||||
XXXXX
|
||||
|
||||
#### 简短的更新日志
|
||||
|
||||
XX
|
||||
|
||||
#### 验证这一变化
|
||||
|
||||
XXXX
|
||||
|
||||
请遵循此清单，以帮助我们快速轻松地整合您的贡献：
|
||||
|
||||
- [ ] 确保有针对更改提交的 Github issue（通常在您开始处理之前）。诸如拼写错误之类的琐碎更改不需要 Github issue。您的 Pull Request 应该只解决这个问题，而不需要进行其他更改—— 一个 PR 解决一个问题。
|
||||
- [ ] 格式化 Pull Request 标题，如[ISSUE #123] support Confluent Schema Registry。 Pull Request 中的每个提交都应该有一个有意义的主题行和正文。
|
||||
- [ ] 编写足够详细的 Pull Request 描述，以了解 Pull Request 的作用、方式和原因。
|
||||
- [ ] 编写必要的单元测试来验证您的逻辑更正。如果提交了新功能或重大更改，请记住在 test 模块中添加 integration-test
|
||||
- [ ] 确保编译通过，集成测试通过
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
<hr>
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
## 10.4 如果提交问题报告
|
||||
|
||||
在[提交问题](https://github.com/didi/KnowStreaming/issues/new/choose)的时候,请选择合适的模板来创建。
|
||||
|
||||
按照每个类型的问题模板描述清楚！
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
<hr>
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
## 10.5 开源激励计划
|
||||
|
||||
我们非常欢迎开发者们为 KnowStreaming 开源项目贡献一份力量，相应也将给予贡献者激励以表认可与感谢。
|
||||
|
||||
#### 参与贡献
|
||||
|
||||
1. 积极参与 Issue 的讨论，如答疑解惑、提供想法或报告无法解决的错误（Issue）
|
||||
2. 撰写和改进项目的文档（Wiki）
|
||||
3. 提交补丁优化代码（Coding）
|
||||
|
||||
#### 你将获得
|
||||
|
||||
1. 加入 KnowStreaming 开源项目贡献者名单并展示
|
||||
2. KnowStreaming 开源贡献者证书(纸质&电子版)
|
||||
3. KnowStreaming 贡献者精美大礼包(KnowStreamin/滴滴 周边)
|
||||
|
||||
#### 相关规则
|
||||
|
||||
- Contributer 和 Commiter 都会有对应的证书和对应的礼包
|
||||
- 每季度有 KnowStreaming 项目团队评选出杰出贡献者,颁发相应证书。
|
||||
- 年末进行年度评选
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
<hr>
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
<br/>
|
||||
|
||||
## 10.6 贡献者名单
|
||||
|
||||
#### KnowStreaming 开发者角色
|
||||
|
||||
KnowStreaming 开发者包含 Maintainer、Committer、Contributor 三种角色，每种角色的标准定义如下。
|
||||
|
||||
##### Maintainer
|
||||
|
||||
Maintainer 是对 KnowStreaming 项目的演进和发展做出显著贡献的个人。具体包含以下的标准：
|
||||
|
||||
- 完成多个关键模块或者工程的设计与开发，是项目的核心开发人员；
|
||||
- 持续的投入和激情，能够积极参与社区、官网、issue、PR 等项目相关事项的维护；
|
||||
- 在社区中具有有目共睹的影响力，能够代表 KnowStreaming 参加重要的社区会议和活动；
|
||||
- 具有培养 Committer 和 Contributor 的意识和能力；
|
||||
|
||||
##### Committer
|
||||
|
||||
Committer 是具有 KnowStreaming 仓库写权限的个人，包含以下的标准：
|
||||
|
||||
- 能够在长时间内做持续贡献 issue、PR 的个人；
|
||||
- 参与 issue 列表的维护及重要 feature 的讨论；
|
||||
- 参与 code review；
|
||||
|
||||
##### Contributor
|
||||
|
||||
Contributor 是对 KnowStreaming 项目有贡献的个人，标准为：
|
||||
|
||||
- 提交过 PR 并被合并；
|
||||
|
||||
开源贡献者名单(定期更新)
|
||||
|
||||
在名单内,但是没有收到贡献者礼品的同学,可以联系：szzdzhp001
|
||||
|
||||
| 姓名 | Github | 角色 | 公司 |
|
||||
| ------------------- | ---------------------------------------------------------- | ----------- | -------- |
|
||||
| 张亮 | [@zhangliangboy](https://github.com/zhangliangboy) | Maintainer | 滴滴出行 |
|
||||
| 谢鹏 | [@PenceXie](https://github.com/PenceXie) | Maintainer | 滴滴出行 |
|
||||
| 赵情融 | [@zqrferrari](https://github.com/zqrferrari) | Maintainer | 滴滴出行 |
|
||||
| 石臻臻 | [@shirenchuang](https://github.com/shirenchuang) | Maintainer | 滴滴出行 |
|
||||
| 曾巧 | [@ZQKC](https://github.com/ZQKC) | Maintainer | 滴滴出行 |
|
||||
| 孙超 | [@lucasun](https://github.com/lucasun) | Maintainer | 滴滴出行 |
|
||||
| 洪华驰 | [@brodiehong](https://github.com/brodiehong) | Maintainer | 滴滴出行 |
|
||||
| 许喆 | [@potaaaaaato](https://github.com/potaaaaaato) | Committer | 滴滴出行 |
|
||||
| 郭宇航 | [@GraceWalk](https://github.com/GraceWalk) | Committer | 滴滴出行 |
|
||||
| 李伟 | [@velee](https://github.com/velee) | Committer | 滴滴出行 |
|
||||
| 张占昌 | [@zzccctv](https://github.com/zzccctv) | Committer | 滴滴出行 |
|
||||
| 王东方 | [@wangdongfang-aden](https://github.com/wangdongfang-aden) | Committer | 滴滴出行 |
|
||||
| 王耀波 | [@WYAOBO](https://github.com/WYAOBO) | Committer | 滴滴出行 |
|
||||
| 赵寅锐 | [@ZHAOYINRUI](https://github.com/ZHAOYINRUI) | Maintainer | 字节跳动 |
|
||||
| haoqi123 | [@haoqi123](https://github.com/haoqi123) | Contributor | 前程无忧 |
|
||||
| chaixiaoxue | [@chaixiaoxue](https://github.com/chaixiaoxue) | Contributor | SYNNEX |
|
||||
| 陆晗 | [@luhea](https://github.com/luhea) | Contributor | 竞技世界 |
|
||||
| Mengqi777 | [@Mengqi777](https://github.com/Mengqi777) | Contributor | 腾讯 |
|
||||
| ruanliang-hualun | [@ruanliang-hualun](https://github.com/ruanliang-hualun) | Contributor | 网易 |
|
||||
| 17hao | [@17hao](https://github.com/17hao) | Contributor | |
|
||||
| Huyueeer | [@Huyueeer](https://github.com/Huyueeer) | Contributor | INVENTEC |
|
||||
| lomodays207 | [@lomodays207](https://github.com/lomodays207) | Contributor | 建信金科 |
|
||||
| Super .Wein（星痕） | [@superspeedone](https://github.com/superspeedone) | Contributor | 韵达 |
|
||||
| Hongten | [@Hongten](https://github.com/Hongten) | Contributor | Shopee |
|
||||
| 徐正熙 | [@hyper-xx)](https://github.com/hyper-xx) | Contributor | 滴滴出行 |
|
||||
| RichardZhengkay | [@RichardZhengkay](https://github.com/RichardZhengkay) | Contributor | 趣街 |
|
||||
| 罐子里的茶 | [@gzldc](https://github.com/gzldc) | Contributor | 道富 |
|
||||
| 陈忠玉 | [@paula](https://github.com/chenzhongyu11) | Contributor | 平安产险 |
|
||||
| 杨光 | [@yaangvipguang](https://github.com/yangvipguang) | Contributor |
|
||||
| 王亚聪 | [@wangyacongi](https://github.com/wangyacongi) | Contributor |
|
||||
| Yang Jing | [@yangbajing](https://github.com/yangbajing) | Contributor | |
|
||||
| 刘新元 Liu XinYuan | [@Liu-XinYuan](https://github.com/Liu-XinYuan) | Contributor | |
|
||||
| Joker | [@LiubeyJokerQueue](https://github.com/JokerQueue) | Contributor | 丰巢 |
|
||||
| Eason Lau | [@Liubey](https://github.com/Liubey) | Contributor | |
|
||||
| hailanxin | [@hailanxin](https://github.com/hailanxin) | Contributor | |
|
||||
| Qi Zhang | [@zzzhangqi](https://github.com/zzzhangqi) | Contributor | 好雨科技 |
|
||||
| fengxsong | [@fengxsong](https://github.com/fengxsong) | Contributor | |
|
||||
| 谢晓东 | [@Strangevy](https://github.com/Strangevy) | Contributor | 花生日记 |
|
||||
| ZhaoXinlong | [@ZhaoXinlong](https://github.com/ZhaoXinlong) | Contributor | |
|
||||
| xuehaipeng | [@xuehaipeng](https://github.com/xuehaipeng) | Contributor | |
|
||||
| 孔令续 | [@mrazkong](https://github.com/mrazkong) | Contributor | |
|
||||
| pierre xiong | [@pierre94](https://github.com/pierre94) | Contributor | |
|
||||
| PengShuaixin | [@PengShuaixin](https://github.com/PengShuaixin) | Contributor | |
|
||||
| 梁壮 | [@lz](https://github.com/silent-night-no-trace) | Contributor | |
|
||||
| 张晓寅 | [@ahu0605](https://github.com/ahu0605) | Contributor | 电信数智 |
|
||||
| 黄海婷 | [@Huanghaiting](https://github.com/Huanghaiting) | Contributor | 云徙科技 |
|
||||
| 任祥德 | [@RenChauncy](https://github.com/RenChauncy) | Contributor | 探马企服 |
|
||||
625
product/2-quick-start.md
Normal file
625
product/2-quick-start.md
Normal file
@@ -0,0 +1,625 @@
|
||||
---
|
||||
order: 2
|
||||
title: '2.快速开始'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 2.1、单机部署
|
||||
|
||||
**风险提示**
|
||||
|
||||
⚠️ 脚本全自动安装，会将所部署机器上的 MySQL、JDK、ES 等进行删除重装，请注意原有服务丢失风险。
|
||||
|
||||
### 2.1.1、产品下载
|
||||
|
||||
| KnowStreaming Version | Offline installer | Helm Chart | Docker Image |
|
||||
| :-------------------: | :------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------: | :---------------------------------------------: |
|
||||
| 3.0.0-beta.1 | [KnowStreaming-3.0.0-beta.1-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.1-offline.tar.gz) | [knowstreaming-manager-0.1.3.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.3.tgz) | [0.1.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.0.0-beta.2 | [KnowStreaming-3.0.0-beta.2-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.2-offline.tar.gz) | [knowstreaming-manager-0.1.4.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.4.tgz) | [0.2.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.0.0-beta.3 | [KnowStreaming-3.0.0-beta.3-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.3-offline.tar.gz) | [knowstreaming-manager-0.1.5.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.5.tgz) | [0.3.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.0.0 | [KnowStreaming-3.0.0-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-offline.tar.gz) | [knowstreaming-manager-0.1.6.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.6.tgz) | [0.4.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.0.1 | [KnowStreaming-3.0.1-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.1-offline.tar.gz) | [knowstreaming-manager-0.1.7.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.7.tgz) | [0.5.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.1.0 | [KnowStreaming-3.1.0-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.1.0-offline.tar.gz) | [knowstreaming-manager-0.1.8.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.8.tgz) | [0.6.0](https://hub.docker.com/u/knowstreaming) |
|
||||
| 3.2.0 | [KnowStreaming-3.2.0-offline.tar.gz](http://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.1.0-offline.tar.gz) | [knowstreaming-manager-0.1.9.tgz](http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.8.tgz) | [0.7.0](https://hub.docker.com/u/knowstreaming) |
|
||||
|
||||
### 2.1.2、安装说明
|
||||
|
||||
- 以 `v3.0.0-beta.1` 版本为例进行部署；
|
||||
- 以 CentOS-7 为例，系统基础配置要求 4C-8G；
|
||||
- 部署完成后，可通过浏览器：`IP:PORT` 进行访问，默认端口是 `8080`，系统默认账号密码: `admin` / `admin2022_`；（注意！`v3.0.0-beta.2` 及以后版本默认账号和密码为：`admin` / `admin`）
|
||||
- 本文为单机部署，如需分布式部署，[请联系我们](https://knowstreaming.com/support-center)
|
||||
|
||||
**软件依赖**
|
||||
|
||||
| 软件名 | 版本要求 | 默认端口 |
|
||||
| ------------- | ------------ | -------- |
|
||||
| MySQL | v5.7 或 v8.0 | 3306 |
|
||||
| ElasticSearch | v7.6+ | 8060 |
|
||||
| JDK | v8+ | - |
|
||||
| CentOS | v6+ | - |
|
||||
| Ubuntu | v16+ | - |
|
||||
|
||||
|
||||
|
||||
### 2.1.3、脚本部署
|
||||
|
||||
**在线安装**
|
||||
|
||||
```bash
|
||||
# 在服务器中下载安装脚本, 该脚本中会在当前目录下，重新安装MySQL。重装后的mysql密码存放在当前目录的mysql.password文件中。
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/deploy_KnowStreaming.sh
|
||||
|
||||
# 执行脚本（会提示选择安装的版本）
|
||||
sh deploy_KnowStreaming.sh
|
||||
|
||||
# 访问地址（根据实际IP地址更换）
|
||||
127.0.0.1:8080
|
||||
```
|
||||
|
||||
**离线安装**
|
||||
|
||||
```bash
|
||||
# 将安装包下载到本地且传输到目标服务器
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.3-offline.tar.gz
|
||||
|
||||
# 解压安装包
|
||||
tar -zxf KnowStreaming-3.0.0-beta.1-offline.tar.gz
|
||||
|
||||
# 执行安装脚本
|
||||
sh deploy_KnowStreaming-offline.sh
|
||||
|
||||
# 访问地址（根据实际IP地址更换）
|
||||
127.0.0.1:8080
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 2.1.4、容器化部署
|
||||
|
||||
#### 2.1.4.1、Helm
|
||||
|
||||
**环境依赖**
|
||||
|
||||
- Kubernetes >= 1.14 ，Helm >= 2.17.0
|
||||
- 系统基础配置要求 14C-26G,可根据需要调整应用副本数。
|
||||
- 默认依赖全部安装，ElasticSearch（3 节点集群模式） + MySQL(单机) + KnowStreaming-manager(2 副本) + KnowStreaming-ui(2 副本)
|
||||
- 请配置持久化存储卷
|
||||
- 使用已有的 ElasticSearch(7.6.x) 和 MySQL(5.7) 只需调整 values.yaml 部分参数即可
|
||||
|
||||
**安装命令**
|
||||
|
||||
```bash
|
||||
# 相关镜像在Docker Hub都可以下载
|
||||
# 快速安装(NAMESPACE需要更改为已存在的，安装启动需要几分钟初始化请稍等~)
|
||||
helm install -n [NAMESPACE] [NAME] http://download.knowstreaming.com/charts/knowstreaming-manager-0.1.9.tgz
|
||||
|
||||
# 获取KnowStreaming前端ui的service. 默认nodeport方式.
|
||||
# (http://nodeIP:nodeport，默认用户名密码：admin/admin2022_)
|
||||
# `v3.0.0-beta.2`版本开始（helm chart包版本0.1.4开始），默认账号密码为`admin` / `admin`；
|
||||
|
||||
# 添加仓库
|
||||
helm repo add knowstreaming http://download.knowstreaming.com/charts
|
||||
|
||||
# 拉取最新版本
|
||||
helm pull knowstreaming/knowstreaming-manager
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 2.1.4.2、Docker Compose
|
||||
|
||||
**环境依赖**
|
||||
|
||||
- [Docker](https://docs.docker.com/engine/install/)
|
||||
- [Docker Compose](https://docs.docker.com/compose/install/)
|
||||
|
||||
**安装命令**
|
||||
|
||||
```bash
|
||||
# `v3.0.0-beta.2`版本开始(docker镜像为0.2.0版本开始)，默认账号密码为`admin` / `admin`；
|
||||
# https://hub.docker.com/u/knowstreaming 在此处寻找最新镜像版本
|
||||
# mysql与es可以使用自己搭建的服务,调整对应配置即可
|
||||
|
||||
# 复制docker-compose.yml到指定位置后执行下方命令即可启动
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
**验证安装**
|
||||
|
||||
```shell
|
||||
docker-compose ps
|
||||
# 验证启动 - 状态为 UP 则表示成功
|
||||
Name Command State Ports
|
||||
----------------------------------------------------------------------------------------------------
|
||||
elasticsearch-single /usr/local/bin/docker-entr ... Up 9200/tcp, 9300/tcp
|
||||
knowstreaming-init /bin/bash /es_template_cre ... Up
|
||||
knowstreaming-manager /bin/sh /ks-start.sh Up 80/tcp
|
||||
knowstreaming-mysql /entrypoint.sh mysqld Up (health: starting) 3306/tcp, 33060/tcp
|
||||
knowstreaming-ui /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
|
||||
|
||||
# 稍等一分钟左右 knowstreaming-init 会退出，表示es初始化完成，可以访问页面
|
||||
Name Command State Ports
|
||||
-------------------------------------------------------------------------------------------
|
||||
knowstreaming-init /bin/bash /es_template_cre ... Exit 0
|
||||
knowstreaming-mysql /entrypoint.sh mysqld Up (healthy) 3306/tcp, 33060/tcp
|
||||
```
|
||||
|
||||
**访问**
|
||||
|
||||
```http request
|
||||
http://127.0.0.1:80/
|
||||
```
|
||||
|
||||
**docker-compose.yml**
|
||||
|
||||
```yml
|
||||
version: '2'
|
||||
services:
|
||||
# *不要调整knowstreaming-manager服务名称，ui中会用到
|
||||
knowstreaming-manager:
|
||||
image: knowstreaming/knowstreaming-manager:0.7.0
|
||||
container_name: knowstreaming-manager
|
||||
privileged: true
|
||||
restart: always
|
||||
depends_on:
|
||||
- elasticsearch-single
|
||||
- knowstreaming-mysql
|
||||
expose:
|
||||
- 80
|
||||
command:
|
||||
- /bin/sh
|
||||
- /ks-start.sh
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
# mysql服务地址
|
||||
SERVER_MYSQL_ADDRESS: knowstreaming-mysql:3306
|
||||
# mysql数据库名
|
||||
SERVER_MYSQL_DB: know_streaming
|
||||
# mysql用户名
|
||||
SERVER_MYSQL_USER: root
|
||||
# mysql用户密码
|
||||
SERVER_MYSQL_PASSWORD: admin2022_
|
||||
# es服务地址
|
||||
SERVER_ES_ADDRESS: elasticsearch-single:9200
|
||||
# 服务JVM参数
|
||||
JAVA_OPTS: -Xmx1g -Xms1g
|
||||
# 对于kafka中ADVERTISED_LISTENERS填写的hostname可以通过该方式完成
|
||||
# extra_hosts:
|
||||
# - "hostname:x.x.x.x"
|
||||
# 服务日志路径
|
||||
# volumes:
|
||||
# - /ks/manage/log:/logs
|
||||
knowstreaming-ui:
|
||||
image: knowstreaming/knowstreaming-ui:0.7.0
|
||||
container_name: knowstreaming-ui
|
||||
restart: always
|
||||
ports:
|
||||
- '80:80'
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
depends_on:
|
||||
- knowstreaming-manager
|
||||
# extra_hosts:
|
||||
# - "hostname:x.x.x.x"
|
||||
elasticsearch-single:
|
||||
image: docker.io/library/elasticsearch:7.6.2
|
||||
container_name: elasticsearch-single
|
||||
restart: always
|
||||
expose:
|
||||
- 9200
|
||||
- 9300
|
||||
# ports:
|
||||
# - '9200:9200'
|
||||
# - '9300:9300'
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
# es的JVM参数
|
||||
ES_JAVA_OPTS: -Xms512m -Xmx512m
|
||||
# 单节点配置，多节点集群参考 https://www.elastic.co/guide/en/elasticsearch/reference/7.6/docker.html#docker-compose-file
|
||||
discovery.type: single-node
|
||||
# 数据持久化路径
|
||||
# volumes:
|
||||
# - /ks/es/data:/usr/share/elasticsearch/data
|
||||
|
||||
# es初始化服务，与manager使用同一镜像
|
||||
# 首次启动es需初始化模版和索引,后续会自动创建
|
||||
knowstreaming-init:
|
||||
image: knowstreaming/knowstreaming-manager:0.7.0
|
||||
container_name: knowstreaming-init
|
||||
depends_on:
|
||||
- elasticsearch-single
|
||||
command:
|
||||
- /bin/bash
|
||||
- /es_template_create.sh
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
# es服务地址
|
||||
SERVER_ES_ADDRESS: elasticsearch-single:9200
|
||||
|
||||
knowstreaming-mysql:
|
||||
image: knowstreaming/knowstreaming-mysql:0.7.0
|
||||
container_name: knowstreaming-mysql
|
||||
restart: always
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
# root 用户密码
|
||||
MYSQL_ROOT_PASSWORD: admin2022_
|
||||
# 初始化时创建的数据库名称
|
||||
MYSQL_DATABASE: know_streaming
|
||||
# 通配所有host,可以访问远程
|
||||
MYSQL_ROOT_HOST: '%'
|
||||
expose:
|
||||
- 3306
|
||||
# ports:
|
||||
# - '3306:3306'
|
||||
# 数据持久化路径
|
||||
# volumes:
|
||||
# - /ks/mysql/data:/data/mysql
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 2.1.5、手动部署
|
||||
|
||||
**部署流程**
|
||||
|
||||
1. 安装 `JDK-11`、`MySQL`、`ElasticSearch` 等依赖服务
|
||||
2. 安装 KnowStreaming
|
||||
|
||||
|
||||
|
||||
#### 2.1.5.1、安装 MySQL 服务
|
||||
|
||||
**yum 方式安装**
|
||||
|
||||
```bash
|
||||
# 配置yum源
|
||||
wget https://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm
|
||||
rpm -ivh mysql57-community-release-el7-9.noarch.rpm
|
||||
|
||||
# 执行安装
|
||||
yum -y install mysql-server mysql-client
|
||||
|
||||
# 服务启动
|
||||
systemctl start mysqld
|
||||
|
||||
# 获取初始密码并修改
|
||||
old_pass=`grep 'temporary password' /var/log/mysqld.log | awk '{print $NF}' | tail -n 1`
|
||||
|
||||
mysql -NBe "alter user USER() identified by 'Didi_km_678';" --connect-expired-password -uroot -p$old_pass
|
||||
```
|
||||
|
||||
**rpm 方式安装**
|
||||
|
||||
```bash
|
||||
# 下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/knowsearch/mysql5.7.tar.gz
|
||||
|
||||
# 解压到指定目录
|
||||
tar -zxf mysql5.7.tar.gz -C /tmp/
|
||||
|
||||
# 执行安装
|
||||
yum -y localinstall /tmp/libaio-*.rpm /tmp/mysql-*.rpm
|
||||
|
||||
# 服务启动
|
||||
systemctl start mysqld
|
||||
|
||||
|
||||
# 获取初始密码并修改
|
||||
old_pass=`grep 'temporary password' /var/log/mysqld.log | awk '{print $NF}' | tail -n 1`
|
||||
|
||||
mysql -NBe "alter user USER() identified by 'Didi_km_678';" --connect-expired-password -uroot -p$old_pass
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 2.1.5.2、配置 JDK 环境
|
||||
|
||||
```bash
|
||||
# 下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/jdk11.tar.gz
|
||||
|
||||
# 解压到指定目录
|
||||
tar -zxf jdk11.tar.gz -C /usr/local/
|
||||
|
||||
# 更改目录名
|
||||
mv /usr/local/jdk-11.0.2 /usr/local/java11
|
||||
|
||||
# 添加到环境变量
|
||||
echo "export JAVA_HOME=/usr/local/java11" >> ~/.bashrc
|
||||
echo "export CLASSPATH=/usr/java/java11/lib" >> ~/.bashrc
|
||||
echo "export PATH=$JAVA_HOME/bin:$PATH:$HOME/bin" >> ~/.bashrc
|
||||
|
||||
source ~/.bashrc
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 2.1.5.3、ElasticSearch 实例搭建
|
||||
|
||||
- ElasticSearch 用于存储平台采集的 Kafka 指标；
|
||||
- 以下安装示例为单节点模式，如需集群部署可以参考：[Elasticsearch 官方文档](https://www.elastic.co/guide/en/elasticsearch/reference/7.6/elasticsearch-intro.html)
|
||||
|
||||
```bash
|
||||
# 下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/elasticsearch.tar.gz
|
||||
|
||||
# 创建ES数据存储目录
|
||||
mkdir -p /data/es_data
|
||||
|
||||
# 创建ES所属用户
|
||||
useradd arius
|
||||
|
||||
# 配置用户的打开文件数
|
||||
echo "arius soft nofile 655350" >> /etc/security/limits.conf
|
||||
echo "arius hard nofile 655350" >> /etc/security/limits.conf
|
||||
echo "vm.max_map_count = 655360" >> /etc/sysctl.conf
|
||||
sysctl -p
|
||||
|
||||
# 解压安装包
|
||||
tar -zxf elasticsearch.tar.gz -C /data/
|
||||
|
||||
# 更改目录所属组
|
||||
chown -R arius:arius /data/
|
||||
|
||||
# 修改配置文件(参考以下配置)
|
||||
vim /data/elasticsearch/config/elasticsearch.yml
|
||||
cluster.name: km_es
|
||||
node.name: es-node1
|
||||
node.master: true
|
||||
node.data: true
|
||||
path.data: /data/es_data
|
||||
http.port: 8060
|
||||
discovery.seed_hosts: ["127.0.0.1:9300"]
|
||||
|
||||
# 修改内存配置
|
||||
vim /data/elasticsearch/config/jvm.options
|
||||
-Xms2g
|
||||
-Xmx2g
|
||||
|
||||
# 启动服务
|
||||
su - arius
|
||||
export JAVA_HOME=/usr/local/java11
|
||||
sh /data/elasticsearch/control.sh start
|
||||
|
||||
# 确认状态
|
||||
sh /data/elasticsearch/control.sh status
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 2.1.5.4、KnowStreaming 实例搭建
|
||||
|
||||
```bash
|
||||
# 下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.1.tar.gz
|
||||
|
||||
# 解压安装包到指定目录
|
||||
tar -zxf KnowStreaming-3.0.0-beta.1.tar.gz -C /data/
|
||||
|
||||
# 修改启动脚本并加入systemd管理
|
||||
cd /data/KnowStreaming/
|
||||
|
||||
# 创建相应的库和导入初始化数据
|
||||
mysql -uroot -pDidi_km_678 -e "create database know_streaming;"
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-ks-km.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-logi-job.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-logi-security.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/dml-ks-km.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/dml-logi.sql
|
||||
|
||||
# 创建elasticsearch初始化数据
|
||||
sh ./bin/init_es_template.sh
|
||||
|
||||
# 修改配置文件
|
||||
vim ./conf/application.yml
|
||||
|
||||
# 监听端口
|
||||
server:
|
||||
port: 8080 # web 服务端口
|
||||
tomcat:
|
||||
accept-count: 1000
|
||||
max-connections: 10000
|
||||
|
||||
# ES地址
|
||||
es.client.address: 127.0.0.1:8060
|
||||
|
||||
# 数据库配置（一共三处地方，修改正确的mysql地址和数据库名称以及用户名密码）
|
||||
jdbc-url: jdbc:mariadb://127.0.0.1:3306/know_streaming?.....
|
||||
username: root
|
||||
password: Didi_km_678
|
||||
|
||||
# 启动服务
|
||||
cd /data/KnowStreaming/bin/
|
||||
sh startup.sh
|
||||
```
|
||||
|
||||
### 2.1.6、Rainbond 部署
|
||||
|
||||
#### 2.1.6.1、根据快速安装文档部署 [Rainbond](/docs/quick-start/quick-install/)
|
||||
|
||||
KnowStreaming 已发布至 `开源应用商店` ，用户可搜索 `KnowStreaming`，一键安装 KnowStreaming
|
||||
|
||||
|
||||
|
||||
安装后，访问 `KnowStreaming-UI` 进入控制台，默认密码：admin / admin
|
||||
|
||||
|
||||
|
||||
#### 2.1.6.2、快速部署 Kafka 集群
|
||||
|
||||
上面我们已经部署了 `KnowStreaming`，接下来我们也可通过 `开源应用商店` 安装 Kafka 集群并进行对接。
|
||||
|
||||
Kafka 已发布至 `开源应用商店` ，用户可搜索 `kafka`，一键安装 Kafka-Zookeeper-Bitnami
|
||||
|
||||
|
||||
|
||||
安装完成后，我们进入 `kafka1` 和 `kafka2` 的组件 -> 环境变量
|
||||
|
||||
修改 `KAFKA_CFG_ADVERTISED_LISTENERS` 环境变量为组件`9092`端口的对外 IP + 端口，例如：`PLAINTEXT://192.168.3.162:10000`
|
||||
|
||||
修改 `JMX_PORT` 环境变量为 TCP 对外端口地址供 `Logikm` 获取指标。例如：`JMX_PORT`为 9999，组件对应的端口也要为 9999，同时 tcp 对外端口也是 9999
|
||||
|
||||
#### 2.1.6.3、使用 KnowStreaming 对接并管理 Kafka 集群
|
||||
|
||||
接下来我们通过 `KnowStreaming` 对接刚刚安装的 `kafka`集群。
|
||||
|
||||
访问 `KnowStreaming`，接入集群，根据页面提示填写对应信息。
|
||||
|
||||
对接完成后，我们就可通过 `KnowStreaming` 管理 `kafka` 集群啦。
|
||||
|
||||
---
|
||||
|
||||
## 2.2、登录系统
|
||||
|
||||
部署完成后，打开浏览器输入 IP 地址 + 端口(默认端口 8080) 即可访问 `Know Streaming`。
|
||||
|
||||
默认账号和密码为：`admin` / `admin`。（注意！v3.0 beta1 版本默认账号和密码为：`admin` / `admin2022_`）
|
||||
|
||||
---
|
||||
|
||||
## 2.3、开始使用
|
||||
|
||||
登录完成后，可根据以下场景快速体验基本功能。
|
||||
|
||||
### 2.3.1、接入集群
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“接入集群”
|
||||
|
||||
- 步骤 2:填写相关集群信息
|
||||
|
||||
- 集群名称：平台内不能重复
|
||||
- Bootstrap Servers：输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）。
|
||||
- Zookeeper：输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）
|
||||
- Metrics 选填：JMX Port，输入 JMX 端口号；MaxConn，输入服务端最大允许的连接数
|
||||
- Security：JMX 账号密码
|
||||
- Version：kafka 版本，如果没有匹配则可以选择相近版本
|
||||
- 集群配置选填：创建 kafka 客户端进行信息获取的相关配置
|
||||
|
||||
|
||||
|
||||
### 2.3.2、新增 Topic
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“新增 Topic”按钮>“创建 Topic“抽屉
|
||||
|
||||
- 步骤 2:输入“Topic 名称（不能重复）”、“Topic 描述”、“分区数”、“副本数”、“数据保存时间”、“清理策略（删除或压缩）”
|
||||
|
||||
- 步骤 3:展开“更多配置”可以打开高级配置选项，根据自己需要输入相应配置参数
|
||||
|
||||
- 步骤 4:点击“确定”，创建 Topic 完成
|
||||
|
||||
|
||||
|
||||
### 2.3.3、Topic 扩分区
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“Topic 列表“>操作项”扩分区“>“扩分区”抽屉
|
||||
|
||||
- 步骤 2:扩分区抽屉展示内容为“流量的趋势图”、“当前分区数及支持的最低消息写入速率”、“扩分区后支持的最低消息写入速率”
|
||||
|
||||
- 步骤 3:输入所需的分区总数，自动计算出扩分区后支持的最低消息写入速率
|
||||
|
||||
- 步骤 4:点击确定，扩分区完成
|
||||
|
||||
|
||||
|
||||
### 2.3.4、Topic 批量扩缩副本
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量扩缩副本“>“批量扩缩容”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行扩缩容的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:Topic 列表展示 Topic“近三天平均流量”、“近三天峰值流量及时间”、“Partition 数”、”当前副本数“、“新副本数”
|
||||
|
||||
- 步骤 4:扩容时，选择目标节点，新增的副本会在选择的目标节点上；缩容时不需要选择目标节点，自动删除最后一个（或几个）副本
|
||||
|
||||
- 步骤 5:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 6:输入任务描述
|
||||
|
||||
- 步骤 7:点击“确定”，创建 Topic 扩缩副本任务
|
||||
|
||||
- 步骤 8:去“Job”模块的 Job 列表查看创建的任务，如果已经执行则可以查看执行进度；如果未开始执行则可以编辑任务
|
||||
|
||||
|
||||
|
||||
### 2.3.5、Topic 批量迁移
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量迁移“>“批量迁移”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行迁移的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:选择所需要迁移的 partition 和迁移数据的时间范围
|
||||
|
||||
- 步骤 4:选择目标节点（节点数必须不小于最大副本数）
|
||||
|
||||
- 步骤 5:点击“预览任务计划”，打开“任务计划”二次抽屉，可对目标 Broker ID 进行编辑
|
||||
|
||||
- 步骤 6:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 7:输入任务描述
|
||||
|
||||
- 步骤 8:点击“确定”，创建 Topic 迁移任务
|
||||
|
||||
- 步骤 9:去“Job”模块的 Job 列表查看创建的任务，如果已经执行则可以查看执行进度；如果未开始执行则可以编辑任务
|
||||
|
||||
|
||||
|
||||
### 2.3.6、设置 Cluster 健康检查规则
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“集群健康状态旁边 icon”>“健康度设置抽屉”
|
||||
|
||||
- 步骤 2:健康度设置抽屉展示出了检查项和其对应的权重，可以修改检查项的检查规则
|
||||
|
||||
- 步骤 3:检查规则可配置，分别为
|
||||
|
||||
- Cluster：集群 controller 数不等于 1（数字不可配置）不通过
|
||||
- Broker：RequestQueueSize 大于等于 10（默认为 10，可配置数字）不通过
|
||||
- Broker：NetworkProcessorAvgIdlePercent 的 Idle 小于等于 0.8%（默认为 0.8%，可配置数字）不通过
|
||||
- Topic：无 leader 的 Topic 数量，大于等于 1（默认为 1，数字可配置）不通过
|
||||
- Topic：Topic 在 10（默认为 10，数字可配置）个周期内 8（默认为 8，数字可配置）个周期内处于未同步的状态则不通过
|
||||
- ConsumerGroup：Group 在 10（默认为 10，数字可配置）个周期内进行 8（默认为 8，数字可配置）次 re-balance 不通过
|
||||
|
||||
- 步骤 4:设置完成后，点击“确认”，健康检查规则设置成功
|
||||
|
||||
|
||||
|
||||
### 2.3.7、图表指标筛选
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“指标筛选 icon”>“指标筛选抽屉”
|
||||
|
||||
- 步骤 2:指标筛选抽屉展示信息为以下几类“Health”、“Cluster”、“Broker”、“Consumer”、“Security”、“Job”
|
||||
|
||||
- 步骤 3:默认勾选比较重要的指标进行展示。根据需要选中/取消选中相应指标，点击”确认“，指标筛选成功，展示的图表随之变化
|
||||
|
||||
|
||||
|
||||
### 2.3.8、新增 ACL
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“Users”>“新增 ACL”
|
||||
|
||||
- 步骤 2:输入 ACL 配置参数
|
||||
|
||||
- ACL 用途：生产权限、消费权限、自定义权限
|
||||
- 生产权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic
|
||||
- 消费权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic；可选择应用于所有 Consumer Group 或者特定 Consumer Group
|
||||
|
||||
- 步骤 3:点击“确定”，新增 ACL 成功
|
||||
|
||||
|
||||
|
||||
### 2.3.9、用户管理
|
||||
|
||||
用户管理是提供给管理员进行人员管理和用户角色管理的功能模块，可以进行新增用户和分配角色。下面是一个典型的场景：
|
||||
eg：团队加入了新成员，需要给这位成员分配一个使用系统的账号，需要以下几个步骤
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“人员管理”>“新增用户”，输入“账号”、“实名”、“密码”，根据此账号所需要的权限，选择此账号所对应的角色。如果有满足权限的角色，则用户新增成功。如果没有满足权限的角色，则需要新增角色（步骤 2）
|
||||
|
||||
- 步骤 2:点击“系统管理”>“用户管理”>“角色管理”>“新增角色”。输入角色名称和描述，给此角色分配权限，点击“确定”，角色新增成功
|
||||
|
||||
- 步骤 3:根据此新增的角色，参考步骤 1，重新新增用户
|
||||
|
||||
- 步骤 4:此用户账号新增成功，可以进行登录产品使用
|
||||
|
||||
|
||||
213
product/3-design-doc.md
Normal file
213
product/3-design-doc.md
Normal file
@@ -0,0 +1,213 @@
|
||||
---
|
||||
order: 3
|
||||
title: '3.设计文档'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 3.1、架构设计
|
||||
|
||||
### 3.1.1、功能架构
|
||||
|
||||
|
||||
|
||||
### 3.1.2、技术架构
|
||||
|
||||
|
||||
|
||||
## 3.2、生态对接(持续完善)
|
||||
|
||||
### 3.2.1、LDAP 对接(持续完善)
|
||||
|
||||
### 3.2.2、Prometheus + Grafana 对接
|
||||
|
||||
安装配置 Knowstreaming + Prometheus + Grafana，参考 https://prometheus.io/docs/visualization/grafana/
|
||||
|
||||
#### 配置 promethues
|
||||
|
||||
```yaml
|
||||
scrape_configs:
|
||||
- job_name: 'ks'
|
||||
# ks metrics 路径
|
||||
metrics_path: '/metrics/prometheus'
|
||||
static_configs:
|
||||
# ks 集群地址
|
||||
- targets: ['172.16.1.10:8080', '172.16.1.11:8080', '172.16.1.12:8080']
|
||||
```
|
||||
|
||||
配置完成后，重启 prometheus
|
||||
|
||||
```sh
|
||||
curl -X POST http://localhost:9090/-/reload
|
||||
```
|
||||
|
||||
访问 promethues 查看指标是否采集成功
|
||||
|
||||
- Cluster_MessagesIn
|
||||
- ...
|
||||
|
||||
#### 配置 grafana
|
||||
|
||||
- 配置 Prometheus 源
|
||||
- 参考 https://prometheus.io/docs/visualization/grafana/
|
||||
- 导入监控面板配置文件
|
||||
- https://grafana.com/grafana/dashboards/16729-knowstreaming/
|
||||
|
||||
|
||||
|
||||
|
||||
#### 预览
|
||||
|
||||
|
||||
|
||||
## 3.3、指标说明
|
||||
|
||||
当前 KnowStreaming 支持针对 kafka 集群的多维度指标的采集和展示，同时也支持多个 kafka 版本的指标进行兼容，以下是 KnowStreaming 支持的指标说明。
|
||||
|
||||
现在对当前 KnowStreaming 支持的指标从指标名称、指标单位、指标说明、kafka 版本、企业/开源版指标 五个维度进行说明。
|
||||
|
||||
### 3.3.1、Cluster 指标
|
||||
|
||||
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
|
||||
| ------------------------- | -------- | ------------------------------------ | ---------------- | --------------- |
|
||||
| HealthScore | 分 | 集群总体的健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed | 个 | 集群总体健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal | 个 | 集群总体健康检查总数 | 全部版本 | 开源版 |
|
||||
| HealthScore_Topics | 分 | 集群 Topics 的健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed_Topics | 个 | 集群 Topics 健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal_Topics | 个 | 集群 Topics 健康检查总数 | 全部版本 | 开源版 |
|
||||
| HealthScore_Brokers | 分 | 集群 Brokers 的健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed_Brokers | 个 | 集群 Brokers 健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal_Brokers | 个 | 集群 Brokers 健康检查总数 | 全部版本 | 开源版 |
|
||||
| HealthScore_Groups | 分 | 集群 Groups 的健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed_Groups | 个 | 集群 Groups 健康检查总数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal_Groups | 个 | 集群 Groups 健康检查总数 | 全部版本 | 开源版 |
|
||||
| HealthScore_Cluster | 分 | 集群自身的健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed_Cluster | 个 | 集群自身健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal_Cluster | 个 | 集群自身健康检查总数 | 全部版本 | 开源版 |
|
||||
| TotalRequestQueueSize | 个 | 集群中总的请求队列数 | 全部版本 | 开源版 |
|
||||
| TotalResponseQueueSize | 个 | 集群中总的响应队列数 | 全部版本 | 开源版 |
|
||||
| EventQueueSize | 个 | 集群中 Controller 的 EventQueue 大小 | 2.0.0 及以上版本 | 开源版 |
|
||||
| ActiveControllerCount | 个 | 集群中存活的 Controller 数 | 全部版本 | 开源版 |
|
||||
| TotalProduceRequests | 个 | 集群中的 Produce 每秒请求数 | 全部版本 | 开源版 |
|
||||
| TotalLogSize | byte | 集群总的已使用的磁盘大小 | 全部版本 | 开源版 |
|
||||
| ConnectionsCount | 个 | 集群的连接(Connections)个数 | 全部版本 | 开源版 |
|
||||
| Zookeepers | 个 | 集群中存活的 zk 节点个数 | 全部版本 | 开源版 |
|
||||
| ZookeepersAvailable | 是/否 | ZK 地址是否合法 | 全部版本 | 开源版 |
|
||||
| Brokers | 个 | 集群的 broker 的总数 | 全部版本 | 开源版 |
|
||||
| BrokersAlive | 个 | 集群的 broker 的存活数 | 全部版本 | 开源版 |
|
||||
| BrokersNotAlive | 个 | 集群的 broker 的未存活数 | 全部版本 | 开源版 |
|
||||
| Replicas | 个 | 集群中 Replica 的总数 | 全部版本 | 开源版 |
|
||||
| Topics | 个 | 集群中 Topic 的总数 | 全部版本 | 开源版 |
|
||||
| Partitions | 个 | 集群的 Partitions 总数 | 全部版本 | 开源版 |
|
||||
| PartitionNoLeader | 个 | 集群中的 PartitionNoLeader 总数 | 全部版本 | 开源版 |
|
||||
| PartitionMinISR_S | 个 | 集群中的小于 PartitionMinISR 总数 | 全部版本 | 开源版 |
|
||||
| PartitionMinISR_E | 个 | 集群中的等于 PartitionMinISR 总数 | 全部版本 | 开源版 |
|
||||
| PartitionURP | 个 | 集群中的未同步的 Partition 总数 | 全部版本 | 开源版 |
|
||||
| MessagesIn | 条/s | 集群每条消息写入条数 | 全部版本 | 开源版 |
|
||||
| Messages | 条 | 集群总的消息条数 | 全部版本 | 开源版 |
|
||||
| LeaderMessages | 条 | 集群中 leader 总的消息条数 | 全部版本 | 开源版 |
|
||||
| BytesIn | byte/s | 集群的每秒写入字节数 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_5 | byte/s | 集群的每秒写入字节数，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_15 | byte/s | 集群的每秒写入字节数，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut | byte/s | 集群的每秒流出字节数 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_5 | byte/s | 集群的每秒流出字节数，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_15 | byte/s | 集群的每秒流出字节数，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| Groups | 个 | 集群中 Group 的总数 | 全部版本 | 开源版 |
|
||||
| GroupActives | 个 | 集群中 ActiveGroup 的总数 | 全部版本 | 开源版 |
|
||||
| GroupEmptys | 个 | 集群中 EmptyGroup 的总数 | 全部版本 | 开源版 |
|
||||
| GroupRebalances | 个 | 集群中 RebalanceGroup 的总数 | 全部版本 | 开源版 |
|
||||
| GroupDeads | 个 | 集群中 DeadGroup 的总数 | 全部版本 | 开源版 |
|
||||
| Alive | 是/否 | 集群是否存活，1：存活；0：没有存活 | 全部版本 | 开源版 |
|
||||
| AclEnable | 是/否 | 集群是否开启 Acl，1：是；0：否 | 全部版本 | 开源版 |
|
||||
| Acls | 个 | ACL 数 | 全部版本 | 开源版 |
|
||||
| AclUsers | 个 | ACL-KafkaUser 数 | 全部版本 | 开源版 |
|
||||
| AclTopics | 个 | ACL-Topic 数 | 全部版本 | 开源版 |
|
||||
| AclGroups | 个 | ACL-Group 数 | 全部版本 | 开源版 |
|
||||
| Jobs | 个 | 集群任务总数 | 全部版本 | 开源版 |
|
||||
| JobsRunning | 个 | 集群 running 任务总数 | 全部版本 | 开源版 |
|
||||
| JobsWaiting | 个 | 集群 waiting 任务总数 | 全部版本 | 开源版 |
|
||||
| JobsSuccess | 个 | 集群 success 任务总数 | 全部版本 | 开源版 |
|
||||
| JobsFailed | 个 | 集群 failed 任务总数 | 全部版本 | 开源版 |
|
||||
| LoadReBalanceEnable | 是/否 | 是否开启均衡, 1：是；0：否 | 全部版本 | 企业版 |
|
||||
| LoadReBalanceCpu | 是/否 | CPU 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
|
||||
| LoadReBalanceNwIn | 是/否 | BytesIn 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
|
||||
| LoadReBalanceNwOut | 是/否 | BytesOut 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
|
||||
| LoadReBalanceDisk | 是/否 | Disk 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
|
||||
|
||||
### 3.3.2、Broker 指标
|
||||
|
||||
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
|
||||
| ----------------------- | -------- | ------------------------------------- | ---------- | --------------- |
|
||||
| HealthScore | 分 | Broker 健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed | 个 | Broker 健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal | 个 | Broker 健康检查总数 | 全部版本 | 开源版 |
|
||||
| TotalRequestQueueSize | 个 | Broker 的请求队列大小 | 全部版本 | 开源版 |
|
||||
| TotalResponseQueueSize | 个 | Broker 的应答队列大小 | 全部版本 | 开源版 |
|
||||
| ReplicationBytesIn | byte/s | Broker 的副本流入流量 | 全部版本 | 开源版 |
|
||||
| ReplicationBytesOut | byte/s | Broker 的副本流出流量 | 全部版本 | 开源版 |
|
||||
| MessagesIn | 条/s | Broker 的每秒消息流入条数 | 全部版本 | 开源版 |
|
||||
| TotalProduceRequests | 个/s | Broker 上 Produce 的每秒请求数 | 全部版本 | 开源版 |
|
||||
| NetworkProcessorAvgIdle | % | Broker 的网络处理器的空闲百分比 | 全部版本 | 开源版 |
|
||||
| RequestHandlerAvgIdle | % | Broker 上请求处理器的空闲百分比 | 全部版本 | 开源版 |
|
||||
| PartitionURP | 个 | Broker 上的未同步的副本的个数 | 全部版本 | 开源版 |
|
||||
| ConnectionsCount | 个 | Broker 上网络链接的个数 | 全部版本 | 开源版 |
|
||||
| BytesIn | byte/s | Broker 的每秒数据写入量 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_5 | byte/s | Broker 的每秒数据写入量，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_15 | byte/s | Broker 的每秒数据写入量，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut | byte/s | Broker 的每秒数据流出量 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_5 | byte/s | Broker 的每秒数据流出量，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_15 | byte/s | Broker 的每秒数据流出量，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| ReassignmentBytesIn | byte/s | Broker 的每秒数据迁移写入量 | 全部版本 | 开源版 |
|
||||
| ReassignmentBytesOut | byte/s | Broker 的每秒数据迁移流出量 | 全部版本 | 开源版 |
|
||||
| Partitions | 个 | Broker 上的 Partition 个数 | 全部版本 | 开源版 |
|
||||
| PartitionsSkew | % | Broker 上的 Partitions 倾斜度 | 全部版本 | 开源版 |
|
||||
| Leaders | 个 | Broker 上的 Leaders 个数 | 全部版本 | 开源版 |
|
||||
| LeadersSkew | % | Broker 上的 Leaders 倾斜度 | 全部版本 | 开源版 |
|
||||
| LogSize | byte | Broker 上的消息容量大小 | 全部版本 | 开源版 |
|
||||
| Alive | 是/否 | Broker 是否存活，1：存活；0：没有存活 | 全部版本 | 开源版 |
|
||||
|
||||
### 3.3.3、Topic 指标
|
||||
|
||||
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
|
||||
| --------------------- | -------- | ------------------------------------- | ---------- | --------------- |
|
||||
| HealthScore | 分 | 健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed | 个 | 健康项检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal | 个 | 健康项检查总数 | 全部版本 | 开源版 |
|
||||
| TotalProduceRequests | 条/s | Topic 的 TotalProduceRequests | 全部版本 | 开源版 |
|
||||
| BytesRejected | 个/s | Topic 的每秒写入拒绝量 | 全部版本 | 开源版 |
|
||||
| FailedFetchRequests | 个/s | Topic 的 FailedFetchRequests | 全部版本 | 开源版 |
|
||||
| FailedProduceRequests | 个/s | Topic 的 FailedProduceRequests | 全部版本 | 开源版 |
|
||||
| ReplicationCount | 个 | Topic 总的副本数 | 全部版本 | 开源版 |
|
||||
| Messages | 条 | Topic 总的消息数 | 全部版本 | 开源版 |
|
||||
| MessagesIn | 条/s | Topic 每秒消息条数 | 全部版本 | 开源版 |
|
||||
| BytesIn | byte/s | Topic 每秒消息写入字节数 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_5 | byte/s | Topic 每秒消息写入字节数，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesIn_min_15 | byte/s | Topic 每秒消息写入字节数，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut | byte/s | Topic 每秒消息流出字节数 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_5 | byte/s | Topic 每秒消息流出字节数，5 分钟均值 | 全部版本 | 开源版 |
|
||||
| BytesOut_min_15 | byte/s | Topic 每秒消息流出字节数，15 分钟均值 | 全部版本 | 开源版 |
|
||||
| LogSize | byte | Topic 的大小 | 全部版本 | 开源版 |
|
||||
| PartitionURP | 个 | Topic 未同步的副本数 | 全部版本 | 开源版 |
|
||||
|
||||
### 3.3.4、Partition 指标
|
||||
|
||||
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
|
||||
| -------------- | -------- | ----------------------------------------- | ---------- | --------------- |
|
||||
| LogEndOffset | 条 | Partition 中 leader 副本的 LogEndOffset | 全部版本 | 开源版 |
|
||||
| LogStartOffset | 条 | Partition 中 leader 副本的 LogStartOffset | 全部版本 | 开源版 |
|
||||
| Messages | 条 | Partition 总的消息数 | 全部版本 | 开源版 |
|
||||
| BytesIn | byte/s | Partition 的每秒消息流入字节数 | 全部版本 | 开源版 |
|
||||
| BytesOut | byte/s | Partition 的每秒消息流出字节数 | 全部版本 | 开源版 |
|
||||
| LogSize | byte | Partition 的大小 | 全部版本 | 开源版 |
|
||||
|
||||
### 3.3.5、Group 指标
|
||||
|
||||
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
|
||||
| ----------------- | -------- | -------------------------- | ---------- | --------------- |
|
||||
| HealthScore | 分 | 健康分 | 全部版本 | 开源版 |
|
||||
| HealthCheckPassed | 个 | 健康检查通过数 | 全部版本 | 开源版 |
|
||||
| HealthCheckTotal | 个 | 健康检查总数 | 全部版本 | 开源版 |
|
||||
| OffsetConsumed | 条 | Consumer 的 CommitedOffset | 全部版本 | 开源版 |
|
||||
| LogEndOffset | 条 | Consumer 的 LogEndOffset | 全部版本 | 开源版 |
|
||||
| Lag | 条 | Group 消费者的 Lag 数 | 全部版本 | 开源版 |
|
||||
| State | 个 | Group 组的状态 | 全部版本 | 开源版 |
|
||||
50
product/4-unique-feature.md
Normal file
50
product/4-unique-feature.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
order: 4
|
||||
title: '4.特色能力'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 4.1、集群诊断(敬请期待)
|
||||
|
||||
## 4.2、Kafka 多版本兼容方案
|
||||
|
||||
  当前 KnowStreaming 支持纳管多个版本的 kafka 集群，由于不同版本的 kafka 在指标采集、接口查询、行为操作上有些不一致，因此 KnowStreaming 需要一套机制来解决多 kafka 版本的纳管兼容性问题。
|
||||
|
||||
### 4.2.1、整体思路
|
||||
|
||||
  由于需要纳管多个 kafka 版本，而且未来还可能会纳管非 kafka 官方的版本，kafka 的版本号会存在着多种情况，所以首先要明确一个核心思想：KnowStreaming 提供尽可能多的纳管能力，但是不提供无限的纳管能力，每一个版本的 KnowStreaming 只纳管其自身声明的 kafka 版本，后续随着 KnowStreaming 自身版本的迭代，会逐步支持更多 kafka 版本的纳管接入。
|
||||
|
||||
### 4.2.2、构建版本兼容列表
|
||||
|
||||
  每一个版本的 KnowStreaming 都声明一个自身支持纳管的 kafka 版本列表，并且对 kafka 的版本号进行归一化处理，后续所有 KnowStreaming 对不同 kafka 集群的操作都和这个集群对应的版本号严格相关。
|
||||
|
||||
  KnowStreaming 对外提供自身所支持的 kafka 版本兼容列表，用以声明自身支持的版本范围。
|
||||
|
||||
  对于在集群接入过程中，如果希望接入当前 KnowStreaming 不支持的 kafka 版本的集群，KnowStreaming 建议在于的过程中选择相近的版本号接入。
|
||||
|
||||
### 4.2.3、构建版本兼容性字典
|
||||
|
||||
  在构建了 KnowStreaming 支持的 kafka 版本列表的基础上，KnowStreaming 在实现过程中，还会声明自身支持的所有兼容性，构建兼容性字典。
|
||||
|
||||
  当前 KnowStreaming 支持的 kafka 版本兼容性字典包括三个维度：
|
||||
|
||||
- 指标采集：同一个指标在不同 kafka 版本下可能获取的方式不一样，不同版本的 kafka 可能会有不同的指标，因此对于指标采集的处理需要构建兼容性字典。
|
||||
- kafka api：同一个 kafka 的操作处理的方式在不同 kafka 版本下可能存在不一致，如：topic 的创建，因此 KnowStreaming 针对不同 kafka-api 的处理需要构建兼容性字典。
|
||||
- 平台操作：KnowStreaming 在接入不同版本的 kafka 集群的时候，在平台页面上会根据不同的 kafka 版。
|
||||
|
||||
兼容性字典的核心设计字段如下：
|
||||
|
||||
| 兼容性维度 | 兼容项名称 | 最小 Kafka 版本号（归一化） | 最大 Kafka 版本号（归一化） | 处理器 |
|
||||
| ---------- | ---------- | --------------------------- | --------------------------- | ------ |
|
||||
|
||||
KS-KM 根据其需要纳管的 kafka 版本，按照上述三个维度构建了完善了兼容性字典。
|
||||
|
||||
### 4.2.4、兼容性问题
|
||||
|
||||
  KS-KM 的每个版本针对需要纳管的 kafka 版本列表，事先分析各个版本的差异性和产品需求，同时 KS-KM 构建了一套专门处理兼容性的服务，来进行兼容性的注册、字典构建、处理器分发等操作，其中版本兼容性处理器是来具体处理不同 kafka 版本差异性的地方。
|
||||
|
||||
|
||||
|
||||
  如上图所示，KS-KM 的 topic 服务在面对不同 kafka 版本时，其 topic 的创建、删除、扩容由于 kafka 版本自身的差异，导致 KnowStreaming 的处理也不一样，所以需要根据不同的 kafka 版本来实现不同的兼容性处理器，同时向 KnowStreaming 的兼容服务进行兼容性的注册，构建兼容性字典，后续在 KnowStreaming 的运行过程中，针对不同的 kafka 版本即可分发到不同的处理器中执行。
|
||||
|
||||
  后续随着 KnowStreaming 产品的发展，如果有新的兼容性的地方需要增加，只需要实现新版本的处理器，增加注册项即可。
|
||||
884
product/5-user-doc.md
Normal file
884
product/5-user-doc.md
Normal file
@@ -0,0 +1,884 @@
|
||||
---
|
||||
order: 5
|
||||
title: '5.用户手册'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 5.1、功能架构
|
||||
|
||||
|
||||
|
||||
## 5.2、体验路径
|
||||
|
||||
下面是用户第一次使用我们产品的典型体验路径：
|
||||
|
||||
|
||||
|
||||
## 5.3、常用功能
|
||||
|
||||
### 5.3.1、用户管理
|
||||
|
||||
用户管理是提供给管理员进行人员管理和用户角色管理的功能模块，可以进行新增用户和分配角色。下面是一个典型的场景：
|
||||
eg：团队加入了新成员，需要给这位成员分配一个使用系统的账号，需要以下几个步骤
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“人员管理”>“新增用户”，输入“账号”、“实名”、“密码”，根据此账号所需要的权限，选择此账号所对应的角色。如果有满足权限的角色，则用户新增成功。如果没有满足权限的角色，则需要新增角色（步骤 2）
|
||||
- 步骤 2:点击“系统管理”>“用户管理”>“角色管理”>“新增角色”。输入角色名称和描述，给此角色分配权限，点击“确定”，角色新增成功
|
||||
|
||||
- 步骤 3:根据此新增的角色，参考步骤 1，重新新增用户
|
||||
|
||||
- 步骤 4:此用户账号新增成功，可以进行登录产品使用
|
||||
|
||||
|
||||
|
||||
### 5.3.2、接入集群
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“接入集群”
|
||||
|
||||
- 步骤 2:填写相关集群信息
|
||||
|
||||
- 集群名称：支持中英文、下划线、短划线（-），最长 128 字符。平台内不能重复
|
||||
- Bootstrap Servers：输入 Bootstrap Servers 地址。输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）。
|
||||
- Zookeeper：输入 zookeeper 地址，输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）
|
||||
- Metrics 选填：JMX Port，输入 JMX 端口号；MaxConn，输入服务端最大允许的连接数
|
||||
- Security：若有 JMX 账号密码，则输入账号密码
|
||||
- Version：选择所支持的 kafka 版本，如果没有匹配则可以选择相近版本
|
||||
- 集群配置选填：输入用户创建 kafka 客户端进行信息获取的相关配置
|
||||
- 集群描述：最多 200 字符
|
||||
|
||||
|
||||
|
||||
### 5.3.3、新增 Topic
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“新增 Topic”按钮>“创建 Topic“抽屉
|
||||
|
||||
- 步骤 2:输入“Topic 名称（不能重复）”、“Topic 描述”、“分区数”、“副本数”、“数据保存时间”、“清理策略（删除或压缩）”
|
||||
|
||||
- 步骤 3:展开“更多配置”可以打开高级配置选项，根据自己需要输入相应配置参数
|
||||
|
||||
- 步骤 4:点击“确定”，创建 Topic 完成
|
||||
|
||||
|
||||
|
||||
### 5.3.4、Topic 扩分区
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“Topic 列表“>操作项”扩分区“>“扩分区”抽屉
|
||||
|
||||
- 步骤 2:扩分区抽屉展示内容为“流量的趋势图”、“当前分区数及支持的最低消息写入速率”、“扩分区后支持的最低消息写入速率”
|
||||
|
||||
- 步骤 3:输入所需的分区总数，自动计算出扩分区后支持的最低消息写入速率
|
||||
|
||||
- 步骤 4:点击确定，扩分区完成
|
||||
|
||||
|
||||
|
||||
### 5.3.5、Topic 批量扩缩副本
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量扩缩副本“>“批量扩缩容”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行扩缩容的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:Topic 列表展示 Topic“近三天平均流量”、“近三天峰值流量及时间”、“Partition 数”、”当前副本数“、“新副本数”
|
||||
|
||||
- 步骤 4:扩容时，选择目标节点，新增的副本会在选择的目标节点上；缩容时不需要选择目标节点，自动删除最后一个（或几个）副本
|
||||
|
||||
- 步骤 5:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 6:输入任务描述
|
||||
|
||||
- 步骤 7:点击“确定”，创建 Topic 扩缩副本任务
|
||||
|
||||
- 步骤 8:去“Job”模块的 Job 列表查看创建的任务，如果已经执行则可以查看执行进度；如果未开始执行则可以编辑任务
|
||||
|
||||
|
||||
|
||||
### 5.3.6、Topic 批量迁移
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量迁移“>“批量迁移”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行迁移的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:选择所需要迁移的 partition 和迁移数据的时间范围
|
||||
|
||||
- 步骤 4:选择目标节点（节点数必须不小于最大副本数）
|
||||
|
||||
- 步骤 5:点击“预览任务计划”，打开“任务计划”二次抽屉，可对目标 Broker ID 进行编辑
|
||||
|
||||
- 步骤 6:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 7:输入任务描述
|
||||
|
||||
- 步骤 8:点击“确定”，创建 Topic 迁移任务
|
||||
|
||||
- 步骤 9:去“Job”模块的 Job 列表查看创建的任务，如果已经执行则可以查看执行进度；如果未开始执行则可以编辑任务
|
||||
|
||||
|
||||
|
||||
### 5.3.7、设置 Cluster 健康检查规则
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“集群健康状态旁边 icon”>“健康度设置抽屉”
|
||||
|
||||
- 步骤 2:健康度设置抽屉展示出了检查项和其对应的权重，可以修改检查项的检查规则
|
||||
|
||||
- 步骤 3:检查规则可配置，分别为
|
||||
|
||||
- Cluster：集群 controller 数不等于 1（数字不可配置）不通过
|
||||
- Broker：RequestQueueSize 大于等于 10（默认为 10，可配置数字）不通过
|
||||
- Broker：NetworkProcessorAvgIdlePercent 的 Idle 小于等于 0.8%（默认为 0.8%，可配置数字）不通过
|
||||
- Topic：无 leader 的 Topic 数量，大于等于 1（默认为 1，数字可配置）不通过
|
||||
- Topic：Topic 在 10（默认为 10，数字可配置）个周期内 8（默认为 8，数字可配置）个周期内处于未同步的状态则不通过
|
||||
- ConsumerGroup：Group 在 10（默认为 10，数字可配置）个周期内进行 8（默认为 8，数字可配置）次 re-balance 不通过
|
||||
|
||||
- 步骤 4:设置完成后，点击“确认”，健康检查规则设置成功
|
||||
|
||||
|
||||
|
||||
### 5.3.8、图表指标筛选
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“指标筛选 icon”>“指标筛选抽屉”
|
||||
|
||||
- 步骤 2:指标筛选抽屉展示信息为以下几类“Health”、“Cluster”、“Broker”、“Consumer”、“Security”、“Job”
|
||||
|
||||
- 步骤 3:默认勾选比较重要的指标进行展示。根据需要选中/取消选中相应指标，点击”确认“，指标筛选成功，展示的图表随之变化
|
||||
|
||||
|
||||
|
||||
### 5.3.9、编辑 Broker 配置
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Brokers”>“Broker ID”>“Configuration”TAB>“编辑”按钮
|
||||
|
||||
- 步骤 2:输入配置项的新配置内容
|
||||
|
||||
- 步骤 3:（选填）点击“应用于全部 Broker”，将此配置项的修改应用于全部的 Broker
|
||||
|
||||
- 步骤 4:点击“确认”，Broker 配置修改成功
|
||||
|
||||
|
||||
|
||||
### 5.3.10、重置 consumer Offset
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Consumer”>“Consumer Group”名称>“Consumer Group 详情”抽屉>“重置 Offset”按钮>“重置 Offset”抽屉
|
||||
|
||||
- 步骤 2:选择重置 Offset 的类型，可“重置到指定时间”或“重置分区”
|
||||
|
||||
- 步骤 3:重置到指定时间，可选择“最新 Offset”或“自定义时间”
|
||||
|
||||
- 步骤 4:重置分区，可选择 partition 和其重置的 offset
|
||||
|
||||
- 步骤 5:点击“确认”，重置 Offset 开始执行
|
||||
|
||||
|
||||
|
||||
### 5.3.11、新增 ACL
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“Users”>“新增 ACL”
|
||||
|
||||
- 步骤 2:输入 ACL 配置参数
|
||||
|
||||
- ACL 用途：生产权限、消费权限、自定义权限
|
||||
- 生产权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic
|
||||
- 消费权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic；可选择应用于所有 Consumer Group 或者特定 Consumer Group
|
||||
|
||||
- 步骤 3:点击“确定”，新增 ACL 成功
|
||||
|
||||
|
||||
|
||||
## 5.4、全部功能
|
||||
|
||||
### 5.4.1、登录/退出登录
|
||||
|
||||
- 登录：输入账号密码，点击登录
|
||||
|
||||
- 退出登录：鼠标悬停右上角“头像”或者“用户名”，出现小弹窗“登出”，点击“登出”，退出登录
|
||||
|
||||
### 5.4.2、系统管理
|
||||
|
||||
用户登录完成之后，点击页面右上角【系统管理】按钮，切换到系统管理的视角，可以进行配置管理、用户管理、审计日志查看。
|
||||
|
||||
|
||||
#### 5.4.2.1、配置管理
|
||||
|
||||
配置管理是提供给管理员一个快速配置配置文件的能力，所配置的配置文件将会在对应模块生效。
|
||||
|
||||
#### 5.4.2.2、查看配置列表
|
||||
|
||||
- 步骤 1:点击”系统管理“>“配置管理”
|
||||
|
||||
- 步骤 2:列表展示配置所属模块、配置键、配置值、启用状态、更新时间、更新人。列表有操作项编辑、删除，可对配置模块、配置键、配置值、描述、启用状态进行配置，也可删除此条配置
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.3、新增配置
|
||||
|
||||
- 步骤 1:点击“系统管理”>“配置管理”>“新增配置”
|
||||
|
||||
- 步骤 2：模块：下拉选择所有可配置的模块；配置键：不限制输入内容，500 字以内；配置值：代码编辑器样式，不限内容不限长度；启用状态开关：可以启用/禁用此项配置
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.4、编辑配置
|
||||
|
||||
可对配置模块、配置键、配置值、描述、启用状态进行配置。
|
||||
|
||||
#### 5.4.2.5、用户管理
|
||||
|
||||
用户管理是提供给管理员进行人员管理和用户角色管理的功能模块，可以进行新增用户和分配角色。
|
||||
|
||||
#### 5.4.2.6、人员管理列表
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“人员管理”
|
||||
|
||||
- 步骤 2:人员管理列表展示用户角色、用户实名、用户分配的角色、更新时间、编辑操作。
|
||||
|
||||
- 步骤 3:列表支持”用户账号“、“用户实名”、“角色名”筛选。
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.7、新增用户
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“人员管理”>“新增用户”
|
||||
|
||||
- 步骤 2:填写“用户账号”、“用户实名”、“用户密码”这些必填参数，可以对此账号分配已经存在的角色。
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.8、编辑用户
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“人员管理”>列表操作项“编辑”
|
||||
|
||||
- 步骤 2:用户账号不可编辑；可以编辑“用户实名”，修改“用户密码”，重新分配“用户角色“
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.9、角色管理列表
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“角色管理”
|
||||
|
||||
- 步骤 2:角色列表展示信息为“角色 ID”、“名称”、“描述”、“分配用户数”、“最后修改人”、“最后更新时间”、操作项“查看详情”、操作项”分配用户“
|
||||
|
||||
- 步骤 3:列表有筛选框，可对“角色名称”进行筛选
|
||||
|
||||
- 步骤 4:列表操作项，“查看详情”可查看到角色绑定的权限项，”分配用户“可对此项角色下绑定的用户进行增减
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.10、新增角色
|
||||
|
||||
- 步骤 1:点击“系统管理”>“用户管理”>“角色管理”>“新增角色”
|
||||
|
||||
- 步骤 2:输入“角色名称”（角色名称只能由中英文大小写、数字、下划线\_组成，长度限制在 3 ～ 128 字符）、“角色描述“（不能为空）、“分配权限“（至少需要分配一项权限），点击确认，新增角色成功添加到角色列表
|
||||
|
||||
|
||||
|
||||
#### 5.4.2.11、审计日志
|
||||
|
||||
- 步骤 1:点击“系统管理”>“审计日志“
|
||||
- 步骤 2:审计日志包含所有对于系统的操作记录，操作记录列表展示信息为下
|
||||
|
||||
- “模块”：操作对象所属的功能模块
|
||||
- “操作对象”：具体哪一个集群、任务 ID、topic、broker、角色等
|
||||
- “行为”：操作记录的行为，包含“新增”、“替换”、“读取”、“禁用”、“修改”、“删除”、“编辑”等
|
||||
- “操作内容”：具体操作的内容是什么
|
||||
- “操作时间”：操作发生的时间
|
||||
- “操作人”：此项操作所属的用户
|
||||
|
||||
- 步骤 3:操作记录列表可以对“模块“、”操作对象“、“操作内容”、”操作时间“进行筛选
|
||||
|
||||
|
||||
|
||||
### 5.4.3、多集群管理
|
||||
|
||||
#### 5.4.3.1、多集群列表
|
||||
|
||||
- 步骤 1:点击顶部导航栏“多集群管理”
|
||||
|
||||
- 步骤 2:多集群管理页面包含的信息为：”集群信息总览“、“集群列表”、“列表筛选项”、“接入集群”
|
||||
|
||||
- 步骤 3:集群列表筛选项为
|
||||
|
||||
- 集群信息总览：cluster 总数、live 数、down 数
|
||||
- 版本筛选：包含所有存在的集群版本
|
||||
- 健康分筛选：筛选项为 0、10、20、30、40、50、60、70、80、90、100
|
||||
- live、down 筛选：多选
|
||||
- 下拉框筛选排序，选项维度为“接入时间”、“健康分“、”Messages“、”MessageSize“、”BytesIn“、”BytesOut“、”Brokers“；可对这些维度进行“升序”、“降序”排序
|
||||
|
||||
- 步骤 4:每个卡片代表一个集群，其所展示的集群概览信息包括“健康分及健康检查项通过数”、“broker 数量”、“ZK 数量”、“版本号”、“BytesIn 均衡状态”、“BytesOut 均衡状态”、“Disk 均衡状态”、”Messages“、“MessageSize”、“BytesIn”、“BytesOut”、“接入时间”
|
||||
|
||||
|
||||
|
||||
#### 5.4.3.2、接入集群
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“接入集群”
|
||||
|
||||
- 步骤 2:填写相关集群信息
|
||||
- 集群名称：平台内不能重复
|
||||
- Bootstrap Servers：输入 Bootstrap Servers 地址，输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）。
|
||||
- Zookeeper：输入 zookeeper 地址，输入完成之后会进行连接测试，测试完成之后会给出测试结果连接成功 or 连接失败（以及失败的原因）
|
||||
- Metrics 选填：JMX Port，输入 JMX 端口号；MaxConn，输入服务端最大允许的连接数
|
||||
- Security：若有 JMX 账号密码，则输入账号密码
|
||||
- Version：kafka 版本，如果没有匹配则可以选择相近版本
|
||||
- 集群配置选填：用户创建 kafka 客户端进行信息获取的相关配置
|
||||
|
||||
|
||||
|
||||
#### 5.4.3.3、删除集群
|
||||
|
||||
- 步骤 1:点击“多集群管理”>鼠标悬浮集群卡片>点击卡片右上角“删除 icon”>打开“删除弹窗”
|
||||
|
||||
- 步骤 2:在删除弹窗中的“集群名称”输入框，输入所要删除集群的集群名称，点击“删除”，成功删除集群，解除平台的纳管关系（集群资源不会删除）
|
||||
|
||||
|
||||
|
||||
### 5.4.4、Cluster 管理
|
||||
|
||||
#### 5.4.4.1、Cluster Overview
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>进入单集群管理界面
|
||||
|
||||
- 步骤 2:左侧导航栏
|
||||
|
||||
- 一级导航：Cluster；二级导航：Overview、Load Rebalance
|
||||
- 一级导航：Broker；二级导航：Overview、Brokers、Controller
|
||||
- 一级导航：Topic；二级导航：Overview、Topics
|
||||
- 一级导航：Consumer
|
||||
- 一级导航：Testing；二级导航：Produce、Consume
|
||||
- 一级导航：Security；二级导航：ACLs、Users
|
||||
- 一级导航：Job
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.2、查看 Cluster 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”
|
||||
|
||||
- 步骤 2:cluster 概览信息包括以下内容
|
||||
|
||||
- 集群健康分，健康检查通过项
|
||||
- Cluster 信息：包含名称、版本、均衡状态
|
||||
- Broker 信息：Broker 总数、controller 信息、similar config 信息
|
||||
- Topic 信息：Topic 总数、No Leader、<Min ISR、URP
|
||||
- Consumer Group 信息：Consumer Group 总数、是否存在 Dead 情况
|
||||
- 指标图表
|
||||
- 历史变更记录：名称、时间、内容、类型
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.3、设置 Cluster 健康检查规则
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“集群健康状态旁边 icon”>“健康度设置抽屉”
|
||||
|
||||
- 步骤 2:健康度设置抽屉展示出了检查项和其对应的权重，可以修改检查项的检查规则
|
||||
|
||||
- 步骤 3:检查规则可配置，分别为
|
||||
|
||||
- Cluster：集群 controller 数不等于 1（数字不可配置）不通过
|
||||
- Broker：RequestQueueSize 大于等于 10（默认为 10，可配置数字）不通过
|
||||
- Broker：NetworkProcessorAvgIdlePercent 的 Idle 小于等于 0.8%（默认为 0.8%，可配置数字）不通过
|
||||
- Topic：无 leader 的 Topic 数量，大于等于 1（默认为 1，数字可配置）不通过
|
||||
- Topic：Topic 在 10（默认为 10，数字可配置）个周期内 8（默认为 8，数字可配置）个周期内处于未同步的状态
|
||||
- ConsumerGroup：Group 在 10（默认为 10，数字可配置）个周期内进行 8（默认为 8，数字可配置）次 re-balance 不通过
|
||||
|
||||
- 步骤 4:设置完成后，点击“确认”，健康检查规则设置成功
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.4、查看 Cluster 健康检查详情
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“集群健康状态旁边【查看详情】”>“健康检查详情抽屉”
|
||||
|
||||
- 步骤 2:健康检查详情抽屉展示信息为：“检查模块”、“检查项”、“权重”、“得分”、“检查时间”、“检查结果是否通过”，若未通过会展示未通过的对象
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.5、编辑 Cluster 信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“Cluster 名称旁边编辑 icon”>“编辑集群抽屉”
|
||||
|
||||
- 步骤 2:可编辑的信息包括“集群名称”、“Bootstrap Servers”、“Zookeeper”、“JMX Port”、“Maxconn（最大连接数）”、“Security（认证措施）”、“Version（版本号）”、“集群配置”、“集群描述”
|
||||
|
||||
- 步骤 3:点击“确定”，成功编辑集群信息
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.6、图表指标筛选
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“指标筛选 icon”>“指标筛选抽屉”
|
||||
|
||||
- 步骤 2:指标筛选抽屉展示信息为以下几类“Health”、“Cluster”、“Broker”、“Consumer”、“Security”、“Job”
|
||||
|
||||
- 步骤 3:默认勾选比较重要的指标进行展示。根据需要选中/取消选中相应指标，点击”确认“，指标筛选成功，展示的图表随之变化
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.7、图表时间筛选
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“时间选择下拉框”>“时间选择弹窗”
|
||||
|
||||
- 步骤 2:选择时间“最近 15 分钟”、“最近 1 小时”、“最近 6 小时”、“最近 12 小时”、“最近 1 天”，也可以自定义时间段范围
|
||||
|
||||
|
||||
|
||||
#### 5.4.4.8、查看集群历史变更记录
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Overview”>“历史变更记录”区域
|
||||
|
||||
- 步骤 2:历史变更记录区域展示了历史的配置变更，每条记录可展开收起。包含“配置对象”、“变更时间”、“变更内容”、“配置类型”
|
||||
|
||||
|
||||
|
||||
### 5.4.5、Load Rebalance（企业版）
|
||||
|
||||
#### 5.4.5.1、查看 Load Rebalance 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Load Rebalance”
|
||||
|
||||
- 步骤 2:Load Rebalance 概览信息包含“均衡状态卡片”、“Disk 信息卡片”、“BytesIn 信息卡片”、“BytesOut 信息卡片”、“Broker 均衡状态列表”
|
||||
|
||||
|
||||
|
||||
#### 5.4.5.2、设置集群规格
|
||||
|
||||
提供对集群的每个节点的 Disk、BytesIn、BytesOut 的规格进行设置的功能
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Load Rebalance”>“State 卡片 icon“>”设置集群规格抽屉“
|
||||
|
||||
- 步骤 2:穿梭框左侧展示集群中的待选节点，穿梭框右侧展示已经选中的节点，选择自己所需设置规格的节点
|
||||
|
||||
- 步骤 3:设置“单机核数”、“单机磁盘”、“单机网络”，点击确定，完成设置
|
||||
|
||||
|
||||
|
||||
#### 5.4.5.3、均衡状态列表筛选
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Load Rebalance”>“筛选列表”按钮>筛选弹窗
|
||||
|
||||
- 步骤 2:可选择“Disk”、“BytesIn”、“BytesOut”三种维度，其各自对应“已均衡”、“未均衡”两种状态，可以组合进行筛选
|
||||
|
||||
- 步骤 3:点击“确认”，执行筛选操作
|
||||
|
||||
|
||||
|
||||
#### 5.4.5.4、立即均衡
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Load Rebalance”>“立即均衡”按钮>“立即均衡抽屉”
|
||||
|
||||
- 步骤 2:配置均衡策略
|
||||
|
||||
- 指标计算周期：默认近 10mins，可选择
|
||||
- 均衡维度：默认 Disk、BytesIn、BytesOut，可选择
|
||||
- 均衡区间：在表格内自定义配置均衡区间范围（单位：%，大于 0，小于 100）
|
||||
- Topic 黑名单：选择 topic 黑名单。通过穿梭框（支持模糊选择）选出目标 topic（本次均衡，略过已选的 topic）
|
||||
|
||||
- 步骤 3:配置运行参数
|
||||
|
||||
- 吞吐量优先：并行度 0（无限制）， 策略是优先执行大小最大副本
|
||||
- 稳定性优先： 并行度 1 ，策略是优先执行大小最小副本
|
||||
- 自定义：可以自由设置并行度和优先执行的副本策略
|
||||
- 限流值：流量最大值，0-99999 自定义
|
||||
|
||||
- 步骤 4:点击“预览计划”按钮，打开执行计划弹窗。可以看到计划概览信息、计划明细信息
|
||||
|
||||
- 步骤 5:点击“预览计划弹窗”的“执行文件”，可以下载 json 格式的执行文件
|
||||
|
||||
- 步骤 6:点击“预览计划弹窗”的“立即均衡”按钮，开始执行均衡任务
|
||||
|
||||
|
||||
|
||||
#### 5.4.5.5、周期均衡
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Cluster”>“Load Rebalance”>“周期均衡”按钮>“周期均衡抽屉”
|
||||
|
||||
- 步骤 2:配置均衡策略
|
||||
|
||||
- 指标计算周期：默认近 10mins，可选择
|
||||
- 均衡维度：默认 Disk、BytesIn、BytesOut，可选择
|
||||
- 均衡区间：在表格内自定义配置均衡区间范围（单位：%，大于 0，小于 100）
|
||||
- Topic 黑名单：选择 topic 黑名单。通过穿梭框（支持模糊选择）选出目标 topic（本次均衡，略过已选的 topic）
|
||||
|
||||
- 步骤 3:配置运行参数
|
||||
|
||||
- 任务并行度：每个节点同时迁移的副本数量
|
||||
- 任务周期：时间选择器，自定义选择运行周期
|
||||
- 稳定性优先： 并行度 1 ，策略是优先执行大小最小副本
|
||||
- 自定义：可以自由设置并行度和优先执行的副本策略
|
||||
- 限流值：流量最大值，0-99999 自定义
|
||||
|
||||
- 步骤 4:点击“预览计划”按钮，打开执行计划弹窗。可以看到计划概览信息、计划明细信息
|
||||
|
||||
- 步骤 5:点击“预览计划弹窗”的“执行文件”，可以下载 json 格式的执行文件
|
||||
|
||||
- 步骤 6:点击“预览计划弹窗”的“立即均衡”按钮，开始执行均衡任务
|
||||
|
||||
|
||||
|
||||
### 5.4.6、Broker
|
||||
|
||||
#### 5.4.6.1、查看 Broker 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Broker”>“Overview”
|
||||
|
||||
- 步骤 2:Broker 概览信息包括以下内容
|
||||
|
||||
- 集群健康分，健康检查通过项
|
||||
- Broker 信息：包含名称、版本、均衡状态
|
||||
- Broker 信息：Broker 总数、controller 信息、similar config 信息
|
||||
- Topic 信息：Topic 总数、No Leader、<Min ISR、URP
|
||||
- Consumer Group 信息：Consumer Group 总数、是否存在 Dead 情况
|
||||
- 指标图表
|
||||
- 历史变更记录：名称、时间、内容、类型
|
||||
|
||||
|
||||
|
||||
#### 5.4.6.2、编辑 Broker 配置
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Brokers”>“Broker ID”>“Configuration”TAB>“编辑”按钮
|
||||
|
||||
- 步骤 2:输入配置项的新配置内容
|
||||
|
||||
- 步骤 3:（选填）点击“应用于全部 Broker”，将此配置项的修改应用于全部的 Broker
|
||||
|
||||
- 步骤 4:点击“确认”，Broker 配置修改成功
|
||||
|
||||
|
||||
|
||||
#### 5.4.6.3、查看 Broker DataLogs
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Brokers”>“Broker ID”>“Data Logs”TAB>“编辑”按钮
|
||||
|
||||
- 步骤 2:Broker DataLogs 列表展示的信息为“Folder”、“topic”、“Partition”、“Offset Lag”、“Size”
|
||||
|
||||
- 步骤 3:输入框输入”Topic Name“可以筛选结果
|
||||
|
||||
|
||||
|
||||
#### 5.4.6.4、查看 Controller 列表
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Broker”>“Controller”
|
||||
|
||||
- 步骤 2:Controller 列表展示的信息为“Change Time”、“Broker ID”、“Broker Host”
|
||||
|
||||
- 步骤 3:输入框输入“Broker Host“可以筛选结果
|
||||
|
||||
- 步骤 4:点击 Broker ID 可以打开 Broker 详情，进行修改配置或者查看 DataLogs
|
||||
|
||||
|
||||
|
||||
### 5.4.7、Topic
|
||||
|
||||
#### 5.4.7.1、查看 Topic 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Overview”
|
||||
|
||||
- 步骤 2:Topic 概览信息包括以下内容
|
||||
|
||||
- 集群健康分，健康检查通过项
|
||||
- Topics：Topic 总数
|
||||
- Partitions：Partition 总数
|
||||
- PartitionNoLeader：没有 leader 的 partition 个数
|
||||
- < Min ISR：同步副本数小于 Min ISR
|
||||
- =Min ISR：同步副本数等于 Min ISR
|
||||
- Topic 指标图表
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.2、查看 Topic 健康检查详情
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Overview”>“集群健康状态旁边【查看详情】”>“健康检查详情抽屉”
|
||||
|
||||
- 步骤 2:健康检查详情抽屉展示信息为：“检查项”、“权重”、“得分”、“检查时间”、“检查结果是否通过”，若未通过会展示未通过的对象
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.3、查看 Topic 列表
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”
|
||||
|
||||
- 步骤 2:Topic 列表展示内容为“TopicName”、“Partitions”、“Replications”、“健康分”、“BytesIn”、“BytesOut”、“MessageSize”、“保存时间”、“描述”、操作项”扩分区“、操作项”删除“
|
||||
|
||||
- 步骤 3:筛选框输入“TopicName”可以对列表进行筛选；点击“展示系统 Topic”开关，可以筛选系统 topic
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.4、新增 Topic
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“新增 Topic”按钮>“创建 Topic“抽屉
|
||||
|
||||
- 步骤 2:输入“Topic 名称（不能重复）”、“Topic 描述”、“分区数”、“副本数”、“数据保存时间”、“清理策略（删除或压缩）”
|
||||
|
||||
- 步骤 3:展开“更多配置”可以打开高级配置选项，根据自己需要输入相应配置参数
|
||||
|
||||
- 步骤 4:点击“确定”，创建 Topic 完成
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.5、Topic 扩分区
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“Topic 列表“>操作项”扩分区“>“扩分区”抽屉
|
||||
|
||||
- 步骤 2:扩分区抽屉展示内容为“流量的趋势图”、“当前分区数及支持的最低消息写入速率”、“扩分区后支持的最低消息写入速率”
|
||||
|
||||
- 步骤 3:输入所需的分区总数，自动计算出扩分区后支持的最低消息写入速率
|
||||
|
||||
- 步骤 4:点击确定，扩分区完成
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.6、删除 Topic
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“Topic 列表“>操作项”删除“>“删除 Topic”弹窗
|
||||
|
||||
- 步骤 2:输入“TopicName”进行二次确认
|
||||
|
||||
- 步骤 3:点击“删除”，删除 Topic 完成
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.7、Topic 批量扩缩副本
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量扩缩副本“>“批量扩缩容”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行扩缩容的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:Topic 列表展示 Topic“近三天平均流量”、“近三天峰值流量及时间”、“Partition 数”、”当前副本数“、“新副本数”
|
||||
|
||||
- 步骤 4:扩容时，选择目标节点，新增的副本会在选择的目标节点上；缩容时不需要选择目标节点，自动删除最后一个（或几个）副本
|
||||
|
||||
- 步骤 5:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 6:输入任务描述
|
||||
|
||||
- 步骤 7:点击“确定”，执行 Topic 扩缩容任务
|
||||
|
||||
|
||||
|
||||
#### 5.4.7.8、Topic 批量迁移
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Topic”>“Topics”>“批量操作下拉“>“批量迁移“>“批量迁移”抽屉
|
||||
|
||||
- 步骤 2:选择所需要进行迁移的 Topic，可多选，所选择的 Topic 出现在下方 Topic 列表中
|
||||
|
||||
- 步骤 3:选择所需要迁移的 partition 和迁移数据的时间范围
|
||||
|
||||
- 步骤 4:选择目标节点（节点数必须不小于最大副本数）
|
||||
|
||||
- 步骤 5:点击“预览任务计划”，打开“任务计划”二次抽屉，可对每个 partition 的目标 Broker ID 进行编辑，目标 broker 应该等于副本数
|
||||
|
||||
- 步骤 6:输入迁移任务配置参数，包含限流值和任务执行时间
|
||||
|
||||
- 步骤 7:输入任务描述
|
||||
|
||||
- 步骤 8:点击“确定”，执行 Topic 迁移任务
|
||||
|
||||
|
||||
|
||||
### 5.4.8、Consumer
|
||||
|
||||
#### 5.4.8.1、Consumer Overview
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Consumer”
|
||||
|
||||
- 步骤 2:Consumer 概览信息包括以下内容
|
||||
|
||||
- 集群健康分，健康检查通过项
|
||||
- Groups：Consumer Group 总数
|
||||
- GroupsActives：活跃的 Group 总数
|
||||
- GroupsEmptys：Empty 的 Group 总数
|
||||
- GroupRebalance：进行 Rebalance 的 Group 总数
|
||||
- GroupDeads：Dead 的 Group 总数
|
||||
- Consumer Group 列表
|
||||
|
||||
- 步骤 3:输入“Consumer Group”、“Topic Name‘，可对列表进行筛选
|
||||
|
||||
- 步骤 4:点击列表“Consumer Group”名称，可以查看 Comsuer Group 详情
|
||||
|
||||
|
||||
|
||||
#### 5.4.8.2、查看 Consumer 列表
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Consumer”>“Consumer Group”名称>“Consumer Group 详情”抽屉
|
||||
|
||||
- 步骤 2:Consumer Group 详情有列表视图和图表视图
|
||||
|
||||
- 步骤 3:列表视图展示信息为 Consumer 列表，包含”Topic Partition“、”Member ID“、”Current Offset“、“Log End Offset”、”Lag“、”Host“、”Client ID“
|
||||
|
||||
|
||||
|
||||
#### 5.4.8.3、重置 Offset
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Consumer”>“Consumer Group”名称>“Consumer Group 详情”抽屉>“重置 Offset”按钮>“重置 Offset”抽屉
|
||||
|
||||
- 步骤 2:选择重置 Offset 的类型，可“重置到指定时间”或“重置分区”
|
||||
|
||||
- 步骤 3:重置到指定时间，可选择“最新 Offset”或“自定义时间”
|
||||
|
||||
- 步骤 4:重置分区，可选择 partition 和其重置的 offset
|
||||
|
||||
- 步骤 5:点击“确认”，重置 Offset 开始执行
|
||||
|
||||
|
||||
|
||||
### 5.4.9、Kafka Connect
|
||||
|
||||
#### 5.4.9.1、Connect Overview
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Connect”
|
||||
|
||||
- 步骤 2:Connect 概览信息包括以下内容
|
||||
|
||||
- 集群健康状态，健康检查通过项
|
||||
- Connect 集群数：Connect 集群的数量
|
||||
- Workers：运行 Connector 任务的 Worker 的总数
|
||||
- Connectors：Connector 的运行数/总数
|
||||
- Tasks：Task 的运行数/总数
|
||||
|
||||
#### 5.4.9.2、查看 Connector 列表
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Connect”>“Connectors”
|
||||
|
||||
- 步骤 2: Connector 列表展示内容为“Connect 集群”、“Connector Name”、“State”、“Class”、“Type”、“Tasks”、“消息读取速率”、“消息写入速率”、“消息处理错误次数”、“Topics”、操作项”重启“、操作项”暂停“、操作项“编辑”、操作项“删除”
|
||||
|
||||
- 步骤 3:筛选框输入“Connector”可以对列表进行筛选；
|
||||
|
||||
|
||||
#### 5.4.9.3、新增 Connector
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“ Connect”>“ Connectors”>“新增 Connector”按钮>“创建 Connector“抽屉
|
||||
|
||||
- 步骤 2:选择“Connect 集群”、“Connector 插件”、
|
||||
|
||||
- 步骤 3:输出基础配置及高级配置
|
||||
|
||||
- 步骤 4:点击“Json 模式”，去 Json 模式继续补充配置
|
||||
- 步骤 5:点击“提交”，成功新增 Connector
|
||||
|
||||
|
||||
### 5.4.10、Testing（企业版）
|
||||
|
||||
#### 5.4.10.1、生产测试
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Testing”>“Produce”
|
||||
|
||||
- 步骤 2:生产配置
|
||||
|
||||
- Data：选择数据写入的 topic，输入写入数据的 key（暂只支持 string 格式），输入写入数据的 value（暂只支持 string 格式）。其中 key 和 value 可以随机生成
|
||||
- Flow：输入单次发送的消息数量，默认为 1，可以手动修改。选择手动生产模式，代表每次点击按钮【Run】执行生产；选择周期生产模式，需要填写运行总时间和运行时间间隔。
|
||||
- Header：输入 Header 的 key，value
|
||||
- Options：选择 Froce Partition，代表消息仅发送到这些选择的 Partition。选择数据压缩格式。选择 Acks 参数，none 意思是消息发送了就认为发送成功；leader 意思是 leader 接收到消息（不管 follower 有没有同步成功）认为消息发送成功；all 意思是所有的 follower 消息同步成功认为是消息发送成功
|
||||
|
||||
- 步骤 3:点击按钮【Run】，生产测试开始，可以从右侧看到生产测试的信息
|
||||
|
||||
|
||||
|
||||
#### 5.4.10.2、消费测试
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Testing”>“Consume”
|
||||
|
||||
- 步骤 2:消费配置
|
||||
|
||||
- Topic：选择数据从哪个 topic 进行消费
|
||||
- Start From：选择数据从什么地方开始消费，可以根据时间选择或者根据 Offset 进行选择
|
||||
- Until：选择消费截止到什么地方，可以根据时间或者 offset 或者消息数等进行选择
|
||||
- Filter：选择过滤器的规则。包含/不包含某【key，value】；等于/大于/小于多少条消息
|
||||
|
||||
- 步骤 3:点击按钮【Run】，消费测试开始，可以在右边看到消费的明细信息
|
||||
|
||||
|
||||
|
||||
### 5.4.11、Security
|
||||
|
||||
注意：只有在开启集群认证的情况下才能够使用 Security 功能
|
||||
|
||||
#### 5.4.11.1、查看 ACL 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“ACLs”
|
||||
|
||||
- 步骤 2:ACL 概览信息包括以下内容
|
||||
|
||||
- Enable：是否可用
|
||||
- ACLs：ACL 总数
|
||||
- Users：User 总数
|
||||
- Topics：Topic 总数
|
||||
- Consumer Groups：Consumer Group 总数
|
||||
- ACL 列表
|
||||
|
||||
|
||||
|
||||
#### 5.4.11.2、新增 ACl
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“Users”>“新增 ACL”
|
||||
|
||||
- 步骤 2:输入 ACL 配置参数
|
||||
|
||||
- ACL 用途：生产权限、消费权限、自定义权限
|
||||
- 生产权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic
|
||||
- 消费权限时：可选择应用于所有 Kafka User 或者特定 Kafka User；可选择应用于所有 Topic 或者特定 Topic；可选择应用于所有 Consumer Group 或者特定 Consumer Group
|
||||
|
||||
- 步骤 3:点击“确定”，新增 ACL 成功
|
||||
|
||||
|
||||
|
||||
#### 5.4.11.3、查看 User 信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“ACLs”
|
||||
|
||||
- 步骤 2:User 列表展示内容包括“Kafka User 名称”、“认证方式”、“passwprd”、操作项”修改密码“、”操作项“删除”
|
||||
|
||||
- 步骤 3:筛选框输入“Kafka User”可筛选出列表中相关 Kafka User
|
||||
|
||||
|
||||
|
||||
#### 5.4.11.4、新增 Kafka User
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Security”>“Users”>“新增 Kafka User”
|
||||
|
||||
- 步骤 2:输入 Kafka User 名称、认证方式、密码
|
||||
|
||||
- 步骤 3:点击“确定”，新增 Kafka User 成功
|
||||
|
||||
|
||||
|
||||
### 5.4.12、Job
|
||||
|
||||
#### 5.4.12.1、查看 Job 概览信息
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Job“
|
||||
|
||||
- 步骤 2:Job 概览信息包括以下内容
|
||||
|
||||
- Jobs：Job 总数
|
||||
- Doing：正在运行的 Job 总数
|
||||
- Prepare：准备运行的 Job 总数
|
||||
- Success：运行成功的 Job 总数
|
||||
- Fail：运行失败的 Job 总数
|
||||
- Job 列表
|
||||
|
||||
|
||||
|
||||
#### 5.4.12.2、Job 查看进度
|
||||
|
||||
Doing 状态下的任务可以查看进度
|
||||
|
||||
- 步骤 1:点击“多集群管理”>“集群卡片”>“Job”>“Job”列表>操作项“查看进度”>“查看进度”抽屉
|
||||
|
||||
- 步骤 2:
|
||||
|
||||
- 均衡任务：任务基本信息、均衡计划、任务执行明细信息
|
||||
- 扩缩副本：任务基本信息、任务执行明细信息、节点流量情况
|
||||
- Topic 迁移：任务基本信息、任务执行明细信息、节点流量情况
|
||||
|
||||
|
||||
|
||||
#### 5.4.12.3、Job 编辑任务
|
||||
|
||||
Prepare 状态下的任务可以进行编辑
|
||||
|
||||
- 点击“多集群管理”>“集群卡片”>“Job”>“Job”列表>操作项“编辑”
|
||||
|
||||
- 对任务执行的参数进行重新配置
|
||||
|
||||
- 集群均衡：可以对指标计算周期、均衡维度、topic 黑名单、运行配置等参数重新设置
|
||||
- Topic 迁移：可以对 topic 需要迁移的 partition、迁移数据的时间范围、目标 broker 节点、限流值、执行时间、描述等参数重新配置
|
||||
- topic 扩缩副本：可以对最终副本数、限流值、任务执行时间、描述等参数重新配置
|
||||
|
||||
- 点击“确定”，编辑任务成功
|
||||
|
||||
|
||||
230
product/6-dev-doc.md
Normal file
230
product/6-dev-doc.md
Normal file
@@ -0,0 +1,230 @@
|
||||
---
|
||||
order: 6
|
||||
title: '6.开发手册'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 6.1、本地源码启动手册
|
||||
|
||||
### 6.1.1、打包方式
|
||||
|
||||
`Know Streaming` 采用前后端分离的开发模式，使用 Maven 对项目进行统一的构建管理。maven 在打包构建过程中，会将前后端代码一并打包生成最终的安装包。
|
||||
|
||||
`Know Streaming` 除了使用安装包启动之外，还可以通过本地源码启动完整的带前端页面的项目，下面我们正式开始介绍本地源码如何启动 `Know Streaming`。
|
||||
|
||||
### 6.1.2、环境要求
|
||||
|
||||
**系统支持**
|
||||
|
||||
`windows7+`、`Linux`、`Mac`
|
||||
|
||||
**环境依赖**
|
||||
|
||||
- Maven 3.6.3
|
||||
- Node v12.20.0
|
||||
- Java 8+
|
||||
- MySQL 5.7
|
||||
- Idea
|
||||
- Elasticsearch 7.6
|
||||
- Git
|
||||
|
||||
### 6.1.3、环境初始化
|
||||
|
||||
安装好环境信息之后，还需要初始化 MySQL 与 Elasticsearch 信息，包括：
|
||||
|
||||
- 初始化 MySQL 表及数据
|
||||
- 初始化 Elasticsearch 索引
|
||||
|
||||
具体见：[快速开始](./1-quick-start.md) 中的最后一步，部署 KnowStreaming 服务中的初始化相关工作。
|
||||
|
||||
### 6.1.4、本地启动
|
||||
|
||||
**第一步：本地打包**
|
||||
|
||||
执行 `mvn install` 可对项目进行前后端同时进行打包，通过该命令，除了可以对后端进行打包之外，还可以将前端相关的静态资源文件也一并打包出来。
|
||||
|
||||
**第二步：修改配置**
|
||||
|
||||
```yaml
|
||||
# 修改 km-rest/src/main/resources/application.yml 中相关的配置
|
||||
|
||||
# 修改MySQL的配置，中间省略了一些非必需修改的配置
|
||||
spring:
|
||||
datasource:
|
||||
know-streaming:
|
||||
jdbc-url: 修改为实际MYSQL地址
|
||||
username: 修改为实际MYSQL用户名
|
||||
password: 修改为实际MYSQL密码
|
||||
logi-job:
|
||||
jdbc-url: 修改为实际MYSQL地址
|
||||
username: 修改为实际MYSQL用户名
|
||||
password: 修改为实际MYSQL密码
|
||||
logi-security:
|
||||
jdbc-url: 修改为实际MYSQL地址
|
||||
username: 修改为实际MYSQL用户名
|
||||
password: 修改为实际MYSQL密码
|
||||
|
||||
# 修改ES的配置，中间省略了一些非必需修改的配置
|
||||
es.client.address: 修改为实际ES地址
|
||||
```
|
||||
|
||||
**第三步：配置 IDEA**
|
||||
|
||||
`Know Streaming`的 Main 方法在：
|
||||
|
||||
```java
|
||||
km-rest/src/main/java/com/xiaojukeji/know/streaming/km/rest/KnowStreaming.java
|
||||
```
|
||||
|
||||
IDEA 更多具体的配置如下图所示：
|
||||
|
||||
<p align="center">
|
||||
<img src="http://img-ys011.didistatic.com/static/dc2img/do1_BW1RzgEMh4n6L4dL4ncl" width = "512" height = "318" div align=center />
|
||||
</p>
|
||||
|
||||
**第四步：启动项目**
|
||||
|
||||
最后就是启动项目，在本地 console 中输出了 `KnowStreaming-KM started` 则表示我们已经成功启动 `Know Streaming` 了。
|
||||
|
||||
### 6.1.5、本地访问
|
||||
|
||||
`Know Streaming` 启动之后，可以访问一些信息，包括：
|
||||
|
||||
- 产品页面：http://localhost:8080 ，默认账号密码：`admin` / `admin` 进行登录。（注意！v3.0 beta1 版本默认账号和密码为：`admin` / `admin2022_`）
|
||||
- 接口地址：http://localhost:8080/swagger-ui.html 查看后端提供的相关接口。
|
||||
|
||||
更多信息，详见：[KnowStreaming 官网](https://knowstreaming.com/)
|
||||
|
||||
## 6.2、版本升级手册
|
||||
|
||||
注意：如果想升级至具体版本，需要将你当前版本至你期望使用版本的变更统统执行一遍，然后才能正常使用。
|
||||
|
||||
### 6.2.0、升级至 `master` 版本
|
||||
|
||||
暂无
|
||||
|
||||
### 6.2.1、升级至 `v3.0.0-beta.2`版本
|
||||
|
||||
**配置变更**
|
||||
|
||||
```yaml
|
||||
|
||||
# 新增配置
|
||||
spring:
|
||||
logi-security: # know-streaming 依赖的 logi-security 模块的数据库的配置，默认与 know-streaming 的数据库配置保持一致即可
|
||||
login-extend-bean-name: logiSecurityDefaultLoginExtendImpl # 使用的登录系统Service的Bean名称，无需修改
|
||||
|
||||
# 线程池大小相关配置，在task模块中，新增了三类线程池，
|
||||
# 从而减少不同类型任务之间的相互影响，以及减少对logi-job内的线程池的影响
|
||||
thread-pool:
|
||||
task: # 任务模块的配置
|
||||
metrics: # metrics采集任务配置
|
||||
thread-num: 18 # metrics采集任务线程池核心线程数
|
||||
queue-size: 180 # metrics采集任务线程池队列大小
|
||||
metadata: # metadata同步任务配置
|
||||
thread-num: 27 # metadata同步任务线程池核心线程数
|
||||
queue-size: 270 # metadata同步任务线程池队列大小
|
||||
common: # 剩余其他任务配置
|
||||
thread-num: 15 # 剩余其他任务线程池核心线程数
|
||||
queue-size: 150 # 剩余其他任务线程池队列大小
|
||||
|
||||
# 删除配置，下列配置将不再使用
|
||||
thread-pool:
|
||||
task: # 任务模块的配置
|
||||
heaven: # 采集任务配置
|
||||
thread-num: 20 # 采集任务线程池核心线程数
|
||||
queue-size: 1000 # 采集任务线程池队列大小
|
||||
|
||||
```
|
||||
|
||||
**SQL 变更**
|
||||
|
||||
```sql
|
||||
-- 多集群管理权限2022-09-06新增
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2000', '多集群管理查看', '1593', '1', '2', '多集群管理查看', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2002', 'Topic-迁移副本', '1593', '1', '2', 'Topic-迁移副本', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2004', 'Topic-扩缩副本', '1593', '1', '2', 'Topic-扩缩副本', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2006', 'Cluster-LoadReBalance-周期均衡', '1593', '1', '2', 'Cluster-LoadReBalance-周期均衡', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2008', 'Cluster-LoadReBalance-立即均衡', '1593', '1', '2', 'Cluster-LoadReBalance-立即均衡', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('2010', 'Cluster-LoadReBalance-设置集群规格', '1593', '1', '2', 'Cluster-LoadReBalance-设置集群规格', '0', 'know-streaming');
|
||||
|
||||
|
||||
-- 系统管理权限2022-09-06新增
|
||||
INSERT INTO `logi_security_permission` (`id`, `permission_name`, `parent_id`, `leaf`, `level`, `description`, `is_delete`, `app_name`) VALUES ('3000', '系统管理查看', '1595', '1', '2', '系统管理查看', '0', 'know-streaming');
|
||||
|
||||
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2000', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2002', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2004', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2006', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2008', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '2010', '0', 'know-streaming');
|
||||
INSERT INTO `logi_security_role_permission` (`role_id`, `permission_id`, `is_delete`, `app_name`) VALUES ('1677', '3000', '0', 'know-streaming');
|
||||
|
||||
-- 修改字段长度
|
||||
ALTER TABLE `logi_security_oplog`
|
||||
CHANGE COLUMN `operator_ip` `operator_ip` VARCHAR(64) NOT NULL COMMENT '操作者ip' ,
|
||||
CHANGE COLUMN `operator` `operator` VARCHAR(64) NULL DEFAULT NULL COMMENT '操作者账号' ,
|
||||
CHANGE COLUMN `operate_page` `operate_page` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '操作页面' ,
|
||||
CHANGE COLUMN `operate_type` `operate_type` VARCHAR(64) NOT NULL COMMENT '操作类型' ,
|
||||
CHANGE COLUMN `target_type` `target_type` VARCHAR(64) NOT NULL COMMENT '对象分类' ,
|
||||
CHANGE COLUMN `target` `target` VARCHAR(1024) NOT NULL COMMENT '操作对象' ,
|
||||
CHANGE COLUMN `operation_methods` `operation_methods` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '操作方式' ;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6.2.2、升级至 `v3.0.0-beta.1`版本
|
||||
|
||||
**SQL 变更**
|
||||
|
||||
1、在`ks_km_broker`表增加了一个监听信息字段。
|
||||
2、为`logi_security_oplog`表 operation_methods 字段设置默认值''。
|
||||
因此需要执行下面的 sql 对数据库表进行更新。
|
||||
|
||||
```sql
|
||||
ALTER TABLE `ks_km_broker`
|
||||
ADD COLUMN `endpoint_map` VARCHAR(1024) NOT NULL DEFAULT '' COMMENT '监听信息' AFTER `update_time`;
|
||||
|
||||
ALTER TABLE `logi_security_oplog`
|
||||
ALTER COLUMN `operation_methods` set default '';
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6.2.3、`2.x`版本 升级至 `v3.0.0-beta.0`版本
|
||||
|
||||
**升级步骤：**
|
||||
|
||||
1. 依旧使用**`2.x 版本的 DB`**，在上面初始化 3.0.0 版本所需数据库表结构及数据；
|
||||
2. 将 2.x 版本中的集群，在 3.0.0 版本，手动逐一接入；
|
||||
3. 将 Topic 业务数据，迁移至 3.0.0 表中，详见下方 SQL；
|
||||
|
||||
**注意事项**
|
||||
|
||||
- 建议升级 3.0.0 版本过程中，保留 2.x 版本的使用，待 3.0.0 版本稳定使用后，再下线 2.x 版本；
|
||||
- 3.0.0 版本仅需要`集群信息`及`Topic的描述信息`。2.x 版本的 DB 的其他数据 3.0.0 版本都不需要；
|
||||
- 部署 3.0.0 版本之后，集群、Topic 等指标数据都为空，3.0.0 版本会周期进行采集，运行一段时间之后就会有该数据了，因此不会将 2.x 中的指标数据进行迁移；
|
||||
|
||||
**迁移数据**
|
||||
|
||||
```sql
|
||||
-- 迁移Topic的备注信息。
|
||||
-- 需在 3.0.0 部署完成后，再执行该SQL。
|
||||
-- 考虑到 2.x 版本中还存在增量数据，因此建议改SQL周期执行，是的增量数据也能被迁移至 3.0.0 版本中。
|
||||
|
||||
UPDATE ks_km_topic
|
||||
INNER JOIN
|
||||
(SELECT
|
||||
topic.cluster_id AS cluster_id,
|
||||
topic.topic_name AS topic_name,
|
||||
topic.description AS description
|
||||
FROM topic WHERE description != ''
|
||||
) AS t
|
||||
|
||||
ON ks_km_topic.cluster_phy_id = t.cluster_id
|
||||
AND ks_km_topic.topic_name = t.topic_name
|
||||
AND ks_km_topic.id > 0
|
||||
SET ks_km_topic.description = t.description;
|
||||
```
|
||||
284
product/7-update-log.md
Normal file
284
product/7-update-log.md
Normal file
@@ -0,0 +1,284 @@
|
||||
---
|
||||
order: 7
|
||||
title: '7.更新日志'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 7.1、v3.2.0
|
||||
|
||||
**问题修复**
|
||||
|
||||
- 修复健康巡检结果更新至 DB 时，出现死锁问题；
|
||||
- 修复 KafkaJMXClient 类中，logger 错误的问题；
|
||||
- 后端修复 Topic 过期策略在 0.10.1.0 版本能多选的问题，实际应该只能二选一；
|
||||
- 修复接入集群时，不填写集群配置会报错的问题；
|
||||
- 升级 spring-context 至 5.3.19 版本，修复安全漏洞；
|
||||
- 修复 Broker & Topic 修改配置时，多版本兼容配置的版本信息错误的问题；
|
||||
- 修复 Topic 列表的健康分为健康状态；
|
||||
- 修复 Broker LogSize 指标存储名称错误导致查询不到的问题；
|
||||
- 修复 Prometheus 中，缺少 Group 部分指标的问题；
|
||||
- 修复因缺少健康状态指标导致集群数错误的问题；
|
||||
- 修复后台任务记录操作日志时，因缺少操作用户信息导致出现异常的问题；
|
||||
- 修复 Replica 指标查询时，DSL 错误的问题；
|
||||
- 关闭 errorLogger，修复错误日志重复输出的问题；
|
||||
- 修复系统管理更新用户信息失败的问题；
|
||||
|
||||
**产品优化**
|
||||
|
||||
- 优化健康巡检为按照资源维度多线程并发处理；
|
||||
- 统一日志输出格式，并优化部分输出的日志；
|
||||
- 优化 ZK 四字命令结果解析过程中，容易引起误解的 WARN 日志；
|
||||
- 优化 Zookeeper 详情中，目录结构的搜索文案；
|
||||
- 优化线程池的名称，方便第三方系统进行相关问题的分析；
|
||||
- 去除 ESClient 的并发访问控制，降低 ESClient 创建数及提升利用率；
|
||||
- 优化 Topic Messages 抽屉文案；
|
||||
- 优化 ZK 健康巡检失败时的错误日志信息；
|
||||
- 提高 Offset 信息获取的超时时间，降低并发过高时出现请求超时的概率；
|
||||
- 优化 Topic & Partition 元信息的更新策略，降低对 DB 连接的占用；
|
||||
- 优化 Sonar 代码扫码问题；
|
||||
- 优化分区 Offset 指标的采集；
|
||||
- 优化前端图表相关组件逻辑;
|
||||
- 优化产品主题色;
|
||||
- Consumer 列表刷新按钮新增 hover 提示；
|
||||
- 优化配置 Topic 的消息大小时的测试弹框体验；
|
||||
|
||||
**功能新增**
|
||||
|
||||
- 新增页面无数据排查文档；
|
||||
- 增加 ES 索引删除的功能；
|
||||
|
||||
**Kafka Connect Beta 版 (v3.2.0 版本新增发布)**
|
||||
|
||||
- Connect 集群的纳管；
|
||||
- Connector 的增删改查；
|
||||
- Connect 集群 & Connector 的指标大盘；
|
||||
|
||||
## 7.2、v3.1.0
|
||||
|
||||
**Bug 修复**
|
||||
|
||||
- 修复重置 Group Offset 的提示信息中，缺少 Dead 状态也可进行重置的描述；
|
||||
- 修复新建 Topic 后，立即查看 Topic Messages 信息时，会提示 Topic 不存在的问题；
|
||||
- 修复副本变更时，优先副本选举未被正常处罚执行的问题；
|
||||
- 修复 git 目录不存在时，打包不能正常进行的问题；
|
||||
- 修复 KRaft 模式的 Kafka 集群，JMX PORT 显示 -1 的问题；
|
||||
|
||||
**体验优化**
|
||||
|
||||
- 优化 Cluster、Broker、Topic、Group 的健康分为健康状态；
|
||||
- 去除健康巡检配置中的权重信息；
|
||||
- 错误提示页面展示优化；
|
||||
- 前端打包编译依赖默认使用 taobao 镜像；
|
||||
|
||||
**新增**
|
||||
|
||||
- 个人头像下拉信息中，新增产品版本信息；
|
||||
- 多集群列表页面，新增集群健康状态分布信息；
|
||||
|
||||
**Kafka ZK 部分 (v3.1.0 版本正式发布)**
|
||||
|
||||
- 新增 ZK 集群的指标大盘信息；
|
||||
- 新增 ZK 集群的服务状态概览信息；
|
||||
- 新增 ZK 集群的服务节点列表信息；
|
||||
- 新增 Kafka 在 ZK 的存储数据查看功能；
|
||||
- 新增 ZK 的健康巡检及健康状态计算；
|
||||
|
||||
## 7.3、v3.0.0-beta.2
|
||||
|
||||
**文档**
|
||||
|
||||
- 新增登录系统对接文档
|
||||
- 优化前端工程打包构建部分文档说明
|
||||
- FAQ 补充 KnowStreaming 连接特定 JMX IP 的说明
|
||||
|
||||
**Bug 修复**
|
||||
|
||||
- 修复 logi_security_oplog 表字段过短，导致删除 Topic 等操作无法记录的问题
|
||||
- 修复 ES 查询时，抛 java.lang.NumberFormatException: For input string: "{"value":0,"relation":"eq"}" 问题
|
||||
- 修复 LogStartOffset 和 LogEndOffset 指标单位错误问题
|
||||
- 修复进行副本变更时，旧副本数为 NULL 的问题
|
||||
- 修复集群 Group 列表，在第二页搜索时，搜索时返回的分页信息错误问题
|
||||
- 修复重置 Offset 时，返回的错误信息提示不一致的问题
|
||||
- 修复集群查看，系统查看，LoadRebalance 等页面权限点缺失问题
|
||||
- 修复查询不存在的 Topic 时，错误信息提示不明显的问题
|
||||
- 修复 Windows 用户打包前端工程报错的问题
|
||||
- package-lock.json 锁定前端依赖版本号，修复因依赖自动升级导致打包失败等问题
|
||||
- 系统管理子应用，补充后端返回的 Code 码拦截，解决后端接口返回报错不展示的问题
|
||||
- 修复用户登出后，依旧可以访问系统的问题
|
||||
- 修复巡检任务配置时，数值显示错误的问题
|
||||
- 修复 Broker/Topic Overview 图表和图表详情问题
|
||||
- 修复 Job 扩缩副本任务明细数据错误的问题
|
||||
- 修复重置 Offset 时，分区 ID，Offset 数值无限制问题
|
||||
- 修复扩缩/迁移副本时，无法选中 Kafka 系统 Topic 的问题
|
||||
- 修复 Topic 的 Config 页面，编辑表单时不能正确回显当前值的问题
|
||||
- 修复 Broker Card 返回数据后依旧展示加载态的问题
|
||||
|
||||
**体验优化**
|
||||
|
||||
- 优化默认用户密码为 admin/admin
|
||||
- 缩短新增集群后，集群信息加载的耗时
|
||||
- 集群 Broker 列表，增加 Controller 角色信息
|
||||
- 副本变更任务结束后，增加进行优先副本选举的操作
|
||||
- Task 模块任务分为 Metrics、Common、Metadata 三类任务，每类任务配备独立线程池，减少对 Job 模块的线程池，以及不同类任务之间的相互影响
|
||||
- 删除代码中存在的多余无用文件
|
||||
- 自动新增 ES 索引模版及近 7 天索引，减少用户搭建时需要做的事项
|
||||
- 优化前端工程打包流程
|
||||
- 优化登录页文案，页面左侧栏内容，单集群详情样式，Topic 列表趋势图等
|
||||
- 首次进入 Broker/Topic 图表详情时，进行预缓存数据从而优化体验
|
||||
- 优化 Topic 详情 Partition Tab 的展示
|
||||
- 多集群列表页增加编辑功能
|
||||
- 优化副本变更时，迁移时间支持分钟级别粒度
|
||||
- logi-security 版本升级至 2.10.13
|
||||
- logi-elasticsearch-client 版本升级至 1.0.24
|
||||
|
||||
**能力提升**
|
||||
|
||||
- 支持 Ldap 登录认证
|
||||
|
||||
## 7.4、v3.0.0-beta.1
|
||||
|
||||
**文档**
|
||||
|
||||
- 新增 Task 模块说明文档
|
||||
- FAQ 补充 `Specified key was too long; max key length is 767 bytes ` 错误说明
|
||||
- FAQ 补充 `出现ESIndexNotFoundException报错` 错误说明
|
||||
|
||||
**Bug 修复**
|
||||
|
||||
- 修复 Consumer 点击 Stop 未停止检索的问题
|
||||
- 修复创建/编辑角色权限报错问题
|
||||
- 修复多集群管理/单集群详情均衡卡片状态错误问题
|
||||
- 修复版本列表未排序问题
|
||||
- 修复 Raft 集群 Controller 信息不断记录问题
|
||||
- 修复部分版本消费组描述信息获取失败问题
|
||||
- 修复分区 Offset 获取失败的日志中，缺少 Topic 名称信息问题
|
||||
- 修复 GitHub 图地址错误，及图裂问题
|
||||
- 修复 Broker 默认使用的地址和注释不一致问题
|
||||
- 修复 Consumer 列表分页不生效问题
|
||||
- 修复操作记录表 operation_methods 字段缺少默认值问题
|
||||
- 修复集群均衡表中 move_broker_list 字段无效的问题
|
||||
- 修复 KafkaUser、KafkaACL 信息获取时，日志一直重复提示不支持问题
|
||||
- 修复指标缺失时，曲线出现掉底的问题
|
||||
|
||||
**体验优化**
|
||||
|
||||
- 优化前端构建时间和打包体积，增加依赖打包的分包策略
|
||||
- 优化产品样式和文案展示
|
||||
- 优化 ES 客户端数为可配置
|
||||
- 优化日志中大量出现的 MySQL Key 冲突日志
|
||||
|
||||
**能力提升**
|
||||
|
||||
- 增加周期任务，用于主动创建缺少的 ES 模版及索引的能力，减少额外的脚本操作
|
||||
- 增加 JMX 连接的 Broker 地址可选择的能力
|
||||
|
||||
---
|
||||
|
||||
## 7.5、v3.0.0-beta.0
|
||||
|
||||
**1、多集群管理**
|
||||
|
||||
- 增加健康监测体系、关键组件&指标 GUI 展示
|
||||
- 增加 2.8.x 以上 Kafka 集群接入，覆盖 0.10.x-3.x
|
||||
- 删除逻辑集群、共享集群、Region 概念
|
||||
|
||||
**2、Cluster 管理**
|
||||
|
||||
- 增加集群概览信息、集群配置变更记录
|
||||
- 增加 Cluster 健康分，健康检查规则支持自定义配置
|
||||
- 增加 Cluster 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Cluster 层 I/O、Disk 的 Load Reblance 功能，支持定时均衡任务（企业版）
|
||||
- 删除限流、鉴权功能
|
||||
- 删除 APPID 概念
|
||||
|
||||
**3、Broker 管理**
|
||||
|
||||
- 增加 Broker 健康分
|
||||
- 增加 Broker 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Broker 参数配置功能，需重启生效
|
||||
- 增加 Controller 变更记录
|
||||
- 增加 Broker Datalogs 记录
|
||||
- 删除 Leader Rebalance 功能
|
||||
- 删除 Broker 优先副本选举
|
||||
|
||||
**4、Topic 管理**
|
||||
|
||||
- 增加 Topic 健康分
|
||||
- 增加 Topic 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Topic 参数配置功能，可实时生效
|
||||
- 增加 Topic 批量迁移、Topic 批量扩缩副本功能
|
||||
- 增加查看系统 Topic 功能
|
||||
- 优化 Partition 分布的 GUI 展示
|
||||
- 优化 Topic Message 数据采样
|
||||
- 删除 Topic 过期概念
|
||||
- 删除 Topic 申请配额功能
|
||||
|
||||
**5、Consumer 管理**
|
||||
|
||||
- 优化了 ConsumerGroup 展示形式，增加 Consumer Lag 的 GUI 展示
|
||||
|
||||
**6、ACL 管理**
|
||||
|
||||
- 增加原生 ACL GUI 配置功能，可配置生产、消费、自定义多种组合权限
|
||||
- 增加 KafkaUser 功能，可自定义新增 KafkaUser
|
||||
|
||||
**7、消息测试（企业版）**
|
||||
|
||||
- 增加生产者消息模拟器，支持 Data、Flow、Header、Options 自定义配置（企业版）
|
||||
- 增加消费者消息模拟器，支持 Data、Flow、Header、Options 自定义配置（企业版）
|
||||
|
||||
**8、Job**
|
||||
|
||||
- 优化 Job 模块，支持任务进度管理
|
||||
|
||||
**9、系统管理**
|
||||
|
||||
- 优化用户、角色管理体系，支持自定义角色配置页面及操作权限
|
||||
- 优化审计日志信息
|
||||
- 删除多租户体系
|
||||
- 删除工单流程
|
||||
|
||||
## 7.6、v2.6.0
|
||||
|
||||
**1、能力提升**
|
||||
|
||||
- 增加简单回退工具类
|
||||
|
||||
**2、体验优化**
|
||||
|
||||
- 补充周期任务说明文档
|
||||
- 补充集群安装部署使用说明文档
|
||||
- 升级 Swagger、SpringFramework、SpringBoot、EChats 版本
|
||||
- 优化 Task 模块的日志输出
|
||||
- 优化 corn 表达式解析失败后退出无任何日志提示问题
|
||||
- Ldap 用户接入时，增加部门及邮箱信息等
|
||||
- 对 Jmx 模块，增加连接失败后的回退机制及错误日志优化
|
||||
- 增加线程池、客户端池可配置
|
||||
- 删除无用的 jmx_prometheus_javaagent-0.14.0.jar
|
||||
- 优化迁移任务名称
|
||||
- 优化创建 Region 时，Region 容量信息不能立即被更新问题
|
||||
- 引入 lombok
|
||||
- 更新视频教程
|
||||
- 优化 kcm_script.sh 脚本中的 LogiKM 地址为可通过程序传入
|
||||
- 第三方接口及网关接口，增加是否跳过登录的开关
|
||||
- extends 模块相关配置调整为非必须在 application.yml 中配置
|
||||
|
||||
**3、bug 修复**
|
||||
|
||||
- 修复批量往 DB 写入空指标数组时报 SQL 语法异常的问题
|
||||
- 修复网关增加配置及修改配置时，version 不变化问题
|
||||
- 修复集群列表页，提示框遮挡问题
|
||||
- 修复对高版本 Broker 元信息协议解析失败的问题
|
||||
- 修复 Dockerfile 执行时提示缺少 application.yml 文件的问题
|
||||
- 修复逻辑集群更新时，会报空指针的问题
|
||||
|
||||
## 7.7、v2.5.0
|
||||
|
||||
**1、体验优化**
|
||||
|
||||
- 修复 bug getAttributes 运行时错误问题
|
||||
- 修复 "集群概览"下查看最近 7 天"历史流量"的时候，Tooltip 中的时间只包含日期
|
||||
- 新增了 Linux 下系统启动和关闭的脚本
|
||||
- "我的审批"列表增加"通过时间"列，并支持按该列排序
|
||||
- tomcat 依赖包升级到 8.5.72
|
||||
- 修复 [前端+后端问题] Topic 管理-更多-编辑-备注没有数据回显; 后端接口也没有返回值 问题
|
||||
172
product/8-common-questions.md
Normal file
172
product/8-common-questions.md
Normal file
@@ -0,0 +1,172 @@
|
||||
---
|
||||
order: 8
|
||||
title: '8.常见问题'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 8.1、支持哪些 Kafka 版本？
|
||||
|
||||
- 支持 0.10+ 的 Kafka 版本；
|
||||
- 支持 ZK 及 Raft 运行模式的 Kafka 版本；
|
||||
|
||||
|
||||
|
||||
## 8.1、2.x 版本和 3.0 版本有什么差异？
|
||||
|
||||
**全新设计理念**
|
||||
|
||||
- 在 0 侵入、0 门槛的前提下提供直观 GUI 用于管理和观测 Apache Kafka®，帮助用户降低 Kafka CLI 操作门槛，轻松实现对原生 Kafka 集群的可管、可见、可掌控，提升 Kafka 使用体验和降低管理成本。
|
||||
- 支持海量集群一键接入，无需任何改造，即可实现集群深度纳管，真正的 0 侵入、插件化系统设计，覆盖 0.10.x-3.x.x 众多 Kafka 版本无缝纳管。
|
||||
|
||||
**开源协议调整**
|
||||
|
||||
- 3.x：AGPL 3.0
|
||||
- 2.x：Apache License 2.0
|
||||
|
||||
更多具体内容见：[新旧版本对比](./9-attachment#92新旧版本对比)
|
||||
|
||||
|
||||
|
||||
## 8.3、页面流量信息等无数据？
|
||||
|
||||
- 1、`Broker JMX`未正确开启
|
||||
|
||||
可以参看：[Jmx 连接配置&问题解决](9-attachment#91jmx-连接失败问题解决)
|
||||
|
||||
- 2、`ES` 存在问题
|
||||
|
||||
建议使用`ES 7.6`版本，同时创建近 7 天的索引，具体见：[快速开始](./1-quick-start.md) 中的 ES 索引模版及索引创建。
|
||||
|
||||
|
||||
|
||||
## 8.4、`Jmx`连接失败如何解决？
|
||||
|
||||
- 参看 [Jmx 连接配置&问题解决](./9-attachment#jmx-连接失败问题解决) 说明。
|
||||
|
||||
|
||||
|
||||
## 8.5、有没有 API 文档？
|
||||
|
||||
`KnowStreaming` 采用 Swagger 进行 API 说明，在启动 KnowStreaming 服务之后，就可以从下面地址看到。
|
||||
|
||||
Swagger-API 地址： [http://IP:PORT/swagger-ui.html#/](http://IP:PORT/swagger-ui.html#/)
|
||||
|
||||
|
||||
|
||||
## 8.6、删除 Topic 成功后，为何过段时间又出现了？
|
||||
|
||||
**原因说明：**
|
||||
|
||||
`KnowStreaming` 会去请求 Topic 的 endoffset 信息，要获取这个信息就需要发送 metadata 请求，发送 metadata 请求的时候，如果集群允许自动创建 Topic，那么当 Topic 不存在时，就会自动将该 Topic 创建出来。
|
||||
|
||||
**问题解决：**
|
||||
|
||||
因为在 `KnowStreaming` 上，禁止 Kafka 客户端内部元信息获取这个动作非常的难做到，因此短时间内这个问题不好从 `KnowStreaming` 上解决。
|
||||
|
||||
当然，对于不存在的 Topic，`KnowStreaming` 是不会进行元信息请求的，因此也不用担心会莫名其妙的创建一个 Topic 出来。
|
||||
|
||||
但是，另外一点，对于开启允许 Topic 自动创建的集群，建议是关闭该功能，开启是非常危险的，如果关闭之后，`KnowStreaming` 也不会有这个问题。
|
||||
|
||||
最后这里举个开启这个配置后，非常危险的代码例子吧：
|
||||
|
||||
```java
|
||||
for (int i= 0; i < 100000; ++i) {
|
||||
// 如果是客户端类似这样写的，那么一启动，那么将创建10万个Topic出来，集群元信息瞬间爆炸，controller可能就不可服务了。
|
||||
producer.send(new ProducerRecord<String, String>("know_streaming" + i,"hello logi_km"));
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 8.7、如何在不登录的情况下，调用接口？
|
||||
|
||||
步骤一：接口调用时，在 header 中，增加如下信息：
|
||||
|
||||
```shell
|
||||
# 表示开启登录绕过
|
||||
Trick-Login-Switch : on
|
||||
|
||||
# 登录绕过的用户, 这里可以是admin, 或者是其他的, 但是必须在系统管理->用户管理中设置了该用户。
|
||||
Trick-Login-User : admin
|
||||
```
|
||||
|
||||
|
||||
|
||||
步骤二：点击右上角"系统管理"，选择配置管理，在页面中添加以下键值对。
|
||||
|
||||
```shell
|
||||
# 模块选择
|
||||
SECURITY.LOGIN
|
||||
|
||||
# 设置的配置键，必须是这个
|
||||
SECURITY.TRICK_USERS
|
||||
|
||||
# 设置的value，是json数组的格式，包含步骤一header中设置的用户名，例如
|
||||
[ "admin", "logi"]
|
||||
```
|
||||
|
||||
|
||||
|
||||
步骤三：解释说明
|
||||
|
||||
设置完成上面两步之后，就可以直接调用需要登录的接口了。
|
||||
|
||||
但是还有一点需要注意，绕过的用户仅能调用他有权限的接口，比如一个普通用户，那么他就只能调用普通的接口，不能去调用运维人员的接口。
|
||||
|
||||
## 8.8、Specified key was too long; max key length is 767 bytes
|
||||
|
||||
**原因：** 不同版本的 InoDB 引擎，参数‘innodb_large_prefix’默认值不同，即在 5.6 默认值为 OFF，5.7 默认值为 ON。
|
||||
|
||||
对于引擎为 InnoDB，innodb_large_prefix=OFF，且行格式为 Antelope 即支持 REDUNDANT 或 COMPACT 时，索引键前缀长度最大为 767 字节。innodb_large_prefix=ON，且行格式为 Barracuda 即支持 DYNAMIC 或 COMPRESSED 时，索引键前缀长度最大为 3072 字节。
|
||||
|
||||
**解决方案：**
|
||||
|
||||
- 减少 varchar 字符大小低于 767/4=191。
|
||||
- 将字符集改为 latin1（一个字符=一个字节）。
|
||||
- 开启‘innodb_large_prefix’，修改默认行格式‘innodb_file_format’为 Barracuda，并设置 row_format=dynamic。
|
||||
|
||||
## 8.9、出现 ESIndexNotFoundEXception 报错
|
||||
|
||||
**原因 ：**没有创建 ES 索引模版
|
||||
|
||||
**解决方案：**执行 init_es_template.sh 脚本，创建 ES 索引模版即可。
|
||||
|
||||
## 8.10、km-console 打包构建失败
|
||||
|
||||
首先，**请确保您正在使用最新版本**，版本列表见 [Tags](https://github.com/didi/KnowStreaming/tags)。如果不是最新版本，请升级后再尝试有无问题。
|
||||
|
||||
常见的原因是由于工程依赖没有正常安装，导致在打包过程中缺少依赖，造成打包失败。您可以检查是否有以下文件夹，且文件夹内是否有内容
|
||||
|
||||
```
|
||||
KnowStreaming/km-console/node_modules
|
||||
KnowStreaming/km-console/packages/layout-clusters-fe/node_modules
|
||||
KnowStreaming/km-console/packages/config-manager-fe/node_modules
|
||||
```
|
||||
|
||||
如果发现没有对应的 `node_modules` 目录或着目录内容为空，说明依赖没有安装成功。请按以下步骤操作，
|
||||
|
||||
1. 手动删除上述三个文件夹（如果有）
|
||||
|
||||
2. 如果之前是通过 `mvn install` 打包 `km-console`，请到项目根目录（KnowStreaming）下重新输入该指令进行打包。观察打包过程有无报错。如有报错，请见步骤 4。
|
||||
|
||||
3. 如果是通过本地独立构建前端工程的方式（指直接执行 `npm run build`），请进入 `KnowStreaming/km-console` 目录，执行下述步骤（注意：执行时请确保您在使用 `node v12` 版本）
|
||||
|
||||
a. 执行 `npm run i`。如有报错，请见步骤 4。
|
||||
|
||||
b. 执行 `npm run build`。如有报错，请见步骤 4。
|
||||
|
||||
4. 麻烦联系我们协助解决。推荐提供以下信息，方面我们快速定位问题，示例如下。
|
||||
|
||||
```
|
||||
操作系统: Mac
|
||||
命令行终端：bash
|
||||
Node 版本: v12.22.12
|
||||
复现步骤: 1. -> 2.
|
||||
错误截图:
|
||||
```
|
||||
|
||||
## 8.11、在 `km-console` 目录下执行 `npm run start` 时看不到应用构建和热加载过程？如何启动单个应用？
|
||||
|
||||
需要到具体的应用中执行 `npm run start`，例如 `cd packages/layout-clusters-fe` 后，执行 `npm run start`。
|
||||
|
||||
应用启动后需要到基座应用中查看（需要启动基座应用，即 layout-clusters-fe）。
|
||||
232
product/9-attachment.md
Normal file
232
product/9-attachment.md
Normal file
@@ -0,0 +1,232 @@
|
||||
---
|
||||
order: 9
|
||||
title: '9. 附录'
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 9.1、JMX-连接失败问题解决
|
||||
|
||||
- [9.1、JMX-连接失败问题解决](#91jmx-连接失败问题解决)
|
||||
- [9.1.1、问题&说明](#911问题说明)
|
||||
- [9.1.2、解决方法](#912解决方法)
|
||||
- [9.1.3、解决方法 —— 认证的 JMX](#913解决方法--认证的-jmx)
|
||||
- [9.2、新旧版本对比](#92新旧版本对比)
|
||||
- [9.2.1、全新的设计理念](#921全新的设计理念)
|
||||
- [9.2.2、产品名称&协议](#922产品名称协议)
|
||||
- [9.2.3、功能架构](#923功能架构)
|
||||
- [9.2.4、功能变更](#924功能变更)
|
||||
|
||||
集群正常接入 Logi-KafkaManager 之后，即可以看到集群的 Broker 列表，此时如果查看不了 Topic 的实时流量，或者是 Broker 的实时流量信息时，那么大概率就是 JMX 连接的问题了。
|
||||
|
||||
下面我们按照步骤来一步一步的检查。
|
||||
|
||||
### 9.1.1、问题说明
|
||||
|
||||
**类型一：JMX 配置未开启**
|
||||
|
||||
未开启时，直接到`2、解决方法`查看如何开启即可。
|
||||
|
||||
|
||||
|
||||
**类型二：配置错误**
|
||||
|
||||
`JMX`端口已经开启的情况下，有的时候开启的配置不正确，此时也会导致出现连接失败的问题。这里大概列举几种原因：
|
||||
|
||||
- `JMX`配置错误：见`2、解决方法`。
|
||||
- 存在防火墙或者网络限制：网络通的另外一台机器`telnet`试一下看是否可以连接上。
|
||||
- 需要进行用户名及密码的认证：见`3、解决方法 —— 认证的JMX`。
|
||||
|
||||
错误日志例子：
|
||||
|
||||
```
|
||||
# 错误一： 错误提示的是真实的IP，这样的话基本就是JMX配置的有问题了。
|
||||
2021-01-27 10:06:20.730 ERROR 50901 --- [ics-Thread-1-62] c.x.k.m.c.utils.jmx.JmxConnectorWrap : JMX connect exception, host:192.168.0.1 port:9999.
|
||||
java.rmi.ConnectException: Connection refused to host: 192.168.0.1; nested exception is:
|
||||
|
||||
|
||||
# 错误二：错误提示的是127.0.0.1这个IP，这个是机器的hostname配置的可能有问题。
|
||||
2021-01-27 10:06:20.730 ERROR 50901 --- [ics-Thread-1-62] c.x.k.m.c.utils.jmx.JmxConnectorWrap : JMX connect exception, host:127.0.0.1 port:9999.
|
||||
java.rmi.ConnectException: Connection refused to host: 127.0.0.1;; nested exception is:
|
||||
```
|
||||
|
||||
**类型三：连接特定 IP**
|
||||
|
||||
Broker 配置了内外网，而 JMX 在配置时，可能配置了内网 IP 或者外网 IP，此时 `KnowStreaming` 需要连接到特定网络的 IP 才可以进行访问。
|
||||
|
||||
比如：
|
||||
|
||||
Broker 在 ZK 的存储结构如下所示，我们期望连接到 `endpoints` 中标记为 `INTERNAL` 的地址，但是 `KnowStreaming` 却连接了 `EXTERNAL` 的地址，此时可以看 `4、解决方法 —— JMX连接特定网络` 进行解决。
|
||||
|
||||
```json
|
||||
{
|
||||
"listener_security_protocol_map": {
|
||||
"EXTERNAL": "SASL_PLAINTEXT",
|
||||
"INTERNAL": "SASL_PLAINTEXT"
|
||||
},
|
||||
"endpoints": ["EXTERNAL://192.168.0.1:7092", "INTERNAL://192.168.0.2:7093"],
|
||||
"jmx_port": 8099,
|
||||
"host": "192.168.0.1",
|
||||
"timestamp": "1627289710439",
|
||||
"port": -1,
|
||||
"version": 4
|
||||
}
|
||||
```
|
||||
|
||||
### 9.1.2、解决方法
|
||||
|
||||
这里仅介绍一下比较通用的解决方式，如若有更好的方式，欢迎大家指导告知一下。
|
||||
|
||||
修改`kafka-server-start.sh`文件：
|
||||
|
||||
```
|
||||
# 在这个下面增加JMX端口的配置
|
||||
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
|
||||
export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
|
||||
export JMX_PORT=9999 # 增加这个配置, 这里的数值并不一定是要9999
|
||||
fi
|
||||
```
|
||||
|
||||
|
||||
|
||||
修改`kafka-run-class.sh`文件
|
||||
|
||||
```
|
||||
# JMX settings
|
||||
if [ -z "$KAFKA_JMX_OPTS" ]; then
|
||||
KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=${当前机器的IP}"
|
||||
fi
|
||||
|
||||
# JMX port to use
|
||||
if [ $JMX_PORT ]; then
|
||||
KAFKA_JMX_OPTS="$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT"
|
||||
fi
|
||||
```
|
||||
|
||||
### 9.1.3、解决方法 —— 认证的 JMX
|
||||
|
||||
如果您是直接看的这个部分，建议先看一下上一节：`2、解决方法`以确保`JMX`的配置没有问题了。
|
||||
|
||||
在`JMX`的配置等都没有问题的情况下，如果是因为认证的原因导致连接不了的，可以在集群接入界面配置你的`JMX`认证信息。
|
||||
|
||||
<img src='http://img-ys011.didistatic.com/static/dc2img/do1_EUU352qMEX1Jdp7pxizp' width=350>
|
||||
|
||||
### 9.1.4、解决方法 —— JMX 连接特定网络
|
||||
|
||||
可以手动往`ks_km_physical_cluster`表的`jmx_properties`字段增加一个`useWhichEndpoint`字段，从而控制 `KnowStreaming` 连接到特定的 JMX IP 及 PORT。
|
||||
|
||||
`jmx_properties`格式：
|
||||
|
||||
```json
|
||||
{
|
||||
"maxConn": 100, # KM对单台Broker的最大JMX连接数
|
||||
"username": "xxxxx", # 用户名，可以不填写
|
||||
"password": "xxxx", # 密码，可以不填写
|
||||
"openSSL": true, # 开启SSL, true表示开启ssl, false表示关闭
|
||||
"useWhichEndpoint": "EXTERNAL" #指定要连接的网络名称，填写EXTERNAL就是连接endpoints里面的EXTERNAL地址
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
SQL 例子：
|
||||
|
||||
```sql
|
||||
UPDATE ks_km_physical_cluster SET jmx_properties='{ "maxConn": 10, "username": "xxxxx", "password": "xxxx", "openSSL": false , "useWhichEndpoint": "xxx"}' where id={xxx};
|
||||
```
|
||||
|
||||
注意：
|
||||
|
||||
- 目前此功能只支持采用 `ZK` 做分布式协调的 kafka 集群。
|
||||
|
||||
## 9.2、新旧版本对比
|
||||
|
||||
### 9.2.1、全新的设计理念
|
||||
|
||||
- 在 0 侵入、0 门槛的前提下提供直观 GUI 用于管理和观测 Apache Kafka®，帮助用户降低 Kafka CLI 操作门槛，轻松实现对原生 Kafka 集群的可管、可见、可掌控，提升 Kafka 使用体验和降低管理成本。
|
||||
- 支持海量集群一键接入，无需任何改造，即可实现集群深度纳管，真正的 0 侵入、插件化系统设计，覆盖 0.10.x-3.x.x 众多 Kafka 版本无缝纳管。
|
||||
|
||||
### 9.2.2、产品名称&协议
|
||||
|
||||
- Know Streaming V3.0
|
||||
|
||||
- 名称：Know Streaming
|
||||
- 协议：AGPL 3.0
|
||||
|
||||
- Logi-KM V2.x
|
||||
|
||||
- 名称：Logi-KM
|
||||
- 协议：Apache License 2.0
|
||||
|
||||
### 9.2.3、功能架构
|
||||
|
||||
- Know Streaming V3.0
|
||||
|
||||
|
||||
|
||||
- Logi-KM V2.x
|
||||
|
||||
|
||||
|
||||
### 9.2.4、功能变更
|
||||
|
||||
- 多集群管理
|
||||
|
||||
- 增加健康监测体系、关键组件&指标 GUI 展示
|
||||
- 增加 2.8.x 以上 Kafka 集群接入，覆盖 0.10.x-3.x
|
||||
- 删除逻辑集群、共享集群、Region 概念
|
||||
|
||||
- Cluster 管理
|
||||
|
||||
- 增加集群概览信息、集群配置变更记录
|
||||
- 增加 Cluster 健康分，健康检查规则支持自定义配置
|
||||
- 增加 Cluster 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Cluster 层 I/O、Disk 的 Load Reblance 功能，支持定时均衡任务（企业版）
|
||||
- 删除限流、鉴权功能
|
||||
- 删除 APPID 概念
|
||||
|
||||
- Broker 管理
|
||||
|
||||
- 增加 Broker 健康分
|
||||
- 增加 Broker 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Broker 参数配置功能，需重启生效
|
||||
- 增加 Controller 变更记录
|
||||
- 增加 Broker Datalogs 记录
|
||||
- 删除 Leader Rebalance 功能
|
||||
- 删除 Broker 优先副本选举
|
||||
|
||||
- Topic 管理
|
||||
|
||||
- 增加 Topic 健康分
|
||||
- 增加 Topic 关键指标统计和 GUI 展示，支持自定义配置
|
||||
- 增加 Topic 参数配置功能，可实时生效
|
||||
- 增加 Topic 批量迁移、Topic 批量扩缩副本功能
|
||||
- 增加查看系统 Topic 功能
|
||||
- 优化 Partition 分布的 GUI 展示
|
||||
- 优化 Topic Message 数据采样
|
||||
- 删除 Topic 过期概念
|
||||
- 删除 Topic 申请配额功能
|
||||
|
||||
- Consumer 管理
|
||||
|
||||
- 优化了 ConsumerGroup 展示形式，增加 Consumer Lag 的 GUI 展示
|
||||
|
||||
- ACL 管理
|
||||
|
||||
- 增加原生 ACL GUI 配置功能，可配置生产、消费、自定义多种组合权限
|
||||
- 增加 KafkaUser 功能，可自定义新增 KafkaUser
|
||||
|
||||
- 消息测试（企业版）
|
||||
|
||||
- 增加生产者消息模拟器，支持 Data、Flow、Header、Options 自定义配置（企业版）
|
||||
- 增加消费者消息模拟器，支持 Data、Flow、Header、Options 自定义配置（企业版）
|
||||
|
||||
- Job
|
||||
|
||||
- 优化 Job 模块，支持任务进度管理
|
||||
|
||||
- 系统管理
|
||||
|
||||
- 优化用户、角色管理体系，支持自定义角色配置页面及操作权限
|
||||
- 优化审计日志信息
|
||||
- 删除多租户体系
|
||||
- 删除工单流程
|
||||
BIN
product/assets/KnowStreamingLogo.png
Normal file
BIN
product/assets/KnowStreamingLogo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
product/assets/connect_jmx_failed/check_jmx_opened.jpg
Normal file
BIN
product/assets/connect_jmx_failed/check_jmx_opened.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 382 KiB |
BIN
product/assets/multi_version_compatible/registerHandler.png
Normal file
BIN
product/assets/multi_version_compatible/registerHandler.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 600 KiB |
BIN
product/assets/startup_using_source_code/IDEA配置.jpg
Normal file
BIN
product/assets/startup_using_source_code/IDEA配置.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 228 KiB |
256
study-kafka/1-introduction.md
Normal file
256
study-kafka/1-introduction.md
Normal file
@@ -0,0 +1,256 @@
|
||||
---
|
||||
title: 1.Kafka新手入门
|
||||
order: 1
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 1.1 简介
|
||||
|
||||
<font size=5 ><b>什么是事件流？</b></font>
|
||||
|
||||
> 从技术上讲，事件流是从事件源（如数据库、传感器、移动设备、云服务和软件应用程序）以事件流的形式实时捕获数据的实践；持久存储这些事件流以供以后检索；实时和回顾性地操作、处理和响应事件流；并根据需要将事件流路由到不同的目标技术。因此，事件流确保了数据的连续流动和解释，以便正确的信息在正确的时间出现在正确的位置。
|
||||
|
||||
<font size=5 ><b> 我可以将事件流用于什么？ </b></font>
|
||||
|
||||
事件流应用于 众多行业和组织的各种场景。它的许多例子包括：
|
||||
|
||||
> - 实时处理支付和金融交易，例如在证券交易所、银行和保险中。
|
||||
> - 实时跟踪和监控汽车、卡车、车队和货运，例如在物流和汽车行业。
|
||||
> - 持续捕获和分析来自物联网设备或其他设备的传感器数据，例如工厂和风电场。
|
||||
> - 收集并立即响应客户互动和订单，例如零售、酒店和旅游行业以及移动应用程序。
|
||||
> - 监测住院病人，预测病情变化，确保在紧急情况下及时治疗。
|
||||
> - 连接、存储和提供公司不同部门产生的数据。
|
||||
> - 作为数据平台、事件驱动架构和微服务的基础。
|
||||
|
||||
<font size=5 ><b> Apache Kafka 是一个事件流平台 </b></font>
|
||||
|
||||
Kafka 结合了三个关键功能，因此您可以 通过一个经过实战考验的解决方案实现端到端的事件流
|
||||
|
||||
1. **发布**（写入）和**订阅**（读取）事件流，包括从其他系统持续导入/导出数据 。
|
||||
2. 根据需要持久可靠地 **存储事件流**。
|
||||
3. 在事件发生时或回顾性 地**处理事件流**。
|
||||
|
||||
所有这些功能都以分布式、高度可扩展、弹性、容错和安全的方式提供。Kafka 可以部署在裸机硬件、虚拟机和容器上，也可以部署在本地和云端。您可以在自行管理 Kafka 环境和使用各种供应商提供的完全托管服务之间进行选择。
|
||||
|
||||
<font size=5 ><b> Apache Kafka 整体架构 </b></font>
|
||||
|
||||
|
||||
|
||||
**Kafka 是一个分布式系统**，由通过高性能**TCP 网络协议进行通信**的 <font color=red>服务器</font>和 <font color=red>客户端</font>组成。它可以部署在本地和云环境中的裸机硬件、虚拟机和容器上。
|
||||
|
||||
**服务器：** Kafka 作为一个或多个服务器的集群运行，可以跨越多个数据中心或云区域。其中一些服务器形成存储层，称为代理(Broker)。其他服务器运行 Kafka Connect 以将数据作为事件流持续导入和导出，将 Kafka 与您现有的系统（如关系数据库以及其他 Kafka 集群）集成。为了让您实现关键任务用例，Kafka 集群具有高度可扩展性和容错性：如果其中任何一个服务器出现故障，其他服务器将接管它们的工作，以确保持续运行而不会丢失任何数据。
|
||||
|
||||
**客户端**：它们允许您编写分布式应用程序和微服务，以并行、大规模和容错方式读取、写入和处理事件流，即使在网络问题或机器故障的情况下也是如此。Kafka 附带了一些这样的客户端，这些客户端由 Kafka 社区提供的 数十个客户端进行了扩充：客户端可用于 Java 和 Scala，包括更高级别的 Kafka Streams 库，用于 Go、Python、C/C++ 和许多其他编程语言以及 REST API。
|
||||
|
||||
**主题分区与副本**
|
||||
|
||||
在 kafka 中有 2 个非常重要的概念, 主题（Topic）和分区（Partition）, Kafka 中的消息是以 Topic 为单位进行归类。
|
||||
|
||||
生产者发送消息的是必须指定消息 Topic, 消费组则订阅具体的 Topic 来消费。
|
||||
|
||||
**主题**（Topic）是逻辑上的概念, 它有一个或多个分区（Partition）, 消息就是存在这些具体的分区里面。
|
||||
|
||||
**分区**（Partition）其实也是一个逻辑上的概念, 每个主题会有一个/多个 **分区**, 我们生产的消息会追加到这些分区的 Log 文件里面, 同一个主题下的分区包含的消息是不同的。消息是以追加的形式存储在分区中。消息在被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)，offset 是消息在分区中的唯一标识。**Kafka 保证分区有序,并不保证主题消息有序。**
|
||||
|
||||
**副本**（Replica）是分区的物理实现, 一个分区可以有多个副本, 一个分区的多个副本分为 **Leader 副本**、**Follower 副本**, **Leader 副本**负责提供读写能力，**Follower 副本**会从**Leader 副本** 同步数据用于备份。
|
||||
|
||||
<font color=red><b>多分区解决了 I/O 性能瓶颈问题</b></font>
|
||||
<font color=red><b>多副本解决了高可用问题</b></font>
|
||||
|
||||
**主题与分区**
|
||||
|
||||
|
||||
|
||||
1. 在消息发送到 Broker 之前,会经过一定的 [分配策略]() 来选择存储到哪个具体的分区, 合理的分配方式能够尽量的让数据更均衡的分配在各个分区上。
|
||||
2. 同一个主题的多个分区可以分配在同一个 Brker 上。
|
||||
|
||||
**分区与副本**
|
||||
|
||||
|
||||
|
||||
看上面的图示, Topic1 有 3 个分区分别是 Topic1-0、 Topic1-1、 Topic1-2
|
||||
每个分区有 3 个副本(包括 Leader 副本), 均衡的分配在 3 个 Broker 中。
|
||||
|
||||
例如分区 **Topic-0** 的 Leader 副本在 Broker-0 上, 那么它承担着读写, Broker-1 和 Broker-2 上的 **Topic-0** Follower 副本会从 Broker-0 中的 Leader 副本去同步数据。
|
||||
|
||||
1. 同一个分区的多个副本不可以分配在同一个 Broker 上。
|
||||
2. 分区的 Leader 副本角色可以切换, 遵循[优先副本选举]()原则
|
||||
3. 只有 Leader 副本才会承担读写职责, Follower 副本用于同步备份
|
||||
|
||||
<font color=red><b>我们往往会在口述中把分区和副本给搞混, 一般默认情况下,我们说分区的时候潜台词说的是 Leader 副本, 说副本的时候实际上是 Follower 副本</b></font>
|
||||
|
||||
<font size=5 ><b> Kafka Api </b></font>
|
||||
|
||||
除了用于管理和任务的命令行工具外，Kafka 还为 Java 和 Scala 提供了五个核心 API：
|
||||
|
||||
- 用于管理和检查主题（Topic）、代理（Broker）和其他 Kafka 对象 的管理 API 。
|
||||
- 将事件流发布（写入）到一个或多个 Kafka 主题 的 Producer API 。
|
||||
- Consumer API 订阅（读取）一个或多个主题并处理向它们生成的事件流 。
|
||||
- 用于实现流处理应用程序和微服务 的 Kafka Streams API 。它提供了更高级别的函数来处理事件流，包括转换、聚合和连接等有状态操作、窗口化、基于事件时间的处理等等。从一个或多个主题读取输入以生成一个或多个主题的输出，有效地将输入流转换为输出流。
|
||||
- Kafka Connect API 用于构建和运行可重用 的数据导入/导出连接器，这些连接器从外部系统和应用程序消耗（读取）或生成（写入）事件流，以便它们可以与 Kafka 集成。例如，与 PostgreSQL 等关系数据库的连接器可能会捕获对一组表的每次更改。但是，在实践中，您通常不需要实现自己的连接器，因为 Kafka 社区已经提供了数百个即用型连接器。
|
||||
|
||||
## 1.2 使用场景
|
||||
|
||||
<font size=5 ><b> 消息队列 </b></font>
|
||||
|
||||
Kafka 可以很好的替代更传统的消息队列, 与大部分消息队列相比, Kafka 具有更好的吞吐量、内置的分区、复制和容错能力，这使其成为大规模消息处理应用程序的良好解决方案。
|
||||
|
||||
<font size=5 ><b> 网站活动跟踪 </b></font>
|
||||
|
||||
Kafka 的原始用例是能够将用户活动跟踪管道重建为一组实时发布-订阅源。这意味着站点活动（页面查看、搜索或用户可能采取的其他操作）将发布到中心主题，每种活动类型都有一个主题。这些订阅源可用于订阅一系列用例，包括实时处理、实时监控以及加载到 Hadoop 或离线数据仓库系统以进行离线处理和报告。
|
||||
活动跟踪的数量通常非常高，因为每个用户页面查看都会生成许多活动消息。
|
||||
|
||||
<font size=5 ><b> 指标 </b></font>
|
||||
|
||||
Kafka 常用于运营监控数据。这涉及聚合来自分布式应用程序的统计数据以生成操作数据的集中提要。
|
||||
|
||||
<font size=5 ><b> 日志聚合 </b></font>
|
||||
|
||||
许多人使用 Kafka 作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件，并将它们放在一个中心位置（可能是文件服务器或 HDFS）进行处理。Kafka 抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理和更容易支持多个数据源和分布式数据消费。与 Scribe 或 Flume 等以日志为中心的系统相比，Kafka 提供同样出色的性能、由于复制而产生的更强大的持久性保证以及更低的端到端延迟。
|
||||
|
||||
<font size=5 ><b> 流处理 </b></font>
|
||||
|
||||
许多 Kafka 用户在由多个阶段组成的处理管道中处理数据，其中原始输入数据从 Kafka 主题中消费，然后聚合、丰富或以其他方式转换为新主题以供进一步消费或后续处理。例如，用于推荐新闻文章的处理管道可能会从 RSS 提要中抓取文章内容并将其发布到“文章”主题；进一步的处理可能会对该内容进行规范化或去重，并将清理后的文章内容发布到新主题；最终处理阶段可能会尝试向用户推荐此内容。此类处理管道基于各个主题创建实时数据流图。从 0.10.0.0 开始，一个轻量级但功能强大的流处理库，称为 Kafka Streams 可以在 Apache Kafka 中执行上述数据处理。除了 Kafka Streams，替代的开源流处理工具包括 Apache Storm 和 Apache Samza。
|
||||
|
||||
<font size=5 ><b> 事件溯源 </b></font>
|
||||
|
||||
事件溯源是一种应用程序设计风格，其中状态更改被记录为按时间排序的记录序列。Kafka 对非常大的存储日志数据的支持使其成为以这种风格构建的应用程序的出色后端。
|
||||
|
||||
<font size=5 ><b> 提交日志 </b></font>
|
||||
|
||||
Kafka 可以作为分布式系统的一种外部提交日志。该日志有助于在节点之间复制数据，并充当故障节点恢复其数据的重新同步机制。Kafka 中的日志压缩功能有助于支持这种用法。在这种用法中，Kafka 类似于 Apache BookKeeper 项目。
|
||||
|
||||
## 1.3 快速入门
|
||||
|
||||
<font size=5 ><b> 第 1 步：获取 KAFKA </b></font>
|
||||
|
||||
选择并下载 [Kafka 安装包](https://kafka.apache.org/downloads), 并解压
|
||||
例如这里我下载 2.7 版本的
|
||||
|
||||
解压
|
||||
|
||||
```sh
|
||||
|
||||
tar -xzf kafka_2.13-2.7.0.tgz
|
||||
cd kafka_2.13-2.7.0
|
||||
```
|
||||
|
||||
<font size=5 ><b> 第 2 步：启动 KAFKA 环境 </b></font>
|
||||
|
||||
> 注意：您的本地环境必须安装 Java 8+。
|
||||
|
||||
运行以下命令以按正确顺序启动所有服务：
|
||||
|
||||
```sh
|
||||
|
||||
# Start the ZooKeeper service
|
||||
# Note: Soon, ZooKeeper will no longer be required by Apache Kafka.
|
||||
$ bin/zookeeper-server-start.sh config/zookeeper.properties
|
||||
|
||||
```
|
||||
|
||||
打开另一个终端会话并运行：
|
||||
|
||||
```sh
|
||||
# Start the Kafka broker service
|
||||
$ bin/kafka-server-start.sh config/server.properties
|
||||
```
|
||||
|
||||
成功启动所有服务后，您将拥有一个基本的 Kafka 环境运行并可以使用
|
||||
|
||||
<font size=5 ><b> 第 3 步：创建一个主题(Topic)来存储您的事件 </b></font>
|
||||
|
||||
Kafka 是一个分布式事件流平台，可让您跨多台机器 读取、写入、存储和处理 事件（在文档中也称为记录或 消息）。
|
||||
|
||||
在您编写第一个事件之前，您必须创建一个主题。打开另一个终端会话并运行：
|
||||
|
||||
```sh
|
||||
|
||||
$ bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092
|
||||
|
||||
```
|
||||
|
||||
查看一下该 Topic 的的详情
|
||||
|
||||
```sh
|
||||
|
||||
$ bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092
|
||||
|
||||
Topic:quickstart-events PartitionCount:1 ReplicationFactor:1 Configs:
|
||||
Topic: quickstart-events Partition: 0 Leader: 0 Replicas: 0 Isr: 0
|
||||
|
||||
|
||||
```
|
||||
|
||||
<font size=5 ><b> 第 4 步：将一些事件写入主题 </b></font>
|
||||
|
||||
Kafka 客户端通过网络与 Kafka Broker 通信以写入（或读取）事件。一旦收到，Broker 将以持久和容错的方式存储事件，只要您需要 - 甚至永远。
|
||||
|
||||
```sh
|
||||
$ bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092
|
||||
这是第一条消息
|
||||
这是第二条消息
|
||||
```
|
||||
|
||||
您可以随时停止生产者客户端 Ctrl-C。
|
||||
|
||||
<font size=5 ><b> 第 5 步：读取事件 </b></font>
|
||||
|
||||
打开另一个终端会话并运行控制台使用者客户端以读取您刚刚创建的事件：
|
||||
|
||||
```sh
|
||||
|
||||
$ bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092
|
||||
这是第一条消息
|
||||
这是第二条消息
|
||||
|
||||
```
|
||||
|
||||
您可以随时停止消费者客户端 Ctrl-C.
|
||||
|
||||
因为事件被持久地存储在 Kafka 中，所以它们可以被尽可能多的消费者多次读取。您可以通过打开另一个终端会话并再次重新运行上一个命令来轻松验证这一点。
|
||||
|
||||
<font size=5 ><b> 第 6 步：使用 KAFKA CONNECT 将数据作为事件流导入/导出 </b></font>
|
||||
|
||||
您可能在现有系统（如关系数据库或传统消息传递系统）中拥有大量数据，以及许多已经使用这些系统的应用程序。 Kafka Connect 允许您不断地将来自外部系统的数据摄取到 Kafka 中，反之亦然。因此很容易将现有系统与 Kafka 集成。为了使这个过程更容易，有数百个这样的连接器随时可用。
|
||||
|
||||
<font size=5 ><b> 第 7 步：使用 KAFKA STREAMS 处理您的事件 </b></font>
|
||||
|
||||
一旦您的数据作为事件存储在 Kafka 中，您就可以使用 Java/Scala 的 [Kafka Streams](https://kafka.apache.org/documentation/streams)客户端库处理数据。它允许您实现关键任务的实时应用程序和微服务，其中输入和/或输出数据存储在 Kafka 主题中。Kafka Streams 将在客户端编写和部署标准 Java 和 Scala 应用程序的简单性与 Kafka 的服务器端集群技术的优势相结合，使这些应用程序具有高度可扩展性、弹性、容错性和分布式性。该库支持一次性处理、有状态操作和聚合、窗口化、连接、基于事件时间的处理等等。
|
||||
|
||||
为了让您初步了解，以下是实现流行 WordCount 算法的方法：
|
||||
|
||||
```java
|
||||
KStream<String, String> textLines = builder.stream("quickstart-events");
|
||||
|
||||
KTable<String, Long> wordCounts = textLines
|
||||
.flatMapValues(line -> Arrays.asList(line.toLowerCase().split(" ")))
|
||||
.groupBy((keyIgnored, word) -> word)
|
||||
.count();
|
||||
|
||||
wordCounts.toStream().to("output-topic", Produced.with(Serdes.String(), Serdes.Long()));
|
||||
```
|
||||
|
||||
[Kafka Streams 演示](https://kafka.apache.org/25/documentation/streams/quickstart) 和[应用程序开发教程](https://kafka.apache.org/25/documentation/streams/tutorial) 演示了如何从头到尾编写和运行这样的流应用程序 。
|
||||
|
||||
<font size=5 ><b> 第 8 步：终止 KAFKA 环境 </b></font>
|
||||
|
||||
现在您已经完成了快速入门，请随意拆除 Kafka 环境，或者继续玩。
|
||||
|
||||
1. 停止生产者和消费组客户端
|
||||
2. 停止 Broker 按 Ctrl-C
|
||||
3. 最后，使用 Ctrl-C 停止 ZooKeeper 服务器
|
||||
|
||||
如果您还想删除本地 Kafka 环境的任何数据，包括您在此过程中创建的任何事件，请运行以下命令：
|
||||
|
||||
```sh
|
||||
|
||||
$ rm -rf /tmp/kafka-logs /tmp/zookeeper
|
||||
|
||||
```
|
||||
|
||||
**您已成功完成 Apache Kafka 快速入门。**
|
||||
|
||||
## 1.4 升级
|
||||
|
||||
该部分请查看 [从旧版本升级](https://kafka.apache.org/27/documentation.html#quickstart_kafkaterminate)
|
||||
85
study-kafka/2-api.md
Normal file
85
study-kafka/2-api.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: 2.Kafka官方API
|
||||
order: 2
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 2.1 Producer API
|
||||
|
||||
Producer API 允许应用程序将数据流发送到 Kafka 集群中的主题。
|
||||
|
||||
要使用生产者，您可以使用以下 maven 依赖项：
|
||||
|
||||
```mvn
|
||||
|
||||
<dependency>
|
||||
<groupId>org.apache.kafka</groupId>
|
||||
<artifactId>kafka-clients</artifactId>
|
||||
<version>2.7.2</version>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
## 2.2 Consumer API
|
||||
|
||||
Consumer API 允许应用程序从 Kafka 集群中的主题中读取数据流。
|
||||
|
||||
要使用消费者，您可以使用以下 maven 依赖项：
|
||||
|
||||
```mvn
|
||||
|
||||
<dependency>
|
||||
<groupId>org.apache.kafka</groupId>
|
||||
<artifactId>kafka-clients</artifactId>
|
||||
<version>2.7.2</version>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
## 2.3 Stream API
|
||||
|
||||
Consumer API 允许应用程序从 Kafka 集群中的主题中读取数据流。
|
||||
|
||||
要使用 Kafka Streams，您可以使用以下 maven 依赖项：
|
||||
|
||||
```mvn
|
||||
|
||||
<dependency>
|
||||
<groupId>org.apache.kafka</groupId>
|
||||
<artifactId>kafka-streams</artifactId>
|
||||
<version>2.7.2</version>
|
||||
</dependency>
|
||||
|
||||
```
|
||||
|
||||
使用 Scala 时，您可以选择包含该 kafka-streams-scala 库。开发人员指南中提供了有关使用 Kafka Streams DSL for Scala 的其他文档。
|
||||
|
||||
要使用 Kafka Streams DSL for Scala for Scala 2.13，您可以使用以下 maven 依赖项：
|
||||
|
||||
```mvn
|
||||
|
||||
<dependency>
|
||||
<groupId>org.apache.kafka</groupId>
|
||||
<artifactId>kafka-streams-scala_2.13</artifactId>
|
||||
<version>2.7.2</version>
|
||||
</dependency>
|
||||
|
||||
```
|
||||
|
||||
## 2.4 Connect API
|
||||
|
||||
Connect API 允许实现连接器，这些连接器不断地从某个源数据系统拉入 Kafka 或从 Kafka 推送到某个接收器数据系统。
|
||||
许多 Connect 用户不需要直接使用此 API，但他们可以使用预构建的连接器，而无需编写任何代码。此处提供有关使用 Connect 的更多信息。
|
||||
|
||||
## 2.5 Admin API
|
||||
|
||||
Admin API 支持管理和检查主题、代理、acls 和其他 Kafka 对象。
|
||||
要使用 Admin API，请添加以下 Maven 依赖项：
|
||||
|
||||
```mvn
|
||||
|
||||
<dependency>
|
||||
<groupId>org.apache.kafka</groupId>
|
||||
<artifactId>kafka-clients</artifactId>
|
||||
<version>2.7.2</version>
|
||||
</dependency>
|
||||
|
||||
```
|
||||
463
study-kafka/3-config.md
Normal file
463
study-kafka/3-config.md
Normal file
@@ -0,0 +1,463 @@
|
||||
---
|
||||
title: 3.Kafka参数配置
|
||||
order: 3
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 3.1 Broker 配置
|
||||
|
||||
基本配置如下：
|
||||
|
||||
| 参数 | 描述 | 默认 |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
|
||||
| broker.id | broker server 的唯一标识,必须唯一, 如果不设置,或者`broker.id`<0 则会自动计算`broker.id`; 相关可以看`broker.id.generation.enable`和 `reserved.broker.max.id` 的配置。 | -1 |
|
||||
| reserved.broker.max.id | `broker.id`能够配置的最大值,同时 `reserved.broker.max.id+1`也是自动创建`broker.id`的最小值。 | 1000 |
|
||||
| broker.id.generation.enable | 允许 server 自动创建`broker.id`。当`broker.id`< 0 并且当前配置是 true,则自动计算`broker.id`，计算逻辑是` {reserved.broker.max.id} +/brokers/seqid.dataVersion` , 其中的`/brokers/seqid.dataVersion`保证了全局自增 | true |
|
||||
| log.dir | log 数据存放的目录 | /tmp/kafka-logs |
|
||||
| log.dirs | Log 数据存放的目录,比如`/tmp/kafka-logs`. 这个可以用逗号隔开设置多个目录,主要是用来挂载到多个磁盘上的<br>例如:`/tmp/kafka0,/tmp/kafka1` 。如果没有设置,则使用 `log.dir`的配置 | null |
|
||||
| zookeeper.connect | 以`hostname:port`形式指定 ZooKeeper 连接字符串 <br> 也可以用逗号形式指定多个 Zookeeper; 例如：`hostname1:port1,hostname2:port2,hostname3:port3 ` <br> 。如果你的 kafka 数据放在 Zookeeper 的某个路径下,也可以指定对应的路径，例如指定 kafka 数据存放到 Zookeeper 全局命名空间的 /szzkafka 下。那么你可以指定 ` hostname:port/szzkafka` | |
|
||||
| advertised.listeners | 对外发布的监听器列表,这个配置会存放在 Zookeeper 中,其他 Broker/客户端可以通过元数据拿到这个监听器列表,从而可以对该 Broker 进行访问。如果这个为空,则默认用 listeners 的配置数据. 简单理解：你可能有多个监听器列表,但是你只想告诉其他客户端你只有某一个/多个监听器列表,其他客户端只能通过其发布的监听器列表该 Broker 进行访问 | null |
|
||||
| listeners | 监听器列表,这个配置的监听器将被用于监听网络请求。简单理解就是你建立监听一个通道,别人能够通过这个通道跟你沟通。 | null |
|
||||
| auto.create.topics.enable | 是否能够自动创建 Topic。当生产者向一个未知 Topic 发送消息,或者消费者从未知 Topic 的时候会自动创建 Topic。创建的时候是按照`num.partitions`和`default.replication.factor` 的配置进行 | true |
|
||||
| auto.leader.rebalance.enable | 是否开始自动 Leader 再均衡的功能,具体看扩展讲解的**Leader 均衡机制** | true |
|
||||
| leader.imbalance.check.interval.seconds | Controller 触发 Leader 再均衡的频率,默认 300S 一次。具体看扩展讲解的**Leader 均衡机制** | 300 |
|
||||
| leader.imbalance.per.broker.percentage | 标识每个 Broker 失去平衡的比率，如果超过改比率，则执行重新选举 Broker 的 leader；默认比例是 10%; 具体看扩展讲解的**Leader 均衡机制** | 10 |
|
||||
| background.threads | 用于各种后台处理任务的线程数，例如过期消息文件的删除等 | 10 |
|
||||
| compression.type | 消息的压缩类型, Kafka 支持的类型有（'gzip'、'snappy'、'lz4'、'zstd'）, 当然还可以设置`uncompressed` 表示不启用压缩, 这里 默认是 `producer` 表示继承使用 `producer`端的压缩类型。具体请看 **压缩类型讲解** | producer |
|
||||
| control.plane.listener.name | Controller 与 Broker 之间的通信监听器名称, 默认为空,则 Controller 的请求与 Broker 请求都是使用同一个监听器,但是一般 Controller 的请求需要优先级更高一点,则需要单独给 Controller 配置网络请求模块,那么 Controller 的请求就不会被其他请求给影响 | null |
|
||||
| delete.topic.enable | 是否允许删除 Topic。 | true |
|
||||
| log.flush.interval.messages | 在消息刷新到磁盘之前在日志分区上累积的消息数 | Long.MaxValue |
|
||||
| log.flush.scheduler.interval.ms | 定时检查是否有任何日志需要刷新到磁盘的频率(毫秒单位),该值通常搭配`log.flush.interval.ms` | Long.MaxValue |
|
||||
| log.flush.interval.ms | 任何 Topic 中的消息在刷新到磁盘之前保留在内存中的最长时间（以毫秒为单位）。如果未设置，则使用 `log.flush.scheduler.interval.ms` 中的值, 但是需要注意的是,如果没有设置`log.flush.scheduler.interval.ms` 那么这个值也是不会生效的。因为都没有去定时检查。 | null |
|
||||
| log.flush.start.offset.checkpoint.interval.ms | 有个名称为"kafka-log-start-offset-checkpoint"的定时任务去更新日志起始偏移量日志文件,这个配置就是更新的频率,被更新的文件是每个`log.dirs`中目录下的`log-start-offset-checkpoint` | 60000 |
|
||||
| log.retention.bytes | 日志文件的最大保留大小。分区级别的 | -1 |
|
||||
| log.retention.hours | 日志保存的最大时间(单位小时),默认 7 天。优先级 `log.retention.ms` > `log.retention.minutes`>`log.retention.hours` | 168 |
|
||||
| log.retention.minutes | 日志保存的最大时间(单位分钟), 优先级 `log.retention.ms` > `log.retention.minutes`>`log.retention.hours` | null |
|
||||
| log.retention.ms | 日志保存的最大时间(单位毫秒),优先级 `log.retention.ms` > `log.retention.minutes`>`log.retention.hours`. | null |
|
||||
| log.roll.hours | 创建新日志段之前的最长时间（以小时为单位）,默认 7 天, 意思是如果 7 天没有创建新的 Segment,则强制创建新的 Segment 用于存储 Log 数据，优先级 次于 log.roll.ms 属性; 日志段的切分请看 **日志段切分条件详解** | 168 |
|
||||
| log.roll.ms | 同`log.roll.hours`，只是单位是毫秒,优先级大于`log.roll.hours` ，详情请看下面**日志段切分条件详解** | null |
|
||||
| log.segment.bytes | 单个日志段最大值,超过这个值就创建新的日志段，详情请看下面 **日志段切分条件详解** | 1073741824(1G) |
|
||||
| log.segment.delete.delay.ms | 执行删除操作,Log 文件夹会先被标记为`-delete`后缀,这个配置就是设置被标记为`-delete`之后延迟多长时间去真正的从磁盘中删除该文件 | 60000 |
|
||||
| message.max.bytes | Kafka 允许的最大记录批量大小（如果启用压缩，则在压缩之后）,如果增加此值并且存在早于 0.10.2 的消费者，则消费者的获取大小也必须增加，以便他们可以获取如此大的记录批次。在最新的消息格式版本中，为了提高效率，记录总是被分组。在以前的消息格式版本中，未压缩的记录不会分组到批处理中，并且此限制仅适用于这种情况下的单个记录。这可以使用主题级别`max.message.bytes`配置为每个主题设置。 | 1048588(约 1M) |
|
||||
| min.insync.replicas | 和生产者的配置`acks=all`配套使用, 表示最小有多少个副本数据同步成功,它的判断条件是 `min.insync.replicas<= 当前副本ISR的数量` 才可以，否则会抛出异常,更详细的请看下面 **min.insync.replicas 详解** | 1 |
|
||||
| num.io.threads | 服务器用于处理请求的线程数，可能包括磁盘 I/O | 8 |
|
||||
| num.network.threads | 服务器用于从网络接收请求并向网络发送响应的线程数 | 3 |
|
||||
| num.recovery.threads.per.data.dir | 每个数据目录（数据目录即指的是上述 log.dirs 配置的目录路径）用于日志恢复启动和关闭时的线程数量，注意，这个参数指的是每个日志目录的线程数，比如如果该参数设置为 8，而 log.dirs 设置为了三个路径（多个路径由","分隔），则总共会启动 24 个线程来处理 | 1 |
|
||||
| num.replica.alter.log.dirs.threads | 可以在日志目录之间移动(跨目录迁移)副本的线程数，其中可能包括磁盘 I/O | null |
|
||||
| num.replica.fetchers | 每个 follower 从 leader 拉取消息进行同步数据时候的拉取线程数,数字大,可以提提高 follower 的 I/O 并发度,单位时间内 leader 持有更多的请求,同时 leader 的负载也会增大 | 1 |
|
||||
| offset.metadata.max.bytes | 与偏移提交相关联的元数据的最大数据量 | 4096(4kb) |
|
||||
| offsets.commit.required.acks | 偏移量相关数据的 ack 设置,0、1、-1 为可选项,默认为-1，不建议你去修改此值 | -1 |
|
||||
| offsets.commit.timeout.ms | 偏移量提交将被延迟，直到偏移量主题的所有副本都收到提交或达到此超时。这类似于生产者请求超时 | 5000 |
|
||||
| offsets.load.buffer.size | 将偏移量加载到缓存中时从偏移量段读取的批量大小（软限制，如果记录太大则覆盖） | 5242880 |
|
||||
| offsets.retention.check.interval.ms | 检查陈旧偏移的频率 | 600000(10 分钟) |
|
||||
| offsets.retention.minutes | 在消费者组失去其所有消费者（即变空）后，其偏移量将在此保留期内保留，然后再被丢弃。对于独立消费者（使用手动分配），偏移量将在上次提交时间加上此保留期后过期 | 10080（7 天） |
|
||||
| offsets.topic.compression.codec | 偏移 Topic `__consumer_offsets` 的压缩编解码器 - 压缩可用于实现“原子”提交,默认是 0; 对应的压缩 k-v 映射关系为{ 0:NONE、1:GZIP、2:SNAPPY、3:LZ4、4: ZSTD} | 0 |
|
||||
| offsets.topic.num.partitions | 偏移 Topic `__consumer_offsets` 的分区数（部署后不应更改） | 50 |
|
||||
| offsets.topic.replication.factor | 偏移 Topic `__consumer_offsets` 的副本数量（设置得更高以确保可用性）。在集群大小满足此复制因子要求之前，内部主题创建将失败。详细请看下面 **`__consumer_offsets` 详解** | 3 |
|
||||
| offsets.topic.segment.bytes | `__consumer_offsets`主题每个 Segment 的字节应该保持相对较小，以促进更快的日志压缩和缓存加载 | 104857600（100M） |
|
||||
| queued.max.requests | 在阻塞网络线程之前允许数据平面的排队请求数 | 500 |
|
||||
| replica.fetch.min.bytes | 每个 fetch 请求响应所需的最小字节数。如果没有足够的字节，则等待 replicaMaxWaitTimeMs | 1 |
|
||||
| replica.fetch.wait.max.ms | Follower 副本发出的每个 fetcher 请求的最大等待时间。该值应始终小于`replica.lag.time.max.ms `以防止频繁收缩低吞吐量主题的 ISR | 500 |
|
||||
| replica.high.watermark.checkpoint.interval.ms | 每个 replica 将最高水位进行 flush 的时间间隔 | 5000 |
|
||||
| replica.lag.time.max.ms | 如果一个 follower 在这个时间内没有发送 fetch 请求，leader 将从 ISR 重移除这个 follow | 30000 |
|
||||
| replica.socket.receive.buffer.bytes | 同步时向 leader 发送网络请求时的 socket receive buffer | 65536 |
|
||||
| replica.socket.timeout.ms | 副本同步时候网络请求的超时时间,这个值要大于`replica.fetch.wait.max.ms` | 30000 |
|
||||
| request.timeout.ms | 这个配置控制着客户端等待请求响应的最长时间。如果在超时之前没有收到响应，客户端将在必要时重新发送请求，或者如果重试用尽，则请求失败 | 30000 |
|
||||
| socket.receive.buffer.bytes | 套接字服务器套接字的 SO_RCVBUF 缓冲区。如果值为 -1，则将使用操作系统默认值。 | 102400（100kb） |
|
||||
| socket.request.max.bytes | 套接字请求中的最大字节数 | 104857600(100M) |
|
||||
| socket.send.buffer.bytes | 套接字服务器套接字的 SO_SNDBUF 缓冲区。如果值为 -1，则将使用操作系统默认值 | 102400 |
|
||||
| transaction.max.timeout.ms | 事务的最大允许超时时间。如果客户端请求的事务时间超过此时间，则代理将在 InitProducerIdRequest 中返回错误。这可以防止客户端超时过大，这可能会阻止消费者从事务中包含的主题中读取。 | 900000 |
|
||||
| transaction.state.log.load.buffer.size | 将生产者 ID 和事务加载到缓存中时从事务日志段读取的批量大小（软限制，如果记录太大则覆盖） | 5242880 |
|
||||
| transaction.state.log.min.isr | 跟`min.insync.replicas`一样,但是事务主题` __transaction_state`有自己的配置,他会覆盖`min.insync.replicas`的配置 | 2 |
|
||||
| transaction.state.log.num.partitions | 事务主题` __transaction_state`的分区数量配置(部署后不应更改) | 50 |
|
||||
| transaction.state.log.replication.factor | 事务主题的副本数量（设置得更高以确保可用性）。在集群大小满足此复制因子要求之前，内部主题创建将失败。 | 3 |
|
||||
| transaction.state.log.segment.bytes | 事务主题` __transaction_state` 的 Segment 段字节应该保持相对较小，以促进更快的日志压缩和缓存加载 | 104857600（100M） |
|
||||
| transactional.id.expiration.ms | 事务协调器在其事务 id 到期之前等待而不接收当前事务的任何事务状态更新的时间（以毫秒为单位）。此设置还会影响生产者 ID 到期 - 在使用给定生产者 ID 的最后一次写入之后，一旦过了此时间，生产者 ID 就会过期。请注意，如果由于主题的保留设置而删除了生产者 ID 的最后一次写入，生产者 ID 可能会更快过期 | 604800000（7 天） |
|
||||
| unclean.leader.election.enable | 如果开启了这个,当 ISR 列表中没有数据的时候,那么将会从不在 ISR 的副本中选择为 Leader,当然这样子可能会导致数据丢失 | false |
|
||||
| zookeeper.connection.timeout.ms | 客户端等待与 zookeeper 建立连接的最长时间。如果未设置，则使用` zookeeper.session.timeout.ms` 中的值 | null |
|
||||
| zookeeper.max.in.flight.requests | 客户端在阻塞之前将发送给 Zookeeper 的最大未确认请求数。 | 10 |
|
||||
| zookeeper.session.timeout.ms | Zookeeper 会话超时 | 18000 |
|
||||
| zookeeper.set.acl | 将客户端设置为使用安全 ACL | false |
|
||||
| broker.rack | broker 的机架配置信息,在进行副本分配的时候会判断是否有机架信息,选择不同的分配策略,以实现容错。 | null |
|
||||
| connection.max.idle.ms | 空闲连接超时：服务器套接字处理器线程关闭空闲超过此时间的连接 | 600000 |
|
||||
| connection.max.reauth.ms | 当明确设置为正数（默认为 0，不是正数）时，不会超过配置值的会话生存期将在 v2.2.0 或更高版本的客户端进行身份验证时进行通信。代理将断开在会话生命周期内未重新验证的任何此类连接，然后将其用于除重新验证之外的任何目的。配置名称可以选择以小写的侦听器前缀和 SASL 机制名称作为前缀。例如，listener.name.sasl_ssl.oauthbearer.connections.max.reauth.ms=3600000 | 0 |
|
||||
| controlled.shutdown.enable | 当该值为 true, 然后当 Broker 关闭的时候, 会向 Controller 发一起一个`ControlledShutdownRequest`请求, Controller 收到这个请求会针对性的做一些善后事件。比如说 **执行 Leader 重选举** 等等之类的 。如果改值为 false，则不会有善后请求事件 | true |
|
||||
| controlled.shutdown.max.retries | Broker 关闭的时候会通知 Controller 执行一个受控关闭的操作，这个操作可能由于多种原因而失败。这决定了发生此类故障时的重试次数 | 3 |
|
||||
| controlled.shutdown.retry.backoff.ms | 在每次重试之前，系统需要时间从导致上一次故障（控制器故障转移、副本滞后等）的状态中恢复。此配置确定重试前等待的时间。 | 5000 |
|
||||
| controller.socket.timeout.ms | 控制器 Controller 到 broker 通道的套接字超时时间 | 30000 |
|
||||
| default.replication.factor | 创建主题的默认副本因子 | 1 |
|
||||
| delegation.token.expiry.time.ms | 令牌需要更新之前的令牌有效期（以毫秒为单位）。默认值 1 天。 | 86400000 |
|
||||
| delegation.token.master.key | 生成和验证委托令牌的主/秘密密钥。必须在所有代理上配置相同的密钥。如果密钥未设置或设置为空字符串，broker 将禁用委托令牌支持。 | null |
|
||||
| delegation.token.max.lifetime.ms | 令牌有一个最长生命周期，超过这个生命周期就不能再更新了。默认值 7 天。 | 604800000 |
|
||||
| delete.records.purgatory.purge.interval.requests | 删除记录请求炼狱的清除间隔（以请求数计） | 1 |
|
||||
| fetch.max.bytes | Fetch 请求返回的最大字节数。必须至少为 1024。 | 57671680(55M) |
|
||||
| fetch.purgatory.purge.interval.requests | 提取请求炼狱的清除间隔（以请求数计） | 1000 |
|
||||
| group.initial.rebalance.delay.ms | 在执行第一次重新平衡之前，组协调器将等待更多消费者加入新组的时间。更长的延迟意味着可能更少的重新平衡，但会增加处理开始之前的时间。 | 3000 |
|
||||
| group.max.session.timeout.ms | 注册消费者的最大允许会话超时。更长的超时时间让消费者有更多的时间在心跳之间处理消息，但代价是检测故障的时间更长。 | 1800000 |
|
||||
| group.max.size | 单个消费组可以容纳的最大消费者数。 | 2147483647 |
|
||||
| group.min.session.timeout.ms | 注册上的消费者的最小允许会话超时。更短的超时导致更快的故障检测，代价是更频繁的消费者心跳，这可能会淹没代理资源。 | 6000 |
|
||||
| inter.broker.listener.name | 用于代理之间通信的侦听器名称。如果未设置，则侦听器名称由 security.inter.broker.protocol 定义。同时设置 这个 和 security.inter.broker.protocol 属性是错误的。 | null |
|
||||
| inter.broker.protocol.version | 指定将使用哪个版本的代理间协议。在所有代理升级到新版本后，这通常会受到影响。可选的所有版本: [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2 -IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 2.0-IV0, 2.0-IV1, 2.1-IV0, 2.1-IV1, 2.1-IV2, 2.2 -IV0、2.2-IV1、2.3-IV0、2.3-IV1、2.4-IV0、2.4-IV1、2.5-IV0] | 根据 kafka 版本会有不同的默认值,例如 2.5-IV0 |
|
||||
| log.cleaner.backoff.ms | 没有要清理的日志时的睡眠时间 | 15000 |
|
||||
| log.cleaner.dedupe.buffer.size | | 134217728(128M) |
|
||||
| log.cleaner.delete.retention.ms | | 86400000（24 小时） |
|
||||
| log.cleaner.enable | 是否开启日志情侣进程, 特殊是如果使用带有 cleanup.policy=compact 的任何主题，包括内部偏移主题，则应启用。如果禁用，这些主题将不会被压缩并不断增长 | true |
|
||||
| log.cleaner.io.buffer.load.factor | | 0.9 |
|
||||
| log.cleaner.io.buffer.size | 所有清理线程中用于日志清理 I/O 缓冲区的总内存 | 524288 |
|
||||
| log.cleaner.io.max.bytes.per.second | 日志清理器将受到限制，以便其读写 I/O 的总和平均小于此值 | 1.7976931348623157E308 |
|
||||
| log.cleaner.max.compaction.lag.ms | 消息在日志中不符合压缩条件的最长时间。仅适用于正在压缩的日志。 | 9223372036854775807（Long.MaxValue） |
|
||||
| log.cleaner.min.cleanable.ratio | 对于符合清理条件的日志，脏日志与总日志的最小比率。如果还指定了 `log.cleaner.max.compaction.lag.ms` 或 `log.cleaner.min.compaction.lag.ms `配置，则日志压缩器会在以下任一情况下认为该日志符合压缩条件：（i）已达到脏比率阈值并且日志至少在 `log.cleaner.min.compaction.lag.ms` 持续时间内有脏（未压缩）记录，或者（ii）如果日志最多有脏（未压缩）记录`log.cleaner.max.compaction.lag.ms `周期 | 0.5 |
|
||||
| log.cleaner.min.compaction.lag.ms | 消息在日志中保持未压缩的最短时间。仅适用于正在压缩的日志。 | 0 |
|
||||
| log.cleaner.threads | 用于日志清理的后台线程数 | 1 |
|
||||
| log.cleanup.policy | 日志清理策略, delete 表示删除过期日志,还有一个 compact 选项表示压缩日志。 | delete |
|
||||
| log.index.interval.bytes | 每隔多少个字节的消息量写入就条件一条索引。 | 4096 |
|
||||
| log.index.size.max.bytes | 索引文件最大值 | 10485760（10M） |
|
||||
| log.message.format.version | 消息格式的版本； [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2 -IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 2.0-IV0, 2.0-IV1, 2.1-IV0, 2.1-IV1, 2.1-IV2, 2.2 -IV0、2.2-IV1、2.3-IV0、2.3-IV1、2.4-IV0、2.4-IV1、2.5-IV0] | |
|
||||
| log.message.timestamp.difference.max.ms | 代理接收消息时的时间戳与消息中指定的时间戳之间允许的最大差异。如果` log.message.timestamp.type=CreateTime`，则如果时间戳差异超过此阈值，则消息将被拒绝。如果 `log.message.timestamp.type=LogAppendTime `则忽略此配置。允许的最大时间戳差异不应大于`log.retention.ms`以避免不必要的频繁日志滚动 | 9223372036854775807（Logn.MaxValue） |
|
||||
| log.message.timestamp.type | 可定义消息中的时间戳是消息创建时间还是日志附加时间。该值应该是 CreateTime 或 LogAppendTime | CreateTime |
|
||||
| log.preallocate | 创建新段时应该预先分配文件吗？如果您在 Windows 上使用 Kafka，则可能需要将其设置为 true。 | false |
|
||||
| log.retention.check.interval.ms | 日志清理器检查任何日志是否符合删除条件的频率（以毫秒为单位） | 300000（5 分钟） |
|
||||
| max.connections | 我们在任何时候允许的最大连接数。除了使用 max.connections.per.ip 配置的任何 per-ip 限制之外，还应用此限制。侦听器级别的限制也可以通过在配置名称前加上侦听器前缀来配置，例如，listener.name.internal.max.connections。应根据代理容量配置代理范围限制，而应根据应用程序要求配置侦听器限制。如果达到侦听器或代理限制，则新连接将被阻止。即使达到代理范围的限制，也允许代理间侦听器上的连接。在这种情况下，另一个侦听器上最近最少使用的连接将被关闭。 | 2147483647(Integer.MaxValue) |
|
||||
| max.connections.per.ip | 我们允许来自每个 IP 地址的最大连接数。如果使用 max.connections.per.ip.overrides 属性配置了覆盖，则可以将其设置为 0。如果达到限制，来自 IP 地址的新连接将被丢弃。 | 2147483647(Integer.MaxValue) |
|
||||
| max.connections.per.ip.overrides | 以逗号分隔的 per-ip 或主机名列表覆盖默认的最大连接数。示例值为“hostName:100,127.0.0.1:200” | “” |
|
||||
| max.incremental.fetch.session.cache.slots | 维护的最大增量 fetch 会话数。 | 1000 |
|
||||
| num.partitions | 创建 topic 时候的默认分区数 | 1 |
|
||||
| password.encoder.old.secret | 用于对动态配置的密码进行编码的旧秘密。只有在更新密码时才需要这样做。如果指定，则当代理启动时，所有动态编码的密码将使用此旧密码解码，并使用 password.encoder.secret 重新编码。(就是你要换密码总得先用老的密码解密再用新密码进行加密呢) | null |
|
||||
| password.encoder.secret | 动态配置编码的秘钥 | null |
|
||||
| principal.builder.class | 实现 KafkaPrincipalBuilder 接口的类的完全限定名称，用于构建授权期间使用的 KafkaPrincipal 对象。此配置还支持已弃用的 PrincipalBuilder 接口，该接口以前用于通过 SSL 进行客户端身份验证。如果未定义主体构建器，则默认行为取决于使用的安全协议。对于 SSL 身份验证，ssl.principal.mapping.rules 如果提供了客户端证书，将使用应用在客户端证书的专有名称上定义的规则派生主体；否则，如果不需要客户端身份验证，则主体名称将为 ANONYMOUS。对于 SASL 身份验证，将使用定义的规则派生主体 sasl.kerberos.principal.to.local.rules 如果正在使用 GSSAPI，以及其他机制的 SASL 身份验证 ID。对于 PLAINTEXT，委托人将是匿名的 | null |
|
||||
| producer.purgatory.purge.interval.requests | | 1000 |
|
||||
| queued.max.request.bytes | 在不再读取请求之前允许的排队字节数 | -1 |
|
||||
| replica.fetch.backoff.ms | 当发生 fetch 分区的时候 休眠的时间长度 | 1000 |
|
||||
| replica.fetch.max.bytes | 尝试为每个分区获取的消息字节数。这不是绝对最大值，如果 fetch 的第一个非空分区中的第一个记录批次大于此值，则仍然会返回该记录批次以确保可以取得进展。代理接受的最大记录批量大小是通过 message.max.bytes(broker config) 或 max.message.bytes(topic config) 定义的。 | 1048576 |
|
||||
| replica.fetch.response.max.bytes | 整个 Fetch 响应预期的最大字节数。记录是分批获取的，如果获取的第一个非空分区中的第一个记录批次大于该值，则仍然会返回该记录批次以确保可以取得进展。因此，这不是绝对最大值。代理接受的最大记录批量大小是通过 message.max.bytes(broker config) 或 max.message.bytes(topic config) 定义的。 | 10485760 |
|
||||
| replica.selector.class | 实现 ReplicaSelector 的完全限定类名。broker 使用它来查找首选只读副本。默认情况下，我们使用返回 leader 的实现方式。 | null |
|
||||
| sasl.client.callback.handler.class | | 实现 AuthenticateCallbackHandler 接口的 SASL 客户端回调处理程序类的完全限定名称 |
|
||||
| sasl.enabled.mechanisms | Kafka 服务器中启用的 SASL 机制列表。该列表可能包含安全提供者可用的任何机制。默认情况下仅启用 GSSAPI。 | GSSAPI |
|
||||
| sasl.jaas.config | SASL 连接的 JAAS 登录上下文参数，采用 JAAS 配置文件使用的格式。此处描述了 JAAS 配置文件格式。该值的格式为：’ loginModuleClass controlFlag (optionName=optionValue)\*;'。对于代理，配置必须以侦听器前缀和小写的 SASL 机制名称作为前缀。例如，listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule 需要； | null |
|
||||
| sasl.kerberos.kinit.cmd | Kerberos kinit 命令路径。 | /usr/bin/kinit |
|
||||
| sasl.kerberos.min.time.before.relogin | 刷新尝试之间的登录线程休眠时间。 | 60000 |
|
||||
| sasl.kerberos.principal.to.local.rules | 从主体名称到短名称（通常是操作系统用户名）的映射规则列表。规则按顺序评估，与主体名称匹配的第一个规则用于将其映射到短名称。列表中任何后面的规则都将被忽略。默认情况下，{username}/{hostname}@{REALM} 形式的主体名称映射到 {username}。有关格式的更多详细信息，请参阅安全授权和 acls。请注意，如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的扩展，则此配置将被忽略。 | null |
|
||||
| sasl.kerberos.service.name | Kafka 运行时使用的 Kerberos 主体名称。这可以在 Kafka 的 JAAS 配置或 Kafka 的配置中定义。 | null |
|
||||
| sasl.kerberos.ticket.renew.jitter | 添加到更新时间的随机抖动百分比。 | 0.05 |
|
||||
| sasl.kerberos.ticket.renew.window.factor | 登录线程将休眠，直到达到从上次刷新到票证到期的指定时间窗口因子，此时它将尝试更新票证。 | 0.8 |
|
||||
| sasl.login.callback.handler.class | 实现 AuthenticateCallbackHandler 接口的 SASL 登录回调处理程序类的完全限定名称。对于代理，登录回调处理程序配置必须以侦听器前缀和小写的 SASL 机制名称作为前缀。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler | null |
|
||||
| sasl.login.class | 实现 Login 接口的类的完全限定名称。对于代理，登录配置必须以侦听器前缀和小写的 SASL 机制名称作为前缀。例如，listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin | null |
|
||||
| sasl.login.refresh.buffer.seconds | 刷新凭证时在凭证到期之前保持的缓冲时间，以秒为单位。如果刷新将在比缓冲秒数更接近到期时发生，则刷新将向上移动以保持尽可能多的缓冲时间。合法值介于 0 到 3600（1 小时）之间；如果未指定值，则使用默认值 300（5 分钟）。如果此值和 sasl.login.refresh.min.period.seconds 的总和超过凭证的剩余生命周期，则它们都将被忽略。目前仅适用于 OAUTHBEARER。 | 300 |
|
||||
| sasl.login.refresh.min.period.seconds | 在刷新凭据之前登录刷新线程所需的最短等待时间，以秒为单位。合法值介于 0 到 900（15 分钟）之间；如果未指定值，则使用默认值 60（1 分钟）。如果此值和 sasl.login.refresh.buffer.seconds 的总和超过凭证的剩余生命周期，则它们都将被忽略。目前仅适用于 OAUTHBEARER。 | 60 |
|
||||
| sasl.login.refresh.window.factor | 登录刷新线程将休眠，直到达到与凭证生命周期相关的指定窗口因子，此时它将尝试刷新凭证。合法值介于 0.5 (50%) 和 1.0 (100%) 之间；如果未指定值，则使用默认值 0.8 (80%)。目前仅适用于 OAUTHBEARER。 | 0.8 |
|
||||
| sasl.login.refresh.window.jitter | 添加到登录刷新线程的睡眠时间的相对于凭证生命周期的最大随机抖动量。合法值介于 0 和 0.25 (25%) 之间；如果未指定值，则使用默认值 0.05 (5%)。目前仅适用于 OAUTHBEARER | 0.05 |
|
||||
| sasl.mechanism.inter.broker.protocol | SASL 机制用于代理间通信。默认为 GSSAPI。 | GSSAPI |
|
||||
| sasl.server.callback.handler.class | 实现 AuthenticateCallbackHandler 接口的 SASL 服务器回调处理程序类的完全限定名称。服务器回调处理程序必须以侦听器前缀和小写的 SASL 机制名称作为前缀。例如，listener.name.sasl_ssl.plain.sasl.server.callback.handler.class=com.example.CustomPlainCallbackH | null |
|
||||
| security.inter.broker.protocol | 用于代理之间通信的安全协议。有效值为：PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL。不能同时设置 这个和 inter.broker.listener.name 属性。 | PLAINTEXT |
|
||||
| ssl.cipher.suites | 密码套件列表。这是身份验证、加密、MAC 和密钥交换算法的命名组合，用于协商使用 TLS 或 SSL 网络协议的网络连接的安全设置。默认情况下，支持所有可用的密码套件。 | |
|
||||
| ssl.client.auth | 配置 kafka 代理以请求客户端身份验证。以下设置是常见的：ssl.client.auth=required 如果设置为 required 则需要客户端身份验证。ssl.client.auth=requested 这意味着客户端身份验证是可选的。与请求不同，如果设置了此选项，客户端可以选择不提供有关自身的身份验证信息 ssl.client.auth=none 这意味着不需要客户端身份验证。 | none |
|
||||
| ssl.enabled.protocols | 为 SSL 连接启用的协议列表。 | TLSv1.2 |
|
||||
| ssl.key.password | 密钥库文件中私钥的密码。这是客户端可选的。 | |
|
||||
| ssl.keymanager.algorithm | 密钥管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的密钥管理器工厂算法。 | SunX509 |
|
||||
| ssl.keystore.location | 密钥存储文件的位置。这对客户端是可选的，可用于客户端的双向身份验证。 | null |
|
||||
| ssl.keystore.password | 密钥存储文件的存储密码。这对客户端是可选的，只有在配置了 ssl.keystore.location 时才需要。 | null |
|
||||
| ssl.keystore.type | 密钥库文件的文件格式。这是客户端可选的。 | JKS |
|
||||
| ssl.protocol | 用于生成 SSLContext 的 SSL 协议。默认设置为 TLSv1.2，适用于大多数情况。最近的 JVM 中允许的值为 TLSv1.2 和 TLSv1.3。旧的 JVM 可能支持 TLS、TLSv1.1、SSL、SSLv2 和 SSLv3，但由于已知的安全漏洞，不鼓励使用它们。 | TLSv1.2 |
|
||||
| ssl.provider | 用于 SSL 连接的安全提供程序的名称。默认值是 JVM 的默认安全提供程序。 | null |
|
||||
| ssl.trustmanager.algorithm | 信任管理器工厂用于 SSL 连接的算法。默认值是为 Java 虚拟机配置的信任管理器工厂算法。 | PKIX |
|
||||
| ssl.truststore.location | 信任存储文件的位置。 | null |
|
||||
| ssl.truststore.password | 信任存储文件的密码。如果未设置密码，则仍可访问信任库，但禁用完整性检查。 | null |
|
||||
| ssl.truststore.type | ssl.truststore.type | JKS |
|
||||
| zookeeper.clientCnxnSocket | 通常 org.apache.zookeeper.ClientCnxnSocketNetty 在使用 TLS 连接到 ZooKeeper 时设置为。覆盖通过同名 zookeeper.clientCnxnSocket 系统属性设置的任何显式值。 | |
|
||||
| zookeeper.ssl.client.enable | 设置客户端在连接到 ZooKeeper 时使用 TLS。显式值会覆盖通过 zookeeper.client.secure 系统属性设置的任何值（注意不同的名称）。如果两者都没有设置，则默认为 false；当为真时，zookeeper.clientCnxnSocket 必须设置（通常为 org.apache.zookeeper.ClientCnxnSocketNetty）；要设置的其他值可能包括 zookeeper.ssl.cipher.suites、zookeeper.ssl.crl.enable、zookeeper.ssl.enabled.protocols、zookeeper.ssl.endpoint.identification.algorithm、zookeeper.ssl.keystore.location、zookeeper.ssl.keystore.password、zookeeper.ssl.keystore.type、zookeeper.ssl.ocsp.enable、zookeeper.ssl.protocol、zookeeper.ssl.truststore.location、zookeeper.ssl.truststore.password、zookeeper.ssl.truststore.typell | false |
|
||||
| zookeeper.ssl.keystore.location | 使用客户端证书与 ZooKeeper 的 TLS 连接时的密钥库位置。覆盖通过 zookeeper.ssl.keyStore.location 系统属性设置的任何显式值（注意驼峰式命名法）。 | null |
|
||||
| zookeeper.ssl.keystore.password | 使用客户端证书与 ZooKeeper 的 TLS 连接时的密钥库密码。覆盖通过 zookeeper.ssl.keyStore.password 系统属性设置的任何显式值（注意驼峰式命名法）。注意 ZooKeeper 不支持与 keystore 密码不同的 key 密码，所以一定要设置 keystore 中的 key 密码与 keystore 密码一致；否则与 Zookeeper 的连接尝试将失败。 | null |
|
||||
| zookeeper.ssl.keystore.type | 使用客户端证书与 ZooKeeper 的 TLS 连接时的密钥库类型。覆盖通过 zookeeper.ssl.keyStore.type 系统属性设置的任何显式值（注意驼峰式命名法）。默认值 null 表示将根据密钥库的文件扩展名自动检测类型。 | |
|
||||
| zookeeper.ssl.truststore.location | 使用 TLS 连接到 ZooKeeper 时的信任库位置。覆盖通过 zookeeper.ssl.trustStore.location 系统属性设置的任何显式值（注意驼峰式命名法）。 | null |
|
||||
| zookeeper.ssl.truststore.password | 使用 TLS 连接到 ZooKeeper 时的 Truststore 密码。覆盖通过 zookeeper.ssl.trustStore.password 系统属性设置的任何显式值（注意驼峰式命名法）。 | null |
|
||||
| zookeeper.ssl.truststore.type | 使用 TLS 连接到 ZooKeeper 时的 Truststore 类型。覆盖通过 zookeeper.ssl.trustStore.type 系统属性设置的任何显式值（注意驼峰式命名法）。默认值 null 表示将根据信任库的文件扩展名自动检测类型。 | null |
|
||||
| alter.config.policy.class.name | 应该用于验证的更改配置策略类。类应该实现 org.apache.kafka.server.policy.AlterConfigPolicy 接口。 | null |
|
||||
| alter.log.dirs.replication.quota.window.num | 更改日志目录复制配额而在内存中保留的样本数 | 11 |
|
||||
| alter.log.dirs.replication.quota.window.size.seconds | 更改日志目录复制配额的每个示例的时间跨度 | 1 |
|
||||
| listener.security.protocol.map | 侦听器名称和安全协议之间的映射。必须为同一安全协议定义这一点，才能在多个端口或 IP 中使用。例如，即使内部和外部流量都需要 SSL，也可以将两者分开。具体来说，用户可以定义名称为 INTERNAL 和 EXTERNAL 的侦听器，并且此属性为：INTERNAL:SSL,EXTERNAL:SSL。如图所示，键和值用冒号分隔，映射条目用逗号分隔。每个侦听器名称在地图中只应出现一次。通过向配置名称添加规范化前缀（侦听器名称小写），可以为每个侦听器配置不同的安全性（SSL 和 SASL）设置。例如，要为 INTERNAL 侦听器设置不同的密钥库，名称为 listener.name.internal.ssl.keystore.location 将被设置。如果未设置侦听器名称的配置，则配置将回退到通用配置（即 ssl.keystore.location） | PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL |
|
||||
| log.message.downconversion.enable | 此配置控制是否启用消息格式的下转换以满足消费请求。当设置为 时 false，broker 将不会为需要旧消息格式的消费者执行向下转换。代理响应 UNSUPPORTED_VERSION 来自此类较旧客户端的消费请求的错误。此配置不适用于复制到追随者可能需要的任何消息格式转换。 | true |
|
||||
| password.encoder.cipher.algorithm | 用于对动态配置的密码进行编码的密码算法。 | AES/CBC/PKCS5Padding |
|
||||
| password.encoder.iterations | 用于编码动态配置密码的迭代计数。 | 4096 |
|
||||
| password.encoder.key.length | 用于对动态配置的密码进行编码的密钥长度。 | 128 |
|
||||
| password.encoder.keyfactory.algorithm | 用于对动态配置的密码进行编码的 SecretKeyFactory 算法。如果可用，默认为 PBKDF2WithHmacSHA512，否则为 PBKDF2WithHmacSHA1 | null |
|
||||
| security.providers | 一个可配置的创建者类列表，每个类返回一个实现安全算法的提供者。这些类应该实现 org.apache.kafka.common.security.auth.SecurityProviderCreator 接口。 | null |
|
||||
| ssl.endpoint.identification.algorithm | 使用服务器证书验证服务器主机名的端点识别算法。 | https |
|
||||
| ssl.principal.mapping.rules | 用于从客户端证书的专有名称映射到短名称的规则列表。规则按顺序评估，与主体名称匹配的第一个规则用于将其映射到短名称。列表中任何后面的规则都将被忽略。默认情况下，X.500 证书的专有名称将是主体。有关格式的更多详细信息，请参阅安全授权和 acls。请注意，如果 principal.builder.class 配置提供了 KafkaPrincipalBuilder 的扩展，则此配置将被忽略。 | DEFAULT |
|
||||
| ssl.secure.random.implementation | 用于 SSL 加密操作的 SecureRandom PRNG 实现。 | null |
|
||||
| transaction.abort.timed.out.transaction.cleanup.interval.ms | 回滚超时事务的时间间隔 | 10000 |
|
||||
| transaction.remove.expired.transaction.cleanup.interval.ms | 删除由于 transactional.id.expiration.ms 传递而过期的事务的时间间隔 | 3600000 |
|
||||
| zookeeper.ssl.cipher.suites | 指定要在 ZooKeeper TLS 协商 (csv) 中使用的已启用密码套件。覆盖通过 zookeeper.ssl.ciphersuites 系统属性设置的任何显式值（注意单个词“密码套件”）。的默认值 null 意味着启用的密码套件列表由正在使用的 Java 运行时确定 | null |
|
||||
| zookeeper.ssl.crl.enable | ZooKeeper TLS 协议中是否开启证书吊销列表。覆盖通过 zookeeper.ssl.crl 系统属性设置的任何显式值（注意较短的名称） | false |
|
||||
| zookeeper.ssl.enabled.protocols | 在 ZooKeeper TLS 协商 (csv) 中指定启用的协议。覆盖通过 zookeeper.ssl.enabledProtocols 系统属性设置的任何显式值（注意驼峰式命名法）。的默认值 null 意味着启用的协议将是 zookeeper.ssl.protocol 配置属性的值 | null |
|
||||
| zookeeper.ssl.endpoint.identification.algorithm | 指定是否在 ZooKeeper TLS 协商过程中启用主机名验证，其中（不区分大小写）“https”表示启用 ZooKeeper 主机名验证，显式空白值表示禁用（仅建议出于测试目的禁用）。显式值会覆盖通过 zookeeper.ssl.hostnameVerification 系统属性设置的任何“true”或“false”值（注意不同的名称和值；true 表示 https，false 表示空白） | HTTPS |
|
||||
| zookeeper.ssl.ocsp.enable | ZooKeeper TLS 协议中是否开启在线证书状态协议。覆盖通过 zookeeper.ssl.ocsp 系统属性设置的任何显式值（注意较短的名称） | false |
|
||||
| zookeeper.ssl.protocol | 指定要在 ZooKeeper TLS 协商中使用的协议。显式值会覆盖通过同名 zookeeper.ssl.protocol 系统属性设置的任何值 | null |
|
||||
| zookeeper.sync.time.ms | ZK 追随者可以落后于 ZK 领导者多远 | 2000 |
|
||||
|
||||
| ZK 追随者可以落后于 ZK 领导者多远 | 2000 |
|
||||
|
||||
可以在 scala 类中找到有关代理配置的更多详细信息`kafka.server.KafkaConfig`。
|
||||
|
||||
#### 扩展讲解
|
||||
|
||||
**Leader 均衡机制（auto.leader.rebalance.enable=true）**
|
||||
|
||||
> 当一个 broker 停止或崩溃时，这个 broker 中所有分区的 leader 将转移给其他副本。这意味着在默认情况下，当这个 broker 重新启动之后，它的所有分区都将仅作为 follower，不再用于客户端的读写操作。
|
||||
>
|
||||
> 为了避免这种不平衡，Kafka 有一个首选副本的概念。如果一个分区的副本列表是 1，5，9，节点 1 将优先作为其他两个副本 5 和 9 的 leader，因为它较早存在于副本中。你可以通过运行以下命令让 Kafka 集群尝试恢复已恢复正常的副本的 leader 地位：。不会导致负载不均衡和资源浪费，**这就是 leader 的均衡机制**
|
||||
>
|
||||
> ```
|
||||
> # kafka版本 <= 2.4
|
||||
> > bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot
|
||||
> # kafka新版本
|
||||
> > bin/kafka-preferred-replica-election.sh --bootstrap-server broker_host:port
|
||||
> ```
|
||||
>
|
||||
> [kafka 平衡 leader](https://www.orchome.com/33)
|
||||
>
|
||||
> 手动运行很不优雅,可以通过配置`auto.leader.rebalance.enable = true` 来自动均衡
|
||||
|
||||
在配置文件 conf/ server.properties 中配置开启（默认就是开启）`auto.leader.rebalance.enable = true`
|
||||
与其相关的配置还有
|
||||
|
||||
`leader.imbalance.check.interval.seconds` partition 检查重新 rebalance 的周期时间 ; 默认 300 秒;
|
||||
`leader.imbalance.per.broker.percentage` 标识每个 Broker 失去平衡的比率，如果超过该比率，则执行重新选举 Broker 的 leader；默认值是 10(百分之 10 的意思);
|
||||
|
||||
这个比率的算法是 ：broker 不平衡率=本应该是 Leader 但是却不是 Leader 的分区总数 /应该是 Leader 的分区总数
|
||||
|
||||
例如,下面表格是集群的分配情况, 问 **Broker-0** 上的不平衡率是多少？
|
||||
| TopicPartition | AR | Leader |
|
||||
| -------------- | ----- | ------ |
|
||||
| Topic1-0 | 0,1,2 | 0 |
|
||||
| Topic1-1 | 2,1,0 | 2 |
|
||||
| Topic1-2 | 1,0,2 | 1 |
|
||||
| Topic2-0 | 0,1,2 | 1 |
|
||||
| Topic2-1 | 0,2,1 | 0 |
|
||||
| Topic2-2 | 0,2,1 | 0 |
|
||||
|
||||
**应该是 Leader 的分区数** = 4 (所有首个副本为这个 Broker 数量)
|
||||
|
||||
**本应该是 Leader 但是却不是的分区数** = 1 (Topic2-0)
|
||||
|
||||
**不平衡率** = 1/4 = 25%
|
||||
|
||||
上面几个配置都是 && 的关系; 同时满足才能触发再平衡;
|
||||
|
||||
<font color=red> 调优建议：考虑到 leader 重选举的代价比较大，可能会带来性能影响，也可能会引发客户端的阻塞，生产环境建议设置为 false。或者周期设置长一点,比如一天一次;</font>
|
||||
|
||||
那么如果我们关闭了 均衡机制 , 或者周期时间比较长, 也就有可能造成上面说的问题, 那么[LogiKM](https://blog.csdn.net/u010634066/article/details/115631758) 就提供了一个手动再平衡的操作;
|
||||
|
||||
**compression.type 压缩类型讲解**
|
||||
|
||||
开启压缩发送传输可以提高 kafka 的消息吞吐量
|
||||
具体压缩类型: `(‘gzip’, ‘snappy’, ‘lz4’, ‘zstd’)`
|
||||
|
||||
**producer** 端设置类型
|
||||
|
||||
```java
|
||||
// 开启 lz4 压缩
|
||||
props.put("compression.type", "lz4");
|
||||
```
|
||||
|
||||
**broker 端** 继承使用 producer 的类型
|
||||
|
||||
```java
|
||||
|
||||
compression.type=producer(默认值)
|
||||
|
||||
```
|
||||
|
||||
Kafak 的压缩方式是将多条消息一起压缩,这样可以保证比较好的压缩效果。一般情况下,生产者发送的压缩数据在 Broker 中也是保持要锁状态进行存储的，消费者从服务端获取的也是压缩的数据,消费组在处理消息之前才会解压消息,这样保持了端到端的压缩。
|
||||
|
||||
使用默认值`producer`, Broker 会原封不动的保存这个数据, 如果设置了跟`producer`不一样的压缩方式,那么 Broker 还有先解压之后再用新的压缩方式来压缩,这样会导致 cpu 使用率升高, 所以使用默认值就好。 **producer** 端建议使用`lz4`的压缩方式,压缩效果比较好。
|
||||
|
||||
**日志段切分条件详解**
|
||||
|
||||
> 1. 当前日志分段文件大小超过 broker 端的参数`log.segment.bytes`,默认是**1073741824** (1G)
|
||||
> 2. 当前日志分段中消息的最大时间戳与当前系统的时间戳差值大于`log.roll.hours`或`log.roll.ms`的值,则强制创建新的日志段 Segment,`log.roll.ms` > `log.roll.hours` . `log.roll.ms` 默认为 168 ,即 7 天。
|
||||
|
||||
**min.insync.replicas 最小同步副本数**
|
||||
|
||||
> 这个参数表示 ISR 集合中的最少副本数，默认值是 1，并只有在生产者将`acks=all`或-1 时才有效。acks 与 min.insync.replicas 搭配使用，才能为消息提供最高的持久性保证。引入`min.insync.replicas`的目的就是为了保证下限：不能只满足于 ISR 全部写入，还要保证 ISR 中的写入个数不少于`min.insync.replicas` 。它的判断条件是 `min.insync.replicas<= 当前副本ISR的数量`，否则会抛出异常。常见的场景是创建一个三副本（即 replication.factor=3）的 topic，最少同步副本数设为 2（即 min.insync.replicas=2），acks 设为 all，那么必须至少有 2 个副本数据同步了(包括 Leader 副本)才可以,当然我们也可以设置为`min.insync.replicas=3`，表示所有的副本必须同步才可以,否则会抛出异常（NotEnoughReplicas 或 NotEnoughReplicasAfterAppend
|
||||
|
||||
**`__consumer_offsets` 详解**
|
||||
|
||||
> 专门用来保存消费组消费的 偏移量的数据, 它也是一个 Topic，是一个内部 Topic，在第一次消费的时候会自动创建这个 Topic,
|
||||
> 分区大小是`offsets.topic.num.partitions`控制,默认是 50,部署后不建议更改,后续可以执行扩容操作进行扩容
|
||||
> 副本数量由`offsets.topic.replication.factor`控制,默认是 3, 在集群大小满足此复制因子要求之前，内部主题`__consumer_offsets` 创建将失败。会抛出异常
|
||||
>
|
||||
> ```java
|
||||
> Number of alive brokers '1' does not meet the required replication factor '3' for the offsets topic (configured via 'offsets.topic.replication.factor'). This error can be ignored if the cluster is starting up and not all brokers are up yet.
|
||||
> ```
|
||||
|
||||
</article>
|
||||
</div>
|
||||
|
||||
**受控关机操作**
|
||||
|
||||
> 当 Broker 关闭的时候, 会向 Controller 发一起一个`ControlledShutdownRequest`请求, Controller 收到这个请求会针对性的做一些善后事件。比如说 **执行 Leader 重选举** 等等之类的...
|
||||
>
|
||||
> 源码位置：**KafkaServer#controlledShutdown**
|
||||
|
||||
**controlled.shutdown.enable 是否启用受控关闭操作**
|
||||
|
||||
> 如果关闭了,则不会发起上面说的请求了
|
||||
|
||||
**controlled.shutdown.max.retries 受控关机操作 重试的次数**
|
||||
|
||||
> `ControlledShutdownRequest`这个请求可能有多种原因执行失败, 这个配置就是重试的次数,当然，超过了这个次数仍然失败的话,那么 Broker 还是会强制关机的。
|
||||
|
||||
**controlled.shutdown.retry.backoff.ms 失败后等等多久再次重试**
|
||||
|
||||
> 当`ControlledShutdownRequest`请求失败后,会等等多少秒后再次重试 ,Thread.sleep(config.controlledShutdownRetryBackoffMs)
|
||||
|
||||
## 3.2 Topic 配置
|
||||
|
||||
与主题相关的配置既有服务器默认值，也有可选的每个主题覆盖。
|
||||
|
||||
如果没有给出每个主题的配置，则使用服务器默认值。可以在创建主题时通过提供一个或多个`--config`选项来设置覆盖。此示例创建一个名为 my-topic 的主题，具有自定义的最大消息大小和刷新率：
|
||||
|
||||
```
|
||||
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 1 \
|
||||
--replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1
|
||||
|
||||
```
|
||||
|
||||
也可以稍后使用 alter configs 命令更改或设置覆盖。此示例更新 my-topic 的最大消息大小：
|
||||
|
||||
```
|
||||
bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
|
||||
--alter --add-config max.message.bytes=128000
|
||||
```
|
||||
|
||||
要检查在主题上设置的覆盖，您可以执行
|
||||
|
||||
```
|
||||
|
||||
bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe
|
||||
|
||||
```
|
||||
|
||||
要删除覆盖，您可以执行
|
||||
|
||||
```
|
||||
bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
|
||||
--alter --delete-config max.message.bytes
|
||||
```
|
||||
|
||||
这本质上是什么呢？这是 Kafka 的动态配置，针对 Topic 级别来控制的都是在动态配置来设置的
|
||||
|
||||
关于 Kafka 的动态配置可以看 [Kafka 中的动态配置源码分析]()
|
||||
|
||||
Topic 相关可选配置
|
||||
|
||||
| key | 服务器默认属性(server.properties) | value | 默认 |
|
||||
| --------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
|
||||
| cleanup.policy | log.cleanup.policy | 此配置指定要在旧日志段使用的保留策略， 可选项[compact, delete]，默认是 delete,表示直接删除旧数据, compact 表示压缩,一个 topic 的一个分区中,只保留最近的某个 key 对应的 value | delete |
|
||||
| compression.type | compression.type | 指定给定 Topic 的最终压缩类型,它不仅可以配置（'gzip'、'snappy'、'lz4'、'zstd'），还可以配置'uncompressed' 不压缩，和'producer' 保留生产者设置的原始压缩格式 | producer |
|
||||
| delete.retention.ms | log.cleaner.delete.retention.ms | cleanup.policy 在 compact 模式下 , 墓碑消息的保存时间,墓碑消息是 value 为空的消息，当紧缩线程发现了这个消息，那么紧缩线程会把该 Key 之前的消息都紧缩掉只留下了墓碑消息，这条墓碑消息会被保存 delete.retention.ms 的时间然后再被删除 | 86400000（1 天） |
|
||||
| file.delete.delay.ms | log.segment.delete.delay.ms | topic 删除被标记为--delete 文件之后延迟多长时间删除该 Log 文件 | 60000（1 分钟） |
|
||||
| flush.messages | log.flush.interval.messages | 调用强制写入数据方法(fsync)的间隔。例如，如果将其设置为 1，我们将在每条消息后进行 fsync；如果是 5，我们将在每 5 条消息后进行 fsync。一般来说，我们建议您不要设置此选项并使用复制来提高持久性，并允许操作系统的后台刷新功能，因为它更有效 | 9223372036854775807 |
|
||||
| flush.ms | log.flush.interval.ms | 调用强制写入数据方法(fsync)的时间间隔。例如, 如果将其设置为 1000，我们将在 1000 毫秒后进行 fsync。一般来说，我们建议您不要设置此选项并使用复制来提高持久性，并允许操作系统的后台刷新功能，因为它更有效 | 9223372036854775807 |
|
||||
| follower.replication.throttled.replicas | follower.replication.throttled.replicas | flowwer 副本限流 格式：分区号:副本 follower 号,分区号:副本 follower 号，例如 0:1,1:1 ,或者可以使用通配符“\*”来限制该主题的所有副本，更详细内容请看 [分区副本同步限流机制]() | "" |
|
||||
| index.interval.bytes | log.index.interval.bytes | 此设置控制 Kafka 将索引消息添加到其偏移索引的频率。默认设置确保我们大约每 4096 个字节索引一条消息。更多的索引允许读取更接近日志中的确切位置，但会使索引更大。您可能不需要更改此设置。 | 4096 |
|
||||
| leader.replication.throttled.replicas | leader.replication.throttled.replicas | leader 副本限流 格式：分区号:副本 Leader 号，或者可以使用通配符“\*”来限制该主题的所有副本 | “” |
|
||||
| max.compaction.lag.ms | log.cleaner.max.compaction.lag.ms | 当 cleanup.policy 在 compact 模式下，一条消息从生产后到被紧缩的时间间隔最大值 | 9223372036854775807 |
|
||||
| min.compaction.lag.ms | log.cleaner.min.compaction.lag.ms | 当 cleanup.policy 在 compact 模式下，一条消息从生产后到被紧缩的时间间隔最小值 | 0 |
|
||||
| min.cleanable.dirty.ratio | log.cleaner.min.cleanable.ratio | 当 cleanup.policy 在 compact 模式下，此配置控制日志紧缩器尝试清理日志的评论 | 0.5 |
|
||||
| max.message.bytes | message.max.bytes | 最大的 batch 的 message 大小 | 1048588 |
|
||||
| message.downconversion.enable | log.message.downconversion.enable | 此配置控制是否启用消息格式的下转换以满足消费请求。当设置为 时 false，Broker 不会为期望旧消息格式的消费者执行下转换。Broker 对 UNSUPPORTED_VERSION 来自这些旧客户端的消费请求做出错误响应。此配置不适用于复制到追随者可能需要的任何消息格式转换。 | true |
|
||||
| min.insync.replicas | min.insync.replicas | 当生产者的 ack 设置为 all 或者-1 的时候，该值表示的是 ISR 的最少数量。如果 ISR 里面的数量少于此值，则消息的写入会抛异常（NotEnoughReplicas 或 NotEnoughReplicasAfterAppend）；ack=all 保证了所有 ISR 都成功写入, 但是如果 ISR 只有一个的话就退变成了 ack=1 的情况了, 如果要保证高可用, 还需要配置此值>1 | 1 |
|
||||
| preallocate | log.preallocate | 创建新的日志段 Segment 是否需要预先分配文件，如果您再 windows 上使用 kafka，您可能需要设置为 true | false |
|
||||
| retention.bytes | log.retention.bytes | 如果我们使用的是`cleanup.policy=delete`策略，此配置控制分区在丢弃旧的日志段 Segment 之前可以增长到的最大大小，默认情况下，没有大小限制，只有时间限制。注意这个配置是控制分区的大小的。不是整个 Topic 所有分区加起来的大小 | -1 |
|
||||
| retention.ms | log.retention.ms | 如果我们使用的是`cleanup.policy=delete`策略，日志段 Segment 能够保留的最长时间。只要日志段最近一条消息写入的时间距离当前时间超过了这个值，则该日志段将会被删除，如果设置为-1，则不应用时间限制 | 604800000（7 天） |
|
||||
| segment.bytes | log.segment.bytes | 每个日志段 Segment 的最大大小，该值越大，那么 Segment 数量就越小。 | 1073741824(1GB) |
|
||||
| segment.index.bytes | log.index.size.max.bytes | 索引文件的大小，我们会预先分配这个索引文件并且仅仅在日志滚动后收缩它，一般您不需要更改此值 | 10485760(10MB) |
|
||||
| segment.jitter.ms | log.roll.jitter.ms | 从计划的段滚动时间中减去的最大随机抖动，以避免雷鸣般的段滚动群 | 0 |
|
||||
| segment.ms | log.roll.ms | 此配置控制 Kafka 将强制日志滚动的时间段，即使段文件未满，以确保保留可以删除或压缩旧数据。 | 604800000（7 天） |
|
||||
| unclean.leader.election.enable | unclean.leader.election.enable | 指示是否启用不在 ISR 集中的副本作为最后的选择作为领导者，即使这样做可能会导致数据丢失。 | false |
|
||||
|
||||
#### 扩展讲解
|
||||
|
||||
**墓碑消息**
|
||||
|
||||
当我们的清理策略`cleanup.policy`是`compact`的时候:
|
||||
|
||||
针对有 key 的 topic，对于每个 key，只存储最近一次的 value，既满足应用的需求，又加快了日志清理的速度。没有指定 key 的 topic 无法进行紧缩。
|
||||
|
||||
然后当你想把该 key 所有的消息都要清理掉的时候 , 你只需要发送一个墓碑消息, key 为你指定的 key，但是 value 为空。
|
||||
|
||||
那么紧缩线程就知道你想把该 Key 的所有消息都清理掉, 但是这个目标消息还是为你保留一段时间,以防你可能有一些业务上的处理。 这个保留的时间为 `delete.retention.ms`
|
||||
|
||||
## 3.3 Producer 配置
|
||||
|
||||
| 属性 | 描述 | 默认值 |
|
||||
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| key.serializer | 实现 org.apache.kafka.common.serialization.Serializer 接口的键的序列化程序类。 | |
|
||||
| value.serializer | org.apache.kafka.common.serialization.Serializer 实现接口的值的序列化程序类。 | |
|
||||
| acks | 生产者要求 Leader 在决定是否完成请求之前收到的确认数量. 这控制了发送的记录的持久性 可配置的参数如下：<br>1. `acks=0` 如果为 0, 生产者不会等待服务器的任何确认, 会被立即视为已发送,这种情况下不能保证服务器是否真的已经收到了消息。这个时候`retries`配置不会生效(客户端都不管服务端的返回了,所以客户端一般是不知道有故障的) <br> 2. `acks=1` Leader 会将消息写入到它的本地日志中,但是不会等待所有的 Follower 完全确认就会返回发送成功状态。 这种情况下, 当 Follower 成功同步数据之前 Leader 挂掉了会造成数据丢失。<br> 3.`acks=all` Leader 将等待所有的 ISR 中的副本完成同步之后返回成功状态, 这样子数据就不会丢失,是最高级别的保证。 | 1 |
|
||||
| bootstrap.servers | 用于连接 kafka 集群 初始连接 host/port 列表，此列表仅用于发现集群, 并不强制在这里配置集群所有服务器列表 | |
|
||||
| buffer.memory | 生产者的消息缓冲区内存大小, 关于缓冲区请看[图解 Kafka Producer 消息缓存模型]() | 33554432(32M) |
|
||||
| compression.type | 生产者生成的所有数据的压缩类型。默认值为 none（即不压缩）。有效值为 none、gzip、snappy、lz4 或 zstd。 | none |
|
||||
| retries | 生产者重试次数,当`max.in.flight.requests.per.connection>1`的情况发生重试可能会导致顺序问题. | 2147483647 |
|
||||
| batch.size | 每当多个记录被发送到同一个分区的时候,生产者会尝试将消息放到一个 Batch 里面处理减少请求数。这个配置就是控制一个 Batch 的内存大小。具体请看[多图详解 kafka 生产者消息发送过程](https://blog.csdn.net/u010634066/article/details/120887135) | 16384 |
|
||||
| client.dns.lookup | 控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips，则依次连接到每个返回的 IP 地址，直到建立成功的连接。断开连接后，使用下一个 IP。一旦所有 IP 都被使用过一次，客户端会再次从主机名解析 IP（但是，JVM 和操作系统都会缓存 DNS 名称查找）。如果设置为 resolve_canonical_bootstrap_servers_only，则将每个引导地址解析为规范名称列表。在引导阶段之后，它的行为与 use_all_dns_ips. 如果设置为 default（不推荐使用），则尝试连接到查找返回的第一个 IP 地址，即使查找返回多个 IP 地址也是如此。 | use_all_dns_ips |
|
||||
| client.id | 生产者客户端 ID | |
|
||||
| connections.max.idle.ms | 在此配置指定的毫秒数后关闭空闲连接 | 540000 (9 minutes) |
|
||||
| delivery.timeout.ms | 最大交付时间, 调用 send()方法后不管是成功还是失败的时间上限。例如重试太多次之后达到次配置时间的时候也会停止重试了。此配置值应该大于等于`request.timeout.ms `和`linger.ms`总和 | 120000 (2 minutes). 如果这个值你没有主动设置并且`request.timeout.ms `+`linger.ms` > 120000(默认值) ,那么它最终的值是`request.timeout.ms `+`linger.ms` |
|
||||
| linger.ms | kafka 生产者会在 Batch 填满或 linger.ms 达到上限时把批次发送出去 | 0 |
|
||||
| max.block.ms | 生产者发送消息过程中,获取元信息的最大超时时间 | 60000 (1 minute) |
|
||||
| max.request.size | 请求的最大大小（以字节为单位）。此设置将限制生产者在单个请求中发送的记录批次的总数据量，以避免发送大量请求。这实际上也是最大未压缩记录批量大小的上限。请注意，服务器对记录批量大小有自己的上限（如果启用压缩，则在压缩之后），这可能与此不同。 | 1048576 |
|
||||
| retries | 生产者重试次数,当`max.in.flight.requests.per.connection>1`的情况发生重试可能会导致顺序问题. | 1048576 |
|
||||
| partitioner.class | 生产者分区分配策略, 详情请看:[Kafka 中生产消息时的三种分区分配策略]() | org.apache.kafka.clients.producer.internals.DefaultPartitioner |
|
||||
| receive.buffer.bytes | 读取数据时使用的 TCP 接收缓冲区 (SO_RCVBUF) 的大小。如果值为 -1，将使用操作系统默认值。 | 32768 (32 kb) |
|
||||
| request.timeout.ms | 控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应，客户端将在必要时重新发送请求，或者如果重试次数用尽，则请求失败 | 30000 (30 seconds) |
|
||||
| security.protocol | | PLAINTEXT |
|
||||
| send.buffer.bytes | 发送数据时使用的 TCP 发送缓冲区 (SO_SNDBUF) 的大小。如果值为 -1，将使用操作系统默认值。 | 131072 (128 kb) |
|
||||
| socket.connection.setup.timeout.max.ms | 客户端等待建立套接字连接的最长时间。对于每个连续的连接失败，连接设置超时将成倍增加，直至达到此最大值。为避免连接风暴，将对超时应用 0.2 的随机化因子，从而产生低于计算值 20% 到高于 20% 的随机范围。 | 127000 (127 seconds) |
|
||||
| socket.connection.setup.timeout.ms | 客户端等待套接字连接建立的时间。如果在超时之前没有建立连接，客户端将关闭套接字通道。 | 10000 (10 seconds) |
|
||||
| enable.idempotence | 是否启动幂等。当设置为 true 时候, 生产者将确保每条消息被最多写入一个副本,如果未 false,生产者由于 Broker 失败等原因重试,可能会写入到多个副本中。注意：启动幂等性的要求`max.in.flight.requests.per.connection<=5` `retries>0`并且 `acks=all` .如果设置了不兼容的值则会抛出异常 | false |
|
||||
| interceptor.classes | 生产者拦截器配置,填写全路径类名,可用逗号隔开配置多个,执行顺序就是配置的顺序。 | |
|
||||
| max.in.flight.requests.per.connection | 客户端能够允许的最大未完成请求(在请求中)的请求数量, 如果该值大于 1, 并且请求发送失败可可能导致消息重排序的风险(如果重试启用的话) | 5 |
|
||||
| metadata.max.age.ms | 即使我们没有看到任何分区领导层更改以主动发现任何新代理或分区，我们也强制刷新元数据的时间段（以毫秒为单位） | 300000 (5 minutes) |
|
||||
| metadata.max.idle.ms | Topic 的最大空闲时间. 如果一个主题在这么多毫秒内没有被访问过，它就会从缓存中删除。并且下一次对其的访问将强制执行元数据获取请求。 | 300000 (5 minutes) |
|
||||
| reconnect.backoff.max.ms | 重新连接到反复连接失败的代理时等待的最长时间（以毫秒为单位）。如果提供，每台主机的退避将在每次连续连接失败时呈指数增长，直至达到此最大值。在计算回退增加后，添加 20% 的随机抖动以避免连接风暴。 | 1000 (1 second) |
|
||||
| reconnect.backoff.ms | 在尝试重新连接到给定主机之前等待的基本时间量。这避免了在紧密循环中重复连接到主机。此退避适用于客户端到代理的所有连接尝试 | 50 |
|
||||
| retry.backoff.ms | 在尝试重试对给定主题分区的失败请求之前等待的时间量。这避免了在某些故障情况下在紧密循环中重复发送请求。 | 100 |
|
||||
|
||||
## 3.4 Consumer 配置
|
||||
|
||||
| 属性 | 描述 | 默认 |
|
||||
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
|
||||
| key.deserializer | 实现 org.apache.kafka.common.serialization.Deserializer 接口的键的反序列化器类 | |
|
||||
| value.deserializer | 实现 org.apache.kafka.common.serialization.Deserializer 接口的值的反序列化器类。 | |
|
||||
| bootstrap.servers | 用于建立与 Kafka 集群的初始连接的主机/端口对列表。客户端将使用所有服务器，无论此处指定哪些服务器进行引导——此列表仅影响用于发现完整服务器集的初始主机 | |
|
||||
| fetch.min.bytes | 服务器应为获取请求返回的最小数据量。如果可用数据不足，则请求将在响应请求之前等待累积那么多数据。1 字节的默认设置意味着只要有一个字节的数据可用或获取请求超时等待数据到达，就会响应获取请求。将此设置为大于 1 的值将导致服务器等待大量数据累积，这可以以一些额外的延迟为代价提高服务器吞吐量。 | 1 |
|
||||
| group.id | 标识此消费者所属的消费者组的唯一字符串。 | |
|
||||
| heartbeat.interval.ms | 使用 Kafka 的 Group 管理设施时，与消费者协调器之间的心跳间隔时间。心跳用于确保消费者的会话保持活跃，并在新消费者加入或离开组时促进重新平衡。该值必须设置为低于 1`session.timeout.ms`，但通常应设置为不高于该值的 1/3。它可以调整得更低，以控制正常重新平衡的预期时间。 | 3000（3 秒） |
|
||||
| max.partition.fetch.bytes | 服务器将返回的每个分区的最大数据量。记录由消费者分批获取。如果 fetch 的第一个非空分区中的第一个记录批大于此限制，则该批仍将返回以确保消费者可以进行。代理接受的最大记录批量大小是通过 message.max.bytes（代理配置）或 max.message.bytes（主题配置）定义的。有关限制消费者请求大小的信息，请参阅 fetch.max.bytes | 1048576（1 MB） |
|
||||
| session.timeout.ms | 使用 Kafka 的组管理工具时用于检测客户端故障的超时。客户端定期发送心跳以向代理指示其活跃性。如果在此会话超时到期之前代理未收到任何心跳，则代理将从组中删除此客户端并启动重新平衡。请注意，该值必须在代理配置中由 group.min.session.timeout.ms 和配置的允许范围内 group.max.session.timeout.ms。 | 10000（10 秒） |
|
||||
| allow.auto.create.topics | 订阅或分配主题时，允许在代理上自动创建主题。仅当代理允许使用 `auto.create.topics.enable` 代理配置时，才会自动创建订阅的主题。使用早于 0.11.0 的代理时，此配置必须设置为 `false` | true |
|
||||
| auto.offset.reset | 如果 Kafka 中没有初始偏移量或服务器上不再存在当前偏移量（例如，因为该数据已被删除），可选项：**earliest**：自动将偏移量重置为最早的偏移量 **latest**：自动将偏移量重置为最新的偏移量 **none**：如果没有为消费者组找到先前的偏移量，则向消费者抛出异常 其他任何事情：向消费者抛出异常。 | latest |
|
||||
| client.dns.lookup | 控制客户端如何使用 DNS 查找。如果设置为 use_all_dns_ips，则依次连接到每个返回的 IP 地址，直到建立成功的连接。断开连接后，使用下一个 IP。一旦所有 IP 都被使用过一次，客户端会再次从主机名解析 IP（但是，JVM 和操作系统都会缓存 DNS 名称查找）。如果设置为 resolve_canonical_bootstrap_servers_only，则将每个引导地址解析为规范名称列表。在引导阶段之后，它的行为与 use_all_dns_ips. 如果设置为 default（不推荐使用），则尝试连接到查找返回的第一个 IP 地址，即使查找返回多个 IP 地址也是如此。 | use_all_dns_ips |
|
||||
| connections.max.idle.ms | 在此配置指定的毫秒数后关闭空闲连接。 | 540000 (9 minutes) |
|
||||
| default.api.timeout.ms | 指定客户端 API 的超时时间（以毫秒为单位）。此配置用作所有未指定 timeout 参数的客户端操作的默认超时。 | 60000 (1 minute) |
|
||||
| enable.auto.commit | 如果为 true，消费者的偏移量将在后台定期提交。 | true |
|
||||
| exclude.internal.topics | 是否应从订阅中排除与订阅模式匹配的内部主题。始终可以显式订阅内部主题 | true |
|
||||
| fetch.max.bytes | 服务器应为获取请求返回的最大数据量。记录由消费者分批获取，如果获取的第一个非空分区的第一个记录批大于该值，仍然会返回记录批，以确保消费者可以进行。因此，这不是绝对最大值。代理接受的最大记录批量大小是通过 message.max.bytes（代理配置）或 max.message.bytes（主题配置）定义的。请注意，消费者并行执行多个提取。 | 52428800(50MB) |
|
||||
| group.instance.id | 最终用户提供的消费者实例的唯一标识符。只允许非空字符串。如果设置，消费者将被视为静态成员，这意味着在任何时候都只允许具有此 ID 的一个实例在消费者组中。这可以与更大的会话超时结合使用，以避免由于暂时不可用（例如进程重新启动）导致的组重新平衡。如果不设置，消费者将作为动态成员加入群组，这是传统的行为 | |
|
||||
| isolation.level | 控制如何读取以事务方式编写的消息。如果设置为 read_committed，consumer.poll() 将只返回已提交的事务性消息。如果设置为 read_uncommitted（默认值），consumer.poll() 将返回所有消息，甚至是已中止的事务消息。在任一模式下都将无条件返回非事务性消息。消息将始终按偏移顺序返回。因此，在 read_committedmode 下，consumer.poll() 将只返回直到最后一个稳定偏移量 (LSO) 的消息，该偏移量小于第一个打开事务的偏移量。特别是在属于正在进行的交易的消息之后出现的任何消息都将被保留，直到相关交易完成。结果，read_committed 当存在飞行交易时，消费者将无法读取到高水位线。此外，当在 read_committedseekToEnd 方法中将返回 LSO | read_uncommitted |
|
||||
| max.poll.interval.ms | 使用消费者组管理时调用 poll() 之间的最大延迟。这为消费者在获取更多记录之前可以空闲的时间量设置了上限。如果在此超时到期之前未调用 poll()，则认为消费者失败，组将重新平衡，以便将分区重新分配给另一个成员。对于使用达到此超时的非 null 的消费者 group.instance.id，不会立即重新分配分区。相反，消费者将停止发送心跳，并且分区将在 session.timeout.ms. 这反映了已关闭的静态消费者的行为。 | 300000（5 分钟） |
|
||||
| max.poll.records | 在一次 poll() 调用中返回的最大记录数。 | 500 |
|
||||
| partition.assignment.strategy | 支持的分区分配策略的类名称或类类型列表，当使用组管理时，客户端将使用这些策略在消费者实例之间分配分区所有权。除了下面指定的默认类之外，您还可以使用 org.apache.kafka.clients.consumer.RoundRobinAssignor 该类将分区循环分配给消费者。实现该 org.apache.kafka.clients.consumer.ConsumerPartitionAssignor 接口允许您插入自定义分配策略。 | org.apache.kafka.clients.consumer.RangeAssignor |
|
||||
| receive.buffer.bytes | 读取数据时使用的 TCP 接收缓冲区 (SO_RCVBUF) 的大小。如果值为 -1，将使用操作系统默认值。 | 65536（64 千字节） |
|
||||
| request.timeout.ms | 配置控制客户端等待请求响应的最长时间。如果在超时之前没有收到响应，客户端将在必要时重新发送请求，或者如果重试次数用尽，则请求失败。 | 30000（30 秒） |
|
||||
| security.protocol | 用于与 Broker 通信的协议。有效值为：PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL。 | PLAINTEXT |
|
||||
| auto.commit.interval.ms | enable.auto.commit 如果设置为 true ，则该值为消费者偏移量自动提交到 Kafka 的频率（以毫秒为单位） | 5000 (5 seconds) |
|
||||
| check.crcs | 自动检查消费记录的 CRC32。这可确保消息不会发生在线或磁盘损坏。此检查会增加一些开销，因此在寻求极端性能的情况下可能会被禁用。 | true |
|
||||
| client.id | 发出请求时传递给服务器的 id 字符串。这样做的目的是通过允许将逻辑应用程序名称包含在服务器端请求日志中来跟踪请求的来源，而不仅仅是 ip/port。 | |
|
||||
| client.rack | 此客户端的机架标识符。这可以是任何字符串值，指示此客户端的物理位置。它对应于代理配置“broker.rack” | |
|
||||
| fetch.max.wait.ms | 如果没有足够的数据立即满足 fetch.min.bytes 给出的要求，服务器将在响应 fetch 请求之前阻塞的最长时间。 | 500 |
|
||||
| interceptor.classes | 用作拦截器的类列表。实现该 org.apache.kafka.clients.consumer.ConsumerInterceptor 接口允许您拦截（并可能改变）消费者收到的记录。默认情况下，没有拦截器。 | |
|
||||
| metadata.max.age.ms | 即使我们没有看到任何分区领导层更改以主动发现任何新代理或分区，我们也强制刷新元数据的时间段（以毫秒为单位）。 | 300000（5 分钟） |
|
||||
| retry.backoff.ms | 如果上次更新失败,发起重试的间隔时间 | 100 |
|
||||
276
study-kafka/4-design.md
Normal file
276
study-kafka/4-design.md
Normal file
@@ -0,0 +1,276 @@
|
||||
---
|
||||
title: 4.Kafka架构设计
|
||||
order: 4
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 4.1 持久性
|
||||
|
||||
<font color=red> <b>Kafka 严重依赖文件系统来存储和缓存消息</b></font>，人们普遍认为“磁盘很慢”, 所以这会使用怀疑用文件系统做持久结构能否提供具有竞争力的性能。
|
||||
|
||||
事实上, 磁盘比人们预期的要慢得多,也快得多，这取决于它们的使用方式。一个设计合理的磁盘结构通常可以和网络一样快。
|
||||
|
||||
关于磁盘性能的关键事实是，在过去十年中，硬盘驱动器的吞吐量一直不同于磁盘寻道的延迟。因此，在具有六个 7200rpm SATA RAID-5 阵列组成的磁盘簇的线性(顺序)写入速度能达到 600MB/秒，但随机写入的性能仅为约 100k/秒——相差超过 6000 倍。这些线性读写是所有使用模式中最可预测的，并且由操作系统进行了大量优化。
|
||||
|
||||
现代操作系统提供<font color=red> 预读(提前将一个比较大的磁盘块读入内存)和后写(将很多小的逻辑写操作合并起来组成一个大的物理写操作)技术 </font>。
|
||||
|
||||
<font color=red> <b>顺序磁盘访问可能比随机内存访问更快！ </b></font>
|
||||
|
||||
为了弥补这种性能差异，现代操作系统越来越积极地使用主内存进行磁盘缓存。现代操作系统很乐意将所有空闲内存转移到磁盘缓存中，而在回收内存时几乎没有性能损失。所有的磁盘读写都会经过这个统一的缓存。如果不使用 Direct I/O，则无法轻松关闭此功能，因此即使进程维护数据的进程内缓存，此数据也可能会在 OS 页面缓存中复制，从而有效地将所有内容存储两次。
|
||||
|
||||
此外, Kafka 是在 JVM 上构建的, 大家都知道 Java 内存有以下问题
|
||||
|
||||
1. 对象的内存开销非常高，通常会使存储的数据大小翻倍（或更糟）。
|
||||
2. 随着堆内数据的增加，Java 垃圾收集变得越来越繁琐和缓慢。
|
||||
|
||||
由于这些因素，<font color=blue> <b>使用文件系统和依赖页面缓存优于维护内存中缓存或其他结构</b></font>
|
||||
|
||||
并且这种方式,即使 Kafka 服务重新启动, 页面缓存也是处于活跃状态, 而进程内的缓存需要再内存中重建(缓存预热)，否则它需要从完全冷的缓存开始(意味着糟糕的初始化性能)
|
||||
|
||||
这也大大简化了代码，因为维护缓存和文件系统之间一致性的所有逻辑现在都在操作系统中，这往往比一次性的进程内尝试更有效、更正确。如果您的磁盘使用倾向于线性读取，那么预读实际上是在每次磁盘读取时使用有用数据预先填充此缓存。
|
||||
|
||||
这表明了一种非常简单的设计：**与其在内存中维护尽可能多的内容，并在空间不足时将其全部刷新到文件系统中，不如将其反转。所有数据都会立即写入文件系统上的持久日志，而不必刷新到磁盘。实际上这只是意味着它被转移到内核的页面缓存中。**
|
||||
|
||||
Kafka 在设计时采用了文件追加的方式来写入消息, 即只能在日志文件的尾部追加新的消息,并且也不允许修改写入的消息, 这种方式属于典型的顺序写盘的操作,所以就算 kafka 使用磁盘作为存储介质,它所能承载的吞吐量也不容小觑。
|
||||
|
||||
## 4.2 效率
|
||||
|
||||
我们在上一节中讨论了磁盘效率。一旦消除了不良的磁盘访问模式，这种系统效率低下的常见原因有两个：<font color=blue> 太多的小型 I/O 操作和过多的字节复制。</font>
|
||||
|
||||
**太多的小型 I/O 操作**
|
||||
|
||||
小的 I/O 问题既发生在客户端和服务器之间，也发生在服务器自己的持久操作中。
|
||||
|
||||
为了避免这种情况，我们的协议是围绕“**消息集**”抽象构建的，该抽象自然地将消息组合在一起。这允许网络请求将消息组合在一起并分摊网络往返的开销，而不是一次发送单个消息。**服务器依次将消息块一次性附加到其日志中，而消费者一次获取大的线性块**。
|
||||
|
||||
这种简单的优化会产生数量级的加速。
|
||||
|
||||
**字节复制**
|
||||
|
||||
另一个低效率是字节复制。在低消息率下，这不是问题，但在负载下影响很大。为了避免这种情况，我们采用了由生产者、代理和消费者共享的标准化二进制消息格式（因此数据块可以在它们之间传输而无需修改）。
|
||||
|
||||
Broker 维护的消息日志本身只是一个文件目录，每个文件都由一系列消息集填充，这些消息集以生产者和消费者使用的相同格式写入磁盘。保持这种通用格式可以优化最重要的操作：**持久日志块的网络传输**。
|
||||
|
||||
现代 Unix 操作系统提供了一个高度优化的代码路径，用于将数据从页面缓存传输到套接字；在 Linux 中，这是通过`sendfile` 系统调用完成的。也就是 **零拷贝**
|
||||
|
||||
<font size=5 ><b>端到端批量压缩 </b></font>
|
||||
|
||||
在某些情况下，瓶颈实际上不是 CPU 或磁盘，而是网络带宽。对于需要通过广域网在数据中心之间发送消息的数据管道来说尤其如此。
|
||||
|
||||
当然，用户总是可以一次压缩一条消息，而不需要 Kafka 的任何支持，但这会导致压缩率非常低，因为大部分冗余是由于相同类型的消息之间的重复（例如，在 Web 日志中的 JSON 或用户代理或通用字符串值）。有效的压缩需要将多条消息一起压缩，而不是单独压缩每条消息。
|
||||
|
||||
Kafka 通过高效的批处理格式支持这一点。一批消息可以聚集在一起压缩并以这种形式发送到服务器。这批消息会以压缩的形式写入，并且会在日志中保持压缩状态，只会被消费者解压。
|
||||
|
||||
Kafka 支持 GZIP、Snappy、LZ4 和 ZStandard 压缩协议。可以在[此处](https://cwiki.apache.org/confluence/display/KAFKA/Compression)找到有关压缩的更多详细信息。
|
||||
|
||||
## 4.3 生产者
|
||||
|
||||
<font size=5 ><b> 负载均衡 </b></font>
|
||||
|
||||
生产者直接将数据发送到作为分区 Leader 的 Broker 上，无需任务中间路由层。
|
||||
|
||||
生产者可以通过更新元数据信息 来获取当前哪些 Broker 是在线的。
|
||||
|
||||
生产者客户端控制消息具体发布到哪个分区, 实现一种随机负载均衡。
|
||||
|
||||
具体请看[Kafka 中生产消息时的三种分区分配策略]()
|
||||
|
||||
<font size=5 ><b>异步发送 </b></font>
|
||||
|
||||
**批处理是效率的主要驱动力之一**，为了启用批处理，Kafka 生产者将尝试在内存中累积数据并在单个请求中发送更大的批处理。批处理可以配置为累积不超过固定数量的消息，并且等待时间不超过某个固定的延迟限制（例如 64k 或 10 ms）。这允许在服务器上累积更多要发送的字节，并减少更大的 I/O 操作。
|
||||
|
||||
这种缓冲是可配置的，并提供了一种机制来权衡少量额外的延迟以获得更好的吞吐量。
|
||||
|
||||
关于这一部分请看：[图解 Kafka Producer 消息缓存模型]()
|
||||
|
||||
## 4.4 消费者
|
||||
|
||||
Kafka 消费者通过向引导它想要消费的分区的代理发出“fetch”请求来工作。
|
||||
|
||||
消费者在每个请求中指定其在日志中的偏移量，并从该位置开始接收回一大块日志。
|
||||
|
||||
因此，消费者对这个位置有很大的控制权，并且可以在需要时可以回溯消息。
|
||||
|
||||
<font size=5 ><b> 推与拉 </b></font>
|
||||
|
||||
我们考虑的第一个问题是消费者是否应该从 Broker 那里提取数据，或者 Broker 应该将数据推送给消费者。
|
||||
|
||||
Kafka 是将数据推送到 Broker, 并由消费者从 Broker 拉取数据。
|
||||
|
||||
基于拉的系统的一个缺点是，如果 Broker 没有数据, 消费组可能最终会在一个紧密的循环中轮询，实际上是忙于等待数据到达，为了避免这种情况，我们在拉取请求中设置了参数，允许消费者请求在“长轮询”中阻塞，等待数据到达（并且可选地等待给定数量的字节可用以确保大传输大小）。
|
||||
|
||||
<font size=5 ><b> 消费者定位</b></font>
|
||||
|
||||
**跟踪已消费的内容是消息传递系统的关键性能点之一 。**
|
||||
|
||||
大多数消息传递系统保留有关在代理上消费了哪些消息的元数据。也就是说，当消息被分发给消费者时，代理要么立即在本地记录该事实，要么等待消费者的确认。这是一个相当直观的选择，实际上对于单机服务器来说，这种状态还能去哪里还不清楚。由于在许多消息传递系统中用于存储的数据结构扩展性很差，这也是一个务实的选择——因为代理知道消耗了什么，它可以立即删除它，从而保持数据大小较小。
|
||||
|
||||
可能不明显的是，让代理和消费者就消费的内容达成一致并不是一个微不足道的问题。如果代理在每次通过网络分发消息时立即将消息记录为已消费，那么如果消费者未能处理该消息（例如因为它崩溃或请求超时或其他原因），则该消息将丢失。为了解决这个问题，许多消息传递系统添加了确认功能，这意味着消息在发送时只标记为已发送而不是消费；代理等待来自消费者的特定确认以将消息记录为已消费. 这种策略解决了丢失消息的问题，但会产生新的问题。首先，如果消费者处理消息但在发送确认之前失败，则消息将被消费两次。第二个问题是关于性能的，现在代理必须为每条消息保留多个状态（首先将其锁定以使其不会再次发出，然后将其标记为永久消耗以便可以将其删除）。必须处理棘手的问题，例如如何处理已发送但从未确认的消息。
|
||||
|
||||
卡夫卡以不同的方式处理这个问题。我们的主题被划分为一组完全有序的分区，每个分区在任何给定时间由每个订阅消费者组中的一个消费者消费。这意味着消费者在每个分区中的位置只是一个整数，即下一条要消费的消息的偏移量。这使得关于已消费什么的状态非常小，每个分区只有一个数字。这种状态可以定期检查点。这使得消息确认的等价物非常便宜。
|
||||
|
||||
这个决定有一个附带好处。消费者可以故意回退到旧的偏移量并重新使用数据。这违反了队列的通用合同，但事实证明它是许多消费者的基本特征。例如，如果消费者代码有错误，并且在消费了一些消息后发现，那么一旦错误被修复，消费者可以重新消费这些消息。
|
||||
|
||||
<font size=5 ><b> 离线数据加载 </b></font>
|
||||
|
||||
可扩展的持久性允许消费者只定期消费，例如批量数据加载，定期将数据批量加载到离线系统，如 Hadoop 或关系数据仓库。
|
||||
在 Hadoop 的情况下，我们通过将负载拆分到各个地图任务上来并行化数据加载，每个地图任务一个用于每个节点/主题/分区组合，从而允许加载中的完全并行性。Hadoop 提供任务管理，失败的任务可以重新启动，而不会出现重复数据的危险——它们只需从原始位置重新启动。
|
||||
|
||||
## 4.5 消息传递语义
|
||||
|
||||
我们讨论一下 Kafka 在生产者和消费者之间提供的语义保证。显然，可以提供多种可能的消息传递保证：
|
||||
|
||||
1. 最多一次——消息可能会丢失，但永远不会重新传递。
|
||||
2. 至少一次——消息永远不会丢失，但可以重新传递。
|
||||
3. 恰好一次——这就是人们真正想要的，每条消息都只传递一次。
|
||||
|
||||
值得注意的是，这分为两个问题：**发布消息的持久性保证和消费消息时的保证。**
|
||||
|
||||
许多系统声称提供“恰好一次”的交付语义，但重要的是阅读细则，这些声明中的大多数都是误导性的（即它们不会转化为消费者或生产者可能失败的情况，存在多个消费者进程，或写入磁盘的数据可能丢失的情况）。
|
||||
|
||||
Kafka 的语义是直截了当的。当发布一条消息时，我们有一个消息被“提交”到日志的概念。一旦发布的消息被提交，只要复制此消息写入的分区的代理保持“活动”状态，它就不会丢失。提交消息的定义、活动分区以及我们尝试处理的故障类型的描述将在下一节中更详细地描述。现在让我们假设一个完美的无损代理，并尝试了解对生产者和消费者的保证。如果生产者尝试发布消息并遇到网络错误，则无法确定此错误是在消息提交之前还是之后发生的。
|
||||
|
||||
在 0.11.0.0 之前，如果生产者没有收到表明消息已提交的响应，它别无选择，只能重新发送消息。这提供了至少一次传递语义，因为如果原始请求实际上已经成功，则在重新发送期间消息可能会再次写入日志。从 0.11.0.0 开始，Kafka 生产者还支持幂等交付选项，以保证重新发送不会导致日志中出现重复条目 。为此，代理为每个生产者分配一个 ID，并使用生产者与每条消息一起发送的序列号对消息进行重复数据删除。同样从 0.11.0.0 开始，生产者支持使用类似事务的语义将消息发送到多个主题分区的能力：即 要么所有消息都已成功写入，要么都没有。主要用例是 Kafka 主题之间的一次性处理（如下所述）。
|
||||
|
||||
并非所有用例都需要如此强大的保证。对于对延迟敏感的用途，我们允许生产者指定其所需的持久性级别。如果生产者指定它想要等待提交的消息，这可能需要 10 毫秒的时间。然而，生产者也可以指定它想要完全异步地执行发送，或者它只想等到领导者（但不一定是追随者）收到消息。
|
||||
|
||||
现在让我们从消费者的角度来描述语义。所有副本都具有完全相同的日志和相同的偏移量。消费者控制其在此日志中的位置。如果消费者从未崩溃，它可以只将这个位置存储在内存中，但是如果消费者失败并且我们希望这个主题分区被另一个进程接管，那么新进程将需要选择一个合适的位置来开始处理。假设消费者读取了一些消息——它有几个选项来处理消息和更新它的位置。
|
||||
|
||||
它可以读取消息，然后将其位置保存在日志中，最后处理消息。在这种情况下，消费者进程可能会在保存其位置之后但在保存其消息处理的输出之前崩溃。在这种情况下，接管处理的进程将从保存的位置开始，即使该位置之前的一些消息尚未处理。这对应于“最多一次”语义，因为在消费者失败的情况下，消息可能不会被处理。
|
||||
它可以读取消息，处理消息，最后保存它的位置。在这种情况下，消费者进程可能会在处理消息之后但在保存其位置之前崩溃。在这种情况下，当新进程接管它收到的前几条消息时，它已经被处理了。这对应于消费者失败情况下的“至少一次”语义。在许多情况下，消息有一个主键，因此更新是幂等的（两次接收相同的消息只会用另一个自身的副本覆盖记录）。
|
||||
那么恰好一次语义（即你真正想要的东西）呢？从 Kafka 主题消费并生产到另一个主题时（如在 Kafka Streams 中） 应用程序），我们可以利用上面提到的 0.11.0.0 中新的事务生产者功能。消费者的位置作为消息存储在主题中，因此我们可以在与接收处理数据的输出主题相同的事务中将偏移量写入 Kafka。如果交易中止，消费者的位置将恢复到其旧值，并且输出主题的生成数据将不会对其他消费者可见，具体取决于他们的“隔离级别”。在默认的“read_uncommitted”隔离级别中，所有消息对消费者都是可见的，即使它们是中止事务的一部分，但在“read_committed”中，消费者将只返回来自已提交事务的消息（以及任何不属于的消息）一笔交易）。
|
||||
|
||||
写入外部系统时，限制在于需要将消费者的位置与实际存储为输出的内容相协调。实现这一点的经典方法是在消费者位置的存储和消费者输出的存储之间引入两阶段提交。但这可以通过让消费者将其偏移量与其输出存储在同一位置来更简单和更普遍地处理。这更好，因为消费者可能想要写入的许多输出系统不支持两阶段提交。作为一个例子，考虑一个 Kafka Connect 连接器在 HDFS 中填充数据以及它读取的数据的偏移量，以保证数据和偏移量都被更新或两者都不更新。对于许多其他需要这些更强语义并且消息没有允许重复数据删除的主键的数据系统，我们遵循类似的模式。
|
||||
|
||||
因此，Kafka 在 Kafka Streams 中有效地支持一次性交付，并且在 Kafka 主题之间传输和处理数据时，通常可以使用事务性生产者/消费者来提供一次性交付。其他目标系统的 Exactly-once 交付通常需要与此类系统合作，但 Kafka 提供了偏移量，这使得实现这一点变得可行（另请参见 Kafka Connect）。否则，Kafka 默认保证至少一次交付，并允许用户通过在处理一批消息之前禁用生产者的重试并在消费者中提交偏移量来实现最多一次交付
|
||||
|
||||
## 4.6 复制
|
||||
|
||||
Kafka 中可以配置副本数, 这些副本分为 Leader 副本和 Follower 副本, Follower 副本会从 Leader 副本中同步数据。 Leader 副本只有一个,Follower 有 0 个或者多个。
|
||||
|
||||
这将允许集群在服务器发生故障的时候自动故障转移到这些副本中，提升集群高可用性。
|
||||
|
||||
Follower 副本有和 Leader 副本相同的偏移量和相同顺序的消息(当然可能 Follower 还没有来得及同步完全,会少一点数据)
|
||||
|
||||
Leader 负责提供读写能力, Follower 只负责复制备份。
|
||||
|
||||
与大多数自动处理故障的分布式系统一样，需要对节点“活着”的含义有一个精确的定义。对于 Kafka 节点的活跃度有两个条件
|
||||
|
||||
一个节点必须能够维持它与 ZooKeeper 的会话（通过 ZooKeeper 的心跳机制）
|
||||
如果它是追随者，它必须复制发生在领导者上的写入，并且不能落后“太远”
|
||||
我们将满足这两个条件的节点称为“同步”，以避免“活着”或“失败”的模糊性。领导者跟踪一组“同步”节点。如果追随者死亡、卡住或落后，领导者会将其从同步副本列表中删除。卡住和滞后副本的确定由 `replica.lag.time.max.ms `配置控制。
|
||||
在分布式系统术语中，我们只尝试处理“故障/恢复”故障模型，其中节点突然停止工作，然后恢复（可能不知道它们已经死亡）。Kafka 不处理所谓的“拜占庭”故障，即节点产生任意或恶意响应（可能是由于错误或犯规）。
|
||||
|
||||
我们现在可以更精确地定义，当该分区的所有同步副本都将消息应用于其日志时，该消息被视为已提交。只有提交的消息才会发送给消费者。这意味着消费者不必担心如果领导者失败，可能会看到可能丢失的消息。另一方面，生产者可以选择等待或不提交消息，这取决于他们对延迟和持久性之间权衡的偏好。此首选项由生产者使用的 acks 设置控制。请注意，主题具有同步副本的“最小数量”设置，当生产者请求确认消息已写入完整的同步副本集时，会检查该设置。
|
||||
|
||||
Kafka 提供的保证是，只要始终有至少一个同步副本处于活动状态，提交的消息就不会丢失。
|
||||
|
||||
在短暂的故障转移期后，如果存在节点故障，Kafka 将保持可用，但在存在网络分区时可能无法保持可用。
|
||||
|
||||
<font size=5 ><b> Leader 选举、ISR 收缩机制 </b></font>
|
||||
|
||||
Leader 选举请看：[Kafka Leader 选举流程和选举策略]()
|
||||
|
||||
|
||||
|
||||
ISR 伸缩机制：[ISR 伸缩机制]()
|
||||
|
||||
|
||||
|
||||
## 4.7 日志紧缩
|
||||
|
||||
日志紧缩确保 Kafka 将始终为单个主题分区的数据日志中的每个消息 key 至少保留最后一个已知值
|
||||
|
||||
<font size=5 ><b> 日志紧缩基础 </b></font>
|
||||
|
||||
这是一张高级图片，显示了 Kafka 日志的逻辑结构以及每条消息的偏移量。
|
||||
|
||||
|
||||
|
||||
日志的头部与传统的 Kafka 日志相同。它具有密集的顺序偏移并保留所有消息。日志压缩添加了处理日志尾部的选项。上图显示了带有压实尾部的原木。请注意，日志尾部的消息保留了第一次写入时分配的原始偏移量——永远不会改变。另请注意，所有偏移量在日志中仍然是有效位置，即使具有该偏移量的消息已被压缩；在这种情况下，该位置与日志中出现的下一个最高偏移量无法区分。例如，在上图中，偏移量 36、37 和 38 都是等效位置，从这些偏移量中的任何一个开始读取都会返回以 38 开头的消息集。
|
||||
|
||||
压缩还允许删除。带有键和空负载的消息将被视为从日志中删除。这样的记录有时被称为墓碑。此删除标记将导致删除具有该键的任何先前消息（与具有该键的任何新消息一样），但删除标记的特殊之处在于它们本身将在一段时间后从日志中清除以释放空间. 删除不再保留的时间点在上图中标记为“删除保留点”。
|
||||
|
||||
压缩是通过定期重新复制日志段在后台完成的。清理不会阻塞读取，并且可以限制为使用不超过可配置量的 I/O 吞吐量，以避免影响生产者和消费者。压缩日志段的实际过程如下所示：
|
||||
|
||||
|
||||
|
||||
<font size=5 ><b> 日志紧缩提供什么保证 </b></font>
|
||||
|
||||
日志压缩保证以下内容：
|
||||
|
||||
1. 任何关注日志头部的消费者都会看到写入的每条消息；这些消息将具有顺序偏移量。主题`min.compaction.lag.ms`可用于保证在消息写入之后必须经过的最短时间长度才能被压缩。即，它提供了每条消息将在（未压缩的）头部中保留多长时间的下限。主题`max.compaction.lag.ms`可用于保证消息写入时间和消息符合压缩条件的时间之间的最大延迟。
|
||||
2. 消息的顺序始终保持不变。压缩永远不会重新排序消息，只需删除一些。
|
||||
3. 消息的偏移量永远不会改变。它是日志中某个位置的永久标识符。
|
||||
4. 从日志开头开始的任何消费者都将按照写入顺序至少看到所有记录的最终状态。此外，如果消费者在小于主题`delete.retention.ms`设置的时间段内到达日志头部（默认为 24 小时），则会看到已删除记录的所有删除标记。换句话说：由于删除标记的删除与读取同时发生，如果消费者滞后超过 delete.retention.ms.
|
||||
|
||||
<font size=5 ><b> 日志紧缩细信息 </b></font>
|
||||
|
||||
日志压缩由日志清理器处理，这是一个后台线程池，用于重新复制日志段文件，删除其键出现在日志头部的记录。每个 compactor 线程的工作方式如下：
|
||||
|
||||
1. 它选择日志头与日志尾比率最高的日志
|
||||
2. 它为日志头部中的每个键创建一个最后偏移量的简洁摘要
|
||||
3. 它从头到尾重新复制日志，删除日志中稍后出现的键。新的、干净的段会立即交换到日志中，因此所需的额外磁盘空间只是一个额外的日志段（不是日志的完整副本）。
|
||||
4. 日志头的摘要本质上只是一个空间紧凑的哈希表。每个条目正好使用 24 个字节。因此，使用 8GB 的 清理缓冲区，一次清理迭代可以清理大约 366GB 的日志头（假设有 1k 条消息）。
|
||||
|
||||
<font size=5 ><b> 配置日志清理器 </b></font>
|
||||
|
||||
默认情况下启用日志清理器。这将启动清洁线程池。要对特定主题启用日志清理，请添加特定于日志的属性
|
||||
|
||||
```
|
||||
|
||||
log.cleanup.policy=compact
|
||||
|
||||
```
|
||||
|
||||
该`log.cleanup.policy`属性是在代理文件中定义的代理配置设置`server.properties`；它会影响集群中没有配置覆盖的所有主题，如此处 所述。日志清理器可以配置为保留最少量的未紧缩日志“头”。这是通过设置压缩时间延迟来实现的
|
||||
|
||||
```
|
||||
log.cleaner.min.compaction.lag.ms
|
||||
|
||||
```
|
||||
|
||||
这可用于防止比最小消息年龄更新的消息受到压缩。如果未设置，则所有日志段都符合压缩条件，除了最后一个段，即当前正在写入的段。即使活动段的所有消息都早于最小压缩时间延迟，活动段也不会被压缩。可以配置日志清理器以确保最大延迟，在此之后，未压缩的日志“头”符合日志压缩的条件。
|
||||
|
||||
```
|
||||
log.cleaner.max.compaction.lag.ms
|
||||
|
||||
```
|
||||
|
||||
这可用于防止具有低生产率的原木在无限制的持续时间内保持不适合压实。如果未设置，则不会压缩不超过 min.cleanable.dirty.ratio 的日志。请注意，此压缩截止日期不是硬性保证，因为它仍然受日志清理线程的可用性和实际压缩时间的影响。您将需要监控 uncleanable-partitions-count、max-clean-time-secs 和 max-compaction-delay-secs 指标。
|
||||
|
||||
## 4.8 配额
|
||||
|
||||
Kafka 集群能够对请求实施配额以控制客户端使用的 Broker 资源。Kafka Broker 可以为共享配额的每组客户端强制执行两种类型的客户端配额：
|
||||
|
||||
1. 网络带宽配额定义字节速率阈值（自 0.9 起）
|
||||
2. 请求速率配额将 CPU 利用率阈值定义为网络和 I/O 线程的百分比（从 0.11 开始）
|
||||
|
||||
<font size=5 ><b> 为什么需要配额？ </b></font>
|
||||
|
||||
生产者和消费者有可能生产/消费非常大量的数据或以非常高的速率生成请求，从而垄断 Broker 资源，导致网络饱和，并且通常 DOS 其他客户端和代理本身。拥有配额可以防止这些问题，并且在大型多租户集群中更为重要，其中一小部分行为不良的客户端可能会降低行为良好的客户端的用户体验。事实上，当将 Kafka 作为服务运行时，这甚至可以根据商定的合同强制执行 API 限制。
|
||||
|
||||
<font size=5 ><b> 配额配置 </b></font>
|
||||
|
||||
可以为（用户、客户端 ID）、用户和客户端 ID 组定义配额配置。可以在任何需要更高（甚至更低）配额的配额级别覆盖默认配额。该机制类似于每个主题的日志配置覆盖。用户和（用户，客户端 ID）配额覆盖写入 ZooKeeper 下/config/users 和客户端 ID 配额覆盖写入/config/clients 下。这些覆盖被所有代理读取并立即生效。这让我们无需滚动重启整个集群即可更改配额。有关详细信息，请参见此处。每个组的默认配额也可以使用相同的机制动态更新。
|
||||
|
||||
配额配置的优先顺序为：
|
||||
|
||||
1. /config/users/<user>/clients/<client-id>
|
||||
2. /config/users/<用户>/clients/<默认>
|
||||
3. /config/users/<用户>
|
||||
4. /config/users/<默认值>/clients/<client-id>
|
||||
5. /config/users/<默认值>/clients/<默认值>
|
||||
6. /config/users/<默认值>
|
||||
7. /config/clients/<client-id>
|
||||
8. /config/clients/<默认>
|
||||
|
||||
Broker 属性（quota.producer.default、quota.consumer.default）也可用于为客户端 ID 组设置网络带宽配额的默认值。这些属性已被弃用，并将在以后的版本中删除。可以在 Zookeeper 中设置 client-id 的默认配额，类似于其他配额覆盖和默认值。
|
||||
|
||||
<font size=5 ><b> 网络带宽配额 </b></font>
|
||||
|
||||
网络带宽配额定义为共享配额的每组客户端的字节速率阈值。默认情况下，每个唯一的客户端组都会收到集群配置的以字节/秒为单位的固定配额。此配额是根据每个经纪人定义的。在限制客户端之前，每组客户端最多可以发布/获取每个代理 X 字节/秒。
|
||||
|
||||
<font size=5 ><b> 请求速率配额 </b></font>
|
||||
|
||||
请求速率配额定义为客户端可以在配额窗口内使用请求处理程序 I/O 线程和每个代理的网络线程的时间百分比。n%的配额表示 一个线程的 n% ，因此配额超出了((num.io.threads + num.network.threads) \* 100)%的总容量。每组客户可以使用的总百分比高达 n%在被限制之前跨配额窗口中的所有 I/O 和网络线程。由于分配给 I/O 和网络线程的线程数通常基于代理主机上可用的内核数，因此请求率配额表示共享配额的每组客户端可能使用的 CPU 的总百分比。
|
||||
184
study-kafka/5-implementation.md
Normal file
184
study-kafka/5-implementation.md
Normal file
@@ -0,0 +1,184 @@
|
||||
---
|
||||
title: 5.Kafka实现机制
|
||||
order: 5
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 5.1 网络层
|
||||
|
||||
网络层是一个相当简单的 NIO 服务器，不再详细介绍。`sendfile` 的实现是通过给 MessageSet 接口一个 writeTo 方法来完成的。这允许文件支持的消息集使用更有效的 transferTo 实现而不是进程内缓冲写入。线程模型是单个接受线程和 N 个处理器线程，每个线程处理固定数量的连接。这种设计已经在其他地方进行了相当彻底的测试，并且发现它易于实现且速度快。该协议保持非常简单，以允许将来以其他语言实现客户端。
|
||||
|
||||
## 5.2 消息
|
||||
|
||||
消息由一个可变长度的标头、一个可变长度的不透明键字节数组和一个可变长度的不透明值字节数组组成。标题的格式在下一节中描述。保持 key 和 value 不透明是正确的决定：序列化库目前正在取得很大进展，任何特定的选择都不太可能适合所有用途。不用说，使用 Kafka 的特定应用程序可能会要求特定的序列化类型作为其使用的一部分。该 RecordBatch 接口只是消息的迭代器，具有用于批量读取和写入 NIO 的专用方法 Channel。
|
||||
|
||||
## 5.3 消息格式
|
||||
|
||||
<font size=5 ><b>Record 结构图 </b></font>
|
||||
|
||||
|
||||
|
||||
**Record 属性解释:**
|
||||
|
||||
1. length：整个 Record 的消息总大小, 使用可变字段。
|
||||
2. attributes：已经弃用,默认为 0,固定占用了 1B
|
||||
3. timestampDelta: 时间戳的增量,使用可变字段。使用增量可以有效节约内存
|
||||
4. offsetDelta: 位移的增量,使用可变字段, 使用增量可以有效节约内存
|
||||
5. keyLength: key 的长度,使用可变字段, 如果没有 key,该值为-1。
|
||||
6. key: key 的信息,正常存储。如果 key==null,则该值不存在。
|
||||
7. valueLength：value 的长度,使用可变字段, 如果没有 key,改值为-1.
|
||||
8. value： value 的信息,正常存储,如果 value==null,则该值也不存在。
|
||||
9. headers：消息头，这个字段用于支持应用级别的扩展,可以携带很多信息,例如你带一个 TraceId 也不过分。
|
||||
10. header counts : 消息头的数量,使用可变字段
|
||||
|
||||
<font color=red> Varints 是可变长自动,可以有效的节省空间</font>
|
||||
|
||||
**Header 属性解释:**
|
||||
|
||||
类似,就不再赘述了。
|
||||
|
||||
<font size=5 ><b> RecordBatchHeader 结构图 </b></font>
|
||||
|
||||
|
||||
|
||||
**RecordBatchHeader 属性解释:**
|
||||
|
||||
1. **baseOffset**: 当然 RecordBatch 的起始位移,一般默认为 0
|
||||
2. **length**：计算从`partition leader epoch` 字段开始到整体末尾的长度,计算的逻辑是(sizeInBytes - LOG_OVERHEAD), 这个`sizeInBytes`就是整个 RecordBatch 的长度。LOG_OVERHEAD = 12
|
||||
3. **partition leader epoch**: 分区的 Leader 纪元,也就是版本号
|
||||
4. **magic**: 消息格式版本号, V2 版本 该值为 2
|
||||
5. **crc32**: 该 RecordBatch 的校验值, 计算该值是从**attributes**的位置开始计算的。
|
||||
6. **attributes**：消息的属性,这里用了 2 个字节, 低 3 位表示压缩格式,第 4 位表示时间戳,第 5 位表示事务标识,第 6 位表示是否控制消息。如下图
|
||||
|
||||
|
||||
|
||||
7. **last offset delta** : RecordBatch 中最后一个 Record 的 offset 与 first offset 的差值。
|
||||
8. **first timestamp**: 第一条 Record 的时间戳。对于 Record 的时间戳的值 ,如果在构造待发送的 ProducerRecord 的时候设置了 timestamp,那么就是这个设置的值,如果没有设置那就是当前时间戳的值。
|
||||
9. **max timestamp**: RecordBatch 中最大时间戳。
|
||||
10. **producer id** : 用于支持幂等和事务的属性。
|
||||
11. **producer epoch** ：用于支持幂等和事务的属性。
|
||||
12. **base sequence** ：用于支持幂等和事务的属性。
|
||||
13. **record count** : 消息数量
|
||||
|
||||
<font size=5 ><b> RecordBatch 整体结构图 </b></font>
|
||||
|
||||
|
||||
|
||||
1. 在创建 RecordBatch 的时候,会先预留 61B 的位置给 BatchHeader, 实现方式就是让 buffer 的位置移动到 61 位` buffer.possition(61)`
|
||||
2. 消息写入的时候并不会压缩,只有等到即将发送这个 Batch 的时候,会关闭 Batch,从而进行压缩(如果配置了压缩策略的话), 压缩的知识 Records, 不包含 RecordBatchHeader
|
||||
3. 填充 RecordBatchHeader
|
||||
|
||||
## 5.4 日志
|
||||
|
||||
具有两个分区的名为“my_topic”的主题的日志由两个目录（即 my_topic_0 和 my_topic_1）组成，其中填充了包含该主题消息的数据文件。日志文件的格式是“日志条目”的序列；每个日志条目是一个 4 字节整数 N，存储消息长度，后跟 N 个消息字节。每条消息由一个 64 位整数偏移量唯一标识给出该消息在该分区上发送到该主题的所有消息流中开始的字节位置。下面给出了每条消息的磁盘格式。每个日志文件都以其包含的第一条消息的偏移量命名。因此，创建的第一个文件将是 00000000000.kafka，并且每个附加文件将具有一个与前一个文件大约 S 字节的整数名称，其中 S 是配置中给出的最大日志文件大小。
|
||||
|
||||
记录的确切二进制格式作为标准接口进行版本控制和维护，因此记录批次可以在生产者、代理和客户端之间传输，而无需在需要时重新复制或转换。上一节包括有关记录的磁盘格式的详细信息。
|
||||
|
||||
使用消息偏移量作为消息 ID 是不寻常的。我们最初的想法是使用生产者生成的 GUID，并在每个代理上维护从 GUID 到偏移量的映射。但是由于消费者必须为每个服务器维护一个 ID，所以 GUID 的全局唯一性没有任何价值。此外，维护从随机 id 到偏移量的映射的复杂性需要一个必须与磁盘同步的重量级索引结构，本质上需要一个完全持久的随机访问数据结构。因此，为了简化查找 结构，我们决定使用一个简单的每个分区原子计数器，它可以与分区 id 和节点 id 耦合来唯一标识一条消息；这使得查找结构更简单，尽管每个消费者请求仍然可能进行多次查找。然而，一旦我们在柜台上安顿下来，直接使用偏移量的跳转似乎很自然——毕竟两者都是分区独有的单调递增整数。由于偏移量对消费者 API 是隐藏的，所以这个决定最终是一个实现细节，我们采用了更有效的方法。
|
||||
|
||||
|
||||
|
||||
**写**
|
||||
|
||||
该日志允许串行附加总是转到最后一个文件。当这个文件达到可配置的大小（比如 1GB）时，它会滚动到一个新文件。该日志采用两个配置参数：M，它给出了在强制操作系统将文件刷新到磁盘之前要写入的消息数，以及 S，它给出了强制刷新之后的秒数。这提供了在系统崩溃 时最多丢失 M 条消息或 S 秒数据的持久性保证。
|
||||
|
||||
**读**
|
||||
|
||||
通过给出消息的 64 位逻辑偏移和 S 字节最大块大小来完成读取。这将返回 S 字节缓冲区中包含的消息的迭代器。S 旨在大于任何单个消息，但在消息异常大的情况下，可以多次重试读取，每次将缓冲区大小加倍，直到成功读取消息。可以指定最大消息和缓冲区大小以使服务器拒绝大于某个大小的消息，并为客户端提供它需要读取的最大值以获得完整消息的最大值。读取缓冲区很可能以部分消息结尾，这很容易通过大小分隔来检测。
|
||||
|
||||
从偏移量读取的实际过程需要首先找到存储数据的日志段文件，根据全局偏移量值计算文件特定的偏移量，然后从该文件偏移量中读取。搜索是针对为每个文件维护的内存范围的简单二进制搜索变体完成的。
|
||||
|
||||
该日志提供了获取最近写入消息的能力，以允许客户端从“现在”开始订阅。这在消费者未能在其 SLA 指定的天数内使用其数据的情况下也很有用。在这种情况下，当客户端尝试使用不存在的偏移量时，它会被赋予 OutOfRangeException 并且可以根据用例自行重置或失败。
|
||||
|
||||
以下是发送给消费者的结果格式。
|
||||
|
||||
|
||||
|
||||
**删除**
|
||||
|
||||
数据一次删除一个日志段。日志管理器应用两个指标来识别符合删除条件的段：时间和大小。对于基于时间的策略，会考虑记录时间戳，段文件中的最大时间戳（记录顺序不相关）定义整个段的保留时间。默认情况下禁用基于大小的保留。启用后，日志管理器会继续删除最旧的段文件，直到分区的总大小再次在配置的限制内。如果同时启用这两个策略，则将删除由于任一策略而符合删除条件的段。
|
||||
|
||||
## 5.5 Zookeeper 结构
|
||||
|
||||
|
||||
|
||||
**/cluster/id 持久数据节点**
|
||||
|
||||
> 集群 ID
|
||||
> 当第一台 Broker 启动的时候, 发现`/cluster/id`不存在,那么它就会把自己的`cluster.id`配置写入 zk; 标记当前 zk 是属于集群哪个集群; 后面其他的 Broker 启动的时候会去获取该数据, 如果发现数据跟自己的配置不一致; 则抛出异常,加入的不是同一个集群;
|
||||
> 数据示例：`{"version":"1","id":"0"}`
|
||||
|
||||
<font size=5 ><b> /controller_epoch 持久数据节点 </b></font>
|
||||
|
||||
> Controller 选举次数;
|
||||
|
||||
<font size=5 ><b> /controller 临时数据节点 </b></font>
|
||||
|
||||
> 当前 Controller 角色的 BrokerId,数据示例:
|
||||
> `{"version":1,"brokerid":0,"timestamp":"1624415590383"}`
|
||||
> 删除该节点立马触发重新选举
|
||||
|
||||
<font size=5 ><b> /log_dir_event_notification </b></font>
|
||||
|
||||
> zk 的数据中有一个节点`/log_dir_event_notification/`，这是一个序列号持久节点
|
||||
> 这个节点在 kafka 中承担的作用是: 当某个 Broker 上的 LogDir 出现异常时(比如磁盘损坏,文件读写失败,等等异常): 向 zk 中谢增一个子节点`/log_dir_event_notification/log_dir_event_序列号` ；Controller 监听到这个节点的变更之后,会向 Brokers 们发送`LeaderAndIsrRequest`请求; 然后做一些副本脱机的善后操作
|
||||
> 详情请看 [【kafka 源码】/log_dir_event_notification 的 LogDir 脱机事件通知]()
|
||||
|
||||
<font size=5 ><b> /isr*change_notification/log_dir_event*{序列号} </b></font>
|
||||
|
||||
> 当 Isr 有变更的时候,会写入这个节点 Controller 监听变更
|
||||
|
||||
<font size=5 ><b> /admin </b></font>
|
||||
|
||||
**/admin/delete_topics 待删除 Topic**
|
||||
|
||||
**/admin/delete_topics/{topicName} 持久节点,待删除 Topic**
|
||||
|
||||
> 存在此节点表示 当前 Topic 需要被删除
|
||||
|
||||
**/admin/reassign_partitions 持久数据节点**
|
||||
|
||||
> 如果有此节点,表示当前正在进行数据迁移,里面的数据就是正在迁移的配置
|
||||
> 示例数据: 
|
||||
|
||||
<font size=5 ><b> /brokers </b></font>
|
||||
|
||||
**/brokers/seqid**
|
||||
|
||||
> **`/brokers/seqid`: 全局序列号**
|
||||
> 里面没有数据,主要是用了节点的`dataVersion`信息来当全局序列号
|
||||
>
|
||||
> **在 kafka 中的作用: 自动生成 BrokerId**
|
||||
> 主要是用来自动生成 brokerId;
|
||||
> 一个集群如果特别大,配置 brokerId 的时候不能重复,一个个设置比较累; 可以让 Broker 自动生成 BrokerId
|
||||
|
||||
`server.properties` 配置
|
||||
|
||||
```properties
|
||||
## 设置Brokerid能够自动生成
|
||||
broker.id.generation.enable=true
|
||||
## 设置BrokerId<0 （如果>=0则以此配置为准）
|
||||
broker.id=-1
|
||||
## 自动生成配置的起始值
|
||||
reserved.broker.max.id=20000
|
||||
```
|
||||
|
||||
BrokerId 计算方法
|
||||
|
||||
> brokerId = {reserved.broker.max.id} +` /brokers/seqid`.dataVersion
|
||||
>
|
||||
> 每次想要获取` /brokers/seqid`的 dataVersion 值的时候都是用 set 方法,set 的时候会返回 version 数据,并不是 get；每次 set 这个节点数据,版本信息就会自增;所以就实现了全局自增 ID 了；
|
||||
|
||||
**/brokers/ids/{id} 临时数据节点 : 在线 BrokerID**
|
||||
|
||||
> 在线的 Broker 都会在这里注册一个节点; 下线自动删除
|
||||
|
||||
**/brokers/topics/{topicName}持久数据节点**
|
||||
|
||||
> 存储 topic 的分区副本分配信息
|
||||
> 例如：`{"version":1,"partitions":{"0":[0]}}`
|
||||
|
||||
**/brokers/topics/{topicName}/{分区号}/state 持久数据节点**
|
||||
|
||||
> 存储指定分区的`leader`和`isr`等信息
|
||||
> 例如:`{"controller_epoch":203,"leader":0,"version":1,"leader_epoch":0,"isr":[0]}`
|
||||
1888
study-kafka/6-operation.md
Normal file
1888
study-kafka/6-operation.md
Normal file
File diff suppressed because it is too large
Load Diff
597
study-kafka/7-safety.md
Normal file
597
study-kafka/7-safety.md
Normal file
@@ -0,0 +1,597 @@
|
||||
---
|
||||
title: 7.Kafka安全管控
|
||||
order: 7
|
||||
toc: menu
|
||||
---
|
||||
|
||||
## 7.1 安全概述
|
||||
|
||||
在 0.9.0.0 版本中，Kafka 社区添加了许多功能，这些功能可以单独或一起使用，以提高 Kafka 集群的安全性。当前支持以下安全措施：
|
||||
|
||||
1. 使用 SSL 或 SASL 对来自客户端（生产者和消费者）、其他代理和工具的代理连接进行身份验证。Kafka 支持以下 SASL 机制：
|
||||
|
||||
- SASL/GSSAPI (Kerberos) - 从版本 0.9.0.0 开始
|
||||
- SASL/PLAIN - 从版本 0.10.0.0 开始
|
||||
- SASL/SCRAM-SHA-256 和 SASL/SCRAM-SHA-512 - 从版本 0.10.2.0 开始
|
||||
- SASL/OAUTHBEARER - 从 2.0 版开始
|
||||
|
||||
2. 从 Broker 到 ZooKeeper 的连接身份验证
|
||||
3. 使用 SSL 加密代理和客户端之间、代理之间或代理和工具之间传输的数据（请注意，启用 SSL 时会出现性能下降，其幅度取决于 CPU 类型和 JVM 实现。）
|
||||
4. 客户端对读/写操作的授权
|
||||
5. 授权可插拔，支持与外部授权服务集成
|
||||
|
||||
值得注意的是，安全性是可选的——支持非安全集群，以及经过身份验证、未经身份验证、加密和非加密客户端的混合。
|
||||
|
||||
## 7.2 使用 SSL 的加密和认证
|
||||
|
||||
Apache Kafka 允许客户端使用 SSL 进行流量加密和身份验证。默认情况下，SSL 处于禁用状态，但可以根据需要打开。以下段落详细解释了如何设置您自己的 PKI 基础设施、使用它来创建证书以及配置 Kafka 以使用这些基础设施。
|
||||
|
||||
**1.为每个 Kafka Broker 生成 SSL 密钥和证书**
|
||||
|
||||
部署一个或多个支持 SSL 的代理的第一步是为每个服务器生成一个公钥/私钥对。由于 Kafka 希望所有密钥和证书都存储在密钥库中，因此我们将使用 Java 的 keytool 命令来完成此任务。该工具支持两种不同的密钥库格式，Java 特定的 jks 格式，现在已被弃用，以及 PKCS12。PKCS12 是 Java 版本 9 的默认格式，以确保无论使用的 Java 版本如何，都使用此格式，所有以下命令都明确指定 PKCS12 格式。
|
||||
|
||||
```
|
||||
|
||||
keytool -keystore {keystorefile} -alias localhost -validity {validity} -genkey -keyalg RSA -storetype pkcs12
|
||||
|
||||
```
|
||||
|
||||
您需要在上述命令中指定两个参数：
|
||||
|
||||
1. keystorefile：存储此代理的密钥（以及后来的证书）的密钥库文件。密钥库文件包含此代理的私钥和公钥，因此需要保持安全。理想情况下，此步骤在将使用密钥的 Kafka 代理上运行，因为此密钥永远不应传输/离开它打算用于的服务器。
|
||||
2. 有效期：密钥的有效时间，以天为单位。请注意，这与证书的有效期不同，证书的有效期将在签署证书中确定。您可以使用同一个密钥申请多个证书：如果您的密钥有效期为 10 年，但您的 CA 只会签署有效期为一年的证书，那么随着时间的推移，您可以使用同一个密钥和 10 个证书。
|
||||
|
||||
要获得可与刚刚创建的私钥一起使用的证书，需要创建证书签名请求。当由受信任的 CA 签名时，此签名请求会生成实际证书，然后可以将其安装在密钥库中并用于身份验证。
|
||||
要生成证书签名请求，请对目前创建的所有服务器密钥库运行以下命令。
|
||||
|
||||
```sh
|
||||
|
||||
keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}
|
||||
|
||||
```
|
||||
|
||||
此命令假定您要在证书中添加主机名信息，如果不是这种情况，您可以省略扩展参数`-ext SAN=DNS:{FQDN},IP:{IPADDRESS1}`。有关这方面的更多信息，请参阅下文。
|
||||
|
||||
**主机名验证**
|
||||
|
||||
主机名验证在启用时是检查您要连接的服务器提供的证书中的属性与该服务器的实际主机名或 IP 地址的过程，以确保您确实连接到正确的服务器。
|
||||
此检查的主要原因是防止中间人攻击。对于 Kafka，此检查默认已禁用很长时间，但从 Kafka 2.0.0 开始，默认为客户端连接和代理间连接启用服务器的主机名验证。
|
||||
可以通过设置`ssl.endpoint.identification.algorithm`为空字符串来禁用服务器主机名验证。
|
||||
|
||||
对于动态配置的 Broker Listener，可以使用以下命令禁用主机名验证`kafka-configs.sh`：
|
||||
|
||||
```sh
|
||||
bin/kafka-configs.sh --bootstrap-server localhost:9093 --entity-type brokers --entity-name 0 --alter --add-config "listener.name.internal.ssl.endpoint.identification.algorithm="
|
||||
|
||||
```
|
||||
|
||||
**2. 创建自己的 CA**
|
||||
|
||||
在这一步之后，集群中的每台机器都有一个可以用于加密流量的公钥/私钥对和一个证书签名请求，这是创建证书的基础。要添加身份验证功能，此签名请求需要由受信任的机构签名，该机构将在此步骤中创建。
|
||||
|
||||
证书颁发机构 (CA) 负责签署证书。CA 的工作就像政府颁发护照一样——政府在每本护照上盖章（签名），使护照变得难以伪造。其他政府验证印章以确保护照是真实的。类似地，CA 对证书进行签名，并且加密保证签名证书在计算上难以伪造。
|
||||
|
||||
该步骤省略..
|
||||
|
||||
**3.签署证书**
|
||||
|
||||
**4.生产中的常见陷阱**
|
||||
|
||||
以上段落显示了创建您自己的 CA 并使用它为您的集群签署证书的过程。虽然对于沙盒、开发、测试和类似系统非常有用，但这通常不是为企业环境中的生产集群创建证书的正确过程。企业通常会运营自己的 CA，用户可以发送 CSR 以使用该 CA 进行签名，这样做的好处是用户无需负责维护 CA 的安全以及每个人都可以信任的中央权威。然而，它也剥夺了用户对证书签名过程的大量控制。
|
||||
|
||||
1. 扩展密钥使用
|
||||
证书可能包含一个扩展字段，用于控制证书的使用目的。如果此字段为空，则对使用没有限制，但如果此处指定了任何使用，则有效的 SSL 实现必须强制执行这些使用。
|
||||
Kafka 的相关用法是：
|
||||
客户端认证
|
||||
服务器认证
|
||||
Kafka 代理需要允许这两种用法，因为对于集群内通信，每个代理都将作为客户端和服务器对其他代理进行操作。企业 CA 拥有 web 服务器的签名配置文件并将其用于 Kafka 的情况并不少见，这将仅包含 serverAuth 使用值并导致 SSL 握手失败。
|
||||
2. 中间证书
|
||||
出于安全原因，企业根 CA 通常处于脱机状态。为了实现日常使用，创建了所谓的中间 CA，然后用于签署最终证书。将证书导入由中间 CA 签名的密钥库时，必须提供到根 CA 的整个信任链。这可以通过简单地将证书文件放入一个组合证书文件中，然后使用 keytool 导入来完成 。
|
||||
3. 未能复制扩展字段
|
||||
CA 运营商通常不愿从 CSR 复制和请求扩展字段，而是更愿意自己指定这些字段，因为这使得恶意方更难获得具有潜在误导或欺诈值的证书。建议仔细检查签名证书，这些证书是否包含所有请求的 SAN 字段以启用正确的主机名验证。以下命令可用于将证书详细信息打印到控制台，应与最初请求的内容进行比较：
|
||||
|
||||
```
|
||||
openssl x509 -in certificate.crt -text -noout
|
||||
|
||||
```
|
||||
|
||||
**5.配置 Kafka 代理**
|
||||
|
||||
Kafka Brokers 支持侦听多个端口上的连接。我们需要在 server.properties 中配置以下属性，该属性必须有一个或多个逗号分隔值：
|
||||
|
||||
```
|
||||
listener
|
||||
```
|
||||
|
||||
如果没有为代理间通信启用 SSL（请参阅下文了解如何启用它），则 PLAINTEXT 和 SSL 端口都是必需的。
|
||||
|
||||
```
|
||||
listeners=PLAINTEXT://host.name:port,SSL://host.name:port
|
||||
|
||||
```
|
||||
|
||||
在代理端需要以下 SSL 配置
|
||||
|
||||
```
|
||||
ssl.keystore.location=/var/private/ssl/server.keystore.jks
|
||||
ssl.keystore.password=test1234
|
||||
ssl.key.password=test1234
|
||||
ssl.truststore.location=/var/private/ssl/server.truststore.jks
|
||||
ssl.truststore.password=test1234
|
||||
```
|
||||
|
||||
注意： ssl.truststore.password 在技术上是可选的，但强烈推荐。如果未设置密码，则仍可访问信任库，但禁用完整性检查。值得考虑的可选设置：
|
||||
|
||||
1. ssl.client.auth=none ("required" => 需要客户端身份验证，"requested" => 请求客户端身份验证并且没有证书的客户端仍然可以连接。不鼓励使用“requested”，因为它提供了一种错误的感觉安全和错误配置的客户端仍然会成功连接。）
|
||||
2. ssl.cipher.suites（可选）。密码套件是身份验证、加密、MAC 和密钥交换算法的命名组合，用于协商使用 TLS 或 SSL 网络协议的网络连接的安全设置。（默认为空列表）
|
||||
3. ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1（列出您将从客户端接受的 SSL 协议。请注意，不推荐使用 SSL 以支持 TLS，并且不建议在生产中使用 SSL）
|
||||
4. ssl.keystore.type=JKS
|
||||
5. ssl.truststore.type=JKS
|
||||
6. ssl.secure.random.implementation=SHA1PRNG
|
||||
|
||||
如果要为 Broker 之间间通信启用 SSL，请将以下内容添加到 server.properties 文件（默认为 PLAINTEXT）
|
||||
|
||||
```
|
||||
security.inter.broker.protocol=SSL
|
||||
|
||||
```
|
||||
|
||||
启动代理后，您应该能够在 server.log 中看到
|
||||
|
||||
```
|
||||
with addresses: PLAINTEXT -> EndPoint(xxx.xxx.xx.xx,9092,PLAINTEXT),SSL -> EndPoint(xxx.xxx.xx.xx,9093,SSL)
|
||||
|
||||
```
|
||||
|
||||
要快速检查服务器密钥库和信任库是否设置正确，您可以运行以下命令
|
||||
|
||||
```
|
||||
openssl s_client -debug -connect localhost:9093 -tls1
|
||||
|
||||
```
|
||||
|
||||
（注意：TLSv1 应该列在 ssl.enabled.protocols 下）
|
||||
在此命令的输出中，您应该看到服务器的证书：
|
||||
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
{variable sized random bytes}
|
||||
-----END CERTIFICATE-----
|
||||
subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Sriharsha Chintalapani
|
||||
issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/emailAddress=test@test.com
|
||||
```
|
||||
|
||||
如果证书未显示或有任何其他错误消息，则您的密钥库设置不正确。
|
||||
|
||||
**6.配置 Kafka 客户端**
|
||||
|
||||
仅新的 Kafka 生产者和消费者支持 SSL，不支持旧 API。生产者和消费者的 SSL 配置相同。
|
||||
如果代理中不需要客户端身份验证，那么以下是一个最小配置示例：
|
||||
|
||||
```sh
|
||||
|
||||
security.protocol=SSL
|
||||
ssl.truststore.location=/var/private/ssl/client.truststore.jks
|
||||
ssl.truststore.password=test1234
|
||||
```
|
||||
|
||||
注意：` ssl.truststore.password` 在技术上是可选的，但强烈推荐。如果未设置密码，则仍可访问信任库，但禁用完整性检查。如果需要客户端身份验证，则必须像步骤 1 中一样创建密钥库，并且还必须配置以下内容：
|
||||
|
||||
```sh
|
||||
ssl.keystore.location=/var/private/ssl/client.keystore.jks
|
||||
ssl.keystore.password=test1234
|
||||
ssl.key.password=test1234
|
||||
|
||||
```
|
||||
|
||||
根据我们的要求和代理配置，可能还需要其他配置设置：
|
||||
|
||||
1. ssl.provider（可选）。用于 SSL 连接的安全提供程序的名称。默认值是 JVM 的默认安全提供程序。
|
||||
2. ssl.cipher.suites（可选）。密码套件是身份验证、加密、MAC 和密钥交换算法的命名组合，用于协商使用 TLS 或 SSL 网络协议的网络连接的安全设置。
|
||||
3. ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1。它应该至少列出一个在代理端配置的协议
|
||||
4. ssl.truststore.type=JKS
|
||||
5. ssl.keystore.type=JKS
|
||||
|
||||
使用控制台生产者和控制台消费者的示例：
|
||||
|
||||
```
|
||||
kafka-console-producer.sh --bootstrap-server localhost:9093 --topic test --producer.config client-ssl.properties
|
||||
kafka-console-consumer.sh --bootstrap-server localhost:9093 --topic test --consumer.config client-ssl.properties
|
||||
```
|
||||
|
||||
## 7.3 使用 SASL 进行身份验证
|
||||
|
||||
<font size=5 ><b> 1.JAAS 配置 </b></font>
|
||||
|
||||
Kafka 使用 Java 身份验证和授权服务 ( JAAS ) 进行 SASL 配置。
|
||||
|
||||
**1.Kafka 代理的 JAAS 配置**
|
||||
|
||||
KafkaServer 是每个 KafkaServer/Broker 使用的 JAAS 文件中的部分名称。本节为代理提供 SASL 配置选项，包括代理为进行代理间通信而建立的任何 SASL 客户端连接。如果多个侦听器配置为使用 SASL，则部分名称可以以小写的侦听器名称为前缀，后跟句点，例如 sasl_ssl.KafkaServer。
|
||||
|
||||
客户端部分用于验证与 zookeeper 的 SASL 连接。它还允许代理在 zookeeper 节点上设置 SASL ACL，锁定这些节点，以便只有代理可以修改它。所有代理都必须具有相同的主体名称。如果您想使用 Client 以外的部分名称，请将系统属性 zookeeper.sasl.clientconfig 设置为适当的名称（例如，-Dzookeeper.sasl.clientconfig=ZkClient）。
|
||||
|
||||
ZooKeeper 默认使用“zookeeper”作为服务名称。如果要更改此设置，请将系统属性 zookeeper.sasl.client.username 设置为适当的名称（例如，-Dzookeeper.sasl.client.username=zk）。
|
||||
|
||||
代理还可以使用代理配置属性来配置 JAAS sasl.jaas.config。属性名称必须以包括 SASL 机制的侦听器前缀作为前缀，即 listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config. 配置值中只能指定一个登录模块。如果在侦听器上配置了多个机制，则必须使用侦听器和机制前缀为每个机制提供配置。例如，
|
||||
|
||||
```sh
|
||||
listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
|
||||
username="admin" \
|
||||
password="admin-secret";
|
||||
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
|
||||
username="admin" \
|
||||
password="admin-secret" \
|
||||
user_admin="admin-secret" \
|
||||
user_alice="alice-secret";
|
||||
```
|
||||
|
||||
如果在不同级别定义 JAAS 配置，则使用的优先顺序为：
|
||||
|
||||
- 代理配置属性 listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config
|
||||
- {listenerName}.KafkaServer 静态 JAAS 配置部分
|
||||
- KafkaServer 静态 JAAS 配置部分
|
||||
|
||||
请注意，ZooKeeper JAAS 配置只能使用静态 JAAS 配置进行配置。
|
||||
|
||||
有关代理配置的示例，请参阅[GSSAPI (Kerberos)](https://kafka.apache.org/27/documentation.html#security_sasl_kerberos_brokerconfig)、 [PLAIN](https://kafka.apache.org/27/documentation.html#security_sasl_plain_brokerconfig)、 [SCRAM](https://kafka.apache.org/27/documentation.html#security_sasl_scram_brokerconfig)或 [OAUTHBEARER](https://kafka.apache.org/27/documentation.html#security_sasl_oauthbearer_brokerconfig)。
|
||||
|
||||
**2.Kafka 客户端的 JAAS 配置**
|
||||
|
||||
客户端可以使用客户端配置属性 [sasl.jaas.config](https://kafka.apache.org/27/documentation.html#security_client_dynamicjaas) 或使用 类似于代理的 [静态 JAAS 配置文件来配置 JAAS](https://kafka.apache.org/27/documentation.html#security_client_staticjaas)。
|
||||
|
||||
1. 使用客户端配置属性的 JAAS 配置
|
||||
客户端可以将 JAAS 配置指定为生产者或消费者属性，而无需创建物理配置文件。此模式还允许同一 JVM 中的不同生产者和消费者通过为每个客户端指定不同的属性来使用不同的凭据。如果同时指定了静态 JAAS 配置系统属性 java.security.auth.login.config 和客户端属性 sasl.jaas.config ，则将使用客户端属性。
|
||||
有关示例配置，请参阅[GSSAPI (Kerberos)](https://kafka.apache.org/27/documentation.html#security_sasl_kerberos_brokerconfig)、 [PLAIN](https://kafka.apache.org/27/documentation.html#security_sasl_plain_brokerconfig)、 [SCRAM](https://kafka.apache.org/27/documentation.html#security_sasl_scram_brokerconfig)或 [OAUTHBEARER](https://kafka.apache.org/27/documentation.html#security_sasl_oauthbearer_brokerconfig)。
|
||||
|
||||
2. 使用静态配置文件的 JAAS 配置
|
||||
要使用静态 JAAS 配置文件在客户端上配置 SASL 身份验证：
|
||||
①. 添加一个 JAAS 配置文件，其中包含一个名为 KafkaClient 的客户端登录部分。在 KafkaClient 中为所选机制配置登录模块，如设置 GSSAPI (Kerberos)、 PLAIN、 SCRAM 或 OUTHBEARER 的示例中所述。例如，GSSAPI 凭证可以配置为：
|
||||
```
|
||||
KafkaClient {
|
||||
com.sun.security.auth.module.Krb5LoginModule required
|
||||
useKeyTab=true
|
||||
storeKey=true
|
||||
keyTab="/etc/security/keytabs/kafka_client.keytab"
|
||||
principal="kafka-client-1@EXAMPLE.COM";
|
||||
};
|
||||
```
|
||||
②.将 JAAS 配置文件位置作为 JVM 参数传递给每个客户端 JVM。例如：
|
||||
|
||||
```
|
||||
-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf
|
||||
```
|
||||
|
||||
<font size=5 ><b> 2. SASL 配置 </b></font>
|
||||
|
||||
SASL 可以与 PLAINTEXT 或 SSL 一起用作传输层，分别使用安全协议 SASL_PLAINTEXT 或 SASL_SSL。如果使用 SASL_SSL，则[还必须配置 SSL](https://kafka.apache.org/27/documentation.html#security_ssl)。
|
||||
|
||||
**1.SASL 机制**
|
||||
|
||||
Kafka 支持以下 SASL 机制：
|
||||
|
||||
- GSSAPI (Kerberos)
|
||||
- PLAIN
|
||||
- SCRAM-SHA-256
|
||||
- SCRAM-SHA-512
|
||||
- OAUTHBEARER
|
||||
|
||||
**2.Kafka 代理的 SASL 配置**
|
||||
|
||||
1. 在 server.properties 中配置 SASL 端口，方法是向 listeners 参数添加 SASL_PLAINTEXT 或 SASL_SSL 中的至少一个，该参数包含一个或多个逗号分隔值：
|
||||
|
||||
```
|
||||
|
||||
listeners=SASL_PLAINTEXT://host.name:port
|
||||
|
||||
```
|
||||
|
||||
如果您只配置 SASL 端口（或者如果您希望 Kafka 代理使用 SASL 相互验证），请确保为代理间通信设置相同的 SASL 协议：
|
||||
|
||||
```
|
||||
security.inter.broker.protocol=SASL_PLAINTEXT（或 SASL_SSL）
|
||||
|
||||
```
|
||||
|
||||
2. 选择一种或多种 [受支持的机制](https://kafka.apache.org/27/documentation.html#security_sasl_mechanism) 以在代理中启用，然后按照步骤为该机制配置 SASL。要在代理中启用多种机制，请按照 此处的步骤操作。
|
||||
|
||||
3. Kafka 客户端的 SASL 配置
|
||||
|
||||
仅新的 Java Kafka 生产者和消费者支持 SASL 身份验证，不支持旧 API。
|
||||
|
||||
要在客户端上配置 SASL 身份验证，请选择在代理中为客户端身份验证启用的 SASL [机制](https://kafka.apache.org/27/documentation.html#security_sasl_mechanism)，然后按照步骤为所选机制配置 SASL。
|
||||
|
||||
<font size=5 ><b> 3. 使用 SASL/Kerberos 进行身份验证 </b></font>
|
||||
|
||||
**1. 先决条件**
|
||||
|
||||
1. Kerberos
|
||||
如果您的组织已经在使用 Kerberos 服务器（例如，通过使用 Active Directory），则无需仅为 Kafka 安装新服务器。否则，您将需要安装一个，您的 Linux 供应商可能有 Kerberos 软件包以及如何安装和配置它的简短指南（[Ubuntu](https://help.ubuntu.com/community/Kerberos)、[Redhat](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/installing-kerberos.html)）。请注意，如果您使用的是 Oracle Java，则需要为您的 Java 版本下载 JCE 策略文件并将它们复制到 $JAVA_HOME/jre/lib/security。
|
||||
|
||||
2. 创建 Kerberos 主体
|
||||
|
||||
如果您使用组织的 Kerberos 或 Active Directory 服务器，请向您的 Kerberos 管理员询问集群中每个 Kafka 代理以及将使用 Kerberos 身份验证（通过客户端和工具）访问 Kafka 的每个操作系统用户的主体。
|
||||
如果您已经安装了自己的 Kerberos，则需要使用以下命令自己创建这些主体：
|
||||
|
||||
```
|
||||
|
||||
sudo /usr/sbin/kadmin.local -q 'addprinc -randkey kafka/{hostname}@{REALM}'
|
||||
sudo /usr/sbin/kadmin.local -q "ktadd -k /etc/security/keytabs/{keytabname}.keytab kafka/{hostname}@{REALM}"
|
||||
|
||||
```
|
||||
|
||||
3. 确保可以使用主机名访问所有主机- Kerberos 要求您的所有主机都可以使用它们的 FQDN 进行解析。
|
||||
|
||||
**2.配置 Kafka Broker**
|
||||
|
||||
1. 在每个 Kafka 代理的配置目录中添加一个经过适当修改的 JAAS 文件，类似于下面的文件，我们将其命名为 kafka_server_jaas.conf （请注意，每个代理都应该有自己的密钥表）：
|
||||
|
||||
```
|
||||
|
||||
KafkaServer {
|
||||
com.sun.security.auth.module.Krb5LoginModule required
|
||||
useKeyTab=true
|
||||
storeKey=true
|
||||
keyTab="/etc/security/keytabs/kafka_server.keytab"
|
||||
principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
|
||||
};
|
||||
|
||||
// Zookeeper client authentication
|
||||
Client {
|
||||
com.sun.security.auth.module.Krb5LoginModule required
|
||||
useKeyTab=true
|
||||
storeKey=true
|
||||
keyTab="/etc/security/keytabs/kafka_server.keytab"
|
||||
principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
JAAS 文件中的 KafkaServer 部分告诉代理要使用哪个主体以及存储该主体的密钥表的位置。它允许代理使用本节中指定的密钥表登录。有关 Zookeeper SASL 配置的更多详细信息，请参阅[注释](https://kafka.apache.org/27/documentation.html#security_jaas_broker)。
|
||||
|
||||
2. 将 JAAS 和可选的 krb5 文件位置作为 JVM 参数传递给每个 Kafka 代理（请参阅[此处](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/KerberosReq.html)了解更多详细信息）：
|
||||
|
||||
```
|
||||
-Djava.security.krb5.conf=/etc/kafka/krb5.conf
|
||||
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
|
||||
```
|
||||
|
||||
3. 确保启动 kafka 代理的操作系统用户可以读取 JAAS 文件中配置的密钥表。
|
||||
|
||||
4. 在 server.properties 中配置 SASL 端口和 SASL 机制。例如：
|
||||
|
||||
```
|
||||
listeners=SASL_PLAINTEXT://host.name:port
|
||||
security.inter.broker.protocol=SASL_PLAINTEXT
|
||||
sasl.mechanism.inter.broker.protocol=GSSAPI
|
||||
sasl.enabled.mechanisms=GSSAPI
|
||||
```
|
||||
|
||||
我们还必须在 server.properties 中配置服务名称，该名称应与 kafka 代理的主体名称匹配。在上面的例子中，principal 是
|
||||
“kafka/kafka1.hostname.com@EXAMPLE.com”，所以：
|
||||
|
||||
```
|
||||
sasl.kerberos.service.name=kafka
|
||||
|
||||
```
|
||||
|
||||
**3.配置 Kafka 客户端**
|
||||
|
||||
在客户端上配置 SASL 身份验证：
|
||||
|
||||
1. 客户端（生产者、消费者、连接工作人员等）将使用自己的主体（通常与运行客户端的用户同名）向集群进行身份验证，因此根据需要获取或创建这些主体。然后为每个客户端配置 JAAS 配置属性。通过指定不同的主体，JVM 中的不同客户端可以作为不同的用户运行。producer.properties 或 consumer.properties 中的属性 sasl.jaas.config 描述了像 producer 和 consumer 这样的客户端如何连接到 Kafka Broker。以下是使用 keytab 的客户端的示例配置（推荐用于长时间运行的进程）：
|
||||
|
||||
```
|
||||
sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
|
||||
useKeyTab=true \
|
||||
storeKey=true \
|
||||
keyTab="/etc/security/keytabs/kafka_client.keytab" \
|
||||
principal="kafka-client-1@EXAMPLE.COM";
|
||||
```
|
||||
|
||||
对于像 kafka-console-consumer 或 kafka-console-producer 这样的命令行实用程序，kinit 可以与“useTicketCache=true”一起使用，如下所示：
|
||||
|
||||
```
|
||||
sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
|
||||
useTicketCache=true;
|
||||
```
|
||||
|
||||
客户端的 JAAS 配置也可以指定为类似于[此处](https://kafka.apache.org/27/documentation.html#security_client_staticjaas)描述的代理的 JVM 参数。客户端使用名为 KafkaClient 的登录部分 。此选项仅允许一个用户用于来自 JVM 的所有客户端连接。
|
||||
|
||||
2. 确保启动 kafka 客户端的操作系统用户可以读取 JAAS 配置中配置的密钥表。
|
||||
3. 可选择将 krb5 文件位置作为 JVM 参数传递给每个客户端 JVM（
|
||||
```
|
||||
-Djava.security.krb5.conf=/etc/kafka/krb5.conf
|
||||
```
|
||||
4. 在 producer.properties 或 consumer.properties 中配置以下属性：
|
||||
```
|
||||
security.protocol=SASL_PLAINTEXT (or SASL_SSL)
|
||||
sasl.mechanism=GSSAPI
|
||||
sasl.kerberos.service.name=kafka
|
||||
```
|
||||
|
||||
<font size=5 ><b> 4.使用 SASL/PLAIN 进行身份验证 </b></font>
|
||||
|
||||
SASL/PLAIN 是一种简单的用户名/密码认证机制，通常与 TLS 一起用于加密以实现安全认证。Kafka 支持 SASL/PLAIN 的默认实现，可以按照[此处](https://kafka.apache.org/27/documentation.html#security_sasl_plain_production)所述进行扩展以供生产使用。
|
||||
|
||||
Principal 用户名用作配置 ACL 等 的身份验证。
|
||||
|
||||
**1. 配置 Kafka 代理**
|
||||
|
||||
1. 在每个 Kafka 代理的配置目录中添加一个经过适当修改的 JAAS 文件，类似于下面的文件，我们将其命名为 kafka_server_jaas.conf 以用于本示例：
|
||||
|
||||
```
|
||||
KafkaServer {
|
||||
org.apache.kafka.common.security.plain.PlainLoginModule required
|
||||
username="admin"
|
||||
password="admin-secret"
|
||||
user_admin="admin-secret"
|
||||
user_alice="alice-secret";
|
||||
};
|
||||
```
|
||||
|
||||
此配置定义了两个用户（admin 和 alice）。KafkaServer 部分 中的属性用户名和密码由代理用于启动与其他代理的连接。在本例中， admin 是代理间通信的用户。属性集 user_userName 定义了连接到代理的所有用户的密码，代理使用这些属性验证所有客户端连接，包括来自其他代理的连接。
|
||||
|
||||
2. 将 JAAS 配置文件位置作为 JVM 参数传递给每个 Kafka 代理：
|
||||
|
||||
```
|
||||
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
|
||||
|
||||
```
|
||||
|
||||
3. 在 server.properties 中配置 SASL 端口和 SASL 机制。例如
|
||||
```
|
||||
listeners=SASL_SSL://host.name:port
|
||||
security.inter.broker.protocol=SASL_SSL
|
||||
sasl.mechanism.inter.broker.protocol=PLAIN
|
||||
sasl.enabled.mechanisms=PLAIN
|
||||
```
|
||||
|
||||
**2. 配置 Kafka 客户端**
|
||||
|
||||
在客户端上配置 SASL 身份验证：
|
||||
|
||||
1. 在 producer.properties 或 consumer.properties 中为每个客户端配置 JAAS 配置属性。登录模块描述了生产者和消费者等客户端如何连接到 Kafka 代理。以下是 PLAIN 机制的客户端的示例配置：
|
||||
|
||||
```
|
||||
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
|
||||
username="alice" \
|
||||
password="alice-secret";
|
||||
```
|
||||
|
||||
客户端使用选项用户名和密码来配置用户以进行客户端连接。在此示例中，客户端以用户 alice 的身份连接到代理。JVM 中的不同客户端可以通过在 sasl.jaas.config.
|
||||
|
||||
客户端的 JAAS 配置也可以指定为类似于此处描述的代理的 JVM 参数。客户端使用名为 KafkaClient 的登录部分 。此选项仅允许一个用户用于来自 JVM 的所有客户端连接。
|
||||
|
||||
2. 在 producer.properties 或 consumer.properties 中配置以下属性：
|
||||
|
||||
```
|
||||
security.protocol=SASL_SSL
|
||||
sasl.mechanism=PLAIN
|
||||
```
|
||||
|
||||
3. 在生产中使用 SASL/PLAIN
|
||||
|
||||
- SASL/PLAIN 应仅与 SSL 作为传输层一起使用，以确保在未加密的情况下不会在线路上传输明文密码。
|
||||
- Kafka 中 SASL/PLAIN 的默认实现在 JAAS 配置文件中指定用户名和密码，如下 所示。从 Kafka 版本 2.0 开始，您可以通过配置自己的回调处理程序来避免在磁盘上存储明确的密码，这些回调处理程序使用配置选项从外部源获取用户名和密码， sasl.server.callback.handler.class 并且 sasl.client.callback.handler.class.
|
||||
- 在生产系统中，外部认证服务器可以实现密码认证。从 Kafka 2.0 版开始，您可以插入自己的回调处理程序，这些处理程序使用外部身份验证服务器通过配置 sasl.server.callback.handler.class.
|
||||
|
||||
<font size=5 ><b> 5. 使用 SASL/SCRAM 进行身份验证 </b></font>
|
||||
|
||||
Salted Challenge Response Authentication Mechanism (SCRAM) 是一系列 SASL 机制，可解决执行用户名/密码验证的传统机制（如 PLAIN 和 DIGEST-MD5）的安全问题。该机制在 RFC 5802 中定义。Kafka 支持 SCRAM-SHA-256 和 SCRAM-SHA-512，可与 TLS 一起使用以执行安全身份验证。用户名用作 PrincipalACL 等配置的身份验证。Kafka 中的默认 SCRAM 实现将 SCRAM 凭据存储在 Zookeeper 中，适用于 Zookeeper 在专用网络上的 Kafka 安装。有关更多详细信息，请参阅安全注意事项 。
|
||||
|
||||
<font size=5 ><b> 6. 使用 SASL/OAUTHBEARER 进行身份验证 </b></font>
|
||||
|
||||
<font size=5 ><b> 7. 在代理中启用多个 SASL 机制 </b></font>
|
||||
|
||||
[在代理中启用多个 SASL 机制](https://kafka.apache.org/27/documentation.html#security_overview)
|
||||
|
||||
<font size=5 ><b> 8. 在正在运行的集群中修改 SASL 机制 </b></font>
|
||||
|
||||
可以使用以下顺序在正在运行的集群中修改 SASL 机制：
|
||||
|
||||
1. 通过将机制添加到每个代理的 server.properties 中的 sasl.enabled.mechanisms 来启用新的 SASL 机制。更新 JAAS 配置文件以包括此处所述的两种机制。增量反弹集群节点。
|
||||
2. 使用新机制重新启动客户端。
|
||||
3. 要更改代理间通信的机制（如果需要），请将 server.properties 中的 sasl.mechanism.inter.broker.protocol 设置为新机制并再次增量反弹集群。
|
||||
4. 要删除旧机制（如果需要），请从 server.properties 中的 sasl.enabled.mechanisms 中删除旧机制，并从 JAAS 配置文件中删除旧机制的条目。再次增量反弹集群。
|
||||
|
||||
## 7.4 授权和 ACL
|
||||
|
||||
[授权和 ACL](https://kafka.apache.org/27/documentation.html#security_authz)
|
||||
|
||||
## 7.5 在运行的集群中加入安全特性
|
||||
|
||||
您可以通过前面讨论的一种或多种支持的协议来保护正在运行的集群。这是分阶段完成的：
|
||||
|
||||
- 增量反弹集群节点以打开额外的安全端口。
|
||||
- 使用安全端口而不是 PLAINTEXT 端口重新启动客户端（假设您正在保护客户端-代理连接）。
|
||||
- 再次增量反弹集群以启用代理到代理的安全性（如果需要）
|
||||
- 关闭 PLAINTEXT 端口的最终增量反弹
|
||||
|
||||
配置 SSL 和 SASL 的具体步骤在 7.2 和 7.3 节中描述。按照以下步骤启用所需协议的安全性。
|
||||
|
||||
安全实现允许您为代理-客户端和代理-代理通信配置不同的协议。这些必须在单独的退回中启用。PLAINTEXT 端口必须始终保持打开状态，以便代理和/或客户端可以继续通信。
|
||||
当执行增量反弹时，通过 SIGTERM 干净地停止代理。在移动到下一个节点之前，等待重新启动的副本返回 ISR 列表也是一种很好的做法。
|
||||
例如，假设我们希望使用 SSL 加密代理-客户端和代理-代理通信。在第一次增量反弹中，每个节点上都会打开一个 SSL 端口：
|
||||
|
||||
```
|
||||
listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092
|
||||
|
||||
```
|
||||
|
||||
然后我们重新启动客户端，将它们的配置更改为指向新打开的安全端口：
|
||||
|
||||
```
|
||||
bootstrap.servers = [broker1:9092,...]
|
||||
security.protocol = SSL
|
||||
...etc
|
||||
```
|
||||
|
||||
在第二次增量服务器反弹中，我们指示 Kafka 使用 SSL 作为代理-代理协议（它将使用相同的 SSL 端口）：
|
||||
|
||||
```
|
||||
listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092
|
||||
security.inter.broker.protocol=SSL
|
||||
```
|
||||
|
||||
在最后的反弹中，我们通过关闭 PLAINTEXT 端口来保护集群：
|
||||
|
||||
```
|
||||
listeners=SSL://broker1:9092
|
||||
security.inter.broker.protocol=SSL
|
||||
|
||||
```
|
||||
|
||||
或者，我们可以选择打开多个端口，以便可以使用不同的协议进行代理-代理和代理-客户端通信。假设我们希望始终使用 SSL 加密（即用于代理-代理和代理-客户端通信），但我们还想将 SASL 身份验证添加到代理-客户端连接。我们将通过在第一次反弹期间打开两个额外的端口来实现这一点：
|
||||
|
||||
```
|
||||
listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093
|
||||
|
||||
```
|
||||
|
||||
然后我们将重新启动客户端，将它们的配置更改为指向新打开的 SASL 和 SSL 安全端口：
|
||||
|
||||
```
|
||||
bootstrap.servers = [broker1:9093,...]
|
||||
security.protocol = SASL_SSL
|
||||
...etc
|
||||
```
|
||||
|
||||
第二个服务器反弹将通过我们之前在端口 9092 上打开的 SSL 端口切换集群以使用加密的代理-代理通信
|
||||
|
||||
```
|
||||
listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093
|
||||
security.inter.broker.protocol=SSL
|
||||
```
|
||||
|
||||
最后的反弹通过关闭 PLAINTEXT 端口来保护集群。
|
||||
|
||||
```
|
||||
listeners=SSL://broker1:9092,SASL_SSL://broker1:9093
|
||||
security.inter.broker.protocol=SSL
|
||||
```
|
||||
|
||||
ZooKeeper 可以独立于 Kafka 集群进行保护。执行此操作的步骤在第 7.6.2 节中介绍。
|
||||
|
||||
## 7.6 Zookeeper 认证
|
||||
|
||||
[Zookeeper 认证](https://kafka.apache.org/27/documentation.html#zk_authz)
|
||||
|
||||
## 7.7 ZooKeeper 加密
|
||||
|
||||
使用双向 TLS 的 ZooKeeper 连接是加密的。从 ZooKeeper 版本 3.5.7（随 Kafka 版本 2.5 发布的版本）开始 ZooKeeper 支持服务器端配置 ssl.clientAuth（不区分大小写：需要/需要/无是有效选项，默认为需要），并设置此 ZooKeeper 中的 value 为 none 允许客户端通过 TLS 加密的连接进行连接，而无需提供自己的证书。这是一个示例（部分）Kafka Broker 配置，用于仅使用 TLS 加密连接到 ZooKeeper。这些配置在上面的 Broker Configs 中进行了描述。
|
||||
|
||||
```
|
||||
# connect to the ZooKeeper port configured for TLS
|
||||
zookeeper.connect=zk1:2182,zk2:2182,zk3:2182
|
||||
# required to use TLS to ZooKeeper (default is false)
|
||||
zookeeper.ssl.client.enable=true
|
||||
# required to use TLS to ZooKeeper
|
||||
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
|
||||
# define trust stores to use TLS to ZooKeeper; ignored unless zookeeper.ssl.client.enable=true
|
||||
# no need to set keystore information assuming ssl.clientAuth=none on ZooKeeper
|
||||
zookeeper.ssl.truststore.location=/path/to/kafka/truststore.jks
|
||||
zookeeper.ssl.truststore.password=kafka-ts-passwd
|
||||
# tell broker to create ACLs on znodes (if using SASL authentication, otherwise do not set this)
|
||||
zookeeper.set.acl=true
|
||||
```
|
||||
154
study-kafka/8-kafka-connect.md
Normal file
154
study-kafka/8-kafka-connect.md
Normal file
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: 8.Kafka Connect
|
||||
order: 8
|
||||
toc: menu
|
||||
---
|
||||
|
||||
# 8. Kafka Connect
|
||||
|
||||
## 8.1 概述
|
||||
|
||||
Kafka Connect 是一种用于在 Apache Kafka 和其他系统之间可扩展且可靠地流式传输数据的工具。它使快速定义将大量数据移入和移出 Kafka 的连接器变得简单。Kafka Connect 可以摄取整个数据库或将所有应用服务器的指标收集到 Kafka 主题中，从而使数据可用于低延迟的流处理。导出作业可以将来自 Kafka 主题的数据传送到辅助存储和查询系统或批处理系统以进行离线分析。
|
||||
|
||||
Kafka Connect 功能包括：
|
||||
|
||||
- **Kafka 连接器的通用框架**——Kafka Connect 标准化了其他数据系统与 Kafka 的集成，简化了连接器的开发、部署和管理
|
||||
- **分布式和独立模式**- 扩展到支持整个组织的大型集中管理服务或缩减到开发、测试和小型生产部署
|
||||
- **REST 接口**- 通过易于使用的 REST API 向 Kafka Connect 集群提交和管理连接器
|
||||
- **自动偏移管理**——只需来自连接器的少量信息，Kafka Connect 就可以自动管理偏移提交过程，因此连接器开发人员无需担心连接器开发中容易出错的部分
|
||||
- **默认情况下是分布式和可扩展的**——Kafka Connect 建立在现有的组管理协议之上。可以添加更多工作人员来扩展 Kafka Connect 集群。
|
||||
- **流/批处理集成**——利用 Kafka 的现有功能，Kafka Connect 是连接流和批处理数据系统的理想解决方案
|
||||
|
||||
## 8.2 用户指南
|
||||
|
||||
<font size=5 ><b> 运行 Kafka Connect </b></font>
|
||||
|
||||
Kafka Connect 目前支持两种执行模式：独立（单进程）和分布式。
|
||||
|
||||
在独立模式下，所有工作都在一个进程中执行。此配置更易于设置和开始使用，并且在只有一个工作人员有意义的情况下（例如收集日志文件）可能很有用，但它不能从 Kafka Connect 的某些功能（例如容错）中受益。您可以使用以下命令启动独立进程：
|
||||
|
||||
```
|
||||
|
||||
> bin/connect-standalone.sh config/connect-standalone.properties connector1.properties [connector2.properties ...]
|
||||
|
||||
|
||||
```
|
||||
|
||||
第一个参数是 worker 的配置。这包括诸如 Kafka 连接参数、序列化格式以及提交偏移量的频率等设置。提供的示例应该适用于使用 config/server.properties. 它将需要调整以用于不同的配置或生产部署。所有工作人员（独立和分布式）都需要一些配置：
|
||||
|
||||
- `bootstrap.servers`- 用于引导连接到 Kafka 的 Kafka 服务器列表
|
||||
- `key.converter` - 转换器类用于在 Kafka Connect 格式和写入 Kafka 的序列化格式之间进行转换。这控制了写入 Kafka 或从 Kafka 读取的消息中键的格式，并且由于它独立于连接器，它允许任何连接器使用任何序列化格式。常见格式的示例包括 JSON 和 Avro。
|
||||
- `value.converter`- 转换器类用于在 Kafka Connect 格式和写入 Kafka 的序列化格式之间进行转换。这控制了写入或读取 Kafka 的消息中值的格式，并且由于它独立于连接器，它允许任何连接器使用任何序列化格式。常见格式的示例包括 JSON 和 Avro。
|
||||
|
||||
特定于独立模式的重要配置选项是：
|
||||
|
||||
- `offset.storage.file.filename`- 用于存储偏移数据的文件
|
||||
|
||||
此处配置的参数旨在供 Kafka Connect 使用的生产者和消费者访问配置、偏移和状态主题。Kafka 源任务使用的生产者和 Kafka 接收器任务使用的消费者的配置，可以使用相同的参数，但需要分别加上 producer.and 前缀 consumer.。唯一从工作配置中继承的不带前缀的 Kafka 客户端参数是 bootstrap.servers，这在大多数情况下就足够了，因为同一个集群通常用于所有目的。一个值得注意的例外是安全集群，它需要额外的参数才能允许连接。这些参数最多需要在工作器配置中设置 3 次，一次用于管理访问，一次用于 Kafka 源，一次用于 Kafka 接收器。
|
||||
|
||||
从 2.3.0 开始，客户端配置覆盖可以通过使用前缀`producer.override`.和`consumer.override`.Kafka 源或 Kafka 接收器分别为每个连接器单独配置。这些覆盖包含在连接器的其余配置属性中。
|
||||
|
||||
其余参数是连接器配置文件。您可以包含任意数量的内容，但所有内容都将在同一个进程中执行（在不同的线程上）。
|
||||
|
||||
分布式模式处理工作的自动平衡，允许您动态扩展（或缩减），并在活动任务以及配置和偏移提交数据中提供容错。执行与独立模式非常相似：
|
||||
|
||||
```
|
||||
|
||||
> bin/connect-distributed.sh config/connect-distributed.properties
|
||||
|
||||
```
|
||||
|
||||
不同之处在于启动的类和配置参数，这些参数改变了 Kafka Connect 进程决定在哪里存储配置、如何分配工作以及在哪里存储偏移量和任务状态的配置参数。在分布式模式下，Kafka Connect 将偏移量、配置和任务状态存储在 Kafka 主题中。建议手动创建偏移量、配置和状态的主题，以实现所需的分区数和复制因子。如果在启动 Kafka Connect 时尚未创建主题，则会使用默认的分区数和复制因子自动创建主题，这可能不适合其使用。
|
||||
|
||||
特别是，除了上面提到的常见设置之外，以下配置参数对于在启动集群之前进行设置至关重要：
|
||||
|
||||
- group.id（默认 connect-cluster）- 集群的唯一名称，用于形成 Connect 集群组；请注意，这不能与消费者组 ID 冲突
|
||||
- config.storage.topic（默认 connect-configs）- 用于存储连接器和任务配置的主题；请注意，这应该是单个分区、高度复制、压缩的主题。您可能需要手动创建主题以确保正确配置，因为自动创建的主题可能有多个分区或自动配置为删除而不是压缩
|
||||
- offset.storage.topic（默认 connect-offsets） - 用于存储偏移量的主题；这个主题应该有很多分区，被复制，并被配置为压缩
|
||||
- status.storage.topic（默认 connect-status） - 用于存储状态的主题；这个主题可以有多个分区，并且应该被复制并配置为压缩
|
||||
|
||||
请注意，在分布式模式下，连接器配置不会在命令行上传递。相反，使用下面描述的 REST API 来创建、修改和销毁连接器。
|
||||
|
||||
<font size=5 ><b> 配置 Connect </b></font>
|
||||
|
||||
连接器配置是简单的键值映射。对于独立模式，这些是在属性文件中定义的，并在命令行上传递给 Connect 进程。在分布式模式下，它们将包含在创建（或修改）连接器的请求的 JSON 有效负载中。
|
||||
|
||||
大多数配置都依赖于连接器，因此此处无法概述。但是，有一些常见的选项：
|
||||
|
||||
- name- 连接器的唯一名称。尝试使用相同名称再次注册将失败。
|
||||
- connector.class- 连接器的 Java 类
|
||||
- tasks.max- 应为此连接器创建的最大任务数。如果连接器无法达到这种并行度，它可能会创建更少的任务。
|
||||
- key.converter- （可选）覆盖工作人员设置的默认密钥转换器。
|
||||
- value.converter- （可选）覆盖工人设置的默认值转换器。
|
||||
|
||||
`connector.class`配置支持多种格式：此连接器的类的全名或别名。如果连接器是 org.apache.kafka.connect.file.FileStreamSinkConnector，您可以指定此全名或使用 FileStreamSink 或 FileStreamSinkConnector 使配置更短一些。
|
||||
|
||||
接收器连接器还有一些额外的选项来控制它们的输入。每个接收器连接器必须设置以下之一：
|
||||
|
||||
`topics`- 以逗号分隔的主题列表，用作此连接器的输入
|
||||
`topics.regex`- 用作此连接器输入的主题的 Java 正则表达式
|
||||
|
||||
<font size=5 ><b> transforms </b></font>
|
||||
|
||||
[transforms](https://kafka.apache.org/27/documentation.html#connect_transforms)
|
||||
|
||||
<font size=5 ><b> Rest Api </b></font>
|
||||
|
||||
由于 Kafka Connect 旨在作为服务运行，因此它还提供了用于管理连接器的 REST API。可以使用 listeners 配置选项配置 REST API 服务器。此字段应包含以下格式的侦听器列表：`protocol://host:port,protocol2://host2:port2. `当前支持的协议是 http 和 https。例如：
|
||||
|
||||
```
|
||||
|
||||
listeners=http://localhost:8080,https://localhost:8443
|
||||
|
||||
```
|
||||
|
||||
默认情况下，如果未 listeners 指定，则 REST 服务器使用 HTTP 协议在端口 8083 上运行。使用 HTTPS 时，配置必须包含 SSL 配置。默认情况下，它将使用 ssl.*设置。如果需要对 REST API 使用与连接到 Kafka 代理不同的配置，则字段可以以 listeners.https. 使用前缀时，只会使用带前缀的 ssl.*选项，不带前缀的选项将被忽略。以下字段可用于为 REST API 配置 HTTPS：
|
||||
|
||||
- ssl.keystore.location
|
||||
- ssl.keystore.password
|
||||
- ssl.keystore.type
|
||||
- ssl.key.password
|
||||
- ssl.truststore.location
|
||||
- ssl.truststore.password
|
||||
- ssl.truststore.type
|
||||
- ssl.enabled.protocols
|
||||
- ssl.provider
|
||||
- ssl.protocol
|
||||
- ssl.cipher.suites
|
||||
- ssl.keymanager.algorithm
|
||||
- ssl.secure.random.implementation
|
||||
- ssl.trustmanager.algorithm
|
||||
- ssl.endpoint.identification.algorithm
|
||||
- ssl.client.auth
|
||||
|
||||
REST API 不仅被用户用来监控/管理 Kafka Connect。它还用于 Kafka Connect 跨集群通信。在跟随节点 REST API 上收到的请求将被转发到领导节点 REST API。如果给定主机可达的 URI 与其侦听的 URI 不同，则配置选项 rest.advertised.host.name 可 rest.advertised.port 用于 rest.advertised.listener 更改跟随者节点用于连接领导者的 URI。同时使用 HTTP 和 HTTPS 侦听器时，该 rest.advertised.listener 选项还可用于定义哪个侦听器将用于跨集群通信。当使用 HTTPS 进行节点之间的通信时，将使用相同的 ssl.\*或 listeners.https 选项来配置 HTTPS 客户端。
|
||||
|
||||
以下是当前支持的 REST API 端点：
|
||||
|
||||
- GET /connectors- 返回活动连接器列表
|
||||
- POST /connectors- 创建一个新的连接器；请求正文应该是一个 JSON 对象，其中包含一个字符串 name 字段和一个 config 带有连接器配置参数的对象字段
|
||||
- GET /connectors/{name}- 获取有关特定连接器的信息
|
||||
- GET /connectors/{name}/config- 获取特定连接器的配置参数
|
||||
- PUT /connectors/{name}/config- 更新特定连接器的配置参数
|
||||
- GET /connectors/{name}/status- 获取连接器的当前状态，包括它是否正在运行、失败、暂停等，它被分配给哪个工作人员，如果它失败了，错误信息，以及它所有任务的状态
|
||||
- GET /connectors/{name}/tasks- 获取当前为连接器运行的任务列表
|
||||
- GET /connectors/{name}/tasks/{taskid}/status- 获取任务的当前状态，包括它是否正在运行、失败、暂停等，它被分配到哪个工作人员，以及失败时的错误信息
|
||||
- PUT /connectors/{name}/pause- 暂停连接器及其任务，这会停止消息处理，直到连接器恢复
|
||||
- PUT /connectors/{name}/resume- 恢复暂停的连接器（如果连接器未暂停，则不执行任何操作）
|
||||
- POST /connectors/{name}/restart- 重新启动连接器（通常是因为它失败了）
|
||||
- POST /connectors/{name}/tasks/{taskId}/restart- 重新启动单个任务（通常是因为它失败了）
|
||||
- DELETE /connectors/{name}- 删除连接器，停止所有任务并删除其配置
|
||||
- GET /connectors/{name}/topics- 获取特定连接器自创建连接器或发出重置其活动主题集的请求以来正在使用的主题集
|
||||
- PUT /connectors/{name}/topics/reset- 发送请求以清空连接器的活动主题集
|
||||
|
||||
Kafka Connect 还提供了一个 REST API，用于获取有关连接器插件的信息：
|
||||
|
||||
- GET /connector-plugins- 返回安装在 Kafka Connect 集群中的连接器插件列表。请注意，API 仅检查处理请求的工作人员上的连接器，这意味着您可能会看到不一致的结果，尤其是在滚动升级期间，如果您添加了新的连接器 jar
|
||||
- PUT /connector-plugins/{connector-type}/config/validate- 根据配置定义验证提供的配置值。此 API 执行每个配置验证，在验证期间返回建议值和错误消息。
|
||||
以下是顶级（根）端点上受支持的 REST 请求：
|
||||
|
||||
- GET /- 返回有关 Kafka Connect 集群的基本信息，例如为 REST 请求提供服务的 Connect worker 的版本（包括源代码的 git commit ID）和连接的 Kafka 集群 ID
|
||||
|
||||
## 8.3 Connect 开发指南
|
||||
|
||||
[Connect 开发指南](https://kafka.apache.org/27/documentation.html#connect_development)
|
||||
7
study-kafka/9-kafka-stream.md
Normal file
7
study-kafka/9-kafka-stream.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: 9.Kafka Streams
|
||||
order: 9
|
||||
toc: menu
|
||||
---
|
||||
|
||||
[Kafka Stream](https://kafka.apache.org/27/documentation/streams/)
|
||||
Reference in New Issue
Block a user