Kafka消费者
消费者概述Kafka消费者是Kafka系统中用于读取并处理Kafka主题(topic)中的消息的组件。Kafka的消费者在消费消息时会从特定的主题和分区中读取数据,然后进行处理。
消费模式:由于推模式很难考虑到每个客户端不同的消费速率,导致消费者无法消费消息而宕机,因此kafka采用的是poll的模式,该模式有个缺点,如果服务端没有消息,消费端就会一直空轮询。
为了避免过多不必要的空轮询,kafka做了改进,如果没消息服务端就会暂时保持该请求,在一段时间内有消息再回应给客户端。
工作流程:Kafka消费者订阅主题后,从指定分区拉取消息,处理并提交消费进度(偏移量)以记录已消费的位置,并在消费者组内通过再均衡机制实现负载均衡和故障恢复,确保每个分区的消息仅被一个组内消费者消费。
消费者组(Consumer Group):消费者组是Kafka中用于管理和协调多个消费者共同消费一个或多个主题的机制,通过添加多个消费者的消费组,并行处理数据提高消息消费速度
特点:
唯一的组ID:每个消费者组都有一个唯一的组ID,用于标识这个组。
水平扩展:同一消费者组内的多个消费者可以并行消费同一主 ...
Kafka中Broker节点
BrokerKafka Broker 是 Kafka 集群中的一个节点,负责接收、存储和转发消息。Kafka Broker 是 Kafka 系统的核心组件,负责管理主题、分区和消费者组等关键功能。
节点的服役和退役Broker节点的服役和退役是Kafka集群运维中的重要操作
服役新节点
启动一台新的KafKa服务端(加入原有的Zookeeper集群)
查看原有的 分区信息:kafka-topics.sh --bootstrap-server ip1:9092 --topic test --describe
会发现根本没有新加入的节点
进行分区重新负载均衡操作:
创建一个要负载均衡的主题:vim topics-to-move.json
1234567{ "topics": [ {"topic": "test"} ], "version": 1}
生成负载均衡计划(将新的broker加入,这里只是让我们查看方案):kafka-reassign-partitio ...
Kafka生产者
生产者Kafka 生产者(Producer)是 Apache Kafka 中负责将数据(消息)发送到 Kafka 主题(Topics)的一种客户端。生产者通常运行在数据生成端,能够高效地将大规模数据流传输到 Kafka 中,以供消费者(Consumers)处理和分析。
发送消息流程:
RecordAccumulator: 在jvm的内存中开辟了一块缓存空间,是多个双端队列(方便内存的回收),用于将多条消息合并成一个批次,然后由sender线程发送给kafka集群。
生产者最后还会处理发送结果:生产者处理 Broker 返回的响应。如果消息成功发送,生产者会收到成功确认,结束请求、清理队列。如果发送失败,生产者可以重试或根据配置处理错误。
生产者重要参数总结:
参数名称
描述
bootstrap.servers
生产者连接集群所有的 broker 地址清单。例如 ip1:9092, ip2:9092, ip3:9092,可以设置 1 个或者多个,中间用逗号隔开。注意这里并非需要所有的 broker 地址,因为生产者从给定的 broker 里查找到其他 broker 信息 ...
Guava限流器
Guava限流器概述Guava 是由 Google 开源的一个 Java 工具库,其中包含了很多实用工具类。RateLimiter 是 Guava 提供的一个限流器,用于限制代码的执行速率。它基于令牌桶算法实现,适用于控制请求速率、限制并发等场景
RateLimiter 提供了两种限流模式:
平滑突发限流(SmoothBursty):适用于允许短时间内的突发请求,然后平滑地限制速率
平滑预热限流(SmoothWarmingUp):适用于系统需要一段时间预热后达到稳定速率的场景
具体实现引入依赖
在 Maven 的 pom.xml 文件中引入 Guava 依赖:
12345<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>30.1-jre</version></dependency>
配置限流器
在 Spring Boot 应用中,可以使用 Ra ...
Kafka基础
kafka基础概述Apache Kafka 是一个分布式流处理平台,最初由 LinkedIn 开发,并在 2011 年作为开源项目贡献给 Apache 软件基金会。Kafka 的设计目标是实现高吞吐量、低延迟、可扩展和容错的数据流处理和消息传递功能。
基础架构
主题(Topic)
定义:主题是消息的分类单位,用于组织和管理消息流。
分区(Partition):每个主题可以划分为多个分区。分区是有序的、不可变的消息序列,消息在分区内有唯一的偏移量(Offset)记录消费位置。
为了配合多个分区的概念,提出了消费组的概念进行并行消费;并且一个分区只能由消费组的一个消费者进行消费,这样单个分区的消息就是有序的
生产者(Producer)
功能:生产者是将消息发布到 Kafka 主题的客户端。
工作方式:生产者将消息发送到特定的主题和分区,可以根据某种策略(如轮询、键散列)选择分区。
消费者(Consumer)
功能:消费者是从 Kafka 主题中读取消息的客户端。
消费者组(Consumer Group):消费者可以组成一个组,共同消费一个主题的消息。每个消息只会被消 ...
驱动架构
驱动架构事件驱动架构概述事件驱动架构(Event-Driven Architecture,EDA)是一种软件架构模式,其中系统通过事件的生成、传递和处理来进行通信和工作。事件是系统中发生的动作或变化,可以是用户操作、传感器数据、系统状态改变等。
架构图:
优点:
解耦合:生产者和消费者通过事件代理进行通信,彼此不直接依赖。
扩展性:易于扩展,可以轻松添加新的事件生产者和消费者。
缺点:
复杂性:事件流和处理逻辑较复杂,需要仔细设计和管理。
一致性:处理异步事件时,需要额外考虑数据一致性和幂等性。
事件顺序性:需要额外的机制去保证事件的顺序性。
调试困难:由于系统是异步的,跟踪和调试问题可能更加困难。
组成部分
事件生产者(Event Producers):生成事件的实体,如用户操作、传感器、服务等。
事件代理(Event Brokers):负责接收、存储和分发事件的中间件,如Kafka、RabbitMQ等。
事件消费者(Event Consumers):处理和响应事件的实体,如服务、函数、微服务等。
事件流(Event Streams):事件在系统中流动的路径。
工作机制 ...
基因法分表
基因法分表概述随着数据量的迅速增长,单表存储和查询的效率问题愈加突出。传统的数据库在面对海量数据时,容易出现性能瓶颈和存储压力。为了解决这一问题,分表策略被广泛应用。基因法作为一种数据分表策略,通过将大表按照一定规则拆分成多个小表,从而提高查询效率和系统性能。
基因法的核心思想是根据数据的某些属性(如用户ID、时间戳等)进行哈希计算或者其他分配算法,将数据分布到不同的子表中。这种方法不仅能够有效平衡各个子表的数据量,还能提高查询的并发性能。
实现思路案例:例如对账户相关表(user、account、account_detail)按照user_id分库分表
执行user表的insert语句会被DAL数据代理(于ShardingProxy类似)所拦截
DAL会拉取数据库信息以及映射关系
再对user_id进行哈希算法进行分片,例如上图的66,DAL将其放在DB1中
计算出user_id的hash值,并返回
这样对于一套需要放一个库的表,主键id都在结尾加上这个hash值,之后就会很方便的路由到一个库
查询的时候,无论带上哪个表的主键都会顺利路由到一个库
好处:
方便一套业务表能够方 ...
跨库分页
跨库分页概述跨库分页是一种在分布式数据库系统中常见的技术挑战。在使用 ShardingJDBC 或其他数据分片技术时,数据通常会被分散到多个数据库实例或表中。跨库分页需要在这些分片中进行数据的合并和排序,以便返回一个统一的分页结果集。
跨库分页的挑战
数据分布不均匀:由于数据分布在多个分片中,直接进行分页查询可能会导致部分分片返回过多或过少数据,影响整体分页结果的准确性。
排序和合并:各个分片返回的数据需要进行全局排序和合并,以确保分页结果的正确性。这涉及到跨库的数据传输和合并计算。
性能问题:跨库分页通常会涉及多个数据库实例的查询操作,可能会导致性能瓶颈,尤其是在数据量较大或网络延迟较高的情况下。
解决方案全局视野法这种方法主要是通过构建全局视野法模拟单库操作的方法解决跨库分页
操作步骤:
在每个分片上执行相同的分页查询,并将结果集返回到应用层。
应用层将各个分片的结果集进行全局排序和合并,然后再进行分页处理。
案例:
将order by time offset X limit Y,改写成order by time offset 0 limit X+Y
服务层将改写后的SQL ...
ShardingJDBC分片策略
ShardingJDBC分片策略概述ShardingJDBC 提供了多种分片策略,以适应不同的应用场景。这些策略通过将数据分布到多个数据库实例或表中,提高系统的性能和可扩展性。分片策略的选择对系统的查询性能、数据均衡性以及扩展性有重要影响。常见的分片策略包括范围分片、哈希分片、列值分片、连续分片、复合分片、广播表分片和异构分片。
分片策略详解自动分片算法这种算法会根据相应配置以及选择的不同算法,自动进行分片
取模分片算法(MOD):取模分片算法通过对分片键进行取模运算来决定分片位置,适用于数据量大且均匀分布的场景
12345678sharding-algorithms: # 分片算法名 my_mod_algorithms: #类型 type: MOD # 算法配置 props: sharding-count: 2
哈希取模分片算法(HASH_MOD):哈希取模分片算法通过对分片键进行哈希运算后再取模来决定分片位置,进一步均匀数据分布。
12345678sharding-algorithms: # 分片算法名 my_hashmod_algori ...
ShardingJDBC
ShardingJDBC概述ShardingJDBC是一个开源的基于 Java 的分库分表中间件,用于处理关系型数据库的分片操作(供了水平分片和垂直分片两种分片方式)。它可以将数据按照某种规则分散存储在不同的数据库中,从而有效地解决了单一数据库在处理大量数据时的性能瓶颈问题。
ShardingJDBC定位为轻量级 Java 框架,在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库,以 jar 包形式提供服务,无需额外部署和依赖,可理解为增强版的 JDBC 驱动,完全兼容 JDBC 和各种 ORM 框架。
适用于任何基于 JDBC 的 ORM 框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC;
支持任何第三方的数据库连接池,如:DBCP, C3P0, BoneCP, HikariCP 等;
支持任意实现 JDBC 规范的数据库,目前支持 MySQL,PostgreSQL,Oracle,SQLServer 以及任何可使用 JDBC 访问的数据库。
ShardingJDBC是以SDK的方式集 ...