大型網站技術架構 筆記

大型網站架構演化

特色：

高併發、大流量

高可用

海量數據

用戶分佈普遍、網絡狀況複雜

安全環境惡劣

需求快速變動、發佈頻繁

漸進式開發

演化發展歷程

0. 演變緣由

    在現有架構下，咱們來看看數據存儲的瓶頸是什麼？
     數據量的總大小  一個機器放不下
數據的索引（B+ Tree）一個機器的內存放不下 
訪問量（讀寫混合）一個實例不能承受
            只有當以上3件事情任何一件或多件知足時，咱們才須要考慮往下一級演變。

1. 初始階段：

應用程序、數據庫、文件都在一臺服務器，如經常使用的Linux+PHP+Apache+Mysql

2. 應用服務和數據庫分離

緣由：性能變差、存儲空間不足

三臺服務器：應用服務器（運算能力：CPU）、文件服務器（更大的存儲）和數據庫服務器（更大的存儲和內存）

3. 使用緩存改善

緣由：數據庫訪問壓力太大； 數據訪問遵循2-8定律

將訪問多的20%的數據放在緩存上，可分爲應用服務器端的本地緩存和分佈式的遠端緩存

4. 應用服務器集羣

緣由：單一服務器處理的請求連接成爲瓶頸

使用應用服務器集羣，使用反向代理實現負載均衡、可用性監測、可伸縮的實現

5. 數據庫讀寫分離

緣由：使用緩存後，仍有部分讀操做和所有寫操做要訪問數據庫，隨着規模的增大，這些操做形成數據庫瓶頸

數據庫進行主從備份和讀寫分離

6. 使用反向代理和CDN加速網站響應

緣由：加速網站訪問速度

CDN: 部署到客戶端最近的網絡提供商的機房，用戶可從本身最近的網絡提供商獲取數據，多用於靜態內容如CSS、圖片等

反向代理：通常代理都是在客戶的瀏覽器端，而此處的代理是在網站端。 用戶請求先經過反向代理，反向代理若是緩存有用戶須要的資源則馬上返回，不然調用相應服務器

7. 使用分佈式文件系統

緣由：業務需求繼續增大

8. 使用分佈式數據庫

分庫：

分表：單表數據規模很是龐大時

9. 使用NoSQL和搜索引擎

特色：數據存儲和檢索愈來愈複雜

NoSQL對可伸縮的分佈式特性有很好的支持

10. 業務拆分

將網站拆分紅多個應用，每一個應用獨立維護

11. 分佈式服務

將共有業務（用戶管理、商品管理等）提取出來獨立部署，上層業務複用這些業務完成具體操做

大型網站架構模式

網站架構模式

分層

將系統分紅MVC層，對C進一步分紅service層和Dao層

注意：定義好層次邊界和接口

做用：便於合做開發和維護；方便分離部署

分割

對業務進行拆分，彼此之間低耦合，而後部署到單獨的應用服務器上

分佈式

分層和分割的主要目的就是爲了切分後的模塊便於分佈式部署

經常使用方案有：

1. 分佈式應用與服務：改善性能和複用

2. 分佈式靜態資源：如JS，CSS獨立部署並有獨立的域名

3. 分佈式數據和存儲：對傳統數據庫使用分佈式、採用NoSQL

4. 分佈式計算：MapReduce

集羣

在多個機器上部署單一模塊，提供擴展性、有效性、負載均衡的處理

緩存

條件：某些數據被頻繁訪問；數據在某個時間段內有效，不會很快過時

有如下方式：

CDN：離用戶最近，靜態資源

反向代理：網站的前段，靜態資源等

本地緩存：應用服務器本機

分佈式緩存

異步

使用消息隊列實現，單一應用服務器使用多線程之間的消息隊列實現異步；分佈式環境中使用分佈式的消息隊列實現異步

好處：下降耦合；加快響應速度；消除併發訪問高峯

冗餘

實現7*24小時服務，提升可用性

服務器集羣實現； 數據庫的冷、熱備份

自動化

發佈過程：自動化代碼管理、自動化測試、自動化部署、自動化安全檢測

