通过Axon和Disruptor处理1M tps

原文地址:http://blog.trifork.nl/2011/07/20/processing-1m-tps-with-axon-framework-and-the-disruptor/

作者:   译者:程晓明

LMAX,一家在英国的金融公司,最近开源了其(新型零售金融交易平台的)核心组件之一:Disruptor。这个组件通过删除必须的锁来降低执行开销,且任然保证正确的处理订单。如果你问我,我会说这是一个优美精巧的工程。我尝试把Disruptor应用到Axon控制总线中,就是想看看它到底有多大的潜力。结果相当惊人。

Read more

CPU Cache Flushing Fallacy

原文地址:http://mechanical-sympathy.blogspot.com/2013/02/cpu-cache-flushing-fallacy.html (因有墙移动到墙内)

作者:Mechanical Sympathy

Even from highly experienced technologists I often hear talk about how certain operations cause a CPU cache to “flush”.  This seems to be illustrating a very common fallacy about how CPU caches work, and how the cache sub-system interacts with the execution cores.  In this article I will attempt to explain the function CPU caches fulfil, and how the cores, which execute our programs of instructions, interact with them.  For a concrete example I will dive into one of the latest Intel x86 server CPUs.  Other CPUs use similar techniques to achieve the same ends. Read more

并发框架Disruptor译文

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

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

剖析Disruptor:为什么会这么快

  1. 剖析Disruptor:为什么会这么快?(一)锁的缺点
  2. 剖析Disruptor:为什么会这么快?(二)神奇的缓存行填充
  3. 剖析Disruptor:为什么会这么快?(三)伪共享
  4. 剖析Disruptor:为什么会这么快?(四)揭秘内存屏障

Disruptor如何工作和使用

  1. 如何使用Disruptor(一)Ringbuffer的特别之处
  2. 如何使用Disruptor(二)如何从Ringbuffer读取
  3. 如何使用Disruptor(三)写入Ringbuffer
  4. 解析Disruptor关系组装
  5. Disruptor(无锁并发框架)-发布
  6. LMAX Disruptor——一个高性能、低延迟且简单的框架
  7. Disruptor Wizard已死,Disruptor Wizard永存!
  8. Disruptor 2.0更新摘要
  9. 线程间共享数据不需要竞争

Disruptor的应用

  1. LMAX的架构
  2. 通过Axon和Disruptor处理1M tps

如何使用 Disruptor(三)写入 Ringbuffer

原文地址:http://ifeve.com/dissecting-the-disruptor-writing-to-the-ring-buffer/

作者:Trisha   译者:廖涵  校对:方腾飞

这是 Disruptor 全方位解析(end-to-end view)中缺少的一章。当心,本文非常长。但是为了让你能联系上下文阅读,我还是决定把它们写进一篇博客里。

本文的 重点 是:不要让 Ring 重叠;如何通知消费者;生产者一端的批处理;以及多个生产者如何协同工作。 Read more

在写作中成长

本文是作者原创,原文发表于InfoQ架构师(二月刊)推荐编辑栏目:http://www.infoq.com/cn/minibooks/architect-feb-10-2013

记得第一次向InfoQ投稿已经是1年前的事情了,当时花了几个星期的时间写了一篇文章“深入分析volatile的实现原理”,准备在自己的博客中发表时,在同事金建法的建议下,怀着试一试的心态投向了InfoQ,庆幸的是半小时后得到InfoQ编辑郑柯采纳的回复,高兴之情无以言表。这也是我第一次在专业媒体上发表文章,而后在InfoQ编辑张龙的不断鼓励和支持下,我陆续在InfoQ发表了几篇并发编程相关的文章,于是便形成了“聊聊并发”专栏,在这个专栏的写作过程中,我得到非常多的成长和帮助,在此非常感谢InfoQ的编辑们。接下来我想分享下我的写作历程和我对写作的看法。

通过写作来学习。不知何时便爱上了写作,翻开自己的博客,从06年到现在已经写了164篇博文。为什么会写博客?因为我的学习方法是每个输入都尽量有所输出,无论是读书,看文章,参加技术讲座,还是看电影,我都会或多或少的总结输出出来,输出形式要么是一篇博客,要么是一篇微博,要么是一篇笔记。我总是在想如果这篇文章我看完了,但是我却说不出他讲的是什么,那我岂不是在浪费时间。自己完全掌握的知识应该是自己能表达出来的知识。 Read more

Disruptor Wizard已死,Disruptor Wizard永存!

原文地址:The Disruptor Wizard is Dead, Long Live the Disruptor Wizard! 译者:杨帆 校对:丁一

