一.核心知識
1.redis和MySQL的同步方案怎么做的？
- 讀數據：先查詢緩存，緩存不存在則查詢數據庫，然后將數據新增到緩存中
- 寫數據：新增時，先新增數據庫，數據庫成功后再新增緩存；更新和刪除時，先更新或者刪除數據庫中的數據，再刪除緩存或者修改緩存的過期時間
2.實現Redis和MySQL之間的同步的方法
- 利用觸發器
- 通過數據庫插件
- 異步隊列方式同步，可采用消息中間件處理
- 實現同步方案，先查緩存，查不到再從DB查詢，并保存到緩存，更新緩存時先更新數據庫，再講緩存設置過期
3.Redis分布式存儲常見方案
中從模式、哨兵模式、集群模式
4.Redis集群切片的常見方式
- 客戶端分片：即在客戶端就通過key的hash值對應到不同的服務器
- 中間件實現分片：再應用軟件和Redis中間，由中間件實現服務到后臺Redis節點的路由分派
- 客戶端服務端協作分片：Redis cluster模式，客戶端采用一致哈希，服務端提供錯誤節點的重定向服務slot上
5.分布式緩存
在高并發的環境下，為了減輕數據庫壓力，提高系統響應事件，在應用和數據庫之間增加獨立緩存系統，常見的分布式緩存有Redis和memcache。
6.解決SQL注入有哪幾種方式
- 正則表達式
- 參數化的過濾語句
- 檢查用戶的輸入合法化
- 數據加密處理
- 存儲過程
- 漏洞掃描工具
- web防火墻
7.Redis緩存淘汰機制
- 所有key中隨機淘汰一個key
- 在過期時間的key中，刪除使用頻率最少的key
- 在過期時間的key中，刪除即將要過期的key
- 所以key中，刪除最不經常使用的key
- 隨機刪除設置了過期時間的key
8.Redis數據結構與文件持久化差別在哪
- 磁盤更新頻率：前者頻率較慢，后者每條指令對數據的操作都要保存，默認時間1秒
- 數據安全：前者不如后者安全
- 數據一致性：RDB可能發生數據丟失和不一致，后者即使宕機也能解決一致性問題
- 重啟性能：前者恢復速度比后者快很多
- 數據文件大小：前者保存整個數據庫的快照，容量比后者大
二.案例考察擴展
1.簡要說明數據遷移準備工作的內容
- 待遷移數據源的詳細說明：包括數據的存放方式、數據量和數據的時間跨度
- 建立新舊系統數據庫的數據字典，對現有系統的歷史數據進行質量分析，以及新舊系統數據結構的差異分析
- 新舊系統代碼數據的差異分析
- 建立新舊系統數據庫表的映射關系，對無法映射字段的處理方法
- 開發或者購買、部署ETL工具
- 編寫數據轉換的測試計劃和校驗程序
- 制定數據轉換的應急措施
2.SQL語句優化的常見策略
- 建立霧化視圖或者盡可能減少多表查詢。
- 以不相干子查詢替代相干子查詢。
- 只檢索需要的列。
- 用帶in的條件子句等價替換or子句。
- 經常提交commit，以盡早釋放鎖。
- 避免嵌套的游標和多重循環等。
三.真題
1.2024下半年
Cache-aside架構，也稱為旁路緩存模式，是一種常見的緩存使用策略。
1+2.填空流程圖說明緩存讀寫的過程。
- 向緩存請求讀取該商品信息
- 若命中則返回該商品信息
- 若未命中則訪問數據庫查詢該商品信息
- 將查詢到的數據庫數據更新到緩存
- 將查詢到的數據庫目標數據返回
- 更新數據庫中的目標商品信息。
- 將數據庫中更新的商品信息寫入到緩存中，確保數據一致性。
3.王工使用了多線程技術進行緩存處理，線程1負責寫入，線程2負責讀取，可能存在數據一致性問題，請解釋其原因，并給出3個以上的解決辦法。
原因：
- 如果沒有適當的同步機制，兩個或多個線程可能同時訪問和修改共享資源，導致最終結果取決于線程調度順序。
- 在多線程環境中，一個線程對共享變量所做的更改不一定立刻被其他線程看到。
- 寫入操作可能不是一個原子操作，意味著它可以被中斷或分段執行。
解決方案：
- 延時雙刪
- 同步刪除
- 加互斥鎖（分布式鎖）
- 消息隊列
- 基于緩存更新策略
2.2024上半年
1.使用基于數據庫的分布式鎖所存在的缺陷
基于數據庫的分布式鎖雖然實現簡單，但在高并發、高可用性場景下存在一些明顯的缺陷，主要包括以下幾個方面：
- 數據庫讀寫性能較低，鎖競爭導致連接池耗盡
- 非原子性操作具有風險
- 數據庫鎖通常是非公平的
- 如果使用單機數據庫，一旦數據庫宕機，所有依賴它的分布式鎖將失效。
- 鎖超時的時間難以設定
2.redis的幾種操作命令
- 寫入：SET key value，哈希：HSET key field value
- 查詢：GET key，哈希：HGET key field
- 刪除：DEL key1 [key2]，哈希：HDEL key field1 [field2]
3.基于redis的數據庫鎖也會存在死鎖場景，舉例說明：
?
基于數據庫的分布式鎖和基于redis的分布式鎖都存在問題，還有哪些其它的分布式鎖的類型？
- 利用 ZooKeeper 的 臨時有序節點（Ephemeral Sequential Nodes） 實現鎖競爭。
- 基于 etcd 的 租約（Lease） 和 事務（TXN） 實現
- 利用 Consul 的 KV 存儲+Session 機制
- 基于 Redlock 的分布式鎖（Redis 多實例）
- 基于 Chubby（Google）的分布式鎖，Google 內部的分布式鎖服務，類似 ZooKeeper 但更強調高可用。
