《深入淺出大型網站架構設計》第1章

第一章 網站架構概述

1.1 網站的基本元件

• 現在的網站在公司或組織中扮演者極其重要的角色，是公司或組織業務的線上版本，甚至是公司與使用者的主要介面。這些網站的使用頻率高，邏輯也極其複雜，所以有必要進行進一步的細分，以達到提升效能、靈活伸縮、更容易變更業務邏輯等的目的。
• 網站基本架構
  • 應用層：提供檢視和輕量前端服務
  • 服務層：提供後端複雜邏輯和計算服務
  • 資料層
    • 檔案伺服器
    • 資料庫伺服器

1.2 網站業務規模增長帶來的問題

• 所謂量變引起質變，對於一個系統來說，同一件事情，做一次造成的影響和做一百萬次造成的影響是完全不同的。
• 從技術的角度看，當一個網站隨著業務規模、業務種類的增長，承擔的流量越來越大時，會出現哪些問題呢？
  1. 當網站的業務變得複雜時，網站應用會有更復雜的計算需求。
  2. 一個事務的每個階段，它的資源佔用未必是一致的。
  3. 網站和伺服器就像平時使用的軟體和個人計算機一樣，它在程式碼本身沒有漏洞的情況下，依然有出錯的概率。

1.3 大型網站架構設計的目標和原則

• “高效能、高可用、高神所、高安全、高擴充套件”
• “高可用性、高併發性、高效能”
• 在實際應用種，很多時間不能簡單地歸類到某一類原則種，而是它們的綜合體。
• 不同的原則，它們遵循方式和實現手段也未必在一個維度上。

1.3.1 高效能(Performance)

• 衡量一個網站效能的主要指標可以分為以下兩個角度。
  • 從單個使用者或客戶都安的角度來看，就是單個請求（在保證正確的情況下）的響應時間（即延時），一般來說響應時間越短，效能越高。
  • 從網站建設和維護者的角度來看，除了每個請求的響應時間，還有每秒事務次數（Transaction Per Second, TPS），以及伺服器的效能指標，包括CPU使用率、記憶體使用率、IOPS（Input Output Per Second）等。TPS越高，效能越高。
• 而伺服器效能的衡量指標則是總體來說資源佔用越低，網站效能越高。
• 高效能：提高每個請求的響應速度，降低其資源消耗。

1.3.2 高可用(Availability)

• 當一個網站的可用性很高時，則意味著它在絕大多數的時候可以被使用者訪問，並且一些小規模的故障和以外不會影響它的可用性。
• 可用性：網站關鍵功能或API的呼叫成功率。
• 網站的可用性應該由部分伺服器或者邏輯元件出現故障時，網站業務是否多半可用來衡量。在實際生產中，依然要落實到API實時錯誤率之類的數值上。

1.3.3 伸縮性(Scalability)

• 伸縮，是指網站的伺服器叢集規模即一些其他的必需資源的增加與減少。
• 網站擁有者的資本是有限的，伺服器資源也是有限的。正常生產環境中的網站需要根據實際的需求，動態地變動自己擁有的伺服器，當預期流量增長時，新增伺服器，而當預期流量減少時，減少伺服器，這樣才能保證在所花費的成本沒有浪費的情況下，滿足所有網站的使用需求。
• 衡量網站伸縮性的指標如下：
  • 理想狀況下，在網站業務規模增長時，能夠通過直接新增足夠的伺服器來滿足未來的需求？
  • 理想狀況下，在網站業務規模縮小時，能夠通過直接減少伺服器削減所有有必要削減的成本？
• 伸縮性好的網站，在業務規模發生變化時，可以通過直接新增或減少伺服器來適應變化，並且能夠最小化成本的浪費。

1.3.4 擴充套件性

