The largest single database on earth - Google Spanner.

我們繼續網際網路技術架構－分散式儲存。

上文大篇幅介紹了一些分散式儲存的理論，偏重理論。可別小看這些理論，Google的各個神器都是建立在這些理論之上，甚至整個Apache的大資料3劍客專案都是受惠於這些理論。難怪@Tiger大牛講Google靠的是一大批世界頂尖資料，物理，計算領域的Ph.D.，這些大神以及他們的Paper是Google為什麼是Google的原因，以及Google沒有開源為什麼依然強大的原因，其背後有著強大的基礎研究團隊。

總目錄

分散式儲存概述

分散式儲存特性 － 雜湊分佈/一致性雜湊分佈

分散式儲存協議 － 兩階段與Paxos

分散式檔案系統 － Google GFS

分散式鍵值系統－ Alibaba Tair

分散式表格系統－ Google BigTable /Megastore

分散式資料庫系統－MySQL Sharding, Google Spanner / F1

1. 分散式檔案系統

GFS Google檔案系統

提到分散式檔案系統，當然首推GFS了。GFS是Google分散式儲存的基石，所有的神器都是建立在分散式儲存之上的，如Google BigTable, Google Megastore, Google Percolator, MapReduce等。

GFS

GFS系統節點可以分為三種角色：GFS Master, GFS ChunkServer, GFS Client.

GFS檔案被劃分固定大小的資料庫，稱為Chunk, 由Master分配一個64位全域性唯一ID; ChunkServer(CS)以普通Linux檔案形式將chunk儲存在磁碟，為了HA, Chunk被replication，預設3份。

客戶端訪問GFS時，首先訪問Master，獲取CS資訊，之後再去訪問CS，完成資料存取。GFS目前主要用於MapReduce, Bigtable.

租約機制(Lease)

GFS追加的記錄大小從即是KB到幾十MB不等，為了避免Master變成系統瓶頸，GFS引入了租約機制，即將Chunk的寫操作授權給ChunkServer。擁有租約授權的CS稱為主ChunkServer。在租約有效期內，如60秒，對該chunk的寫操作都由主CS負責。主CS也可以在租約到期後，不斷向Master提出續約直到Chunk寫滿。

一致性模型

GFS支援一個寬鬆的一致性模型，GFS從相對需求以及簡單化層名考慮，設計成主要是為了追加append而不是為了改寫override的架構，如我們瞭解的

HBase。

看一下記錄追加的流程：

1）客戶端向Master請求chunk每個副本所在CS

2）Master返回客戶端主副本和備副本所在CS位置

3）客戶端將追加記錄傳送給每一個副本，CS會內部LRU結構快取這些資料

4）當所有副本都確認收到資料，客戶端接著發起一個請求控制命令給主副本

5）主副本把寫請求提交給所有副本。

6）備副本成功完成後應答主副本。

7）主副本響應客戶端。

其中，分為控制流與資料流。

容錯

1）Master容錯：

與傳統類似，通過操作日誌加checkpoint來進行。

2）CS容錯：

採用複製多個副本方式。

從GFS的架構可以看出，GFS是一個具有良好可擴充套件能力並可以自動處理各種異常的系統。Google的系統已開始就考慮瞭如河水平擴充套件，所以後續的系統能夠站在巨人的肩膀上，如Bigtable建構在GFS之上，Megastore, Spanner又在

Biigtable之上融合了關係型資料庫的功能，整個方案華麗，完美。

另外，Google的成功經驗反過來證明了單Master是可行的，簡化了系統同時實現了一致性。

2. 分散式鍵值系統

分散式鍵值類似於分散式表格模型Bigtable的一種特例。比較著名的有Amazon Dynamo, Memcache以及國內阿里的Tair系統。

前兩天有夥伴提到Tair, 那我們就以Tail來聊聊吧。

Tair分散式系統

Tair是阿里/淘寶開發的一個分散式鍵/值儲存系統，tair分為持久化和非持久化兩種方式。非持久化的tair可以看作一個分散式快取，持久化的tair將資料存放置磁碟，當然tair可以自動備份以避免磁碟損壞等問題。

系統架構：

同樣，Tair由一個Master和一系列Slave節點組成，稱之為Config Server作為整體的控制中心，而服務節點為可伸縮的Data Server。Config Server負責管理所有的data server， 維護其狀態資訊。Data Server則對外提供各種資料服務，並以心跳來將自身資訊反饋給config server。可以看到，Config Server是核心控制點，而且是單點，只有主－備形式保證其可靠性。

