LMAX是一種新型零售金融交易平臺(tái)，它能夠以很低的延遲(latency)產(chǎn)生大量交易(吞吐量). 這個(gè)系統(tǒng)是建立在JVM平臺(tái)上，核心是一個(gè)業(yè)務(wù)邏輯處理器，它能夠在一個(gè)線程里每秒處理6百萬訂單. 業(yè)務(wù)邏輯處理器完全是運(yùn)行在內(nèi)存中(in-memory)，使用事件源驅(qū)動(dòng)方式(event sourcing). 業(yè)務(wù)邏輯處理器的核心是Disruptors，這是一個(gè)并發(fā)組件，能夠在無鎖的情況下實(shí)現(xiàn)網(wǎng)絡(luò)的Queue并發(fā)操作。他們的研究表明，現(xiàn)在的所謂高性能研究方向似乎和現(xiàn)代CPU設(shè)計(jì)是相左的。

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)提供從項(xiàng)目策劃、軟件開發(fā)，軟件安全維護(hù)、網(wǎng)站優(yōu)化(SEO)、網(wǎng)站分析、效果評(píng)估等整套的建站服務(wù)，主營業(yè)務(wù)為網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站，重慶App定制開發(fā)以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。創(chuàng)新互聯(lián)深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

過去幾年我們不斷提供這樣聲音：免費(fèi)午餐已經(jīng)結(jié)束。我們不再能期望在單個(gè)CPU上獲得更快的性能，因此我們需要寫使用多核處理的并發(fā)軟件，不幸的是， 編寫并發(fā)軟件是很難的，鎖和信號(hào)量是很難理解的和難以測(cè)試，這意味著我們要花更多時(shí)間在計(jì)算機(jī)上，而不是我們的領(lǐng)域問題，各種并發(fā)模型，如Actors 和軟事務(wù)STM(Software Transactional Memory), 目的是更加容易使用，但是按下葫蘆飄起瓢，還是帶來了bugs和復(fù)雜性.

我很驚訝聽到去年3月QCon上一個(gè)演講， LMAX是一種新的零售的金融交易平臺(tái)。它的業(yè)務(wù)創(chuàng)新 – 允許任何人在一系列的金融衍生產(chǎn)品交易。這就需要非常低的延遲，非?？焖俚奶幚?，因?yàn)槭袌?chǎng)變化很快，這個(gè)零售平臺(tái)因?yàn)橛泻芏嗳送瑫r(shí)操作自然具備了復(fù)雜性，用戶越多，交易量越大，不斷快速增長(zhǎng)。

鑒于多核心思想的轉(zhuǎn)變，這種苛刻的性能自然會(huì)提出一個(gè)明確的并行編程模型 ，但是他們卻提出用一個(gè)線程處理6百萬訂單，而且是每秒，在通用的硬件上。

通過低延遲處理大量交易，取得低延遲和高吞吐量，而且沒有并發(fā)代碼的復(fù)雜性，他們是怎么做到呢？現(xiàn)在LMAX已經(jīng)產(chǎn)品化一段時(shí)間了，現(xiàn)在應(yīng)該可以揭開其神秘而迷人的面紗了。

整體結(jié)構(gòu)

結(jié)構(gòu)如圖：

（圖一：LMAX架構(gòu)的三大塊）

 從最高層次看，架構(gòu)有三個(gè)部分：

1.        

   • 業(yè)務(wù)邏輯處理器business logic processor[5]

   • 輸入input disruptor

   • 輸出output disruptors

業(yè)務(wù)邏輯處理器處理所有的應(yīng)用程序的業(yè)務(wù)邏輯，這是一個(gè)單線程的Java程序，純粹的方法調(diào)用，并返回輸出。不需要任何平臺(tái)框架，運(yùn)行在JVM里，這就保證其很容易運(yùn)行測(cè)試環(huán)境。

Although the Business Logic Processor can run in a simple environment for testing, there is rather more involved choreography to get it to run in a production setting. Input messages need to be taken off a network gateway and unmarshaled, replicated and journaled. Output messages need to be marshaled for the network. These tasks are handled by the input and output disruptors. Unlike the Business Logic Processor, these are concurrent components, since they involve IO operations which are both slow and independent. They were designed and built especially for LMAX, but they (like the overall architecture) are applicable elsewhere.

業(yè)務(wù)邏輯處理器

全部駐留在內(nèi)存中