運行過程：自動化監控、自動化報警、自動化失效轉移和回覆、自動化降級

安全

身份認證： 密碼和手機校驗碼

加密：登陸、交易和存儲的敏感數據

驗證碼：機器人程序攻擊網站

編碼轉換：XSS攻擊和Sql注入

過濾：垃圾信息和敏感信息

風險控制： 對交易轉帳等重要操做根據交易模式和交易信息進行

 

大型網站核心架構要素

性能

定義：用戶訪問的快慢

評價指標：響應時間，TPS，系統性能計數器

手段：

1. 瀏覽器端：頁面壓縮、瀏覽器緩存、合理佈局頁面、減小cookie傳輸、CDN、CSS放在上面和js放在最下邊

2. 應用服務器端：反向代理服務器、緩存、異步請求、集羣

3. 代碼層：多線程、改善內存管理

4. 數據庫端：索引、緩存、SQL優化、主從備份和讀寫分離、NoSQL數據庫

可用性

定義：能夠訪問的時間

評價指標：幾個9，如99.99%

手段：

1. 冗餘（應用服務器集羣、數據庫備份）

2. 軟件質量：預發佈驗證、自動化測試、自動化發佈、灰度發佈

伸縮性

定義：經過向集羣中加入服務器提升併發訪問和數據存儲需求

評價指標：是否容易添加新的服務器；新的服務器可否提供無差異服務；服務器數量是否有限制

手段：

1. 應用服務器集羣：服務器上不保存數據（無狀態）+合適的負載均衡設備

2. 緩存集羣：改進緩存路由算法：hash環

3. 數據庫集羣：路由分區將部署有多個數據庫的服務器組成一個集羣； NoSQL數據庫天生比較好

擴展性

定義：快速響應需求變化

評價指標：增長新業務，是否對現有產品透明無影響

手段：

1. 事件驅動：消息隊列實現

2. 分佈式服務：業務經過分佈式框架調用可複用服務

安全性

定義：現存和潛在攻擊手段的應對策略

瞬時響應：網站的高性能架構

網站性能測試

1. 不一樣視角的網站性能

1）用戶視角

   瀏覽器和服務器通訊時間+處理時間+瀏覽器解析響應數據的時間

2）開發人員視角

   應用程序自己和子系統的性能，有 響應時間、吞吐量、併發處理能力、系統穩定性等指標

3）運維人員視角

  關注基礎設施性能和資源利用率，如網絡帶寬利用率和服務器資源利用率等

  手段：建設優化骨幹網、定製的服務器、使用虛擬化技術優化資源利用率

2. 性能測試指標

響應時間：

   執行一個操做須要的時間

   測量方法：重複請求，如一個請求重複執行1萬次，求得單次平均訪問時間

併發數：

   同時訪問的請求數量

   測量方法：模擬併發用戶，在兩次請求之間加入隨機等待時間（思考時間）

吞吐量：

   單位時間內處理的請求數量，TPS（每秒事務數）

   併發小：吞吐量增長、響應時間小幅上升；併發逐漸增長：吞吐量降低、響應時間快速上升；併發達到崩潰點：吞吐量爲0，不響應

性能計數器

   描述服務器和操做系統性能的數據指標，如System Load（進程數和CPU數）、內存和CPU使用、對象與線程數

3. 性能測試方法

性能測試：以系統規劃初期的指標測試

負載測試：增長併發請求，直到多項性能指標達到臨界值

壓力測試：直到系統崩潰

穩定性測試：特定軟硬件條件下，給系統加載必定業務壓力，使系統運行一段時間

4. 性能優化策略

性能分析： 檢查各環節日誌——》檢查監控數據，關注內存、磁盤、網絡、CPU——》肯定是代碼問題、架構設計仍是系統資源不足

Web前段性能優化

瀏覽器訪問優化

1. 減小http請求

合併javascript css、圖片（若是每張獨有不一樣的超連接，可經過css偏移響應鼠標點擊操做，構造不一樣的URL）。

2. 使用瀏覽器緩存

