問答專欄Q & A COLUMN
以mysql為列：
1：支撐高并發(fā)系統(tǒng)，一定會涉及事務(wù)，所以數(shù)據(jù)庫引擎必選innodb，innodb支持事務(wù)，事務(wù)級別根據(jù)業(yè)務(wù)而定，如果業(yè)務(wù)數(shù)據(jù)一致性要求很高，事務(wù)就開啟序列化級別，這樣就完全隔離事務(wù)，但是會導(dǎo)致鎖資源競爭加劇。mysql的性能有一定的降低。
2：讀寫分離，數(shù)據(jù)庫分成主庫和從庫，主庫負責(zé)寫數(shù)據(jù)，叢庫負責(zé)讀數(shù)據(jù)。注意主從數(shù)據(jù)庫數(shù)據(jù)一致性問題。
3：冷熱數(shù)據(jù)分離，美團，餓了么部分設(shè)計采用冷熱數(shù)據(jù)分離，拿訂單來說，已送達訂單，主要的業(yè)務(wù)場景就是查詢，越往前的數(shù)據(jù)查詢的概率就越低。這就是冷數(shù)據(jù)。正在交易的訂單就是熱數(shù)據(jù)，需要時時查詢和更新。對于冷數(shù)據(jù)，可以放到redis緩存。這樣會增加查詢效率。
4：數(shù)據(jù)表設(shè)計，充分利用索引查詢。業(yè)務(wù)sql避免返回?zé)o用的行和列，禁止使用select *查詢，查詢的時候加limit，盡可能返回滿足要求的行。對于復(fù)雜的sql，考慮拆分sql，拆分sql有一個好處，重復(fù)查詢的sql，第二次查詢會放到mysql的緩沖區(qū)，避免重復(fù)操作磁盤，提高訪問的性能。
5：分庫分表。比如業(yè)務(wù)數(shù)據(jù)按月分等。一定程度緩解增刪改查的壓力。
希望對你有一定的幫助。謝謝。
評論0
加載中...
之前做過一個每天訪問量達到800w的系統(tǒng)，簡單說下自己的見解！
從整個應(yīng)用系統(tǒng)來看，想要支持超高并發(fā)量，負載均衡，緩存，消息中間件，數(shù)據(jù)庫讀寫分離，分庫分表等必不可少，既然文章只問了數(shù)據(jù)庫系統(tǒng)，那就只談數(shù)據(jù)庫！
數(shù)據(jù)庫層面，一般無外乎是主從復(fù)制，讀寫分離，分庫分表這些東西！
1，從單臺數(shù)據(jù)庫性能來看，單個mysql實例最大連接數(shù)為16384，就是說在同一時間最多能容納那么多的訪問量，同時受服務(wù)器CPU，內(nèi)存，硬盤等的影響，但是在實際應(yīng)用中能達到2000就不錯了！
需要使用druid等數(shù)據(jù)庫監(jiān)控中間件，實時的監(jiān)控數(shù)據(jù)庫連接，sql效率等各種指標(biāo)，在達到瓶頸之前找到辦法，show status;這個指令也可以方便的查看數(shù)據(jù)庫實例的各項指標(biāo)
單臺數(shù)據(jù)庫實例配置最優(yōu)化是保證整個數(shù)據(jù)庫集群最優(yōu)化的基本保證！
2，數(shù)據(jù)庫集群:以分庫分表為例，分庫分表的方式有很多，比如mycat，Sharding-jdbc等。
分庫分表的思想很簡單，比如單表1億的數(shù)據(jù)量，查詢效率很低，如果使用8庫1024表拆分，每張表中的數(shù)據(jù)不會超過10萬，對數(shù)據(jù)庫來說不存在任何瓶頸，就算總數(shù)據(jù)量達到100億，單表的查詢也不會慢！
拆分的策略通常以某個全局唯一的業(yè)務(wù)主鍵使用某種方式(比如hash取模，按月份等等)進行分庫分表的計算！
那么問題來了，全局唯一的字段怎么獲取？普通的數(shù)據(jù)庫主鍵自增，uuid等不再合適，可以使用redis，zookeeper等獲取全局唯一的id，具體可參見之前的其他回答！
問題:分庫分表之后存在跨庫join的問題，通常的解決方式為1，盡量使用分庫分表主鍵能保證在同一庫，同一類型的表中進行連接查詢，2，增加專門的查詢庫:將常用的數(shù)據(jù)字段冗余到查詢庫中，方便連接查詢和常用字段的快速查詢；
4，sql優(yōu)化：最基本的條件查詢，count，分組等使用索引字段等避免全局查詢，避免null值判斷，避免使用not in，避免無效的like語句，避免查詢的時候使用函數(shù)操作等等！
5，像秒殺系統(tǒng)等這種瞬時高并發(fā)，最好借助緩存系統(tǒng)來完成！
總而言之，數(shù)據(jù)庫是整個應(yīng)用系統(tǒng)當(dāng)中最核心，也是最容易出問題的地方，做好監(jiān)控，提前預(yù)防才能保證系統(tǒng)訪問量的增長！
評論0
加載中...
這個問題的需求不夠明確，主要是業(yè)務(wù)方面。
比如是一個百萬日活的IM系統(tǒng)。
則百萬日活的，假定有1000萬用戶的系統(tǒng)，用MYSQL基本可以不用分庫分表（可以采用讀寫分離）。
主要是緩存系統(tǒng)的設(shè)計，常見的比如redis，可以用戶全緩存在redis中，只有用戶更改時才回寫（回寫也可以先寫緩存，再異步刷入庫中）。這樣的設(shè)計，就用戶表而言，基本是沒有多少負載的。
真正復(fù)雜的是業(yè)務(wù)本身，比如是一個論壇，可能一天的新貼，回復(fù)等會產(chǎn)生巨量的數(shù)據(jù)。或是一個電商系統(tǒng)，商品，訂單等。這些沒有數(shù)據(jù)量都無法評估。
只是總體來看，用MYSQL（讀寫分離，分表設(shè)計）+緩存 是夠用了。
評論0
加載中...
日活都百萬了，那么我估算一下場景
建議使用TiDB即可
TiDB 是 PingCAP 公司自主設(shè)計、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，是一款同時支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數(shù)據(jù)庫、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。目標(biāo)是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場景。
五大核心特性：
評論0
加載中...
那活百萬就算全部集中在高峰期十個小時。小時也就10萬。
就算每秒有10萬的點擊。
備兩臺緩存的機器應(yīng)該就足夠了。
評論0
加載中...
0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
