百度技術沙龍第 12 期 大型網站數據庫架構設計和性能優化

本文做者：HelloDeveloper

在剛剛結束的第 12 期百度技術沙龍，咱們邀請到了百度運維部高級 DBA 經理王龍和飛信互聯網產品首席架構師孫朝暉，分別向你們分享了百度數據庫架構演變與設計，以及 Mysql HandleSocket 在動態數據存儲中的應用的技術話題。本文對此次百度技術沙龍內容作簡單的回顧與總結。

 

百度數據庫架構演變與設計（點擊進入相關音視頻、文字資料下載頁面）

 

在演講中，百度運維部的高級 DBA 經理王龍和你們分享了百度在數據庫架構設計上的演變過程。百度的數據庫架構體系總共分爲三個階段：

 

2005 年 -2008 年：分散式數據庫結構 

這一階段是被動知足業務需求階段，其特色是業務單1、單機單業務服務、無交叉關聯、簡單 Replication 機制、依賴硬件，數據的存儲和管理均由單機實現。

 

2008 年 -2010 年：集中式數據庫結構

 

這一階段主要重點是放在了數據庫管理和存儲上。特色是集羣易擴展，功能多；數據存儲與應用分離；數據庫結構各異，業務鏈接和使用方式各異。

 

2010 年至今：分佈式數據庫結構

 

 

 其特色是不只關注存儲和管理，而且把應用也注重起來，提供透明應用和策略的數據庫服務； 自動擴容、節點自動分裂與合併。

王龍的分享分爲三個部分：

 

● 百度數據庫架構綜述：業務概念、業務接口、業務規則 

● 百度數據庫三階：分散式、集中式、分佈式

 

 

 ● 百度數據庫挑戰

演講的開始王龍簡單介紹了三種不一樣數據庫的概念：

 

分散式系統是指運行在同一臺服務器上，爲單一產品線或業務提供服務的數據庫系統，不與其餘系統有交互。

集中式系統是指運行在同一臺服務器上，爲多系統提供業務服務的數據庫系統，不與其餘系統有交互。多爲架構調整和性能需求，主要運行在高性能和高穩定的服務器上。

 

 

 分佈式系統使數據庫資源充分共享，包括數據和服務器資源，這種將部件或功能分佈到不一樣計算機系統和不一樣位置的方法通常稱爲分佈式計算。

本次分享重點介紹了百度在不一樣的發展階段，採起不一樣的數據庫架構方式和設計思路。最後王龍提到了簡單介紹了目前在數據庫架構、性能、傳輸、安全以及服務方面的挑戰。

 

MySQL HandleSocket 技術在 SNS Feed 存儲中的應用（點擊進入音視頻、文字資料下載頁面）

 

孫朝暉主要爲你們分享了他們在 SNS Feed 存儲中使用 Mysql HandleSocket 技術的實踐經驗。

 

MySQL HandleSocket 技術你們可能不多瞭解，實踐應用據我所知也沒見有人用過，咱們其實主要用它來處理 NoSQL 技術。其實我今天的主要話題也是 NoSQL 技術，只是我沒有用你們熟悉的 HBase 等去實現，而用 MySQL 實現的。

分享內容主要是如下幾個部分：

 

● SNS Feed 應用的主要挑戰 

● NoSQL 在 Feed 存儲中的應用情況

 

● MySQL HandleSocket 的技術架構

 

● MySQL HandleSocket 協議

 

 

 ● MySQL HandleSocket 在飛信開放平臺中的應用

在演講中，孫朝暉提到，SNS Feed 面對的主要問題就是數據量大，更新快。並介紹了 SNS Feed 面臨的挑戰：

 

● 數據寫入操做密集，高頻度，小數據量 

● 讀操做訪問壓力大，讀寫比高

 

● 高活躍用戶帶來的數據快速失效問題（在微博類應用尤爲突出）

 

● 用戶體驗要求快速被前端感知

 

● 數據分區存儲成爲必然選項

 

 

 ● 數據具備時效性，LRU 數據清洗成爲必然工做

而後詳細介紹了 SNS Feed 的數據架構和技術優點，並把 MySQL HandleSocket 和 MongoDB 作了比較。

 

OpenSpace

 

一樣在沙龍最後一個環節，咱們分紅了六個話題小組，小組話題發起分別由咱們的兩位講師、咱們邀請的嘉賓，新浪 DBA 楊海朝和現場提出話題的三位參會者擔任，並在討論以後跟你們作了分享：

 

● 沙龍講師王龍：數據庫一致性的保障

 

