国产亚洲av在线,国产高清,欧美激情,国产精品久久久久7777,国产精品人成在线观看,国产精品永久免费视频

IT之道-艾銻知道

it運(yùn)維知識(shí)教您緩存的三種方式


2020-04-03 16:53 作者:艾銻無(wú)限 瀏覽量:


從打破雞蛋這個(gè)故事中我們能學(xué)到什么
 
大多數(shù)管理者的困境


 
 


 
 
作為一名專業(yè)的教練,我經(jīng)常會(huì)被問到:

教練,我的團(tuán)隊(duì)溝通不暢該怎么辦?

教練,我的團(tuán)隊(duì)執(zhí)行力不強(qiáng)要如何處理?

教練,我的團(tuán)隊(duì)里沒有人才可用要如何做呢?

教練,我的團(tuán)隊(duì)士氣很低怎樣激勵(lì)他們呢?

教練,我的團(tuán)隊(duì)經(jīng)常達(dá)不成目標(biāo)能給些建議嗎?

教練,我的團(tuán)隊(duì)沒有凝聚力有什么好的方法嗎?

教練,我的團(tuán)隊(duì)沒有能量,我要怎么給他們賦能呢?
……
 
教練與企業(yè)管理者的對(duì)話:



 
 
 

每當(dāng)這個(gè)時(shí)候,我都會(huì)問這些企業(yè)的負(fù)責(zé)人,
 
一個(gè)雞蛋如果從外給予壓力,最終會(huì)怎什么呢?

他們有的說(shuō),會(huì)形成碎雞蛋,也有人說(shuō),打破了可以做成炒雞蛋,還有人說(shuō),可以用雞蛋清敷在臉上做面膜,人類的想象力總是讓人出乎意料……

我又問到,
 
那如果從里面給到動(dòng)力,最后破殼而出,又會(huì)發(fā)生什么呢?

 
 
 
 
所有人的回答幾乎都是一樣的,一只有著生命力的小雞.

我又問了一個(gè)問題,
 
我說(shuō)假如你可以讓你的員工具備破殼而出的生命力,你覺得企業(yè)會(huì)發(fā)生什么呢?

他們說(shuō),那簡(jiǎn)直太棒了,每個(gè)人都能自發(fā)地去做事,而且?guī)еで楹蛣?dòng)力,整個(gè)企業(yè)一定朝氣蓬勃,充滿斗志,但是,教練,我怎么做才能讓他們具備這樣的生命力呢?
 
我說(shuō),這是一個(gè)好問題,你覺得母雞是怎么做的呢?

他們說(shuō),母雞每天都會(huì)坐在雞蛋上,哪都不去玩,全身心投入,給到雞蛋持續(xù)的關(guān)懷和溫度,并且堅(jiān)持21天,直到小雞可以從蛋殼中走出來(lái).


 
 

 
 
那母雞孵化小雞這個(gè)過程給到你什么啟發(fā)呢?
 
他們說(shuō),我也需要給到自己團(tuán)隊(duì)這樣的關(guān)懷和支持,用心去孵化他們內(nèi)在的動(dòng)力,幫助他們釋放出潛能,為他們創(chuàng)造適合他們成長(zhǎng)的環(huán)境和土壤,以及給予更多的陽(yáng)光和水,我相信他們一定能由內(nèi)而外的活出有能量的狀態(tài),到那時(shí)無(wú)論什么困難和挑戰(zhàn)都會(huì)迎刃而解.
 
每個(gè)人都是自己生命中的天才

 

 
 
他們分享完我就直接鼓掌,我一直都認(rèn)為,每個(gè)人都是自己生命中的天才,而且我也是這樣去踐行的,無(wú)論是多大的企業(yè)家,還是最普通的員工都可以活出自己內(nèi)在的智慧,并且解決生命中的困境.

馬斯洛也曾說(shuō)過類似的話,他說(shuō)“人并不是被澆鑄或塑造成人的,而是依靠自身實(shí)現(xiàn)潛能的,環(huán)境對(duì)人的成長(zhǎng)象土壤、陽(yáng)光和水對(duì)于植物一樣,只能促進(jìn)潛能的現(xiàn)實(shí)化。”
 
