分布式消息通信 kafka

最新推荐文章于 2023-08-15 15:35:08 发布
最新推荐文章于 2023-08-15 15:35:08 发布
阅读量458 收藏 1
点赞数 1
分类专栏： # 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wszcy199503/article/details/106643023
版权

Kafka 简介

Kafka 是一款分布式消息发布和订阅系统，具有高性能、高吞吐量的特点而被广泛应用与大数据传输场景。它由LinkedIn公司开发，使用Scala语言编写，之后成为Apache基金会的一个顶级项目。

典型应用

日志分析系统
在这里插入图片描述

为什么使用 Kafka

互联网公司在营销方面逐步要做到精细化运营需求，这样就能够针对不同的用户喜好推送不同的产品，而这个过程需要收集和分析用户的行为数据，而通过传统的ActiveMQ这类消息中间件在处理大数据传输的时候存在实效性、性能、消息堆积等问题。
kafka 早期设计的目的是作为linkln活动流和运营数据处理管道，它天然的具备了高吞吐量、内置分区、复制等能力而非常适合处理大规模的消息，因此很多的大数据传输场景都选用kafka，比如应用日志收集分析、消息系统、用户行为分析、运营指标（服务器性能数据）、流式处理（spark、storm）。

Kafka 架构组件

在这里插入图片描述

Kafka 架构图

在这里插入图片描述

安装 KafKa

  1. tar -zxvf .
  2. 进入到config目录下修改server.properties
    broker.id
    listeners=PLAINTEXT://192.168.174.128:9092
    zookeeper.connect
  3. 启动
    sh kafka-server-start.sh -daemon …/config/server.properties
    sh kafka-server-stop.sh

zookeeper上注册的节点信息

cluster, controller, controller_epoch, brokers, zookeeper, admin, isr_change_notification, consumers, latest_producer_id_block, config

controller 控制节点
brokers kafka集群的broker信息 。 topic
consumer ids/owners/offsets

Kafka 基本操作

Kafka 从 2.2 版本开始将脚本中的 −−zookeeper 参数标注为 “过时”，推荐使用 −−bootstrap-server 参数。若依旧使用的是 2.1 及以下版本，请将下述的 --bootstrap-server 参数及其值手动替换为 --zookeeper zk:2181,zk:2181,z:2181。一定要注意两者参数值所指向的集群地址是不同的。

启动服务器

sh kafka-server-start.sh ../config/server.properties

建立 Topic

--bootstrap-server 使用的是server.properties文件中listeners的配置（localhost和ip地址不视为相同）。

sh kafka-topics.sh --create --bootstrap-server 192.168.174.128:9092 --replication-factor 1 --partitions 1 --topic MyTopic

查看 Topic 列表

sh kafka-topics.sh --list --bootstrap-server 192.168.174.128:9092

发送消息

sh kafka-console-producer.sh --bootstrap-server 192.168.174.128:9092 --topic MyTopic

启动消费者

sh kafka-console-consumer.sh --bootstrap-server 192.168.174.128:9092 --topic MyTopic --from-beginning

Kafka 实现细节

消息

消息是 kafka 中最基本的数据单元。消息由一串字节构成，其中主要由key和value构成，key和value也都是byte数组。key的主要作用是根据一定的策略，将消息路由到指定的分区中，这样就可以保证包含同一key的消息全部写入到同一个分区中，key可以是null。为了提高网络的存储和利用率，生产者会批量发送消息到kafka，并在发送之前对消息进行压缩。

topic & partition

Topic是用于存储消息的逻辑概念，可以看作一个消息集合。每个topic可以有多个生产者向其推送消息，也可以有任意多个消费者消费其中的消息。
每个topic可以划分多个分区（每个Topic至少有一个分区），同一topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个offset（称之为偏移量），它是消息在此分区中的唯一编号，kafka通过offset保证消息在分区内的顺序，offset的顺序不跨分区，即kafka只保证在同一个分区内的消息是有序的；
在这里插入图片描述
在这里插入图片描述
Partition是以文件的形式存储在文件系统中，存储在kafka-log目录下，命名规则是：topic_name-partition_id（MyTopic-0）。

