互聯網數據庫架構設計思路

一 、58同城數據庫架構設計思路

（1）可用性設計

解決思路：復制+冗余

副作用：復制+冗余一定會引發一致性問題

保證“讀”高可用的方法：復制從庫，冗余數據，如下圖

 
帶來的問題：主從不一致

解決方案：見下文

保證“寫”高可用的一般方法：雙主模式，即復制主庫（很多公司用單master，此時無法保證寫的可用性），冗余數據，如下圖

 
帶來的問題：雙主同步key沖突，引不一致

解決方案：

a）方案一：由數據庫或者業務層保證key在兩個主上不沖突

b）方案二：見下文

58同城保證“寫”高可用的方法：“雙主”當“主從”用，不做讀寫分離，在“主”掛掉的情況下，“從”（其實是另外一個主），頂上，如下圖

 
優點：讀寫都到主，解決了一致性問題；“雙主”當“主從”用，解決了可用性問題

帶來的問題：讀性能如何擴充？解決方案見下文

（2）讀性能設計：如何擴展讀性能

最常用的方法是，建立索引

建立非常多的索引，副作用是：

a）降低了寫性能

b）索引占內存多了，放在內存中的數據就少了，數據命中率就低了，IO次數就多了

但是否想到，不同的庫可以建立不同的索引呢？如下圖

 
TIPS：不同的庫可以建立不同索引

主庫只提供寫，不建立索引

online從庫只提供online讀，建立online讀索引

offline從庫只提供offline讀，建立offline讀索引

提高讀性能常見方案二，增加從庫

上文已經提到，這種方法會引發主從不一致問題，從庫越多，主從時延越長，不一致問題越嚴重

這種方案很常見，但58沒有采用

提高讀性能方案三，增加緩存

傳統緩存的用法是：

a）發生寫請求時，先淘汰緩存，再寫數據庫

b）發生讀請求時，先讀緩存，hit則返回，miss則讀數據庫並將數據入緩存（此時可能舊數據入緩存），如下圖

 
帶來的問題：

a）如上文所述，數據復制會引發一致性問題，由於主從延時的存在，可能引發緩存與數據庫數據不一致

b）所有app業務層都要關注緩存，無法屏蔽“主+從+緩存”的復雜性

58同城緩存使用方案：服務+數據+緩存

 
好處是：

1）引入服務層屏蔽“數據庫+緩存”

2）不做讀寫分離，讀寫都到主的模式，不會引發不一致

（3）一致性設計

主從不一致解決方案

方案一：引入中間件

 
中間件將key上的寫路由到主，在一定時間范圍內（主從同步完成的經驗時間），該key上的讀也路由到主

方案二：讀寫都到主

上文已經提到，58同城采用了這種方法，不做讀寫分離，不會不一致

數據庫與緩存不一致解決方案

兩次淘汰法

異常的讀寫時序，或導致舊數據入緩存，一次淘汰不夠，要進行二次淘汰

a）發生寫請求時，先淘汰緩存，再寫數據庫，額外增加一個timer，一定時間（主從同步完成的經驗時間）后再次淘汰

b）發生讀請求時，先讀緩存，hit則返回，miss則讀數據庫並將數據入緩存（此時可能舊數據入緩存，但會被二次淘汰淘汰掉，最終不會引發不一致）

（4）擴展性設計

（4.1）58同城秒級別數據擴容

需求：原來水平切分為N個庫，現在要擴充為2N個庫，希望不影響服務，在秒級別完成

 
最開始，分為2庫，0庫和1庫，均采用“雙主當主從用”的模式保證可用性

 
接下來，將從庫提升，並修改服務端配置，秒級完成擴庫

由於是2擴4，不會存在數據遷移，原來的0庫變為0庫+2庫，原來的1庫變為1庫和3庫

此時損失的是數據的可用性

 
最后，解除舊的雙主同步（0庫和2庫不會數據沖突），為了保證可用性增加新的雙主同步，並刪除掉多余的數據

這種方案可以秒級完成N庫到2N庫的擴容。

存在的問題：只能完成N庫擴2N庫的擴容（不需要數據遷移），非通用擴容方案（例如3庫擴4庫就無法完成）