設置http頭中的Cache-Control和Expires設定瀏覽器緩存

靜態文件變化後：改變js文件名並更新html文件中的引用

更新靜態資源時，採用批量更新的方法，好比更新10個圖標文件，應一個文件一個文件逐步更新，並有必定時間間隔

3. 啓用壓縮

可對html css javaScript啓動GZip壓縮，但會對服務器產生壓力

須要在 通訊和服務器資源間權衡考慮

4. CSS放在頁面最上面，JavaScript放在最下面

瀏覽器會在下載徹底部CSS後才進行頁面渲染，最好是把CSS放在頁面上邊

瀏覽器在加載Js後馬上執行，有可能阻塞整個頁面，所以js放在下面，但若是頁面解析時就要用到JavaScript的，放在下面就不太合適了

5. 減小cookie傳輸

靜態資源使用獨立域名，避免發送cookie

哪些數據須要寫入cookie要慎重考慮

CDN加速

用於對靜態資源的代理

反向代理

部署在應用服務器前邊，實現 安全過濾、緩存加速web請求、負載均衡

應用服務器性能優化

主要手段有緩存、集羣和異步

分佈式緩存

網站優化第必定律：優先考慮緩存優化

緩存實際是內存的hash表

1. 合理使用緩存：

1）頻繁修改的數據：讀寫比在2:1以上

2）沒有熱點的訪問

3）數據不一致和髒讀：設置失效時間、數據更新時當即更新緩存 

4）緩存可用性 

5）緩存預熱：新緩存上沒數據

6）緩存穿透：持續高併發地請求某個不存在的數據，會對數據庫形成很大壓力

2. 分佈式緩存架構

集羣

異步

使用消息隊列：減小響應延遲、平滑併發訪問波動；

須要對返回狀態作特殊處理，如訂單提交（等待消費者處理完後才顯示成功）等

代碼優化

1. 多線程

使用緣由：IO阻塞會釋放CPU； 多CPU每一個對應一個

多少線程： 啓動線程數=【任務執行時間/(任務執行時間-IO等待時間)】*CPU數

線程安全問題：對象是無狀態的；使用threadLocal 方法內對象；併發訪問資源時加鎖

2. 資源複用

開銷很大的資源，如數據庫鏈接、網絡鏈接、線程、複雜對象。有兩種模式：單例和對象池

3. 數據結構

字符串Hash散列算法：Time33算法： hash(i)=hash(i-1)*33+str[i]

類似的字符串hash值區別很大： MD5算法

4. 垃圾回收

有助於程序優化和參數調優，分爲stack和heap，堆空間分爲Young Generation（Eden  from  to）和Old Generation，新建對象在Eden，當Eden滿時，複製到from；Eden又滿了，將Eden和from——》to，下次Eden+to——》from，young都滿了就放到old，若是都滿了就觸發Full GC（時間比較長）

合理設置young 和 old大小，儘可能減小Full GC

存儲性能優化

機械硬盤 vs 固態硬盤

B+樹 vs LSM樹

RAID vs HDFS

萬無一失：網站的高可用性架構

可用性的度量和考覈

    可用性度量： 幾個9，如99.99%

    可用性考覈（對工程師的考覈）： 故障時間*故障權重

高可用的網站架構

    企業級採用昂貴的軟硬件，如IOE；互聯網更可能是PC級服務器、開源的數據庫和操做系統

    主要手段：數據和服務的冗餘備份和失效轉移。

高可用的應用

1. 無狀態應用服務器

         採用負載均衡軟件，通常都提供：心跳檢測可用性；失效轉移、負載均衡

2. 有狀態的應用服務器

         1）session複製：當服務器集羣規模下的時候可用。經過開啓web容器的session複製功能，讓每臺服務器上都有用戶session信息。 應用在集羣規模小的狀況下。

         2）session綁定：使用負載均衡軟件的源地址hash算法，保證同一IP的處理總在一臺服務器上。但使用較少，主要是可用性的問題，若是該機器done了，該用戶的session會丟失

         3）cookie記錄session：1）cookie大小限制；2）每次都要傳輸；3）關閉cookie訪問不正常；4）簡單易用；5）支持應用服務器的線性伸縮。 大部分網站或多或少使用。

         4）session服務器： 可用性高，伸縮性好，性能也不錯，信息大小又沒限制。 將服務器中session都放到獨立的session服務器統一管理，每次讀寫session時，都經過session服務器。經過對分佈式緩存、數據庫基礎上包裝實現。