Disruptor Wizard(上一篇中提到的DSL组件)目前已经正式并入Disruptor的代码树当中。既然.net移植版包含了Wizard风格的语法很久了,并且看起来还挺受欢迎,所以为什么还要让人们非得搞两个jar而不是一个?

我跟随Disruptor在术语命名上的变动做出了相应的更新。以前的Customer(消费者),现在叫EventProcessor(事件处理器)和EventHandler(事件句柄)。这样的命名更好的说明了实际上的情况:消费者事实上可以向事件添加附加值。另外,ProducerBarrier(生产者屏障)被合并到Ring Buffer一起,并且Ring Buffer Entry(条目)被改名为Event(事件)。新的命名更贴切了,因为实际上围绕Disruptor的编程模型大部分时候都是基于事件的。

Read more

Disruptor 2.0更新摘要

原文:Disruptor 2.0 – All Change Please 译者:杨帆

马丁最近发布了Disruptor的2.0版本,从我们开始将其开源以来发生了很多变化,现在是个时候推出一个正式的里程碑了。马丁的博客上涵盖了这次更新的所有内容,这篇文章的目的是尝试把我以前的博文以新框架的架构转述给大家,因为将它们都重写一遍要耗费很多时间。现在我看到手工绘图的缺点了。

Read more

深入理解Java内存模型(四)——volatile

本文属于作者原创,原文发表于InfoQ:http://www.infoq.com/cn/articles/java-memory-model-4

volatile的特性

当我们声明共享变量为volatile后,对这个变量的读/写将会很特别。理解volatile特性的一个好方法是:把对volatile变量的单个读/写,看成是使用同一个锁对这些单个读/写操作做了同步。下面我们通过具体的示例来说明,请看下面的示例代码:

class VolatileFeaturesExample {
    //使用volatile声明64位的long型变量
    volatile long vl = 0L;

    public void set(long l) {
        vl = l;   //单个volatile变量的写
    }

    public void getAndIncrement () {
        vl++;    //复合(多个)volatile变量的读/写
    }

    public long get() {
        return vl;   //单个volatile变量的读
    }
}

Read more

LMAX Disruptor——一个高性能、低延迟且简单的框架

原文地址:LMAX Disruptor – High Performance, Low Latency and Simple Too 翻译:杨帆 校对:丁一

Disruptor是一个用于在线程间通信的高效低延时的消息组件,它像个增强的队列,并且它是让LMAX Exchange跑的如此之快的一个关键创新。关于什么是Disruptor、为何它很重要以及它的工作原理方面的信息都呈爆炸性增长 —— 这些文章很适合开始学习Disruptor,还可跟着LMAX BLOG深入学习。这里还有一份更详细的白皮书

Read more

The j.u.c Synchronizer Framework翻译(二)设计与实现

原文链接 作者:Doug Lea 译者:欧振聪 校对:丁一

3 设计与实现

同步器背后的基本思想非常简单。acquire操作如下:

while (synchronization state does not allow acquire) {
	enqueue current thread if not already queued;
	possibly block current thread;
}
dequeue current thread if it was queued;

release操作如下:

update synchronization state;
if (state may permit a blocked thread to acquire)
	unblock one or more queued threads;

为了实现上述操作,需要下面三个基本组件的相互协作:

  • 同步状态的原子性管理;
  • 线程的阻塞与解除阻塞;
  • 队列的管理;

创建一个框架分别实现这三个组件是有可能的。但是,这会让整个框架既难用又没效率。例如:存储在队列节点的信息必须与解除阻塞所需要的信息一致,而暴露出的方法的签名必须依赖于同步状态的特性。

同步器框架的核心决策是为这三个组件选择一个具体实现,同时在使用方式上又有大量选项可用。这里有意地限制了其适用范围,但是提供了足够的效率,使得实际上没有理由在合适的情况下不用这个框架而去重新建造一个。 Read more

Qcon2012杭州站参会分享

作者:方腾飞  整理水羽哲

去年参加了QCon杭州2012大会,有一些收获和大家分享一下。

京东的分享

京东面临的问题

京东的分享嘉宾何斌提出京东之前面临的两个问题:第一个是促销时需要很多机器,但是平时不需要;第二个是当某一台客服中毒其他客服主机也会中毒。大家可以先思考下,觉得应该如何解决这两个问题呢?

京东的解决方案

