Disruptor本地线程队列--是什么决定了批量数据的多少_什么决定了endofBatch是true还是false---线程间通信工作笔记006

已于 2022-09-03 10:09:59 修改
阅读量1k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 离&实时计算&大数据 文章标签： java disruptor 环形队列 环形队列分批保存
于 2022-09-03 10:01:36 首次发布
本文为博主原创文章，未经博主 添柴程序猿 允许不得转载 违者追究法律责任。
本文链接：https://blog.youkuaiyun.com/lidew521/article/details/126673948
本文探讨了在使用Disruptor时，如何确保数据按固定数量或时间间隔保存。当数据每100条到达时，原本期望endofBatch为true触发保存，但实际中可能因发布间隔过短导致endofBatch一直是false，从而出现200条才保存一次的情况。通过在publish数据时增加至少300毫秒的延迟，可以确保endofBatch正确切换，避免这个问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

     由于我们要做一个功能,因为数据的获取,并不是匀速的,而是不定的,数据会不停的,非匀速的,

 

类似无界流,不停的过来数据,我们需要让数据在队列中,每个一个固定的时间,或者固定的数量,来保存一次,而每次保存会根据endofbatch,disruptor的endofbatch来进行保存一次,当endofbatch是true的时候就需要进行一次,数据的保存,生成一个数据文件.

    那么虽然是数据每隔一段时间过来的,或者是每隔固定数量的数据过来的,这里,出现了一个问题,

就是如果数据是每隔一定固定数量过来的,那么出现了问题,如果比如数据是每100条就会存一次,也就是,如果数据:dataIndex - ringbuffer.getCursor,这个游标是100了,大于等于100了,就进行,publish.

ringBuffer.publish(ringBuffer.getCursor,dataIndex).发布一次数据,数据消费端就会立刻进行数据保存,但是如果数据,每隔100,每隔100,来的数据太快了,那么就会出现,一个文件,保存了200条数据的情况,也就是,本来每隔100,过来100条的,也就是每隔100,endofbatch就是true一次,但是虽然每隔100进行发布一次数据,但现在出现了,200条才endofbatch才是true一次.这是什么原因呢?

      是什么决定了endofbatch的,true还是false,经过多次测试,知道,就是发布数据publish数据的,间隔,如果时间间隔太近,比如小于300毫秒,那么可能这个过程,虽然是分了两次publish的数据,

