Kafka

一、Kafka的架构 如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。 二、Topics和Partition Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中

要回答这个问题，首先要明确啥程度算“零编码”？ 以 Excel 为例，如果把写 Excel 公式（包括复杂一些的）看做零编码；而把写 Excel VBA 看做编码的话， 报表开发是可以零编码的！ 但是，这有个前提：在数据（集）准备好的情况下才可以零编码！ 为什么这么说？ 我们知道报表开发主要分两个阶段： 第一阶段是为报表准备数据，也就是把原始数据通过 SQL/ 存储过程加工成数据集； 第二阶段是使用已准备的数据编写表达式做报表呈现。在报表工具提供的 IDE 里可视化地画出报表样式，然后再填入一些把数据和单元格绑定的表达式就可以完成报表呈现了，虽然表达式可能比较复杂，但相对硬编码要简单得多（Excel 公式和 VBA 的关系）。所以说这个阶段是能做到“零编码”的。 那报表数据准备怎么办？ 很遗憾，这个阶段没法零编码，一直以来只能硬编码，想想我们报表里写的嵌套 SQL、存储过程、JAVA 程序就知道了。为什么报表工具发展这么多年报表呈现已经完全工具化而报表数据准备的手段还这样原始呢？因为这个阶段太复杂了，不仅涉及计算逻辑的算法实现，还涉及报表性能（要知道大部分报表性能问题都是数据准备阶段引起的）。 那报表数据准备是不是没办法了呢？ 虽然不能做到零编码，但可以朝着简单化的方向努力，将数据准备阶段也工具化，这样可以使用工具提供的便利来简化报表数据准备阶段的工作，从而进一步简化报表的开发。

要回答这个问题，首先要明确啥程度算“零编码”？ 以 Excel 为例，如果把写 Excel 公式（包括复杂一些的）看做零编码；而把写 Excel VBA 看做编码的话， 报表开发是可以零编码的！ 但是，这有个前提：在数据（集）准备好的情况下才可以零编码！ 为什么这么说？ 我们知道报表开发主要分两个阶段： 第一阶段是为报表准备数据，也就是把原始数据通过 SQL/ 存储过程加工成数据集； 第二阶段是使用已准备的数据编写表达式做报表呈现。在报表工具提供的 IDE 里可视化地画出报表样式，然后再填入一些把数据和单元格绑定的表达式就可以完成报表呈现了，虽然表达式可能比较复杂，但相对硬编码要简单得多（Excel 公式和 VBA 的关系）。所以说这个阶段是能做到“零编码”的。 那报表数据准备怎么办？ 很遗憾，这个阶段没法零编码，一直以来只能硬编码，想想我们报表里写的嵌套 SQL、存储过程、JAVA 程序就知道了。为什么报表工具发展这么多年报表呈现已经完全工具化而报表数据准备的手段还这样原始呢？因为这个阶段太复杂了，不仅涉及计算逻辑的算法实现，还涉及报表性能（要知道大部分报表性能问题都是数据准备阶段引起的）。 那报表数据准备是不是没办法了呢？ 虽然不能做到零编码，但可以朝着简单化的方向努力，将数据准备阶段也工具化，这样可以使用工具提供的便利来简化报表数据准备阶段的工作，从而进一步简化报表的开发。

Kafka- 为什么选择 kafka(kafka 的优点 ) 多个生产者 kafka 可以无缝的支持多个生产者，不管客户端在使用单个主题还是多个主题。所以它很适合用来从多个前端系统手机数据，并以同一的格式对外提供数据。 例如 : 一个包含了多个微服务的网站，可以为页面视图创建一个单独的主题，所有服务都以相同的消息格式向该主题写入数据。消费者应用程序会获得统一的页面视图，而无需协调来自不同生产者的数据流。 多个消费者 kafka 支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。这与其他队列系统不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。 另外，多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。 基于磁盘的数据存储 kafka 允许消费者非实时地读取消息，这要归功于 kafka 的数据保留特性。 消息被提交到磁盘，根据设置的保留规则进行保存。每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。 消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证数据不会丢失。 消费者可以被关闭，但消息会继续保留在 kafka 里。消费者可以从上次中断的地方继续处理消息。 伸缩性 为了能够处理大量数据， kafka

来源： oschina 链接： https://my.oschina.net/siwcky90/blog/4950734

安装librdkafka git clone https://github.com/edenhill/librdkafka.git cd librdkafka ./configure --prefix /usr make sudo make install 下载源码 go get -u github.com/confluentinc/confluent-kafka-go/kafka 以上都githup给出的，需要执行以下命令，否则会异常 sudo ldconfig /tmp/go-build616273194/b001/exe/consumer: error while loading shared libraries: librdkafka.so.1: cannot open shared object file: No such file or directory 来源： oschina 链接： https://my.oschina.net/u/3247419/blog/2050756

