Kafka

Apache Kafka 是由Apache软件基金会开发的一个开源消息系统项目，由Scala写成。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。 Kafka是一个分布式的、分区的、多复本的日志提交服务。它通过一种独一无二的设计提供了一个消息系统的功能，让我一起来看看关于Apache Kafka的实战操作吧！ 由于整个PDF文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。如有需要获取资料文档的朋友 可以 三连文章 后台私信我【学习】或者查看下方即可获得免费领取。 第1章 认识Apache Kafka 1.1 Kafka快速入门 1.2 消息引擎系统 1.3 Kafka概要设计 1.4 Kafka基本概念与术语 1.5 Kafka使用场景 第2章 Kafka发展历史 2.1 Kafka的历史 2.2 Kafka版本变迁 2.3 如何选择Kafka版本 2.4 Kafka与Confluent 第3章 Kafka线上环境部署 3.1 集群环境规划 3.2 伪分布式环境安装 3.3 多节点环境安装 3.4 验证部署 3.5 参数设置 第4章 producer开发 4.1 producer概览 4.2 构造producer 4.3 消息分区机制 4.4 消息序列化 4.5 producer拦截器 4.6 无消息丢失配置 4.7 消息压缩 4.8 多线程处理 第5章

一般而言，如果你选择RabbitMQ，那肯定就是把可靠性放在第一位。毕竟，RabbitMQ可是金融行业消息队列的标配。如果把性能放在第一位，那毫无疑问，必须是Kafka。但是，可靠性毕竟是相对的，就拿大火的阿里云，AWS云，或者传统的IBM小型机，Oracle数据库，没有谁敢说自己可靠性100%，都是说几个9。所以，本文的目的很明确，就是尽可能的提高我们RabbitMQ的可靠性，从发送、存储、消费、集群、监控、告警等多个维度给出可行性方案，指导开发者以及运维人员获取更加可靠的消息投递，保障我们的业务系统安全、可靠、稳定的运行。 数据可靠性是和RabbitMQ节点、生产者、消费者以及服务器等息息相关的。本文比较长，大概分为如下几个段落： 确认机制 生产者 消费者 队列镜像 告警 监控和Metrics 健康检查 如下是一张RabbitMQ架构图，本文对可靠性的分析，会涉及到架构图中的方方面面： 1. 确认机制 当连接出现问题的时候，在客户端和服务端之间的消息可能正在投递中，还没有被Broker接收，它们可能正在被编码或者解码，或者一些其他的情况。在这种场景下，消息并没有被投递，那么它们是需要被重新投递以保障业务稳定性。确认机制让服务端和客户端知道什么时候需要做这些事情，它对于生产者和消费者保障数据安全是非常重要的。 确认机制能被用在两个方向：允许消费者告诉服务器（Broker

一 磁盘读写原理 磁盘的结构图： 当需要从磁盘读取数据时，要确定读的数据在哪个磁道，哪个扇区： 首先必须找到柱面，即磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间; 然后目标扇区旋转到磁头下,这个过程耗费的时间叫做旋转时间； 一次访盘请求（读/写）完成过程由三个动作组成 寻道（时间）：磁头移动定位到指定磁道; 旋转延迟（时间）：等待指定扇区从磁头下旋转经过； 数据传输（时间）：数据在磁盘、内存与网络之间的实际传输 由于存储介质的特性，磁盘本身存取就比主存慢，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分之一甚至几千分支一 二 利用page cache+mmap 1.page cache Page Cache ：以Page为单位，缓存文件内容。缓存在Page Cache中的文件数据，能够更快的被用户读取。同时对于带buffer的写入操作，数据在写入到Page Cache中即可立即返回，而不需等待数据被实际持久化到磁盘，进而提高了上层应用读写文件的整体性能。cached这列的数值表示的是当前的页缓存（page cache）的占用量，page cache文件的页数据，页是逻辑上的概念，因此page cache是与文件系统同级的 buffer cache：磁盘等块设备的缓冲，内存的这一部分是要写入到磁盘里的 。buffers列 表示当前的块缓存（buffer