生命生長(zhǎng)需要時(shí)間



 

無(wú)論是打破一個(gè)雞蛋,還是一花一世界,萬(wàn)物皆具潛能,只是我們只盯在相上,只盯在結(jié)果上,卻沒有為結(jié)果投入更多的時(shí)間和耐心,即使我們今天看到的太陽(yáng)的光芒,也不是今天太陽(yáng)發(fā)出來(lái)的.

根據(jù)科學(xué)家的計(jì)算,從太陽(yáng)發(fā)出光到地球需要8分20秒左右的時(shí)間,這就意味著,當(dāng)我們生命中出現(xiàn)了至暗時(shí)刻,不用著急,也不用慌張,因?yàn)樘?yáng)光在路上,給它一點(diǎn)時(shí)間,至暗終會(huì)迎來(lái)光明.

以下文章由IT外包服務(wù)商北京艾銻無(wú)限科技發(fā)展公司整理
 

it運(yùn)維知識(shí)教您緩存的三種方式
 
 
緩存是現(xiàn)在系統(tǒng)中必不可少的模塊,并且已經(jīng)成為了高并發(fā)高性能架構(gòu)的一個(gè)關(guān)鍵組件?,F(xiàn)在我們來(lái)分析一下使用緩存的正確姿勢(shì)。

緩存能解決的問題

· 提升性能

絕大多數(shù)情況下,select 是出現(xiàn)性能問題最大的地方。一方面,select 會(huì)有很多像 join、group、order、like 等這樣豐富的語(yǔ)義,而這些語(yǔ)義是非常耗性能的;另一方面,大多 數(shù)應(yīng)用都是讀多寫少,所以加劇了慢查詢的問題。

分布式系統(tǒng)中遠(yuǎn)程調(diào)用也會(huì)耗很多性能,因?yàn)橛芯W(wǎng)絡(luò)開銷,會(huì)導(dǎo)致整體的響應(yīng)時(shí)間下降。為了挽救這樣的性能開銷,在業(yè)務(wù)允許的情況(不需要太實(shí)時(shí)的數(shù)據(jù))下,使用緩存是非常必要的事情。

· 緩解數(shù)據(jù)庫(kù)壓力

當(dāng)用戶請(qǐng)求增多時(shí),數(shù)據(jù)庫(kù)的壓力將大大增加,通過緩存能夠大大降低數(shù)據(jù)庫(kù)的壓力。

緩存的適用場(chǎng)景

· 對(duì)于數(shù)據(jù)實(shí)時(shí)性要求不高

對(duì)于一些經(jīng)常訪問但是很少改變的數(shù)據(jù),讀明顯多于寫,適用緩存就很有必要。比如一些網(wǎng)站配置項(xiàng)。

· 對(duì)于性能要求高

比如一些秒殺活動(dòng)場(chǎng)景。

緩存三種模式

一般來(lái)說(shuō),緩存有以下三種模式:

· Cache Aside 更新模式

· Read/Write Through 更新模式

· Write Behind Caching 更新模式

通俗一點(diǎn)來(lái)講就是,同時(shí)更新緩存和數(shù)據(jù)庫(kù)(Cache Aside 更新模式);先更新緩存,緩存負(fù)責(zé)同步更新數(shù)據(jù)庫(kù)(Read/Write Through 更新模式);先更新緩存,緩存定時(shí)異步更新數(shù)據(jù)庫(kù)(Write Behind Caching 更新模式)。這三種模式各有優(yōu)劣,可以根據(jù)業(yè)務(wù)場(chǎng)景選擇使用。

Cache Aside 更新模式

這是最常用的緩存模式了,具體的流程是:

· 失效:應(yīng)用程序先從 cache 取數(shù)據(jù),沒有得到,則從數(shù)據(jù)庫(kù)中取數(shù)據(jù),成功后,放到緩存中。

· 命中:應(yīng)用程序從 cache 中取數(shù)據(jù),取到后返回。

· 更新:先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中,成功后,再讓緩存失效。

 

Cache Aside 更新模式流程圖

