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

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

58和趕集合并了，但是針對于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頁數據的精確性真這么重要么？

最后的大招！！！

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

需求：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）查詢改寫，二段查詢

來自：http://mp.weixin.qq.com/s?__biz=MjM5ODI5Njc2MA==&mid=205789980&idx=2&sn=f62a429d4ccd7a159148084bad71f54c&scene=2&from=timeline&isappinstalled=0#rd