支撐日活百萬用戶的高并發(fā)系統(tǒng)，應(yīng)該如何設(shè)計(jì)其數(shù)據(jù)庫架構(gòu)？ ？以mysql為列：1：支撐高并發(fā)系統(tǒng)，一定會涉及事務(wù)，所以數(shù)據(jù)庫引擎必選innodb，innodb支持事務(wù)，事務(wù)級別根據(jù)業(yè)務(wù)而定，如果業(yè)務(wù)數(shù)

支撐日活百萬用戶的高并發(fā)系統(tǒng)，應(yīng)該如何設(shè)計(jì)其數(shù)據(jù)庫架構(gòu)？ ？

以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ù)庫分成主庫和從庫，主庫負(fù)責(zé)寫數(shù)據(jù)，叢庫負(fù)責(zé)讀數(shù)據(jù)。注意主從數(shù)據(jù)庫數(shù)據(jù)一致性問題。

3：冷熱數(shù)據(jù)分離，美團(tuán)，餓了么部分設(shè)計(jì)采用冷熱數(shù)據(jù)分離，拿訂單來說，已送達(dá)訂單，主要的業(yè)務(wù)場景就是查詢，越往前的數(shù)據(jù)查詢的概率就越低。這就是冷數(shù)據(jù)。正在交易的訂單就是熱數(shù)據(jù)，需要時(shí)時(shí)查詢和更新。對于冷數(shù)據(jù)，可以放到redis緩存。這樣會增加查詢效率。

4：數(shù)據(jù)表設(shè)計(jì)，充分利用索引查詢。業(yè)務(wù)sql避免返回?zé)o用的行和列，禁止使用select *查詢，查詢的時(shí)候加limit，盡可能返回滿足要求的行。對于復(fù)雜的sql，考慮拆分sql，拆分sql有一個好處，重復(fù)查詢的sql，第二次查詢會放到mysql的緩沖區(qū)，避免重復(fù)操作磁盤，提高訪問的性能。

5：分庫分表。比如業(yè)務(wù)數(shù)據(jù)按月分等。一定程度緩解增刪改查的壓力。

希望對你有一定的幫助。謝謝。

寫入mysql數(shù)據(jù)庫的數(shù)據(jù)量很大，數(shù)據(jù)庫架構(gòu)該怎么去設(shè)計(jì)？

對于這種大數(shù)據(jù)量系統(tǒng)業(yè)界已經(jīng)有不少成熟方案

最簡單的是讀寫分離，寫操作只在主庫寫，配置自動同步到從庫。部分讀操作改成操作從庫，減少主庫數(shù)據(jù)庫壓力。

還可以讓給應(yīng)用加一個redis緩存，查詢時(shí)先讀緩存，讀不到再讀數(shù)據(jù)庫。

如果改成這樣，壓力還是太大，就要考慮分表。

分表思路很多，例如把熱點(diǎn)數(shù)據(jù)放一張表，非熱點(diǎn)數(shù)據(jù)放一張表?；蛘甙从脩鬷d尾號做hash，分表分布在不同表。

如果讀寫要求已經(jīng)超過單機(jī)支撐能力，那就要考慮集群，你可以搜索一下怎么用mycat搭建數(shù)據(jù)庫集群

mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫分表之外，還有沒有其他的解決方式？

mysql在常規(guī)配置下，一般只能承受2000萬的數(shù)據(jù)量(同時(shí)讀寫，且表中有大文本字段，單臺服務(wù)器)。現(xiàn)在超過1億，并不斷增加的情況下，建議如下處理：

1 分表?？梢园磿r(shí)間，或按一定的規(guī)則拆分，做到查詢某一條數(shù)據(jù)庫，盡量在一個子表中即可。這是最有效的方法

2 讀寫分離。尤其是寫入，放在新表中，定期進(jìn)行同步。如果其中記錄不斷有update，最好將寫的數(shù)據(jù)放在 redis中，定期同步

3 表的大文本字段分離出來，成為獨(dú)立的新表。大文本字段，可以使用NOSQL數(shù)據(jù)庫

4 優(yōu)化架構(gòu)，或優(yōu)化SQL查詢，避免聯(lián)表查詢，盡量不要用count(*)， in，遞歸等消耗性能的語句

5 用內(nèi)存緩存，或在前端讀的時(shí)候，增加緩存數(shù)據(jù)庫。重復(fù)讀取時(shí)，直接從緩存中讀取。

上面是低成本的管理方法，基本幾臺服務(wù)器即可搞定，但是管理起來麻煩一些。

當(dāng)然，如果整體數(shù)據(jù)量特別大的話，也不在乎投入費(fèi)用的話，用集群吧，用TIDB吧