目前一些互联网公司会使用消息队列来做核心业务，因为是核心业务，所以对数据的最后一致性比较敏感，如果中间出现数据丢失，就会引来用户的投诉，年底绩效就变成325了。之前和几个朋友聊天，他们的公司都在用kafka来做消息队列，使用kafka到底会不会丢消息呢？如果丢消息了该怎么做好补偿措施呢？本文我们就一起来分析一下，并介绍如何使用Go操作Kafka可以不丢失数据。
https://www.cnblogs.com/bainianminguo/p/12247158.html
在现代的大数据时代，消息队列成为了极为重要的组件。Kafka作为一种高吞吐量、低延迟、可扩展的分布式发布订阅消息系统，在大数据领域得到了广泛的应用。来，这里我们将介绍如何安装Kafka以及一些配置注意事项。
数据丢失是一件非常严重的事情事，针对数据丢失的问题我们需要有明确的思路来确定问题所在，针对这段时间的总结，我个人面对kafka 数据丢失问题的解决思路如下：
当想要对来自事务数据库（如 Postgres 或 MySQL）的数据执行分析时，通常需要通过称为更改数据捕获[4] CDC的过程将此数据引入数据仓库或数据湖等 OLAP 系统。Debezium 是一种流行的工具，它使 CDC 变得简单，其提供了一种通过读取更改日志[5]来捕获数据库中行级更改的方法，通过这种方式 Debezium 可以避免增加数据库上的 CPU 负载，并确保捕获包括删除在内的所有变更。现在 Apache Hudi[6] 提供了 Debezium 源连接器，CDC 引入数据湖比以往任何时候都更容易，因为它具有一些独特的差异化功能[7]。Hudi 可在数据湖上实现高效的更新、合并和删除事务。Hudi 独特地提供了 Merge-On-Read[8] 写入器，与使用 Spark 或 Flink 的典型数据湖写入器相比，该写入器可以显着降低摄取延迟[9]。最后，Apache Hudi 提供增量查询[10]，因此在从数据库中捕获更改后可以在所有后续 ETL 管道中以增量方式处理这些更改下游。
segmentio/kafka-go 是一款开源的golang kafka读写sdk，开源地址为：https://github.com/segmentio/kafka-go 。截止写文章时，这个开源代码库收获了3.3K的star，在很多公司内外部项目广泛使用。与 https://github.com/confluentinc/confluent-kafka-go 和 https://github.com/Shopify/sarama 一起，作为最常用的三个golang kafka sdk。
本书大部分内容都在讨论单个kafka集群的配置、维护和使用。但是，在一些场景中，可能需要多集群架构。 在某些情况下，集群是完全分离的，他们属于不同部门的不同实例，没有理由将数据从一个集群复制到另外一个集群。有时，不同的SLA或者工作负载使得单个集群提供多个用例服务的集群很难调优。在某些时候，还有不同的安全需求。这些场景非常容易管理多个不同的集群，就像多次允许单个集群一样。 在其他场景中，不同的集群是互相依赖的，管理有要不断地在集群之间复制数据。在大多数数据库中，在数据库服务之间持续复制数据称为复制。由于我们使用复制来描述属于同一集群的kafka节点之间的数据移动，因此我们将把kafak集群之间的数据复制称之为镜像。Apache kafka内置的跨集群 的复制器称为mirrormaker。 在本章中，我们将讨论所有或者部分数据的跨集群镜像。我们将首先讨论跨集群的镜像的一些常用用例。然后我们将展示一些用于实现这些用例的架构，并讨论每种架构的优缺点。然后我们将讨论MirrorMaker本书以及如何使用它。我们将分享一些操作技巧，包括部署的性能调优。最后我们将讨论mirrorMaker的一些替代方案。
本文只聚焦于Kafka系统的消息丢失，如果是生产环境出现数据丢失，排查时要先从链路上分段定位，缩小问题范围。
Spark Streaming 是一种构建在 Spark 上的实时计算框架，它扩展了 Spark 处理大规模流式数据的能力。Spark Streaming 的优势在于：
我们VIP成员很多在2021年春节年前、后，拿到了offer。而且不止一个，有的两个，有的四个，有的六个。这里给我们分享其中一位成员，整理的一家公司的面试题，后续将会陆续发布。
Kafka生态-Kafka Core，Kafka Streams，Kafka Connect，Kafka REST Proxy和Schema Registry Kafak的核心主要有Broker，Topic，日志，分区和集群。该核心还包括相关的工具，如MirrorMaker。 Kafka生态系统由Kafka Core，Kafka Streams，Kafka Connect，Kafka REST Proxy和Schema Registry组成。Kafka生态系统的大多数附件来自Confluent，而不是Apa
分布式实时消息队列Kafka（三） 知识点01：课程回顾 请简述Kafka的集群架构及角色功能？ Kafka：分布式主从架构 主： Controller：管理集群中的Topic、分区、副本选举 从：Broker：对外接受读写请求，存储分区数据 Zookeeper 辅助选举Active的主节点：Crontroller 存储核心元数据 请简述Kafka中Topic管理的脚本及常用选项参数？ 使用命令行中的脚本命令实现管理 脚本：kafka-topics.sh 常用选项
当人们讨论使用apache kafka构建数据管道时，他们通常会应用如下几个示例，第一个就是构建一个数据管道，Apache Kafka是其中的终点。丽日，从kafka获取数据到s3或者从Mongodb获取数据到kafka。第二个用例涉及在两个不同的系统之间构建管道。但是使用kafka做为中介。一个例子就是先从twitter使用kafka发送数据到Elasticsearch，从twitter获取数据到kafka。然后从kafka写入到Elasticsearch。 我们在0.9版本之后在Apache kafka 中增加了kafka connect。是我们看到之后再linkerdin和其他大型公司都使用了kafka。我们注意到，在将kafka集成到数据管道中的时候，每个公司都必须解决的一些特定的挑战，因此我们决定向kafka 添加AP来解决其中的一些特定的挑战。而不是每个公司都需要从头开发。 kafka为数据管道提供的主要价值是它能够在管道的各个阶段之间充当一个非常大的，可靠的缓冲区，有效地解耦管道内数据的生产者和消费者。这种解耦，结合可靠性、安全性和效率，使kafka很适合大多数数据管道。
在本文中将从演示如何搭建一个Kafka集群开始，然后简要介绍一下关于Kafka集群的一些基础知识点。但本文仅针对集群做介绍，对于Kafka的基本概念不做过多说明，这里假设读者拥有一定的Kafka基础知识。
我们先看一下维基百科是怎么说的： Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，[这使它作为企业级基础设施来处理流式数据非常有价值。此外，Kafka可以通过Kafka Connect连接到外部系统（用于数据输入/输出），并提供了Kafka Streams——一个Java流式处理库。看完这个说法，是不是有点一脸蒙蔽， 再看看其他大神的理解：Kafka 是由 Linkedin 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。 总的来说就是他就是发布订阅消息的引擎系统，在做集群的时候需要依靠zookeeper。
导语 本文介绍了 Kafka 跨数据中心的两种部署方式，简要分析两种方式下的不同架构以及优缺点，对这些架构可能碰到的问题也提供了一些解决思路；同时也说明了 Kafka 跨数据中心部署的社区解决方案和商业化解决方案。 背景 Kafka 作为世界上最流行的消息中间件之一，一般是客户数据链路中的核心组件，高可用性是客户很关注的因素。近期在对接云上客户时发现，客户对 Kafka 的高可用也有需求，行业架构师也想了解 Kafka 高可用的方案细节；有些客户是需要云上 Kafka 的高可用能力，有些客户需要 IDC
Redis性能优化，单机增加CPU核数是否会提高性能 1、根据业务需要选择合适的数据类型，并为不同的应用场景设置相应的紧凑存储参数。 2、当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能以及最大的内存使用量。 3、如果需要使用持久化，根据是否可以容忍重启丢失部分数据在快照方式与语句追加方式之间选择其一，不要使用虚拟内存以及diskstore方式。 4、不要让你的Redis所在机器物理内存使用超过实际内存总量的3/5。 我们知道Redis是用”单线程-多路复用io模型”来实现高性能的内存数据服务的，这种机制避免了使用锁，但是同时这种机制在进行sunion之类的比较耗时的命令时会使redis的并发下降。因为是单一线程，所以同一时刻只有一个操作在进行，所以，耗时的命令会导致并发的下降，不只是读并发，写并发也会下降。而单一线程也只能用到一个cpu核心，所以可以在同一个多核的服务器中，可以启动多个实例，组成master-master或者master-slave的形式，耗时的读命令可以完全在slave进行。
使用Filebeat收集本地日志数据，Filebeat监视日志目录或特定的日志文件，再发送到消息队列到kafka，然后logstash去获取消费，利用filter功能过滤分析，最终存储到elasticsearch中。
本译文自Jean-Paul Azar 在 https://dzone.com 发表的 Kafka Detailed Design and Ecosystem ，文中版权，图像代码的数据均归作者所有。为
线上数据一般主要是落地（存储到磁盘）或者通过 socket 传输给另外一个系统，这种情况下，你很难推动线上应用或服务去修改接口，实现直接向 kafka里写数据，这时候你可能就需要 flume 这样的系统帮你去做传输。
网上有很多Kafka的文章，但大多写得千篇一律，要么偏理论化，无实战数据参考。要么写了发现的某个问题的解决方案，对于想在实际环境上搭建真实的Kafka环境，参考意义并不大。
注意：以上需要在NiFi集群中的每个节点上创建“/root/test/logdata”文件，“logdata”是文件，而非目录。
在《图解Kafka中的基本概念》中已经对副本进行了介绍。我们先回顾下，Kafka中一个分区可以拥有多个副本，副本可分布于多台机器上。而在多个副本中，只会有一个Leader副本与客户端交互，也就是读写数据。其他则作为Follower副本，负责同步Leader的数据，当Leader宕机时，从Follower选举出新的Leader，从而解决分区单点问题。本文将继续深入了解Kafka中副本机制的设计和原理。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XX0kexvT-1617677731154)(D:\Code_Study\博客笔记\Kafka学习笔记.assets\1606809962993.png)]
作者：李捷，Elastic首席云解决方案架构师 ELK生态下，构建日志分析系统的选择 说起开源的日志分析系统，ELK几乎无人不晓，这个生态并非是Elastic特意而为，毕竟Elasticsearch的初心是分布式的搜索引擎，被广泛用作日志系统纯粹一个“美丽的意外”，这是社区使用者推动而成。而现在各大云厂商推广自己的日志服务时，也往往将各种指标对标于ELK，可见其影响之广。 但其实，流行的架构中并非只有ELKB，当我们使用ELKB搭建一套日志系统时，除了Elasticsearch, Logstash, Kib
经过上次 Kafka 日志集群某节点重启失败导致某个主题分区不可用的事故之后，这篇文章专门对分区不可用进行故障重现，并给出我的一些骚操作来尽量减少数据的丢失。
说起开源的日志分析系统，ELK几乎无人不晓，这个生态并非是Elastic特意而为，毕竟Elasticsearch的初心是分布式的搜索引擎，被广泛用作日志系统纯粹一个“美丽的意外”，这是社区使用者推动而成。而现在各大云厂商推广自己的日志服务时，也往往将各种指标对标于ELK，可见其影响之广。
分区分配策略：保障每个消费者尽量能够均衡地消费分区的数据，不能出现某个消费者消费分区的数量特别多，某个消费者消费的分区特别少
数据的丢失问题，可能出现在生产者、MQ、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。
Confluent Replicator是一个Kafka connector,它运行在Kafka Connect框架内。Replicator继承了所有Kafka Connect API的优点为，包括伸缩性，性能和容错。Confluent Replicator从原始集群消费消息然后将消息写入到目标集群。这个Kafka Connect workers部署在和目标集群相同的数据中心。
生产者： rabbitMQ支持事务，可以在发送中进行捕获异常，如果出现未接受异常进行回滚操作。
Apache Kafka（简称Kafka）是由LinkedIn公司开发的分布式消息流平台，于2011年开源。
今天要介绍的是消息中间件KafKa，应该说是一个很牛的中间件吧，背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ，为什么不用RabbitMQ，因为公司需要它。 网上已经有很多怎么用和用到哪的内容，但结果很多人都倒在了入门第一步 环境都搭不起来，可谓是从了解到放弃，所以在此特记录如何在linux环境搭建，windows中配置一样，只是启动运行bat文件。 想要用它就先必须了解它能做什么及能做到什么程度，先看看它是什么吧。 当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工
在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader，
这个是肯定的，用 MQ 有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是前面说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。
# **kafka release reviews: what happen from kafka 0.10 to 2.6*
Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。
hello，大家好，我是张张，「架构精进之路」公号作者。 引言 在探究 Kafka 核心知识之前，我们先思考一个问题：什么场景会促使我们使用 Kafka? 说到这里，我们头脑中或多或少会蹦出异步解耦
作者：mo 引言 在探究 Kafka 核心知识之前，我们先思考一个问题：什么场景会促使我们使用 Kafka? 说到这里，我们头脑中或多或少会蹦出异步解耦和削峰填谷等字样，是的，这就是 Kafka 最
你好，我是码哥，可以叫我靓仔 作者：mo 引言 在探究 Kafka 核心知识之前，我们先思考一个问题：什么场景会促使我们使用 Kafka? 说到这里，我们头脑中或多或少会蹦出异步解耦和削峰填谷等字样
Kafka在早期版本中，并不提供高可用机制，一旦某个Broker宕机，其上所有Partition都无法继续提供服务，甚至发生数据丢失 对于分布式系统，当集群规模上升到一定程度后，宕机的可能性大大提高，对高可用性就有了非常高要求 Kafka在0.8版本提供了高可用机制，主要是增加了Partition的复制设计 引入Partition的Replication之后，同一个Partition的就有了多个副本，把这些副本均匀的分布到多个Broker上，就保证了数据的安全，不再担心某个Broker宕机后使其中的P
Kafka在0.8以前的版本中，并不提供High Availablity机制，一旦一个或多个Broker宕机，则宕机期间其上所有Partition都无法继续提供服务。若该Broker永远不能再恢复，亦或磁盘故障，则其上数据将丢失。而Kafka的设计目标之一即是提供数据持久化，同时对于分布式系统来说，尤其当集群规模上升到一定程度后，一台或者多台机器宕机的可能性大大提高，对于Failover机制的需求非常高。因此，Kafka从0.8开始提供High Availability机制。本文从Data Replication和Leader Election两方面介绍了Kafka的HA机制。
下面这些都是我在工作中总结出来的，希望对大家有帮助，如果有其他的问题或者解决方法可以留言给我。
面试官：OK，那我们继续上次的话题，就是MQ如何保证消息的可靠性，或者说如何保证消息不丢失呢？
转载请注明原创地址 http://www.cnblogs.com/dongxiao-yang/p/5443789.html
高可用是很多分布式系统中必备的特征之一，Kafka 日志的高可用是通过基于 leader-follower 的多副本同步实现的，每个分区下有多个副本，其中只有一个是 leader 副本，提供发送和消费消息，其余都是 follower 副本，不断地发送 fetch 请求给 leader 副本以同步消息，如果 leader 在整个集群运行过程中不发生故障，follower 副本不会起到任何作用，问题就在于任何系统都不能保证其稳定运行，当 leader 副本所在的 broker 崩溃之后，其中一个 follower 副本就会成为该分区下新的 leader 副本，那么问题来了，在选为新的 leader 副本时，会导致消息丢失或者离散吗？Kafka 是如何解决 leader 副本变更时消息不会出错？以及 leader 与 follower 副本之间的数据同步是如何进行的？带着这几个问题，我们接着往下看，一起揭开 Kafka 水印备份的神秘面纱。
面试大厂时，一旦简历上写了Kafka，几乎必然会被问到一个问题：说说acks参数对消息持久化的影响？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
