对LMAX架构以及Event Sourcing模式的一些新思考和问题的记录 - netfocus - 博客园
一个人一辈子能做好一件事情就够了！没有学不会，只有没耐心。
posts - 95, comments - 1281, trackbacks - 0, articles - 0
最近又学习了一下LMAX架构，让我对该架构以及event sourcing模式又有了很多新的认识和疑问。
注：如果不知道什么是lmax架构和event sourcing模式的看官可以自己先去查查资料：
LMAX可以看看martin写的一篇文章：
Event Sourcing的资料比较多，随便google一下即可。
当然，我的博客里也有大量关于这两个方面的笔记，有兴趣的可以看看。
下面是我的一些最新的想法。
LMAX architecture：input event + business logic processor（BLP） + output event
架构主要执行过程：首先input event由上层（如controller）创建并最后统一汇集到input disruptor（一个并发控制组件），然后BLP在单个线程内处理所有的input event，一般处理的情况有：1）简单时，直接让aggregate 处理，处理完之后aggregate会产生output event；2）如果是复杂的过程，如long running process，则通过saga的方式来控制整个业务流程；首先也是由aggregate来处理input event，然后产生的output event会由saga响应，然后saga会根据流程逻辑决定接下来要做什么，即产生哪个input event；实际上我把saga也看成是一种聚合，因为saga也有状态，saga表达了一个流程的处理状态，saga也有唯一标识，saga也需要被持久化；总之，BLP在处理完input event后会产生output event。然后这些output event会被某些关心的event handler处理；另外有些event handler在处理output event时又会产生另外的input event并最终也发送到input disruptor，整个过程大概是这样。不知我理解的是否正确。
下面针对我上面的理解再做一些总结：
整个过程有下面这几个主要元素构成：input event + BLP(包含aggregate,saga) + output event；
input event，output event用于消息(message)传递，实际上他们都属于消息，并且也都是domain event？
BLP用于处理业务逻辑（由aggregate负责）和流程控制逻辑（由saga负责）；
aggregate产生output event，output event会最终被发送到output disruptor；
output event有两个主要作用：1）可以让领域外知道领域内发生了什么；2）可以通过output event串联某些复杂的业务过程，如银行转账，如提交订单，etc；
值得注意的是：整个BLP（saga+aggregate）是in-memory的，重建BLP是用input event来实现，而不是output event；这也是为什么LMAX架构中在BLP处理input event之前必须先通过一个叫journaler的东西持久化input event的原因。目的就是为了在需要的时候利用这些input event通过event sourcing（事件溯源）模式重建整个BLP。其实这个行为更直白的理解就是让BLP再重新处理一遍所有的input event；当然，在重建过程中对于任何要访问外部系统接口的地方，都要禁止访问，否则会带来问题，尤其是更新外部系统的时候，这个其实比较简单，只要设计一个gateway即可，重建blp的时候设置一下该gateway即可。
接下来我想阐述一些我觉得自己比较纠结的地方：
event sourcing的中文解释是事件溯源，关键是如何理解溯源？我的理解是：根据已经发生的事情来重现历史。如果这个理解是正确的，那何为已经发生的事情？lmax是通过input event来溯源，也就是说Lmax认为已经发生的事情是input event，而非output event，即LMAX认为已经发生是指只要input event一旦被创建就表示事情已经发生了，即已经发生是针对用户而言的，如用户提交了订单，那就是OrderSubmitted，用户点击了修改资料的保存按钮，那就是UserProfileChangeRequested；而我们之前的做法是根据aggregate产生的output event来溯源，即我们认为已经发生是相对aggregate而言的；那么到底哪种思路更好呢？虽然两种做法都能最终还原BLP。但就我个人理解，我觉得lmax的做法更合理，实际上如果让LMAX和CQRS架构的command端做对比，那么input event相当于command，只不过command一般都是动词，所以就是CreateOrder，ChangeUserProfile。所以可以理解为lmax架构实际上是在replay command；所以问题就演变为我们到底应该replay command还是replay event？想想replay是谁在replay？是聚合根，这点毫无疑问。另外，replay从语义上来说实际上就是和play做的事情是一样的，只不过是&重做&的意思。那么要理解重做首先要理解什么是&做&？我对&做&的理解就是执行行为并改变状态。所以&重做&就是重新重新执行行为并改变状态；replay command相当于是在重做别人给aggregate一些命令；而replay event相当于是在重做aggregate自己以前曾今做过的一些事情。其实，最重要的一点是，到底要重做什么？是重做用户的要求(what user want to do)还是重做聚合根内已经发生的事情(what domain has happened.)，这个问题的回答直接决定到底该replay command 还是 replay event，呵呵。所以，按照这样的思路来思考就很明显了，LMAX是在重做用户的要求，而我们之前的replay event则是在重做聚合根内已经发生的事情。如果我认为重做应该是重做用户的要求，那replay event就不是真正意义上的重做了，而仅仅只是改变状态。举例：假设有一个Note聚合根，有一个ChangeTitle的公共方法，然后还有一个ChangeTitleCommand，ChangeTitleCommand的handler会调用Note的ChangeTitle方法；另外Note还有一个OnTitleChanged的私有方法，用于响应TitleChanged事件。如果是replay command，那会导致ChangeTitle会被重新调用，这就是重做用户的要求；而如果是replay event，则只有OnTitleChanged方法被重新调用，也就是说只是在重做聚合根内已经发生的事情。思考到这里，我不得不承认第一个思考出这种思路的人很厉害，因为他用了这种绕个弯的做法（将本来可以放在一个方法内一次性完成的任务（先改状态然后再产生output event））拆分为两个步骤，第一步是先仅仅产生一个TitleChanged的事件，第二步才是响应该事件并作出状态改变。这样拆分的目的是可以让第二步的方法（OnTitleChanged方法）可以用于event sourcing。另外，这两步对聚合根外部来说是透明的，因为外部根本不知道内部是通过两个步骤来实现的。不得不承认这种做法在replay的时候远比replay command要容易的多，因为所有的aggregate的内部事件响应函数都不会涉及与任何外部系统的交互。虽然这种做法挺好，但是我觉得我们非常有必要搞清楚这两种不同的event sourcing的区别。
另一方面，从确保event必须被持久化的角度来讲：我觉得LMAX的架构，即replay command的好处是，可以很容易在进入BLP之前持久化command，真正做到在BLP处理之前确保所有事件已经被持久化了；而如果是replay event，那我们就没办法实现一个in-memory的BLP了，因为首先BLP是in-memory的，即没有任何IO，但是我们又要求必须持久化output event。那怎么办呢？如果是同步的方式持久化output event，那就不是in-memory了；如果是异步的方式来持久化output event，那虽然可以做到in-memory，但怎么确保output event一定已经被持久化了呢？
目前就这些了，以后有更多的思考内容再补充上来。
-------------------------------------------------------------------------------------------------------------------------------
后来又做了一些思考。想来想去，最终还是倾向于应该通过output event来做event sourcing。因为毕竟只有output event才真正表示domain aggregate认可的可以发生的domain event。而我们要重建的就是聚合根，到底是应该通过重复执行用户的命令来让模型达到最新状态还是通过让聚合根重新执行已经发生过的事情呢？现在想来，应该是后者。虽然前者也可以，但是要付出的代价相对比较大，比如重建时要禁用外部系统的调用，最麻烦的还是重启发布时的很多细节问题要考虑；而通过聚合根已经发生的事情来重建，则相对很容易，因为重建时不会涉及任何模型之外的东西！但是因为我们现在采用了in-memory domain的架构，所以传统的基于数据库事务的做法已经无法使用了。所以需要设计另外一种架构确保在domain修改状态之前domain event已经被持久化了，为什么要做这个保证是因为event sourcing+in memory的架构实际上是一种event driven architecture，即整个领域模型的状态的修改都是由事件驱动的，这意味着如果要改变内存中的领域模型的状态，那必须先确保引起该状态修改的domain event必须已经被持久化了。从用户发起一个command后执行的流程如下：disruptor是并发控制组件，大家可以暂时理解为一个消息队列。如果要进一步了解disruptor，可以看看LMAX架构。
Send ChangeNoteTitleComman
Command handler execute method calle
Note.ChangeTitle method called by command ha
NoteTitleChanged domain event is created and raised in note.ChangeT
The infrastructure framework send the above NoteTitleChanged event to input disruptor when the ra
Journal event handler called by input disruptor
Another event handler called by input disruptor to really apply all the note state changes according with the event.
A third event handler called by input disruptor to send the event to
All the external event handlers are called by
for example, some external event handlers will update the CQRS
以上步骤必须严格按照上面的顺序一步步执行下来，否则无法确保逻辑正确。另外，以上流程目前只考虑单台机器，未考虑主备或集群的架构如何实现；之所以用英文写是因为我还要拿去和老外讨论，呵呵。不过这几句英文应该比较简单吧。LMAX TRADER 平台使用说明. 目录. 目录. .... ..
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
LMAX TRADER 平台使用说明 - LMAX外汇
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口只需一步，快速开始
后使用快捷导航没有帐号？
& &LMAX常见问题
LMAX常见问题
　　LMAX平台的MT4模拟账户不能自己直接申请，必须向官方人员申请的。
　　可以的，但是开户的时候基础货币要选跟之前开的那个账户不同，如果先前是美元帐户的话，那开第二个账户就要选欧元、英镑或澳元帐户。
　　注册第二个账户时一定要注意：除了基础货币不同外，其它的资料要和上 ...
　　LMAX的黄金最低交易是额是10盎司
　　MT4上最低交易是20盎司
　　LMAX平台的MT4可以交易白银的。
　　目前，LMAX平台的MT4只能交易外汇与黄金，白银，其中cfd只能在webtrader上交易。
　　lmax平台的强平标准是：低于保证金的70%.举个例子，你帐户上有一万美元，交易了一百万市值的货币对，也就是说杠杆用足了一百倍，需要占用保证金一万美元，而你帐户上的资金正好够一万，那么，当你帐户上的资金低 ...
　　LMAX平台真实帐户里有英国原油，美原油，黄金，白银，各类指数，但铜还没有的。
关于LMAX上的隔夜利息计算的基本原则：多仓 + 正利率 = 客户支付利息 ,多仓 + 负利率 = 客户收取利息,空仓 + 正利率 = 客户收取利息,空仓 + 负利率 = 客户支付利息
对于LMAX出入金是否收费一事，官网客服回应LMAX不在客户的出入金上收取任何费用。客户在银行汇款时，客户方的银行和我方的银行会收取国际汇款的手续费，依银行而收费不同。一般而言，美国银行大致是收取25 美元的手
LMAX交易所既支持手动交易也可以提供数据源来接入自动交易系统。连接模式：交叉连接 (Equinix LD4/5)、PoP协定连结 (Interxion)、外联网和互联网连接方式：API接口 (Java 和 .Net)、FIX 4.4、网页平台、手机平台更多 ...
入金方式和品种LMAX目前支持银行电汇和信用卡(目前仅支持visa信用卡)出入金,支持货币为美元,欧元和英镑大陆地区信用卡入金仅可使用工行visa信用卡，请注意这是大陆地区唯一可用的信用卡入金方式官网资金到帐情况查询 ...
LMAX银行概述LMAX银行间只是银行现货外汇执行场所,LMAX交换的一部分。基于证明,可靠,获奖LMAX交易所外汇匹配技术,LMAX银行同业提供的所有好处交换质量的执行,完成前,交易后透明度和所有参与者的公平竞争——无论地位 ...
字号：大中小LMAX交易所交易技术
在线咨询-独一无二的,健壮和可伸缩的核心技术是LMAX交换——我们不断关注专业知识提炼和改进LMAX交换技术的所有方面。我们的革命和简约的方法技术,架构和技术相关流程仔细混 ...
交易所标准的优质执行质量LMAX 交易所为多边交易设施MTF，受到英国金融市场行为管理局FCA授权并监管。我们为所有外汇市场参与者提供一个公平安全的交易平台：该平台拥有独一无二的、交易所标准的执行质量，并保证交
1.申请账户请打开我所提供的联接。申请表总共为4页，第一面是个人信息，如下Title称呼，将鼠标点框内之后，选择相关称呼：Mr.为先生，Miss.为小姐，Ms.为女士，Mrs为太太Firstname:名Surname:姓Emailaddress:电子邮
LMAX平台出入金流程LMAX入金方式有两种：一种信用卡入金。一种是电汇入金。信用卡入金：目前LMAX只支持工行visa双币信用卡电汇入金流程如下图：（出入金说明-新.pdf直接点击下载PDF文档）
平台最新优惠活动
012 / 次浏览
025 / 次浏览
03223 / 次浏览
04173 / 次浏览
05106 / 次浏览
06129 / 次浏览
07205 / 次浏览
08196 / 次浏览
09240 / 次浏览
Powered byMartin Fowler最近的一篇文章：。LMAX是一种新型零售金融交易平台，它能够以很低的延迟(latency)产生大量交易(吞吐量). 这个系统是建立在JVM平台上，核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单. 业务逻辑处理器完全是运行在内存中(in-memory)，使用事件源驱动方式(event sourcing). 业务逻辑处理器的核心是Disruptors，这是一个组件，能够在无锁的情况下实现网络的Queue并发操作。他们的研究表明，现在的所谓高性能研究方向似乎和现代CPU设计是相左的。(见另外一篇文章：)过去几年我们不断提供这样声音：免费午餐已经结束。我们不再能期望在单个CPU上获得更快的性能，因此我们需要写使用多核处理的软件，不幸的是， 编写软件是很难的，锁和信号量是很难理解的和难以测试，这意味着我们要花更多时间在计算机上，而不是我们的领域问题，各种模型，如 和软事务STM(Software Transactional Memory), 目的是更加容易使用，但是按下葫芦飘起瓢，还是带来了bugs和复杂性.我很惊讶听到去年3月QCon上一个演讲， LMAX是一种新的零售的金融交易平台。它的业务创新 - 允许任何人在一系列的金融衍生产品交易。这就需要非常低的延迟，非常快速的处理，因为市场变化很快，这个零售平台因为有很多人同时操作自然具备了复杂性，用户越多，交易量越大，不断快速增长。鉴于多核心思想的转变，这种苛刻的性能自然会提出一个明确的并行编程模型 ，但是他们却提出用一个线程处理6百万订单，而且是每秒，在通用的硬件上。通过低延迟处理大量交易，取得低延迟和高吞吐量，而且没有代码的复杂性，他们是怎么做到呢？现在LMAX已经产品化一段时间了，现在应该可以揭开其神秘而迷人的面纱了。结构如图：从最高层次看，架构有三个部分：业务逻辑处理器business logic processor[5]输入input disruptor输出output disruptors业务逻辑处理器处理所有的应用程序的业务逻辑，这是一个单线程的Java程序，纯粹的方法调用，并返回输出。不需要任何平台框架，运行在JVM里，这就保证其很容易运行测试环境。业务逻辑处理器全部驻留在内存中业务逻辑处理器有次序地取出消息，然后运行其中的业务逻辑，然后产生输出事件，整个操作都是在内存中，没有数据库或其他持久存储。将所有数据驻留在内存中有两个重要好处：首先是快，没有IO，也没有事务，其次是简化编程，没有对象/关系数据库的映射，所有代码都是使用Java对象模型(广告：开源框架JdonFramework和Jivejdon也是全部基于内存和事件源，内存领域对象+事件驱动，看来这条路的方向是对的)。使用基于内存的模型有一个重要问题：万一崩溃怎么办？电源掉电也是可能发生的，“事件”(Event Sourcing )概念是问题解决的核心，业务逻辑处理器的状态是由输入的，只要这些输入事件被持久化保存起来，你就总是能够在崩溃情况下，根据事件重演重新获得当前状态。()要很好理解这点可以通过版本控制系统来理解，版本控制系统提交的序列，在任何时候，你可以建立由申请者提交一个工作拷贝，版本控制系统是一个复杂的商业逻辑处理器，而这里的业务逻辑处理只是一个简单的序列。因此，从理论上讲，你总是可以通过后处理的所有事件的商业逻辑处理器重建的状态，但是实践中重建所有事件是耗时的，需要切分，LMAX提供业务逻辑处理的快照，从快照还原，每天晚上系统不繁忙时构建快照，重新启动商业逻辑处理器的速度很快，一个完整的重新启动 - 包括重新启动JVM加载最近的快照，和重放一天事件 - 不到一分钟。快照虽然使启动一个新的业务逻辑处理器的速度，但速度还不够快，业务逻辑处理器在下午2时就非常繁忙甚至崩溃，LMAX就保持多个业务逻辑处理器同时运行，每个输入事件由多个处理器处理，只有一个处理器输出有效，其他忽略，如果一个处理器失败，切换到另外一个，这种故障转移失败恢复是事件源驱动(Event Sourcing)的另外一个好处。通过(event sourcing)他们也可以在处理器之间以微秒速度切换，每晚创建快照，每晚重启业务逻辑处理器， 这种复制方式能够保证他们没有当机时间，实现24/7.事件方式是有价值的因为它允许处理器可以完全在内存中运行，但它有另一种用于诊断相当大的优势：如果出现一些意想不到的行为，事件副本们能够让他们在开发环境重放生产环境的事件，这就容易使他们能够研究和发现出在生产环境到底发生了什么事。这种诊断能力延伸到业务诊断。有一些企业的任务，如在风险管理，需要大量的计算，但是不处理订单。一个例子是根据其目前的交易头寸的风险状况排名前20位客户名单，他们就可以切分到复制好的领域模型中进行计算，而不是在生产环境中正在运行的领域模型，不同性质的领域模型保存在不同机器的内存中，彼此不影响。性能优化正如我解释，业务逻辑处理器的性能关键是按顺序地做事(其实并不愚蠢 并行做就聪明吗？)，这可以让普通开发者写的代码处理10K TPS. 如果能精简代码能够带来100K TPS提升. 这需要良好的代码和小方法，当然，JVM Hotspot的微调，让其更加优化也是必须的。以下省去两段.......调试方面。编程模型以一个简单的非LMAX的例子来说明。想象一下，你正在为糖豆使用信用卡下订单。一个简单的零售系统将获取您的订单信息，使用信用卡验证服务，以检查您的信用卡号码，然后确认您的订单 - 所有这些都在一个单一过程中操作。当进行信用卡有效性检查时，服务器这边的线程会阻塞等待，当然这个对于用户来说停顿不会太长。在MAX架构中，你将此单一操作过程分为两个，第一部分将获取订单信息，然后输出事件(请求信用卡检查有效性的请求事件)给信用卡公司. 业务逻辑处理器将继续处理其他客户的订单，直至它在输入事件中发现了信用卡已经检查有效的事件，然后获取该事件来确认该订单有效。这种异步方式确实不寻常，虽然使用异步提高应用程序的响应是一个熟悉的技术。它还可以帮助业务流程更弹性，因为你必须要更明确的思考与远程应用程序打交道的不同之处。这个编程模型第二个特点在于错误处理。传统模式下会话和数据库事务提供了一个有用的错误处理能力。如果有什么出错，很容易抛出任何东西，这个会话能够被丢弃。如果一个错误发生在数据库端，你可以回滚事务。LMAX的内存模式(in-memory structures)在于持久化输入事件，如果有错误发生也不会从内存中离开造成不一致的状态。但是因为没有回滚机制，LMAX投入了更多精力，确保输入事件在实施任何内存状态影响前有效地持久化，他们发现这个关键是测试，在进入生产环境之前尽可能发现各种问题，确保持久化有效。banq注：老马虽然很罗嗦，但是详细易懂，英文也标准，下面还有一半，休息一下，待续。[该贴被banq于 11:10修改过]
尽管业务逻辑是在单个线程中实现的，但是在我们调用一个业务对象方法之前，有很多任务需要完成. 原始输入来自于消息形式，这个消息需要恢复成业务逻辑处理器能够处理的形式。事件源Event Sourcing依赖于让所有输入事件持久化，这样每个输入消息需要能够存储到持久化介质上，最后整个架构还有赖于业务逻辑处理器的集群. 同样在输出一边，输出事件也需要进行转换以便能够在网络上传输。如图复制和日志是比较慢的。所有业务逻辑处理器避免最任何IO处理，所有这些任务都应该相对独立，他们需要在业务逻辑处理器处理之前完成，它们可以以任何次序方式完成，这不同意业务逻辑处理器需要根据交易自然先后进行交易,这些都是需要的机制。为了这个机制，他们开发了的开源组件。Disruptor可以看成一个事件监听或消息机制，在队列中一边生产者放入消息，另外一边消费者并行取出处理. 当你进入这个队列内部查看，发现其实是一个真正的单个数据结构：一个ring buffer. 每个生产者和消费者都有一个次序计算器，以显示当前缓冲工作方式.每个生产者消费者写入自己次序计数器，能够读取对方的计数器，生产者能够读取消费者的计算器确保其在没有锁的情况下是可写的，类似地消费者也要通过计算器在另外一个消费者完成后确保它一次只处理一次消息。输出disruptors也类似于此，但是只有两个有顺序的消费者，转换和输出。输出事件被组织进入几个topics, 这样消息能够被发送到只有感兴趣的topic中，每个topic有自己的disruptor.disruptor不但适合一个生产者多个消费者，也适合多个生产者。disruptor设计的好处是能够容易让消费者快速抓取，如果发生问题，比如在15号位置有一个转换问题，而接受者在31号，它能够从16-30号一次性批量抓取，这种数据批读取能力加快消费者处理，降低整体延迟性。ring buffer是巨大的: 输入2千万号槽；4百万输出. 次序计算器是一个64bit long 整数型，平滑增长(banq注：大概这里发现了JVM的伪共享)，象其他系统一样disruptors过一个晚上将被清除，主要是擦除内存，以便不会产生代价昂贵的垃圾回收机制启动(我认为重启是一个好的习惯，以便你应付不时之需。)日志工作是将事件存储到持久化介质上，以便出错是重放，但是他们没有使用数据库来实现，而是文件系统，他们将事件流写到磁盘上，在现代概念看来，磁盘对于随机访问是非常慢，但是对于流操作却很快，也就是说，磁盘是一种新式的磁带。之前我提到LMAX运行在集群多个系统拷贝能够支持失败回复，复制工作负责这些节点的同步，所有节点联系是IP广播, 这样客户端能够不需要知道主节点的IP地址. 只有主节点直接听取输入事件，然后运行一个复制工作者，复制工作者将把输入事件广播到其他次要节点. 如果主节点当机，心跳机制将会发现， 另外一个节点就成为主节点，开始处理输入事件，启动复制工作者，每个节点都有自己的输入disruptor这样它有自己的日志处理和格式转换。(为防止再次崩溃，提交后待续...)
即使有IP广播，复制还是需要的，因为IP消息是以不同顺序到达不同节点，主节点提供为其他处理提供一个确定顺序。格式转换unmarshaler是将事件从其消息格式转换到Java对象，这样才能在业务逻辑处理器中使用，不同于其他消费者，它需要修改ring buffer中的数据以便能够存入这个被转换好的Java对象，这里有一个规则：并发地每次只有一个消费者能够运行写入，这实际上也符合单一写入者原则。disruptor组件可以用在LMAX系统以外，通常金融财务公司对他们的系统都保持隐秘，但是LMAX能够开源，我很高兴，这将允许其他组织使用disruptor，它也将允许其他人对其进行性能测试。(banq注：disruptor看来是一种特殊的消息组件类似JMS东西)。队列和机制偏爱的缺乏LMAX架构引起了人们的关注，因为它是一个非常不同的方式接近的高性能系统。到目前为止，我已经谈到了它是如何工作的，但没有太多深入探讨了为什么它是这样。这个故事本身是有趣的，意识到他们是有缺陷的。许多商业系统都有自己的核心架构师，通过事务性数据库实现多个会话事务(banq注：如EJB或Spring JTA等等)，LMAX团队也熟悉这些知识，但是确信这些不合适他们的系统。这个经验是建立在LMAX母公司Betfair上 - 这是一家体育博彩公司，它处理很多人的体育投赌事件，这是一个相当大的访问，传统数据库机制几乎无法应付，这些让他们相信必须寻找另外一个途径来突破，他们现在接近目标了。他们最初的想法为获得高性能是使用现在流行的。这意味着允许多线程并行处理多个订单。然而，在这种情况下是很难实现的，因为这些线程必须互相沟通。处理订单变化的市场条件等都需要相互沟通。早期他们探索了Actor模型和近亲SEDA. Actor模型依赖于独立，活跃的对象有其自己的线程，彼此之间是通过queue同学，很多人认为这种模型比基于原始锁的方式易于处理。这团队就建立了一个actor模型原型，进行性能测试，他们发现的是处理器会花费更多时间在管理队列，而不是去做真正应用逻辑，队列访问成了真正瓶颈(banq注：Scala的Actor模型很有名，不知这是否算Scala致命问题，怪不得很少人谈Scala的Actor模型了).当追求性能达到这种程度，现代硬件构造原理成为很重要的必须了解的知识了，马丁汤普森喜欢用的一句话是“机制偏爱”，这词来自赛车驾驶，它反映的是赛车手对汽车有一种与生俱来的感觉，使他们能够感受到如何发挥它到最好状态。许多程序员包括我承认我也陷入这样一个阵营：不会认为编程如何与硬件等底层机制交互是值得研究的。现代的CPU延迟是影响性能的主导因素之一，在CPU如何与内存交互，CPU具有多层次的（一级二级），每级速度都明显加快。因此，如果要提高速度，将您的代码和数据加载到这些中。在某个层次, actor模型能够帮助你，你能认为actor可以作为集群节点，是的自然单元。但是需要相互联系, 这是通过队列的- 而LMAX团队发现队列会干扰(banq注：JVM伪分享的问题)。(为防止崩溃，待续...)[该贴被admin于 07:16修改过]
为什么队列干扰了呢？解释是这样的: 为了将数据放入队列，你需要写入队列，类似地，为了从队列取出数据，你需要移除队列也是一种写，客户端也许不只一次写入同样数据结构，处理写通常需要锁，但是如果锁使用了，会引起切换到底层系统的场景， 当这个发生后，处理器会丢失它的中的数据。他们得出的结论能够获得最好的性能, 你需要设计一个CPU核写任何内存，多个读是好的，处理器会非常快，而队列失败在one-writer原则。()这样的分析导致LMAX团队得出一系列结论，导致他们设计出disruptor, 能够遵循single-writer约束. 其次它导向留澳单个线程处理业务逻辑的新的目标, 问题是：一个线程如果从管理结构中脱离出来(没有锁机制)，它到底能跑多快？单个线程的本质是：确保你每个CPU核运行一个线程，缓存配合，尽可能的高速访问甚于主内存。这就意味着代码和数据需要尽可能的一致，. 保持小的代码对象和数据在一起，以便允许他们能够调入到一个高速单位中或者轮换，简化高速管理就是提高性能。
LMAX架构的路径的一个重要组成部分是使用了性能测试。基于actor模型的放弃也是来自于测试原型的性能。同时也为改善的各个组成部分的性能步骤，启用了性能测试。机械同情是非常宝贵的的 - 它有助于形成假设什么可以改进，并指导你前进 -最终测试提供了有说服力的证据。两段关于性能测试重要性，忽略....你应当使用者架构吗这个架构是适合非常小小众，必须有很低的延迟获得复杂大量的交易，大多数应用并不需要6百万TPS。但是我对这个架构着迷的原因是它的设计，它移除了很多其他大多数编程系统的复杂性，传统围绕事务性的关系数据库会话模型是不是免费的麻烦？(banq注：因为都掌握都知道也就是免费的) 通常与数据库打交道都有不寻常的付出和努力，对象/关系数据库映射ORM工具Object/relational mapping tools能够帮助减轻不少这种痛苦，但是它不能解决全部问题，大多数企业性能微调还是要纠结于SQL.现在你能得到服务器更多的主内存，比我们过去这些老家伙得到的磁盘还要多，越来越多应用能够将他们的工作全部置于内存中，这样消除了复杂性和性能低问题. 事件源驱动Event Sourcing提供了一种内存in-memory系统的解决方案, 在单个线程运行业务解决了. LMAX 经验建议只要你需要少于几百万TPS，你就有足够的性能提升余地。这里也是相似于. 一种, in-memory风格自然的命令系统(尽管LMAX当前没有使用.)那么表示你是不是不应该走上这条道路呢？始终存在这样鲜为人知的棘手的技术问题，这个行业需要更多的时间去探索它的边界(注：老子思想的缴啊)。基本出发点是鼓励有自己特点的架构。一个重要特点是处理一个交易总是潜在地影响其后面的处理方式，因为交易总是相互独立的, 因为很少相互协调，那么使用分离单独处理器分别处理运行也许更加有吸引力。LMAX指出了“事件”概念是如何改变世界(banq注：hold住事件，而不是hold住数据，你就上了一个新层次，摆脱低级趣味的数据库癖好)。 许多网站使用原有的信息存储系统，然后渲染各种能够吸引眼球的效果. 他们的架构挑战就是如何正确使用。LMAX另外一个特点是这是一个后台系统，有理由考虑如何在一个交互模型中应用它，比如日益增长的Web应用，当异步通讯在WEB应用越来越多时，这将改变我们的编程模型。这个改变会影响很多团队，大多数人倾向于认为同步编程，不习惯于异步处理。异步通讯是必不可少的响应工具，在javascript世界已经广泛使用，如 AJAX 和 node.js, 这些鼓励人们研究这些风格. LMAX团队发现虽然要花费一定时间来适应模型，但是一旦习惯就成为自然，特别是错误处理上容易得多。LMAX团队当然感觉到花力气协调事务性关系数据库的日子已经屈指可数(banq老泪纵横啊，05年喊出了，08年我就喊出，被国内很多大牛讥笑为疯子) 。你可以使用一种更加容易方式编写程序而且比传统集中式中央数据库运行得更快，为什么视而不见呢？从我的观点看，我发现了一个令人激动的故事，我的大多数目标集中在软件的复杂领域模型解决上，作为一个架构师很喜欢这样的分离关注：让人们关注领域驱动设计 Domain-Driven Design，同时很好分离了平台复杂性，领域对象和数据库的紧耦合总是如一根针刺激我，现在好像找到出路了。全文完。banq最后注，我来总结老马文章的主要观点：1.肯定了In-Memory内存模式 + 异步事件 架构，LMAX实践也验证了这个架构。这个架构降低复杂性。2.LMAX的核心是新型框架，其核心是根据现代CPU硬件特点发明不同于通用LinkedList或Queue的新型数据结构RingBuffer。3.号称未来的Actor模型被LMAX团队验证是有瓶颈的。4.提出新的模型，每个CPU一个线程，多个CPU多个线程模式，摒弃了锁模式。5.ORM等Hibernate没有完全解决的目标，关系数据库的事务也不是最后救命的稻草。LMAX用自己的事件记录的方式实现事务，这也不同于所谓内存事务STM。见另外一篇：。6.09年推出jdonFramework 6.1版本就是(Event Sourcing)+异步编程模型+In-memory架构，老马实际肯定了Jdon一直坚持的前沿架构观点。(当然jdonframework和LMAX还有些差别，只有领域模型异步的输出事件，没有输入事件，下一步可以引入Disruptors)。7.老马认为架构师要分离关注，一是通过降低业务的复杂性；二是通过技术探索创新，降低技术平台的复杂性，让程序员更多精力投入业务问题解决上。[该贴被banq于 08:35修改过]
探索 分享 交流 解惑 授道
OpenSource
Code & 2002-15