目錄
大部分網際網路業務都是讀多寫少，因此優先考慮db如何支撐更高查詢數，首先就需要區分讀、寫流量，這才方便針對讀流量單獨擴充套件，即主從讀寫分離。
若前端流量突增導致從庫負載過高，dba會優先做個從庫擴容上去，這樣對db的讀流量就會落到多個從庫，每個從庫的負載就降了下來，然後開發再盡力將流量擋在db層之上。
cache v.s mysql讀寫分離
由於從開發和維護的難度考慮，引入快取會引入複雜度，要考慮快取資料一致性，穿透，防雪崩等問題，並且也多維護一類元件。所以推薦優先採用讀寫分離，扛不住了再使用cache。
主從讀寫分離一般將乙個db的資料拷貝為一或多份，並且寫入到其它的db伺服器中：
所以主從讀寫分離的關鍵：
即主從複製
讓開發人員使用感覺依舊在使用單一db
mysql的主從複製依賴於binlog，即記錄mysql上的所有變化並以二進位制形式儲存在磁碟上二進位制日誌檔案。
主從複製就是將binlog中的資料從主庫傳輸到從庫，一般非同步：主庫操作不會等待binlog同步完成。
使用獨立的 dump執行緒是非同步，避免影響主庫的主體更新流程，而從庫在接收到資訊後並不是寫入從庫的儲存，是寫入乙個relay log，這是為避免寫入從庫實際儲存會比較耗時，最終造成從庫和主庫延遲變長。
基於效能考慮，主庫寫入流程並沒有等待主從同步完成就返回結果，極端情況下，比如主庫上binlog還沒來得及落程式設計客棧盤，就發生磁碟損壞或機器掉電，導致binlog丟失，主從資料不一致。不過概率很低，可容忍。
主庫宕機後，binlog丟失導致的主從資料不一致也只能手動恢復。
主從複製後，即可：
這樣即使寫請求會鎖表或鎖記錄，也不會影響讀請求執行。高併發下，可部署多個從庫共同承擔讀流量，即一主多從支撐高併發讀。
從庫也能當成個備庫，以避免主庫故障導致資料丟失。
那無限制地增加從庫就能支撐更高併發嗎？
no！從庫越多，從庫連線上來的i/o執行緒越多，主庫也要建立同樣多log dump執行緒處理複製的請求，對於主庫資源消耗較高，同時受限於主庫的網路頻寬，所以一般乙個主庫最多掛3～5個從庫。
比如發朋友圈這一操作，就存在資料的：
如更新db
如將朋友圈內容同步給審核系統
所以更新完主庫後，會將朋友圈id寫入mq，由consumer依據id在從庫獲取朋友圈資訊再發給審核系統。
此時若主從db存在延遲，會導致在從庫取不到朋友圈資訊，出現異常！
主從延遲對業務的影響示意圖
這咋辦呢？其實解決方案有很多，核心思想都是 盡量不去從庫查詢資料。因此針對上述案例，就有如下方案：
2.3.1 資料冗餘
可在發mq時，不止傳送朋友圈id，而是發給consumer需要的所有朋友圈資訊，避免從db重新查詢資料。
推薦該方案，因為足夠簡單，不過可能造成單條訊息較大，從而增加訊息傳送的頻寬和時間。
2.3.2 使用cache
在同步寫db的同時，把朋友圈資料寫cache，這樣consumer在獲取朋友圈資訊時，優先查詢cache，這也能保證資料一致性。
該方案適合新增資料的場景。若是在更新資料場景下，先更新cache可能導致資料不一致。比如兩個執行緒同時更新資料：
最終db值（1）和cache值（2）不一致！
2.3.3 查詢主庫
可以在consumer中不查詢從庫，而改為查詢主庫。
使用要慎重，要明確查詢的量級不會很大，是在主庫的可承受範圍之內，否則會對主庫造成較大壓力。
若非萬不得已，不要使用該方案。因為要提供乙個查詢主庫的介面，很難保證其他人不濫用該方法。
主從同步延遲也是排查問題時容易忽略。
有時會遇到從db獲取不到資訊的詭異問題，會糾結**中是否有一些邏輯把之前寫入內容刪除了，但發現過段時間再去查詢時又能讀到資料，這基本就是主從延遲問題。
所以，一般把從庫落後的時間作為乙個重點db指標，做監控和報警，正常時間在ms級，達到s級就要告警。
主從的延遲時間預警，那如何通過哪個資料庫中的哪個指標來判別？ 在從從庫中，通過監控show sl**e
status\g命令輸出的seconds_behind_master引數的值判斷，是否有發生主從延時。
這個引數值是通過比較sql_thread執行的event的timestamp和io_thread複製好的
event的timestamp(簡寫為ts)進行比較，而得到的這麼乙個差值。
但如果複製同步主庫bin_log日誌的io_thread執行緒負載過高，則seconds_behind_master一直為0，即無法預警，通過seconds_behind_master這個值來判斷延遲是不夠準確。其實還可以通過比對master和sl**e的binlog位置。
使用主從複製將資料複製到多個節點，也實現了db的讀寫分離，這時，對db的使用也發生了變化：
為降低實現的複雜度，業界湧現了很多db中介軟體解決db的訪問問題，大致分為：
如tddl（ taobao distributed data layer），以**形式內嵌執行在應用程式內部。可看成是一種資料來源**，它的配置管理多個資料來源，每個資料來源對應乙個db，可能是主庫或從庫。
當有乙個db請求時，中介軟體將sql語句發給某個指定資料來源，然後返回處理結果。
優點簡單易用，部署成本低，因為植入應用程式內部，與程式一同運程式設計客棧行，適合運維較弱的小團隊。
缺點缺乏多語言支援，都是j**a語言開發的，無法支援其他的語言。版本公升級也依賴使用方的更新。
如mycat、atlas、dbproxy。
這類中介軟體部署在獨立伺服器，業務**如同在使用單一db，實際上它內部管理著很多的資料來源，當有db請求時，它會對sql語句做必要的改寫，然後發往指定資料來源。
優點
缺點
可以把主從複製引申為儲存節點之間互相複製儲存資料的技術，可以實現資料冗餘，以達到備份和提公升橫向擴充套件能力。
使用主從複製時，需考慮：
若保證所有從節點都寫入成功，則寫效能一定受影響；若只寫主節點就返回成功，則從節點就可能出現資料同步失敗，導致主從不一致。網際網路專案，一般優先考慮效能而非資料的強一致性
會導致很多詭異的讀取不到資料的問題
很多實際案例：
不同元件對於複製的一致性、延遲要求不同，採用的方案也不同，但設計思想是相通的。
若大量訂單，通過userid hash到不同庫，對前台使用者訂單查詢有利，但後台系統頁面需檢視全部訂單且排序，sql執行就很慢。這該怎麼辦呢？
由於後台系統不能直接查詢分庫分表的資料，可考慮將資料同步至乙個單獨的後台庫或同步至es。
系統從初期到支撐億級流量，都經歷了哪些架構的變遷？
隨著網際網路的發展，網際網路企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化。總體來說，系統的架構大致經歷了 單體應用架構 垂直應用架構 分布式架構 soa架構 微服務架構的演變。當然，很多網際網路企業的系統架構已經向service mesh 服務化網格 演變。今天，我們就一起來...
別逗了！知識付費能支撐起喜馬拉雅的200億估值？
凸顯資本主義對音訊市場的焦慮 今年上半年，就有傳言喜馬拉雅的估值達240億元，並可能在一到兩年內上市。在ipo傳言越演越烈的背後，也克聯想到喜馬拉雅其內部與資本之間的不同決策。同時，受益於近年來付費內容的增長和崛起，網路音訊平台也成為資本家青睞的物件。有了賺錢的模式，資本家當然紛紛投錢給這些音訊平台...
億級流量專案 redis持久化的意義
redis持久化的意義當然是 故障恢復，當遇到為什麼要用的問題時候，想一想沒有用的場景怎麼樣，再想一想用了的場景怎麼樣 1.如果redis不做持久化，它是儲存在記憶體中的，如果機器宕機了，資料就直接沒有了，要恢復資料，只能大批量的讀取資料庫資料，這樣的動作很慢，增大了資料庫的壓力。因此，不做持久化處...