高可用的服務

    1. 分級管理：  對不一樣的功能模塊進行分級，對於高優先級使用好的硬件，更快的相應速度；等訪問量大時，可關閉低優先級功能

    2. 超時設置：  設置調用的超時時間，當服務不可用或超時後，通訊框架報出異常，根據調度策略轉移到其餘服務器

    3. 異步調用：消息隊列

    4. 服務降級：訪問高峯期，拒絕低優先級服務

    5. 冥等性設計：請求從新發送時，保證統一請求重複調用和一次調用結果相同，好比轉帳（使用交易編號）

高可用的數據

    1. 冷備： 廉價； 不能保證數據一致性；可用來按期備份

    2. 異步熱備：只寫成功一份，其餘之間複製

    3. 同步熱備：同時向多個副本中寫入

    4. 失效轉移：失效確認（心跳檢測和訪問異常）——》訪問轉移——》數據恢復

    5. 庫表散列： 不一樣業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。

高可用網站的軟件質量保證

1. 網站發佈

每次關閉服務器集羣中的一小部分，發佈完後馬上能夠訪問。

使用發佈腳本實現

2. 自動化測試

Selenium 自動化測試技術

3. 預發佈驗證

4. 代碼控制

要求：發佈版本和開發版本互不影響

主幹開發、分支發佈：發佈時主幹出一個branch，若是該版本有bug，在分支上修改發佈，並將修改merge回主幹

5. 自動化發佈

6. 灰度發佈

天天只發布一部分服務器，觀察運行穩定沒有故障

網站運行監控

1. 數據採集

用戶行爲日誌收集：服務器端（web服務器）、客戶端（javascript）

性能監控

運行數據報告

統計：基於實時計算框架Storm的日誌統計和分析工具

2. 監控管理

系統報警

主動失效轉移

自動優雅降級

永無止境：網站的伸縮架構

伸縮性：當訪問量增長時，經過增長資源（服務器）能夠提升吞吐率

伸縮性設計是複雜的、沒有通用的、完美的解決方案

網站架構

根據功能進行物理分離實現伸縮

    一臺服務器——》數據庫分離——》緩存分離——》靜態資源從應用服務器分離

    縱向分離（按層分割）：網絡具體產品--可複用業務服務--基礎技術服務--數據庫

    橫向分離（業務分割）：網站前臺--買家前臺--賣家後臺

單一功能經過集羣實現伸縮

    條件：當隨着訪問量增大，即便分離到最小粒度的獨立部署，單一服務器也不能知足須要

應用服務器集羣

1. 若是是無狀態的，可使用負載均衡（請求分發，服務器可用性監測）

2. 負載均衡實現技術有：

    1. http重定向： 使用http request將用戶請求從新定向處處理服務器，優勢是簡單；缺點是兩次請求才能完成一次訪問，性能較差。重定向服務器可能成爲系統瓶頸。 http302會被搜索引擎斷定爲做弊。 實際使用中很少見

    2. dns域名解析：在DNS中實現負載均衡。優勢是負載均衡給了DNS實現簡單。能夠解析到用戶最近的服務器地址；缺點是當下線了某臺服務器不能當即反應。 實際中大型網站使用DNS做爲第一級負載均衡，到一樣提供負載均衡的內部服務器

    3. 反向代理： 反向代理服務器提供緩存資源、負載均衡的功能，須要部署雙網卡和雙ip，優勢是 和反向代理功能一塊兒部署比較簡單。缺點是反向代理服務器是全部請求和響應的中轉站，性能可能成爲瓶頸

    4. IP負載均衡：負載均衡服務器修改數據包中的目的IP地址實現。優勢較反向代理有更好的處理性能；缺點是全部請求都通過，數據吞吐量受限於網卡帶寬

    5. 數據鏈路層負載均衡：修改mac地址實現。使用最廣，linux平臺使用LVS(Linux Virtual Server)

