csdn_manong1的博客

Kafka系统的灵活多变，让它拥有丰富的拓展性，可以与第三方套件很方便的对接。例如，实时计算引擎Spark。接下来通过一个完整案例，运用Kafka和Spark来合理完成。

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。其核心组件包含Producer、Broker、Consumer，以及依赖的Zookeeper集群。其中Zookeeper集群是Kafka用来负责集群元数据的管理、控制器的选举等。

绝大多数是读取请求；数据以相当大的Batch进行更新；已存储的数据不能随意修改；对于读取，从数据存储中提取相当多的行，但是只提取列的一小部分；大宽表，即每个表包含着大量的列；查询相对较少（QPS很小）；对于简单查询，允许有较低的延迟，比如50ms~100ms；列中的数据相对较小，比如字符串长度很短；处理单个查询时需要高吞吐量；事务非必须；对数据一致性要求低；每一个查询有一个大表，除了它其他都是很小的；查询结果明显小于源数据。

Kafka核心组件整体来说比较好理解，实际在编写应用程序时，用到比较频繁的就是生产者和消费者，因此，处理学会应用之外，我们还需要更近一步的来了解Kafka的核心组件。

支持多组件，比如HDFS、Hive、Kafka等，基本能覆盖现有大数据组件；支持日志审计，便于问题排查；用于自己的用户管理体系，方便和其他系统集成。

用户可以通过浏览器界面访问Kibana来制定不同的筛选规则，查询存储在ElasticSearch集群中的异常日志数据。返回的结果在浏览器界面通过表格或者JSON对象的形式进行展示，一目了然。

最近，有同学留言关于SQL解析器方面的问题，今天笔者就为大家分享一下SQL解析器方便的一些内容。

当我们管理Kafka多集群或者一个规模较大的Kafka集群时，单机模式的EFAK部署时，运行的多线程任务，相关消费者、Topic、生产者、Broker & Zookeeper的监控指标等内容调度时，部署EFAK的服务器如果配置较低，会造成很大的负载，对CPU的负载会很高。如果管理的Kafka集群规模较小，Topic数量、消费者应用等较少，可以使用EFAK的单机模式部署即可。

Kafka 连接器可以从DB存储或应用程序服务器收集数据到Topic，使数据可用于低延迟的流处理。导出作业可以将数据从Topic传输到二次存储和查询系统，或者传递到批处理系统以便进行离线分析。

Kafka 3.0 的发布标志着社区对 Kafka 项目迈向了一个新的里程牌。正式改名为EFAK），EFAK会持续更新迭代优化，为大家管理Kafka集群和使用Kafka应用提供便利，欢迎大家使用EFAK，也可以到Github或者EAFK官网上关注EFAK的最新动态。

如果使用压缩策略清除过期日志，则需设置属性“log.cleanup.policy”的值为“compact”。压缩清除只能针对特定的主题应用，即，写的消息数据都包含Key。它会合并相同Key的消息数据，只留下最新的消息数据。

对于存储在Kafka系统内的数据，Kafka系统提供了一种进行处理和分析的功能——流处理，它具有以下特性。通常情况下，流式计算与批处理计算会放在一起做比较分析。（1）在流式计算模型中，数据的输入是持续不断的，这意味着永远不知道数据的上限是多少，因此，计算产生的结果也是持续输出的，流程如下图所示。流式计算一般对实时性要求较高，为了提升计算效率，通常会采用增量计算来替代全量计算。（2）在批处理计算模型中，通常数据上限是可知的，一般会先定义计算逻辑，然后进行全量计算，并将计算结果一次性输出。流程如下图所示。

从Kafka2.8版本开始，可以不用Apache Zookeeper来作为Kafka的依赖组件了，官网把这种称之为KRaft模式。目前，Kafka使用Zookeeper来存储有关分区和Broker的元数据，并选择一个Broker作为Kafka的Controller。现在官网打算删除对Zookeeper的依赖，让Kafka能够以更具扩展性和更加强大的方式管理元数据，从而支持更多分区。

在大数据的浪潮下，时时刻刻都会产生大量的数据。比如社交媒体、博客、电子商务等等，这些数据会以不同的类型存储在不同的平台里面。为了执行ETL（提取、转换、加载）操作，需要一个消息中间件系统，该系统应该是异步和低耦合的，即来自各种存储系统（如HDFS、Cassandra、RDBMS等）的数据可以同时转存在一个地方，而所有这些数据源都是彼此独立的。解决这个问题的方法之一是Kafka，它是一个开源的分布式消息处理平台。

