Kafka

在移动互联网时代掉队的.NET，当下正凭借着.NET5的开源跨平台以及容器友好，在云原生时代正在重铸辉煌。而作为.NET开发者，新年跳槽季的高并发问题会更多了，因为高并发能牵扯出太多问题，接口响应超时、CPU负载升高、GC频繁、死锁、大数据量存储等，最能考察求职者的真实情况。千万并发级的.NET5项目，是怎样炼成的？ 理解高并发 公认的高并发场景：双11、春运抢票、微博大V热点新闻、秒杀系统、日均千万级订单系统、亿级日活信息流，然而这些高并发场景，并发量各不相同，那到底多大并发才算高并发呢？ 而很多人在这里就倒下了，因为对数据化的指标没有概念：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等关键数据，谈优化只是隔靴搔痒。 高并发的目标 高并发就是高性能？其实不然， 高并发系统设计的目标有三个：高性能、高可用，以及高可扩展。 高性能 性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。优化用户的体验，响应时间分别是100毫秒、1秒、3秒，给用户的感受是完全不同的。 高可用 表示系统可以正常服务的时间。对于高并发系统，最基本的要求能做到3个9以上，像一些大公司每年动辄千亿以上的GMV，1%(2个9)不可服务就是10亿级别的业务影响。 高扩展 表示系统的扩展能力

一、flink状态原理 1.1 什么是flink中的状态？为什么需要状态管理？ ​ flink运行计算任务的过程中，会有很多中间处理过程。在整个任务运行的过程中，中间存在着多个临时状态，比如说某些数据正在执行一个operator，但是只处理了一半数据，另外一般还没来得及处理，这也是一个状态。 ​ 假设运行过程中，由于某些原因，任务挂掉了，或者flink中的多个task中的一个task挂掉了，那么它在内存中的状态都会丢失，如果这时候我们没有存储中间计算的状态，那么就意味着重启这个计算任务时，需要从头开始将原来处理过的数据重新计算一遍。如果存储了中间状态，就可以恢复到中间状态，并从该状态开始继续执行任务。这就是状态管理的意义。所以需要一种机制去保存记录执行过程中的中间状态，这种机制就是状态管理机制。 1.2 flink中状态的分类 flink中包括两种基础状态：keyed state（keyed状态）和operator state（operator状态） 1.2.1 keyed状态 keyed状态总是与key一起，且只能用在keyedStream中。这个状态是跟特定的key绑定的，对KeyedStream流上的每一个key，可能都对应一个state。唯一组合成（operator--key，state）的形式。 1.2.2 operator状态 与Keyed State不同

最开始的网站架构 最初业务量不大，访问量小，此时的架构，应用程序、数据库、文件都部署在一台服务器上，有些甚至仅仅是租用主机空间 1. 应用、数据、文件分离 将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 2. 利用缓存改善网站性能 大部分网站访问都遵循28原则,即80%的访问请求，最终落在20%的数据上,所以我们可以对热点数据进行缓存，减少热点数据的访问路径，提高用户体验。缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理。 2.1 本地缓存 本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。 2.2 分布式缓存 分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。 2.3 反向代理 部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。 2.4 CDN 假设我们的服务器都部署在杭州的机房，对于浙江的用户来说访问是较快的，而对于北京的用户访问是较慢的

