常用快取處理場景：
解決目標
避免了透傳到資料庫，從而把大量的類似請求擋在了快取之中。
解決問題的思路
1.將這個不存在的
key預先設定乙個值。比如
，「null" 。
2.在返回
這個「null"
值的時候
，客戶端應用
就可以認為這是不存在的
key，客戶端應用
就可以決定是否繼續等待繼續訪問，還是放棄掉這次操作。
3.如果
繼續等待訪問，過乙個時間輪詢點後，再次請求這個
key，如果取到的值不再
是「null"
，則可以認為這時候
key有值
了，從而避免了透傳到資料庫，從而把大量的類似請求擋在了快取之中。
解決問題的思路
1.客戶端從快取中根據
key讀取資料，
2.如果
讀到了資料則流程結束，如果沒有讀到資料（可能會有多個併發都沒有讀到資料），這時候使用快取系統中的
setnx
方法設定乙個值（這種方法類似加個鎖）
3.沒有
設定成功的請求則
sleep
一段時間，設定成功的請求讀取資料庫獲取值，如果獲取到則更新快取，流程結束
4.之前
sleep
的請求這時候喚醒後直接再從快取中讀取資料，此時流程結束。
解決問題的思路
1.如果
快取是因為網路問題沒有更新成功資料，進入
重試 2.如果
依然沒有更新成功則認為快取系統出錯不可用，這時候客戶端會將資料的key插入到訊息系統中，訊息系統可以過濾相同的key，只需保證訊息系統不存在相同的
key
3.當快取系統恢復可用的時候，依次從mq中取出key值然後從資料庫中讀取最新的資料更新快取。
方案分析
1.快取系統做乙個排序佇列，比如
1000
個使用者，系統會根據使用者的訪問時間更新使用者資訊的時間，越是最近訪問的使用者排名越排前
2.系統通過定時任務定期
過濾掉排名最後的
200個使用者，然後再從資料庫中隨機取出
200個使用者加入
佇列。
3.請求
每次到達的時候，會先從佇列中獲取使用者資訊，如果命中則根據
userid
，再從另乙個快取資料結構中讀取使用者資訊，如果沒有命中則說明該使用者請求頻率不高。
Redis快取應用場景
記錄一下自己的聽課筆記，看的網課。參考資料 快取一些常用的 經常訪問的 不經常變化的資料，也就是相對穩定即時性低的，比如說 選單 許可權 類別 資料字典。這樣的資料放快取是因為文章的閱讀量和點讚量變化太快了，如果頻繁的更新資料庫，資料庫壓力太大了，頂不住的。如果放到redis中快取起來，讀寫更快。加...
負載均衡實現方案與應用場景
負載均衡實現方案與應用場景 1.dns 伺服器解析客戶端請求的網域名稱，根據每個地方的網域名稱，然後去請求不同的伺服器應用。可能不及時，有快取。2.軟體實現 如nginx 均衡實現 1.輪詢 順序輪詢，隨機輪詢，權重配比輪詢，相當於輪詢的找伺服器。2.hash計算 根據計算某個值，值一樣了 ngin...
訊息推送應用場景與解決方案
作為開發者，不要有需求就接，應該多思考 多理解使用者 功能的使用場景，有助於我們更好地去選擇合適的開發方式 3.1 作業系統有自身的訊息推送功能 系統級別 3.2 推送的本質與原理 主動獲取方式 pull 客戶端隔固定時間主動向伺服器獲取資訊，看是否有更新的資訊 若有更新資訊，則傳送到客戶端 被動接...