kafka的高吞吐量的因素

  1. 顺序写的方式存储数据
  2. 批量发送；在异步发送模式中。kafka允许进行批量发送，也就是先讲消息缓存到内存中，然后一次请求批量发送出去。这样减少了磁盘频繁io以及网络IO造成的性能瓶颈
    batch.size 每批次发送的数据大小
    linger.ms 间隔时间
  3. 零拷贝
    消息从发送到落地保存，broker维护的消息日志本身就是文件目录，每个文件都是二进制保存，生产者和消费者使用相同的格式来处理。在消费者获取消息时，服务器先从硬盘读取数据到内存，然后把内存中的数据原封不懂的通过socket发送给消费者。虽然这个操作描述起来很简单，但实际上经历了很多步骤：
  • 操作系统将数据从磁盘读入到内核空间的页缓存
  • 应用程序将数据从内核空间读入到用户空间缓存中
  • 应用程序将数据写回到内核空间到socket缓存中
  • 操作系统将数据从socket缓冲区复制到网卡缓冲区，以便将数据经网络发出
    在这里插入图片描述
    通过“零拷贝”技术可以去掉这些没必要的数据复制操作，同时也会减少上下文切换次数。
    在这里插入图片描述

日志策略

日志保留策略

无论消费者是否已经消费了消息，kafka都会一直保存这些消息，但并不会像数据库那样长期保存。为了避免磁盘被占满，kafka会配置响应的保留策略（retention policy），以实现周期性地删除陈旧的消息
kafka有两种“保留策略”：

  1. 根据消息保留的时间，当消息在kafka中保存的时间超过了指定时间，就可以被删除
  2. 根据topic存储的数据大小，当topic所占的日志文件大小大于一个阀值，则可以开始删除最旧的消息

日志压缩策略

在很多场景中，消息的key与value的值之间的对应关系是不断变化的，就像数据库中的数据会不断被修改一样，消费者只关心key对应的最新的value。我们可以开启日志压缩功能，kafka定期将相同key的消息进行合并，只保留最新的value值 。
在这里插入图片描述

文件存储机制

存储机制

在kafka文件存储中，同一个topic下有多个不同的partition，每个partition为一个目录，partition的名称规则为：topic名称+有序序号，第一个序号从0开始，最大的序号为partition数量减1，partition是实际物理上的概念，而topic是逻辑上的概念。
partition还可以细分为segment，这个segment是什么呢？ 假设kafka以partition为最小存储单位，那么我们可以想象当kafka producer不断发送消息，必然会引起partition文件的无线扩张，这样对于消息文件的维护以及被消费的消息的清理带来非常大的挑战，所以kafka 以segment为单位又把partition进行细分。每个partition相当于一个巨型文件被平均分配到多个大小相等的segment数据文件中（每个setment文件中的消息不一定相等），这种特性方便已经被消费的消息的清理，提高磁盘的利用率。
segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。
segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

查找方式

在这里插入图片描述
以上图为例，读取offset=170418的消息，首先查找segment文件，其中00000000000000000000.index为最开始的文件，第二个文件为00000000000000170410.index（起始偏移为170410+1=170411），而第三个文件为00000000000000239430.index（起始偏移为239430+1=239431），所以这个offset=170418就落到了第二个文件之中。其他后续文件可以依次类推，以其实偏移量命名并排列这些文件，然后根据二分查找法就可以快速定位到具体文件位置。其次根据00000000000000170410.index文件中的[8,1325]定位到00000000000000170410.log文件中的1325的位置进行读取。

消息可靠性机制

消息发送可靠性

生产者发送消息到broker，有三种确认方式（request.required.acks）：
acks = 0 producer不会等待broker（leader）发送ack 。因为发送消息网络超时或broker crash(1.Partition的Leader还没有commit消息 2.Leader与Follower数据不同步)，既有可能丢失也可能会重发。
acks = 1 当leader接收到消息之后发送ack，丢会重发，丢的概率很小
acks = -1 当所有的follower都同步消息成功后发送ack. 丢失消息可能性比较低。

消息存储可靠性

每一条消息被发送到broker中，会根据partition规则选择被存储到哪一个partition。如果partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。
在创建topic时可以指定这个topic对应的partition的数量。在发送一条消息时，可以指定这条消息的key，producer根据这个key和partition机制来判断这个消息发送到哪个partition。
kafka的高可靠性的保障来自于另一个叫副本（replication）策略，通过设置副本的相关参数，可以使kafka在性能和可靠性之间做不同的切换。

查看 kafka 数据文件内容

在使用kafka的过程中有时候需要我们查看产生的消息的信息，这些都被记录在kafka的log文件中。由于log文件的特殊格式，需要通过kafka提供的工具来查看：

