redis 的併發競爭問題是什麼？如何解決這個問題？了解 redis 事務的 cas 方案嗎？
面試官心理分析
這個也是線上非常常見的乙個問題，就是多客戶端同時併發寫乙個 key，可能本來應該先到的資料後到了，導致資料版本錯了；或者是多客戶端同時獲取乙個 key，修改值之後再寫回去，只要順序錯了，資料就錯了。
而且 redis 自己就有天然解決這個問題的 cas 類的樂觀鎖方案。
面試題剖析
某個時刻，多個系統例項都去更新某個 key。可以基於 zookeeper 實現分布式鎖。每個系統通過 zookeeper 獲取分布式鎖，確保同一時間，只能有乙個系統例項在操作某個 key，別人都不允許讀和寫。
你要寫入快取的資料，都是從 mysql 裡查出來的，都得寫入 mysql 中，寫入 mysql 中的時候必須儲存乙個時間戳，從 mysql 查出來的時候，時間戳也查出來。
每次要寫之前，先判斷一下當前這個 value 的時間戳是否比快取裡的 value 的時間戳要新。如果是的話，那麼可以寫，否則，就不能用舊的資料覆蓋新的資料。
生產環境中的 redis 是怎麼部署的？
面試官心理分析
看看你了解不了解你們公司的 redis 生產集群的部署架構，如果你不了解，那麼確實你就很失職了，你的 redis 是主從架構？集群架構？用了哪種集群方案？有沒有做高可用保證？有沒有開啟持久化機制確保可以進行資料恢復？線上 redis 給幾個 g 的記憶體？設定了哪些引數？壓測後你們 redis 集群承載多少 qps？
兄弟，這些你必須是門兒清的，否則你確實是沒好好思考過。
面試題剖析
redis cluster，10 臺機器，5 臺機器部署了 redis 主例項，另外 5 臺機器部署了 redis 的從例項，每個主例項掛了乙個從例項，5 個節點對外提供讀寫服務，每個節點的讀寫高峰qps可能可以達到每秒 5 萬，5 臺機器最多是 25 萬讀寫請求/s。
機器是什麼配置？32g 記憶體+ 8 核 cpu + 1t 磁碟，但是分配給 redis 程序的是10g記憶體，一般線上生產環境，redis 的記憶體盡量不要超過 10g，超過 10g 可能會有問題。
5 臺機器對外提供讀寫，一共有 50g 記憶體。
因為每個主例項都掛了乙個從例項，所以是高可用的，任何乙個主例項宕機，都會自動故障遷移，redis 從例項會自動變成主例項繼續提供讀寫服務。
你往記憶體裡寫的是什麼資料？每條資料的大小是多少？商品資料，每條資料是 10kb。100 條資料是 1mb，10 萬條資料是 1g。常駐記憶體的是 200 萬條商品資料，占用記憶體是 20g，僅僅不到總記憶體的 50%。目前高峰期每秒就是 3500 左右的請求量。
其實大型的公司，會有基礎架構的 team 負責快取集群的運維。 碼巢
高併發架構 快取的挑戰
快取 使用快取，出於兩個場景需要 高效能，高併發 計算機的業務資料，為了實現高可用和安全性，必然要進行持久化處理，但目前的技術而言，持久化到硬碟或者從硬碟中查詢本來就是一件非常慢的事情，但實際我們又要求在大量的資料中快速訪問，所以，一般我們會把資料提前載入記憶體中，實現高效能訪問 而高效能意味著可以...
Java 高併發程式設計 重入鎖 面試題
public class reentrantlock5 extends threadfinally public static void main string args reentrantlock還可以指定為公平鎖什麼是公平鎖，什麼是不公平鎖，假設很多個執行緒訪問同乙份資源的時候都要鎖定，其中某乙...
面試準備 高併發快取研究
高併發口訣 讀多寫少用快取，寫多讀少用佇列 使用快取時難免遇到兩個問題 快取雪崩 快取擊穿 快取雪崩是指 大批量快取失效，或者單個快取的時間突然失效的時間點大批量訪問導致都查資料庫。大批量失效我們可以吧過期時間設定成隨機的均勻分布。單個的失效大批量訪問，可以加鎖，讓查庫的動作乙個人來做。lock 這...