ConfigServer的功能

1) 通過維護和dataserver心跳獲知叢集中存活節點資訊

2) 根據存活節點的資訊來構建資料在叢集中的分佈表。

3) 提供資料分佈表的查詢服務。

4) 排程dataserver之間的資料遷移、複製。

另外ConfigServer實現了從配置檔案load進節點資訊，然後根據配置的資料分佈的桶和需要建立的資料備份數，建立資料分佈表，長度為桶數乘以備份數。如目前有1023個桶，備份3，所以長度為1023*3的陣列。陣列元素就是資料要儲存的主節點資訊，下標即桶號碼。其中後面的1023*2為備份節點資訊。為了負載均衡，主桶會盡量均勻分佈到所有節點，備桶則根據策略，如不同資料中心來分佈。

DataServer的功能

1) 提供儲存引擎

2) 接受client的put/get/remove等操作

3) 執行資料遷移，複製等

4) 外掛：在接受請求的時候處理一些自定義功能

5) 訪問統計

操作層面：

客戶端首先請求Config Server獲取資料所在Data Server， 之後向Data Server傳送讀寫請求。

負載均衡：

Tair採用分散式一致性雜湊演算法，可參考我們上一篇介紹，正所謂理論之基石。tair對於所有的key，分配到Q個桶，桶是負載均衡和資料遷移的基本單位。config server根據已定策略把每個桶指派到不同的data server，因為資料按照key做hash演算法，所以每個桶中的資料基本平衡。

如下圖：

一致性和可靠性：

分散式系統中的可靠性和一致性是無法同時保證的,因為有網路錯誤. tair採用複製技術來提高可靠性,並做了一些優化,當無網路錯誤的時候, tair提供的是一種強一致性.但是在有data server發生故障的時候,客戶有可能在一定時間視窗內讀不到最新的資料.甚至發生最新資料丟失的情況.

參考：http://tair.taobao.org/

3. 分散式表格系統

顧名思義，表格模型，多行多列，通過主鍵唯一標識。如始祖Google Bigtable

Google Bigtable:

基於GFS與Chubby的分散式表格系統，目標是解決讀取速度，許多Google資料如web索引，衛星影象資料都存放在bigtabe。

整體結構：

(row:string, column:string, timestamp:int64) -> string

RowKey為任意字串，長度小於64kb。整個資料按照主鍵進行排序，字典排序，如果域名的話通常使用反向變換來排序，這樣可以做到二級，子域名可以連續。

系統架構：

Bigtable

總體分為客戶端，主控伺服器和子表伺服器Tablet Server。 Bigtable把大表分割為100-200m的子表tablet。

Master:

管理所有子表tablet server，暴扣分配子表給子表伺服器，子表合併，以及接受子表分裂訊息，監控子表伺服器，以及在子表實現負載均衡與故障恢復。

Tablet Server:

子表伺服器，實現子表的裝載／解除安裝，以及表格內容的讀寫，合併，分裂。其服務的資料包含操作日誌及子表sstable資料，而資料保存於底層GFS中。

Chubby:

Google的分散式服務，zk的鼻祖。底層核心演算法就是我們上文提及的Paxos,即多數派達成一致，類似昨天的英國公投脫歐。Chubby作為整個bigtable的核心，如果發生故障，則整個bigtabe不可用。Chubby為了保持HA, 通常大型部署結構為兩地三資料中心五副本。

為什麼需要五個副本？

理論上3個數據中心就已經很高可用了,為什麼要選擇5個呢?假如只部署在3個數據中心,一個掛了後剩餘兩個必須不能掛,因為commit成功在Paxos協議裡需要至少2節點;但如果第二個節點又掛了此時就真的無法訪問了,為了高可用,所以選擇了5個數據中心節點.

Chubby在Bigtable中提供了／輔助了以下核心功能：

1）選取並保證同一時間有且只有一個主控伺服器master

2）儲存bigtable系統引導資訊

3）配合master發現子表伺服器載入與解除安裝

4）獲取bigtable的schema資訊以及訪問控制資訊

Bigtable

分為使用者表（User Table）, 元資料表（Meta Table）和根表（Root Table）。客戶段查詢時，首先訪問Chubby讀取根表位置，再從根表讀取所需元資料子表的位置。