• 擴充套件性：業務和功能的擴充套件。
• 網站的擴充套件性是指一個網站需要支援新的功能和業務時，是否能夠很容易地新增支援。
  • 新增這個新功能，是否需要對已有程式碼或者架構進行大量的修改？
  • 新增這個新功能，假如在已有元件中已經有類似功能，是否需要從頭搭建類似的功能？
  • 新增這個新功能，有沒有可能對沒有被修改的網站元件造成影響？
  • 新增這個新功能，有沒有可能降低沒有被修改的網站元件的效能。
  • 回答“否”越多，網站的擴充套件性越好，反之擴充套件性越差。

《深入淺出大型網站架構設計》

第2章 大型網站架構設計的流程

2.1 需求分析

• 需要列舉出所有需求，並結合當前團隊的成本預算和技術實力設計出一個有效且符合實際的架構。

2.1.1 需求驅動的重要性

• 需求驅動是指將需求作為設計的原動力來決定設計的特點，以及應該側重哪些方面、捨棄哪些方面，當需求變動時，優先根據需求的變動量決定進行什麼樣的更新。
• 容易出現的問題：
  • 過於側重需求方面，而忽視了同樣重要的其他方面。
  • 設計能滿足當前需求，但是過於追求設計上的完美，從而需要花費遠多於滿足需求截止日期的時間，使專案處於錯過視窗期而可能失敗的境地。
  • 設計能滿足當前需求，但是對某些未來潛在且近在眼前的需求變動無法滿足，並且需要徹底重構。
  • 沒有與需求發起者，如產品經理溝通，而對某些需求產生了錯誤的理解。

2.1.2 如何根據需求制定系統目標

• 步驟
  1. 列舉出這個架構是為了誰而設計的，即使用者是誰。
  2. 列舉出每個型別的使用者的所有用例。
     • 用例（Use Case）是一個描述使用者如何使用這個系統的例子。規範寫法如：作為一個某類的使用者，我希望在做事情家時，能夠看見效果乙。
  3. 根據這些用例，對使用者進行優先順序的分類和排序。
     • 優先順序分類
       • 必須有的功能，一般稱為P0。P代表英文單詞Priority（優先順序）。
       • 初始釋出可以沒有，但是未來版本馬上需要有的功能，一般成為P1.
       • 有固然好，沒有也沒關係的功能，一般稱為P2。
     • 優先順序分類，促使設計者和產品經理或者任何需求的發起者進行深入溝通，從而發現一些之前沒有意識到的問題。決定了設計者設計的側重點。指導設計者如何迅速修改系統來滿足新的狀況。
  4. 根據P0制定當前架構必須具有的功能，根據P1制定當前架構必須沒有的瓶頸。
     • 設計者要指導系統必須滿足哪些功能。
     • 提醒設計者，由於成本限制、舊有系統的限制或者團隊自身能力的限制，當前設計出的架構未必是最完美的。

2.2 方案設計

2.2.1 與架構設計原則相結合

• “奧卡姆剃刀定律”：如無必要，勿增實體。
• 根據識別出的優先順序，結合網站的主要用例和流量特徵，決定需要有限考慮什麼原則。參考標準：
  • 對訪問模式比較頻繁的網站，我們需要儘量追求高效能、高併發。
  • 對業務實時性和可靠性要求高、訪問人群對服務質量敏感挑剔的網站，我們需要儘量追求高可用。
  • 對業務根據不同時間流量變化比較大的網站，我們需要儘量追求伸縮性。
  • 對業務變動頻繁、需要經常支援新用例或者淘汰老用例的系統，我們需要儘量追求擴充套件性。

2.2.2 設計多套備選方案

• 儘量設計多套方案以供選擇，越複雜的架構，使用的依賴越多。
• 複雜且潛在種種變動的需求：
  1. 列舉出所有不確定的部分。
  2. 做出假設。
     • 目的是不要讓不確定性阻止你的工作。
  3. 根據做出的假設，列出備選方案。
     • 備選方案需要有一個預備思想，以防意外出現時錯手不及。
     • 有時候你的主設計依賴於對某些隱患的暫時忽視，而當這些隱變成了真正的問題時，你能展示出你的“B計劃”。

