03 youtube官網打不開如何清除緩存數據一致性是指(經典好文--如何保證緩存和數據庫的雙寫一致性)

— 4 —

Write-Through

Write-Through 意為直寫模式，對于 Write-Through 直寫模式來說，它也增加了訪問控制層來提供更高程度的封裝。不同于 Cache-Aside 的是，Write-Through 直寫模式在寫請求更新數據庫之后，并不會刪除緩存，而是更新緩存。

這種方式的 優勢在于讀請求過程簡單 ，不需要查詢數據庫更新緩存等操作。但其劣勢也非常明顯，除了上面我們提到的更新數據庫再更新緩存的弊端之外，這種方案還會造成更新效率低，并且兩個寫操作任何一次寫失敗都會造成數據不一致。

如果要使用這種方案， 最好可以將這兩個操作作為事務處理，可以同時失敗或者同時成功，支持回滾，并且防止并發環境下的不一致 。另外，為了防止緩存擾動的頻發，也可以給緩存增加 TTL 來緩解。

站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過分布式事務保證緩存層數據與持久化層數據的一致性，但在實際項目中，大多都對一致性的要求存在一些寬容度，所以在方案上往往有所折衷。

Write-Through 直寫模式適合寫操作較多，并且對一致性要求較高的場景，在應用 Write-Through 模式時，也需要通過一定的補償機制來解決它的問題。首先，在并發環境下，我們前面提到了先更新數據庫，再更新緩存會導致緩存和數據庫的不一致，那么先更新緩存，再更新數據庫呢？

這樣的操作時序仍然會導致下面這樣線程 1 先更新緩存，最后更新數據庫的情況，即由于線程 1 和 線程 2 的執行不確定性導致數據庫和緩存的不一致。這種由于線程競爭導致的緩存不一致，可以通過分布式鎖解決，保證對緩存和數據庫的操作僅能由同一個線程完成。對于沒有拿到鎖的線程，一是通過鎖的 timeout 時間進行控制，二是將請求暫存在消息隊列中順序消費。

在下面這種并發執行場景下，來自線程 1 的寫請求更新了數據庫，接著來自線程 2 的讀請求命中緩存，接著線程 1 才更新緩存，這樣便會導致線程 2 讀取到的緩存落后于數據庫。同理，先更新緩存后更新數據庫在寫請求和讀請求并發時，也會出現類似的問題。面對這種場景，我們也可以加鎖解決。

另在，在 Write-Through 模式下，不管是先更新緩存還是先更新數據庫，都存在更新緩存或者更新數據庫失敗的情況，上面提到的重試機制和補償機制在這里也是奏效的。

— 5 —

Write-Behind

Write behind 意為異步回寫模式，它也具有類似 Read-Through/Write-Through 的訪問控制層，不同的是，Write behind 在處理寫請求時，只更新緩存而不更新數據庫，對于數據庫的更新，則是通過批量異步更新的方式進行的，批量寫入的時間點可以選在數據庫負載較低的時間進行。

在 Write-Behind 模式下，寫請求延遲較低，減輕了數據庫的壓力，具有較好的吞吐性。但數據庫和緩存的一致性較弱，比如當更新的數據還未被寫入數據庫時，直接從數據庫中查詢數據是落后于緩存的。同時，緩存的負載較大，如果緩存宕機會導致數據丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫操作的場景，常用于電商秒殺場景中庫存的扣減。

— 6 —

Write-Around

如果一些非核心業務，對一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個緩存過期時間，在寫請求中僅僅更新數據庫，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過過期時間失效。這種方案實現簡單，但緩存中的數據和數據庫數據一致性較差，往往會造成用戶的體驗較差，應慎重選擇。

— 7 —

總結

在解決緩存一致性的過程中，有多種途徑可以保證緩存的最終一致性，應該根據場景來設計合適的方案，讀多寫少的場景下，可以選擇采用“Cache-Aside 結合消費數據庫日志做補償”的方案，寫多的場景下，可以選擇采用“Write-Through 結合分布式鎖”的方案 ，寫多的極端場景下，可以選擇采用“Write-Behind”的方案。

php面試題 memcache和redis的區別

Redis與Memcached的區別

傳統MySQL+ Memcached架構遇到的問題

實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據加載到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：

1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作占據大量開發時間。

2.Memcached與MySQL數據庫數據一致性問題。

3.Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。

4.跨機房cache同步問題。

眾多NoSQL百花齊放，如何選擇

最近幾年，業界不斷涌現出很多各種各樣的NoSQL產品，那么如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的

問題，實際歸根結底最重要的是了解這些產品的定位，并且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用于解

決以下幾種問題

1.少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。

2.海量數據存儲，分布式系統支持，數據一致性保證，方便的集群節點添加/刪除。

3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，后者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然后定期買粉絲pat歸并到磁盤上，將隨機寫優化為順序寫，提高寫入性能。

4.Schema 買粉絲，買粉絲-sharding等。比如目前常見的一些文檔數據庫都是支持schema-買粉絲的，直接存儲json格式數據，并且支持買粉絲-sharding等功能，比如mongodb。

面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。

Redis適用場景，如何正確的使用

backed的功能，跟傳統意義上的持久化有比較大的差別，那么可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那么何時使用

Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

2 Redis支持數據的備份，即master-slave模式的數據備份。

3 Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。

拋開這些，可以深入到Redis內部構造去觀察更加本質的區別，理解Redis的設計。

在

Redis中，并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。Redis只會緩存所有的

key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據“swappability =

age*log(size_in_memory)”計

算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis可以

保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由于Redis將內存

中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個

操作，直到子線程完成swap操作后才可以進行修改。

使用Redis特有內存模型前后的情況對比：

VM off: 300k keys, 4096 bytes values: 1.3G used

VM on: 300k keys, 4096 bytes values: 73M used

VM off: 1 million keys, 256 bytes values: 430.12M used

VM on: 1 million keys, 256 bytes values: 160.09M used

VM on: 1 million keys, values as large as you want, still: 160.09M used

當

從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數據，然后再返回給請求方。

這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小，進行

批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程

池的大小，對需要從swap文件中加載相應數據的讀取請求進行并發操作，減少阻塞的時間。

如果希望在海量數據的環境中使用好Redis，我相信理解Redis的內存設計和阻塞的情況是不可缺少的。

補充的知識點：

memcached和redis的比較

1 網絡IO模型

Memcached是多線程，非阻塞IO復用的網絡模型，分為監聽主線程和worker子線程，監聽線程監聽網絡連接，接受請求后，將連接描述

字pipe 傳

很赞哦!（3811）