緩存由于其高性能，支持高并發(fā)的特性，在高并發(fā)的項目中不可或缺。被大家廣泛使用的有Redis，Memcached等。本文主要探討幾種常見的緩存的讀寫模式，以及如何來保證緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性。

這里大家可以關(guān)注一下我的個人專欄《PHP進階集中營》，每天會給大家即時分享一個最新的php技術(shù)資訊，有優(yōu)秀的PHP技術(shù)內(nèi)容，也歡迎分享在我的專欄。

PHP進階集中營?zhuanlan.zhihu.com

Cache-Aside

Cache-Aside可能是項目中最常見的一種模式。它是一種控制邏輯都實現(xiàn)在應(yīng)用程序中的模式。緩存不和數(shù)據(jù)庫直接進行交互，而是由應(yīng)用程序來同時和緩存以及數(shù)據(jù)庫打交道。Cache-Aside的名字正體現(xiàn)了這個模式，Cache在應(yīng)用的一旁(aside)。

讀數(shù)據(jù)時

程序需要判斷緩存中是否已經(jīng)存在數(shù)據(jù)。

當(dāng)緩存中已經(jīng)存在數(shù)據(jù)(也就是緩存命中，cache hit)，則直接從緩存中返回數(shù)據(jù)

當(dāng)緩存中不存在數(shù)據(jù)(也就是緩存未命中，cache miss)，則先從數(shù)據(jù)庫里讀取數(shù)據(jù)，并且存入緩存，然后返回數(shù)據(jù)

寫數(shù)據(jù)時，我們可以有以下兩種策略：

第一種策略：

更新數(shù)據(jù)庫

更新緩存

但這種策略有線程安全的問題，可能出現(xiàn)緩存和數(shù)據(jù)庫不一致。試想有兩個寫的線程，線程A和線程B

A寫數(shù)據(jù)庫

B后于A寫數(shù)據(jù)庫

B寫緩存

A寫緩存

緩存和數(shù)據(jù)庫中的數(shù)據(jù)不一致，緩存中的是臟數(shù)據(jù)

要解決線程安全的問題，我們可以加鎖，不過實現(xiàn)起來比較麻煩，因此我們不考慮這種寫策略，而使用第二種策略。

第二種策略：

更新數(shù)據(jù)庫

刪除緩存中對應(yīng)的數(shù)據(jù)

那么這種寫策略會有線程安全的問題嗎？有，試想一下有兩個線程，線程A讀，線程B寫

A讀數(shù)據(jù)，由于未命中那么從數(shù)據(jù)庫中取數(shù)據(jù)

B寫數(shù)據(jù)庫

B刪除緩存

A由于網(wǎng)絡(luò)延遲比較慢，將臟數(shù)據(jù)寫入緩存

但是這種情況可能性非常的小，需要同時滿足很多條件，近乎不太可能發(fā)生，所以我們一般都采用這種寫策略。另外可以對緩存中的數(shù)據(jù)設(shè)置合適的過期時間，即使發(fā)生的臟數(shù)據(jù)的情況，也不會發(fā)生很長時間。

應(yīng)用場景

應(yīng)用于緩存不支持Read-Through/Write-Through的系統(tǒng)。

優(yōu)點

• 緩存僅僅保存被請求的數(shù)據(jù)，屬于懶加載模式(Lazy Loading)，和下文的Write-Through模式相比，避免了任何數(shù)據(jù)都被寫入緩存造成緩存頻繁的更新。

缺點

• 當(dāng)發(fā)生緩存未命中的情況時，則會比較慢，因為要經(jīng)過三個步驟：查詢緩存，從數(shù)據(jù)庫讀取，寫入緩存。
• 復(fù)雜的邏輯都在應(yīng)用程序中，如果實現(xiàn)微服務(wù)，多個微服務(wù)中會有重復(fù)的邏輯代碼

Read-Through/Write-Through

這種模式中，應(yīng)用程序?qū)⒕彺孀鳛橹饕臄?shù)據(jù)源，而數(shù)據(jù)庫對于應(yīng)用程序是透明的，更新數(shù)據(jù)庫和從數(shù)據(jù)庫的讀取的任務(wù)都交給緩存來代理了，所以對于應(yīng)用程序來說，簡單很多。