Kafka是一个分布式消息中间件系统，里面存储着实际场景中的数据。Kafka原生是不支持点查询的，如果我们想对存储在Topic中的数据进行查询，可能需要对Topic中的数据进行消费落地，然后构建索引（或者数据落地到自带所以的存储系统中，例如HBase、Hive等）。今天，笔者就为大家来介绍如何实现Kafka分布式查询引擎。

以上就是笔者给大家简要的汇总了Kafka的各个知识点，包含常见的术语、Consumer & Producer的使用方式、存储流程等。

最近有同学咨询Kafka的消费和心跳机制，今天笔者将通过这篇博客来逐一介绍这些内容。

Kafka Eagle提供了简单易用的操作界面，支持Kafka和Zookeeper的ACL认证监控，满足常规的消费者组、集群性能、消息容量、多集群管理、多IM告警（微信、钉钉、邮件、WebHook）等多功能。超过1300+，处理大家提交的Issue 300+多个，如果你Kafka集群缺少监控，不妨可以试试Kafka Eagle。

在Kafka 0.9.0.0之后，Kafka社区增加了一系列的功能，其中包含对Kafka集群进行安全管控。Broker与Client之间的权限认证（例如Producer和Consumer）。可以使用SSL或SASL，而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版本。

在Kafka 0.9.0.0之后，Kafka社区增加了一系列的功能，其中包含对Kafka集群进行安全管控。Broker与Client之间的权限认证（例如Producer和Consumer）。可以使用SSL或SASL，而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版本。

通过认真阅读和分析Kafka的网络通信层代码，可以收获不少关于NIO的网络通信知识。通过对Kafka的源代码进行阅读和学习，这对大规模Kafka集群性能的调优和问题定位排查是很有帮助的。

Kafka的日志压缩原理并不复杂，就是定时把所有的日志读取两遍，写一遍，而CPU的速度超过磁盘完全不是问题，只要日志的量对应的读取两遍和写入一遍的时间在可接受的范围内，那么它的性能就是可以接受的。

active为0说明在dubbo调用的过程中active并没有发生变化。那active为什么是0，其实就是在问active什么时候发生变化？要回答这个问题我们得知道active是在哪里定义的，因为在其定义的地方，必有其修改的方法。下面这图说明了active是定义在RpcStatus类里面的一个类型为AtomicInteger的成员变量。在RpcStatus类中，有三处()调用active值的方法，一个增加、一个减少、一个获取：很明显，我们需要看的是第一个，在哪里增加。

void表示的程序上不需要关心返回值，但是对Dubbo框架而言，还是需要构建返回数据的。仔细看oneway调用方式的图，可以看出：从客户端到服务端，只有req，没有resp;所以客户端不需要阻塞等待。2.sync --- 同步调用sync是最常用的通信方式，也是Dubbo默认的通信方法。还是仔细看sync调用方式的图，再想一想你自己写的Dubbo应用，或者公司其他的Dubbo应用，是不是就是你们现在正在使用的通信方式。

ConsistentHashSelector通过调用其构造函数进行初始化的。invokers(服务端)作为参数传递到了构造函数中，构造函数里面的逻辑，就是把服务端映射到哈希环上的过程，请看下图，结合代码，仔细分析输出数据：转存失败重新上传取消从上图可以看出，当ConsistentHashSelector的构造方法调用完成后，8个虚拟节点在哈希环上已经映射完成。两台服务器，每一台4个虚拟节点组成了这8个虚拟节点。

很多从 swagger 2 过来的用户可能会好奇，为什么不使用 springfox 库来生成 API，我在这里简单总结一下springdoc-openapi 是 spring 官方出品，与 springboot 兼容更好（springfox 兼容有坑）springdoc-openapi 社区更活跃，springfox 已经 2 年没更新了springdoc-openapi 的注解更接近 OpenAPI 3 规范。

请假流程报销流程入职流程离职流程出差流程等等……就算你自己没有设计过工作流，那么你每天肯定也在使用各种流程。由于 BPMN 1.0 规范广受欢迎，组织于2011年1月发布 BPMN 2.0 规范，BPMN 2.0 版本则继承了 1.0 版本的内容，并且注重流程执行语法和标准交换格式。

openapiinfoserverspathscomponentssecuritytagsOpenAPI 的其余功能都是基于这 8 根对象扩展而成，凡是包含以上对象并且扩展名为jsonyaml的文件，我们可以将其视为符合OpenAPI 规范的描述文件API Editor 在线编辑器中来验证你的 OpenAPI 文件是否符合规范，以下我们就主要介绍 8 个根对象的使用和扩展方法以上就是一个完整的 OpenAPI 规范的文件的使用说明。