3. 負載均衡算法

    輪詢：請求依次分發

    加權輪詢：根據服務器的硬件狀況加權

    隨機：好的隨機數自己就很均衡，若是硬件配置不一樣，可以使用加權隨機

    最少連接：記錄每一個服務器的鏈接數，新的請求分配到最少的

    源地址散列：對IP進行散列，使得該IP的上下文信息存儲在這臺服務器上，實現會話粘滯

分佈式緩存

1. 目標： 新加入的緩存使得已緩存的數據儘量能被訪問到

2. memchached 分佈式緩存集羣，其中路由算法很重要：

    1. 餘數hash： 緩存數據hashcode/服務器數目。 但添加新的緩存服務器就麻煩了，解決方案是 使用虛擬節點的一致性hash環

數據存儲服務器

1. 目標：相對於緩存，對數據的持久性（能存到硬盤）和可用性（能訪問到數據）要求更高

2. 關係型數據庫

    數據庫複製： 主從讀寫分離； 分庫（不一樣表在不一樣數據庫集羣，缺點是不能進行跨庫join）； 分表（產品有Amoeba和Cobar，Cobar可與mysql集羣使用）

    伸縮的實現：Corba的服務器使用負載均衡；Mysql（Cobar利用Mysql的數據同步功能進行數據遷移）

    沒法執行跨庫Join和事務

        避免事務或利用事務補償機制（分佈式事務）代替數據庫事務；分解數據訪問邏輯避免JOIN操做

        支持JOIN的，如GreenPlum，但延遲比較大

3. NoSql數據庫

    Apache 的HBase，依賴於可分裂的HRegion（數據塊）和HDFS（分佈式文件系統）。使用者無需處理

隨需應變：網站的可擴展架構

    擴展性： 對現有系統影響最小狀況下，能夠加功能，符合開閉原則

構建可擴展的網站架構

   軟件架構師最大的價值不是掌握多少先進技術，而在於具備將一個大系統切分紅N個低耦合的子模塊的能力，這些子模塊包括橫向模塊和縱向模塊。這種能力是專業的技術和經驗，對業務場景的理解，對人性的把握。

   核心思想是模塊化，並在此基礎上，下降模塊間的耦合性

   主要手段是分層和分割，模塊間經過分佈式消息隊列和分佈式服務聚合

利用分佈式消息隊列下降耦合性

事件驅動架構

    藉助事件完成模塊間合做，常見的是生產者消費者模式，最經常使用的分佈式消息隊列

    好處是：更好的響應延遲；平緩高峯壓力；

分佈式消息隊列

    ActiveMQ：除了實現分佈式消息隊列，在伸縮性（加入隊列服務器）和可用性（內存隊列滿後，寫入磁盤）也作了改善。

    避免系統當機形成消息丟失，會把發送成功的消息存儲在生產者服務器，等消息被消費者處理後才刪除消息。

分佈式服務

    縱向拆分：將一個大應用拆分爲多個小應用，部署爲單獨的web系統

    橫向拆分：將複用業務拆分後部署爲分佈式服務，新增業務調用這些服務

    縱向比較簡單，經過梳理業務將較少相關的業務剝離，使其成爲獨立的web應用。橫向不只要識別可複用的業務，設計服務接口，規範依賴關係，還須要一個完善的分佈式服務管理框架。

web service與企業級分佈式服務

    可整合異構系統和構件分佈式系統

    缺點： 臃腫的註冊和發現機制；低效的xml序列化；開銷相對較高的HTTP遠程通訊；複雜的部署和維護手段。

大型網站分佈式服務的需求

    服務註冊和發現

    服務調用

    負載均衡：對熱門服務如登陸或商品服務，須要部署在集羣上

    失效轉移

    高效的遠程通訊

    整合異構系統

    對應用最少侵入：儘可能使框架和業務獨立   

    版本管理：提供者升級接口發佈新版本服務，並同時提供舊版本服務，當請求者調用接口升級後才關閉舊版本服務。

