Kafka

作者 | 悟空聊架构 来源 | 悟空聊架构 （ID：PassJava666） 转载请联系授权（微信ID：PassJava） 本篇主要内容如下： 主要内容 前言 我们都在讨论分布式，特别是面试的时候，不管是招初级软件工程师还是高级，都会要求懂分布式，甚至要求用过。传得沸沸扬扬的分布式到底是什么东东，有什么优势？ 借用火影忍术 风遁 · 螺旋手里剑 看过 火影 的同学肯定知道 漩涡鸣人 的招牌忍术： 多重影分身之术 。 这个术有一个特别厉害的地方， 过程和心得 ：多个分身的感受和经历都是相通的。比如 A 分身去找卡卡西（鸣人的老师）请教问题，那么其他分身也会知道 A 分身问的什么问题。 漩涡鸣人 有另外一个超级厉害的忍术，需要由几个影分身完成： 风遁·螺旋手里剑。 这个忍术是 靠三个鸣人一起协作完成的。 这两个忍术和分布式有什么关系？ 分布在不同地方的系统或服务，是彼此相互关联的。 分布式系统是分工合作的。 案例： 比如 Redis 的 哨兵机制 ，可以知道集群环境下哪台 Redis 节点挂了。 Kafka的 Leader 选举机制 ，如果某个节点挂了，会从 follower 中重新选举一个 leader 出来。（leader 作为写数据的入口，follower 作为读的入口） 那 多重影分身之术 有什么缺点？ 会消耗大量的查克拉。分布式系统同样具有这个问题，需要几倍的资源来支持。

作者：买蓉 · 美团点评高级技术专家 整理：赵阳（Flink 社区志愿者） 校对：苗浩冲（Flink 社区志愿者） 本文将从数仓诞生的背景、数仓架构、离线与实时数仓的对比着手，综述数仓发展演进，然后分享基于 Flink 实现典型 ETL 场景的几个方案。 1.实时数仓的相关概述 1.1 实时数仓产生背景 我们先来回顾一下数据仓库的概念。 数据仓库的概念是于90年代由 Bill Inmon 提出, 当时的背景是传统的 OLTP 数据库无法很好的支持长周期分析决策场景，所以数据仓库概念的4个核心点，我们要结合着 OLTP 数据库当时的状态来对比理解。 面向主题的：数据仓库的数据组织方式与 OLTP 面向事务处理不同。因为数据仓库是面向分析决策的，所以数据经常按分析场景或者是分析对象等主题形式来组织。 集成的：对于数据仓库来说，经常需要去集合多个分散的、异构的数据源，做一些数据清洗等 ETL 处理，整合成一块数据仓库，OLTP 则不需要做类似的集成操作。 相对稳定的：OLTP 数据库一般都是面向业务的，它主要的作用是把当前的业务状态精准的反映出来，所以 OLTP 数据库需要支持大量的增、删、改的操作。但是对于数据仓库来说，只要是入仓存下来的数据，一般使用场景都是查询，因此数据是相对稳定的。 反映历史变化：数据仓库是反映历史变化的数据集合，可以理解成它会将历史的一些数据的快照存下来。而对于

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据 订阅 和 消费 。应该是阿里云DTS（Data Transfer Service）的开源版本，开源地址： https://github.com/alibaba/canal。 canal从1.1.4版本开始引入了admin控制台，有了很多不一样的配置方式。在搭建过程中如果仅仅按照wiki的用户手册，还是容易踩很多坑的。因此，将笔者在搭建过程中的步骤记录下来，作为官方wiki的 补充，希望能有所帮助。 根据本文内容与搭建顺序 ，并搭配对应的官网文档链接，应该就能快速搭建完成了，enjoy~ 1. 部署canal-admin 1）部署服务 官方文档地址： https://github.com/alibaba/canal/wiki/Canal-Admin-QuickStart 主要配置application.yml文件 server : port : 8089 s pring : jackson : date-format : yyyy-MM-dd HH : mm :ss time-zone : GMT+ 8 s pring. datasource : address : 127.0 . 0.1 : 3306 database : canal_manager username

什么是消息队列 MQ全称为Message Queue 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 你可以想想在生活中的一种场景：当你把信件的投进邮筒，邮递员肯定最终会将信件送给收件人。我们可以把MQ比作 邮局和邮递员。 MQ和邮局的主要区别是,它不处理消息,但是,它会接受数据、存储消息数据、转发消息 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 如果有人问你这个问题，期望的一个回答 是说，你们公司有个什么业务场景 ，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个： 解耦 、 异步 、 削峰 。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合

前言 最新项目中要用到消息队列来做消息的传输，之所以选着 Kafka 是因为要配合其他 java 项目中，所以就对 Kafka 了解了一下，也算是做个笔记吧。 本篇不谈论 Kafka 和其他的一些消息队列的区别，包括性能及其使用方式。 简介 Kafka 是一个实现了分布式的、具有分区、以及复制的日志的一个服务。它通过一套独特的设计提供了消息系统中间件的功能。它是一种发布订阅功能的消息系统。 一些名词 如果要使用 Kafka ，那么在 Kafka 中有一些名词需要知道，文本不讨论这些名词是否在其他消息队列中具有相同的含义。所有名词均是针对于 Kafka。 Message 消息，就是要发送的内容，一般包装成一个消息对象。 Topic 通俗来讲的话，就是放置“消息”的地方，也就是说消息投递的一个容器。假如把消息看作是信封的话，那么 Topic 就是一个邮筒，如下图所示： Partition && Log Partition 分区，可以理解为一个逻辑上的分区，像是我们电脑的磁盘 C:, D:, E: 盘一样, Kafka 为每个分区维护着一份日志Log文件。 每个分区是一个有序的，不可修改的，消息组成的队列。 当消息过来的时候，会被追加到日志文件中，这个追加是根据 commit 命令来执行的。 分区中的每一条消息都有一个编号，叫做 offset id，这个 id 在当前分区中是唯一的