2.3 方案評估

• 針對方案的評估和調整。
  1. 需要開一個設計的研討會議或者評估會議。
     • 整個團隊瞭解你的設計思路。
     • 有團隊中水平與你相當或高於你的人來參與評估。
     • 有需求發起者參與評估。
     • 好處是：第一，你能夠發現一些在設計過程中沒有意識到或遺漏的問題；第二，也可以通過對需求的再次回顧，在設計中精簡掉一些不必要的部分。
  2. 團隊在技術角度上認可了你的設計之後，需要對成本進行評估。
     • 這樣的架構需要使用其他服務嗎？例如，資料庫系統或者雲服務。
     • 這樣的架構需要使用多少臺伺服器？
     • 開發的週期需要多久？測試的週期需要多久？
  3. 在進行技術評估和成本評估，瞭解了資源的使用率之後，再次回顧設計，檢視有沒有可以取捨的部分。
     • 在技術評估的過程中，發現某一部分設計對團隊的技術能力要求過高，或者某一部分使用了極為昂貴的某類系統，則需要重新思考是否需要捨棄一部分設計中帶來的優勢，從而達到節約成本、降低實現難度等目的。

《深入淺出大型網站架構設計》

第3章 資料庫的選擇

3.1 關係資料庫

• 關係資料庫（Relational Database）

3.1.1 什麼是關係資料庫

• 關係資料庫由“表”構成。
• 每張表都有一個獨立且唯一的名字，而表中的每一行代表使用者儲存的值的聯絡。
• “關係”（Relation）就是指表。
• 所有的關係資料庫都有一個模式（Schema），模式是指資料庫的邏輯設計，就是資料庫表的定義。
• 規範的關係資料庫語言表示就是：成績（學號、姓名、成績）
• 在關係資料庫中，相同名字的屬性可以建立不同表之間的聯絡，以及相應的約束（Constraint）
• 需要對資料庫進行讀取、更新、寫入等操作，所謂的SQL（Structured Query Language，結構化查詢語言）
• SQL在對資料庫進行操作時，整個過程被成為一個事務（Transaction）。
• 成熟的關係資料庫產品，都一定會保證事務在執行過程中，所有出現的錯誤都能夠被正確地處理，不會出現由於SQL語句複雜，而出現數據不一致的情況。

3.1.2 關係資料庫的優勢和應用場景

• 關係資料庫特徵
  1. 使用者在對SQL熟練掌握的前提下，可在資料層直接對資料進行極為複雜的操作。
  2. 關係資料庫在完成資料操作時始終保持一致，而不會因為一些操作的錯誤或者先後順序問題讓某些請求讀到一些過時或者不正確的資料。這一般也被簡稱為關係資料庫的資料一致性。
  3. 對於資料記錄和寫入記錄的過程，關係資料庫可以進行資料的值驗證。
• 關係資料庫應用場景
  • 經常要對資料進行非常複雜或者繁所的操作的業務
  • 對資料操作的安全性和可靠性要求極高的業務

3.2 非關係資料庫

• NoSQL = Not Only SQL
• 非關係資料庫和關係資料庫並不是完全對立的關係，你中有我，我中有你的關係，各自的側重點不同。

3.2.1 什麼是非關係資料庫

• 非關係資料庫的核心是鍵值對（Key-Value Pair）。
• 非關係資料庫中新紀錄的鍵值可以自由輸入，即如果該非關係資料庫沒有特殊定義的話，新記錄中可以缺失舊記錄中的鍵值對，也可以有舊記錄中沒有的鍵值對。
• 關係資料庫中，記錄受到約束，在進行寫入、讀取等操作時，都經過了資料庫的層層處理保證它的強一致性，而非關係資料庫在沒有特別定義的前提下，這些操作都沒有相應的安全保證。
• 非關係資料庫的優勢
  1. 非關係資料庫容易擴充套件和更新，在變動時所需要進行的配置和程式碼變化是最少的。
  2. 非關係資料庫在所作事務相同、所使用的產品技術水平相當的情況下，一般比關係資料庫速度快。
  3. 非關係資料庫機會不需要開發者學習額外的內容，易上手。
