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