前言 秒杀架构持续优化中,基于自身认知不足之处在所难免,也请大家指正,共同进步.文章标题来自码友 简介 LMAX Disruptor是一个高性能的线程间消息库.它源于LMAX对并发性,性能和非阻塞算法的研究,如今构成了Exchange基础架构的核心部分. Disruptor它是一个开源的并发框架,并获得2011 Duke's 程序框架创新奖,能够在无锁的情况下实现网络的Queue并发操作. Disruptor是一个高性能的异步处理框架,或者可以认为是最快的消息框架(轻量的JMS),也可以认为是一

1.引言 Disruptor是一个开源的Java框架,它被设计用于在生产者—消费者(producer-consumer problem,简称PCP)问题上获得尽量高的吞吐量(TPS)和尽量低的延迟.Disruptor是LMAX在线交易平台的关键组成部分,LMAX平台使用该框架对订单处理速度能达到600万TPS,除金融领域之外,其他一般的应用中都可以用到Disruptor,它可以带来显著的性能提升.其实Disruptor与其说是一个框架,不如说是一种设计思路,这个设计思路对于存在“并发.缓冲区.生

原文地址:http://coderbee.net/index.php/open-source/20130812/400 一.Disruptor 是什么? Disruptor 是一个高性能异步处理框架,也可以认为是一个消息框架,它实现了观察者模式. Disruptor 比传统的基于锁的消息框架的优势在于:它是无锁的.CPU友好:它不会清除缓存中的数据,只会覆盖,降低了垃圾回收机制启动的频率. 这个解读是在最新版 3.1.1 的源码上进行. 关于Disruptor的更多介绍可见: http://if

Martin Fowler在自己网站上写了一篇LMAX架构的文章,在文章中他介绍了LMAX是一种新型零售金融交易平台,它能够以很低的延迟产生大量交易.这个系统是建立在JVM平台上,其核心是一个业务逻辑处理器,它能够在一个线程里每秒处理6百万订单.业务逻辑处理器完全是运行在内存中,使用事件源驱动方式.业务逻辑处理器的核心是Disruptor. Disruptor它是一个开源的并发框架,并获得2011 Duke’s程序框架创新奖,能够在无锁的情况下实现网络的Queue并发操作.本文是Disrupto

一.Disruptor基本原理 在多线程开发中,我们常常遇到这样一种场景:一些线程接受用户请求,另外一些线程处理这些请求.比如日志处理中的日志输入和告警.这种典型的生产者消费者场景十分常见,而生产者消费者模式的核心就是阻塞队列.由于阻塞队列会涉及大量的锁竞争和线程阻塞,都是非常耗费CPU的操作,因此阻塞队列的性能好坏能够在很大程度上决定上层应用的性能瓶颈. JAVA中用BlockingQueue这个接口来描述阻塞队列,有数组实现的有界阻塞队列为 ArrayBlockingQueue,用链表实现的

..................2015年的第一天................... 本文代码托管在 https://github.com/hupengcool/disruptor-starter Intruduction 关于吹牛逼的话就不说了...Disruptor是Java实现的用于线程间通信的消息组件.其核心是一个Lock-free的Ringbuffer,Disruptor使用CAS而不是Lock.与大部分并发队列使用的Lock相比,CAS显然要快很多.CAS是CPU级别的指令,

http://mechanitis.blogspot.com/search/label/disruptor http://ifeve.com/disruptor/, 并发框架Disruptor译文 http://blog.sina.com.cn/s/blog_68ffc7a4010150yl.html, 论文译文   LMAX需要搭建high performance的交易平台, 所以需要基于并发编程模型 (并发编程模型和访问控制) 当然他们也关注类似Actor或SEDA模型, 并进行了测试, 从

系列译文: http://ifeve.com/disruptor/ 当有多个消费者时,(按Disruptor的设计)每个消费者各自控制自己的指针,依次读取每个Slot(也就是每个消费者都会读取到所有的产品),这时只需要保证生产者指针不会超过最慢的消费者(超过最后一个消费者“一圈”)即可,也不需要锁. 重复消费http://blog.csdn.net/zero__007/article/details/49684363 Disruptor多个消费者不重复处理生产者发送的消息的demo Disrup

原文地址:http://www.cnblogs.com/qiaoyihang/p/6479994.html disruptor适用于大规模低延迟的并发场景.可用于读写操作分离.数据缓存,速度匹配(因为其实现了生产者-消费者模型).或者是基于内存的事件流处理机制的场景. disruptor的主要设计思想是无锁的高并发,特别适用于对时间高度敏感的多线程应用.如果app对时间不敏感完全可以不用disruptor 而只用array blocking queue,在设计上采用内存屏障的机制和CAS操作实现

前提概要 简单回顾 jdk 里的队列: 阻塞队列: ArrayBlockingQueue主要通过:数组(Object[])+ 计数器(count)+ ReetrantLock的Condition (notEmpty:非空.notFull:非饱和)进行阻塞. 入队操作: 操作不阻塞: add:添加失败,则会直接进行返回. offer:添加失败后(满了)直接抛出异常,注意:offer(E o, long timeout, TimeUnit unit):可以设定等待的时间,如果在指定的时间内,还不能往

并发理论 JMM 概述 Java Memory Model缩写为JMM,直译为Java内存模型,定义了一套在多线程读写共享数据时(成员变量.数组)时,对数据的可见性.有序性和原子性的规则和保障:JMM用来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各平台下都能够达到一致的内存访问效果. JMM是一种规范,目的是解决由于多线程通过共享内存进行通信时,存在的本地内存数据不一致.编译器对代码指令重排序.处理器对代码乱序执行.CPU切换线程等带来的问题. 并发与并行 并发:指的是多个事