分佈式服務框架設計

    開源的阿里的Dubbo

    描述：

       1. 消費者經過服務接口調用服務，服務接口經過代理加載服務，代理調用服務框架客戶端模塊，客戶端包括服務提供者列表、負載均衡、失效遷移服務

       2. 提供者提供服務管理容器註冊服務

       3. 支持多種通訊協議和序列化協議，使用NIO通訊框架，具備較高的網絡通訊性能

可擴展數據結構

    無需修改表字段就能夠新增字段，使用NoSql數據庫

利用開放平臺創建生態圈

    提供更多的增值服務，將API開放被第三方開發者使用

固若金湯：網站的安全架構

網站應用攻擊和防護

1. XSS攻擊

    跨站點腳本攻擊，有兩種，一種是反射性（在url中 ?<script src... >），一種是持久型XSS（將惡意腳本的請求保存到數據庫中，經常使用語論壇和博客）

    防範手段： 消毒（對提交的文本進行匹配替換，如<img src=  對<進行轉義)； HttpOnly（防止xss竊取cookie，即瀏覽器禁止頁面Javascript訪問帶有HttpOnly的cookie）

2. 注入攻擊

    須要對數據庫有所瞭解，經過開源（網站使用開源軟件搭建）；錯誤回顯（從錯誤信息猜想表結構）；盲注（猜想數據庫表結構）

    防範手段：消毒（可能注入的sql，如drop table  delete from等）；參數綁定（PrepareStatement， ？而不是連接字符串）

3. CSRF攻擊

    跨站點請求僞造：經過跨站請求，以合法用戶身份進行非法操做

    關鍵是識別請求者身份，防範手段：

表單token、

驗證碼（糟糕的用戶體驗，只在必要時使用，如支付交易）；

Referer check（檢查http請求頭的referer的請求來源，可用來實現圖片防盜鏈）

4. 其餘攻擊和漏洞

    Error code：得到異常信息，查找系統漏洞； 防範手段：專門的錯誤頁面

    html註釋： 發佈前自動掃描，去除html註釋

    文件上傳：防範手段：設置上傳文件白名單，只容許上傳可靠的文件類型；修改文件名；使用專門的存儲

    路徑遍歷：在url中使用相對路徑；防範手段：動態參數不包括文件路徑信息；其餘文件不適用靜態URL訪問

5. web應用防火牆

    處理網站攻擊的產品，開源的Web應用防火牆：ModSecurity

6. 網站安全漏洞掃描

    根據內置規則，構造具備攻擊性的URL請求模擬黑客攻擊行爲

信息加密技術和祕鑰安全管理

1. 單向散列加密

    不能逆轉獲得明文，字符串微小差異輸出差異很大，不一樣長度輸入獲得固定長度的輸出

    經常使用的有MD5 SHA

    用於密碼加密保存、生成信息摘要

2. 對稱加密

    算法簡單，效率高，系統開銷少，適合對大量數據加密；使用同一祕鑰，遠程通訊下如何安全交換祕鑰是個難題

    經常使用的有DES RC

    用於信息須要安全交換或存儲的場合，如Cookie加密、通訊加密等

3. 非對稱加密

    用於信息安全傳輸、數字簽名。

    在實際中，常會混合使用對稱加密和非對稱加密。先使用非對稱對祕鑰進行安全傳輸，再使用對稱進行信息加密和交換。 有時對一個數據兩次使用非對稱加密，可同時實現信息安全傳輸與數字簽名的目的。

4. 祕鑰安全管理

    寫到配置文件，線上和線下使用不一樣的

    加密算法放在應用系統中，祕鑰放在一個獨立的服務器，甚至作成一個專用的硬件設施

    祕鑰分片後存儲在多個服務器

信息過濾和反垃圾

