中型存儲架構實踐探索

最近一直在作平臺優化：對於中小型的站點，如何在資源有限的狀況下，實現一個穩定，高效，靠譜的存儲方案。下圖是小拽我的在時間過程使用的一個存儲架構。拿出來分享交流一下，也但願獲得指點改進！

先上圖

首先說思想

思想就一個：權衡資源和業務需求

簡單解釋一下：對於架構的理解，我的很是認同百度架構師tandai的一句話：架構設計本質上是折衷的藝術，若是你有足夠量的高速存儲和高性能的機器，那麼徹底能夠用足量的cache，足量的離線計算存儲，來提高時效性；一樣，若是你的機器不足，資源不足，那麼就能夠經過可接受的時間消耗來節省存儲空間。

架構基本組件：

• 至少兩臺機器。【保證物理容災】

• 三個mysql實例。【一主兩從，一主不解釋；一從主要用於實時備份，暫叫容災從；一從用於離線計算，cache更新，非時效性的數據抓取，暫叫api從；】

• ameoba 負責負載均衡和讀寫分離【暫時用着還能夠】。

• redis 負責緩存，預取，存儲cache。【能夠換成其餘】

• 一個抗高併發的中間件。【暫時只加了antispam組件，高併發並未處理，可能系統負載比較平均，qpd幾千萬 ，可是並未出現qps峯值】

that's all，這些組件對於一個操做尚可的程序員來講，部署一整套確定不會特別麻煩，相對於其餘大型的架構來講，略顯簡單；可是，麻雀雖小，五臟俱全，下面從架構必備的幾個角度分析一下。

安全性（Failover）

任何一個架構首要考慮的是數據安全和容災。小拽的架構中作了哪些

數據庫全量備份

這個就是一個簡單腳本，對api從庫在閒暇時間【晚上3-4點】進行全量導出備份，同時scp到另外一臺機器一份。（之因此對api庫，是由於api庫主要負責非失效性的查詢和計算）

# crontab 天天3點進行數據庫備份 (cuihuan)
# 0 3 * * * sh /home/disk6/mysql/bin/backup.sh
# 天天備份，保存最近30天的
DATE=$(date +%Y%m%d)
/home/xxx/bin/mysqldump -uroot -pxxx db > /home/xxx/bak_sql/db_$DATE.sql;
find /home/xxx/bak_sql/ -mtime +30 -name '*.sql' -exec rm -rf {} \;

數據庫增量備份

增量備份主要從兩個角度

• binlog中按期備份sql；

• 是採用主從庫以後，從庫會定時的備份主庫信息，同時，對api庫採用數據徹底一致，對容災庫則設置只同步update 和insert；這樣完備的保證了數據的安全。

可用性（Availabilty）

數據的安全排第一，毋庸置疑；次之排平臺的可用性，也毫無爭議。可用性最簡單的一個指標則爲：不卡。

cache

cache是提高查詢時效性最有效的一個手段，小拽在框架中主要應用了兩種cache，知足不一樣的業務需求。（全部關於cache的使用，必定要注意時效性和一致性，時效性和一致性，時效性和一致性）

• 普通的cache。即用戶搜索或者查詢以後的結果存在redis裏面，下次查詢使用。

• 預取的cache。即預測用戶要查詢的內容，放到cache裏面。舉幾個栗子，用戶首頁內容必定要存cache裏面；用戶在看page1的時候，能夠後臺預測用戶會看page2，提早取過來等等，這些策略和本身的實際業務緊密結合。

關於時效性和一致性再多說一句：必定要注意及時更新，例如用戶寫操做，點擊操做，都須要在後臺觸發cache的主動更新，不然可能形成數據一致性錯誤。

分庫分表

中小型的架構中，存儲的瓶頸每每在於讀。

隨着數據的增長，讀庫的成本愈來愈大，一個sql極可能會形成鎖死整個庫，一條sql 10+s也是常有的事情；所以，解決讀庫的瓶頸，能夠大大提高系統的可用性；小拽的實踐中主要應用了分庫，分表。

分庫

之因此要分庫，是由於二八原則的存在，80%的用戶操做集中於20%的數據。

舉個栗子：實踐過程當中小拽有個月庫，只存本月的數據，基本上80%+的用戶操做數據，都會命中這個庫。

分庫的原則有不少，例如時間原則，業務原則，數據邏輯原則等等；總之在您的框架中，當db扛不住的時候就分庫，分層級。

分表

分表的思想和分庫相似，只是粒度更小，不在贅述。

擴展性（Scabability）

小拽的架構中，擴展性主要從三個方面考慮

• 1：數據庫的擴展性。若是資源容許N主N從都是能夠的，基本上不會影響業務操做。

• 2：緩存的擴展。緩存基本上也是單獨部署的，redis，memcache等都可以，變動成本不大。

• 3：高併發和負載均衡。這塊屬於大型網站須要考慮的，暫時只採用了ameaba進行負載均衡的擴展，高併發預留接口。

權衡（Balance）

全部的架構和技術，最終都要落實到和業務需求權衡。

上面的架構最大的優點其實就是：簡單，搭建起來很是容易，這就夠了。

做爲一名碼農，只有在實踐的過程當中，不斷髮現系統的瓶頸，權衡現有資源和需求，解決和處理問題，才能成爲一名靠譜的碼農。

以上只是小拽在實踐過程當中的一點小當心的，歡迎你們到小站交流（http://cuihuan.net）。

【轉載請註明：中型存儲架構實踐探索 | 靠譜崔小拽 】