（4.2）非指數擴容，數據庫增加字段，數據遷移

[這些方法在（上）篇中都已經介紹過，此處不再冗余，有興趣的朋友回復“同城”回看（上）篇]

方案一：追日志方案

方案二：雙寫方案

（4.3）水平切分怎么切

四類場景覆蓋99%拆庫業務

a）“單key”場景，用戶庫如何拆分： user(uid, XXOO)

b）“1對多”場景，帖子庫如何拆分： tiezi(tid, uid, XXOO)

c）“多對多”場景，好友庫如何拆分： friend(uid, friend_uid, XXOO)

d）“多key”場景，訂單庫如何拆分：order(oid, buyer_id, seller_id, XXOO)

[這些拆庫方案在（上）篇中都已經介紹過，此處不再冗余，有興趣的朋友回復“同城”回看（上）篇]

（5）海量數據下，SQL怎么玩

不會這么玩

a）各種聯合查詢

b）子查詢

c）觸發器

d）用戶自定義函數

e）“事務”都用的很少

原因：對數據庫性能影響極大

拆庫后，IN查詢怎么玩[回復“同城”回看（上）篇]

拆庫后，非Partition key的查詢怎么玩[回復“同城”回看（上）篇]

拆庫后，誇庫分頁怎么玩？[回復“同城”回看（上）篇]

問題的提出與抽象：ORDER BY xxx OFFSET xxx LIMIT xxx

單機方案：ORDER BY time OFFSET 10000 LIMIT 100

分庫后的難題：如何確認全局偏移量

分庫后傳統解決方案：查詢改寫+內存排序

a）ORDER BY time OFFSET 0 LIMIT 10000+100

b）對20200條記錄進行排序

c）返回第10000至10100條記錄

優化方案一：增加輔助id，以減少查詢量

優化方案二：模糊查詢

a）業務上：禁止查詢XX頁之后的數據

b）業務上：允許模糊返回 => 第100頁數據的精確性真這么重要么？

最后的大招！！！（由於時間問題，只在DTCC2015上分享了喲）

優化方案三：終極方案，業務無損，查詢改寫與兩段查詢

需求：ORDER BY x OFFSET 10000 LIMIT 4; 如何在分庫下實現（假設分3庫）

步驟一、查詢改寫： ORDER BY x OFFSET 3333 LIMIT 4

[4,7,9,10] <= 1庫返回

[3,5,6,7] <= 2庫返回

[6,8,9,11] <= 3庫返回

步驟二、找到步驟一返回的min和max，即3和11

步驟三、通過min和max二次查詢：ORDER BY x WHERE x BETWEEN 3 AND 11

[3,4,7,9,10] <= 1庫返回，4在1庫offset是3333，於是3在1庫的offset是3332

[3,5,6,7,11] <= 2庫返回，3在2庫offset是3333

[3,5,6,8,9,11] <= 3庫返回，6在3庫offset是3333，於是3在3庫的offset是3331

步驟四、找出全局OFFSET

3是全局offset3332+3333+3331=9996

當當當當，跳過3,3,3,4，於是全局OFFSET 10000 LIMIT 4是[5,5,6,6]

總結：58同城數據庫架構設計思路

（1）可用性，解決思路是冗余（復制）

（1.1）讀可用性：多個從庫

（1.2）寫可用性：雙主模式 or 雙主當主從用（58的玩法）

（2）讀性能，三種方式擴充讀性能

（2.1）增加索引：主從上的索引可以不一樣

（2.2）增加從庫

（2.3）增加緩存：服務+緩存+數據一套（58的玩法）

（3）一致性

（3.1）主從不一致：引入中間層 or 讀寫都走主庫（58的玩法）

（3.2）緩存不一致：雙淘汰來解決緩存不一致問題

（4）擴展性

（4.1）數據擴容：提升從庫，double主庫，秒級擴容

（4.2）字段擴展：追日志法 or 雙寫法

（4.3）水平切分

（單key）用戶庫如何拆分：, user(uid XXOO)

（1對多）帖子庫如何拆分： tiezi(tid, uid, XXOO)

（多對多）好友庫如何拆分： friend(uid, friend_uid, XXOO)