業(yè)務(wù)邏輯處理器有次序地取出消息，然后運(yùn)行其中的業(yè)務(wù)邏輯，然后產(chǎn)生輸出事件，整個(gè)操作都是在內(nèi)存中，沒有數(shù)據(jù)庫或其他持久存儲(chǔ)。將所有數(shù)據(jù)駐留在內(nèi)存中有兩個(gè)重要好處：首先是快，沒有IO，也沒有事務(wù)，其次是簡(jiǎn)化編程，沒有對(duì)象/關(guān)系數(shù)據(jù)庫的映射，所有代碼都是使用Java對(duì)象模型(廣告：開源框架Jdonframework和JiveJdon也是全部基于內(nèi)存和事件源，內(nèi)存領(lǐng)域?qū)ο?事件驅(qū)動(dòng)，看來這條路的方向是對(duì)的)。

使用基于內(nèi)存的模型有一個(gè)重要問題：萬一崩潰怎么辦？電源掉電也是可能發(fā)生的，“事件”(Event Sourcing )概念是問題解決的核心，業(yè)務(wù)邏輯處理器的狀態(tài)是由輸入事件驅(qū)動(dòng)的，只要這些輸入事件被持久化保存起來，你就總是能夠在崩潰情況下，根據(jù)事件重演重新獲得當(dāng)前狀態(tài)。(NOSQL存儲(chǔ)的基于事件的事務(wù)實(shí)現(xiàn))

要很好理解這點(diǎn)可以通過版本控制系統(tǒng)來理解，版本控制系統(tǒng)提交的序列，在任何時(shí)候，你可以建立由申請(qǐng)者提交一個(gè)工作拷貝，版本控制系統(tǒng)是一個(gè)復(fù)雜的商業(yè)邏輯處理器，而這里的業(yè)務(wù)邏輯處理只是一個(gè)簡(jiǎn)單的序列。

因此，從理論上講，你總是可以通過后處理的所有事件的商業(yè)邏輯處理器重建的狀態(tài)，但是實(shí)踐中重建所有事件是耗時(shí)的，需要切分，LMAX提供業(yè)務(wù)邏輯處理的快照，從快照還原，每天晚上系統(tǒng)不繁忙時(shí)構(gòu)建快照，重新啟動(dòng)商業(yè)邏輯處理器的速度很快，一個(gè)完整的重新啟動(dòng) – 包括重新啟動(dòng)JVM加載最近的快照，和重放一天事件 – 不到一分鐘。

快照雖然使啟動(dòng)一個(gè)新的業(yè)務(wù)邏輯處理器的速度，但速度還不夠快，業(yè)務(wù)邏輯處理器在下午2時(shí)就非常繁忙甚至崩潰，LMAX就保持多個(gè)業(yè)務(wù)邏輯處理器同時(shí)運(yùn)行，每個(gè)輸入事件由多個(gè)處理器處理，只有一個(gè)處理器輸出有效，其他忽略，如果一個(gè)處理器失敗，切換到另外一個(gè)，這種故障轉(zhuǎn)移失敗恢復(fù)是事件源驅(qū)動(dòng) (Event Sourcing)的另外一個(gè)好處。

通過事件驅(qū)動(dòng)(event sourcing)他們也可以在處理器之間以微秒速度切換，每晚創(chuàng)建快照，每晚重啟業(yè)務(wù)邏輯處理器， 這種復(fù)制方式能夠保證他們沒有當(dāng)機(jī)時(shí)間，實(shí)現(xiàn)24/7.

事件方式是有價(jià)值的因?yàn)樗试S處理器可以完全在內(nèi)存中運(yùn)行，但它有另一種用于診斷相當(dāng)大的優(yōu)勢(shì)：如果出現(xiàn)一些意想不到的行為，事件副本們能夠讓他們?cè)陂_發(fā)環(huán)境重放生產(chǎn)環(huán)境的事件，這就容易使他們能夠研究和發(fā)現(xiàn)出在生產(chǎn)環(huán)境到底發(fā)生了什么事。

這種診斷能力延伸到業(yè)務(wù)診斷。有一些企業(yè)的任務(wù)，如在風(fēng)險(xiǎn)管理，需要大量的計(jì)算，但是不處理訂單。一個(gè)例子是根據(jù)其目前的交易頭寸的風(fēng)險(xiǎn)狀況排名前 20位客戶名單，他們就可以切分到復(fù)制好的領(lǐng)域模型中進(jìn)行計(jì)算，而不是在生產(chǎn)環(huán)境中正在運(yùn)行的領(lǐng)域模型，不同性質(zhì)的領(lǐng)域模型保存在不同機(jī)器的內(nèi)存中，彼此不影響。