GOREPLAY是一个网络流量转发的应用，之前的名字叫GOR，GITHUB上的作者有介绍，更准确说应该是HTTP流量转发，作者的目标应该是WEB型应用在内网的转发，因为HTTP是一个应用广泛的协议，并且是标准的，因此从这个角度出发编写出来的转发应用能够在绝大多数的场景使用。这也会带来一定的问题，假设我们要转发其他的协议类型，这个时候需要自行编码识别协议的边界再做转发。 GOREPLAY使用GO语言编写，使用了一系列GO的工具，如操作pcap、kafka等。运行goreplay的前提也需要安装pcap等工具，并且需要在root权限下才能打开网卡的混杂模式，监听指定端口的所有tcp报文。GOREPLAY的工作流程： 1.使用pcap的go接口，使用bpf（伯克利包过滤）设置指定端口的过滤表达式，bpf可以参考tcpdump工具的表达式，tcpdump命令背后也是使用了bpf。 2.截取到tcp报文之后，根据网络五元组（又一个名词，<源IP，源端口，目标IP，目标端口，协议>，实际程序中没有使用协议这个字段）作为key露拼装message，因为HTTP基于TCP协议，根据TCP协议中的ACK以及SEQ识别一次调用包的完整性。想读懂代码需要对TCP协议报文格式，HTTP协议格式有一定的了解，除了普通HTTP协议报文，还需要了解CHUNKED等比较少见的报文。 3

根据 2017 年的 DevOps 发展报告，高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力，涉及众多环节，其中发布是尤为重要的环节。 作为技术人员，大家可能听说过“滚动发布”和“蓝绿发布”等术语，但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略，每个的优劣，适用性，让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识，让大家能够根据自己的企业上下文，对发布策略做出正确的选型和实践。 一、单服务器组发布 先解释下单服务器组的概念，早先我们机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）这么发达，所以应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 住在这 n 台机器上，那么下次升级发布的应用 A 也住在这 n 台机器上，所以称为单服务器组发布方式。 1.1 蛮力发布 如下图所示，这种发布方式比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成，先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断（停机），在开发测试环境是可行的，但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。 发布前 发布后 优势和适用场合 优势： 简单成本低 不足： 服务中断用户受影响，出了问题回退也慢 适用场合： 开发测试环境 非关键应用（用户影响面小）

CDH中kafka想要在删除topic时，彻底删除，需要在kafka的配置页中进行如下配置： 设置 delete.topic.enable=true 设置完成后重启kafka即可。 来源： oschina 链接： https://my.oschina.net/u/4332858/blog/4275773

给大家分享4个项目，别小看这四个项目。 互联网大部分公司项目用到的技术可能还没这几个项目用到的多。 都快2021年了，没有微服务、分布式的项目经验真的有点难了，其次在项目中用到的中间接比如Redis、MQ、Nginx、solr、ElasticSearch、Docker、Dubbo、Kafka、ShardingSphere等等。 从业务梳理到环境配置再到具体模块的代码实现，视频里都讲的都很细致，而且提供源码！ 以下项目均为视频版本，包含源码和课堂笔记 项目分别是： 青橙商城完整版 后台+前台+青橙秒杀 Java大型电商系统谷粒商城项目开发实践 淘淘商城 （分布式基于SS M ） 大型微服务项目十次方 【乐优商城】项目（SpringBoot、SpringCloud、Vue） 以上2个项目获取方式 扫描下方二维码，回复 「 项目 」 👆 长按上方二维码 2 秒 回复「 项目 」即可获取实战项目 部分截图大家感受一下。 图片可上下滑动 另外在平时在学习的时候有画思维导图的习惯，一方面加强自己的记忆，另一方面也方便自己复习。 分享一些学习的思维导图，包括具体内容看下图吧！真的是太良心了 完整思维导图获取方式： 1、扫描下方二维码 2、回复关键字： 导图 👆长按上方二维码 2 秒 回复「 导图 」 即可获取资料 本文分享自微信公众号 - Java专栏（finishbug）。 如有侵权，请联系

深度剖析了各个基础技术的源码(ZooKeeper、Hive、Spark、Flink、Hadoop等)，对这些基础技 术知识动态的排列组合，形成大数据全局架构观，并深入讲述大数据全局架构设计的方方面面，打 造真正满足企业万亿级海量数据规模的数据中台，真正赋能前台业务。同时，在企业万亿级真实项 目落地环节，采用高性能、高可用、高扩展的架构设计原则，技术上更是融合了企业级主流的离线 架构和实时架构，带领大家构建PB级的大数据中台，真正落地“企业千亿级的数据仓库中台”，实现 “企业级数据中心平台”，搞定“企业千亿级广告统一数据流智能分析平台”，掌握“企业级Hadoop平 台全方位二次源码开发”，让学员面对企业各种海量复杂业务场景，给出优雅的大数据架构设计方 案，从而真正成为企业级大数据架构师! ​ 第一阶段：分布式协调组件 第一单元 掌握ZooKeeper的核心设计 ZooKeeper生态体系结构 ZooKeeper总体架构设计 ZooKeeper读写请求流程深度剖析 第二单元 掌握ZooKeeper服务端源码流程 ZooKeeper启动流程源码深度剖析 Master选举算法源码深度剖析 服务端通信模型源码深度剖析 第三单元 掌握ZooKeeper客户端源码流程 客户端启动流程源码剖析 客户端通信模型源码剖析 Session管理机制源码剖析 第四单元 掌握ZooKeeper企业应用