1. 文本匹配

    敏感詞過濾： 正則表達式（敏感詞較少、提交的文本長度較短）；Trie樹（敏感詞較多、提交的文本長，如雙數組Trie算法）；多級Hash表（Trie中相同父節點的字放在Hash表中， 速度較快，浪費部份內存）

2. 分類算法

    數據挖掘：分類算法， 貝葉斯算法

3. 黑名單

    hash表，布隆過濾器

電子商務風險控制

1. 風險

2. 風控

    規則引擎： 將業務規則和規則處理分開，業務規則可配置

    統計模型：數據挖掘分類算法（當規則增長，出現規則衝突、難以維護時）

維基百科高性能架構

目標：業務簡單，大部分是讀操做

組成部分

   GeoDNS：將域名解析到離用戶最近的服務器

   LVS：Linux的開源負載均衡服務器

   Squid：Linux的開源反向代理服務器

   Lighttpd: 開源的應用服務器，更快速，更輕量，許多網站做爲圖片服務器

性能優化策略

1. 前端優化

請求先通過GeoDNS到達地理最近的CDN服務器，若是沒找到調用LVS到Squid服務器，若是緩存有則返回，不然經過LVS分發到Apache應用服務器集羣。

2. 服務端優化

代碼和數據結構（非特定）

3. 數據端優化

最主要手段是緩存，策略以下

1. 熱點特別集中的數據緩存到應用服務器的本地緩存

2. 緩存數據儘量是直接可用格式，如HTML格式

3. 使用緩存服務器存儲session對象

4. 數據庫以下優化

1. 更大內存

2. Master當機，關閉寫功能，將應用切換到Slave

秒殺系統架構案例

技術挑戰

    1. 對原有業務造成衝擊

    2. 高併發下數據庫、應用負載

    3. 忽然增大的服務器和網絡帶寬

    4. 防止秒殺前下單

應對策略

  1. 獨立部署

和原有業務部署在不一樣服務器，防止高併發拖垮整個網站

  2. 頁面靜態化

將商品詳情、描述靜態化到頁面

  3. 租借秒殺網絡帶寬

向運營商租借帶寬

  4. 動態生成隨機下單頁面URL

沒法在秒殺前訪問下單頁面的URL：加入服務器端生成的隨機數做爲參數，在秒殺開始前才能獲得

架構設計

   1. 控制秒殺購買頁面的點亮

秒殺商品頁面加入一個javascript引用，該javascript中加入秒殺是否開始的標誌和下單頁面URL的隨機數參數，該javascript使用隨機版本號，不可被瀏覽器緩存

當秒殺開始時，生成一個新的javascript文件並被用戶瀏覽器加載

   2. 容許第一個訂單提交

控制進入下單頁面入口，只有先提交的少數用戶可進入，後邊的用戶直接進入秒殺結束頁面

架構師領導藝術

架構師角色

    架構設計、軟件開發

    承擔一些管理職能：規劃產品路線、估算人力資源和時間資源

    安排人員職責分工，肯定計劃里程碑點、指導工程師工做、過程風險評估與控制

    與組內外各類角色溝通

架構師職場攻略

新員工tip

首先要作的是融入團隊，和你們打成一片。等熟悉狀況後，知道了水的深淺，再尋找突破口，擇機而動

新員工最不須要作的就是證實本身的能力

提出問題，尋求支持

對於問題，找到誰須要對可能發生的問題負責。要解決方案被接受，就必須找到問題負責者並願意支持他的人

提出問題tip

    1. 把個人問題表述成咱們的問題

    2. 給上司提封閉式問題，給下屬提開放式問題

        給上司提問題是但願獲得支持，給下屬提問題是爲了啓發他思考

    3. 指出問題而不是批評人

        在合做中出現問題，告訴問題存在和緊迫性

    4. 用贊同方式提出問題

        我很是贊同你的方案，不過我有一個小小的建議

解決問題tip

1. 在解決個人問題前，先解決你的問題

    在幫別人解決問題的過程當中，熟悉了狀況，解決本身的問題就駕輕就熟了

2. 適當的逃避問題

    對於不怎麼靠譜的問題和方案： 這個idea很好，改天組織個會議好好討論下