高并發(fā)下生成唯一訂單號 支撐日活百萬用戶的高并發(fā)系統(tǒng),應(yīng)該如何設(shè)計其數(shù)據(jù)庫架構(gòu)? ?
支撐日活百萬用戶的高并發(fā)系統(tǒng),應(yīng)該如何設(shè)計其數(shù)據(jù)庫架構(gòu)? ?以MySQL為列:1:要支持高并發(fā)系統(tǒng),必須涉及事務(wù),所以數(shù)據(jù)庫引擎必須選擇InnoDB。InnoDB支持事務(wù),事務(wù)級別取決于業(yè)務(wù)。如果業(yè)務(wù)
支撐日活百萬用戶的高并發(fā)系統(tǒng),應(yīng)該如何設(shè)計其數(shù)據(jù)庫架構(gòu)? ?
以MySQL為列:
1:要支持高并發(fā)系統(tǒng),必須涉及事務(wù),所以數(shù)據(jù)庫引擎必須選擇InnoDB。InnoDB支持事務(wù),事務(wù)級別取決于業(yè)務(wù)。如果業(yè)務(wù)數(shù)據(jù)一致性要求非常高,事務(wù)將開啟序列化級別,這將完全隔離事務(wù),但會導(dǎo)致對鎖資源的競爭加劇。MySQL的性能在一定程度上降低了。
2:數(shù)據(jù)庫分為主數(shù)據(jù)庫和從數(shù)據(jù)庫。主數(shù)據(jù)庫負責(zé)寫入數(shù)據(jù),集群數(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è)計,充分利用索引查詢。businesssql避免返回?zé)o用的行和列,禁止使用select*query,在查詢時增加限制,并盡可能返回滿足要求的行。對于復(fù)雜的SQL,請考慮拆分SQL。拆分SQL有一個優(yōu)點。對于重復(fù)查詢SQL,將第二次查詢放入MySQL緩沖區(qū),避免重復(fù)磁盤操作,提高訪問性能。
5:子數(shù)據(jù)庫和子表。例如,業(yè)務(wù)數(shù)據(jù)按月份分類。在一定程度上,增加、刪除、修改和檢查的壓力將得到緩解。
希望對您有所幫助。謝謝您。
你怎么看待滿嘴高并發(fā),編碼能力卻稀松平常的程序員?
我是磚頭人。我來回答。
高并發(fā)的核心原則是網(wǎng)絡(luò)io的事件處理機制。在細節(jié)方面,一些重要的環(huán)節(jié),如分組和分組,都比較復(fù)雜。但就大多數(shù)采訪和日常工作而言,真正了解反應(yīng)堆機制的核心幾乎就足夠了。關(guān)于高并發(fā)性,您可以閱讀更多關(guān)于陳碩的書。
關(guān)鍵問題是,如果編程能力很弱,那么問題就很大。簡單地說,如果你給一個任務(wù)或解決一個問題,如果你的動手能力很弱,你可能會很長時間不確定,容易犯錯誤。對于一個發(fā)展崗位來說,無論公司有多大或多小,在日常工作中都不會有額外的難度或大規(guī)模的發(fā)展。換言之,誰的基本技能更好,誰的任務(wù)往往完成得又快又好。
動手能力弱,有一種特別簡單直接的改進方法,就是刷leetcode等,先寫代碼。不管用什么語言,先多寫,多寫自然不會松懈。
然后從簡單的面向?qū)ο蟮阶罨镜膬扇N設(shè)計模式,從串行到并行,結(jié)合自己的編程語言,對語言的特點逐漸了解,過程就像刷題目一樣,寫代碼加深印象。學(xué)習(xí)一門新的編程語言也是如此。
對大多數(shù)人來說,要成為一名優(yōu)秀的程序員并不容易,但要成為一名合格的員工并付出足夠的努力是可以的。好腦子不如壞筆好。