2 天前 / 尹千觞
Springboot 引入 Reactor 已经有一段时间了，笔者潜伏在各种技术群里暗中观察发现，好像 scala 圈子的同仁们，似乎对响应式更热衷一点。也许是因为他们对 fp 理解的更深吧，所以领悟起来障碍性更少一些的原因吧。尽管 webflux 对于数据库的支持，还不那么完善，也不妨我们试上一试。 首先请允许我引用全部的反应式宣言作为开篇，接下来会介绍 webflux 整合 kafka 做一个 demo。 反应式宣言 在不同领域中深耕的组织都在不约而同地尝试发现相似的软件构建模式。希望这些系统会更健壮、更具回弹性 、更灵活，也能更好地满足现代化的需求。
8 天前 / binecy
本文分享如何使用 KRaft 部署 Kafka 集群，以及 Spring 中如何实现 Kafka 响应式交互。 KRaft 我们知道，Kafka 使用 Zookeeper 负责为 kafka 存储 broker，Consumer Group 等元数据，并使用 Zookeeper 完成 broker 选主等操作。 虽然使用 Zookeeper 简化了 Kafka 的工作，但这也使 Kafka 的部署和运维更复杂。 Kafka 2.8.0 开始移除了 Zookeeper，并使用 Kafka 內部的仲裁（Quorum）控制器來取代 ZooKeeper，官方称这个控制器为 "Kafka Raft metadata mode"，即 KRaft mode。
26 天前 / 全菜工程师小辉
如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 其余有关 Kakfa 的文章如下： 《一文理解 Kafka 的选举机制与 Rebalance 机制》 《一文理解 Kafka 重复消费的原因和解决方案》 《一文理解 Kafka 如何消息不丢失》 《一文理解如何解决 Kafka 消息积压问题》 《一文理解 Kafka 如何保证消息顺序性》 Kafka 高吞吐量的原因 kafka 高效文件存储设计特点 Kafka 把 topic 中一个 Parition 大文件分成多个小文件 segment，通过多个小文件 segment，就容易定期清除或删除已经消费完的文件，减少磁盘占用。
33 天前 / 全菜工程师小辉
Kafka 是一个高性能，高容错，多副本，可复制的分布式消息系统。在整个系统中，涉及到多处选举机制，被不少人搞混，这里总结一下，本篇文章大概会从三个方面来讲解。 控制器（Broker）选举机制 分区副本选举机制 消费组选举机制 如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 控制器选举控制器是 Kafka 的核心组件，它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 Broker 都能充当控制器的角色，但在运行过程中，只能有一个 Broker 成为控制器。
35 天前 / 全菜工程师小辉
如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 在解释 Kafka 重复消费出现原因之前，列举一下 Kafka 中与消费者有关的几个重要配置参数。 enable.auto.commit：表示消费者会周期性自动提交消费的 offset。默认值 true。 auto.commit.interval.ms：在 enable.auto.commit 为 true 的情况下， 自动提交的间隔。默认值 5 秒。 max.poll.records：单次消费者拉取的最大数据条数，默认值 500。
40 天前 / 全菜工程师小辉
本文只聚焦于 Kafka 系统的消息丢失，如果是生产环境出现数据丢失，排查时要先从链路上分段定位，缩小问题范围。 如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 数据丢失的原因生产者丢失消息的情况生产者 (Producer) 调用 send 方法发送消息之后，消息可能因为网络问题并没有发送过去。 解决方法： 不能认为在调用 send 方法发送消息之后消息消息发送成功了。为了确定消息是发送成功，需要判断消息发送的结果。
42 天前 / PerfMa社区-性能领域的垂直社区
XPocket登录注册文章》跟 Kafka 学技术系列之时间轮》跟 Kafka 学技术系列之时间轮楼顶凉席看星星星 javakafka 大数据 1 年前 写在前面 kafka 是一个分布式消息中间件，其高可用高吞吐的特点是大数据领域首选的消息中间件，Kafka 是分布式消息队列的顺序读写文件分段组织串联起来思想的鼻祖，包括 RocketMq 这些消息队列都是借鉴了 Kafka 早期的架构和设计思路改造而来，所以在架构设计层面，Kafka 有非常多值得借鉴的地方。本文是作者介绍 Kafka 优秀架构设计文章中的一篇，文中的代码和流程图均是 base on 0.10.2.0 版本。
45 天前 / 全菜工程师小辉
通常情况下，企业中会采取轮询或者随机的方式，通过 Kafka 的 producer 向 Kafka 集群生产数据，来尽可能保证 Kafk 分区之间的数据是均匀分布的。 如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 消息积压的解决方法加强监控报警以及完善重新拉起任务机制，这里就不赘述了。 1.实时 / 消费任务挂掉导致的消费积压的解决方法在积压数据不多和影响较小的情况下，重新启动消费任务，排查宕机原因。 如果消费任务宕机时间过长导致积压数据量很大，除了重新启动消费任务、排查问题原因，还需要解决消息积压问题。
50 天前 / 全菜工程师小辉
要想实现消息有序，需要从 Producer 和 Consumer 两方面来考虑。 如果对 Kafka 不了解的话，可以先看这篇博客《一文快速了解 Kafka》。 针对消息有序的业务需求，还分为全局有序和局部有序。 全局有序：一个 Topic 下的所有消息都需要按照生产顺序消费。 局部有序：一个 Topic 下的消息，只需要满足同一业务字段的要按照生产顺序消费。例如：Topic 消息是订单的流水表，包含订单 orderId，业务要求同一个 orderId 的消息需要按照生产顺序进行消费。
64 天前 / yes的练级攻略
你好，我是 yes。（先说下哈，今天文末送三本硬核的书！） 在上个月 30 号， confluent 发布了一篇文章，文章上说在 Kafka 2.8 版本上将支持内部的 quorum 服务来替换 ZooKeeper 的工作。 其实去年我写的 Kafka 控制器事件处理全流程这篇文章已经提到这一点。 今天再稍微展开来说说。 ZooKeeper 的作用 ZooKeeper 是一个开源的分布式协调服务框架，你也可以认为它是一个可以保证一致性的分布式 ( 小量)存储系统。特别适合存储一些公共的配置信息、集群的一些元数据等等。 它有持久节点和临时节点，而临时节点这个玩意再配合 Watcher 机制就很有用。
72 天前 / vivo互联网技术
作者：vivo 互联网服务器团队 -Yang Yijun 一、Kafka 应用 本文主要总结当 Kafka 集群流量达到万亿级记录 / 天或者十万亿级记录 / 天 甚至更高后，我们需要具备哪些能力才能保障集群高可用、高可靠、高性能、高吞吐、安全的运行。 这里总结内容主要针对 Kafka2.1.1 版本，包括集群版本升级、数据迁移、流量限制、监控告警、负载均衡、集群扩 / 缩容、资源隔离、集群容灾、集群安全、性能优化、平台化、开源版本缺陷、社区动态等方面。本文主要是介绍核心脉络，不做过多细节讲解。下面我们先来看看 Kafka 作为数据中枢的一些核心应用场景。
73 天前 / 李浩宇Alex
前提回顾经过了之前的【Kafka 技术专题系列（上）】和【Kafka 技术专题系列（中）】的学习，相信您对 Kafka 的基本原理应该已经有了一个简单的介绍和认识了，接下来需要对总体做个收尾。下篇结束之后，我会对 Kafka 所有相关的技术板块做细化，做每一个技术板块做深入和扩展。 总体架构 核心优势 kafka 被设计成通用的数据流处理平台，日志收集器和消息队列。 高吞吐（日志聚合）： 大型数据块的整合（offline 平台的拉取） 低延迟（消息队列） 分区、分布式的实时流处理，从一个流派生新的流； 容错（当被投喂非日志数据时） 为了支持这些特性...
79 天前 / u553049
本文从高可用的角度观察一下 RabbitMQ、Kafka、RocketMQ，看看它们各自的实现思路。 1. RabbitMQRabbitMQ 有 3 种部署模式： 单机模式普通集群模式镜像集群模式单机模式与高可用完全没关系，咱就不说了，直接看看这 2 种集群模式。 1.1 普通集群模式某一个 Queue 是在集群中的某一个 Broker 上，各个 Broker 会同步元数据，但不会同步 Queue 的消息数据。 如果某一个 Broker 故障了，其中的 Queue 便无法使用。如果消息没有配置消息持久化，则消息丢失。
82 天前 / u553049
Partition（分区）是 Kafka 的核心角色，对于 Kafka 的存储结构、消息的生产消费方式都至关重要。 掌握好 Partition 就可以更快的理解 Kafka。本文会讲解 Partition 的概念、结构，以及行为方式。 一、Events, Streams, Topics 在深入 Partition 之前，我们先看几个更高层次的概念，以及它们与 Partition 的联系。 Event（事件）代表过去发生的一个事实。简单理解就是一条消息、一条记录。 Event 是不可变的，但是很活跃，经常从一个地方流向另一个地方。 Stream 事件流表示运动中的相关事件。 当一个事件流进入 Kafka 之后，它就成为了一个 Topic 主题。
83 天前 / u553049
Kafka 2.8.0 出炉了，此版本有一项重大改进： 实现了 Raft 分布式一致性机制，意味着可以脱离 ZooKeeper 独立运行了。 ZooKeeper 在 Kafka 中扮演着重要的角色，用来存储 Kafka 的元数据。 ZooKeeper 存储着 Partition 和 Broker 的元数据 ，同时也负责 Kafka Controller 的选举工作。 对于 Kafka 来讲，ZooKeeper 是一套外部系统，要想部署一套 Kafka 集群，就要同时部署、管理、监控 ZooKeeper。 ZooKeeper 有自己的配置方式、管理工具，和 Kafka 完全不一样，所以，一起搞两套分布式系统，自然就提升了复杂度，也更容易出现问题。