咱們會從兩個角度考慮，一個是正面保障它不出問題，第二個是出問題後如何去修復。在不出問題的時候，也要從硬件和軟件兩個角度去看。從硬件來講主要是像底層的存儲相似的經常使用技術。可是也要考慮一個問題，由於不管如何都是要經過通訊傳輸的，那通訊如何保障？好比像採用光纖這種狀況。從軟件角度，主要考慮兩種狀況，從前端應用去保障和數據庫本地保障。

 

 若是是出問題之後，咱們一是按照傳統的方式是從日曆裏去作數據結構解析，或者作前端數據的分解或關聯關係映射，另外一種狀況就是保證數據完整不流失的狀況下去解析數據結構。

 

● 沙龍講師孫朝暉：NoSQL 在 Feed 中應用爭論點

 

主要是圍繞在 SNS 弱一致性前提下如何提升數據庫的性能，其實在放棄一些對用戶體驗影響很是小的點，雖然看似不合理，其實會在不影響用戶體驗的狀況下把性能提高不少。

剛纔有人問我說在推拉結合的前提下怎麼去作分頁，我認爲不用去追求每次分頁數量的精確性，把這一點放下去的話，性能起碼可以提高 10 倍以上，其實還有不少這樣的需求，好比分發前端併發鏈接的時候，讓保持長鏈接和短鏈接的 Web 請求分佈在不一樣的 Web 服務器上，這樣，在僅能影響一部分用戶的狀況下，性能也會提高不少。

 

 

 總之咱們的話題總結出來，就是說 SNS 的應用，尤爲 SNS Feed 的應用，沒必要要求像電子商務數據那樣百分之百精確，有不少小的點，捨棄一點點用戶體驗，一點用戶察覺不到的體驗，能讓系統成本下降不少，這裏有不少可挖掘的空間。

● 沙龍嘉賓楊海朝：高併發 MySQL 的架構設計

 

主要是和你們分享了一下高併發架構設計的話題，討論在實時性要求很高的場合中，MySQL 遇到高併發寫入時如何經過架構去解決它的 slave 延時的問題。

 

 傳統的方式是經過對寫進行分片，分散到多臺物理機上，多臺機器承擔寫操做。但這種方式對多個表之間有強 ACID 的場合不太適合，前期經過提升主庫的硬件性能，master 不能進行拆分，slave 採用鏈條策略把不一樣的表拆分到不一樣組的機器上，這樣每組集羣中同步的數據量變小，在必定的時間內緩解了延時問題。但隨着量的增長，須要採用 NOCAP 原則把數據寫入內存，兩分內存互相同步，內存中的數據再異步到持久化存儲中，保證達到一個很是高的併發，同時不損失一致性和擴展性的問題。

 

● 參會者張成斌：消息隊列的應用

 

咱們討論是一個消息隊列解決方案的話題：假設客戶端性能很是高，如何實現客戶的請求經過服務器端調度，在客戶端處理，而後呈如今 Web 界面上，對此咱們討論出了一個模型：

 

 好比說咱們的頁面有加減乘除的處理，而後可能有 a、b、c、d……不少客戶，他們把請求傳到服務器端，服務器端會把消息包發送到各地的客戶端處理後再返給服務器，傳給頁面。咱們小組主要討論了前面列出的客戶相關的實時性、異常處理、路徑、程序以及消息的保護等問題，並提出了幾個方案，對於實時性，咱們須要維護客戶端心跳數據來優化調度，對於異常咱們不作處理，客戶得不到他要的數據能夠屢次刷新幾回；最優路徑仍是經過這個心跳數據和客戶端 CPU 資源評估得出綜合分數，對於消息的保護咱們會經過非對稱密鑰去保護咱們對稱密鑰的交換，利用對稱密鑰保護消息的通信。

 

● 參會者王炳山：雲計算在脫機業務中的應用

 

個人話題是一個雲計算的話題，可能在今天關注的人很少，雖然沒有徹底解決掉本身的問題，可是仍是從討論中獲得一些收穫，之後指望有機會能繼續和你們分享這個話題。

● 最後一個小組討論的話題是：SNS Game 千萬量級用戶 DB 架構設計

 

我主要是介紹了咱們公司的一個狀況：在用戶量增加的狀況下要常常不斷的停機，這樣作的成本比較高，相對來講也不太安全。目前業內作的比較好的也能作到平滑升級的，剛纔有個朋友說數據庫加個中間層可能會解決這個問題，咱們公司如今在嘗試 NoSQL 的方式。

參會者博客

 

和往常同樣，也有參會者在會後寫博客談到了本身在本期百度技術沙龍中的收穫。若有熱心參會者 CSDN 論壇中對第十二期百度技術沙龍作了介紹，上傳了本期沙龍的一些照片和你們分享。頗受其餘用戶熱議。你們能夠點擊進入大型網站數據庫架構設計和性能優化查看。

原文連接地址：https://developer.baidu.com/topic/show/290172