數據庫/資料庫(DB)架構 [純粹收集，如果公司沒有花錢DBA，那也表示根本不重視資料庫，自己也就不用太在意]
數據庫/資料庫(DB)架構 [純粹收集，如果公司沒有花錢DBA，那也表示根本不重視資料庫，自己也就不用太在意]
GITHUB: https://github.com/jash-git/DBA-Database-architecture
01.架構原則
▲高可用
▲高性能
▲一致性
▲擴展性
02.常見的架構方案
▲主從架構，只有主庫提供讀寫服務，備庫冗餘作故障轉移用
1、高可用分析：高可用，主庫掛了，keepalive（只是一種工具）會自動切換到備庫。這個過程對業務層是透明的，無需修改代碼或配置。
2、高性能分析：讀寫都操作主庫，很容易產生瓶頸。大部分互聯網應用讀多寫少，讀會先成為瓶頸，進而影響寫性能。另外，備庫只是單純的備份，資源利用率50%，這點方案二可解決。
3、一致性分析：讀寫都操作主庫，不存在數據一致性問題。
4、擴展性分析：無法通過加從庫來擴展讀性能，進而提高整體性能。
5、可落地分析：兩點影響落地使用。第一，性能一般，這點可以通過建立高效的索引和引入緩存來增加讀性能，進而提高性能。這也是通用的方案。第二，擴展性差，這點可以通過分庫分錶來擴展。
▲雙主架構，兩個主庫同時提供服務，負載均衡
1、高可用分析：高可用，一個主庫掛了，不影響另一台主庫提供服務。這個過程對業務層是透明的，無需修改代碼或配置。
2、高性能分析：讀寫性能相比於方案一都得到提升，提升一倍。
3、一致性分析：存在數據一致性問題。請看，一致性解決方案。
4、擴展性分析：當然可以擴展成三主循環，但筆者不建議（會多一層數據同步，這樣同步的時間會更長）。如果非得在數據庫架構層面擴展的話，擴展為方案四。
5、可落地分析：兩點影響落地使用。第一，數據一致性問題，一致性解決方案可解決問題。第二，主鍵衝突問題，ID統一地由分佈式ID生成服務來生成可解決問題。
▲主從架構，一主多從，讀寫分離
1、高可用分析：主庫單點，從庫高可用。一旦主庫掛了，寫服務也就無法提供。
2、高性能分析：大部分互聯網應用讀多寫少，讀會先成為瓶頸，進而影響整體性能。讀的性能提高了，整體性能也提高了。另外，主庫可以不用索引，線上從庫和線下從庫也可以建立不同的索引（線上從庫如果有多個還是要建立相同的索引，不然得不償失；線下從庫是平時開發人員排查線上問題時查的庫，可以建更多的索引）。
3、一致性分析：存在數據一致性問題。請看，一致性解決方案。
4、擴展性分析：可以通過加從庫來擴展讀性能，進而提高整體性能。（帶來的問題是，從庫越多需要從主庫拉取binlog日誌的端就越多，進而影響主庫的性能，並且數據同步完成的時間也會更長）
5、可落地分析：兩點影響落地使用。第一，數據一致性問題，一致性解決方案可解決問題。第二，主庫單點問題，筆者暫時沒想到很好的解決方案。
注：思考一個問題，一台從庫掛了會怎樣？讀寫分離之讀的負載均衡策略怎麼容錯？
▲雙主+主從架構，看似完美的方案
1、高可用分析：高可用。
2、高性能分析：高性能。
3、一致性分析：存在數據一致性問題。請看，一致性解決方案。
4、擴展性分析：可以通過加從庫來擴展讀性能，進而提高整體性能。（帶來的問題同方案二）
5、可落地分析：同方案二，但數據同步又多了一層，數據延遲更嚴重。
☆原文PDF