（多key）訂單庫如何拆分：order(oid, buyer_id, seller_id, XXOO)

（5）SQL玩法

（5.0）不這么玩：聯合查詢，子查詢，觸發器，自定義函數，事務

（5.1）IN查詢：分發MR or 拼裝成不同SQL語句

（5.2）非partition key查詢：定位一個庫 or 分發MR

（5.3）誇庫分頁

（5.3.1）修改sql語句，服務內排序

（5.3.2）引入特殊id，減少返回數量

（5.3.3）業務優化，允許模糊查詢

（5.3.4）查詢改寫，二段查詢

58同城的案例到這兒

 

二、數據庫之父Codd的12條法則

另外，我們回顧一下數據庫之父Codd的12條法則，作為數據庫設計的指導性方針：

1. 信息法則
   關系數據庫中的所有信息都用唯一的一種方式表示——表中的值。
2. 保證訪問法則
   依靠表名、主鍵值和列名的組合，保證能訪問每個數據項。
3. 空值的系統化處理
   支持空值（NULL），以系統化的方式處理空值，空值不依賴於數據類型。
4. 基於關系模型的動態聯機目錄
   數據庫的描述應該是自描述的，在邏輯級別上和普通數據采用同樣的表示方式，即數據庫必須含有描述該數據庫結構的系統表或者數據庫描述信息應該包含在用戶可以訪問的表中。
5. 統一的數據子語言法則
   一個關系數據庫系統可以支持幾種語言和多種終端使用方式，但必須至少有一種語言，它的語句能夠一某種定義良好的語法表示為字符串，並能全面地支持以下所有規則：數據定義、視圖定義、數據操作、約束、授權以及事務。（這種語言就是SQL)
6. 視圖更新法則
   所有理論上可以更新的視圖也可以由系統更新。
7. 高級的插入、更新和刪除操作
   把一個基礎關系或派生關系作為單個操作對象處理的能力不僅適應於數據的檢索，還適用於數據的插入、修改個刪除，即在插入、修改和刪除操作中數據行被視作集合。
8. 數據的物理獨立性
   不管數據庫的數據在存儲表示或訪問方式上怎么變化，應用程序和終端活動都保持着邏輯上的不變性。
9. 數據的邏輯獨立性
   當對表做了理論上不會損害信息的改變時，應用程序和終端活動都會保持邏輯上的不變性。
10. 數據完整性的獨立性
    專用於某個關系型數據庫的完整性約束必須可以用關系數據庫子語言定義，而且可以存儲在數據目錄中，而非程序中。
11. 分布獨立性
    不管數據在物理是否分布式存儲，或者任何時候改變分布策略，RDBMS的數據操縱子語言必須能使應用程序和終端活動保持邏輯上的不變性。
12. 非破壞性法則
    如果一個關系數據庫系統支持某種低級（一次處理單個記錄）語言，那么這個低級語言不能違反或繞過更高級語言（一次處理多個記錄）規定的完整性法則或約束，即用戶不能以任何方式違反數據庫的約束。

 

還有一些經驗：

• 降低對數據庫功能的依賴
  功能應該由程序實現，而非DB實現。原因在於，如果功能由DB實現時，一旦更換的DBMS不如之前的系統強大，不能實現某些功能，這時我們將不得不去修改代碼。所以，為了杜絕此類情況的發生，功能應該有程序實現，數據庫僅僅負責數據的存儲，以達到最低的耦合。
• 定義實體關系的原則
  當定義一個實體與其他實體之間的關系時，需要考量如下：
  • 牽涉到的實體 識別出關系所涉及的所有實體。
  • 所有權 考慮一個實體“擁有”另一個實體的情況。
  • 基數 考量一個實體的實例和另一個實體實例關聯的數量。

---

來自網絡資料收集與整合，希望對您軟件開發有幫助。 其它您可能感興趣的文章：
企業應用之性能實時度量系統演變
雲計算參考架構幾例
智能移動導游解決方案簡介
人力資源管理系統的演化

如有想了解更多軟件,系統 IT,企業信息化 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。

原文地址：https://www.cnblogs.com/wintersun/p/4638176.html