複製與一致性：

Bigtable採用強一致性，同一時刻同一個子表只能被一臺tablet server服務，master需要來控制這種一致性，而這也是通過Chubby的分散式互斥鎖機制來保證的。

GFS + Bigtable兩層架構以一種優雅的方式兼顧系統的強一致和HA。底層的GFS是弱一致性，可用性和效能很好，但是多客戶追加可能會出現重複記錄等資料不一致問題；上層的Bigtable通過多級分散式索引使得系統對外表現為強一致。Bigtable最大優勢在於線性擴充套件，單機出現故障，可以將服務（1分鐘內）自動遷移到整個叢集。

Google Megastore:

Megastore在Bigtable的基礎上，提供了資料庫功能的支援，介於關係型資料庫與NoSQL之間的儲存。Google在其公開的Megastore論文中指出，傳統的關係型資料庫在Google已經被否定，如MySQL。昂貴的商業資料庫會大幅加大使用者在雲中大幅部署的總成本。

Megastore設計原理與精髓在於，能夠在廣域網中同步複製檔案寫操作，可接受的延時，支援資料中心的故障遷移。論文還透漏，目前Google以及有100多個生產應用Megastore作為儲存服務，其可靠度在99.99%-100%，並且平均讀取延遲小於萬分之一毫秒，寫入延遲100-400毫秒。

系統架構如下：

客戶端庫Megastore Library:

提供應用程式的介面，包括對映megastore操作到bigtable，事務及併發控制，基於Paxos的複製，將請求分發給複製伺服器，通過協調者快速讀寫。

複製伺服器Replication:

接受客戶端的使用者請求並轉發到所在機房的bigtable例項解決跨機房連線數過多的問題。

協調者Coord.

儲存每個機房本地的實體組是否處於最新狀態資訊，實現快速讀寫。

Megastore主要功能分為：對映Megastore到Bigtable; 事務併發控制；跨機房資料複製與讀寫優化。

操作流程：

首先解析使用者的SQL，接著根據使用者定義的Megastore資料模型將sSQL轉換為底層對應的Bigtable。

資料複製Replication：

資料拆分成不同的實體組，每個實體組內的操作日誌採用基於Paxos的方式同步到多個機房保持強一致性。實體組之間通過分散式佇列或者兩階段提交協議實現分散式事務。

如上圖所示，Megastore的資料複製是通過paxos進行同步複製的，即如果更新一個數據，所有機房都會進行同步更新，因為使用了paxos協議，所以不同機房真對同一條資料的更新複製到所有機房的更新順序都是一致的；同步複製保證了資料的實時可見性，採用paxos演算法則保證了所有機房的更新一致性。

Megastore主要創新：

1） 包括提出了實體組的資料模型，實體組內部維持了關係資料庫的ACID特性，實體組之間維持NoSQL弱一致性，創新的融合了SQL和NoSQL的優勢。另外實體組的定義規避了效能殺手Join。

2） 通過Paxos協議同時保證了高可靠與高可用，既可把資料強同步到多個機房，又做到發生故障時自動切換不影響讀寫服務。

分散式儲存系統有兩個目標：可擴充套件性 ＋ 全功能SQL在Megastore上基本實現了。當然，Megastore也有一些問題，其中一些來源於底層Bigtable，如單副本等等。實際上，在Google, Megastore已經過時，並重新開發了一套革命性的分散式系統Spanner用於解決這些問題。

4. 分散式資料庫

關係型資料庫彙集了計算機領域的智慧，也為如今網際網路，大資料做好了鋪墊。在網際網路時代，如何水平擴充套件是傳統關係型資料的最大挑戰。

MySQL Sharding

通常水平擴充套件的做法是應用層按照規則將資料查分到多個分片，分佈到多個數據庫節點，並引入一箇中間層應用來遮蔽後段的拆分細節。

同樣，在MySQL Sharding中也是類似：

如上圖，總體分為：應用端，中間層dbproxy叢集，資料庫組，元資料伺服器等。

1）應用端／客戶端：通過MySQL與客戶端互動，支援JDBC，使得原有單機資料庫無縫對接。

2）中間層dbproxy:解析客戶SQL，並轉發到後端資料庫。解析MySQL協議，執行SQL路由，過濾，讀寫分離，結果歸併，排序以及分組等。另外可以引入LVS（Linux Virtual Server）進行負載均衡。