这是一篇关于 Kafka 实践的文章，内容来自 DataWorks Summit/Hadoop Summit（Hadoop Summit）上的一篇分享，里面讲述了很多关于 Kafka 配置、监控、优化的内容，绝对是在实践中总结出的精华，有很大的借鉴参考意义，本文主要是根据 PPT 的内容进行翻译及适当补充。 Kafka 的架构这里就不多做介绍了，直接步入正题。 Kafka 基本配置及性能优化 这里主要是 Kafka 集群基本配置的相关内容。 硬件要求 Kafka 集群基本硬件的保证 OS 调优 OS page cache：应当可以缓存所有活跃的 Segment（Kafka 中最基本的数据存储单位）； fd 限制：100k+； 禁用 swapping：简单来说，swap 作用是当内存的使用达到一个临界值时就会将内存中的数据移动到 swap 交换空间，但是此时，内存可能还有很多空余资源，swap 走的是磁盘 IO，对于内存读写很在意的系统，最好禁止使用 swap 分区； TCP 调优 JVM 配置 JDK 8 并且使用 G1 垃圾收集器 至少要分配 6-8 GB 的堆内存 Kafka 磁盘存储 使用多块磁盘，并配置为 Kafka 专用的磁盘； JBOD vs RAID10； JBOD（Just a Bunch of Disks，简单来说它表示一个没有控制软件提供协调控制的磁盘集合

简介 Kafka 是一种高吞吐的分布式发布订阅消息系统，能够替代传统的消息队列用于解耦合数据处理，缓存未处理消息等，同时具有更高的吞吐率，支持分区、多副本、冗余，因此被广泛用于大规模消息数据处理应用。Kafka 支持Java 及多种其它语言客户端，可与Hadoop、Storm、Spark等其它大数据工具结合使用。中文网站： http://kafka.apachecn.org/quickstart.html 本教程主要介绍Kafka 在Centos 7上的安装和使用，包括功能验证和集群的简单配置。 安装JDK Kafka 使用Zookeeper 来保存相关配置信息，Kafka及Zookeeper 依赖Java 运行环境，从 oracle网站 下载JDK 安装包，解压安装： $tar zxvf jdk-8u65-linux-x64.tar.gz $mv jdk1.8.0_65 java 设置Java 环境变量： JAVA_HOME=/opt/java PATH=$PATH:$JAVA_HOME/bin export JAVA_HOME PATH 也可以选择yum install安装，相应设置环境变量。 安装Kafka 从 官网 下载Kafka 安装包，解压安装： tar zxvf kafka_2.11-0.8.2.2.tgz mv kafka_2.11-0.8.2.2 kafka cd

Kafka 基础 Broker 一个集群中，每个服务server Topic 主题,代表一个消息的类型 partition 分区，对一个topic划分为多个分区 Replica 一个分区可以存在多个replica,除了leader对外提供服务，其他salve用于同步数据 segment 为防止log不断追加导致文件过大，导致检索消息效率变低，一个partition又被划分为多个segment来组织数据 Producer 生产者，发部消息到topic Consumer 消费者,订阅topic 从一个topic pull数据 offset 偏移量，kafka的数据是顺序写入，顺序拉取的 Group 同一个消费组的消费者不能制定同一个topic的同一个partition ACK机制 producer acks=0 producer不等待Broker的ACK，这种方式延迟最低，但如果在还未保存数据，broker故障，则数据丢失。 acks=1 producer等待broker的leader写成功后返回ACK，此方式为默认方式。如果在leader与follower同步成功前leader故障，可能带来数据丢失。 acks=-1(all) producer等待broker的leader和follwer全部写数据成功后保存，此方法效率最低，但数据一致性最高。 consumer 与通常的mq

broker.id=3 listeners=PLAINTEXT://10.86.6.56:9092 advertised.listeners=PLAINTEXT://10.160.242.130:9092 num.network.threads=3 num.io.threads=8 socket.send.buffer.bytes=102400 socket.receive.buffer.bytes=102400 socket.request.max.bytes=104857600 log.dirs=/tmp/kafka-logs num.partitions=3 num.recovery.threads.per.data.dir=1 offsets.topic.replication.factor=3 transaction.state.log.replication.factor=3 transaction.state.log.min.isr=3 min.insync.replicas=2 log.retention.hours=72 log.segment.bytes=1073741824 log.retention.check.interval.ms=300000 zookeeper.connect=zk-node1:2181,zk-node2:2181,zk-node3