Read-Through

由緩存配置一個讀模塊，它知道如何將數(shù)據(jù)庫中的數(shù)據(jù)寫入緩存。在數(shù)據(jù)被請求的時候，如果未命中，則將數(shù)據(jù)從數(shù)據(jù)庫載入緩存。

Write-Through

緩存配置一個寫模塊，它知道如何將數(shù)據(jù)寫入數(shù)據(jù)庫。當(dāng)應(yīng)用要寫入數(shù)據(jù)時，緩存會先存儲數(shù)據(jù)，并調(diào)用寫模塊將數(shù)據(jù)寫入數(shù)據(jù)庫。

應(yīng)用場景

Read Through/Write Through適用于寫入之后經(jīng)常被讀取的應(yīng)用。

優(yōu)點

• 緩存不存在臟數(shù)據(jù)
• 相比較Cache-Aside懶加載模式，讀取速度更高，因為較少因為緩存未命中而從數(shù)據(jù)庫中查找
• 應(yīng)用程序的邏輯相對簡單

缺點

• 對于總是寫入?yún)s很少被讀取的應(yīng)用，那么Write-Through會非常浪費性能，因為數(shù)據(jù)可能更改了很多次，卻沒有被讀取，白白的每次都寫入緩存造成寫入延遲。

除了Write-Through以外，我們還有另外的兩種寫模式可以和Read-Through一起來配合使用，分別是Write-Back和Write-Around。

Write-Back

又叫做Write-Behind。和Write-Through寫入的時機不同，Write-Back將緩存作為可靠的數(shù)據(jù)源，每次都只寫入緩存，而寫入數(shù)據(jù)庫則采用異步的方式，比如當(dāng)數(shù)據(jù)要被移除出緩存的時候再存儲到數(shù)據(jù)庫或者一段時間之后批量更新數(shù)據(jù)庫。

應(yīng)用場景

讀寫效率都非常好，寫的時候因為異步存儲到數(shù)據(jù)庫，提升了寫的效率，適用于讀寫密集的應(yīng)用。

優(yōu)點

• 寫入和讀取數(shù)據(jù)都非常的快，因為都是從緩存中直接讀取和寫入。
• 對于數(shù)據(jù)庫不可用的情況有一定的容忍度，即使數(shù)據(jù)庫暫時不可用，系統(tǒng)也整體可用，當(dāng)數(shù)據(jù)庫之后恢復(fù)的時候，再將數(shù)據(jù)寫入數(shù)據(jù)庫。

缺點

• 有數(shù)據(jù)丟失的風(fēng)險，如果緩存掛掉而數(shù)據(jù)沒有及時寫到數(shù)據(jù)庫中，那么緩存中的有些數(shù)據(jù)將永久的丟失了

Write-Around

和Write-Through不同，更新的時候只寫入數(shù)據(jù)庫，不寫入緩存，結(jié)合Read-Through或者Cache-Aside使用，只在緩存未命中的情況下寫緩存。

應(yīng)用場景

適合于只寫入一次而很少被讀取的應(yīng)用。

優(yōu)點

• 相比較Write-Through寫入的時候的效率較高，如果數(shù)據(jù)寫入后很少被讀取，緩存也不會被沒用到的數(shù)據(jù)占滿。

缺點

• 如果數(shù)據(jù)會寫入多次，那么可能存在緩存和數(shù)據(jù)庫不一致

以上內(nèi)容希望幫助到大家，很多PHPer在進階的時候總會遇到一些問題和瓶頸，業(yè)務(wù)代碼寫多了沒有方向感，不知道該從那里入手去提升，對此我整理了一些資料，包括但不限于：分布式架構(gòu)、高可擴展、高性能、高并發(fā)、服務(wù)器性能調(diào)優(yōu)、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql優(yōu)化、shell腳本、Docker、微服務(wù)、Nginx等多個知識點高級進階干貨需要的可以免費分享給大家，需要點擊

總結(jié)

以上是生活随笔為你收集整理的net.conn read 判断数据读取完毕_高并发：缓存模式以及缓存的数据一致性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。