• 非關係資料庫的使用場景
  • 需要快速開始開發並迭代的產品
  • 產品所用到的資料定義不確定、未來變動很大
  • 產品規模變動頻繁，資料層需要經常擴充套件
  • 資料規模較大，處理速度要求較高
• 如果要建設的網站沒有特殊的安全性或可靠性需求，一般簡易從非關係資料庫產品入手。

3.3 常見的關係資料庫產品

3.3.1 MySQL

• LAMP = Linux + Apache + MySQL +PHP
• 在現在新興的網站中，使用MySQL的網站已經逐漸變少了，因為同樣的使用場景，更多的公司願意城市使用非關係書庫，因為同樣簡便、輕量的需求下，非關係資料庫比MySQL所需的配置、學習成本都要低，而且效能更好。

3.3.2 MS SQL Server

• MS SQL Server是典型的商用、企業級關係資料庫，主要使用者也是中小型企業和組織，但是也有大型公司和商業用例使用它。
• 優勢：
  • 擁有強大的視覺化介面。
  • 與微軟技術棧的結合非常自然且緊密。從Windows伺服器、C#程式語言、.NET框架、IIS中介軟體到MS SQL Server。
• 缺點：
  • 使用MS SQL Server一般就要使用微軟的技術棧。
  • 由於使用全套的微軟商用產品價格交規，所以對於中小型公司和組織來說成本也是無法迴避的負擔。

3.3.2 Oracle

• Oracle的優勢，可靠性和安全性。如果網站的安全性要求極高，資料層要求非常健壯，那麼Oracle是最佳選擇。並且其錯誤恢復和日誌機制十分健全。
• Oracle的劣勢，需要一定的學習成本，領域知識特徵極強。

3.4 常見的非關係資料庫產品

3.4.1 MongoDB

3.4.2 DynamoDB

3.5 雲資料庫

• 第一，雲資料庫可以省去專門針對資料庫的部署和配置。
• 第二，雲資料庫的維護和伸縮都不需要使用者手動操作。
• 第三，大多數雲服務商都對雲資料庫提供了良好的配套監視系統。
• 無論是關係資料庫還是非關係資料庫，在網站開發者成本和條件允許的情況下，應當儘量使用雲服務，以減少編碼之外的工作量。

《深入淺出大型網站架構設計》

第4章 資料庫優化：分庫分表

• 資料庫在業務規模增長時，就需要對原先簡單的資料庫系統進行進一步的分割和優化。

4.1 什麼是分庫分表

• 資料庫從廣義上說就是一臺伺服器或者伺服器叢集。因此，當資料存量或者資料的吞吐量增大時，伺服器的負擔就會逐漸增加以至於影響讀/寫的效能和成功率。這時，就需要將資料庫進行切分。
• 如果將資料分散到多臺資料庫伺服器，則稱為分庫；
• 如果將一臺資料庫伺服器上的資料用多張表表示，則成為分表。

4.1.1 分庫

• 根據資料種類拆分：使用者、商品、訂單資料庫->使用者資料庫+商品資料庫+訂單資料庫

4.1.2 分表

• 分表之後，就得到了一張從業務邏輯上來說資訊更重要、讀取更頻繁的表和一張資訊不如前一張重要、讀取較少的表。

4.2 為什麼要進行分庫分表

4.2.1 吞吐量

• 資料量太大時，資料庫的效能會受到影響。資料量大有兩個方面：意識資料的吞吐量很大，即每次儲存或讀取的資料都很複雜或者很大；二是資料庫本身儲存的資料很多。

4.2.2 索引