atitit.细节决定成败的适合情形与缺点 1. 在理论界有两种观点:一种是"细节决定成败",另一种是"战略决定成败".1 1.1. 格局决定成败,方向决定成败 战略决定成败"1 1.2.   战略用的是望远镜,细节用的是显微镜.1 2. 只有战略正确,细节才会有意义.2 2.1. 只见树木,不见森林2 2.2. 对于一艘驶错了方向的航船来说,任何来风都是逆风,2 2.3. 南辕北辙的故事2 2.4. 大失误是战略,小失误是细节,战略错了回天无力,细节错了

一.概述 disruptor对于处理并发任务很擅长,曾有人测过,一个线程里1s内可以处理六百万个订单,性能相当感人. 这个框架的结构大概是:数据生产端 --> 缓存 --> 消费端 缓存中的数据是主动发给消费端的,而不是像一般的生产者消费者模式那样,消费端去缓存中取数据. 可以将disruptor理解为,基于事件驱动的高效队列.轻量级的JMS disruptor学习网站:http://ifeve.com/disruptor-getting-started 二.开发流程 1.建Event类(数据

ajax的优点 Ajax的给我们带来的好处大家基本上都深有体会,在这里我只简单的讲几点: 1.最大的一点是页面无刷新,在页面内与服务器通信,给用户的体验非常好. 2.使用异步方式与服务器通信,不需要打断用户的操作,具有更加迅速的响应能力. 3.可以把以前一些服务器负担的工作转嫁到客户端,利用客户端闲置的能力来处理,减轻服务器和带宽的负担,节约空间和宽带租用成本.并且减轻服务器的负担,ajax的原则是"按需取数据",可以最大程度的减少冗余请求,和响应对服务器造成的负担. 4.基于标准化的

PNG32的alpha透明效果在IE6下会出现bug,出现灰色背景.而目前的解决方案就是 IE提供的滤镜.需要注意的是滤镜并不是对原图片进行修改,而是对相应的html元素进行 修改.所以在一个html中的多处使用alpha滤镜,那么性能的损耗将会累加. 现总结使用滤镜的缺点: 1,IE6下使用滤镜,那么无法对该PNG图片进行定位.可以通过其他解决方案完成.这篇 文章提到了两种解决方案,分别是硬编码和clip方案. 2,使用滤镜会冻结IE6的渐进渲染.渲染往往是从css下载完毕开始进行,然而对于使

解决的问题 当我们有多个消息的生产者线程,一个消费者线程时,他们之间如何进行高并发.线程安全的协调? 很简单,用一个队列. 当我们有多个消息的生产者线程,多个消费者线程,并且每一条消息需要被所有的消费者都消费一次(这就不是一般队列,只消费一次的语义了),该怎么做? 这时仍然需要一个队列.但是: 1. 每个消费者需要自己维护一个指针,知道自己消费了队列中多少数据.这样同一条消息,可以被多个人独立消费. 2. 队列需要一个全局指针,指向最后一条被所有生产者加入的消息.消费者在消费数据时,不能消费到这

注解与XML配置的区别 注解:是一种分散式的元数据,与源代码耦合. xml :是一种集中式的元数据,与源代码解耦. 因此注解和XML的选择上可以从两个角度来看:分散还是集中,源代码耦合/解耦. 注解的缺点: 1.很多朋友比如在使用spring注解时,会发现注解分散到很多类中,不好管理和维护: 2.注解的开启/关闭必须修改源代码,因为注解是源代码绑定的,如果要修改,需要改源码,有这个问题,所以如果是这种情况,还是使用XML配置方式:比如数据源: 3.注解还一个缺点就是灵活性,比如在之前翻译的Spr

本文为原创,转载请注明:http://www.cnblogs.com/gistao/ epoll提供了ET和LT两种模式,网上文章很多,这里只总结下LT模式下的两个缺点 epoll对fd的管理实现是用的红黑树,所以epoll_ctl并不是一个很快的操作,而LT模式更放大了这个缺点. 有一个关于内存屏障(Memory barrier)的patch:prevent missed events on EPOLL_CTL_MOD,可能很多内核都没有打上这个补丁.

已经不记得最早接触到 Disruptor 是什么时候了,只记得发现它的时候它是以具有闪电般的速度被介绍的.于是在脑子里, Disruptor 和"闪电"一词关联了起来,然而却一直没有时间去探究一下. 最近正在进行一项对性能有很高要求的产品项目的研究,自然想起了闪电般的 Disruptor ,这必有它的用武之地,于是进行了一番探查,将成果和体会记录在案. 一.什么是 Disruptor  从功能上来看,Disruptor 是实现了"队列"的功能,而且是一个有界队列.那

不论是从官方手册,还是各种第三方教程,几乎涉及到的,都是讲如何使用U3D,以及U3D的优点. 虽然我是用的一个让步语气,但请不要否认U3D的这些优点,它们的确存在. 但对于一个引擎的特性来说,优点与缺点总是共存的. 你可以从网上了解到所有优点,但是,你很难真正体会到U3D的缺点,除非你自己被坑过. 今天,我就来细数一下U3D的缺点. 这些缺点,仅针对大中型项目. 小型项目,U3D的优点可以充分利用. 是不是猛的一看,全是缺点. 不要怕,想看优点的朋友,走这里  Unity3D使用经验总结 优点篇