支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？

之前做過一個每天訪問量達到800w的系統，簡單說下自己的見解！

從整個應用系統來看，想要支持超高併發量，負載均衡，緩存，消息中間件，數據庫讀寫分離，分庫分表等必不可少，既然文章只問了數據庫系統，那就只談數據庫！

數據庫層面，一般無外乎是主從複製，讀寫分離，分庫分表這些東西！

1，從單臺數據庫性能來看，單個mysql實例最大連接數為16384，就是說在同一時間最多能容納那麼多的訪問量，同時受服務器CPU，內存，硬盤等的影響，但是在實際應用中能達到2000就不錯了！

需要使用druid等數據庫監控中間件，實時的監控數據庫連接，sql效率等各種指標，在達到瓶頸之前找到辦法，show status;這個指令也可以方便的查看數據庫實例的各項指標

單臺數據庫實例配置最優化是保證整個數據庫集群最優化的基本保證！

2，數據庫集群:以分庫分表為例，分庫分表的方式有很多，比如mycat，Sharding-jdbc等。

分庫分表的思想很簡單，比如單表1億的數據量，查詢效率很低，如果使用8庫1024表拆分，每張表中的數據不會超過10萬，對數據庫來說不存在任何瓶頸，就算總數據量達到100億，單表的查詢也不會慢！

拆分的策略通常以某個全局唯一的業務主鍵使用某種方式(比如hash取模，按月份等等)進行分庫分表的計算！

那麼問題來了，全局唯一的字段怎麼獲取？普通的數據庫主鍵自增，uuid等不再合適，可以使用redis，zookeeper等獲取全局唯一的id，具體可參見之前的其他回答！

問題:分庫分表之後存在跨庫join的問題，通常的解決方式為1，儘量使用分庫分表主鍵能保證在同一庫，同一類型的表中進行連接查詢，2，增加專門的查詢庫:將常用的數據字段冗餘到查詢庫中，方便連接查詢和常用字段的快速查詢；

4，sql優化：最基本的條件查詢，count，分組等使用索引字段等避免全局查詢，避免null值判斷，避免使用not in，避免無效的like語句，避免查詢的時候使用函數操作等等！

5，像秒殺系統等這種瞬時高併發，最好藉助緩存系統來完成！

總而言之，數據庫是整個應用系統當中最核心，也是最容易出問題的地方，做好監控，提前預防才能保證系統訪問量的增長！