3）資料庫組dbgroup：每個dbgroup由n臺數據庫機器組成，一臺master，剩餘為slave。master負責所有些事務及強一致讀，並複製到備機。

4）元資料伺服器：維護dbgroup拆分規則並用於dbgroup選主。dbproxy通過元資料伺服器拆分規則確定SQL的執行計劃。另外採用zk來實現多個副本HA。

值得注意的是，如果請求資料只涉及一個數據庫組，則中間層將請求轉發並等待返回結果給客戶端；如涉及多個數據庫分組，則由中間層將結果執行合併，分組，排序等操作後返回給客戶端，中間層協議與MySQL相容，所以透明於客戶端。

Google Spanner

終於到Google Spanner登場了，Google Spanne是Google全球級分散式資料庫儲存系統。Spanner的擴充套件性達到了全球級，可以擴充套件數百個資料中心，數百萬臺機器，上萬億行記錄。

Spanner使得分散式技術與資料庫技術有機的結合起來，分散式可擴充套件，而資料庫則類關係型資料模型。

重溫CAP理論：

上圖的CAP定理是指在網路可能出現分割槽故障的情況下，一致性和可用性不可得兼。例如在銀行等應用領域，一致性是非常重要的。又如我們熟知的MongoDB並不支援複雜的事務，只支援少量的原子操作，所以不適用於“轉帳”等對事務和一致性要求很高的場合。這就要求需要一個關係資料庫來對 交易進行過高級別的控制。

Spanner同時支援同步複製，多版本控制，以及跨資料中心事務，完全衝破CAP的枷鎖，在三者之間完美平衡。無論從學術還是工程，Spanner可謂一個劃時代的分散式儲存系統。Spanner能做到這些，Google使用GPS和原子鐘實現的時間API。這個API能將資料中心之間的時間同步精確到10ms以內。因此實現了功能：無鎖讀事務，原子schema修改，讀歷史資料無block。

Google F1 RDBMS

說到Spanner, 我們不得不提一下F1，賽車？Google研究院推出命名為F1的新資料庫，F1是Google全新建立的新RDBMS資料庫，作為一種混合型資料庫融合了BigTable的高擴充套件性和SQL資料庫的可用性和功能性。支援擁有伸縮性很強的資料庫，而不必轉向NoSQL。

如上圖，F1目前支撐著谷歌的AdWords核心業務, 而AdWords的後臺F1已經從MySQL分庫分表遷移到了Spanner。

F1系統架構及功能：

為什麼Google還需要F1,而不是都使用BigTable呢？因為BigTable提供的最終一致性，一些需要事務級別的應用無法使用。同時BigTable還是NoSql,而大量的應用場景需要有關係模型。就像現在大量的網際網路企業都使用Mysql而不願意使用HBase,因此Google才有這個可擴充套件資料庫的F1.而Spanner就是F1的至關重要的底層儲存技術。

Spanner資料模型

資料模型類似Megastore系統。Spanner的表是層次化的，最底層是目錄表directory，其它表建立時可以使用INTERLEAVE IN PARENT表示層次關係。其中目錄類似於megastore中的實體組，實際儲存時，會將同一個目錄的資料放到一起，同一個目錄的每個副本都會分配到同一臺機器。因此，針對同一個目錄的讀寫事物通常不會涉及跨機器，除非目錄非常非常之巨大。

Google全新設計了GFS 2- Colossus之上，主要改進了實時性，並支援海量小檔案。

Spanner基本概念

Universe:一個Spanner部署例項稱之為一個Universe, 目前全世界只有3個，一個用於開發，一個測試，一個線上。

Zones:每個zone屬於一個數據中心，而一個數據中心可以包含多個zone。跨zone通訊代價較高。

Universe Master:監控這個例項中的zone級別狀態資訊

Placement Driver: 提供跨zone資料遷移

Location Proxy:提供獲取資料位置資訊服務；

Spanserver: 提供儲存服務，類似於bigtable中的tablet server

Spanner也是通過Paxos協議實現跨資料中心多個副本的一致性。每個主副本所在的spanserver還會實現一個鎖用於併發控制。

TrueTime

為了實現併發，資料庫需要給每個事務分配全域性唯一事務ID。然而，在分散式系統中，很難生成全域性唯一ID。Google創意的選用了TrueTime機制。