性能優(yōu)化

正如我解釋，業(yè)務(wù)邏輯處理器的性能關(guān)鍵是按順序地做事(其實(shí)并不愚蠢 并行做就聰明嗎？)，這可以讓普通開發(fā)者寫的代碼處理10K TPS. 如果能精簡(jiǎn)代碼能夠帶來100K TPS提升. 這需要良好的代碼和小方法，當(dāng)然，JVM Hotspot的緩存微調(diào)，讓其更加優(yōu)化也是必須的。

#p#

以下兩段未翻譯…….調(diào)試方面。

It took a bit more cleverness to go up another order of magnitude. There are several things that the LMAX team found helpful to get there. One was to write custom implementations of the java collections that were designed to be cache-friendly and careful with garbage[8]. An example of this is using primitive java longs as hashmap keys with a specially written array backed Map implementation (LongToObjectHashMap). In general they’ve found that choice of data structures often makes a big difference, Most programmers just grab whatever List they used last time rather than thinking which implementation is the right one for this context.[9]

Another technique to reach that top level of performance is putting attention into performance testing. I’ve long noticed that people talk a lot about techniques to improve performance, but the one thing that really makes a difference is to test it. Even good programmers are very good at constructing performance arguments that end up being wrong, so the best programmers prefer profilers and test cases to speculation.[10] The LMAX team has also found that writing tests first is a very effective discipline for performance tests.

編程模型

以一個(gè)簡(jiǎn)單的非LMAX的例子來說明。想象一下，你正在為糖豆使用信用卡下訂單。一個(gè)簡(jiǎn)單的零售系統(tǒng)將獲取您的訂單信息，使用信用卡驗(yàn)證服務(wù)，以檢查您的信用卡號(hào)碼，然后確認(rèn)您的訂單 – 所有這些都在一個(gè)單一過程中操作。當(dāng)進(jìn)行信用卡有效性檢查時(shí)，服務(wù)器這邊的線程會(huì)阻塞等待，當(dāng)然這個(gè)對(duì)于用戶來說停頓不會(huì)太長(zhǎng)。

在MAX架構(gòu)中，你將此單一操作過程分為兩個(gè)，第一部分將獲取訂單信息，然后輸出事件(請(qǐng)求信用卡檢查有效性的請(qǐng)求事件)給信用卡公司. 業(yè)務(wù)邏輯處理器將繼續(xù)處理其他客戶的訂單，直至它在輸入事件中發(fā)現(xiàn)了信用卡已經(jīng)檢查有效的事件，然后獲取該事件來確認(rèn)該訂單有效。

這種異步事件驅(qū)動(dòng)方式確實(shí)不尋常，雖然使用異步提高應(yīng)用程序的響應(yīng)是一個(gè)熟悉的技術(shù)。它還可以幫助業(yè)務(wù)流程更彈性，因?yàn)槟惚仨氁鞔_的思考與遠(yuǎn)程應(yīng)用程序打交道的不同之處。

這個(gè)編程模型第二個(gè)特點(diǎn)在于錯(cuò)誤處理。傳統(tǒng)模式下會(huì)話和數(shù)據(jù)庫事務(wù)提供了一個(gè)有用的錯(cuò)誤處理能力。如果有什么出錯(cuò)，很容易拋出任何東西，這個(gè)會(huì)話能夠被丟棄。如果一個(gè)錯(cuò)誤發(fā)生在數(shù)據(jù)庫端，你可以回滾事務(wù)。

LMAX的內(nèi)存模式(in-memory structures)在于持久化輸入事件，如果有錯(cuò)誤發(fā)生也不會(huì)從內(nèi)存中離開造成不一致的狀態(tài)。但是因?yàn)闆]有回滾機(jī)制，LMAX投入了更多精力，確保輸入事件在實(shí)施任何內(nèi)存狀態(tài)影響前有效地持久化，他們發(fā)現(xiàn)這個(gè)關(guān)鍵是測(cè)試，在進(jìn)入生產(chǎn)環(huán)境之前盡可能發(fā)現(xiàn)各種問題，確保持久化有效。

Disruptors的輸入和輸出