• 當資料庫本身的資料量很大時，讀寫操作的效能也會下降，具體下降程度取決於資料庫的實現。同時，無論是關係資料庫還是非關係資料庫，都會有“索引”的概念。
• 索引在本質上也是一個數據庫表，只是經過了特殊資料結構或者演算法的調製，例如，很多資料庫中的索引是使用B樹實現的，比簡單的散列表在範圍查詢上速度要快得多，但再快的資料結構也不是魔法，當資料量達到一定程度時，執行速度依然會出現肉眼可見的下降。索引的本意就是為了加快查詢，如果索引的速度受到了影響。那麼資料庫的效能就更加不堪了。

4.2.3 備份

• 資料備份時指每隔一段時間對生產環境中的資料進行復制。它們不必時刻保持與實際資料同步，只需要保證一定的時效性。
• 如果生產資料的量極多，備份時所消耗的時間也會相應增大。
• 如果經過了分庫或者分表，就可以對不同的表採取不同的備份策略。

4.2.4 其他風險

• 資料量越大、資料越集中，發生其他問題導致資料損壞或丟失的風險越大，而發生問題時造成的問題也越大。

4.3 實現分庫分表

• 分庫分表的實現手段大致分為兩類：垂直和水平。

4.3.1 垂直分庫分表

• 垂直分庫分表適用於如下場景：
  • 表的列數過多。
  • 表中的資訊明顯屬於多個業務邏輯模組。
  • 表中的資訊重要程度差異明顯。
  • 表中的欄位大小差異明顯。
  • 表中的欄位訪問頻率差異明顯。
• 可根據業務邏輯，將庫分成幾個獨立的小庫。
• 垂直分表
  1. 迴歸本源，即網站的業務邏輯。根據業務邏輯分析，從邏輯和語義上看，有哪幾類資訊。
  2. 根據以下特徵進行進一步的分類。
     • 哪些是重要的，哪些是次要的。
     • 哪些是佔用空間大的，哪些是佔用空間小的。
     • 哪些是訪問頻率高的，哪些是訪問頻率低的。
  3. 根據分析後的結果，儘量將重要、佔用空間小和訪問頻率高的資訊分為一組，將相反的資訊分為另一組。
  4. 如果不能同時滿足多條特徵（即又重要、又佔用空間小、或者又重要、訪問頻率又高等），則優先從資料資訊本身的意義考慮分組。
• 分表之後，所有分出來的表都依然和原來的表共享一個唯一的ID。

4.3.2 水平分庫分表

• 水平分庫分表就是橫向切分一個庫或表，切分之後，分出來的庫或表依然保持原表的結構，但是儲存的是另一部分的資料。
• 水平分庫分表適用於以下場景：
  • 當前單庫或單表的資料行數過大，已經導致單庫或者單表的讀寫出現了效能下降。
  • 尚未出現效能瓶頸，但業務特徵導致資料庫規模（行數）會持續增長或大幅增長。
• 水平分表的解決方案
  1. 固定範圍
     • 優點：
       • 易於理解，易於實現。
       • 隨著業務和資料規模的增長，資料表均勻增長，理論上可以無限擴充套件。
     • 缺點：
       • 範圍的大小不易掌握，太大則重現了分庫分表前的問題，太小則造成了太多的子庫或子表，從而造成過重的維護負擔。
       • 在某些情況下，不同子庫或子表所承擔的資料量和吞吐量可能會極不均衡。
  2. 使用配置表
     • 優點：
       • 易於理解，易於實現。
       • 變動靈活，隨著業務和資料規模的增長，資料表的增長可以自由控制。
       • 當業務規模和資料規模需要變動時可以通過修改配置表的資料來進行快速的修改。
     • 缺點：
       • 配置表本身也是表。
       • 為了操作到真正的資料，每次操作都要額外對配置表進行一次操作。
  3. 基於演算法的對映
     • 優點：可以通過調製對映演算法使資料在子表中的分佈達到相對均勻，並且無論資料如何增長，每個子表承擔的新資料都是相對均勻的。
     • 缺點
       • 雖然不是高新科技，但其實現手段畢竟比前兩種要複雜一些，而且需要設計者挑選一個適合當前用例的演算法，不至於在資料增長時出現不均勻的子表增長。
       • 當業務變動，擴充新表時需要重新設計對映演算法，而對映演算法的重新設計有時會造成所有資料都需要重新分佈，維護代價將大大增高。