TrueTime是一個提供本地時間的介面，可以同步全球時間。這個API的實現靠的是GPS與原子鐘。引入了兩種，是避免當GPS受到干擾失敗後，原子鐘則非常穩定，不會出現偏差。實際部署中，每個資料中心都需要部署Master機器，其它機器則需要Slave來從Master同步。

有了TrueTime, Spanner並可以控制併發，實現外部一致性，支援以下事務：

讀寫，只讀，快照讀，讀寫事務。

[Google2012] James C. Corbett, Jeffrey Dean, Michael Epstein, etc. Spanner: Google’s Globally-Distributed Database.OSDI’2012.

我們非常期望看到類似Spanner和F1的山寨開源產品。當然，在2014年以及去年2015年，我們看到一個類似於Spanner的開源專案，值得注意的是其作者是前Google員工，CockroachDB，中文叫蟑螂？打不死的小強。目前

CockroachDB已經推出Beta版本，並且獲得高額風投。

相關推薦

大型網際網路技術架構4－分散式儲存-II Google

The largest single database on earth - Google Spanner. 我們繼續網際網路技術架構－分散式儲存。 上文大篇幅介紹了一些分散式儲存的理論，偏重理論。可別小看這些理論，Google的各個神器都是建立在這些理論之上，

大型網際網路技術架構1－架構概述

上圖座標指向矽谷，最近開始研究網際網路分散式架構，風口浪尖，高大上；特與極客朋友們分享，共勉。 網際網路架構 近些年來，網際網路的高速發展，大資料時代，Booming Years，我們作為技術極客，需要跟得上節奏，趨勢。 1 大型網站特性 大型網站，無論是電

大型網際網路必備架構技術：高效能+分散式+開源框架+微服務

高效能、分散式架構 文末附免費學習資料！！！ 分散式架構思維 大型網際網路架構演進過程 架構師應具備的分散式知識 主流分散式架構設計詳解 分散式協調和分流 Zookeeper分散式環境指揮官 Nginx高併發分流進階實戰 非同步與訊息中介軟體 RabbitMq

分散式大型網際網路企業架構！

摘要: 開發工具 1.Eclipse IDE：採用Maven專案管理，模組化。 2.程式碼生成：通過介面方式簡單配置，自動生成相應程式碼，目前包括三種生成方式（增刪改查）：單表、一對多、樹結構。生成後的程式碼如果不需要注意美觀程度，生成後即可用。 技術選型（只列了一部分技術）

《大型網站技術架構：核心原理與案例分析》-- 讀書筆記 (5) ：網購秒殺系統

案例 並發 刷新 隨機 url 對策 -- 技術 動態生成 1. 秒殺活動的技術挑戰及應對策略 1.1 對現有網站業務造成沖擊 秒殺活動具有時間短，並發訪問量大的特點，必然會對現有業務造成沖擊。對策：秒殺系統獨立部署 1.2 高並發下的應用、

《大型網站技術架構》讀書筆記之六：永無止境之網站的伸縮性架構

映射 應對 方法 訂閱 知識 位置 n+1 轉換 bsp 此篇已收錄至《大型網站技術架構》讀書筆記系列目錄貼，點擊訪問該目錄可獲取更多內容。 首先，所謂網站的伸縮性，指不需要改變網站的軟硬件設計，僅僅通過改變部署的服務器數量就可以擴大或者縮小網站的服務處理能力。在整個互聯

大型站點技術架構（八）--站點的安全架構

aof 伸縮 構造 輸出 信息泄露 .net 隨著 必須 font 大型站點技術架構（一）--大型站點架構演化 大型站點技術架構（二）--架構模式 大型站點技術架構（三）--架構核心要素 大型站點技術架構（四）--站點的高性能架構 大型站點技術架構（五）--站

大型站點技術架構PDF閱讀筆記（一）：

coo fun function end 關系 spl 閱讀 each 數據庫 1、數據庫讀寫分離： 2、系統吞吐量和系統並發數以及系統響應時間之間的關系： 3、系統負載的概念： 4、反向代理的概念： 5、使用緩存來讀取數據：

軟件架構設計學習總結（13）：大型網站技術架構（七）網站的可擴展性架構

開放 擴展 修改 restfu 消息發送 封裝 nts 進行 可擴展性 擴展性是指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。 設計網站可擴展架構的核心思想是模塊化，並在此基礎上，降低模塊間的耦合性，提供模塊的復用性。模塊通過分布式部署，獨立