盡管業(yè)務(wù)邏輯是在單個(gè)線程中實(shí)現(xiàn)的，但是在我們調(diào)用一個(gè)業(yè)務(wù)對(duì)象方法之前，有很多任務(wù)需要完成. 原始輸入來自于消息形式，這個(gè)消息需要恢復(fù)成業(yè)務(wù)邏輯處理器能夠處理的形式。事件源Event Sourcing依賴于讓所有輸入事件持久化，這樣每個(gè)輸入消息需要能夠存儲(chǔ)到持久化介質(zhì)上，最后整個(gè)架構(gòu)還有賴于業(yè)務(wù)邏輯處理器的集群. 同樣在輸出一邊，輸出事件也需要進(jìn)行轉(zhuǎn)換以便能夠在網(wǎng)絡(luò)上傳輸。

如圖復(fù)制和日志是比較慢的。所有業(yè)務(wù)邏輯處理器避免最任何IO處理，所有這些任務(wù)都應(yīng)該相對(duì)獨(dú)立，他們需要在業(yè)務(wù)邏輯處理器處理之前完成，它們可以以任何次序方式完成，這不同意業(yè)務(wù)邏輯處理器需要根據(jù)交易自然先后進(jìn)行交易,這些都是需要的并發(fā)機(jī)制。

為了這個(gè)并發(fā)機(jī)制，他們開發(fā)了disruptor的開源組件。

Disruptor可以看成一個(gè)事件監(jiān)聽或消息機(jī)制，在隊(duì)列中一邊生產(chǎn)者放入消息，另外一邊消費(fèi)者并行取出處理. 當(dāng)你進(jìn)入這個(gè)隊(duì)列內(nèi)部查看，發(fā)現(xiàn)其實(shí)是一個(gè)真正的單個(gè)數(shù)據(jù)結(jié)構(gòu)：一個(gè)ring buffer. 每個(gè)生產(chǎn)者和消費(fèi)者都有一個(gè)次序計(jì)算器，以顯示當(dāng)前緩沖工作方式.每個(gè)生產(chǎn)者消費(fèi)者寫入自己次序計(jì)數(shù)器，能夠讀取對(duì)方的計(jì)數(shù)器，生產(chǎn)者能夠讀取消費(fèi)者的計(jì)算器確保其在沒有鎖的情況下是可寫的，類似地消費(fèi)者也要通過計(jì)算器在另外一個(gè)消費(fèi)者完成后確保它一次只處理一次消息。

#p#

輸出disruptors也類似于此，但是只有兩個(gè)有順序的消費(fèi)者，轉(zhuǎn)換和輸出。輸出事件被組織進(jìn)入幾個(gè)topics, 這樣消息能夠被發(fā)送到只有感興趣的topic中，每個(gè)topic有自己的disruptor.

disruptor不但適合一個(gè)生產(chǎn)者多個(gè)消費(fèi)者，也適合多個(gè)生產(chǎn)者。

disruptor設(shè)計(jì)的好處是能夠容易讓消費(fèi)者快速抓取，如果發(fā)生問題，比如在15號(hào)位置有一個(gè)轉(zhuǎn)換問題，而接受者在31號(hào)，它能夠從16-30號(hào)一次性批量抓取，這種數(shù)據(jù)批讀取能力加快消費(fèi)者處理，降低整體延遲性。

ring buffer是巨大的: 輸入2千萬號(hào)槽；4百萬輸出. 次序計(jì)算器是一個(gè)64bit long 整數(shù)型，平滑增長(zhǎng)(banq注：大概這里發(fā)現(xiàn)了JVM的偽共享)，象其他系統(tǒng)一樣disruptors過一個(gè)晚上將被清除，主要是擦除內(nèi)存，以便不會(huì)產(chǎn)生代價(jià)昂貴的垃圾回收機(jī)制啟動(dòng)(我認(rèn)為重啟是一個(gè)好的習(xí)慣，以便你應(yīng)付不時(shí)之需。)

日志工作是將事件存儲(chǔ)到持久化介質(zhì)上，以便出錯(cuò)是重放，但是他們沒有使用數(shù)據(jù)庫來實(shí)現(xiàn)，而是文件系統(tǒng)，他們將事件流寫到磁盤上，在現(xiàn)代概念看來，磁盤對(duì)于隨機(jī)訪問是非常慢，但是對(duì)于流操作卻很快，也就是說，磁盤是一種新式的磁帶。