4.4 分庫分錶帶來的問題

• 在資料量很大的情況下，能夠提高讀寫效能、降低風險，並且可以適應持續的業務增長。但分庫分表也會帶來一些潛在問題。

4.4.1 全域性唯一ID

• 資料的ID需要額外的機制保護其唯一性。
• 一個常見的手段時使用各個程式語言框架提供的ID生成邏輯。
• UUID的主要缺陷就是佔用過多的空間。作為資料的ID，其唯一作用就是識別這條資料，如果連它都佔用了過多的空間，那麼資料庫的讀寫效能必然受到影響。另外，索引的建立也會因為它佔用過多的空間而降低效能。

4.4.2 關係資料庫的部分操作

• 分庫分表之後會影響關係資料庫的部分操作的有效性和效率。（例如JOIN）
• SQL還有一部分操作時處理查詢資料集合的，如Order By、Group By等，這些操作也無法在多個庫之間進行，而是依然要使用應用層的邏輯，讓網站開發者使用程式語言手動實現這些操作。

4.4.3 事務支援

• 資料庫，尤其是關係資料庫，有原生的事務支援，即所謂的一致性、原子性等（最流行的說法是ACID，A=Atomicity原子性，C=Consistency一致性，I=Isolation獨立性，D=Durability永續性）。
• 分庫之後，事務就不能再被原生支援。
• 有很多現代的應用層框架已經支援了這樣的操作，但是與之整合依然需要額外的工作。

《深入淺出大型網站架構設計》

第5章 資料庫優化：讀寫分離

• 使用者資訊的讀操作和寫操作是不平衡的，讀操作高而寫操作低。

5.1 什麼是讀寫分離

• 讀寫分離是指將資料庫的讀操作和寫操作分開。這裡的分開是指再伺服器的維度上分開，即讀操作和寫操作在不同的伺服器上完成。
• 經過讀寫分離之後，在應用層對資料庫進行操作時，寫操作和讀操作的請求將會被髮送到不同的資料庫伺服器。
• 寫操作被髮送至一臺稱為主資料庫的伺服器中，我們也可以成為主伺服器（Master），而讀操作被髮送至一臺成為從資料庫的伺服器中，我們也可以稱其為從伺服器（Slave）。
• 讀寫分離之後，一般會有一主一從兩臺伺服器（庫），或者一主多從多臺伺服器（庫），而控制讀寫分離的實際操作，在應用層或者資料訪問的封裝層中完成，在需要進行讀/寫操作時，實時決定要將請求傳送給哪臺伺服器。
• 分庫分表：
  • 原動力是資料量過大。
  • 分開的方式一般是將每一條資料根據欄位分成兩部分或將多條資料分散到多個數據庫中。
• 讀寫分離：
  • 原動力是因為資料讀寫的頻率不均衡；
  • 分開的方式一般是將同樣的資料複製到多臺資料庫伺服器中。

5.2 為什麼要使用讀寫分離

• 第一，在什麼情況下我們需要考慮讀寫分離？
• 第二，使用讀寫分離後，會帶來哪些好處。

5.2.1 何時需要使用讀寫分離

• 資料庫的讀寫頻率極高，已經造成資料庫的效能明顯下降。
• 資料庫的資訊根據業務邏輯和生產資料可知，讀寫頻率有明顯差距，一般來說讀操作次數遠遠大於寫操作的次數。
• 資料庫的效能下降原因不在於讀操作本身。