还是一样，要先引入依赖，在pom.xml <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-planner_2.12</artifactId> <version>1.10.1</version> </dependency> 从文件中读取数据 新建一个 TableApiFromFile的object： /** * * @author mafei * @date 2020/11/22 * * 把txt内容注册成为表，按照预期的格式输出出来 */ package com.mafei.apitest.tabletest import org.apache.flink.streaming.api.scala._ import org.apache.flink.table.api.{DataTypes, Table} import org.apache.flink.table.api.scala._ import org.apache.flink.table.descriptors.{Csv, FileSystem, OldCsv, Schema} object TableApiFromFile { def main(args: Array[String]): Unit = { //1 、创建环境

高可靠性分析 Kafka的高可靠性的保障来源于其健壮的副本（replication）策略。通过调节其副本相关参数，可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供Partition级别的复制，replication数量可以配置文件（default.replication.refactor）中或者创建Topic的时候指定。 这里先从Kafka文件存储机制入手，从最底层了解Kafka的存储细节，进而对存储有个微观的认知。之后通过Kafka复制原理和同步方式来阐述宏观层面的概念。最后从ISR，HW，leader选举以及数据可靠性和持久性保证等等各个维度来丰富对Kafka相关知识点的认知。 Kafka文件存储机制 Kafka中消息是以Topic进行分类的，生产者通过Topic向Kafka Broker发送消息，消费者通过Topic读取数据。然而Topic在物理层面又能以Partition为分组，一个Topic可以分成若干个Partition，那么Topic以及Partition又是怎么存储的呢？Partition还可以细分为Segment，一个partition物理上由多个Segment组成，那么这些Segment又是什么呢？下面我们来一一揭晓。 为了便于说明问题，假设这里只有一个Kafka集群，且这个集群只有一个Kafka Broker

点击上方蓝字“极客运维”一起运筹帷幄 提问的艺术理论上适用于任何行业，在 IT 行业应该普及的较广了。这里只是做一下归纳总结，以供萌新们翻阅，大佬们忽略即可。 提问前你必须需要知道的事情 要知道， Free 的正确翻译是 自由 ，而非 免费 。 要知道，愿意回答问题的人，都是 可爱 的人。 要知道，向帮助你的人 付费 是一个高尚的行为。即使回答你的人不是为了钱。 要知道，花钱买时间一个是常识。如果你不能认同，要么你钱包穷，要么你思想穷。 要知道，给对方发工资的不是你或者你老板。 要知道，提问的时候你才是 孙子 ，帮助你的人是 大爷 。 要知道，不回答你的问题对其他人没有任何损失。 要知道，准确描述一件事情是一项基本生存技能。要学会 《提问的智慧》 要知道，搜索是一项基本生存技能，学不会用 Google 的话，你可能真的不太适合你所从事的行业。 要知道，英文是一项基本生存技能，不认识英文的话，你可能真的不太适合你所从事的行业。 幼儿园的小朋友都知道要有礼貌 请问 ...问题描述... 谢谢 学会描述问题 请问一个关于 什么 的问题。 我想要达到 什么样 效果，但是我这样做出现了 什么样 的问题。 报错日志是 这样 的。（要 学会 画关键字） 我尝试过 什么方法 来解决。 我尝试搜索过了 什么关键字 ，在里面找到了 这些 URL 的回答，尝试了还是没有解决问题。 我用的是 什么

使用KafkaUtil来实现SparkStreaming的对接。 KafkaUtil共有两个版本： spark-streaming-kafka-0-8 spark-streaming-kafka-0-10 kafka version 0.8.2.1 or higher 0.10.0 or higher Offset Commit API × √ 其中0.8版本已经被遗弃， 不建议使用。 消费kafka共有三种消费语义： 1.At most once： 至多消费一次 2.At least once: 至少一次 3.Exactly once:精确消费一次 其中， at least once级别推荐使用官方API对kafka offset进行维护， 代码如下： object SSApp02 { def main(args: Array[String]): Unit = { val sparkConf = new SparkConf().setMaster("local[2]").setAppName("hehe") val ssc = new StreamingContext(sparkConf, Seconds(3)) ssc.sparkContext.setLogLevel("ERROR") val kafkaParams = Map[String, Object](

https://blog.csdn.net/dingding_ting/article/details/84862776 https://blog.csdn.net/xianpanjia4616/article/details/84347087 kafka-0.10.1.X版本之前: auto.offset.reset 的值为smallest,和,largest.(offest保存在zk中) kafka-0.10.1.X版本之后: auto.offset.reset 的值更改为:earliest,latest,和none (offest保存在kafka的一个特殊的topic名为:__consumer_offsets里面) auto.offset.reset： 可理解为kafka consumer读取数据的策略，本地用的kafka版本为0.10，因此该参数可填earliest|latest|none。 earliest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费 latest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据 none： topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset

最开始的网站架构 最初业务量不大，访问量小，此时的架构，应用程序、数据库、文件都部署在一台服务器上，有些甚至仅仅是租用主机空间 1. 应用、数据、文件分离 将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 2. 利用缓存改善网站性能 大部分网站访问都遵循28原则,即80%的访问请求，最终落在20%的数据上,所以我们可以对热点数据进行缓存，减少热点数据的访问路径，提高用户体验。缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理。 2.1 本地缓存 本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。 2.2 分布式缓存 分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。 2.3 反向代理 部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。 2.4 CDN 假设我们的服务器都部署在杭州的机房，对于浙江的用户来说访问是较快的，而对于北京的用户访问是较慢的

今 天主要聊聊数仓的基础知识，分为两篇文章介绍，这是第一篇。 主要内容： 数仓基本概念 数仓架构演变 实时数仓和离线数仓的区别 数仓基本概念 首先说一下数据仓库的概念，以下简称数仓。 数仓是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 主题 是公司从宏观出发，为了分析数据，分了用户主题、商品主题、设备主题等有助于决策的数据模型。 随着互联网的发展，数据源头越来越多且是分散的，除了业务库，APP埋点，web网站log，LOT 设备等会产生各种各样的海量数据，这些数据在进入数据仓库之前（或之后），需要进行统一（字段定义、主题归属、项目划分等），数据 集成 在一起。 数仓中的数据是不可修改的，主要用于数据查询，是相对 稳定 的。 数仓的数据一般都带有时间特征，数据是随着时间的变化而变化的。 数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合， 反应历史变化 。 数仓从模型层面分为三层： ODS，操作数据层，保存原始数据； DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据； DM，数据集市/轻度汇总层，在DWD层的基础之上根据不同的业务需求做轻度汇总； 很多面试的时候