伴隨著計算機、網際網路等技術的發展，使用者對系統低延時的要求越來越高，**直播、****、社交類軟體、當前作為技術熱點的大資料處理，各行各類的應用都需要不斷優化其低延時架構。低延時系統架構優化經久不衰，其目的是提高使用者體驗，吸引客戶，並最終直接或者間接的創造價值。
一、低延時架構的核心思想及解決的問題
低延時系統架構不斷優化和發展，並呈現螺旋式上公升的狀態，其核心思想主要有三個： 1、
盡可能減少網路中轉環節，提高網路速度。減少跳點；增加頻寬，使用千兆、萬兆網絡卡，甚至infiniband。 2、
盡可能的提高資料處理速度，提高處理器速度，使用記憶體計算技術，使用平行計算等高效能處理技術。 3、
盡可能的減少磁碟io操作、同步操作等，以降低介面延遲。
在架構不斷優化的過程中，需要不斷解決的問題包括： 1、
資料可靠性。在儘量減少資料落地（不一定沒有）的情況下，保證資料不丟失。採用非同步寫磁碟、ha等技術保證資料可靠性。 2、
吞吐量。對大規模的資料應能保證資料處理速度，分布式計算的協調和架構。 3、
高可用、容錯等。
三低延時架構演化概述
低延時架構的演化是伴隨著計算機軟硬體行業的發展，各行各業的需求發展起來的，我們以**行業中的****為例，管中窺豹，來看一下低延時機構的演化歷史
1、
早期架構模型
在最初的硬體資源匱乏的年代，資料的接入處理發布都部署在一起，減少各種io操作，充分利用有限的資源，保證系統的執行。如圖1所示：
圖1最簡單模型
早期架構的演化中，更為成型的乙個系統架構模型如圖2所示，系統內各程序之間ipc程序通訊如共享記憶體技術等進行資料的互動，資料的接入部分引入緩衝佇列模型，以避免網路擁堵或丟包，同時具備緩衝功能，提高系統的吞吐壓力。比如流**模型中通過時間戳序列號等標識配合資料重傳等保證資料的可靠。
圖2早期通用的成熟架構
關於這一部分，筆者曾有幸拜讀過國內最早一代******系統的部分核心**，並曾與早在90年代便從事該行業的第一代程式設計師共事。在感嘆這位前輩職業精神的同時，更是感嘆這部分系統架構的魅力。所謂沒有最好的架構，只有最合適的架構，限於當時各種環境和資源，架構師要充分考慮系統的可用性和成本，對一點一滴細節的把握已經到了極致。主要體現在以下幾點：
第乙個是基於記憶體檔案的資料計算和管理。通過雜湊鍊錶的方式自組織記憶體資料，實現增刪改查等操作，同時通過記憶體檔案和磁碟檔案的對映機制，實現記憶體資料的持久化備份，並解決讀寫鎖機制等核心問題，這些實際都是記憶體資料庫的一種簡單實現，像fastdb等。極大提高資料計算和共享的速度。
第二個是高併發非同步服務框架。基於c、c++語言的非同步socket完成，實現穩定可靠的高併發的服務要求。在行業發展的過程中，出現的其他高效能網路框架如ace、libev等一直是資料類、遊戲類服務使用的基礎框架。使用c\s架構，並通過資料推送技術盡快的將有效資料傳送到客戶端。所有實時資料都是採用流的方式進行處理和傳送，這也是早期流式計算的雛形。即使在b\s大行其道的很長時間內，這種架構仍然是對低延時需求最合理的解決方案。在html5中出現的websocket技術，實際上是完善bs架構在實時資料方面表現的不足。
第四個是檔案系統。以低成本來完成資料的儲存和組織，並實現檢索和裝載等。和上述所有環節一起，不使用資料庫或第三方的軟體產品，第一是降低成本，第二便是部署運維簡單。當然，前提是系統具有強大的穩定性。
第五個必須要提強大的程式語言，c\c++。用最靠近系統底層、最高效的語言，完美實現上述四點。提供高效能和計算效率，提供低儲存結構。在這些系統的**中，處處可見儲存計算的優化，掩碼、位運算、二進位制傳輸、浮點型與長整形轉換，甚至部分核心模組採用組合語言。
2、
較為成熟的架構體系
早期的架構體現了其技術特點，也存在一些問題：系統的擴充套件性、開放性、資料的再利用，這些與過去興起的soa觀念看起來格格不入。隨著訊息中介軟體、記憶體資料庫、分布式計算等更多商業化產品或者更多網際網路技術的飛速發展，低延時系統主要呈現如下樣貌：
圖3成熟機構體系
訊息佇列中介軟體mq技術主要用於解決緩衝、解耦、資料可靠性、一致性等問題，並可通過發布訂閱等機制完成系統的分布式擴充套件和資料的分布式處理，可以提供峰值處理能力。訊息佇列產品眾多，商業化產品有ibm mq、tibco等，開源產品則層出不窮，各有優勢，如activemq、rabbitmq、zeromq，以及大資料處理中使用的kafka、rocketmq等技術。舉例來講，對資料可靠性要求不高，保證最快速度獲得最新資料的情形，tibco的rv產品無人能出其右，其組播機制能快速實現資料的分享，同時通過硬體產品、基於記憶體的訊息交換技術、infiniband技術等，始終走在低延時技術的前沿。而對資料可靠性等有一定要求的情形，ibm wmq、rabbitmq等具有較高的效率。關於訊息中介軟體技術的相關比較和分析，我們將在《低延時系統架構（二）訊息佇列技術分析》中進行**。
記憶體資料庫技術主要用於解決資料快取、組織與管理、提高查詢和訪問效率等。像關係型的包括oracle timesten，altibase、sap hana、ibm soliddb、開源的fastdb等。像非關係型基於kv的快取產品有redis、mongodb等。另外，分布式快取產品如gemfire等也逐漸開拓新的領域。記憶體資料庫比較的主要引數包括，資料量、資料讀寫速度、介面形式、資料持久化方式、與傳統資料庫的資料同步介面等。這部分工作我們將在後續進行**。
訊息佇列技術和記憶體資料庫技術的發展為低延時系統架構提供了技術基礎，極大的提公升了系統的可擴充套件性、穩定性、可靠性。在成熟的架構體系中，mq分布於各個環節之間，形成流式分布的形式，各節點即是消費者同時又是生產者，最終將結果資料等寫入記憶體資料庫。或直接通過實時的方式發布出去。
3 流式實時分布式計算架構體系
在後摩爾定律時代，伴隨資料吞吐量的增多、大資料處理的需求，分布式流式計算框架逐漸興起。大資料計算主要有批量計算和流式計算兩種形態，如何構建低延遲、高吞吐且持續可靠執行的大資料流式計算系統是當前亟待解決的問題，流式大資料所呈現出的實時性、易失性、突發性、無序性、無限性等特徵，在系統結構、資料傳輸、應用介面、高可用技術、可伸縮性、系統容錯、狀態一致性、負載均衡、資料吞吐量等方面提出了技術挑戰。
在第2節的架構體系之上，進一步考慮系統的吞吐，將分布式訊息佇列技術、分布式記憶體資料庫技術、分布式計算協調排程等技術進行綜合應用，便形成了流式計算的架構體系，在這個過程中出現了分布式訊息佇列如kafka技術、分布式協調框架如zookeeper等技術。其中值得一提的是zeromq，雖然它不是傳統意義的訊息佇列，但是為資料分發訂閱，流式處理等提供了很多可以擴充套件的模型，包括push|pull、pub|sub、forward、route等。通過ipc或者網路分發機制，實現了執行緒、程序、主機之間的彈性伸縮。
實時流式計算框架的代表主要有spark和storm。以storm為例，說明其流式特點，
限於篇幅，我們將於後續章節對流式計算技術進行詳細比較和分析。
一 架構基礎
1.1 系統與子系統 系統 一群有關聯的個體，根據某種規則運作，完成單個元件不能單獨完成的工作能力。1.2 模組與元件 模組 從邏輯的角度來拆分得到的單元。劃分模組的目的是職責分離。元件 從物理的角度來拆分得到的單元。劃分的目的是單元復用。1.3 框架與架構 框架 為了實現元件規範，提供規範的基礎功...
架構學習一 架構概要總覽
架構學習一 架構概要總覽1 架構的主要複雜點 高效能 高可用 可擴充套件 低成本 安全 規模 2 架構設計的目的 根據實際情況，選擇合適的技術方案。一味的套用大公司或者高大上的技術方案是不成熟，大概率會造成異常技術災難。架構設計首先要找到系統的痛點，針對此來進行設計。3 架構設計的主要流程 1 找到...
android 應用架構隨筆一（架構搭建）
1 拷貝積累utils以及pagertab類 3 定義baseactivity類 4 改寫mainactivity 5 定義布局檔案 6 定義basefragment類 7 定義fragmentfactory類 8 定義fragmentfactory類 9 定義子頁fragment 10 定義thr...