軟件架構設計學習總結（14）：大型網站技術架構（八）網站的安全架構

根據 知情 提交 pac 請求參數 用途 text 避免 信息加密 從互聯網誕生起，安全威脅就一直伴隨著網站的發展，各種Web攻擊和信息泄露也從未停止。常見的攻擊手段有XSS攻擊、SQL註入、CSRF、Session劫持等。 1、XSS攻擊 XSS攻擊即跨站點腳本攻擊（C

軟件架構設計學習總結（12）：大型網站技術架構（六）網站的伸縮性架構

可用性 name 偶數 發送 得到 合並 linux vi 可謂 性能 網站系統的伸縮性架構最重要的技術手段就是使用服務器集群功能，通過不斷地向集群中添加服務器來增強整個集群的處理能力。“伸”即網站的規模和服務器的規模總是在不斷擴大。 1、網站架構的伸縮性設計 網站的伸縮性

《大型網站技術架構》讀書筆記一：大型網站架構演化

硬件 解決方案 更新 獨立 流量 操作 大型網站技術架構 負責 思維導圖 一、大型網站系統特點 　　（1）高並發、大流量：PV量巨大 　　（2）高可用：7*24小時不間斷服務 　　（3）海量數據：文件數目分分鐘xxTB 　　（4）用戶分布廣泛，網絡情況復雜：網絡運營

《大型網站技術架構：核心原理與案例分析》【PDF】下載

優化 均衡 1.7 3.3 架設 框架 應用服務器 博客 分布式服務框架 《大型網站技術架構：核心原理與案例分析》【PDF】下載鏈接: https://u253469.pipipan.com/fs/253469-230062557 內容簡介 本書通過梳理大型網站技

閱讀《大型網站技術架構：核心原理與案例分析》第五、六、七章，結合《河北省重大技術需求征集系統》，列舉實例分析采用的可用性和可修改性戰術

定時 並不會 表現 做出 span class 硬件 進行 情況 　　網站的可用性描述網站可有效訪問的特性，網站的頁面能完整呈現在用戶面前，需要經過很多個環節，任何一個環節出了問題，都可能導致網站頁面不可訪問。可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指

《大型網站技術架構：核心原理與案例分析》結合需求征集系統分析

運行 模塊 正常 一致性hash 產品 進行 OS 很多 層次 閱讀《大型網站技術架構：核心原理與案例分析》第五、六、七章，結合《河北省重大技術需求征集系統》，列舉實例分析采用的可用性和可修改性戰術，將上述內容撰寫成一篇1500字左右的博客闡述你的觀點。 閱

大型站點技術架構閱讀筆記（二）

UC link style views body HR markdown img tle 1、 2、 3、 4、 5、 6、 7、

大型網站技術架構：摘要與讀書筆記

思想 發展 感覺 物理 消息隊列 高可用架構 小時 整體 年度 　　花了幾個晚上看完了《大型網站技術架構》這本書，個人感覺這本書的廣度還行，深度還有些欠缺（畢竟只有200頁左右）。但是作為一個缺乏大型網站技術的IT民工，看完一遍還是很有收獲的，至少對一個網站的技術演進

《大型網站技術架構：核心原理與案例分析》讀後感

TP bubuko 一個 nbsp 分享 架構 優化 技術分享 src 李智慧的著作《大型網站技術架構：核心原理與案例分析》，寫得非常好， 本著學習的態度，對於書中的關於性能優化的講解做了一個思維導圖，供大家梳理思路和學習之用。拋磚引玉。 《大型網站技術架構

一張圖讀懂大型網站技術架構

軟體架構師最大的價值不在於掌握多少先進的技術，而在於具有將一個大系統切分成N個低耦合的子模組的能力，這些子模組包含橫向的業務模組，也包含縱向的基礎技術模組。這種能力一部分源自專業的技術和經驗，還有一部分源自架構師對業務場景的理解、對人性的把握、甚至對世界的認知。 ----李智慧 以下為李

網購秒殺系統架構設計案例分析——《大型網站技術架構》筆記

一、核心思想： 網站秒殺時的併發比正常運營時多的多，所以網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用伺服器（否則造成巨大浪費），必須設計部署專門的秒殺系統，進行專門應對   二、技術挑戰： 1.對現有網站業務造成衝擊：秒殺活動只是網站營銷的一個附加活動，具有時間短