Kafka

.net core kafka 入门实例 一篇看懂 kafka 相信都有听说过，不管有没有用过，在江湖上可以说是大名鼎鼎，就像天龙八部里的乔峰。国际惯例，先介绍生平事迹 简介 Kafka 是由 Apache软件基金会 开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka是一种高吞吐量的 分布式 ，支持分区（partition），多副本（replica）的 发布订阅消息系统 。与其他MQ最大不同是Topic 具有分区（Partition）的概念，消息出队的速度也比其他MQ快。 特性及适用场景 高吞吐量、低延迟 可扩展性：集群支持热扩展 持久性、可靠性 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） 高并发：支持数千个客户端同时读写 常用场景 日志收集 消息系统：生产者和消费者、缓存消息等。 用户活动跟踪：流网页、搜索、点击等活动 运营指标 工作流处理 对实时性要求不高的数据处理 Kafka基础概念 Topic Kafka 中可将消息分类，每一类的消息称为一个 Topic(主题)，消费者可以对不同的 Topic 进行不同的处理。Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition

Flink： Apache Flink是一个计算框架和分布式处理引擎，用于对***和有界数据流进行有状态计算。其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。 Flink主要特点： 1、高吞吐、低延迟、纯流式架构； 2、支持对乱序事件的处理； 3、有状态、提供exactly-once计算； 4、高度灵活的窗口机制； 5、失败恢复、故障转移、水平扩展； 6、批处理、流处理统一的API NBI大数据可视化： NBI一站式自服务大数据可视化分析平台是一款自助式可视化分析大屏展示平台，可以通过平台零代码或低代码方式构建各类数据展示分析； NBI拥有几十种传统图形和新型大数据图形组件（如桑 基图， treemap、层级聚类图、旭日图、热力矩 阵、日历矩阵、gis等等）能让您轻松构建各类炫 酷的数据大屏。 Flink+NBI实时数据分析系统构建方案： （1）通过kafka分布式消息队列接入各类数据源，比如IOT设备实时数据，服务器日志数据，应用系统日志数据，数据库数据等等； （2）然后通过Flink接入kafka，根据时间窗口，对各类指标做数据计算； （3）计算完毕后接入NBI大数据可视化分析平台，通过平台构建各类分析应用，做实时分析展示； 实时数据分析： NBI大数据 Kafka Flink 流计算 分布式 实时数据 实时分析系统 大数据 系统架构 来源： oschina

点击蓝色“ 程序员大帝 ”关注我哟 加个“ 星标 ”，及时阅读最新技术文章 每日鸡汤，好喝 前言 本文属于《从零开始消息中间件》的系列文章，之前的几篇文章向大家介绍了消息中间件 MQ 并进行了初步入门 ，大家可以看： 《 十分钟入门消息中间件 》 《 还在纠结秒杀？看看 MQ 如何搞定 》 《 消息中间件的正确打开方式 》 本篇文章开始，整个系列都会基于目前流行的 RocketMQ 为基础，开始对每个组件和场景进行深入的讲解，首先咱们来学习下 Topic。 正文 01 什么是Topic？ Topic 中文含义大家肯定不陌生，直接翻译过来是话题。而在 MQ 里，无论是 RocketMQ 还是 Kafka，都用 Topic 这个名词来代表一种 数据的集合 。 比如说，现在需要往 MQ 中发送订单的消息，那么我们就可以将这一种类的消息归为一个 Topic，给它取名为 order_info_topic，也就是一个包含了订单信息的数据集合。 接下来物流系统可以去这个 order_info_topic 中获取订单信息进行发货。简单的总结一下，Topic 并不具有真正的属性，它只是一类数据的集合，不同类型的数据我们应该放到不同的 Topic 中。 也就是说当有商品数据时，这时应该新建一个Topic，假设取名为 product_info_topic，代表这里面放的商品信息。获取商品数据时