第一个问题京东采用弹性架构的方式解决。当服务器的资源利用率超过一定阈值时动态扩展虚拟机。举一个例子:如在5分钟内资源使用率达到某个设定的阈值时,就会自动生成几个虚拟机,虚拟机里会自动部署好相关的应用程序,在自动发布前有一个TestServer来监测生成的虚拟机是否可以对外提供服务。云存储和云计算是分离的,云存储使用一个磁盘阵列来实现。

第二个问题京东采用桌面云的方式来解决。首先分配一批虚拟桌面池,然后客服通过权限登陆虚拟桌面,如果没有则再分配一批,虚拟桌面和人不是一一对应的,用完后就回到池子里别人可以继续申请使用,这样可以大大节约资源,当一台机器中病毒后只会影响到子网。

Read more

剖析Disruptor:为什么会这么快?(三)揭秘内存屏障

原文地址:http://ifeve.com/disruptor-memory-barriers/

译者:杜建雄     校对:欧振聪

最近我博客文章更新有点慢,因为我在忙着写一篇介绍内存屏障(Memory Barries)以及如何将其应用于Disruptor的文章。问题是,无论我翻阅了多少资料,向耐心的MartinMike请教了多少遍,以试图理清一些知识点,可我总是不能直观地抓到重点。大概是因为我不具备深厚的背景知识来帮助我透彻理解。

所以,与其像个傻瓜一样试图去解释一些自己都没完全弄懂的东西,还不如在抽象和大量简化的层次上,把我在该领域所掌握的知识分享给大家 。Martin已经写了一篇文章《going into memory barriers》介绍内存屏障的一些具体细节,所以我就略过不说了。

免责声明:文章中如有错误全由本人负责,与Disruptor的实现和LMAX里真正懂这些知识的大牛们无关。

Read more

Java NIO系列教程(十二) Java NIO与IO

原文地址:http://tutorials.jenkov.com/java-nio/nio-vs-io.html

作者:Jakob Jenkov   译者:郭蕾    校对:方腾飞

当学习了Java NIO和IO的API后,一个问题马上涌入脑海:

我应该何时使用IO,何时使用NIO呢?在本文中,我会尽量清晰地解析Java NIO和IO的差异、它们的使用场景,以及它们如何影响您的代码设计。

Java NIO和IO的主要区别

下表总结了Java NIO和IO之间的主要差别,我会更详细地描述表中每部分的差异。

IO                NIO
面向流            面向缓冲
阻塞IO            非阻塞IO
无                选择器

Read more

剖析Disruptor:为什么会这么快?(一)Ringbuffer的特别之处

原文地址:http://ifeve.com/ringbuffer/

作者:Trisha    译者寒桐  校对:方腾飞

最近,我们开源了LMAX Disruptor,它是我们的交易系统吞吐量快(LMAX是一个新型的交易平台,号称能够单线程每秒处理数百万的订单)的关键原因。为什么我们要将其开源?我们意识到对高性能编程领域的一些传统观点,有点不对劲。我们找到了一种更好、更快地在线程间共享数据的方法,如果不公开于业界共享的话,那未免太自私了。同时开源也让我们觉得看起来更酷。

从这个站点,你可以下载到一篇解释什么是Disruptor及它为什么如此高性能的文档。这篇文档的编写过程,我并没有参与太多,只是简单地插入了一些标点符号和重组了一些我不懂的句子,但是非常高兴的是,我仍然从中提升了自己的写作水平。

我发现要把所有的事情一下子全部解释清楚还是有点困难的,所有我准备一部分一部分地解释它们,以适合我的NADD听众。

首先介绍ringbuffer。我对Disruptor的最初印象就是ringbuffer。但是后来我意识到尽管ringbuffer是整个模式(Disruptor)的核心,但是Disruptor对ringbuffer的访问控制策略才是真正的关键点所在。

Read more

JVM运行时数据区

本文是《The Java Virtual Machine Specification (Java SE 7 Edition)》2011年6月版的运行时数据区的翻译

原文参见:http://download.oracle.com/javase/7/specs/jvms/JVMS-JavaSE7.pdf  译者:方腾飞

JVM定义了若干个程序执行期间使用的数据区域。这个区域里的一些数据在JVM启动的时候创建,在JVM退出的时候销毁。而其他的数据依赖于每一个线程,在线程创建时创建,在线程退出时销毁。

2.5.1  程序计数器(The pc Register

JVM一次能支持很多线程执行。每一个JVM线程有它自己的程序计数器。在任何时候,一个JVM的线程都正在执行当前线程的方法代码。如果这个方法不是本地方法,程序计数器包含当前被执行的JVM地址。如果线程正在执行本地方法,程序计数器的值为未定义。JVM 程序计数器足以存储一个返回地址或一个本地指针。

Read more

return top