# Aeron：我們真的需要另一個消息傳遞系統嗎？ > 原文： [http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html](http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html)  我們真的需要 [另一個](https://www.youtube.com/watch?v=dq4aOaDXIfY) 消息傳遞系統嗎？ 如果它承諾使用創新的設計，以每秒一百萬微秒的延遲在機器之間以百萬微秒的延遲將數百萬條消息以一致的響應時間傳遞給大量客戶端，那么我們可能會做到。 這就是 [Aeron](https://github.com/real-logic/Aeron) （凱爾特神 戰斗，而不是主持人，盡管告訴搜索引擎），這是 [Todd Montgomery](https://twitter.com/toddlmontgomery) 團隊開發的一種新型高性能開源消息傳輸庫， 多播和可靠協議專家，編譯器優化專家 [Richard Warburton](http://insightfullogic.com/blog/) 和 [Martin Thompson [](https://twitter.com/mjpt777) ，這是面糊的表演黑幫。 聲稱 Aeron 已經在吞吐量方面擊敗了最好的產品，并且延遲匹配了最高達 90％的最佳商業產品。 Aeron 可以以每秒 600 萬條消息的速度推送 40 字節的小消息，這是非常困難的情況。 以下是馬丁在 Strangeloop 上對 Aeron 的演講： [Aeron：開源高性能消息傳遞](https://www.youtube.com/watch?v=tM4YskS94b0) 。 我將簡要介紹他的演講，并整合到本文末尾列出的信息源中。 Martin 和他的團隊處于令人羨慕的位置，擁有一個需要像 Aeron 這樣的產品的客戶，并愿意為其開發提供資金，同時也使其開源。 因此，在 GitHub 上運行 git [Aeron](https://github.com/real-logic/Aeron) 。 請注意，對于 Aeron 來說還處于初期，他們仍處于繁重的優化階段。 世界已經改變，因此端點需要前所未有的擴展。 這就是為什么馬丁說我們需要一個新的消息傳遞系統的原因。 現在是一個多面的世界。 我們擁有多核，多插槽，多云，數十億用戶計算，通訊一直在發生。 大量的消費者定期對要從同一發布者讀取的頻道進行搗亂，這會導致鎖爭用，排隊效應，從而導致吞吐量下降和延遲高峰。 我們需要一個新的消息庫來充分利用這個新世界。 [轉向微服務](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) 僅增加了需求： 當我們進入微服務世界時，我們需要從通信中獲得非常低且可預測的延遲，否則 [USL](http://www.perfdynamics.com/Manifesto/USLscalability.html) 的一致性部分將會出現 雨火和硫磺在我們的設計上。 使用 Aeron 的目標是保持事物的純正和專注。 到目前為止，我們所做的基準測試表明吞吐量和延遲方面的進步。 十分獨特的是，您不必在吞吐量和延遲之間進行選擇。 對于其他高端消息傳輸，這是一個獨特的選擇。 Aeron 使用的算法可提供最大的吞吐量，同時將直到飽和的等待時間最小化。 “許多通訊產品都是瑞士軍刀； [說](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/IMvQY_bCQf8J) Martin，這是了解 Aeron 的好方法。 它不是您習慣的全功能消息傳遞產品，例如 [Kafka](http://kafka.apache.org/) 。 Aeron 不保留消息，不支持有保證的傳遞，也不支持群集，也不支持主題。 Aeron 不會知道客戶端是否崩潰了，也無法從歷史記錄同步備份或從歷史記錄初始化新客戶端。 將 Aeron 置于心理矩陣中的最佳方法可能是將其作為面向消息的 TCP 替代品，并在其上寫入更高級別的服務。 Todd Montgomery [擴展了](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/XsKndzoR6ycJ) 的構想： Aeron 是 ISO 第 4 層協議，它提供了許多消息傳遞系統無法提供的功能，也沒有提供某些消息傳遞系統可以提供的功能.... 讓我稍微解釋一下所有典型的消息傳遞系統（不僅是 Kafka 和 0MQ）。 一種更多考慮 Aeron 適合何處的方法是 TCP，但是可以選擇可靠的多播傳送。 但是，這在一定程度上是有限的，因為 Aeron 在設計上也具有許多可能的用途，這些用途遠遠超出了 TCP 的功能范圍。 以下是一些要考慮的事項： Todd 繼續提供更多詳細信息，因此請繼續閱讀文章以了解更多有關該主題的信息。 Aeron 的核心是 **復制的消息持久記錄** 。 通過非常有意識的設計過程，消息從發布到接收的整個過程都是無等待的，零復制。 這意味著延遲非常好并且非常可預測。 總結 Aeron 簡而言之。 它是由一支經驗豐富的團隊創建的，使用了以前許多項目中都得到強化的扎實的設計原則，并得到了并非所有人都擁有的技術支持。 每個方面都經過精心設計，干凈，簡單，高性能和高度并發。 如果說簡單與聰明是無法區分的，那么 Aeron 就有很多聰明之處。 讓我們看看他們是如何做到的... 請注意，Martin Thompson 的 [這個話題](https://www.youtube.com/watch?v=tM4YskS94b0) 正在進行中。 我盡了最大的努力來捕捉想法，但是您沒有得到的感覺就是它們融合在一起的程度。 馬丁在傳達這種整體感方面做得很出色，這就是為什么這次演講值得一看。 ## 其他 * *Todd Montgomery 繼續說。*。關于 Aeron 適合何處的一種思考方式是 TCP，但可以選擇可靠的多播傳遞。 但是，這在一定程度上是有限的，因為 Aeron 在設計上也具有許多可能的用途，這些用途遠遠超出了 TCP 的功能范圍。 這里有幾件事情要考慮： * 及時識別具有完整記錄邊界的“持久”數據流。 這是{channel，sessionId，channelId，offset，length}元組，它是日志緩沖區策略的核心。 這使得具有任意回放的流的非易失性存儲能夠掉出……這非常有趣。 這導致以真正機械的同情方式進行數據流的重新連接和持久化。 我對此壓力太大了。 實際上，這也為傳輸協議提供了真正的位置透明性。 即本地訂戶可以直接從發布者的日志緩沖區中讀取，而驅動程序則透明地將數據發送給現成的訂戶。 到目前為止，我們已經確定了這些內容，但是我認為這也可以應用于處理主動/被動前??向糾錯，輪播，任意重放等的獨特方法。 * Aeron 沒有主題。 它具有單獨的非競爭流。 大多數消息傳遞系統都提供主題空間。 這是一種祝福和詛咒。 通過為 Aeron 故意保留有界的實現方式（但不受設計限制）的流空間，Aeron 允許在頂部構建主題空間（這使 0MQ 和許多其他系統可以利用它）而不會將實現鎖定在浪費資源上 對于那些不需要它的用例。 * 可靠的單播設計是一種模仿 TCP 的熟悉的防火墻可穿越設計。 但是可靠的多播設計允許發布/訂閱語義具有無限可配置的流控制策略。 這不僅提供了普通的消息傳遞，流傳輸等各種用例可能性。 * 傳輸媒體已更改。 消息不再只是通過 TCP。 更多的多播正在發生。 Infiniband 正在高性能領域起飛。 [PCI Express](http://en.wikipedia.org/wiki/PCI_Express) 3.0 具有內置的內存模型，因此可以在計算機之間的總線之間傳輸字節。 這就是許多高性能空間的去向。 * 我們需要在同一臺機器上的進程和套接字之間進行通信。 隨著使用越來越多的內核構建機器，它們實際上成為了一個盒子中的數據中心。 英特爾的新款 [Haswell CPU](http://www.extremetech.com/computing/189518-intels-new-18-core-haswell-xeon-chips-will-try-to-preempt-the-arm-server-onslaught) 每個插槽具有 18 個內核，每個內核具有兩個超線程。 在一臺計算機上可能同時運行 240 個線程，我們需要一種方法來分工并有效地進行通信。 * 用純 Java 8 編寫，并利用了該版本新引入的 lambda 表達式。 * 對等而不是代理解決方案，這是它具有如此低的延遲的原因之一。 * 使用 UDP 并將很快擁有 SHM IPC 和 Infiniband。 * 構建高性能系統的秘訣在于簡單性。 復雜性會降低性能。 追求簡潔的簡潔設計。 * 通過提供替代算法提供帶有可插拔鉤子的自己的流控制。 * 不支持群集和存檔的消息，盡管將來的項目可能會添加一些此功能。 * 可靠的多播傳遞。 * Aeron 本質上將日志緩沖區從一臺機器復制到另一臺機器。 從功能上來說，緩沖區是持久的，因為存儲的記錄不會發生突變，也不會持久存儲到磁盤。 * 提供可靠的交貨，但不能保證。 如果訂戶死亡并超時，則將不會重試消息傳遞。 可以在 Aeron 之上分層協議以存檔已發布的消息，以便訂戶可以恢復，但這不在基本功能之內。 * 不提供交易擔保。 因此，要約完成后，當要約返回時，要么被拒絕，要么被放置在共享內存日志緩沖區中，由驅動程序發送。 在流量控制允許的范圍內，驅動程序會盡力發送。 但是，Aeron 確實盡力將其提供給訂戶。 這是一種盡力而為的傳遞保證，就像 TCP 一樣，但是要好一點，因為它可以處理 TCP 無法實現的某些連接故障。 但這并不能保證。 * 為了測試捕獲完整的等待時間直方圖，同時嘗試多個線程同時發布從而發生競爭的情況。 還要與許多其他消息傳遞因素進行比較。 例如 IPC /單播/多播，不同的消息大小等。 ## 基本操作 * 發布者通過一個頻道發送消息，供訂閱者閱讀。 頻道內是流向訂戶的流。 * 通道保持消息有序。 信息流彼此獨立，因此它們不會相互阻塞。 * 檢測到損失并以對延遲和吞吐量的最小影響進行處理。 * 使用流量控制和背壓以免淹沒客戶。 * 擁塞避免和控制處理經過擁塞網絡的數據包。 它被認為是高性能領域中的一項可選服務。 當發生擁塞時，需要此服務，但是在等待時間需要盡可能低的情況下，擁塞控制算法會使您減速。 一個示例是 TCP 的 [慢啟動](http://en.wikipedia.org/wiki/Slow-start) 問題，因為 TCP 試圖避免用流量淹沒網絡。 * 在處理非常大的消息，處理碎片并避免 [行頭阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) 的同時，在通道中對流進行多路復用和多路分解。 * 不是框架，而是圖書館。 這是一種可組合的設計，因此可以在其之上構建其他層。 * 設計大約涉及三件事：系統架構，數據結構和協議交互。 * 正確構建架構，并使其美觀整潔。 * 數據結構非常重要。 * 如今，人們不再強調良好的協議工作，這是分布式代理進行通信和合作時的基礎。 ## 架構 [ * 發布者發布，訂閱者訂閱。 您可以在兩臺計算機之間進行雙向通信，但是每臺計算機都需要分別注冊一個發布者和一個訂閱者。 一對發布者和訂閱者只是一種通信方式。 * 通信通過 UDP，UDP 多播，Infiniband，PCI-e 3.0，RDMA 等媒體進行。 * 發送者負責通過媒體發送數據，而接收者則通過媒體接收數據。 發送者和接收者是在各自的線程中運行各自工作的獨立代理。 現代處理器確實擅長于一遍又一遍地執行相同的操作，因為它們的高速緩存中存儲著指令和數據。 * 導體是獨立的代理，可以完成所有不在 A 和 B 之間發送字節的工作。這包括內部管理和管理員（如用戶設置，新出版物的事件，新的訂閱以及告訴系統正在發生的事情）。 * 發送方和接收方保持非常簡單和整潔，因此它們可以使用最佳方法在媒體上的兩點之間盡快傳輸數據。 * 在同一進程中沒有共享數據結構。 通信正在使用消息傳遞。 導體使用消息通過非阻塞結構進行通信。 這允許使用干凈的單線程代碼，該代碼可以運行得很快。 避免了并發和使用隊列的鎖定。 * 明確分開的關注點意味著可以選擇零件的放置位置。 它們都是獨立的代理程序，具有自己的線程，運行自己的代碼，具有自己的內部數據結構，這些數據結構不共享，因此它們不需要并發，不需要鎖，因此可以實現令人難以置信的執行 快速。 * 導體分為為發送者和接收者提供服務所需的內容以及為客戶端提供服務所需的內容。 而且由于通訊不使用共享內存，而是在隊列中，因此可以將 Conductor 的這些部分拆分為單獨的進程。 媒體驅動程序可以處于自己的進程中，客戶端可以處于其自己的進程中。 或者，媒體驅動程序可能位于內核中。 或在 FPGA 中。 ## 數據結構 * Java 中的數據結構過于復雜，間接性太多，這意味著性能低下，因此他們構建了自己的映射，IPC 環形緩沖區，IPC 廣播緩沖區，ITC 隊列，動態數組，日志緩沖區。 * 環形緩沖區用于在導體，客戶端和驅動程序之間進行通信。 * 還需要將事件從驅動程序發送到多個客戶端，而不會降低驅動程序的速度，而不考慮客戶端的數量，因此廣播用于事件。 * 許多數據結構在動態變化，例如給定訂閱的訂閱者數量，發布的發布者數量，這些數據結構必須是動態的且無阻塞的。 日志緩沖區用于將消息從發布移動到訂閱。 ## 永久日志 * 消息與標頭一起存儲在持久日志結構中。 （更多關于日志結構[在此處](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)的介紹）。 * 日志已映射到磁盤，但使用內存映射文件保存在內存中。 日志活在文件中，因為文件可跨進程使用。 文件被映射到內存中，從而避免了必須進行系統調用才能進入磁盤的過程。 * 不變的數據結構可以安全無鎖地讀取，因為它們會隨著時間增長。 * 描述了添加消息的協議和狀態機。 添加消息不涉及任何鎖。 * 首先，將尾部原子地向前移動，以便另一個線程可以在同一時間添加一條消息。 * 現在可以添加消息了。 該消息被復制到緩沖區。 * 為了表示一條消息已完成，將單個字操作寫入消息頭中的字段。 * 消息標頭已完全寫入日志，因此向發送方發送消息只需要編寫標頭和消息的連續字節，無需動態編寫，因此將消息發送至發布者非常有效 很多客戶。 * 日志不僅僅是隨時間增長的單個文件。 單一文件設計雖然很常見，但存在很多問題。 因為頁面錯誤會一直發生，并且頁面錯誤非常昂貴，這會增加 VM 壓力和頁面攪動（這是 [頁面錯誤成本](https://plus.google.com/+LinusTorvalds/posts/YDKRFDwHwr6) 上的 Linus Torvalds） ）。 頁面錯誤并沒有變得越來越快，過程也越來越快，因此差距是巨大的（盡管這一直是正確的，為什么頁面錯誤總是要避免的原因）。 * 單個文件方法的替代方法是保留三個緩沖區：干凈，臟，活動。 活動緩沖區是您正在寫入的緩沖區。 骯臟是永恒的歷史。 清除是下一個變為活動狀態的緩沖區。 導體可以在后臺進行清理，因此寫入它們不會造成等待時間的損失。 緩沖區在緩存中都很熱，因此沒有頁面緩存正在進行。 另一個線程可以將臟緩沖區存檔到另一個數據存儲中，以便可以永久保存消息。 * 這是免等待時間的實現方式。 假設有兩個編寫者試圖在兩個不同的線程中由兩個不同的發布者同時將消息 X 和 Y 寫入日志，可能是在不同的過程中寫入同一驅動程序。 由于驅動程序用盡了進程，因此可以在多個進程之間共享。 Y 贏得比賽以增加尾巴。 然后 X 遞增尾部，但是尾部越過緩沖區的末端。 Y 可以使用它分配的空間。 填充記錄放置在 Y 的末尾與緩沖區的末尾之間，因此緩沖區始終是連續且完整的。 X 負責旋轉到下一個緩沖區，在該緩沖區中它將消息從緩沖區的開頭寫入新的尾部。 所有這些工作并沒有導致線程的任何延遲。 它完全獨立發生，沒有阻塞操作。 如果某個進程中斷，則其他所有線程均不會阻塞。 ## 發送消息 ， * 標頭包含版本信息； 旗; 消息類型； 幀長 術語“偏移量”，即到緩沖區的偏移量，這是將其復制到另一端的位置； 會話 ID，流 ID； 條款 ID； 編碼的消息。 所需的所有內容都在標頭中，因此可以將其直接寫入網絡。 寫入幀長字節后，消息已發送。 * 標頭設計的有趣含義是，流中的每個字節在整個時間上都有唯一的標識符，這是 streamId，sessionId，termId，termOffset 的復合鍵。 稍后將使用此功能，以便接收者可以告訴發送者日志的哪個區域被刪除，因此發送者可以從該點重新發送。 * 使用消息協議在發送方和接收方之間復制日志。 發送方要發送消息時，會向接收方發送設置消息。 接收方發回狀態消息。 發送方開始向接收方發送數據。 接收方發送更多狀態消息，告訴發送方它還有 X 的剩余空間，因此您可以繼續發送。 消息不被確認，NAK 代替。 為了最小化[內爆效應](ftp://www-net.cs.umass.edu/pub/Rubenst98:Proact-TR-98-19.ps.gz)，大多數現代組播協議使用 NAK 代替 ACK。 接收者告訴發送者它還剩下多少空間，這比基于 ack 的方法所需的消息更少。 它為您提供了一種實現流量控制和背壓的機制。 * 發送方將其作為心跳發送的最后一條消息發送給接收方。 這種方法還可以處理丟棄最后一條消息的情況（請記住，正在使用 UDP）。 * 當接收者知道有一條消息被丟棄時，它將向發送者發送一個 NAK，用于查找丟失的術語區域。 在這一點上，請記住，正在復制的是日志，因此接收方可以假定整個日志可用，而不僅僅是很小的窗口大小。 * 接收者具有發送者中相同數據結構的副本。 標頭和消息被寫入日志。 有兩個計數器：已完成和高水位標記。 假設已寫入消息 1，消息 3 出現在消息 2 之前，因為存在訂購問題。 完成的計數器指向消息 1 的末尾。高水位標記指向消息 3 的末尾。消息 2 應該有一個孔。 已完成指向連續的消息流。 如果消息 2 到達完成，則向前移動以指向消息 3 的末尾。 * 使用這種方法，您無需保留遺漏郵件的跳過列表或歷史記錄中有空白的地方。 這些額外的數據結構很復雜，而且速度很慢。 它們導致并發問題和高速緩存未命中。 * 日志緩沖區在內存中是完全線性的。 訪問它們只需要向前邁進內存，這確實是硬件友好的。 指針追逐在性能上確實很糟糕，因為它們會導致頁面錯誤。 * 此表示形式也非常緊湊。 您可以通過記憶尖叫。 * 此設計是回到基礎的結果。 考慮如何解決丟失，重新排序，保留歷史記錄，同時保持內存和并發友好的問題。 結果是一個持久的數據結構，其速度比任何現有方法都要快。 [持久數據結構](http://en.wikipedia.org/wiki/Persistent_data_structure) 是一種數據結構，在修改后始終保留其自身的先前版本。 從軌道的功能角度來看，這是一個想法。 學科合作時，有很多東西要學習。 只執行功能性技術或忽略功能性技術是愚蠢的。 * 導體始終在完成和高水位線之間尋找間隙。 它將發送 NAK，因此發送方將重新發送日志的該部分。 這是簡單且易于調試的。 * 要了解消耗了哪些消息，請使用指向字節流中某個位置的計數器。 發布者，發送者，接收者和訂閱者都在字節流中保留位置計數器。 這使得監視，應用流量控制和擁塞控制變得容易。 這些計數器在另一個內存映射文件中可用，因此它們可用于單獨的監視應用程序。 * 協議很難。 您需要注意大規模的自相似行為。 例如，在多播世界中，當出現問題時，您會得到一種稱為自相似行為的信息，這種行為會開始發生模式并建立起共振。 因此必須將隨機性注入系統。 NAK 必須在將來的某個隨機點發送。 這樣可以防止訂戶立即全部錘擊源。 ## 吸取的教訓 [ * **人們以** n 估算值吸吮。 即使有團隊的豐富經驗，他們的估計也全都沒有了。 估算只是人類不擅長的事情。 * **構建分布式系統非常困難** 。 只有不想構建分布式系統的人才有資格構建一個分布式系統，因為他們至少對工作的辛苦程度有所了解。 您只是不能說嘿，讓我們創建一個分布式的并發系統。 首先制作一個單線程系統，然后再進行其余工作。 * **我們的防御代碼比特征代碼** 更多。 在分布式系統上，事情可能會大規模出錯，并且那些故障需要得到處理。 這并不意味著代碼中充滿了異常處理程序。 他們知道很多失敗案例，但是仍然有很多防御性代碼。 * **建立分布式系統是對** 的獎勵。 看到整個機器網絡針對注入的故障進行調整并全部得到糾正是一件很美好的事情。 * **從一開始就設計監視和調試** 。 從一開始就讓一切可見。 無鎖方法的優點之一是，您實際上可以從另一個線程觀察狀態，這使調試更加容易。 * **由于配置** ，我們將 3x-4x 的性能留在桌面上。 程序員和系統管理員的分離是一種反模式。 開發人員不會與沒有 root 訪問權限的人交談，而不會與擁有網絡訪問權限的人交談。 這意味著系統永遠不會配置正確，這會導致大量數據包丟失。 丟失，吞吐量和緩沖區大小都與 密切相關。 我們需要鍛煉如何彌合差距，知道參數是什么，以及如何解決它們。 因此 知道您的 OS 網絡參數以及如何對其進行調整 。 * **Java 的某些部分確實很爛** 。 無符號類型； NIO 系統布滿了鎖； 很難在沙盒模型中進行堆外工作并獲得所需的性能； 字符串編碼不應要求復制緩沖區三次； 有些人是成年人，讓我們映射和取消映射內存映射文件，并像成年人一樣使用套接字。 哈希圖周圍的垃圾回收問題是痛苦的； 或字節標志會將字節提升為整數，因此您無法將結果分配回一個字節； * **Java 的不錯部分** 。 工具。 Java 是世界上最糟糕的語言，擁有世界上最好的工具鏈：IDE，Gradle，HdrHistogram。 Java 的 lambda 和方法句柄非常好。 字節碼檢測對于調試確實很有用。 例如，Java 8 中的不安全性非常好，這就是計數器無鎖遞增的方式，并且可以在 CPU 上很好地擴展，并且內存柵欄使構建廣播緩沖區成為可能。 優化器很棒。 垃圾回收對于某些類的算法非常有用。 * **平均值絕對沒有意義** 。 注意百分位數。 ## 未來 [ * 現在功能已完成。 現在進行大量的分析和優化。 * 情況看起來很好。 在吞吐量方面已經擊敗了最好的產品。 可以以每秒 600 萬條消息的速度發送 40 字節的小消息，這是非常困難的情況。 時延看起來很棒，那里有最好的商業產品，高達 90％。 除了 90％的百分位數之外，還有很多工作要做，部分是基于算法，??還有 NIO，選擇器和鎖。 * 接下來是 C ++端口。 * Infiniband 和 IPC。 ## 相關文章 * [在 Reddit](http://www.reddit.com/r/programming/comments/2ml0gb/aeron_do_we_really_need_another_messaging_system/) 上/ [在黑客新聞](https://news.ycombinator.com/item?id=8619735)上 * [Aeron 高性能開源消息傳輸](http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf) * [Martin Ahompson 撰寫的“ Aeron：開源高性能消息傳遞”](https://www.youtube.com/watch?v=tM4YskS94b0) * [GitHub 上的 Aeron](https://github.com/real-logic/Aeron) * Aeron [協議規范](https://github.com/real-logic/Aeron/wiki/Protocol-Specification) 和 [設計概述](https://github.com/real-logic/Aeron/wiki/Design-Overview) 。 * [日志：每位軟件工程師應了解的有關實時數據統一抽象的知識](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying) * [Google：馴服長時間延遲的尾巴-當更多的機器等于更差的結果時](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) * [偉大的微服務與整體應用 Twitter 近戰](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) * [簡單二進制編碼](http://mechanical-sympathy.blogspot.com/) * [本周要去 Strangeloop 嗎？ 您的“必看”清單上有哪些講座？](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) * [Aeron 性能測試](https://groups.google.com/forum/#!topic/mechanical-sympathy/GrEce0gP7RU) * [策略：利用處理器親和力實現高性能和可預測的性能](http://highscalability.com/blog/2012/3/29/strategy-exploit-processor-affinity-for-high-and-predictable.html) * [12 種將吞吐量提高 32 倍，將延遲降低 20 倍的方法](http://highscalability.com/blog/2012/5/2/12-ways-to-increase-throughput-by-32x-and-reduce-latency-by.html) * [破壞了 4 個現代硬件神話-內存，HDD 和 SSD 真的是隨機訪問嗎？](http://highscalability.com/blog/2013/6/13/busting-4-modern-hardware-myths-are-memory-hdds-and-ssds-rea.html) * [對 Apache Kafka 進行基準測試：每秒 200 萬次寫入（在三臺便宜的機器上）](http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines) * [HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) -高動態范圍（HDR）直方圖。 非常感謝您提供大量信息來總結并做得很好，但是聲明“發布者和訂閱者之間的全雙工通信”并不是很準確。 發布者發布，訂閱者訂閱。 您可以在兩臺計算機之間進行雙向通信，但是每臺計算機都需要分別注冊一個發布者和一個訂閱者。 一對發布者和訂閱者只是一種通信方式。 另外，當您說“并非所有郵件都被確認”時，我們不會確認數據包。 我們使用 NAK 代替，我的理解是實際上大多數現代多播協議使用 NAK 代替 ACK 來最小化內爆效應。 太好了，謝謝理查德的改正！ “面對面”，認真嗎？ 是的，我猜這翻譯得不好。 它引用了猶他爵士樂團的約翰·斯托克頓（John Stockton），他是 NBA 歷史上最好的球員之一。 因此，這是一個受人尊敬的術語，這就是它的意思。