之前我提到LMAX運(yùn)行在集群多個(gè)系統(tǒng)拷貝能夠支持失敗回復(fù)，復(fù)制工作負(fù)責(zé)這些節(jié)點(diǎn)的同步，所有節(jié)點(diǎn)聯(lián)系是IP廣播, 這樣客戶端能夠不需要知道主節(jié)點(diǎn)的IP地址. 只有主節(jié)點(diǎn)直接聽取輸入事件，然后運(yùn)行一個(gè)復(fù)制工作者，復(fù)制工作者將把輸入事件廣播到其他次要節(jié)點(diǎn). 如果主節(jié)點(diǎn)當(dāng)機(jī)，心跳機(jī)制將會(huì)發(fā)現(xiàn)， 另外一個(gè)節(jié)點(diǎn)就成為主節(jié)點(diǎn)，開始處理輸入事件，啟動(dòng)復(fù)制工作者，每個(gè)節(jié)點(diǎn)都有自己的輸入disruptor這樣它有自己的日志處理和格式轉(zhuǎn)換。

即使有IP廣播，復(fù)制還是需要的，因?yàn)镮P消息是以不同順序到達(dá)不同節(jié)點(diǎn)，主節(jié)點(diǎn)提供為其他處理提供一個(gè)確定順序。

格式轉(zhuǎn)換unmarshaler是將事件從其消息格式轉(zhuǎn)換到Java對(duì)象，這樣才能在業(yè)務(wù)邏輯處理器中使用，不同于其他消費(fèi)者，它需要修改ring buffer中的數(shù)據(jù)以便能夠存入這個(gè)被轉(zhuǎn)換好的Java對(duì)象，這里有一個(gè)規(guī)則：并發(fā)地每次只有一個(gè)消費(fèi)者能夠運(yùn)行寫入，這實(shí)際上也符合單一寫入者原則。

disruptor組件可以用在LMAX系統(tǒng)以外，通常金融財(cái)務(wù)公司對(duì)他們的系統(tǒng)都保持隱秘，但是LMAX能夠開源，我很高興，這將允許其他組織使用disruptor，它也將允許其他人對(duì)其進(jìn)行并發(fā)性能測(cè)試。
(banq注：disruptor看來是一種特殊的消息組件類似JMS東西)。

隊(duì)列和機(jī)制偏愛的缺乏

LMAX架構(gòu)引起了人們的關(guān)注，因?yàn)樗且粋€(gè)非常不同的方式接近的高性能系統(tǒng)。到目前為止，我已經(jīng)談到了它是如何工作的，但沒有太多深入探討了為什么它是這樣。這個(gè)故事本身是有趣的，意識(shí)到他們是有缺陷的。

許多商業(yè)系統(tǒng)都有自己的核心架構(gòu)師，通過事務(wù)性數(shù)據(jù)庫實(shí)現(xiàn)多個(gè)會(huì)話事務(wù)(banq注：如EJB或Spring JTA等等)，LMAX團(tuán)隊(duì)也熟悉這些知識(shí)，但是確信這些不合適他們的系統(tǒng)。這個(gè)經(jīng)驗(yàn)是建立在LMAX母公司Betfair上 – 這是一家體育博彩公司，它處理很多人的體育投賭事件，這是一個(gè)相當(dāng)大的并發(fā)訪問，傳統(tǒng)數(shù)據(jù)庫機(jī)制幾乎無法應(yīng)付，這些讓他們相信必須尋找另外一個(gè)途徑來突破，他們現(xiàn)在接近目標(biāo)了。

他們最初的想法為獲得高性能是使用現(xiàn)在流行的并發(fā)。這意味著允許多線程并行處理多個(gè)訂單。然而，在這種情況下是很難實(shí)現(xiàn)的，因?yàn)檫@些線程必須互相溝通。處理訂單變化的市場(chǎng)條件等都需要相互溝通。

早期他們探索了Actor模型和近親SEDA. Actor模型依賴于獨(dú)立，活躍的對(duì)象有其自己的線程，彼此之間是通過queue同學(xué)，很多人認(rèn)為這種并發(fā)模型比基于原始鎖的方式易于處理。

這團(tuán)隊(duì)就建立了一個(gè)actor模型原型，進(jìn)行性能測(cè)試，他們發(fā)現(xiàn)的是處理器會(huì)花費(fèi)更多時(shí)間在管理隊(duì)列，而不是去做真正應(yīng)用邏輯，隊(duì)列訪問成了真正瓶頸(banq注：Scala的Actor模型很有名，不知這是否算Scala致命問題，怪不得很少人談Scala的Actor模型了).