注意我們上面所提到的,緩存更新時(shí)先更新數(shù)據(jù)庫(kù),然后在讓緩存失效。那么為什么不是直接更新緩存呢?這里有一些緩存更新的坑,我們需要避免入坑。
 
避坑指南一

先更新數(shù)據(jù)庫(kù),再更新緩存。這種做法最大的問題就是兩個(gè)并發(fā)的寫操作導(dǎo)致臟數(shù)據(jù)。如下圖(以Redis和Mysql為例),兩個(gè)并發(fā)更新操作,數(shù)據(jù)庫(kù)先更新的反而后更新緩存,數(shù)據(jù)庫(kù)后更新的反而先更新緩存。這樣就會(huì)造成數(shù)據(jù)庫(kù)和緩存中的數(shù)據(jù)不一致,應(yīng)用程序中讀取的都是臟數(shù)據(jù)。


 
 

 
兩個(gè)并發(fā)的寫操作導(dǎo)致臟數(shù)據(jù)
 
避坑指南二

先刪除緩存,再更新數(shù)據(jù)庫(kù)。這個(gè)邏輯是錯(cuò)誤的,因?yàn)?strong>兩個(gè)并發(fā)的讀和寫操作導(dǎo)致臟數(shù)據(jù)。如下圖(以Redis和Mysql為例)。假設(shè)更新操作先刪除了緩存,此時(shí)正好有一個(gè)并發(fā)的讀操作,沒有命中緩存后從數(shù)據(jù)庫(kù)中取出老數(shù)據(jù)并且更新回緩存,這個(gè)時(shí)候更新操作也完成了數(shù)據(jù)庫(kù)更新。此時(shí),數(shù)據(jù)庫(kù)和緩存中的數(shù)據(jù)不一致,應(yīng)用程序中讀取的都是原來(lái)的數(shù)據(jù)(臟數(shù)據(jù))。

 
 

 
兩個(gè)并發(fā)的讀和寫操作導(dǎo)致臟數(shù)據(jù)
 
避坑指南三

先更新數(shù)據(jù)庫(kù),再刪除緩存。這種做法其實(shí)不能算是坑,在實(shí)際的系統(tǒng)中也推薦使用這種方式。但是這種方式理論上還是可能存在問題。如下圖(以Redis和Mysql為例),查詢操作沒有命中緩存,然后查詢出數(shù)據(jù)庫(kù)的老數(shù)據(jù)。此時(shí)有一個(gè)并發(fā)的更新操作,更新操作在讀操作之后更新了數(shù)據(jù)庫(kù)中的數(shù)據(jù)并且刪除了緩存中的數(shù)據(jù)。然而讀操作將從數(shù)據(jù)庫(kù)中讀取出的老數(shù)據(jù)更新回了緩存。這樣就會(huì)造成數(shù)據(jù)庫(kù)和緩存中的數(shù)據(jù)不一致,應(yīng)用程序中讀取的都是原來(lái)的數(shù)據(jù)(臟數(shù)據(jù))。

 
 


 
但是,仔細(xì)想一想,這種并發(fā)的概率極低。因?yàn)檫@個(gè)條件需要發(fā)生在讀緩存時(shí)緩存失效,而且有一個(gè)并發(fā)的寫操作。實(shí)際上數(shù)據(jù)庫(kù)的寫操作會(huì)比讀操作慢得多,而且還要加鎖,而讀操作必需在寫操作前進(jìn)入數(shù)據(jù)庫(kù)操作,又要晚于寫操作更新緩存,所有這些條件都具備的概率并不大。但是為了避免這種極端情況造成臟數(shù)據(jù)所產(chǎn)生的影響,我們還是要為緩存設(shè)置過期時(shí)間。
 
Read/Write Through 更新模式


在上面的 Cache Aside 更新模式中,應(yīng)用代碼需要維護(hù)兩個(gè)數(shù)據(jù)存儲(chǔ),一個(gè)是緩存(Cache),一個(gè)是數(shù)據(jù)庫(kù)(Repository)。而在Read/Write Through 更新模式中,應(yīng)用程序只需要維護(hù)緩存,數(shù)據(jù)庫(kù)的維護(hù)工作由緩存代理了。

 
 

 
Read Through