sh kafka-run-class.sh kafka.tools.DumpLogSegments --files /tmp/kafka-logs/*/000**.log  --print-data-log

高可靠性的副本

在 kafka0.8 版本前，并没有提供这种High Availablity机制，也就是说一旦一个或者多个broker宕机，则在这期间内所有的partition都无法继续提供服务。如果broker无法再恢复，则上面的数据就会丢失。所以在0.8版本以后引入了High Availablity机制。

leader election

在 kafka 引入 replication 机制以后，同一个 partition 会有多个 Replica。那么在这些 replication 之间需要选出一个Leader，Producer或者Consumer只与这个Leader进行交互，其他的Replica作为Follower从leader中复制数据（因为需要保证一个Partition中的多个Replica之间的数据一致性，其中一个Replica宕机以后其他的Replica必须要能继续提供服务且不能造成数据重复和数据丢失）。 如果没有leader，所有的Replica都可以同时读写数据，那么就需要保证多个Replica之间互相同步数据，数据一致性和有序性就很难保证，同时也增加了Replication实现的复杂性和出错的概率。在引入leader以后，leader负责数据读写，follower只向leader顺序fetch数据，简单而且高效。

如何将所有的Replica均匀分布到整个集群？
为了更好的做到负载均衡，kafka尽量会把所有的partition均匀分配到整个集群上。如果所有的replica都在同一个broker上，那么一旦broker宕机所有的Replica都无法工作。kafka分配Replica的算法：

  1. 把所有的Broker（n）和待分配的Partition排序
  2. 把第i个partition分配到 （i mod n）个broker上
  3. 把第i个partition的第j个Replica分配到 ( (i+j) mod n) 个broker上
sh kafka-topics.sh --create --zookeeper 192.168.11.140:2181 --replication-factor 3 --partitions 1 --topic six

--replication-factor 表示的副本数
在这里插入图片描述

副本机制

ISR（副本同步队列）,维护的是有资格的follower节点：

  1. 副本的所有节点都必须要和zookeeper保持连接状态
  2. 副本的最后一条消息的offset和leader副本的最后一条消息的offset之间的差值不能超过指定的阀值，这个阀值是可以设置replica.lag.max.messages

如何处理所有的Replica不工作的情况？
在ISR中至少有一个follower时，Kafka可以确保已经commit的数据不丢失，但如果某个Partition的所有Replica都宕机了，就无法保证数据不丢失了：

  1. 等待ISR中的任一个Replica“活”过来，并且选它作为Leader
  2. 选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader

这就需要在可用性和一致性当中作出一个简单的折衷。
如果一定要等待ISR中的Replica“活”过来，那不可用的时间就可能会相对较长。而且如果ISR中的所有Replica都无法“活”过来了，或者数据都丢失了，这个Partition将永远不可用。
选择第一个“活”过来的Replica作为Leader，而这个Replica不是ISR中的Replica，那即使它并不保证已经包含了所有已commit的消息，它也会成为Leader而作为consumer的数据源（前文有说明，所有读写都由Leader完成）。
Kafka0.8.*使用了第二种方式。Kafka支持用户通过配置选择这两种方式中的一种，从而根据不同的使用场景选择高可用性还是强一致性。

HW&LEO

关于follower副本同步的过程中，还有两个关键的概念，HW(HighWatermark)和LEO(Log End Offset). 这两个参数跟ISR集合紧密关联。HW标记了一个特殊的offset，当消费者处理消息的时候，只能拉去到HW之前的消息，HW之后的消息对消费者来说是不可见的。也就是说，取partition对应ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置。每个replica都有HW，leader和follower各自维护更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步更新HW，此时消息才能被consumer消费。这样就保证了如果leader副本损坏，该消息仍然可以从新选举的leader中获取。
LEO 是所有副本都会有的一个offset标记，它指向追加到当前副本的最后一个消息的offset。当生产者向leader副本追加消息的时候，leader副本的LEO标记就会递增；当follower副本成功从leader副本拉去消息并更新到本地的时候，follower副本的LEO就会增加。
在这里插入图片描述

消息确认的几种方式

自动提交

// 是否自动提交消息offset
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
// 自动提交的间隔时间
properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

手动提交
手动异步提交
consumer. commitASync() //手动异步ack
手动同步提交
consumer. commitSync() //手动异步ack

指定消费某个分区的消息

// 指定消费的分区
TopicPartition p0 = new TopicPartition(KafkaProperties.TOPIC, 0);
this.consumer.assign(Arrays.asList(p0));
// 指定分区后无需订阅（指定消费与订阅互斥）
//consumer.subscribe(Collections.singletonList(KafkaProperties.TOPIC));

消息的消费原理

之前Kafka存在的一个非常大的性能隐患就是利用ZK来记录各个Consumer Group的消费进度（offset）。当然JVM Client帮我们自动做了这些事情，但是Consumer需要和ZK频繁交互，而利用ZK Client API对ZK频繁写入是一个低效的操作，并且从水平扩展性上来讲也存在问题。所以ZK抖一抖，集群吞吐量就跟着一起抖，严重的时候简直抖的停不下来。
新版Kafka已推荐将consumer的位移信息保存在Kafka内部的topic中，即__consumer_offsets_topic。通过以下操作来看看__consumer_offsets_topic是怎么存储消费进度的，__consumer_offsets_topic默认有50个分区

  1. 计算consumer group对应的hash值
System.out.println(Math.abs("DemoGroup1".hashCode())%50);
// 15
  1. 获得consumer group的位移信息
    kafka-simple-consumer-shell.sh的查看方式已移除
sh kafka-run-class.sh kafka.tools.DumpLogSegments --files /tmp/kafka-logs/__consumer_offsets-15/00000000000000.log  --print-data-log

kafka 分区分配策略

在 kafka 中每个topic一般都会有很多个partitions。为了提高消息的消费速度，我们可能会启动多个consumer去消费； 同时，kafka存在consumer group的概念，也就是group.id一样的consumer，这些consumer属于一个consumer group，组内的所有消费者协调在一起来消费消费订阅主题的所有分区。当然每一个分区只能由同一个消费组内的consumer来消费，那么同一个consumer group里面的consumer是怎么去分配该消费哪个分区里的数据，这个就设计到了kafka内部分区分配策略（Partition Assignment Strategy）。
在 Kafka 内部存在两种默认的分区分配策略：Range（默认） 和 RoundRobin。通过：partition.assignment.strategy指定。

consumer rebalance

当以下事件发生时，Kafka 将会进行一次分区分配：

  1. 同一个consumer group内新增了消费者
  2. 消费者离开当前所属的consumer group，包括shuts down 或crashes
  3. 订阅的主题新增分区（分区数量发生变化）
  4. 消费者主动取消对某个topic的订阅

也就是说，把分区的所有权从一个消费者移到另外一个消费者上，这个是kafka consumer 的rebalance机制。如何rebalance就涉及到前面说的分区分配策略。

两种分区策略

Range 策略（默认）
0 ，1 ，2 ，3 ，4，5，6，7，8，9
c0 [0 1 2 3]
c1 [4 5 6]
c2 [7 8 9]
10(partition num)/3(consumer num) =3
roundrobin 策略
0 ，1 ，2 ，3 ，4，5，6，7，8，9
c0 [0 3 6 9]
c1 [1 4 7]
c2 [2 5 8]

kafka 的 key 为null， 是随机｛一个Metadata的同步周期内，默认是10分钟｝。
在这里插入图片描述

public class KafkaProducer {

    private final org.apache.kafka.clients.producer.KafkaProducer<Integer, String> producer;


    public KafkaProducer() {
        Properties props = new Properties();
        props.put("bootstrap.servers", KafkaProperties.KAFKA_BROKER_LIST);
        props.put("key.serializer", "org.apache.kafka.common.serialization.IntegerSerializer");
        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("client.id", "producerDemo");
        // 自定义分区策略
		props.put("partitioner.class", "com.spring.kafka.MyPartition");
        this.producer = new org.apache.kafka.clients.producer.KafkaProducer<Integer, String>(props);
    }

    public void senMsg() {
        producer.send(new ProducerRecord<>(KafkaProperties.TOPIC, 1, "message"), new Callback() {
            @Override
            public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                System.out.println("message send to:[" + recordMetadata.partition() + "], offset:[" + recordMetadata.offset() + "]");
            }
        });
    }

    public static void main(String[] args) throws IOException {
        KafkaProducer producer = new KafkaProducer();
        producer.senMsg();
        System.in.read();
    }
}
public class Consumer extends ShutdownableThread {
    private final KafkaConsumer<Integer, String> consumer;

    public Consumer() {
        super("KafkaConsumerTest", false);
        Properties properties = new Properties();
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, KafkaProperties.KAFKA_BROKER_LIST);
        // 消息所属的分组
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "DemoGroup1");
        // 是否自动提交消息offset
        properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
        // 自动提交的间隔时间
        properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
        // 设置最开始的offset偏移量为当前group.id的最早消息
        properties.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        // 设置心跳时间
        properties.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, "30000");
        // 对key和value设置反序列化对象
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.IntegerDeserializer");
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");

        this.consumer = new KafkaConsumer<>(properties);
    }


    @Override
    public void doWork() {
        consumer.subscribe(Collections.singletonList(KafkaProperties.TOPIC));
        ConsumerRecords<Integer, String> records = consumer.poll(1000);
        for (ConsumerRecord record : records) {
            System.out.println("[" + record.partition() + "]receiver message:[" + record.key() + "->" + record.value() + "],offset:" + record.offset());
        }
    }

    public static void main(String[] args) {
        Consumer consumer = new Consumer();
        consumer.start();
    }
}
public class MyPartition implements Partitioner {
    @Override
    public int partition(String s, Object o, byte[] bytes, Object o1, byte[] bytes1, Cluster cluster) {
        List<PartitionInfo> partitions = cluster.partitionsForTopic(s);
        int numPart = partitions.size();
        int hashCode = o.hashCode();
        return Math.abs(hashCode%numPart);
    }
    @Override
    public void close() {}
    @Override
    public void configure(Map<String, ?> map) {}
}
花开不合阳春暮
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Kafka史上最详细原理总结(一)
徐小慧_Blog的博客
08-17 9993
Kafka史上最详细原理总结 一、概念理解（1）产生背景（2）Kafka的特性（3）Kafka场景应用（4）Kafka一些重要设计思想二、消息队列通信的模式（1）点对点模式（2）发布订阅模式三、Kafka的架构原理（1）基础架构与名词解释（2）工作流程分析（1）发送数据（2）保存数据（3）消费数据 一、概念理解 Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大
四十二、Kafka的介绍
象在舞的技术专栏
02-25 5257
Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用：（1）降低系统组网复杂度。（2）降低编程复杂
kafka详解
qq_54247497的博客
06-28 2609
kafka是一款分布式、支持分区的、多副本，基于zookeeper协调的分布式消息系统。最大的特性就是可以实时处理大量数据来满足需求。
kafka简介
sinat_14913533的博客
12-28 3163
kafka的消息模型
搭建一个开源项目14-安装部署Kafka以及下载ruoyi
weixin_44630050的博客
08-29 705
一、安装部署消息队列KAFKA 1.首先准备Zookeeper服务 kafka是依赖于Zookeeper的，所以首先先运行Zookeeper。 先启动依赖，然后把安装包kafka_2.12-2.5.0.taz放到/root目录下，并解压到新建的一个目录中 [root@k8s-master ~]# cd /usr/local/zookeeper/apache-zookeeper-3.6.1-bin/bin/ [root@k8s-master bin]# ./zkServer.sh start [root@
40 1 分布式消息通信Kafka
08-07
教程视频：Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统
开课吧-01分布式消息系统Kafka.pdf
04-24
【分布式消息系统 Kafka】 Kafka 是一款高性能的分布式消息系统，由 Apache 软件基金会开发，主要用于构建实时数据管道和流应用。它的核心特性包括高吞吐量、可扩展性、容错性和持久性。Kafka 使用 Scala 和 Java ...
kafka-分布式消息系统
01-27
总结起来，Kafka是一个强大的分布式消息系统，通过解耦、冗余、并发处理、顺序处理和异步通信等特性，为企业级应用提供高效、可靠的数据交换平台。在设计和部署Kafka时，需要考虑如何合理分配topic、partition和...
基于NS3的分布式消息系统Kafka的仿真实现.pdf
08-10
#资源达人分享计划#
Kafka经典100问
Java搜索工程技术栈
03-18 551
全面介绍Kafka基础理论、用法、基础原理、架构设计以及集群部署方案。
SpringBoot-Pro:若依系统优化
03-07
平台简介 若依是一套全部开源的快速开发平台，毫无保留给个人及企业免费使用。 前端采用Vue，Element UI。 初步采用Spring Boot，Spring Security，Redis＆Jwt。 权限认证使用Jwt，支持多终端认证系统。 支持加载动态权限菜单，多方式轻松权限控制。 高效率开发，使用代码生成器可以一键生成前的代码。 提供了单应用版本 ，Oracle版本 ，保持同步更新。 不分离版本，请移步 ，微服务版本，请移步 特别鸣谢： ， ， 。 阿里云折扣场：，腾讯云秒杀场： 阿里云优惠券： ，腾讯云优惠券： 内置功能 用户管理：用户是系统操作者，该功能主要完成系统用户配置。 部门管理：配置系统组织机构（公司，部门，小组），树结构展现支持数据权限。 职位管理：配置系统用户所属职位。 菜单管理：配置系统菜单，操作权限，按钮权限标识等。 角色管理：角色菜单权限分配，设置角色按机
kafka从入门到精通 以及 kafka 与sparkStreaming的俩种连接方式 kafka 对接flume
weixin_43548518的博客
01-12 1405
前言： spark 官网提供了俩种和kafka的连接方式 第一种： Reciver方式 spark-streaming-kafka-0-8 第二种： 直连方式 spark-streaming-kafka-0-10 3台kafka 1T 吞吐量没问题 直连方式的使用指南 Reciver方式的使用指南 俩种连接方式的对比 ...
大数据篇Kafka消息队列指定Topic打印Key、Value、Offset和Partition
最新发布
u011250186的博客
08-15 1061
大数据篇Kafka消息队列指定Topic打印Key、Value、Offset和Partition
springboot集成Kafka
qq_35705176的博客
12-09 395
Kafka，消费能力不足，消费不及时
【kafka】二、kafka框架介绍（消费者篇）：
lsr40的博客
11-13 1265
本人菜鸡，正在努力学习，记录知识以备后患！ 该文章承接上文（kafka系列），暂有两篇： 【kafka】一、kafka框架介绍（生产者篇）：https://blog.csdn.net/lsr40/article/details/84029034 【kafka】二、kafka框架介绍（消费者篇）：https://blog.csdn.net/lsr40/article/details/84034...
若依集成 WebSocket
热门推荐
萌宅鹿的技术小屋
05-07 1万+
若依集成 WebSocket引入依赖创建 WebSocket 配置类，开启 WebSocket 支持添加 WebSocketServer 类，创建 webSocket 端点创建 controller，用于模拟服务端消息发送添加 websocket.html 由于若依模块划分的很清楚，建议将 WebSocket 配置代码放到 framework 模块中， 将 WebSocket 控制器的代码放到用到的模块中。 引入依赖 在 xxx-framework 下的 pom.xml 中引入 websocket 的依赖：
纯手动搭建大数据集群架构_记录016_微服务架构选型_RuoYi-Cloud-Plus-master_Job如何使用_Es如何使用_Kafka如何使用---大数据之Hadoop3.x工作笔记0177
添柴程序猿的专栏
03-30 282
RuoYi-Cloud-Plus-master 这个是在若依基础上做的增强,里面自带了很多功能,具体就不多说了,来看看怎么下载,部署,跑起来,并且,测试一下,kafka功能,es功能,还有看一下如何,把大数据的hbase集成进去.可以看到右边首先选择,RouYi-Cloud-Plus这个项目,然后选择test,这里然后,点击右上角的,闪电符号,意思是编译的时候,跳过tests。这里选型也是弄了很久,用的微服务架构,刚开始自己捣鼓半天....启动ruoyi-demo这个项目,然后,找到对应的他的配置里的,
Ruoyi若依前后端一体项目整合cas单点登录
weixin_43860634的博客
09-08 4993
若依前后端不分离集成cas单点登录
Kafka之集群架构原理
芋艿V
08-02 121
点击上方“芋道源码”，选择“设为星标”管她前浪，还是后浪？能浪的浪，才是好浪！每天 10:33更新文章，每天掉亿点点头发...源码精品专栏原创 | Java 2021超神之路，很肝~中文详细注释的开源项目RPC 框架 Dubbo 源码解析网络应用框架 Netty 源码解析消息中间件 RocketMQ 源码解析数据库中间件 Sharding-JDBC 和 MyCAT ...
"分布式消息通信：Kafka实现原理1及异步处理场景【解耦提效】
分布式消息通信之Kafka的实现原理1是一个涉及到消息中间件的技术，通过引入分布式队列，可以大大提升程序的处理效率，并且解决各个模块之间的耦合问题。消息中间件主要解决分布式系统之间消息传递的问题，屏蔽各种...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值