當(dāng)追求性能達(dá)到這種程度，現(xiàn)代硬件構(gòu)造原理成為很重要的必須了解的知識(shí)了，馬丁湯普森喜歡用的一句話是“機(jī)制偏愛”，這詞來自賽車駕駛，它反映的是賽車手對(duì)汽車有一種與生俱來的感覺，使他們能夠感受到如何發(fā)揮它到最好狀態(tài)。許多程序員包括我承認(rèn)我也陷入這樣一個(gè)陣營：不會(huì)認(rèn)為編程如何與硬件等底層機(jī)制交互是值得研究的。

現(xiàn)代的CPU延遲是影響性能的主導(dǎo)因素之一，在CPU如何與內(nèi)存交互，CPU具有多層次的緩存（一級(jí)二級(jí)），每級(jí)速度都明顯加快。因此，如果要提高速度，將您的代碼和數(shù)據(jù)加載到這些緩存中。

在某個(gè)層次, actor模型能夠幫助你，你能認(rèn)為actor可以作為集群節(jié)點(diǎn)，是緩存的自然單元。但是actors需要相互聯(lián)系, 這是通過隊(duì)列的- 而LMAX團(tuán)隊(duì)發(fā)現(xiàn)隊(duì)列會(huì)干擾緩存(banq注：JVM偽分享的問題)。

為什么隊(duì)列干擾了緩存呢？解釋是這樣的: 為了將數(shù)據(jù)放入隊(duì)列，你需要寫入隊(duì)列，類似地，為了從隊(duì)列取出數(shù)據(jù)，你需要移除隊(duì)列也是一種寫，客戶端也許不只一次寫入同樣數(shù)據(jù)結(jié)構(gòu)，處理寫通常需要鎖，但是如果鎖使用了，會(huì)引起切換到底層系統(tǒng)的場(chǎng)景， 當(dāng)這個(gè)發(fā)生后，處理器會(huì)丟失它的緩存中的數(shù)據(jù)。

他們得出的結(jié)論能夠獲得最好的緩存性能, 你需要設(shè)計(jì)一個(gè)CPU核寫任何內(nèi)存，多個(gè)讀是好的，處理器會(huì)非常快，而隊(duì)列失敗在one-writer原則。

這樣的分析導(dǎo)致LMAX團(tuán)隊(duì)得出一系列結(jié)論，導(dǎo)致他們?cè)O(shè)計(jì)出disruptor, 能夠遵循single-writer約束. 其次它導(dǎo)向留澳單個(gè)線程處理業(yè)務(wù)邏輯的新的目標(biāo), 問題是：一個(gè)線程如果從并發(fā)管理結(jié)構(gòu)中脫離出來(沒有鎖機(jī)制)，它到底能跑多快？

單個(gè)線程的本質(zhì)是：確保你每個(gè)CPU核運(yùn)行一個(gè)線程，緩存配合，盡可能的高速緩存訪問甚于主內(nèi)存。這就意味著代碼和數(shù)據(jù)需要盡可能的一致，. 保持小的代碼對(duì)象和數(shù)據(jù)在一起，以便允許他們能夠調(diào)入到一個(gè)高速緩存單位中或者輪換，簡(jiǎn)化高速緩存管理就是提高性能。

LMAX架構(gòu)的路徑的一個(gè)重要組成部分是使用了性能測(cè)試。基于actor模型的放棄也是來自于測(cè)試原型的性能。同時(shí)也為改善的各個(gè)組成部分的性能步驟，啟用了性能測(cè)試。機(jī)械同情是非常寶貴的的 – 它有助于形成假設(shè)什么可以改進(jìn)，并指導(dǎo)你前進(jìn) -最終測(cè)試提供了有說服力的證據(jù)。

兩段關(guān)于性能測(cè)試重要性，忽略…

你應(yīng)當(dāng)使用者架構(gòu)嗎？

這個(gè)架構(gòu)是適合非常小小眾，必須有很低的延遲獲得復(fù)雜大量的交易，大多數(shù)應(yīng)用并不需要6百萬TPS。

