問答專欄Q & A COLUMN
以mysql為列：
1：支撐高并發系統，一定會涉及事務，所以數據庫引擎必選innodb，innodb支持事務，事務級別根據業務而定，如果業務數據一致性要求很高，事務就開啟序列化級別，這樣就完全隔離事務，但是會導致鎖資源競爭加劇。mysql的性能有一定的降低。
2：讀寫分離，數據庫分成主庫和從庫，主庫負責寫數據，叢庫負責讀數據。注意主從數據庫數據一致性問題。
3：冷熱數據分離，美團，餓了么部分設計采用冷熱數據分離，拿訂單來說，已送達訂單，主要的業務場景就是查詢，越往前的數據查詢的概率就越低。這就是冷數據。正在交易的訂單就是熱數據，需要時時查詢和更新。對于冷數據，可以放到redis緩存。這樣會增加查詢效率。
4：數據表設計，充分利用索引查詢。業務sql避免返回無用的行和列，禁止使用select *查詢，查詢的時候加limit，盡可能返回滿足要求的行。對于復雜的sql，考慮拆分sql，拆分sql有一個好處，重復查詢的sql，第二次查詢會放到mysql的緩沖區，避免重復操作磁盤，提高訪問的性能。
5：分庫分表。比如業務數據按月分等。一定程度緩解增刪改查的壓力。
希望對你有一定的幫助。謝謝。
評論0
加載中...
之前做過一個每天訪問量達到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，像秒殺系統等這種瞬時高并發，最好借助緩存系統來完成！
總而言之，數據庫是整個應用系統當中最核心，也是最容易出問題的地方，做好監控，提前預防才能保證系統訪問量的增長！
評論0
加載中...
這個問題的需求不夠明確，主要是業務方面。
比如是一個百萬日活的IM系統。
則百萬日活的，假定有1000萬用戶的系統，用MYSQL基本可以不用分庫分表（可以采用讀寫分離）。
主要是緩存系統的設計，常見的比如redis，可以用戶全緩存在redis中，只有用戶更改時才回寫（回寫也可以先寫緩存，再異步刷入庫中）。這樣的設計，就用戶表而言，基本是沒有多少負載的。
真正復雜的是業務本身，比如是一個論壇，可能一天的新貼，回復等會產生巨量的數據?；蚴且粋€電商系統，商品，訂單等。這些沒有數據量都無法評估。
只是總體來看，用MYSQL（讀寫分離，分表設計）+緩存 是夠用了。
評論0
加載中...
日活都百萬了，那么我估算一下場景
建議使用TiDB即可
TiDB 是 PingCAP 公司自主設計、研發的開源分布式關系型數據庫，是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式數據庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數據庫、兼容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各種應用場景。
五大核心特性：
評論0
加載中...
0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
