快取命中率 = 命中的 / 總的
寫入操作時，更新快取（寫入db && 寫入快取 計算簡單的時候，直接更新，增加一次命中率）/淘汰快取（寫
入db，只淘汰資料，計算複雜時，比更新操作簡單，但會增加一次不命中）
處理時應先寫入快取，再寫入db，如果db失敗，則快取多一次失效。如果先db後快取，這時快取失敗了，則快取資料和db資料出現不一致
實現方案：中間加入服務層/寫請求都到db，都請求都到cache，非同步工具來做db與快取間的同步（這種太複雜了點吧）
服務化是向業務方遮蔽底層cache與db複雜性的一種通用解決方式
使用者想查詢自己的訂單列表，分頁，列表會變 (uid -> list，uid的訂單新增時，刪除快取)
頻繁刪除redis key會產生很多記憶體碎片，導致記憶體佔用率越來越大，最後不得不重啟釋放記憶體
連線池每次取出乙個連線後併發執行，想序列化這種操作，考慮在獲取連線時按照業務id取模
例如訂單表，業務上對使用者和商家都有訂單查詢需求：
order(oid, info_detail)
t(buyer_id, seller_id, oid)
如果用buyer_id來分庫，seller_id的查詢就需要掃瞄多庫。
如果用seller_id來分庫，buyer_id的查詢就需要掃瞄多庫。
t1(buyer_id, seller_id, oid)
t2(seller_id, buyer_id, oid)
同乙個資料，冗餘兩份，乙份以buyer_id來分庫，滿足買家的查詢需求；
乙份以seller_id來分庫，滿足賣家的查詢需求。
具體實現：
雙寫非同步訊息投遞
通過log接觸耦合，線下非同步寫
誰先來？哪種對業務影響小哪種先來，一切為業務服務
以上文的訂單生成業務為例，buyer和seller冗餘表都需要插入資料：
t1(buyer_id, seller_id, oid)
t2(seller_id, buyer_id, oid)
使用者下單時，如果「先插入buyer表t1，再插入seller冗餘表t2」，當第一步成功、第二步失敗時，出現的業務影
響是「買家能看到自己的訂單，賣家看不到推送的訂單」
相反，如果「先插入seller表t2，再插入buyer冗餘表t1」，當第一步成功、第二步失敗時，出現的業務影響是「賣家能看到推送的訂單，賣家看不到自己的訂單」
由於這個生成訂單的動作是買家發起的，買家如果看不到訂單，會覺得非常奇怪，並且無法支付以推動訂單狀態的流轉，此時即使賣家看到有人下單也是沒有意義的。
因此，在此例中，應該先插入buyer表t1，再插入seller表t2。
一致性保證：
線下離線掃瞄，對比兩個表，不一致進行修補
寫入表，寫入log，線下增量掃瞄log，對比兩個表，不一致進行修補canal
寫入表，傳送訊息msg1,寫入另乙個表，傳送訊息msg2，檢查兩個訊息的間隔，確定是否需要修補
快取一致性
一般應用而言，追求的都是快取的最終一致性。一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。引起這個問題的主要原因還是高併發的時...
快取一致性
計算機體系結構量化研究方法 第五版 學習筆記 快取一致性 1 快取一致性的問題 2 儲存器一致性的概念 3 一致性的基本實現方案 大型 多級快取可以充分降低處理器對儲存頻寬的需求。採用對稱共享儲存器的計算機通常支援對共享資料與專用資料的快取。多處理器之間的通訊基本上是通過讀寫共享資料實現。為了降低訪...
資料冗餘一致性優化
通過patition key的查詢能夠直接定位到庫，但是非patition key上的查詢可能就需要掃瞄多個庫了。1 4流程 1 業務方呼叫服務，新增資料 2 服務先插入 t1資料 3 服務再插入 t2資料 4 服務返回業務方新增資料成功 1 不複雜，服務層由單次寫，變兩次寫 2 資料一致性相對較高...