但是我對(duì)這個(gè)架構(gòu)著迷的原因是它的設(shè)計(jì)，它移除了很多其他大多數(shù)編程系統(tǒng)的復(fù)雜性，傳統(tǒng)圍繞事務(wù)性的關(guān)系數(shù)據(jù)庫會(huì)話并發(fā)模型是不是免費(fèi)的麻煩？ (banq注：因?yàn)槎颊莆斩贾酪簿褪敲赓M(fèi)的) 通常與數(shù)據(jù)庫打交道都有不尋常的付出和努力，對(duì)象/關(guān)系數(shù)據(jù)庫映射ORM工具Object/relational mapping tools能夠幫助減輕不少這種痛苦，但是它不能解決全部問題，大多數(shù)企業(yè)性能微調(diào)還是要糾結(jié)于SQL.

現(xiàn)在你能得到服務(wù)器更多的主內(nèi)存，比我們過去這些老家伙得到的磁盤還要多，越來越多應(yīng)用能夠?qū)⑺麄兊墓ぷ魅恐糜趦?nèi)存中，這樣消除了復(fù)雜性和性能低問題. 事件源驅(qū)動(dòng)Event Sourcing提供了一種內(nèi)存in-memory系統(tǒng)的解決方案, 在單個(gè)線程運(yùn)行業(yè)務(wù)解決了并發(fā). LMAX 經(jīng)驗(yàn)建議只要你需要少于幾百萬TPS，你就有足夠的性能提升余地。

這里也是相似于CQRS. 一種事件驅(qū)動(dòng), in-memory風(fēng)格自然的命令系統(tǒng)(盡管LMAX當(dāng)前沒有使用CQRS.)

那么表示你是不是不應(yīng)該走上這條道路呢？始終存在這樣鮮為人知的棘手的技術(shù)問題，這個(gè)行業(yè)需要更多的時(shí)間去探索它的邊界(注：老子思想的繳啊)?；境霭l(fā)點(diǎn)是鼓勵(lì)有自己特點(diǎn)的架構(gòu)。

一個(gè)重要特點(diǎn)是處理一個(gè)交易總是潛在地影響其后面的處理方式，因?yàn)榻灰卓偸窍嗷オ?dú)立的, 因?yàn)楹苌傧嗷f(xié)調(diào)，那么使用分離單獨(dú)處理器分別處理并發(fā)運(yùn)行也許更加有吸引力。

LMAX指出了“事件”概念是如何改變世界(banq注：hold住事件，而不是hold住數(shù)據(jù)，你就上了一個(gè)新層次，擺脫低級(jí)趣味的數(shù)據(jù)庫癖好)。 許多網(wǎng)站使用原有的信息存儲(chǔ)系統(tǒng)，然后渲染各種能夠吸引眼球的效果. 他們的架構(gòu)挑戰(zhàn)就是如何正確使用緩存。

LMAX另外一個(gè)特點(diǎn)是這是一個(gè)后臺(tái)系統(tǒng)，有理由考慮如何在一個(gè)交互模型中應(yīng)用它，比如日益增長(zhǎng)的Web應(yīng)用，當(dāng)異步通訊在WEB應(yīng)用越來越多時(shí)，這將改變我們的編程模型。

這個(gè)改變會(huì)影響很多團(tuán)隊(duì)，大多數(shù)人傾向于認(rèn)為同步編程，不習(xí)慣于異步處理。異步通訊是必不可少的響應(yīng)工具，在javascript世界已經(jīng)廣泛使用，如 AJAX 和 node.js, 這些鼓勵(lì)人們研究這些風(fēng)格. LMAX團(tuán)隊(duì)發(fā)現(xiàn)雖然要花費(fèi)一定時(shí)間來適應(yīng)異步編程模型，但是一旦習(xí)慣就成為自然，特別是錯(cuò)誤處理上容易得多。

LMAX團(tuán)隊(duì)當(dāng)然感覺到花力氣協(xié)調(diào)事務(wù)性關(guān)系數(shù)據(jù)庫的日子已經(jīng)屈指可數(shù)(banq老淚縱橫啊，05年喊出了數(shù)據(jù)庫時(shí)代的終結(jié)，08年我就喊出數(shù)據(jù)庫已死，被國內(nèi)很多大牛譏笑為瘋子) 。你可以使用一種更加容易方式編寫程序而且比傳統(tǒng)集中式中央數(shù)據(jù)庫運(yùn)行得更快，為什么視而不見呢？

分享題目：小延遲大吞吐：LMAX架構(gòu)
文章網(wǎng)址：http://www.dlmjj.cn/article/ccsggdo.html