5.2.2 讀寫分離的好處

• 首先，使用讀寫分離之後讀操作和寫操作對相應伺服器的壓力都將大大減輕，從而提升效能。

• 其次，在分離讀寫操作之後，我們可以進一步地為主從資料庫進行有區別的、針對性的優化。

• 再次，本書後文會重點闡述“高可用性”的重要性和實現方式。

• 最後，針對某些書庫，使用讀寫分離數還可以帶來更多額外的好處。

• 有的資料庫，如MySQL中有X鎖和S鎖的概念，X鎖是指排它鎖（X是Exclusive，即排斥），S鎖是指共享鎖（S是Shared，即共享），X鎖的作用是當某個操作可以對某條資料加上鎖使得只有當前這個操作可以讀取或者修改這條資料，而S鎖的作用是某個操作可以對某條資料加上所，使得其他資料不可以再給當前資料加上X鎖，直到這個S鎖被解除（釋放）為止。讀操作往往需要加S鎖，而寫操作往往需要加X鎖。

• 讀寫操作頻繁的時候，X鎖和S鎖會頻繁爭用，在資料庫原本的延時基礎上增加了更多的時間來等待鎖的釋放。在使用讀寫分離之後，這兩個鎖的爭用情況將會被大大緩解。

5.3 實現讀寫分離

• 通過中介軟體實現和通過應用層實現。

5.3.1 中介軟體實現

• 中介軟體（Middleware）是一個舶來詞，它是處於硬體（Hardware）和軟體（Software）之間的元件。
• 資料庫伺服器看作硬體，可以將業務邏輯，即應用層看作軟體，那中介軟體就在資料庫伺服器和應用層之間。從軟體設計的原則角度上，中介軟體應該是一個和業務解耦的獨立元件，連線資料庫伺服器和應用層，幷包裝訪問資料庫的任何邏輯。
• 中介軟體需要實現以下功能：
  • 與不同型別的資料庫的操作語言和標準（如SQL、JSON資料）進行整合，這樣才能夠實現資料庫和應用層的解耦。
  • 與不同型別的資料庫的連線協議相容。
  • 提供對主從資料庫操作的整合和錯誤處理。這方面類似與原生資料庫事務的原子性、一致性。
  • 提供支援多門語言的介面給應用層呼叫。中介軟體存在的目的就是讓應用層不需要處理讀寫分離的操作，因此其介面必須和資料庫保持一致，而原生資料庫的介面，如關係資料庫就是標準SQL。

5.4.2 應用層實現

• 直接在應用層實現。這種實現方法當然也需要將訪問資料庫的程式碼抽象到一個層中，稱其為資料庫訪問層（Data Access Layer），但它不是一個獨立的元件或者伺服器。
• 中介軟體在應用層就相當於一個數據庫，而資料訪問層則是一個與應用層耦合更緊密的元件。
• 資料訪問層可以自己實現讀寫分離。

5.4 讀寫分離帶來的問題

• 讀寫分離可以使讀頻率遠遠高於寫頻率的網站或者服務得到極大的效能提升，但它也有自己的問題。

5.4.1 副本的實時性

• 主從資料庫不一致是讀寫分離面臨的主要問題。

5.4.2 副本實時性的解決方案

1. 根據業務的實時敏感度決定是否採用讀寫分離。
2. 一旦對某些資訊發生了寫操作，下一個讀操作在主資料庫上進行。
3. 對主資料庫進行二次讀取。

5.4.3 成本問題

• 讀寫分離有成本問題，或者說複雜性上的顧慮。在資料庫的讀操作頻率極高時，是否選擇使用讀寫分離是一個值得思考的問題。讀寫分離最大的問題在於，從資料庫也是資料庫（伺服器），它也需要成本，當從資料庫及其中介軟體、資料訪問層消耗的建設和維護成本以及導致的故障頻率增加時，還有很多其他選項值得考慮，如快取。