建站
咨詢
售后
建站咨詢
新聞中心
隨著數(shù)據(jù)量的不斷增長(zhǎng)，數(shù)據(jù)庫(kù)讀取的性能成為影響系統(tǒng)性能的重要因素之一。為了提高數(shù)據(jù)庫(kù)的讀取性能，我們常常需要采用一些優(yōu)化措施，其中最常見(jiàn)的一種措施就是緩存讀取。緩存讀取是指將數(shù)據(jù)庫(kù)中經(jīng)常讀取的數(shù)據(jù)放入緩存中，以減少磁盤IO的操作，提高讀取性能。
成都創(chuàng)新互聯(lián)公司堅(jiān)信：善待客戶，將會(huì)成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。十年網(wǎng)站建設(shè)經(jīng)驗(yàn)成都創(chuàng)新互聯(lián)公司是成都老牌網(wǎng)站營(yíng)銷服務(wù)商,為您提供網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、H5高端網(wǎng)站建設(shè)、網(wǎng)站制作、品牌網(wǎng)站建設(shè)、微信小程序定制開(kāi)發(fā)服務(wù),給眾多知名企業(yè)提供過(guò)好品質(zhì)的建站服務(wù)。
緩存讀取的基本原理
在了解緩存讀取的優(yōu)化原理之前，我們需要先理解一下數(shù)據(jù)庫(kù)的讀取過(guò)程。數(shù)據(jù)庫(kù)的讀取過(guò)程包括兩個(gè)階段：緩存讀取和磁盤讀取。
緩存讀取指的是將數(shù)據(jù)從磁盤讀入內(nèi)存，這個(gè)過(guò)程會(huì)消耗一定的時(shí)間，但相對(duì)于磁盤讀取來(lái)說(shuō)，速度還是較快的。在數(shù)據(jù)被成功讀取到內(nèi)存中之后，我們就可以從內(nèi)存中訪問(wèn)這些數(shù)據(jù)，這個(gè)過(guò)程是非常快速的。
磁盤讀取是指直接從磁盤中讀取數(shù)據(jù)，這個(gè)過(guò)程會(huì)消耗比較多的時(shí)間，所以我們通常盡量避免磁盤讀取，而采用緩存讀取。
緩存讀取的原理就是：我們將經(jīng)常讀取的數(shù)據(jù)放入內(nèi)存中，以便我們?cè)谛枰x取這些數(shù)據(jù)時(shí)，可以直接從內(nèi)存中讀取數(shù)據(jù)，避免了磁盤IO操作，提高了讀取性能。
緩存讀取的實(shí)現(xiàn)方式
緩存讀取可以通過(guò)多種方式來(lái)實(shí)現(xiàn)，最常見(jiàn)的方式有內(nèi)存緩存和硬件緩存兩種。
內(nèi)存緩存通常是指采用軟件實(shí)現(xiàn)的緩存機(jī)制。通過(guò)將經(jīng)常讀取的數(shù)據(jù)存儲(chǔ)在內(nèi)存中，我們可以優(yōu)化讀取性能，減少磁盤IO操作的頻率。常見(jiàn)的內(nèi)存緩存實(shí)現(xiàn)包括：數(shù)據(jù)連接池，二級(jí)緩存等。
硬件緩存通常是指采用硬件實(shí)現(xiàn)的緩存機(jī)制。通過(guò)使用內(nèi)存、磁盤、SSD等設(shè)備實(shí)現(xiàn)緩存機(jī)制，我們可以盡量避免磁盤IO操作，提高讀取性能。常見(jiàn)的硬件緩存實(shí)現(xiàn)包括：內(nèi)存緩存，RD控制器等。
緩存讀取的優(yōu)點(diǎn)
緩存讀取可以帶來(lái)多方面的優(yōu)點(diǎn)，包括：
1.提高讀取性能。通過(guò)將經(jīng)常讀取的數(shù)據(jù)放入緩存中，我們可以直接從內(nèi)存中訪問(wèn)這些數(shù)據(jù)，避免了磁盤IO操作，提高了讀取性能。
2.減少資源占用。通過(guò)使用緩存，我們可以減少對(duì)磁盤的訪問(wèn)操作，降低磁盤IO操作的頻率，減少對(duì)系統(tǒng)資源的占用，提高系統(tǒng)的穩(wěn)定性和可靠性。
3.提高系統(tǒng)的可用性。通過(guò)使用緩存，我們可以減少對(duì)磁盤的訪問(wèn)操作，提高了系統(tǒng)的可用性，減少了系統(tǒng)因磁盤訪問(wèn)出現(xiàn)問(wèn)題而導(dǎo)致的系統(tǒng)崩潰和數(shù)據(jù)丟失等問(wèn)題。
緩存讀取的缺點(diǎn)
雖然緩存讀取可以帶來(lái)多方面的優(yōu)點(diǎn)，但其也存在一些缺點(diǎn)，包括：
1.數(shù)據(jù)一致性問(wèn)題。由于緩存數(shù)據(jù)可能被多個(gè)應(yīng)用程序共享，因此當(dāng)緩存中的數(shù)據(jù)發(fā)生變化時(shí)，需要及時(shí)通知其他應(yīng)用程序，否則可能會(huì)導(dǎo)致數(shù)據(jù)不一致的問(wèn)題。
2.容量限制。由于緩存機(jī)制需要占用內(nèi)存空間，因此其容量是有限的，當(dāng)緩存容量達(dá)到一定限制時(shí)，需要及時(shí)清理緩存，以便釋放內(nèi)存空間。
3.緩存失效問(wèn)題。由于緩存中的數(shù)據(jù)可能發(fā)生變化，因此緩存會(huì)存在失效的問(wèn)題，需要及時(shí)更新緩存數(shù)據(jù)，以保證數(shù)據(jù)的正確性。
緩存讀取是提高數(shù)據(jù)庫(kù)讀取性能的重要措施之一。通過(guò)將經(jīng)常訪問(wèn)的數(shù)據(jù)放入緩存中，可以減少磁盤IO操作，提高讀取性能。然而，在實(shí)踐中，我們需要根據(jù)實(shí)際情況選擇適當(dāng)?shù)木彺娣绞剑⒆⒁饨鉀Q緩存數(shù)據(jù)一致性、容量限制和失效問(wèn)題等。只有掌握了緩存讀取的優(yōu)化原理和實(shí)現(xiàn)方式，才能更好地提高數(shù)據(jù)庫(kù)讀取的性能。
相關(guān)問(wèn)題拓展閱讀：
- 如何保證數(shù)據(jù)庫(kù)緩存的最終一致性？
如何保證數(shù)據(jù)庫(kù)緩存的最終一致性？
對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)來(lái)說(shuō)，傳統(tǒng)的直接訪問(wèn)數(shù)據(jù)庫(kù)方式，主要通過(guò)數(shù)據(jù)分片、一主多從等方式來(lái)扛住讀寫(xiě)流量，但隨著數(shù)據(jù)量的積累和流量的激增，僅依賴數(shù)據(jù)庫(kù)來(lái)承接所有流量，不僅成本高、效率低、而且還伴隨著穩(wěn)定性降低的風(fēng)險(xiǎn)。
鑒于大部分業(yè)務(wù)通常是讀多寫(xiě)少（讀取頻率遠(yuǎn)遠(yuǎn)高于更新頻率），甚至存在讀操作數(shù)量高出寫(xiě)操作多個(gè)數(shù)量級(jí)的情況。因此， 在架構(gòu)設(shè)計(jì)中，常采用增加緩存層來(lái)提高系統(tǒng)的響應(yīng)能力 ，提升數(shù)據(jù)讀寫(xiě)性能、減少數(shù)據(jù)庫(kù)訪問(wèn)壓力，從而提升業(yè)務(wù)的穩(wěn)定性和訪問(wèn)體驗(yàn)。
根據(jù) CAP 原理，分布式系統(tǒng)在可用性、一致性和分區(qū)容錯(cuò)性上無(wú)法兼得，通常由于分區(qū)容錯(cuò)無(wú)法避免，所以一致性和可用性難以同時(shí)成立。對(duì)于緩存系統(tǒng)來(lái)說(shuō)， 如何保證其數(shù)據(jù)一致性是一個(gè)在應(yīng)用緩存的同時(shí)不得不解決的問(wèn)題 。
需要明確的是，緩存系統(tǒng)的數(shù)據(jù)一致性通常包括持久化層和緩存層的一致性、以及多級(jí)緩存之間的一致性，這里我們僅討論前者。持久化層和緩存層的一致性問(wèn)題也通常被稱為雙寫(xiě)一致性問(wèn)題，“雙寫(xiě)”意為數(shù)據(jù)既在數(shù)據(jù)庫(kù)中保存一份，也在緩存中保存一份。
對(duì)于一致性來(lái)說(shuō)，包含強(qiáng)一致性和弱一致性 ，強(qiáng)一致性保證寫(xiě)入后立即可以讀取，弱一致性則不保證立即蔽高握可以讀取寫(xiě)入后的值，而是盡可能的保證在經(jīng)過(guò)一定時(shí)間后可以讀取到，在弱一致性中應(yīng)用最為廣泛的模型則是最終一致性模型，即保證在一定時(shí)間之后寫(xiě)入和讀取達(dá)到一致的狀態(tài)。對(duì)于應(yīng)用緩存的大部分場(chǎng)景來(lái)說(shuō)，追求的則是最終一致性，少部分對(duì)數(shù)據(jù)一致性要求極高的場(chǎng)景則會(huì)追求強(qiáng)一致性。
為了達(dá)到最終一致性，針對(duì)不同的場(chǎng)景，業(yè)界逐步形成了下面這幾種應(yīng)用緩存的策略。
—
—
Cache-Aside
Cache-Aside 意為旁路緩存模式，是應(yīng)用最為廣泛的一種緩存策略。下面的圖示展示了它的讀寫(xiě)流程，來(lái)看看它是如何保證最終一致性的。在讀請(qǐng)求中，首先請(qǐng)求緩存，若緩存命中（cache hit），則直接返回緩存中的數(shù)據(jù)；若緩存未命中（cache miss），則查詢數(shù)據(jù)庫(kù)并將查詢結(jié)果更新至緩存，然后返回查詢出的數(shù)據(jù)（demand-filled look-aside ）。在寫(xiě)請(qǐng)求中，先更新數(shù)據(jù)庫(kù)，再刪除緩存（write-invalidate）。
1、為什么刪除緩存，而不是更新緩存？
在 Cache-Aside 中，對(duì)于讀請(qǐng)求的處理比較容易理解，但在寫(xiě)請(qǐng)求中，可能會(huì)有讀者提出疑問(wèn)，為什么要?jiǎng)h除緩存，而不是更新緩存？站在符合直覺(jué)的角度來(lái)看，更新緩存是一個(gè)容易被理解的方案，但站在性能和安全的角度，更新緩存則可能會(huì)導(dǎo)致一些不好的后果。
首先是性能 ，當(dāng)該緩存對(duì)應(yīng)的結(jié)果需要消耗大量的計(jì)算過(guò)程才能得到時(shí)，比如需要訪問(wèn)多宏慶張數(shù)據(jù)庫(kù)表并聯(lián)合計(jì)算，那么在寫(xiě)操作中更新緩存的動(dòng)作將會(huì)是一筆不小的開(kāi)銷。同時(shí)，當(dāng)寫(xiě)操作較多時(shí)，可能也會(huì)存在剛更新的緩存還沒(méi)有被讀取到，又再次被更新的情況（這常被稱為緩存擾動(dòng)），顯然，這樣的更新是白白消耗機(jī)器性能的，會(huì)導(dǎo)致緩存利用率不高。
而等到讀請(qǐng)求未命中緩存時(shí)再去更新，也符合懶加載的思路，需要時(shí)再進(jìn)行計(jì)算。刪除緩存的念圓操作不僅是冪等的，可以在發(fā)生異常時(shí)重試，而且寫(xiě)-刪除和讀-更新在語(yǔ)義上更加對(duì)稱。
其次是安全 ，在并發(fā)場(chǎng)景下，在寫(xiě)請(qǐng)求中更新緩存可能會(huì)引發(fā)數(shù)據(jù)的不一致問(wèn)題。參考下面的圖示，若存在兩個(gè)來(lái)自不同線程的寫(xiě)請(qǐng)求，首先來(lái)自線程 1 的寫(xiě)請(qǐng)求更新了數(shù)據(jù)庫(kù)（step 1），接著來(lái)自線程 2 的寫(xiě)請(qǐng)求再次更新了數(shù)據(jù)庫(kù)（step 3），但由于網(wǎng)絡(luò)延遲等原因，線程 1 可能會(huì)晚于線程 2 更新緩存（step 4 晚于 step 3），那么這樣便會(huì)導(dǎo)致最終寫(xiě)入數(shù)據(jù)庫(kù)的結(jié)果是來(lái)自線程 2 的新值，寫(xiě)入緩存的結(jié)果是來(lái)自線程 1 的舊值，即緩存落后于數(shù)據(jù)庫(kù)，此時(shí)再有讀請(qǐng)求命中緩存（step 5），讀取到的便是舊值。
2、為什么先更新數(shù)據(jù)庫(kù)，而不是先刪除緩存？
另外，有讀者也會(huì)對(duì)更新數(shù)據(jù)庫(kù)和刪除緩存的時(shí)序產(chǎn)生疑問(wèn)，那么為什么不先刪除緩存，再更新數(shù)據(jù)庫(kù)呢？在單線程下，這種方案看似具有一定合理性，這種合理性體現(xiàn)在刪除緩存成功。
但更新數(shù)據(jù)庫(kù)失敗的場(chǎng)景下，盡管緩存被刪除了，下次讀操作時(shí)，仍能將正確的數(shù)據(jù)寫(xiě)回緩存，相對(duì)于 Cache-Aside 中更新數(shù)據(jù)庫(kù)成功，刪除緩存失敗的場(chǎng)景來(lái)說(shuō)，先刪除緩存的方案似乎更合理一些。那么，先刪除緩存有什么問(wèn)題呢？
問(wèn)題仍然出現(xiàn)在并發(fā)場(chǎng)景下，首先來(lái)自線程 1 的寫(xiě)請(qǐng)求刪除了緩存（step 1），接著來(lái)自線程 2 的讀請(qǐng)求由于緩存的刪除導(dǎo)致緩存未命中，根據(jù) Cache-Aside 模式，線程 2 繼而查詢數(shù)據(jù)庫(kù)（step 2），但由于寫(xiě)請(qǐng)求通常慢于讀請(qǐng)求，線程 1 更新數(shù)據(jù)庫(kù)的操作可能會(huì)晚于線程 2 查詢數(shù)據(jù)庫(kù)后更新緩存的操作（step 4 晚于 step 3），那么這樣便會(huì)導(dǎo)致最終寫(xiě)入緩存的結(jié)果是來(lái)自線程 2 中查詢到的舊值，而寫(xiě)入數(shù)據(jù)庫(kù)的結(jié)果是來(lái)自線程 1 的新值，即緩存落后于數(shù)據(jù)庫(kù)，此時(shí)再有讀請(qǐng)求命中緩存（ step 5 ），讀取到的便是舊值。
另外，先刪除緩存，由于緩存中數(shù)據(jù)缺失，加劇數(shù)據(jù)庫(kù)的請(qǐng)求壓力，可能會(huì)增大緩存穿透出現(xiàn)的概率。
3、如果選擇先刪除緩存，再更新數(shù)據(jù)庫(kù)，那如何解決一致性問(wèn)題呢？
為了避免“先刪除緩存，再更新數(shù)據(jù)庫(kù)”這一方案在讀寫(xiě)并發(fā)時(shí)可能帶來(lái)的緩存臟數(shù)據(jù)，業(yè)界又提出了延時(shí)雙刪的策略，即在更新數(shù)據(jù)庫(kù)之后，延遲一段時(shí)間再次刪除緩存，為了保證第二次刪除緩存的時(shí)間點(diǎn)在讀請(qǐng)求更新緩存之后，這個(gè)延遲時(shí)間的經(jīng)驗(yàn)值通常應(yīng)稍大于業(yè)務(wù)中讀請(qǐng)求的耗時(shí)。
延遲的實(shí)現(xiàn)可以在代碼中 sleep 或采用延遲隊(duì)列。顯而易見(jiàn)的是，無(wú)論這個(gè)值如何預(yù)估，都很難和讀請(qǐng)求的完成時(shí)間點(diǎn)準(zhǔn)確銜接，這也是延時(shí)雙刪被詬病的主要原因。
4、那么 Cache-Aside 存在數(shù)據(jù)不一致的可能嗎？
在 Cache-Aside 中，也存在數(shù)據(jù)不一致的可能性。在下面的讀寫(xiě)并發(fā)場(chǎng)景下，首先來(lái)自線程 1 的讀請(qǐng)求在未命中緩存的情況下查詢數(shù)據(jù)庫(kù)（step 1），接著來(lái)自線程 2 的寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)（step 2），但由于一些極端原因，線程 1 中讀請(qǐng)求的更新緩存操作晚于線程 2 中寫(xiě)請(qǐng)求的刪除緩存的操作（step 4 晚于 step 3），那么這樣便會(huì)導(dǎo)致最終寫(xiě)入緩存中的是來(lái)自線程 1 的舊值，而寫(xiě)入數(shù)據(jù)庫(kù)中的是來(lái)自線程 2 的新值，即緩存落后于數(shù)據(jù)庫(kù)，此時(shí)再有讀請(qǐng)求命中緩存（step 5），讀取到的便是舊值。
這種場(chǎng)景的出現(xiàn)，不僅需要緩存失效且讀寫(xiě)并發(fā)執(zhí)行，而且還需要讀請(qǐng)求查詢數(shù)據(jù)庫(kù)的執(zhí)行早于寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)，同時(shí)讀請(qǐng)求的執(zhí)行完成晚于寫(xiě)請(qǐng)求。足以見(jiàn)得，這種 不一致場(chǎng)景產(chǎn)生的條件非常嚴(yán)格，在實(shí)際的生產(chǎn)中出現(xiàn)的可能性較小 。
除此之外，在并發(fā)環(huán)境下，Cache-Aside 中也存在讀請(qǐng)求命中緩存的時(shí)間點(diǎn)在寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)之后，刪除緩存之前，這樣也會(huì)導(dǎo)致讀請(qǐng)求查詢到的緩存落后于數(shù)據(jù)庫(kù)的情況。
雖然在下一次讀請(qǐng)求中，緩存會(huì)被更新，但如果業(yè)務(wù)層面對(duì)這種情況的容忍度較低，那么可以采用加鎖在寫(xiě)請(qǐng)求中保證“更新數(shù)據(jù)庫(kù)&刪除緩存”的串行執(zhí)行為原子性操作（同理也可對(duì)讀請(qǐng)求中緩存的更新加鎖）。 加鎖勢(shì)必會(huì)導(dǎo)致吞吐量的下降，故采取加鎖的方案應(yīng)該對(duì)性能的損耗有所預(yù)期。
—
—
補(bǔ)償機(jī)制
我們?cè)谏厦嫣岬搅?，?Cache-Aside 中可能存在更新數(shù)據(jù)庫(kù)成功，但刪除緩存失敗的場(chǎng)景，如果發(fā)生這種情況，那么便會(huì)導(dǎo)致緩存中的數(shù)據(jù)落后于數(shù)據(jù)庫(kù)，產(chǎn)生數(shù)據(jù)的不一致的問(wèn)題。
其實(shí)，不僅 Cache-Aside 存在這樣的問(wèn)題，在延時(shí)雙刪等策略中也存在這樣的問(wèn)題。針對(duì)可能出現(xiàn)的刪除失敗問(wèn)題，目前業(yè)界主要有以下幾種補(bǔ)償機(jī)制。
1、刪除重試機(jī)制
由于同步重試刪除在性能上會(huì)影響吞吐量，所以常通過(guò)引入消息隊(duì)列，將刪除失敗的緩存對(duì)應(yīng)的 key 放入消息隊(duì)列中，在對(duì)應(yīng)的消費(fèi)者中獲取刪除失敗的 key ，異步重試刪除。這種方法在實(shí)現(xiàn)上相對(duì)簡(jiǎn)單，但由于刪除失敗后的邏輯需要基于業(yè)務(wù)代碼的 trigger 來(lái)觸發(fā) ，對(duì)業(yè)務(wù)代碼具有一定入侵性。
鑒于上述方案對(duì)業(yè)務(wù)代碼具有一定入侵性，所以需要一種更加優(yōu)雅的解決方案，讓緩存刪除失敗的補(bǔ)償機(jī)制運(yùn)行在背后，盡量少的耦合于業(yè)務(wù)代碼。一個(gè)簡(jiǎn)單的思路是通過(guò)后臺(tái)任務(wù)使用更新時(shí)間戳或者版本作為對(duì)比獲取數(shù)據(jù)庫(kù)的增量數(shù)據(jù)更新至緩存中，這種方式在小規(guī)模數(shù)據(jù)的場(chǎng)景可以起到一定作用，但其擴(kuò)展性、穩(wěn)定性都有所欠缺。
一個(gè)相對(duì)成熟的方案是基于 MySQL 數(shù)據(jù)庫(kù)增量日志進(jìn)行解析和消費(fèi)，這里較為流行的是阿里巴巴開(kāi)源的作為 MySQL binlog 增量獲取和解析的組件 c（類似的開(kāi)源組件還有 Maxwell、Databus 等）。
c sever 模擬 MySQL slave 的交互協(xié)議，偽裝為 MySQL slave，向 MySQL master 發(fā)送 dump 協(xié)議，MySQL master 收到 dump 請(qǐng)求，開(kāi)始推送 binary log 給 slave （即 c sever ），c sever 解析 binary log 對(duì)象（原始為 byte 流），可由 c client 拉取進(jìn)行消費(fèi)，同時(shí) c server 也默認(rèn)支持將變更記錄投遞到 MQ 系統(tǒng)中，主動(dòng)推送給其他系統(tǒng)進(jìn)行消費(fèi)。
在 ack 機(jī)制的加持下，不管是推送還是拉取，都可以有效的保證數(shù)據(jù)按照預(yù)期被消費(fèi)。當(dāng)前版本的 c 支持的 MQ 有 Kafka 或者 RocketMQ。另外， c 依賴 ZooKeeper 作為分布式協(xié)調(diào)組件來(lái)實(shí)現(xiàn) HA ，c 的 HA 分為兩個(gè)部分：
那么，針對(duì)緩存的刪除操作便可以在 c client 或 consumer 中編寫(xiě)相關(guān)業(yè)務(wù)代碼來(lái)完成。這樣，結(jié)合數(shù)據(jù)庫(kù)日志增量解析消費(fèi)的方案以及 Cache-Aside 模型，在讀請(qǐng)求中未命中緩存時(shí)更新緩存（通常這里會(huì)涉及到復(fù)雜的業(yè)務(wù)邏輯），在寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)后刪除緩存，并基于日志增量解析來(lái)補(bǔ)償數(shù)據(jù)庫(kù)更新時(shí)可能的緩存刪除失敗問(wèn)題，在絕大多數(shù)場(chǎng)景下，可以有效的保證緩存的最終一致性。
另外需要注意的是，還應(yīng)該隔離事務(wù)與緩存，確保數(shù)據(jù)庫(kù)入庫(kù)后再進(jìn)行緩存的刪除操作。 比如考慮到數(shù)據(jù)庫(kù)的主從架構(gòu)，主從同步及讀從寫(xiě)主的場(chǎng)景下，可能會(huì)造成讀取到從庫(kù)的舊數(shù)據(jù)后便更新了緩存，導(dǎo)致緩存落后于數(shù)據(jù)庫(kù)的問(wèn)題，這就要求對(duì)緩存的刪除應(yīng)該確保在數(shù)據(jù)庫(kù)操作完成之后。所以，基于 binlog 增量日志進(jìn)行數(shù)據(jù)同步的方案，可以通過(guò)選擇解析從節(jié)點(diǎn)的 binlog，來(lái)避免主從同步下刪除緩存過(guò)早的問(wèn)題。
3、數(shù)據(jù)傳輸服務(wù) DTS
—
—
Read-Through
Read-Through 意為讀穿透模式，它的流程和 Cache-Aside 類似，不同點(diǎn)在于 Read-Through 中多了一個(gè)訪問(wèn)控制層，讀請(qǐng)求只和該訪問(wèn)控制層進(jìn)行交互，而背后緩存命中與否的邏輯則由訪問(wèn)控制層與數(shù)據(jù)源進(jìn)行交互，業(yè)務(wù)層的實(shí)現(xiàn)會(huì)更加簡(jiǎn)潔，并且對(duì)于緩存層及持久化層交互的封裝程度更高，更易于移植。
—
—
Write-Through
Write-Through 意為直寫(xiě)模式，對(duì)于 Write-Through 直寫(xiě)模式來(lái)說(shuō)，它也增加了訪問(wèn)控制層來(lái)提供更高程度的封裝。不同于 Cache-Aside 的是，Write-Through 直寫(xiě)模式在寫(xiě)請(qǐng)求更新數(shù)據(jù)庫(kù)之后，并不會(huì)刪除緩存，而是更新緩存。
這種方式的 優(yōu)勢(shì)在于讀請(qǐng)求過(guò)程簡(jiǎn)單 ，不需要查詢數(shù)據(jù)庫(kù)更新緩存等操作。但其劣勢(shì)也非常明顯，除了上面我們提到的更新數(shù)據(jù)庫(kù)再更新緩存的弊端之外，這種方案還會(huì)造成更新效率低，并且兩個(gè)寫(xiě)操作任何一次寫(xiě)失敗都會(huì)造成數(shù)據(jù)不一致。
如果要使用這種方案， 更好可以將這兩個(gè)操作作為事務(wù)處理，可以同時(shí)失敗或者同時(shí)成功，支持回滾，并且防止并發(fā)環(huán)境下的不一致 。另外，為了防止緩存擾動(dòng)的頻發(fā)，也可以給緩存增加 TTL 來(lái)緩解。
站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過(guò)分布式事務(wù)保證緩存層數(shù)據(jù)與持久化層數(shù)據(jù)的一致性，但在實(shí)際項(xiàng)目中，大多都對(duì)一致性的要求存在一些寬容度，所以在方案上往往有所折衷。
Write-Through 直寫(xiě)模式適合寫(xiě)操作較多，并且對(duì)一致性要求較高的場(chǎng)景，在應(yīng)用 Write-Through 模式時(shí)，也需要通過(guò)一定的補(bǔ)償機(jī)制來(lái)解決它的問(wèn)題。首先，在并發(fā)環(huán)境下，我們前面提到了先更新數(shù)據(jù)庫(kù)，再更新緩存會(huì)導(dǎo)致緩存和數(shù)據(jù)庫(kù)的不一致，那么先更新緩存，再更新數(shù)據(jù)庫(kù)呢？
這樣的操作時(shí)序仍然會(huì)導(dǎo)致下面這樣線程 1 先更新緩存，最后更新數(shù)據(jù)庫(kù)的情況，即由于線程 1 和 線程 2 的執(zhí)行不確定性導(dǎo)致數(shù)據(jù)庫(kù)和緩存的不一致。這種由于線程競(jìng)爭(zhēng)導(dǎo)致的緩存不一致，可以通過(guò)分布式鎖解決，保證對(duì)緩存和數(shù)據(jù)庫(kù)的操作僅能由同一個(gè)線程完成。對(duì)于沒(méi)有拿到鎖的線程，一是通過(guò)鎖的 timeout 時(shí)間進(jìn)行控制，二是將請(qǐng)求暫存在消息隊(duì)列中順序消費(fèi)。
在下面這種并發(fā)執(zhí)行場(chǎng)景下，來(lái)自線程 1 的寫(xiě)請(qǐng)求更新了數(shù)據(jù)庫(kù)，接著來(lái)自線程 2 的讀請(qǐng)求命中緩存，接著線程 1 才更新緩存，這樣便會(huì)導(dǎo)致線程 2 讀取到的緩存落后于數(shù)據(jù)庫(kù)。同理，先更新緩存后更新數(shù)據(jù)庫(kù)在寫(xiě)請(qǐng)求和讀請(qǐng)求并發(fā)時(shí)，也會(huì)出現(xiàn)類似的問(wèn)題。面對(duì)這種場(chǎng)景，我們也可以加鎖解決。
另在，在 Write-Through 模式下，不管是先更新緩存還是先更新數(shù)據(jù)庫(kù)，都存在更新緩存或者更新數(shù)據(jù)庫(kù)失敗的情況，上面提到的重試機(jī)制和補(bǔ)償機(jī)制在這里也是奏效的。
—
—
Write-Behind
Write behind 意為異步回寫(xiě)模式，它也具有類似 Read-Through/Write-Through 的訪問(wèn)控制層，不同的是，Write behind 在處理寫(xiě)請(qǐng)求時(shí)，只更新緩存而不更新數(shù)據(jù)庫(kù)，對(duì)于數(shù)據(jù)庫(kù)的更新，則是通過(guò)批量異步更新的方式進(jìn)行的，批量寫(xiě)入的時(shí)間點(diǎn)可以選在數(shù)據(jù)庫(kù)負(fù)載較低的時(shí)間進(jìn)行。
在 Write-Behind 模式下，寫(xiě)請(qǐng)求延遲較低，減輕了數(shù)據(jù)庫(kù)的壓力，具有較好的吞吐性。但數(shù)據(jù)庫(kù)和緩存的一致性較弱，比如當(dāng)更新的數(shù)據(jù)還未被寫(xiě)入數(shù)據(jù)庫(kù)時(shí)，直接從數(shù)據(jù)庫(kù)中查詢數(shù)據(jù)是落后于緩存的。同時(shí)，緩存的負(fù)載較大，如果緩存宕機(jī)會(huì)導(dǎo)致數(shù)據(jù)丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫(xiě)操作的場(chǎng)景，常用于電商秒殺場(chǎng)景中庫(kù)存的扣減。
—
—
Write-Around
如果一些非核心業(yè)務(wù)，對(duì)一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個(gè)緩存過(guò)期時(shí)間，在寫(xiě)請(qǐng)求中僅僅更新數(shù)據(jù)庫(kù)，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過(guò)過(guò)期時(shí)間失效。這種方案實(shí)現(xiàn)簡(jiǎn)單，但緩存中的數(shù)據(jù)和數(shù)據(jù)庫(kù)數(shù)據(jù)一致性較差，往往會(huì)造成用戶的體驗(yàn)較差，應(yīng)慎重選擇。
—
—
總結(jié)
在解決緩存一致性的過(guò)程中，有多種途徑可以保證緩存的最終一致性，應(yīng)該根據(jù)場(chǎng)景來(lái)設(shè)計(jì)合適的方案，讀多寫(xiě)少的場(chǎng)景下，可以選擇采用“Cache-Aside 結(jié)合消費(fèi)數(shù)據(jù)庫(kù)日志做補(bǔ)償”的方案，寫(xiě)多的場(chǎng)景下，可以選擇采用“Write-Through 結(jié)合分布式鎖”的方案 ，寫(xiě)多的極端場(chǎng)景下，可以選擇采用“Write-Behind”的方案。
數(shù)據(jù)庫(kù)緩沖讀取的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫(kù)緩沖讀取,提高數(shù)據(jù)庫(kù)讀取性能的關(guān)鍵——緩沖讀取,如何保證數(shù)據(jù)庫(kù)緩存的最終一致性？的信息別忘了在本站進(jìn)行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
當(dāng)前題目：提高數(shù)據(jù)庫(kù)讀取性能的關(guān)鍵——緩沖讀取(數(shù)據(jù)庫(kù)緩沖讀取)
網(wǎng)頁(yè)URL：http://m.5511xx.com/article/djpjdde.html
