各位志同道合的朋友們大家好，我是一個一直在一線互聯網踩坑十余年的編碼愛好者，現在將我們的各種經驗以及架構實戰分享出來，如果大家喜歡，就關注我，一起將技術學深學透，我會每一篇分享結束都會預告下一專題
一般我們業務在讀多寫少的場景下，遇到的第一個瓶頸就是數據庫這塊，大量的讀請求會來到數據庫，這樣如果你初期部署的一個數據庫就會造成IO大量增加，使得請求變慢，甚至會卡死整個數據庫，到了這個階段，我們一般會將讀請求和寫請求進行分開數據處理，即采用主從讀寫分離的方式。
注：這里說的是主從并不是主備，主從中的從服務器是要承擔業務的，而主備中備份機器一般只作為備份存在。
我們采用主從讀寫分離的方式，目的是為了將更多的讀請求進行分發來緩解我們的大量讀請求。
讀寫分離架構原理
正如上面所說，讀寫分離是為了將請求流量分散到不同的數據庫節點上，將寫入數據的請求分發到主數據庫，讀取數據的請求分發到從數據庫，從數據可以有多臺，即一主多從。如下圖：
從上圖可看出，有個關鍵技術就是主從復制，每次寫入數據的時候，需要將主服務器數據復制到從服務器中，用來確保數據一致性。下面我們來單獨看看主從是怎么復制的，以我們互聯網中最熟悉的MySQL為例。
- 從服務器連接上主服務器，啟動復制的時候，則會自身創建一個IO線程去像主數據庫服務器拉取binlog的更新信息。
- 把拉過來的binlog信息寫到自己服務器的一個relay log日志文件中。
- 從數據庫服務器創建一個SQL線程，是為了將relay log的所有日志信息，進行sql回寫到自己的數據庫中，這樣就和主庫的數據一模一樣了。
- 當主數據庫有數據更新的時候，比如新插入了一條或者update了一條數據，這時候主庫會將這些數據更新到binlog二進制文件中，同時，主庫會創建一個binlog dump線程，這個線程將更新了的binlog信息發送到從庫的IO線程，需要注意的是，這個過程是異步的，如果等著從庫接受完成，是不是特別慢，且影響性能。
這樣的“一主多從”的主從復制方案做好之后，現在咱們就不怕當前這些大量的讀請求了，因為我們把這些大流量讀請求都分發到這些從數據庫中了，寫入數據的請求依然還是寫到主數據，一點不影響我們讀的業務，互不影響的。同時，從數據庫還可以作為備份數據庫來使用，萬一主庫突然故障了，它可以頂上去防止數據丟失。
但是，我們不能一味的加從數據庫，加個十七八個的，這樣做是無腦的操作啊，你想想看，你加一堆的的從數據庫連接到數據庫，復制他的數據，太多的IO線程會造成主數據不堪重負的，就會造成你寫入數據慢，還會卡死，這就悲劇了。所以，不能這么搞啊，一般生產環境一個主數據庫掛三個從數據就行了，最多不能超過5個以上，要是還是不滿足肯定就會有其他方案了啊，多級緩存方案啊，是不是，后面會講的。
主從延時
上面說了主從讀寫分離的那么多好處， 主從同步是有延遲的，當然，這個延時一般都在ms級別，但是如果到了秒級別，可能就會對有些業務造成影響，看我們能否接受。比如，我們在支付系統創建支付單后，風控系統會進入查詢作出相應的風控操作，如果查不到就會可能終止本次交易了。
主從延遲優化
- 我們可以在這些立馬需要查的業務，讓它直接查主數據庫，但是這種方案不推薦，因為量大怕會拖垮主數據
- 當從數據庫讀取不到，我們回去再讀主數據，這樣就能讀到數據了。但是，這種也是有風險的，量大也會拖垮主庫。
- 像我前面文章提到過，分重要性業務和非重要業務，將很核心的幾個業務查主數據，其他非核心，讀寫分離。
- 使用緩存，將新增的數據同時添加一份緩存，然后查緩存數據，這種建議新增的數據使用緩存較好。
- 使用消息隊列中間件進行消息冗余，將新的主數據內容，通過消息中間件MQ冗余一份當前數據，然后發到需要查詢的系統。
在消息體不大，推薦使用第 5 種優化方案，需要消息中間件；其次考慮緩存, redis,Memcache 都可以的，因為更新的操作，需要更新緩存，也需要解決一致性問題，所以，新增的數據，就首選緩存優化方案。最后，推薦重要性非重要性隔離方案。最好不要使用都查詢主庫的操作。
如何優雅使用讀寫分離
我們現在使用了數據庫讀寫分離的機制，但是我們代碼該怎么去友好的去訪問數據庫呢？以前我們一個數據源配置就可以了，現在有好多個數據源了，代碼里既要區分哪個地方使用寫數據庫的數據源，哪個地方需要使用讀數據的數據源。當然，肯定是有辦法的，業界大佬們都早于我們遇到了這些問題，下面我會分享出兩種方案：
1，程序代碼嵌入
代碼嵌入，是指通過在我們的代碼中開發出數據庫訪問中間層，由這個數據庫訪問中間層去訪問不同的數據源，以實現讀寫分離和數據源的管理。現在推薦使用淘寶開源的TDDL（Taobao Distributed Data Layer），使用方便，直接集成到我們代碼就可以了，它自己管理讀寫分離和數據庫配置。
特點是：
- 實現簡單，可以根據自己業務進行定制化開發
- 語言不同，就得開發不同語言版本的數據庫訪問層
2，部署獨立代理層
部署代理層是指，在我們的業務服務器和數據庫直接引入數據訪問代理層，并不用自己寫代碼。現在為代表的開源中間件有阿里的MyCat、360的Atlas、美團的DBProxy等。這些都是使用標準的MySql通信協議。
特點：
- 不用自己編寫多余代碼，使用方便。
- 支持對語言
- sql語句會跨兩層網絡，性能稍微低一點。
建議，在自己公司沒有比較成熟的中間件團隊的話就用程序代碼封裝的方案，雖然寫代碼麻煩點，但是自己可以把控；要是公司有成熟中間件團隊，就盡量考慮代理層部署的方案，因為需要有個團隊要研究和長期維護這個代理層，才能確保業務正常發展，現在我們公司大部分都用的是代理層方案，是有個專門團隊來維護。
總結，今天講到了當我們讀多寫少的場景下，采取數據庫讀寫分離的方式來分攤大流量。從而引出了主從復制，并且對主從復制的延遲進行了優化方案的講解和給出來相應的建議，希望對大家有所幫助。如果大家喜歡就關注我，讓我們一起聊公司的各種技術，共同學習共同進步，有什么想說的是想學的評論區里說啊，大家都可以給方案，謝謝
