并发框架Disruptor译文

并发框架Disruptor译文

(感谢同事方腾飞投递本文)

Martin Fowler在自己网站上写了一篇LMAX架构的文章,在文章中他介绍了LMAX是一种新型零售金融交易平台,它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上,其核心是一个业务逻辑处理器,它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中,使用事件源驱动方式。业务逻辑处理器的核心是Disruptor。

Disruptor它是一个开源的并发框架,并获得2011 Duke’s 程序框架创新奖,能够在无锁的情况下实现网络的Queue并发操作。本文是Disruptor官网中发布的文章的译文(现在被移到了GitHub)。

剖析Disruptor:为什么会这么快

Disruptor如何工作和使用

Disruptor的应用

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——


本广告收入已由广告主捐给Wikipedia

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.48 )
Loading...

并发框架Disruptor译文》的相关评论

  1. 内存运算每秒600万次这不算啥。关键Java是IO,不论用同步IO,NIO,还是NIO.2,哪怕一次只读写1字节,每秒都只能处理十万次请求这个数量级。

  2. 我想了一下,我觉得每秒600万次请求的网络服务还是有可能的,但要求请求很小,多个请求合并在一个IP包中,就可以减少IO次数了。

    如果用于网络游戏的话,这种服务器只能是后台的逻辑服务器,不能直接面对客户端连接。

  3. 看了一下,这个框架之所以高性能主要是因为能有效的解锁,避免了伪共享,我很好奇一点,他是如何针对具体的处理器而变化的呢?是使用在所有架构的处理器上么?

  4. 大概看了一下,可以理解为两个东西
    1. 在线程级别的Actor并发,姑且不论好有无必要;并发实体从Process简化为Thread又从Thread变成Actor。。难道说并发实体真的是越小越好?这不科学吧。
    2. 无锁的生产消费队列,没啥好说的,到处是这些东西。这个framework似乎用它来做消息的承载。

  5. 【这个系统是建立在JVM平台上,其核心是一个业务逻辑处理器,它能够在一个线程里每秒处理6百万订单】
    什么配置的硬件平台?1笔订单需要做哪些事情?

    这个机制很复杂吗?需要一个框架来实现?
    如真的有效,应该有c或c++的实现例子吧?操作系统会把它利用起来(彻底抛弃锁)吗?

  6. 该代码在4×4核Xeon E7520 1.87G上测试,16线程加padding和不加padding性能差别是2.9倍左右,远没有图示数据那么夸张;另外用C/C++写的测试代码也是类似结果(差距更小一些),详见 http://www.felix021.com/blog/read.php?2106 。我怀疑是共享的L2/L3 Cache导致Cache Line失效的开销显著降低了。

  7. 大概看了一遍
    有个问题不是很理解
    多个线程读取 Ringbuffer 的话怎么保证线程读取到的不是重复的数据
    按我以前的做法,是维护一个读索引,做原子自增操作
    但是文章上说Ringbuffer只维护一个写索引。。。
    望指教

  8. 有个疑问呢,希望大家能够帮忙解决一下,文章说的是在cpu是多核情况下的伪共享会有优化,如果是单核的呢,会不会在伪共享的优化上边就没有意义了?

发表评论

电子邮件地址不会被公开。 必填项已用*标注