Kafka

什么是Kafka Connect 正如前面的文章所说，Debezium提供的各种Connector都是Kafka Connect的插件，运行于Kafka Connect的服务上。 首先我们要知道，Kafka的特性，例如，topic的分区、I/O结合操作系统的页缓存(page cache)等，这些令Kafka具备了高吞吐量、低延时及高可用等优点。 由于Kafka的优点，当需要实现 CDC(Changed Data Capture) 时，即捕获 数据源 的变动并同步至 目标数据源 ，我们可以使用Kafka作为 数据源 和 目标数据源 之间的数据通道。 而作为开发人员只想专注于开发与数据源交互的代码，至于怎样开发Producer程序把捕获的数据发布到Kafka、怎样保证捕获数据的服务高可用，他们不希望多花精力考虑。这时，可以使用Kafka Connect把上下游的数据源与Kafka串联起来，而与数据源交互的业务代码则以Connector的形式运行在Kafka Connect上。 如上图所示，从 捕获数据源变动情况 的Connector被称为 Source Connector ，它们负责与数据源交互，把捕获到的记录放到一个集合里面(不一定是queue)，然后，Kafka Connect会调用 Connector 对应的 Task 的 poll 方法从集合中获取记录，并发送至Kafka。

微服务架构并不是一种新方法；多年来，它的核心思想一直以 SOA（面向服务的体系结构），Web 服务以及模块化和分层架构的形式存在。现在SpringCloud微服务架构无论是在工作中还是在面试中都是必不可少的一部分，作为一名程序员开发人员，这些都是必须会的！ 今天LZ在逛博客园的看到四份有关SpringCloud微服务架构的学习笔记，干货满满的，需要的小伙伴可以帮忙一键三连+评论，加小助手vx:bjmsb2019或者vx:1249448307即可！ Day1 微服务基础知识 随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服 务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 Day2 服务调用+服务注册+微服务架构+服务熔断 Day3 微服务网关：在学习完前面的知识后，微服务架构已经初具雏形。但还有一些问题：不同的微服务一般会有不同的网 络地址，客户端在访问这些微服务时必须记住几十甚至几百个地址，这对于客户端方来说太复杂也难以 维护。 Day4 在实际的企业开发中，消息中间件是至关重要的组件之一。 消息中间件主要解决应用解耦，异步消 息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。不同的中间件其实现方式，内 部结构是不一样的。如常见的RabbitMQ 和 Kafka ，由于这两个消息中间件的架构上的不同，像

本文译自https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013?gi=f8addb915af7，作者Vijini Mallawaarachchi，Sep 4, 2017 译者：evandeng2009（blog.csdn.net/evandeng2009/） 为了更好的组织语言和理解，符合我们的阅读习惯，原文的部分段落被合并或者分割。为体现完整性，不删减文字，保持原文文字内容。翻译纯属个人喜爱、分享和收藏。 正文 是否想知道大型企业级系统是怎么设计的？在软件主体开发之前，我们必须选择一个合适的架构来提供所需的功能和质量特征。所以在应用于设计之前，我们应该了解不同的架构。 什么是架构模式 维基百科：架构模式是在给定上下文的软件架构中，针对常发生问题的一种通用、复用的解决方案。架构模式类似于软件设计模式，但是范畴更广。 本文中，我将简要的阐述如下10中常见架构模式的应用和优缺点。 分层模式 客户端-服务端模式 主从模式 管道-过滤器模式 代理模式 点对点模式 事件总线模式 模型-视图-控制器模式 黑板模式 解释器模式 1. 分层模式 该模式用于构建可分解为多组子任务的程序，每个子任务都在某个抽象层，每个层对上一个更高层提供服务

相关文章链接 CentOS7安装CDH 第一章：CentOS7系统安装 CentOS7安装CDH 第二章：CentOS7各个软件安装和启动 CentOS7安装CDH 第三章：CDH中的问题和解决方法 CentOS7安装CDH 第四章：CDH的版本选择和安装方式 CentOS7安装CDH 第五章：CDH的安装和部署-CDH5.7.0 CentOS7安装CDH 第六章：CDH的管理-CDH5.12 CentOS7安装CDH 第七章：CDH集群Hadoop的HA配置 CentOS7安装CDH 第八章：CDH中对服务和机器的添加与删除操作 CentOS7安装CDH 第九章：CDH中安装Kafka CentOS7安装CDH 第十章：CDH中安装Spark2 CentOS7安装CDH 第十一章：离线升级CDH版本 CentOS7安装CDH 第十二章：YARN的资源调优 CentOS7安装CDH 第十三章：CDH资源池配置 CentOS7安装CDH 第十四章：CDH的优化 1. memory调优 调优的本质就是对内存进行设置，使服务能够充分利用内存，从而速度更快，假设一台机器有32G内存，那应该怎么设置DataNode和Nodemanager的内存配置，从而是服务跑得更快。在Linux中，一般使用机器内存的百分之八十五用于服务，其他的百分之十五用于Linux本机自己的运行。所以机器32G内存