一.Hadoop简介 Hadoop是一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。简单地说来，Hadoop是一个可以更容易开发和运行处理大规模数据的软件平台。 Hadoop的核心组件是HDFS、MapReduce。随着处理任务不同，各种组件相继出现，丰富Hadoop生态圈，目前生态圈结构大致如图所示： 二.Hadoop生态圈组件介绍 1.HDFS（分布式文件系统） HDFS是整个hadoop体系的基础，负责数据的存储与管理。HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。 client：切分文件，访问HDFS时，首先与NameNode交互，获取目标文件的位置信息，然后与DataNode交互，读写数据 NameNode：master节点，每个HDFS集群只有一个，管理HDFS的名称空间和数据块映射信息，配置相关副本信息，处理客户端请求。 DataNode：slave节点，存储实际数据，并汇报状态信息给NameNode，默认一个文件会备份3份在不同的DataNode中，实现高可靠性和容错性。

🎙️阅读本文需要 5 分钟 为了方便 Kafka 用户使用 Pulsar，Pulsar 对 Kafka Client 做了一些封装，让 Kafka 用户更方便的使用 Pulsar。 本篇内容主要介绍 Kafka Client 如何将消息发送到 Pulsar, 并从 Pulsar 消费消息，以及如何使用 Pulsar Schema。 ⌨️ 引入依赖 < dependency > < groupId > org.apache.pulsar </ groupId > < artifactId > pulsar-client-kafka </ artifactId > < version > {project.version} </ version > </ dependency > 依赖引入了 Kafka 的 0.10.2.1 版本的客户端，还有 Pulsar 对 Kafka Client 封装后的客户端。 ⌨️ 使用 Kafka Schema >>> 添加生产者代码 String topic = "persistent://public/default/test" ; Properties props = new Properties(); props.put( "bootstrap.servers" , "pulsar://localhost:6650" ); props.put(

大数据界很早以前就意识到了批处理的不足，实际应用中对于实时查询和流处理的需求越来越迫切。近年来涌现出了很多解决方案，像Twitter的Storm，Yahoo的S4，Cloudera的Impala，Apache Spark, 和 Apache Tez 等。本文试着去研究这些流式处理技术，溯寻这些技术与批量处理以及OLTP/OLAP之间的关联，并探讨如何用一个统一的查询引擎来同时支持流处理、批处理和OLAP。 在Grid Dynamics（作者工作的公司名），我们需要建立一个每天要处理80亿条数据的流式数据处理系统，并且要有良好的容错性和严格的事务约束，数据不允许丢失或者重复。这个系统要作为对已有的基于hadoop系统的补充，hadoop系统的数据延迟以及维护成本都太高了。这个需求以及系统本身都是极具通用性和典型性的，我们提出了一个模型来来抽象这类问题。 工作环境如下图： 可以看出，这是一个非常典型的场景：分布在多个数据中心的应用产生数据，然后被采集系统传递到hdfs上，用hadoop系列工具（MapReduce, Pig, Hive）对原始数据进行聚合和分析，结果储存在hdfs或者NoSQL里，再导入到OLAP数据库或者提供给各种应用使用。我们现在要增加一个流处理引擎（如下图所示），可以对数据进行预处理，这样可以减少hadoop上原始数据的数量并减少重量级批处理作业的数量

温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。 Fayson的github：https://github.com/fayson/cdhproject 提示：代码块部分可以左右滑动查看噢 1.文档编写目的 最近后台有位兄弟向Fayson提了一个问题，原文如下： “ 就是我的hdfs机器配置两个ip，一个外部可以访问，一个内部互联的地址，机器的hostname都是配置内网地址，现在有一个集群外的机器要写hdfs文件，发现namenode分配的datanode的地址是内网地址，不能访问到，这个不知道怎么去配置了。 ” Fayson想了想这个问题其实在各个环境是都可能碰到的，于是在这篇文章给大家系统介绍一下。 在做Hadoop应用开发时有多种方式访问HDFS文件系统（如：FileSystem、WebHdfsFileSystem），Fayson前面的文章《 如何使用Java代码访问HDFS.docx 》已讲过使用FileSystem访问HDFS。另外一种基于REST的API实现，分为两种一种是Hortonworks提供的WebHDFS默认的与Hadoop集成，一种是Cloudera 提供的HttpFS需要安装独立的HttpFS服务。本篇文章主要介绍如何使用WebHdfs和HttpFS方式访问HDFS。两种方式具体架构如下图： 内容概述 1

Flink基于Kafka-Connector 数据流容错回放机制及代码案例实战-Flink牛刀小试 Flink牛刀小试系列目录 Flink牛刀小试-Flink 集群运行原理兼部署及Yarn运行模式深入剖析 Flink牛刀小试-Flink Window类型及使用原理案例实战 Flink牛刀小试-Flink Broadcast 与 Accumulators 应用案例实战 Flink牛刀小试-Flink与SparkStreaming之Counters& Accumulators 累加器双向应用案例实战 Flink牛刀小试-Flink分布式缓存Distributed Cache应用案例实战 Flink牛刀小试-Flink状态管理与checkPoint数据容错机制深入剖析 Flink牛刀小试-Flink Window分析及Watermark解决乱序数据机制深入剖析 Flink牛刀小试-Flink Restart Strategies 重启策略机制深入剖析 Flink牛刀小试-Flink CheckPoint状态点恢复与savePoint机制对比剖析 Flink牛刀小试-Flink SQL Table 我们一起去看2018中超联赛 Flink牛刀小试-Flink基于Kafka-Connector 数据流容错回放机制及代码案例实战 [Flink牛刀小试-Flink

Java多线程编程核心技术_完整版 第1章 Java多线程技能 第2章 对象及变量的并发访问 第3章 线程间通信 第4章 Lock的使用 第5章 定时器Timer 第6章 单例模式与多线程 第7章 拾遗增补 Java 给多线程编程提供了内置的支持。 一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。 多线程是多任务的一种特别的形式，但多线程使用了更小的资源开销。 这里定义和线程相关的另一个术语 - 进程：一个进程包括由操作系统分配的内存空间，包含一个或多个线程。一个线程不能独立的存在，它必须是进程的一部分。一个进程一直运行，直到所有的非守护线程都结束运行后才能结束。 多线程能满足程序员编写高效率的程序来达到充分利用 CPU 的目的。 Redis实战核心篇 第1章 初识Redis 第2章 使用Redis构建Web应用 第二部分　核心概念 第3章 Redis命令 第4章 数据安全与性能保障 第5章 使用Redis构建支持程序 第6章 使用Redis构建应用程序组件 第7章 基于搜索的应用程序 第8章 构建简单的社交网站 第三部分　进阶内容 第9章 降低内存占用 第10章 扩展Redis 第11章 Redis的Lua脚本编程 Redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多

1.kafka消费者编程模型 分区消费模型 组(group)消费模型 1.1.分区消费模型 1.1.1.分区消费架构图，每个分区对应一个消费者。 1.1.2.分区消费模型伪代码描述 指定偏移量，用于从上次消费的地方开始消费. 提交offset ，java客户端会自动提交的集群，所以这一步可选。 1.2.组(group)消费模型 1.2.1.组消费模型架构图 每个组都消费该topic的全量数据,一条消息会发给groupA和groupB. 1.2.2.组消费模型伪代码： 流数N：表示一个consumer组里面有几个consumer 实例，上例中组A创建2个流，组B创建4个流。 1.2.3.consumer分配算法 当kafka的分区个数大于组A里consumer实例个数时，怎么去分配，以下为分配步骤： 1.3.两种消费模型对比 Partition消费模型更加灵活但是： （1）需要自己处理各种异常情况； （2）需要自己管理offset(以实现消息传递的其他语义)； Group消费模型更加简单，但是不灵活： （1）不需要自己处理异常情况，不需要自己管理offset； （2）只能实现kafka默认的最少一次消息传递语义； 知识补充：消息传递的3中语义： 至少一次，(消息不会丢,消息者至少得到一次，但有可能会重复，生产者向消费者发送之后，会等待消费者确认，没收到确认会再发) (kafka