更新時(shí)間:2020年07月22日18時(shí)15分 來(lái)源:傳智播客 瀏覽次數(shù):
1、單例設(shè)計(jì)模式?
單例—將只會(huì)初始化一次的操作,可以封裝到單列中—優(yōu)化單例—始終只需要初始化一個(gè)對(duì)象的方案,可以采用單例---數(shù)據(jù)庫(kù)鏈接用單例ip + 端口 + 賬號(hào)密碼 == 數(shù)據(jù)庫(kù)對(duì)象ip + 端口 + 賬號(hào)密碼 == 數(shù)據(jù)庫(kù)對(duì)象 ip + 端口 + 賬號(hào)密碼 == 數(shù)據(jù)庫(kù)對(duì)象
(1)單例只保留一個(gè)對(duì)象,可以減少系統(tǒng)資源開(kāi)銷。
(2)提高創(chuàng)建速度,每次都獲取已經(jīng)存在的對(duì)象因此提高創(chuàng)建速度--全局共享對(duì)象。
(3)單例在系統(tǒng)中只存在一個(gè)對(duì)象實(shí)例,因此任何地方使用此對(duì)象都是同一個(gè)對(duì)象避免多實(shí)例創(chuàng)建使用時(shí)產(chǎn)生的邏輯錯(cuò)誤。
代碼實(shí)現(xiàn)
單列在項(xiàng)目中應(yīng)用
python web 處理企業(yè)級(jí)電商業(yè)務(wù)中的秒殺功能:
(1)[秒殺]搶訂單環(huán)節(jié)一般會(huì)帶來(lái)2個(gè)問(wèn)題:
·高并發(fā):大量用戶同一時(shí)間搶購(gòu),網(wǎng)站瞬時(shí)訪問(wèn)量劇增,導(dǎo)致服務(wù)器壓力大
·超賣: 成功下訂單買到商品的人數(shù),超過(guò)數(shù)據(jù)庫(kù)最大庫(kù)存數(shù)量
(2)[秒殺]解決方案:
前端 [擴(kuò)容,靜態(tài)化,限流]:
A擴(kuò)容:加機(jī)器,這是最簡(jiǎn)單的方法,通過(guò)增加前端池的整體承載量來(lái)抗峰值。
B:靜態(tài)化 將頁(yè)面能夠靜態(tài)化的元素全部靜態(tài)化,并減少動(dòng)態(tài)元素,通過(guò)CDN來(lái)抗峰值ESI: 在web服務(wù)器上做動(dòng)態(tài)內(nèi)容請(qǐng)求,并將數(shù)據(jù)插入靜態(tài)頁(yè)面中,用戶拿到就一個(gè)完整的頁(yè)面,這種方案對(duì)服務(wù)器端性能有影響,但是用戶體驗(yàn)好。
CSI:在靜態(tài)頁(yè)面中單獨(dú)發(fā)送異步j(luò)s請(qǐng)求,從服務(wù)器動(dòng)態(tài)獲取數(shù)據(jù),這種服務(wù)器效果很好,但是用戶體驗(yàn)稍差
C:限流
ip限流:針對(duì)某一個(gè)ip地址,限制單位時(shí)間內(nèi)訪問(wèn)次數(shù)
D:其他
在活動(dòng)入口的地方設(shè)置關(guān)卡游戲或者問(wèn)題環(huán)節(jié),削弱峰值
后端出現(xiàn)高并發(fā)和超賣的原因:
I:首先MySQL自身對(duì)于高并發(fā)的處理性能就會(huì)出現(xiàn)問(wèn)題,一般來(lái)說(shuō),MySQL的處理性能會(huì)隨著并發(fā)thread上升而上升,但是到了一定的并發(fā)度之后會(huì)出現(xiàn)明顯的拐點(diǎn),之后一路下降,最終甚至?xí)葐蝨hread的性能還要差。
II:其次,超賣的根結(jié)在于減庫(kù)存操作是一個(gè)事務(wù)操作,需要先select,然后insert,最后update -1。最后這個(gè)-1操作是不能出現(xiàn)負(fù)數(shù)的,但是當(dāng)多用戶在有庫(kù)存的情況下并發(fā)操作,出現(xiàn)負(fù)數(shù)這是無(wú)法避免的。
III:最后,當(dāng)減庫(kù)存和高并發(fā)碰到一起的時(shí)候,由于操作的庫(kù)存數(shù)目在同一行,就會(huì)出現(xiàn)爭(zhēng)搶InnoDB行鎖的問(wèn)題,導(dǎo)致出現(xiàn)互相等待甚至死鎖,從而大大降低MySQL的處理性能,最終導(dǎo)致前端頁(yè)面出現(xiàn)超時(shí)異常。
解決方案1:
將存庫(kù)從MySQL前移到Redis中,所有的寫操作放到內(nèi)存中,由于Redis中不存在鎖故不會(huì)出現(xiàn)互相等待,并且由于Redis的寫性能和讀性能都遠(yuǎn)高于MySQL,這就解決了高并發(fā)下的性能問(wèn)題。然后通過(guò)隊(duì)列等異步手段,將變化的數(shù)據(jù)異步寫入到DB中。
優(yōu)點(diǎn):解決性能問(wèn)題
缺點(diǎn):沒(méi)有解決超賣問(wèn)題,同時(shí)由于異步寫入DB,存在某一時(shí)刻DB和Redis中數(shù)據(jù)不一致的風(fēng)險(xiǎn)。
解決方案2:
引入隊(duì)列,然后將所有寫DB操作在單隊(duì)列中排隊(duì),完全串行處理。當(dāng)達(dá)到庫(kù)存閥值的時(shí)候就不在消費(fèi)隊(duì)列,并關(guān)閉購(gòu)買功能。這就解決了超賣問(wèn)題。
優(yōu)點(diǎn):解決超賣問(wèn)題,略微提升性能。
缺點(diǎn):性能受限于隊(duì)列處理機(jī)處理性能和DB的寫入性能中最短的那個(gè),另外多商品同時(shí)搶購(gòu)的時(shí)候需要準(zhǔn)備多條隊(duì)列。
解決方案3:
將寫操作前移到Memcached中,同時(shí)利用Memcached的輕量級(jí)的鎖機(jī)制CAS來(lái)實(shí)現(xiàn)減庫(kù)存操作。
優(yōu)點(diǎn):讀寫在內(nèi)存中,操作性能快,引入輕量級(jí)鎖之后可以保證同一時(shí)刻只有一個(gè)寫入成功,解決減庫(kù)存問(wèn)題。
缺點(diǎn):沒(méi)有實(shí)測(cè),基于CAS的特性不知道高并發(fā)下是否會(huì)出現(xiàn)大量更新失敗?不過(guò)加鎖之后肯定對(duì)并發(fā)性能會(huì)有影響。
解決方案4:
將提交操作變成兩段式,先申請(qǐng)后確認(rèn)。然后利用Redis的原子自增操作(相比較MySQL的自增來(lái)說(shuō)沒(méi)有空洞),同時(shí)利用Redis的事務(wù)特性來(lái)發(fā)號(hào),保證拿到小于等于庫(kù)存閥值的號(hào)的人都可以成功提交訂單。然后數(shù)據(jù)異步更新到DB中。
優(yōu)點(diǎn):解決超賣問(wèn)題,庫(kù)存讀寫都在內(nèi)存中,故同時(shí)解決性能問(wèn)題。缺點(diǎn):由于異步寫入DB,可能存在數(shù)據(jù)不一致。另可能存在少買,也就是如果拿到號(hào)的人不真正下訂單,可能庫(kù)存減為0,但是訂單數(shù)并沒(méi)有達(dá)到庫(kù)存閥值。
服務(wù)器解決性能瓶頸問(wèn)題
1、排隊(duì): 可以使用消息隊(duì)列,將同步請(qǐng)求轉(zhuǎn)化成異步請(qǐng)求,中間通過(guò)一個(gè)消息隊(duì)列在一端[隊(duì)列入口]承接瞬時(shí)的流量峰值,在另一端[隊(duì)列出口]平滑的將消息推送出去;
2、設(shè)置關(guān)卡: 在活動(dòng)入口的地方設(shè)置關(guān)卡游戲或者問(wèn)題環(huán)節(jié),削弱峰值;
3、分層過(guò)濾: 秒殺請(qǐng)求先經(jīng)過(guò)CDN ==> 前端系統(tǒng) ==> 后端系統(tǒng) 過(guò)濾掉無(wú)效請(qǐng)求。
猜你喜歡
Python+人工智能培訓(xùn)課程
北京校區(qū)