了解本专栏 订阅专栏 解锁全文 超级会员免费看
Disruptor本地线程队列_WorkProcessor异常_FatalExceptionHandler---线程间通信工作笔记004
添柴程序猿的专栏
06-21 570
在使用disruptor的过程中,disruptor队列偶尔发现会报错,就是报的:_FatalExceptionHandler这种错误,其实:在disruptor中,它把异常给封装了:可以去看源码,我们知道在disruptor中工作线程是com.lmax.disruptor.WorkProcessor#run 在这个方法中,可以看到有个try ,catch,可以看到捕获到异常以后,这里用exceptionHandler.handleEventException这里处理的,而:handleEventExcep
xxljob从入门到精通-全网段最全解说
热门推荐
打造全国最全的AI Agent开发知识领域的博客
06-05 1万+
XXL-JOB特性一览 基本概念 xxljob解决的是以下几个痛点： 1） 跑批处理监控无法可视化，当前跑批的状态是：成功？失败？挂起？进度？为什么失败/原因？ 2）批处理任务不可重用，特别是无法对批处理任务做：定时？重复使用？频次？其中路由调度？ 3）批处理任务无法做到网格计算（特别像：websphere ibm grid computing）即批处理任务本身可以做成集群、fail over、sharding 由其是批处理任务可以做成“网格计算”这个功能，有了xxljob后你会发觉特别强大
41 - 案例分析（三）：高性能队列Disruptor
pizicai007的博客
07-19 607
案例分析（三）：高性能队列Disruptor1. RingBuffer 如何提升性能2. 如何避免“伪共享”3. Disruptor 中的无锁算法4. 总结   我们在《24 - 并发容器》介绍过 Java SDK 提供了 2 个有界队列：ArrayBlockingQueue 和 LinkedBlockingQueue，它们都是基于 ReentrantLock 实现的，在高并发场景下，锁的效率并不高，那有没有更好的替代品呢？有，今天我们就介绍一种性能更高的有界队列：Disruptor。      Disru
利用 disruptor DB批量存储
土豆哼小调
01-02 2044
public class AplusMonitorDataRing { private final static Logger logger = LoggerFactory.getLogger(AplusMonitorDataRing.class); private static Executor executor = Executors.newSingleThreadExecutor
java disrupter_java – LMAX Disruptor – 什么决定批量大小？
weixin_36221980的博客
03-04 600
我最近一直在学习LMAX Disruptor并且正在做一些实验.令我困惑的一件事是EventHandler的onEvent处理程序方法的endOfBatch参数.请考虑以下代码.首先,我称为Test1和Test1Worker的虚拟消息和消费者类：public class Test1 {}public class Test1Worker implements EventHandler{public ...
在DWR中beginBatch()和endBatch()的含义
学习 进步
11-19 254
function addBook(){ var book = {name:null,isbm:null,author:null}; dwr.util.getValues(book); dwr.engine.beginBatch(); BookManageService.addBook(...
Disruptor系列（二）— disruptor使用
weixin_34292287的博客
01-25 629
本文译自Dirsruptor在github上的wiki中文章：Getting Started 获取Disruptor Disruptor jar包可以从maven仓库mvnrepository获取，可以将其集成进项目的依赖管理中。 <dependency> <groupId>com.lmax</groupId> <artifactId>d...
十五、寻龙队列术——Disruptor+Redis 队列
流楚丶格念的博客
08-30 2558
Disruptor 是 LMAX 开源的高性能异步处理框架，提供了高性能的无锁内存队列实现，并优化了 CPU 伪共享，旨在构建低延迟、高吞吐量的交易型应用。Disruptor 可以用于构建复杂的任务工作流，下面是一个消费者工作流的示意图：在实际项目中，我们将 Disruptor 与 Redis 结合，用于异步处理任务。整体架构如下图所示：Redis 队列：我们使用 Redis List 数据结构来存储任务，并分为等待队列、本地处理队列、失败队列、备份队列。
bootstrap框架怎么用_java并发编程实战笔记：高性能队列Disruptor框架到底怎么用
weixin_39611863的博客
11-14 239
Disruptor 是一款高性能的有界内存队列，目前应用非常广泛，Log4j2、SpringMessaging、HBase、Storm 都用到了 Disruptor，那 Disruptor 的性能为什么这么高呢？Disruptor 项目团队曾经写过一篇论文，详细解释了其原因，可以总结为如下：内存分配更加合理，使用 RingBuffer 数据结构，数组元素在初始化时一次性全部创建，提升缓存命中率；对...
并发框架Disruptor浅析
weixin_30241919的博客
10-02 631
1、引言 　　Disruptor是一个开源的Java框架，它被设计用于在生产者—消费者（producer-consumer problem，简称PCP）问题上获得尽量高的吞吐量（TPS）和尽量低的延迟。Disruptor是LMAX在线交易平台的关键组成部分，LMAX平台使用该框架对订单处理速度能达到600万TPS，除金融领域之外，其他一般的应用中都可以用到Disruptor，它可以带来显著的性能...
disruptor 多个消费者
04-05
disruptor 多个消费者 但是只消费一次 有时候会有这样的需求
深入浅出Disruptor的使用和原理
景川的博客
04-28 2162
1. Disruptor简介 Disruptor git地址：https://github.com/LMAX-Exchange/disruptor Disruptor定义：线程间的高性能消息框架 Disruptor核心思想：把多线程并发写的线程安全问题转化为线程本地写，即：不需要做同步 2. Disruptor优点 Disruptor非常轻量，整个框架最新版3.4.2也才70多个类，但性能却...
Disruptor --优雅的使用
Fanxil的博客
04-27 1037
Disruptor是一个高性能的消息框架，其核心是基于环形缓冲区实现的。Disruptor的设计目标是尽可能地减少线程之间的竞争和同步，从而提高系统的吞吐量和响应速度。下面让我来介绍一下在使用Disruptor中如何优雅地使用环形队列。首先，需要明确的是，Disruptor中的环形队列与普通的环形队列有所不同。Disruptor的环形队列并不是用于存储数据，而是用于协调读写操作的顺序。
disruptor使用示例
wh0426的专栏
05-15 3485
LMAX 开源了一个高性能并发编程框架。可以理解为消费者-生产者的消息发布订阅模式。本文下载了官方示例代码，进行实验。 longEvent事件数据 public class LongEvent { private long value; public void set(long value) { this.value = value; }
Disruptor官方文档实现
持之以恒！
06-09 7111
获得Disruptor Disruptor是什么，我就不废话了，本文是对官方文档的实现，直接进入主题，要使用Disruptor可以通过Maven或者下载jar来安装Disruptor，只要把对应的jar放在Java classpath就可以了。 1.定义事件 首先声明一个Event来包含需要传递的数据 public class LongEvent { private long valu
Disruptor学习笔记：基本使用、核心概念和原理
hxt的博客
09-20 1872
Disruptor是英国外汇交易公司LMAX开发的一个高性能队列（系统内部的内存队列），研发的初衷是解决内存队列的延迟问题（在性能测试中发现竟然与I/O操作处于同样的数量级）。基于Disruptor开发的系统单线程能支撑每秒600万订单，2010年在QCon演讲后，获得了业界关注。2011年，企业应用软件专家Martin Fowler专门撰写长文介绍。同年它还获得了Oracle官方的Duke大奖 1、快速入门 1）、步骤 创建一个工厂Event类，用于创建Event类实例对象 需要有一个监听事件类，用于处
无锁队列Disruptor使用笔记
yuanshenqiang的博客
10-19 885
由于Disruptor原版是java开发的，而本人是从事C/C++开发工作的，期望找一个C/C++版本的实现，用到自己的工作中。Disruptor不对生产者和消费者的数量做限制，可以是单生产者->单消费者，单生产者->多消费者，多生产者->单消费者，以及多生产者->多消费者(这里的每个生产者和消费者都指的是一个线程，而不是某个抽象业务的类实例)。在竞争消费模式下，每条消息的真正被消费的时机是不确定的，有可能先入队的消息后被消费，因此可以看到打印顺序是乱的，这也是这种消费模式的重要特性。
Disruptor的使用以及原理
qq_39939541的博客
07-07 4118
Disruptor是一种高性能的并发框架，用于解决在高并发场景下的数据交换和协调问题。通过无锁的环形缓冲区和批量处理的方式，实现了更高的吞吐量和更低的延迟。它适用于需要处理大量并发事件的场景，如高频交易系统、消息队列等。
锁是什么，什么对象锁，乐观锁，悲观锁
最新发布
02-28
<think>好的，用户问的是关于锁的概念，特别是对象锁、乐观锁和悲观锁。首先，我需要确定用户的基本背景。可能是一个刚开始学习并发编程或者数据库的开发者，或者是在面试准备中遇到了相关问题。用户可能对锁的基本概念有一定了解，但想深入理解不同类型的锁以及它们的应用场景。 接下来，我得理清楚各个锁的定义和区别。对象锁通常是在面向对象编程中，比如Java中的synchronized关键字，用来控制对对象实例的访问。而乐观锁和悲观锁是更广泛的概念，常用于数据库和并发控制。需要解释清楚它们的区别：乐观锁假设冲突少，通过版本号或时间戳实现；悲观锁假设冲突多，先加锁再操作。 用户可能存在的疑问点包括：为什么需要这么多类型的锁？各自的应用场景是什么？比如在高并发环境下，悲观锁可能导致性能问题，而乐观锁可能在冲突频繁时导致重试次数过多。这时候需要举例说明，比如数据库的更新操作，或者购物网站的库存扣减。 还要注意区分不同语境下的锁，比如对象锁是编程语言层面的，而乐观锁和悲观锁更多是设计思想，可以在数据库或应用层实现。可能用户混淆了这些概念，需要明确它们的应用层次。 另外，用户可能想知道如何选择使用哪种锁。这时候需要给出实际建议，比如冲突频率、系统性能要求等。同时，结合现实中的例子，比如版本控制中的冲突解决，或者电商系统中的库存管理，帮助用户更好地理解。 最后，检查是否有常见的误区需要提醒，比如乐观锁并不是真正的锁，而是一种无锁机制，或者悲观锁可能导致的死锁问题。确保回答准确且易于理解，避免技术术语过多，必要时用比喻或类比来解释复杂概念。</think>### 🔒 锁机制深度解析（附代码示例） #### 🌟 核心概念 **锁的本质**：协调多线程/多进程访问共享资源的同步机制，如同会议室使用登记表，防止多人同时修改重要文件 #### 1️⃣ 对象锁（Monitor Lock） ```java // Java示例（synchronized实现） public class BankAccount { private int balance = 1000; // 对象锁保护取款操作 public synchronized void withdraw(int amount) { if (this.balance >= amount) { this.balance -= amount; } } } ``` - **特点**：粒度最细的互斥锁（每个对象独立） - **内存语义**：加锁时清空工作内存，解锁时同步主内存（保证可见性） - **锁升级**：无竞争时偏向锁 -> 轻度竞争时自旋锁 -> 重度竞争时重量级锁 #### 2️⃣ 悲观锁 vs 乐观锁 **对比维度**： | | 悲观锁 | 乐观锁 | |------------------|-------------------------------|-------------------------------| | 适用场景 | 高冲突率环境 | 低冲突率环境 | | 实现方式 | 行锁、表锁、读写锁 | 版本号、CAS机制 | | 数据读取 | 加锁后才允许读取 | 直接读取，提交时校验 | | 典型应用 | 银行转账、库存扣减 | 点赞计数、文章浏览数更新 | | 失败处理 | 线程阻塞等待 | 回滚重试（需业务层处理） | **数据库实现对比**： ```sql -- 悲观锁实现（SELECT FOR UPDATE） BEGIN; SELECT * FROM products WHERE id=1 FOR UPDATE; UPDATE products SET stock=stock-1 WHERE id=1; COMMIT; -- 乐观锁实现（版本号控制） UPDATE products SET stock=stock-1, version=version+1 WHERE id=1 AND version=5; -- 返回受影响行数判断是否成功 ``` #### 3️⃣ CAS原理（乐观锁基石） ```cpp // C++原子操作示例（CPU指令级实现） bool compare_and_swap(int *addr, int expected, int new_value) { if (*addr == expected) { *addr = new_value; return true; } return false; } ``` - **ABA问题解决方案**：添加版本戳（Java的AtomicStampedReference） - **CPU支持**：x86的CMPXCHG指令（单条指令实现原子操作） - **适用场景**：简单原子操作（计数器等），复杂逻辑需结合重试机制 #### 4️⃣ 锁的代价与规避方案 **性能损耗三要素**： 1. **上下文切换**：线程阻塞/唤醒消耗（约1-2μs） 2. **内存同步**：缓存失效导致的性能下降 3. **竞争加剧**：等待线程越多，整体吞吐量越低 **优化策略**： - 减小锁粒度（ConcurrentHashMap的分段锁） - 读写分离（ReentrantReadWriteLock） - 无锁数据结构（Disruptor环形队列） - 线程本地存储（ThreadLocal） - 协程轻量级锁（Go语言的goroutine） #### 5️⃣ 分布式锁实现 **Redis分布式锁示例**： ```lua -- Lua脚本保证原子性 local key = KEYS[1] local reqId = ARGV[1] local ttl = tonumber(ARGV[2]) if redis.call('exists', key) == 0 then redis.call('hset', key, 'lock', reqId) redis.call('pexpire', key, ttl) return 1 end return 0 ``` **关键要求**： - 互斥性（唯一客户端持有） - 防死锁（自动过期机制） - 容错性（Redis集群故障转移时仍有效） - 可重入性（支持同一客户端多次加锁） #### 🛠 实战选择指南 1. **优先考虑无锁设计**（如Actor模型、事件溯源） 2. **读多写少用乐观锁**（评论系统、配置信息） 3. **写多读少用悲观锁**（支付系统、库存管理） 4. **分布式场景用Redis/Zookeeper**（保证最终一致性） #### ⚠️ 典型死锁案例 ```java // 交叉锁死锁示例 Thread1: 先锁A，再请求锁B Thread2: 先锁B，再请求锁A // 解决方案： // 1. 统一加锁顺序 // 2. 使用tryLock()带超时机制 // 3. 死锁检测（JStack工具分析） ``` #### 📊 性能测试数据（4核CPU） | 场景 | QPS | 平均延迟 | 适用场景 | |--------------------|--------|---------|------------------| | 无锁 | 120万 | 0.8ms | 只读操作 | | 乐观锁（CAS） | 85万 | 1.2ms | 低冲突写操作 | | 轻量级锁 | 45万 | 2.3ms | 中等并发 | | 重量级锁 | 12万 | 8.5ms | 高冲突关键操作 | #### 🧠 知识延伸 1. **锁消除**：JIT编译器对不可能存在共享资源竞争的锁进行消除 2. **锁粗化**：将多个连续锁操作合并为单个锁操作 3. **自旋锁**：短暂循环尝试获取锁（避免线程切换） 4. **偏向锁**：消除无竞争情况下的同步开销 选择锁策略时，需结合具体业务场景通过压力测试验证，没有绝对最优方案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

添柴程序猿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值