緩存擊穿解決
關於java清緩存前可以進後台方法,清完緩存不進了相關資料如下
java我們在使用緩存時，往往先嘗試去緩存中取值，如果沒有，再去資料庫取值，如果資料庫也沒有值，則根據業務需求，返回空或者拋異常。
如果用戶一直訪問一個資料庫不存在的數據，比如id為-1的數據，就會導致每次請求都會先去緩存查一次，然後再去資料庫查一次，造成嚴重的性能問題。這種情況就叫緩存穿透。
解決方案
以下幾種解決方案：對請求參數做校驗，比如用戶鑒權校驗，id做基礎校驗，id <= 0的直接攔截。
如果查詢到資料庫沒有值，也將對應的key存進緩存中，value為null。這樣下次查詢就直接從緩存返回了。但這里的key的緩存時間應該比較短，比如30s。防止後面在資料庫插入了這條數據，而用戶獲取不到。
使用布隆過濾器，判斷一個key是否已經查過了，如果已經查過了，就不去資料庫查詢。
緩存擊穿
緩存擊穿指的是，一個key的訪問量非常大，比如某秒殺活動，有1w/s的並發量。這個key在某一時刻過期，那這些大量的請求就會一瞬間到資料庫，資料庫可能會直接崩潰。
解決方案
緩存擊穿的解決方案也有幾種，可以配合使用：對於熱點數據，慎重考慮過期時間，確保熱點期間key不會過期，甚至有些可以設置永不過期。
使用互斥鎖(比如Java的多線程鎖機制)，第一個線程訪問key的時候就鎖住，等查詢資料庫返回後，把值插入到緩存後再釋放鎖，這樣後面的請求就可以直接取緩存裡面的數據了。
緩存雪崩
緩存雪崩指的是，在某一時刻，多個key失效。這樣就會有大量的請求從緩存中獲取不到值，全部到資料庫。還有另一種情況，就是緩存伺服器宕機，也算做緩存雪崩。
解決方案
針對上述兩種情況，緩存雪崩有兩種解決方案：對每個key的過期時間設置一個隨機值，而不是所有key都相同。
使用高可用的分布式緩存集群，確保緩存的高可用性，比如redis-cluster。
B. 緩存擊穿互斥鎖 設置鎖的失效時間
設置鎖的失效時間是自己設置的，它的過期時間會很短，最長不超過五分鍾
緩存穿透是指查詢一個一定不存在的數據
由於緩存是不命中時被動寫的，
並且出於容錯考慮，如果從存儲層查不到數據則不寫入緩存，
這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。
在流量大時，可能DB就掛掉了，
要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。
最常見的則是採用布隆過濾器
將所有可能存在的數據哈希到一個足夠大的bitmap中，
一個一定不存在的數據會被 這個bitmap攔截掉，
從而避免了對底層存儲系統的查詢壓力。
另外也有一個更為簡單粗暴的方法
如果一個查詢返回的數據為空（不管是數 據不存在，還是系統故障），
我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鍾
C. 緩存穿透和緩存擊穿有什麼區別
兩者計算的功能是不同的，因為它們所需的能量不同。
前者要達到的需求是要穿透這個設備，而另一個是需要完成擊穿，通過正常運行。
D. redis常見問題
1. 緩存擊穿
緩存擊穿是指一個請求要訪問的數據，緩存中沒有，但資料庫中有的情況。這種情況一般都是緩存過期了。
但是這時由於並發訪問這個緩存的用戶特別多，這是一個熱點 key，這么多用戶的請求同時過來，在緩存裡面沒有取到數據，所以又同時去訪問資料庫取數據，引起資料庫流量激增，壓力瞬間增大，直接崩潰給你看。
所以一個數據有緩存，每次請求都從緩存中快速的返回了數據，但是某個時間點緩存失效了，某個請求在緩存中沒有請求到數據，這時候我們就說這個請求就"擊穿"了緩存。
針對這個場景，對應的解決方案一般來說有三種。
藉助Redis setNX命令設置一個標志位就行。設置成功的放行，設置失敗的就輪詢等待。就是在更新緩存時加把鎖
後台開一個定時任務，專門主動更新過期數據
比如程序中設置 why 這個熱點 key 的時候，同時設置了過期時間為 10 分鍾，那後台程序在第 8 分鍾的時候，會去資料庫查詢數據並重新放到緩存中，同時再次設置緩存為 10 分鍾。
其實上面的後台續命思想的最終體現是也是永不過期。
只是後台續命的思想，會主動更新緩存，適用於緩存會變的場景。會出現緩存不一致的情況，取決於你的業務場景能接受多長時間的緩存不一致。
2. 緩存穿透
緩存穿透是指一個請求要訪問的數據，緩存和資料庫中都沒有，而用戶短時間、高密度的發起這樣的請求，每次都打到資料庫服務上，給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。
解決方案有兩種：
就是在資料庫即使沒有查詢到數據，我們也把這次請求當做 key 緩存起來，value 可以是 NULL。下次同樣請求就會命中這個 NULL，緩存層就處理了這個請求，不會對資料庫產生壓力。這樣實現起來簡單，開發成本很低。
3. 緩存雪崩
緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間，而查詢數據量巨大，這時候，又是緩存中沒有，資料庫中有的情況了。
防止雪崩的方案簡單來說就是錯峰過期。
在設置 key 過期時間的時候，在加上一個短的隨機過期時間，這樣就能避免大量緩存在同一時間過期，引起的緩存雪崩。
如果發了雪崩，我們可以有服務降級、熔斷、限流手段來拒絕一些請求，保證服務的正常。但是，這些對用戶體驗是有一定影響的。
4. Redis 高可用架構
Redis 高可用架構，大家基本上都能想到主從、哨兵、集群這三種模式。
哨兵模式：
它主要執行三種類型的任務：
哨兵其實也是一個分布式系統，我們可以運行多個哨兵。
然後這些哨兵之間需要相互通氣，交流信息，通過投票來決定是否執行自動故障遷移，以及選擇哪個從伺服器作為新的主伺服器。
哨兵之間採用的協議是 gossip，是一種去中心化的協議，達成的是最終一致性。
選舉規則：
E. Linux運維工程師會面試哪些
給大家分享一些Linux面試題的筆記，從負載均衡、nginx、MySQL、redis、kafka、zabbix、k8s等方面拆解 Linux 知識點。用來對個人技術點進行查漏補缺。
目錄：
1. 磁碟使用率檢測（用shell腳本）
2. LVS 負載均衡有哪些策略？
3. 談談你對LVS的理解？
4. 負載均衡的原理是什麼？
5. LVS由哪兩部分組成的？
6. 與lvs相關的術語有哪些？
7. LVS-NAT模式的原理
8. LVS-NAT模型的特性
9. LVS-DR模式原理
10. LVS-DR模型的特性
11. LVS三種負載均衡模式的比較
12. LVS的負載調度演算法
13. LVS與nginx的區別
14. 負載均衡的作用有哪些？
15. nginx實現負載均衡的分發策略
16. keepalived 是什麼？
17. 你是如何理解VRRP協議的
18. keepalived的工作原理？
19. 出現腦裂的原因
20. 如何解決keepalived腦裂問題？
21. zabbix如何監控腦裂？
22. nginx做負載均衡實現的策略有哪些
23. nginx做負載均衡用到哪些模塊
24. 負載均衡有哪些實現方式
25. nginx如何實現四層負載？
26. 你知道的web服務有哪些？
27. 為什麼要用nginx
28 . nginx的性能為什麼比apache高？
29 . epoll的組成
30 . nginx和apache的區別
31. Tomcat作為web的優缺點？
32. tomcat的三個埠及作用
33. fastcgi 和cgi的區別
34. nginx常用的命令
35. 什麼是反向代理，什麼是正向代理，以及區別？
36. Squid、Varinsh、Nginx 有什麼區別？
37. nginx是如何處理http請求的
38. nginx虛擬主機有哪些？
39. nginx怎麼實現後端服務的健康檢查
40. apache中的Worker 和 Prefork 之間的區別是什麼?
41. Tomcat預設埠是多少，怎麼修改
42. Tomcat的工作模式是什麼？
43. Web請求在Tomcat請求中的請求流程是怎麼樣的?
44. 怎麼監控Tomcat的內存使用情況
45. nginx的優化你都做過哪些？
46. Tomcat你做過哪些優化
47. nginx的session不同步怎麼辦
48. nginx的常用模塊有哪些？
49. nginx常用狀態碼
50. 訪問一個網站的流程
51. 三次握手，四次揮手
52. 什麼是動態資源，什麼是靜態資源
53. worker支持的最大並發數是什麼？
54. Tomcat和Resin有什麼區別，工作中你怎麼選擇？
55. 什麼叫網站灰度發布？56.. 統計ip訪問情況，要求分析nginx訪問日誌，找出訪問頁面數量在前十位的ip
57. nginx各個版本的區別
58. nginx最新版本
59. 關於nginx access模塊的面試題
60. nginx默認配置文件
61. location的規則
62. 配置nginx防盜鏈
63. drop，delete和truncate刪除數據的區別？
64. MySQL主從原理
65. MySQL主從復制存在哪些問題？
66. MySQL復制的方法
67. 主從延遲產生的原因及解決方案？
68. 判斷主從延遲的方法
69. MySQL忘記root密碼如何找回
70. MySQL的數據備份方式
71. innodb的特性
72. varchar(100) 和varchar(200）的區別
73. MySQL主要的索引類型
74. 請說出非關系型資料庫的典型產品、特點及應用場景？
75. 如何加強MySQL安全，請給出可行的具體措施？
76. Binlog工作模式有哪些？各什麼特點，企業如何選擇？
77. 生產一主多從從庫宕機，如何手工恢復？
78. MySQL中MyISAM與InnoDB的區別，至少5點
79. 網站打開慢，請給出排查方法，如是資料庫慢導致，如何排查並解決，請分析並舉例？
80. xtrabackup的備份，增量備份及恢復的工作原理
81.誤執行drop數據，如何通過xtrabackup恢復？
82. 如何做主從數據一致性校驗？
83. MySQL有多少日誌
84. MySQL binlog的幾種日誌錄入格式以及區別
85. MySQL資料庫cpu飆升到500%的話他怎麼處理？
86. redis是單線程還是多線程？
87. redis常用的版本是？
88. redis 的使用場景？
89. redis常見的數據結構
90. redis持久化你們怎麼做的？
91. 主從復制實現的原理
92. redis哨兵模式原理
93. memcache和redis的區別
94. redis有哪些架構模式？
95. 緩存雪崩？
96. 緩存穿透
97. 緩存擊穿
98. redis為什麼這么快
99. memcache有哪些應用場景
100. memcache 服務特點及工作原理
101. memcached是如何做身份驗證的？
102. mongoDB是什麼？
103. mongodb的優勢
104. mongodb使用場景
105. kafka 中的ISR，AR代表什麼，ISR伸縮又代表什麼
106.kafka中的broker 是干什麼的
107. kafka中的 zookeeper 起到什麼作用，可以不用zookeeper么
108. kafka follower如何與leader同步數據
109. kafka 為什麼那麼快
110. Kafka中的消息是否會丟失和重復消費？
111. 為什麼Kafka不支持讀寫分離？
112. 什麼是消費者組?
113. Kafka 中的術語114. kafka適用於哪些場景
115. Kafka寫入流程：
116. zabbix有哪些組件
117. zabbix的兩種監控模式
118. 一個監控系統的運行流程
119. zabbix的工作進程
120. zabbix常用術語
121. zabbix自定義發現是怎麼做的？
122. 微信報警
123. zabbix客戶端如何批量安裝
124. zabbix分布式是如何做的
125. zabbix proxy 的使用場景
126. prometheus工作原理
127. prometheus組件
128. ELK工作流程
129. logstash的輸入源有哪些？
130. logstash的架構
131. ELK相關的概念
132. es常用的插件
134. zabbix你都監控哪些參數
135. MySQL同步和半同步
136. CI/CD
137 K8S監控指標
138. k8s是怎麼做日誌監控的
139. 【運維面試】k8s中service和ingress的區別
140. k8s組件的梳理
141. 關於tcp/IP協議
142. 談談你對CDN的理解
F. 緩存擊穿、穿透、雪崩及Redis分布式鎖
分布式鎖: setnx ,redisson 並發問題
冪等問題: 落表狀態,Redis
緩存擊穿: 指緩存中無,db中有
原因: 一個key高並發恰好失效導致大量請求到db
方案: 加鎖,自旋鎖,或一個線程查db,一個線程監控(直接用Redisson分布式鎖)
緩存穿透:指緩存和db中均無
原因: 一般是惡意請求
方案: 加布隆過濾,或查db無時,也設置緩存,value為某些特殊表示或"null"
雪崩:指緩存同時大量失效
原因: 大量的key同時失效,db壓力加大
方案: 設置失效時間是增加隨機數
問題方案文獻:
https://www.jianshu.com/p/31ab9b020cd9 (圖例分析)
https://blog.csdn.net/fcvtb/article/details/89478554
Redis分布式鎖:
事務未執行完鎖已到期釋放問題：使用Redissoin解決續租問題，內部已解決
分布式鎖文獻:
https://www.jianshu.com/p/4838f8be00c9
https://blog.csdn.net/qq_30038111/article/details/90696233 (setnx + expire同時操作)
====================================
https://www.runoob.com/redis/keys-scan.html
https://www.jianshu.com/p/611a492d9121 Redis原理與應用
G. 介面添加redis緩存之後並發還是很低
把redis作為緩存使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是數據量很大的時候，經典的幾個問題如下：
(一)緩存和資料庫間數據一致性問題
分布式環境下（單機就不用說了）非常容易出現緩存和資料庫間的數據一致性問題，針對這一點的話，只能說，如果你的項目對緩存的要求是強一致性的，那麼請不要使用緩存。我們只能採取合適的策略來降低緩存和資料庫間數據不一致的概率，而無法保證兩者間的強一致性。合適的策略包括 合適的緩存更新策略，更新資料庫後要及時更新緩存、緩存失敗時增加重試機制，例如MQ模式的消息隊列。
(二)緩存擊穿問題