Read Through 模式就是在查詢操作中更新緩存,也就是說(shuō),當(dāng)緩存失效的時(shí)候,Cache Aside 模式是由調(diào)用方負(fù)責(zé)把數(shù)據(jù)加載入緩存,而 Read Through 則用緩存服務(wù)自己來(lái)加載。

Write Through

Write Through 模式和 Read Through 相仿,不過是在更新數(shù)據(jù)時(shí)發(fā)生。當(dāng)有數(shù)據(jù)更新的時(shí)候,如果沒有命中緩存,直接更新數(shù)據(jù)庫(kù),然后返回。如果命中了緩存,則更新緩存,然后由緩存自己更新數(shù)據(jù)庫(kù)(這是一個(gè)同步操作)。

Write Behind Caching 更新模式

Write Behind Caching 更新模式就是在更新數(shù)據(jù)的時(shí)候,只更新緩存,不更新數(shù)據(jù)庫(kù),而我們的緩存會(huì)異步地批量更新數(shù)據(jù)庫(kù)。這個(gè)設(shè)計(jì)的好處就是直接操作內(nèi)存速度快。因?yàn)楫惒剑琖rite Behind Caching 更新模式還可以合并對(duì)同一個(gè)數(shù)據(jù)的多次操作到數(shù)據(jù)庫(kù),所以性能的提高是相當(dāng)可觀的。

但其帶來(lái)的問題是,數(shù)據(jù)不是強(qiáng)一致性的,而且可能會(huì)丟失。另外,Write Behind Caching 更新模式實(shí)現(xiàn)邏輯比較復(fù)雜,因?yàn)樗枰_認(rèn)有哪些數(shù)據(jù)是被更新了的,哪些數(shù)據(jù)需要刷到持久層上。只有在緩存需要失效的時(shí)候,才會(huì)把它真正持久起來(lái)。

 
 

 
Write Behind Caching 更新模式

總結(jié)

三種緩存模式的優(yōu)缺點(diǎn):

Cache Aside 更新模式實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單,但是需要維護(hù)兩個(gè)數(shù)據(jù)存儲(chǔ),一個(gè)是緩存(Cache),一個(gè)是數(shù)據(jù)庫(kù)(Repository)。

Read/Write Through 更新模式只需要維護(hù)一個(gè)數(shù)據(jù)存儲(chǔ)(緩存),但是實(shí)現(xiàn)起來(lái)要復(fù)雜一些。

Write Behind Caching 更新模式和Read/Write Through 更新模式類似,區(qū)別是Write Behind Caching 更新模式的數(shù)據(jù)持久化操作是異步的,但是Read/Write Through 更新模式的數(shù)據(jù)持久化操作是同步的。優(yōu)點(diǎn)是直接操作內(nèi)存速度快,多次操作可以合并持久化到數(shù)據(jù)庫(kù)。缺點(diǎn)是數(shù)據(jù)可能會(huì)丟失,例如系統(tǒng)斷電等。

緩存是通過犧牲強(qiáng)一致性來(lái)提高性能的。所以使用緩存提升性能,就是會(huì)有數(shù)據(jù)更新的延遲。這需要我們?cè)谠O(shè)計(jì)時(shí)結(jié)合業(yè)務(wù)仔細(xì)思考是否適合用緩存。然后緩存一定要設(shè)置過期時(shí)間,這個(gè)時(shí)間太短太長(zhǎng)都不好,太短的話請(qǐng)求可能會(huì)比較多的落到數(shù)據(jù)庫(kù)上,這也意味著失去了緩存的優(yōu)勢(shì)。太長(zhǎng)的話緩存中的臟數(shù)據(jù)會(huì)使系統(tǒng)長(zhǎng)時(shí)間處于一個(gè)延遲的狀態(tài),而且系統(tǒng)中長(zhǎng)時(shí)間沒有人訪問的數(shù)據(jù)一直存在內(nèi)存中不過期,浪費(fèi)內(nèi)存。

相關(guān)文章

IT外包服務(wù)
二維碼 關(guān)閉