本篇主要介绍kafka的分区和副本，因为这两者是有些关联的，所以就放在一起来讲了，后面顺便会给出一些对应的配置以及具体的实现代码，以供参考~ 1.kafka分区机制 分区机制是kafka实现高吞吐的秘密武器，但这个武器用得不好的话也容易出问题，今天主要就来介绍分区的机制以及相关的部分配置。 首先，从数据组织形式来说，kafka有三层形式，kafka有多个主题，每个主题有多个分区，每个分区又有多条消息。 而每个分区可以分布到不同的机器上，这样一来，从服务端来说，分区可以实现高伸缩性，以及负载均衡，动态调节的能力。 当然多分区就意味着每条消息都难以按照顺序存储，那么是不是意味着这样的业务场景kafka就无能为力呢？不是的， 最简单的做法可以使用单个分区，单个分区，所有消息自然都顺序写入到一个分区中，就跟顺序队列一样了 。而复杂些的，还有其他办法， 那就是使用按消息键，将需要顺序保存的消息存储的单独的分区，其他消息存储其他分区，这个在下面会介绍 。 我们可以通过replication-factor指定创建topic时候所创建的分区数。 bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test 比如这里就是创建了1个分区

我看大部分教程都是在linux搭建的，那么俺就搭建在win上面吧。 首先，下载E+L+K，下面这个地址都有这3个相关的软件包 Elasticsearch+Logstash+Kibana https://www.elastic.co/downloads 1、安装Logstash，Logstash的版本为：6.3.1 解压后，进入bin文件夹下，新建配置文件logstash.conf，让后输入下面内容 input { kafka{ bootstrap_servers => ["192.168.1.1:9092"] client_id => "test" group_id => "test" topics => ["test"] auto_offset_reset => "latest" codec => json{charset=>"UTF-8"} } } output { elasticsearch { hosts => ["192.168.1.1:9200"] codec => json{charset=>"UTF-8"} index=> "%{source}" } } stdin表示在控制台输入，也可以用其他方式输入，elasticsearch表示输出到elasticsearch，index表示json传参进来的index值映射到ES的index上面去。注意，如果传递有中文

本文是《剖析Spark数据分区》系列文章的第三篇，本篇我们将分析Spark streaming，TiSpark中的数据分区。 系列一： 剖析Spark数据分区之Hadoop分片 系列二： 剖析Spark数据分区之Spark RDD分区 1. Kafka +Spark Streaming 图 1 Spark Streaming从Kafka接收数据，转换为Spark Streaming中的数据结构DStream即离散数据流。 数据接收方式有两种： 1)使用Receiver接收的旧方法； 2)使用Direct拉取的新方法 （Spark 1.3引入） ； 1）Receiver方式 当前spark已经 不支持 该模式。 图 2 receiver模式的 并行度 由spark.streaming.blockInterval决定，默认是200ms。 receiver模式接收block.batch数据后会封装到RDD中，这里的block对应RDD中的partition。 batchInterval一定的情况 下： 减少 spark.streaming.Interval参数值，会 增大 DStream中的partition个数。 建议spark.streaming.Interval 最低不能低于50ms 。 2）Direct方式 图 3 Spark会创建跟Kafka partition一样多的RDD

在双十一过程中投入同样的硬件资源，Kafka 搭建的日志集群单个Topic可以达到几百万的TPS；而使用RocketMQ组件的核心业务集群，集群TPS只能达到几十万TPS，这样的现象激发了我对两者性能方面的思考。 温馨提示： TPS只是众多性能指标中的一个，我们在做技术选型方面要从多方面考虑，本文并不打算就消息中间件选型方面投入太多笔墨，重点想尝试剖析两者在性能方面的设计思想。 01 文件布局 1.1 Kafka 文件布局 Kafka 文件在宏观上的布局如下图所示： 正如上图所示，Kafka 文件布局的主要特征如下： 文件的组织以 topic + 分区进行组织，每一个 topic 可以创建多个分区，每一个分区包含单独的文件夹，并且是多副本机制。即 topic 的每一个分区会有 Leader 与 Follow，并且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器，并且每一台 broker 会尽量均衡的承担各个分区的 Leader，当然在运行过程中如果不均衡，可以执行命令进行手动重平衡。Leader 节点承担一个分区的读写，follow 节点只负责数据备份。 Kafka 的负载均衡主要依靠分区 Leader 节点的分布情况 。 分区的 Leader 节点负责读写，而从节点负责数据同步

Kafka 提供了 3 种提交 offset 的方式 自动提交 复制 1 2 3 4 // 自动提交,默认true props.put( "enable.auto.commit" , "true" ); // 设置自动每1s提交一次 props.put( "auto.commit.interval.ms" , "1000" ); 手动同步提交 offset 复制 1 consumer.commitSync(); 手动异步提交 offset 复制 1 consumer.commitAsync(); 上面说了既然异步提交 offset 可能会重复消费, 那么我使用同步提交是否就可以表明这个问题呢？ 复制 1 2 3 4 5 6 7 while ( true ) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis( 100 )); records.forEach(record -> { insertIntoDB(record); consumer.commitSync(); }); } 很明显不行, 因为 insertIntoDB 和 commitSync() 做不到原子操作, 如果 insertIntoDB() 成功了，但是提交 offset 的时候 consumer 挂掉了

公司有个项目在用kafka同步数据，详细背景就不交代了，客户端版本0.9.0.1，自动提交offset，发现程序在kafka拉不到消息时poll每次都提示如下信息及报错： 由于项目环境及代码均在公司内网，详细日志无法贴出来，基本就是： ........................ Marking the coordinator 11111111111 dead. ........................ Error UNKNOWN_MEMBER_ID occurred while committing offsets for group ggggggg ........................ Auto offset commit failed: Commit cannot be completed due to group rebalance ........................ Error UNKNOWN_MEMBER_ID occurred while committing offsets for group ggggggg ........................ Auto offset commit failed: ........................ Attempt to join group gggggggg