Kafka是一种分布式消息队列，为何要使用消息队列？是基于异步通信的诉求，为了服务之间相互解耦，同时避免在高并发时完成流量削峰的作用。 一 基础概念： producer：消息生产者、 consumer：消息消费者、 topic：一个队列、 consumer group：消费者组 broker：一台kafka机器，一个broker可以容纳多个topic partition：每个topic包含多个partition 二 环境搭建： 1 首先需要java环境，下载安装jdk 2 下载kafka安装包，kafka_2.11-2.4.1.tgz。解压缩。 3 修改config/server.properties文件： #broker 的全局唯一编号，不能重复 broker.id=0 #删除 topic 功能使能 delete.topic.enable=true #kafka服务监听端口 listeners=PLAINTEXT://localhost:9092 #kafka 运行日志存放的路径 log.dirs=/opt/module/kafka/logs #配置连接 Zookeeper 集群地址 zookeeper.connect=localhost:2181 三 常见命令： zookeeper服务启动：/usr/local/kafka/bin/zookeeper-server-start

一、什么是消息队列 MQ (Message Quene) : 翻译为 消息队列 ,通过典型的 ⽣产者 和 消费者 模型,⽣产者不断向消息队列中⽣产消息，消费者不断的从队列中获取消息。因为消息的⽣产和消费都是异步的，⽽且只关⼼消息的发送和接收，没有业务逻辑的侵⼊,轻松的实现系统间解耦。别名为 消息中间件 通过利⽤⾼效可靠的消息传递机制进⾏平台⽆关的数据交流，并基于数据通信来进⾏分布式系统的集成。 二、为什么要使用MQ 1.解耦 现在我有一个系统A，系统A可以产生一个userId,然后，现在有系统B和系统C都需要这个userId去做相关的操作,可以写成如下操作 如果有一天，系统B的负责人告诉系统A的负责人，现在系统B的SystemBNeed2do(String userId)这个接口不再使用了，让系统A别去调它了。那么就需要从代码的基础上去修改了。这样紧密的耦合关系会导致很多麻烦，如果使用消息中间件就不会出现以上问题。 2.异步 我们再来看看下面这种情况：系统A还是直接调用系统B、C、D 假设系统A运算出userId具体的值需要50ms，调用系统B的接口需要300ms，调用系统C的接口需要300ms，调用系统D的接口需要300ms。那么这次请求就需要50+300+300+300=950ms 并且我们得知，系统A做的是主要的业务，而系统B、C、D是非主要的业务。比如系统A处理的是订单下单

项目介绍 项目整体介绍 1.项目模型搭建 此项目为数据仓库项目,主要是做离线计算的 项目模型:项目分为流量域和业务域两个主题域,为了方便管理这么多数据,又将每个主题域划分为五个层级,分别是ODS层,DWD层,DWS层,ADS层及DIM层,分层的原因为解耦,复用,便于管理,下面我分别介绍一下项目中他们的应用场景 1.1 ODS层 ODS层:源数据层,分为流量域ODS层及业务域ODS层 流量域ODS层:数据来源于日志服务器(用户行为日志数据(APP端和WEB端)),日志服务器将数据生产到Kafka,然后使用Flume日志采集工具消费Kafka中的数据并将数据采集到Hdfs集群,在Hive中将数据加载到ODS层的Hive表中,这样就完成了原始数据的采集 业务域ODS层:数据来源于业务系统中的关系型数据库mysql,采用sqoop抽取工具将数据从mysql导入到Hdfs中,再在Hive中将数据加载到ODS层相应的表中 1.2 DWD层 DWD层:数据明细层,同样分为流量域DWD层及业务域DWD层 流量域DWD层:将数据在ODS层进行ETL操作(先对ODS层数据进行清洗,过滤(过滤掉缺失重要字段信息,重要字段信息为空或者json格式不正确的数据),降维等操作),再抽取到DWD层 业务域DWD层:抽取ODS层每天的增量数据,与DWD层每天的全量数据进行合并

