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