項目用到redis redis過期數(shù)據(jù)刪除的機制 刪除的策略
使用redis存放用戶token，一些不常變化的數(shù)據(jù)，比如某個用戶的菜單權限信息等
redis數(shù)據(jù)過期刪除機制：
定期刪除：每隔指定時間就隨機找出W(默認100個)個設置了過期時間的key，假設有N個key過期了，刪除這些過期的key，如果 (N/M)*100% > P(默認值25%)，就再次輪訓刪除，
直到過期key的百分比<=P（默認值25%），這里的W和P都是可以配置的
當新數(shù)據(jù)進入redis，redis空間不足，有以下刪除策略：
針對帶過期時間的數(shù)據(jù)：
volatile-lru：挑選最近最少使用的數(shù)據(jù)淘汰
volatile-lfu：挑選最近使用次數(shù)最少的數(shù)據(jù)淘汰
volatile-ttl：挑選將要過期的數(shù)據(jù)進行淘汰
volatile-random：任意選擇數(shù)據(jù)進行淘汰
針對所有數(shù)據(jù)：
allkeys-lru：挑選最近最少使用的數(shù)據(jù)進行淘汰
allkeys-lfu：挑選最近使用次數(shù)最少的數(shù)據(jù)淘汰
allkeys-random：任意選擇數(shù)據(jù)進行淘汰
no-enviction：禁止驅逐數(shù)據(jù)，會引發(fā)錯誤OOM
實際項目中用到了redis哪些數(shù)據(jù)結構 用list做了什么
用到了String，List，Set，Zset，Hash
String:用來存放用戶token信息，每次用戶登陸之后會存放token到redis，并且設置過期時間，每次接口訪問會先訪問redis查詢請求攜帶的token是否存在與redis，
不存在時需要重新登陸
List：用來做一個簡易的消息隊列，或者文章詳情中右側最近文章列表，這種變動不大的數(shù)據(jù)
Set：不包含重復元素的無序集合，可以用來做類似微博的共同關注，或者可能認識的功能，他可以列出兩個集合的交集，或者差集
Zset：帶權重的不包含重復元素的集合，會自動根據(jù)權重進行排序，可以用來做網(wǎng)站瀏覽量排行榜的功能
Hash: 相比較于直接將整個數(shù)據(jù)存放到String，如果對象的某個字段修改了，需要整條數(shù)據(jù)進行修改，如果使用hash來，只需要修改指定的某個字段值就好了
kafka 如何保證消費者不會重復消費數(shù)據(jù)
保證冪等性，每個消息給一個唯一的id，并且創(chuàng)建一個消息表，
生產(chǎn)者創(chuàng)建的消息，插入消息表時先查詢，這個唯一id如果有記錄，就說明消息已經(jīng)發(fā)送了，不要重復發(fā)送，如果唯一id數(shù)據(jù)不存在，新增消息，標記消息狀態(tài)為待處理，
消費者，消息處理時，根據(jù)唯一id查詢數(shù)據(jù)，如果數(shù)據(jù)狀態(tài)為待處理，開始處理數(shù)據(jù)，最后將狀態(tài)設置為已消費，如果狀態(tài)為已消費，說明已經(jīng)被別的線程消費了，不做別的處理
offset提交方式
自動提交，手動提交
kafka有沒有什么確認機制保證消息一定寫入kafka集群當中
spring.kafka.producer.acks:
配置為0時：只要消息通過網(wǎng)絡發(fā)送出去就認為發(fā)送成功了，不管集群是否接收到消息
配置為1時：保證leader副本接收到消息，就認為是成功了
配置為-1時：保證所有副本都接收到了消息，才認為是成功了(等待的時間長一些，但是可以確保消息在leader和flower副本中都存在)
哈希表的作用 哈希表使用的數(shù)據(jù)結構 哈希內部解決哈希沖突的方式有哪幾種
哈希表使用較低的時間復雜度，獲取數(shù)據(jù)
使用的數(shù)據(jù)結構是：數(shù)組+鏈表+紅黑樹
解決hash沖突的方式：鏈地址法，再哈希
多線程環(huán)境下為什么要引入同步的機制
因為多線程下，如果不使用同步機制，對于同一個資源變量，會被拷貝副本到自己的線程，對于這一個資源變量的修改，對其他線程不可見，可能會出現(xiàn)數(shù)據(jù)丟失的情況
java內部有哪些同步的機制 回答 synchronized 和 ReentrantLock 問 這兩種鎖有哪些區(qū)別
針對某個變量可以使用volatile關鍵字保證可見性
synchronized：是java的關鍵字，是jvm層面的實現(xiàn)，非公平鎖
ReentrantLock：使用AQS，是java代碼層面的實現(xiàn)，可以實現(xiàn)公平鎖和非公平鎖
多線程什么場景下會發(fā)生死鎖
例如有兩個事務，事務A操作數(shù)據(jù)的順序是12，事務B操作數(shù)據(jù)的順序是21
這時候，假設事務A操作了數(shù)據(jù)1，事務B操作了數(shù)據(jù)2，
下一步事務A需要操作數(shù)據(jù)2了，但是數(shù)據(jù)2被事務2修改了，被鎖住，那么事務A就需要進行等待，同時，事務B需要操作數(shù)據(jù)1了，但是數(shù)據(jù)1被事務A修改了，
數(shù)據(jù)1被鎖住了，則事務B也需要等待，這樣兩個事務兩個線程互相等待對方，結果就出現(xiàn)了死鎖
解決方法：保證線程對資源的訪問順序，例如在這個操作里面，就可以根據(jù)數(shù)據(jù)id排序一下
有什么具體的辦法可以避免死鎖
（1）保持加鎖順序：當多個線程都需要加相同的幾個鎖的時候（例如上述情況一的死鎖），按照不同的順序枷鎖那么就可能導致死鎖產(chǎn)生，所以我們如果能確保所有的線程都是按照相同的順序獲得鎖，那么死鎖就不會發(fā)生。
（2）獲取鎖添加時限：上述死鎖代碼情況二就是因為出現(xiàn)了獲取鎖失敗無限等待的情況，如果我們在獲取鎖的時候進行限時等待，例如wait(1000)或者使用ReentrantLock的tryLock(1,TimeUntil.SECONDS)這樣在指定時間內獲取鎖失敗就不等待；
（3）進行死鎖檢測：我們可以通過一些手段檢查代碼并預防其出現(xiàn)死鎖
Http的請求報文和響應報文各有哪幾部分組成
請求報文包含3部分。
（1）請求行，包含請求方法、URI、HTTP版本信息。
（2）請求首部字段。
（3）請求內容實體。
響應報文包含3部分。
（1）狀態(tài)行，包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語。
（2）響應首部字段。
（3）響應內容實體。
Http 協(xié)議和TCP協(xié)議的關系是什么
TCP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸
HTTP是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)。
更多IT資料【IT桃園村】，電子書，面試手冊，八股文
image