计算机各个组件之间的速度往往很不均衡，比如 CPU 和硬盘，比兔子和乌龟的速度差还大，那么按照我们前面介绍的木桶理论，可以说这个系统是存在着短板的。 当系统存在短板时，就会对性能造成较大的负面影响，比如当 CPU 的负载特别高时，任务就会排队，不能及时执行。而其中，CPU、内存、I/O 这三个系统组件，又往往容易成为瓶颈，所以接下来我会对这三方面分别进行讲解。 CPU 首先介绍计算机中最重要的计算组件中央处理器 CPU，围绕 CPU 一般我们可以： 通过 top 命令，来观测 CPU 的性能； 通过负载，评估 CPU 任务执行的排队情况； 通过 vmstat，看 CPU 的繁忙程度。 具体情况如下。 1.top 命令 —— CPU 性能 如下图，当进入 top 命令后，按 1 键即可看到每核 CPU 的运行指标和详细性能。 CPU 的使用有多个维度的指标，下面分别说明： us 用户态所占用的 CPU 百分比，即引用程序所耗费的 CPU； sy 内核态所占用的 CPU 百分比，需要配合 vmstat 命令，查看上下文切换是否频繁； ni 高优先级应用所占用的 CPU 百分比； wa 等待 I/O 设备所占用的 CPU 百分比，经常使用它来判断 I/O 问题，过高输入输出设备可能存在非常明显的瓶颈； hi 硬中断所占用的 CPU 百分比； si 软中断所占用的 CPU 百分比； st

常见的集群架构如图： redis操作过程中数据同步的函数调用关系： 集群搭建： 　　1.修改3个redis.config 文件的： 　　2.启动2个redis服务器 当杀掉redis主进程Master时，由于Slave（6380）只读，则无法向redis中写数据了，这时我们将借助sentinel工具进行监控主从服务器。 以上内容希望帮助到大家， 很多PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家 ，需要戳这里 PHP进阶架构师>>>实战视频、大厂面试文档免费获取 来源： oschina 链接： https://my.oschina.net/u/4234147/blog/4511551

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近，又重新学习了下Redis，深深被Redis的魅力所折服，我才知道Redis不仅能快还能慢（我想也这么优秀o(╥﹏╥)o），简直是个利器呀。 好了，接下来回到我们的话题，我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。（这就是为什么Redis既能快又能慢啦！） 那接下来开始讲讲我们的楷模Redis在队列中如何实现延时的情况： 在我们日常生活中，我们可以发现， 在淘宝、京东等购物平台上下单，超过一定时间未付款，订单会自动取消。 打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。 点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。 收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。 在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。 .......还有很多这样的场景。 这时，我们可以想想为什么要这样做？ 因为这样可以保证商品的库存可以释放给其他人购买，你可以不用一直等待打车却得不到回复，你可以及时换一家店点到外卖。

1.为什么要保证顺序 消息队列中的若干消息如果是对同一个数据进行操作，这些操作具有前后的关系，必须要按前后的顺序执行，否则就会造成数据异常。举例： 比如通过mysql binlog进行两个数据库的数据同步，由于对数据库的数据操作是具有顺序性的，如果操作顺序搞反，就会造成不可估量的错误。比如数据库对一条数据依次进行了 插入->更新->删除操作，这个顺序必须是这样，如果在同步过程中，消息的顺序变成了 删除->插入->更新，那么原本应该被删除的数据，就没有被删除，造成数据的不一致问题。 2.出现顺序错乱的场景 （1）rabbitmq ①一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先完成操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误。 rabbitmq消息顺序错乱第一种情况示意图.png ②一个queue对应一个consumer，但是consumer里面进行了多线程消费，这样也会造成消息消费顺序错误。 abbitmq消息顺序错乱第二种情况示意图.png （2）kafka ①kafka一个topic，一个partition，一个consumer，但是consumer内部进行多线程消费，这样数据也会出现顺序错乱问题。