1.使用工廠模式和策略模式實(shí)現(xiàn)布隆過(guò)濾器解決緩存穿透問(wèn)題

Bitmap

Bitmap是一種數(shù)據(jù)結(jié)構(gòu)，它使用位圖來(lái)表示數(shù)據(jù)。在處理大量數(shù)據(jù)時(shí)，Bitmap可以通過(guò)將每個(gè)數(shù)據(jù)元素映射到一個(gè)位，然后使用位運(yùn)算來(lái)對(duì)數(shù)據(jù)進(jìn)行操作。
通過(guò)使用Bitmap，我們可以快速地完成排序、查找和去重等操作。優(yōu)點(diǎn)極大的節(jié)省儲(chǔ)存空間。但是，Bitmap也存在一些局限性，例如它只能表示有限的數(shù)值類型，并且對(duì)于數(shù)據(jù)稀疏的情況可能不太適用。

布隆過(guò)濾器

布隆過(guò)濾器是一種用于快速檢索一個(gè)元素是否可能存在于一個(gè)集合中的數(shù)據(jù)結(jié)構(gòu)。
它的基本原理是利用多個(gè)哈希函數(shù)，將一個(gè)元素映射成多個(gè)位，然后將這些位設(shè)置為1。當(dāng)查詢一個(gè)元素時(shí)，如果這些位都被設(shè)置為1，則認(rèn)為元素可能存在于集合中。布隆過(guò)濾器的優(yōu)點(diǎn)在于它的內(nèi)存占用極少，并且不局限于數(shù)值類型。但是，由于哈希沖突的存在，布隆過(guò)濾器也存在誤判的可能。

緩存穿透

訪問(wèn)的資源不存在，而導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到數(shù)據(jù)庫(kù)中去查詢，導(dǎo)致數(shù)據(jù)庫(kù)掛掉

用布隆過(guò)濾器解決緩存穿透問(wèn)題

不直接訪問(wèn)數(shù)據(jù)庫(kù)，而是先通過(guò)布隆過(guò)濾器判斷訪問(wèn)的資源是否存在，存在則放行，不存在則攔截。
使用BitMap作為布隆過(guò)濾器，通過(guò)多個(gè)哈希函數(shù)來(lái)將被訪問(wèn)的元素映射到位數(shù)組中的多個(gè)位置上，將對(duì)應(yīng)的位置設(shè)置為1。
當(dāng)需要判斷一個(gè)元素是否在布隆過(guò)濾器中時(shí)：只需將該元素進(jìn)行多次哈希，并檢查對(duì)應(yīng)的位數(shù)組位置是否都為1，如果其中有任意一位為0，則說(shuō)明該元素不在集合中；如果所有位都為1，則說(shuō)明該元素可能在集合中（因?yàn)橛锌赡艽嬖诠_突），需要進(jìn)一步檢查。

使用工廠模式和策略模式解決緩存穿透問(wèn)題

1. 定義布隆過(guò)濾器接口：首先定義一個(gè)布隆過(guò)濾器接口，包括添加元素和判斷元素是否存在兩個(gè)基本操作。
2. 實(shí)現(xiàn)具體的布隆過(guò)濾器類：創(chuàng)建類，實(shí)現(xiàn)布隆過(guò)濾器接口中的方法。在這個(gè)類中，需要定義布隆過(guò)潷器的數(shù)據(jù)結(jié)構(gòu)（比如位數(shù)組）、大小等屬性。
3. 定義哈希策略接口：定義一個(gè)哈希策略接口，包含計(jì)算哈希值的方法。
4. 實(shí)現(xiàn)具體的哈希策略類：創(chuàng)建多個(gè)具體的哈希策略類，每個(gè)類對(duì)應(yīng)一種哈希函數(shù)的計(jì)算方法。
5. 創(chuàng)建布隆過(guò)濾器工廠類：定義一個(gè)布隆過(guò)濾器工廠類，其中包含一個(gè)用于創(chuàng)建布隆過(guò)濾器對(duì)象的工廠方法。工廠方法接受布隆過(guò)濾器的大小和哈希策略對(duì)象作為參數(shù)，并返回一個(gè)具體的布隆過(guò)濾器對(duì)象。
6. 使用布隆過(guò)濾器工廠：在需要?jiǎng)?chuàng)建布隆過(guò)濾器對(duì)象的地方，調(diào)用布隆過(guò)濾器工廠的工廠方法來(lái)創(chuàng)建布隆過(guò)濾器對(duì)象，并傳入相應(yīng)的哈希策略對(duì)象。
   總結(jié)：使用策略模式是創(chuàng)建多個(gè)具體的哈希策略類，每個(gè)類對(duì)應(yīng)一種哈希函數(shù)。并且創(chuàng)建布隆過(guò)濾器的工廠類。
   當(dāng)需要?jiǎng)?chuàng)建布隆過(guò)濾器對(duì)象時(shí)，直接調(diào)用工廠類并傳入相應(yīng)的哈希策略對(duì)象。
   這樣可以將對(duì)象的創(chuàng)建和哈希函數(shù)的選擇解耦，更靈活的創(chuàng)建對(duì)象和選擇哈希函數(shù)。

好處

使用工廠模式和策略模式來(lái)實(shí)現(xiàn)布隆過(guò)濾器帶來(lái)以下好處：

（1）解耦性：工廠模式和策略模式的結(jié)合可以將對(duì)象的創(chuàng)建和哈希函數(shù)的選擇分離，使得各部分之間的耦合度降低。這樣在需要修改布隆過(guò)濾器的具體實(shí)現(xiàn)或者切換哈希函數(shù)時(shí)，只需要修改相應(yīng)的工廠類或策略類，而不影響其他部分。
（2）可擴(kuò)展性：通過(guò)工廠模式和策略模式，我們可以方便地添加新的布隆過(guò)濾器實(shí)現(xiàn)類和哈希函數(shù)策略類，而不需要修改現(xiàn)有代碼。這樣在需要增加新的布隆過(guò)濾器類型或者新的哈希函數(shù)時(shí)，只需添加相應(yīng)的類即可。

2.使用Redis采用一主兩從+哨兵的集群方案

使用Redis

當(dāng)用戶數(shù)量較多時(shí)，用戶頻繁的訪問(wèn)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)壓力增大，系統(tǒng)的性能下降。因此使用Redis對(duì)數(shù)據(jù)進(jìn)行緩存，減小數(shù)據(jù)庫(kù)的壓力，提高系統(tǒng)的性能和訪問(wèn)速度。

為什么采用一主兩從+哨兵的集群方案（解決高并發(fā)高可用問(wèn)題）

進(jìn)一步提高Redis的并發(fā)能力，可以搭建主從集群，實(shí)現(xiàn)讀寫(xiě)分離。
我們項(xiàng)目的redis采用一主二從的集群方案，主節(jié)點(diǎn)負(fù)責(zé)寫(xiě)數(shù)據(jù)，從節(jié)點(diǎn)負(fù)責(zé)讀數(shù)據(jù)，主節(jié)點(diǎn)寫(xiě)入數(shù)據(jù)之后，需要把數(shù)據(jù)同步到從節(jié)點(diǎn)中，實(shí)現(xiàn)了讀寫(xiě)分離，解決了高并發(fā)問(wèn)題。
哨兵是一個(gè)獨(dú)立的進(jìn)程，作為進(jìn)程，它會(huì)獨(dú)立運(yùn)行。其原理是哨兵通過(guò)發(fā)送ping命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運(yùn)行的多個(gè)Redis實(shí)例。
哨兵可以實(shí)現(xiàn)自動(dòng)故障修復(fù)：哨兵可以監(jiān)測(cè)到主節(jié)點(diǎn)宕機(jī)，自動(dòng)將從節(jié)點(diǎn)切換為主節(jié)點(diǎn)并發(fā)布通知其他從服務(wù)器修改配置文件，當(dāng)舊主服務(wù)器恢復(fù)后會(huì)成為一個(gè)新的從節(jié)點(diǎn)。

怎樣解決高并發(fā)高可用問(wèn)題

主從集群保證高并發(fā)，哨兵保證高可用。

怎樣解決數(shù)據(jù)一致性問(wèn)題

數(shù)據(jù)一致性：當(dāng)修改了數(shù)據(jù)庫(kù)的數(shù)據(jù)也要同時(shí)更新緩存的數(shù)據(jù)，緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)要保持一致。
?使用旁路緩存模式在緩存與數(shù)據(jù)庫(kù)雙寫(xiě)時(shí)保持一致性。
先更新數(shù)據(jù)庫(kù)，后刪除緩存。理論上會(huì)出現(xiàn)不一致的情況，但概率較小因?yàn)榫彺娴膶?xiě)入速度是比數(shù)據(jù)庫(kù)的寫(xiě)入速度快很多。

**更新緩存替換為刪除緩存**，那么**下一次執(zhí)行的查詢操作都會(huì)從數(shù)據(jù)庫(kù)中加載數(shù)據(jù)**，此時(shí)數(shù)據(jù)一致性就有了保證。

比較方法時(shí)注意：緩存被清空后，線程只能到數(shù)據(jù)庫(kù)中查詢，在數(shù)據(jù)庫(kù)中查完就會(huì)直接更新緩存。
先查緩存，再查數(shù)據(jù)庫(kù)。
**重點(diǎn)在與看結(jié)束后數(shù)據(jù)庫(kù)與緩存是否一致，用多久一致的。**

（1）先刪緩存，再更新數(shù)據(jù)庫(kù)：
（多線程調(diào)度不確定）可能會(huì)導(dǎo)致A刪緩存，B去查緩存“空”-->然后去查數(shù)據(jù)庫(kù)-->拿著數(shù)據(jù)庫(kù)中數(shù)據(jù)更新緩存-->A更新數(shù)據(jù)庫(kù)
結(jié)束后：數(shù)據(jù)庫(kù)中是A更新后的信息，緩存中是原始信息。（2）先更數(shù)據(jù)庫(kù)，再刪緩存：
A更數(shù)據(jù)庫(kù)，B查緩存-->B拿到原始數(shù)據(jù)-->A刪除緩存
結(jié)束后：數(shù)據(jù)庫(kù)中新數(shù)據(jù)，緩存被刪即還會(huì)獲得新數(shù)據(jù)。【從B在數(shù)據(jù)庫(kù)拿到原始數(shù)據(jù)到寫(xiě)到緩存中，但持續(xù)時(shí)間相比其他方法短】（3）延遲雙刪：
A刪緩存，B去查緩存“空”-->然后去查數(shù)據(jù)庫(kù)-->拿著數(shù)據(jù)庫(kù)中數(shù)據(jù)更新緩存-->A更新數(shù)據(jù)庫(kù)-->延遲刪除緩存
結(jié)束后：相比1最后緩存與數(shù)據(jù)庫(kù)時(shí)一致的，但性能上不如2

總結(jié)：采取旁路緩存使緩存和數(shù)據(jù)庫(kù)保持?jǐn)?shù)據(jù)的一致性，
讀的時(shí)候，先讀緩存，緩存沒(méi)有的話，就讀數(shù)據(jù)庫(kù)，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。
更新的時(shí)候，先更新數(shù)據(jù)庫(kù)，再刪除緩存中對(duì)應(yīng)著數(shù)據(jù)庫(kù)更新的數(shù)據(jù)。

3.使用Spring Task實(shí)現(xiàn)訂單超時(shí)取消，使用WebSocket實(shí)現(xiàn)用戶催單。

WebSocket

基于TCP的一種新的網(wǎng)絡(luò)協(xié)議。實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信——瀏覽器和服務(wù)器只需完成一次握手，兩者就可以建立連接，雙向數(shù)據(jù)傳輸。
WebSocket：兩邊都可以主動(dòng)通信。
應(yīng)用場(chǎng)景：網(wǎng)頁(yè)聊天、視頻彈幕，股票信息實(shí)時(shí)更新（服務(wù)器主動(dòng)推送到網(wǎng)頁(yè)上的）

訂單超時(shí)取消流程

客戶下單后未支付，訂單一直處于“待支付”狀態(tài)。
使用Spring Task工具的cron表達(dá)式設(shè)置定時(shí)任務(wù)觸發(fā)時(shí)間，每分鐘檢查一次是否存在支付超時(shí)的訂單，如果存在超時(shí)則將訂單狀態(tài)修改為“已取消”。

用戶催單流程

用戶在小程序中點(diǎn)擊催單按鈕后，根據(jù)用戶id查詢是否有支付成功的訂單，有則調(diào)用WebSocke實(shí)現(xiàn)服務(wù)端向客戶端推送消息，展示用戶訂單和支付成功信息。

4.使用自定義攔截器和JWT令牌實(shí)現(xiàn)用戶登錄認(rèn)證，用ThreadLocal存儲(chǔ)用戶ID

用戶登錄認(rèn)證流程

（1）用戶登錄時(shí)，發(fā)送用戶名和密碼給服務(wù)器，服務(wù)器驗(yàn)證通過(guò)則生成一個(gè)包含用戶信息的JWT令牌，并將其發(fā)送給客戶端。
（2）客戶端受到JWT令牌后，保存在本地中，
（3）每當(dāng)用戶發(fā)起請(qǐng)求時(shí)，將JWT令牌添加到請(qǐng)求頭中
（4）服務(wù)器端的自定義攔截器會(huì)攔截所有請(qǐng)求，從請(qǐng)求頭中提取JWT令牌。
（5）攔截器解析JWT令牌，獲取用戶信息，并將其存儲(chǔ)在ThreadLocal中,以避免在每次請(qǐng)求時(shí)都去解析JWT令牌。
（6）攔截器可以檢查用戶是否已經(jīng)通過(guò)認(rèn)證，通過(guò)則處理請(qǐng)求，未通過(guò)則返回錯(cuò)誤信息。
（7）請(qǐng)求完成后，攔截器remove清楚ThreadLocal里的用戶信息

為什么用JWT不用Session

傳統(tǒng)的Session用戶認(rèn)證方案:

(1)用戶向服務(wù)器發(fā)送用戶名和密碼。
(2)服務(wù)器驗(yàn)證通過(guò)后，在當(dāng)前**對(duì)話（session）**里面保存相關(guān)數(shù)據(jù)，比如用戶角色、登錄時(shí)間等等。
(3)服務(wù)器向用戶返回一個(gè) session_id，寫(xiě)入用戶的 Cookie。
(4)用戶隨后的每一次請(qǐng)求，都會(huì)通過(guò) Cookie將 session_id 傳回服務(wù)器。
(5)服務(wù)器收到 session_id，找到對(duì)應(yīng)的session并獲取前期保存的數(shù)據(jù)，由此得知用戶的身份。

這種傳統(tǒng)的通過(guò)session的方式適用于前后端不分離的情況，因?yàn)?strong>session是保存在服務(wù)器端，因此對(duì)于跨域或服務(wù)器集群的情況很不友好。
而JWT解決了跨域問(wèn)題，而且（1）jwt基于json，數(shù)據(jù)處理方便。（2）使用非對(duì)稱加密和簽名技術(shù)，安全性高。（3）資源服務(wù)使用JWT，可不依賴認(rèn)證服務(wù)即可完成授權(quán)。

為什么用ThreadLocal

ThreadLocal為每個(gè)線程提供單獨(dú)一份存儲(chǔ)空間，具有線程隔離的效果，只有在線程內(nèi)才能獲取到對(duì)應(yīng)的值，線程外則不能訪問(wèn)。
這樣可以保證線程之間的數(shù)據(jù)隔離，避免了線程安全問(wèn)題。

ThreadLocal使用流程

每次執(zhí)行請(qǐng)求時(shí)攔截器將用戶信息用set保存在ThreadLocal中，ThreadLocal每次調(diào)用set時(shí)是一個(gè)獨(dú)立的線程，當(dāng)另一個(gè)用戶調(diào)用ThreadLocal的set時(shí)方法 時(shí)，就會(huì)新建另一個(gè)線程，線程之間互不影響，當(dāng)對(duì)應(yīng)線程在調(diào)用get時(shí)候，就會(huì)請(qǐng)求到set時(shí)候的信息。在攔截器執(zhí)行過(guò)后的方法中添加ThreadLocal線程remove()方法，這樣每次請(qǐng)求結(jié)束后會(huì)將ThreadLocal線程中的數(shù)據(jù)刪除，這樣可以防止線程過(guò)多內(nèi)存泄露。

為什么用攔截器不用過(guò)濾器、切面

粒度更細(xì)： 攔截器可以針對(duì)特定的控制器或控制器方法進(jìn)行攔截，實(shí)現(xiàn)精確的攔截邏輯，
而過(guò)濾器是基于URL路徑進(jìn)行攔截，無(wú)法做到針對(duì)具體的控制器或方法，切面也是基于切點(diǎn)進(jìn)行攔截，粒度相對(duì)較粗。

5.使用AOP統(tǒng)一記錄登錄者操作日志

使用AOP切片，將登陸者增刪改用戶信息的操作信息記錄到數(shù)據(jù)庫(kù)中。

流程

（1）建表日志信息表
（2）自定義注解，在增刪改等方法運(yùn)行時(shí)調(diào)用切面
（3）定義切面類，操作者記錄：先通過(guò)當(dāng)前請(qǐng)求的請(qǐng)求頭拿到JWT令牌并解析出操作者的用戶ID，然后記錄操作命令和操作時(shí)間等信息插入到日志信息表中。

6.使用Redis分布式鎖實(shí)現(xiàn)高并發(fā)商品秒殺，解決超賣(mài)問(wèn)題

為什么不用單體鎖

單體應(yīng)用難以滿足實(shí)際高并發(fā)訪問(wèn)需求，會(huì)將單體應(yīng)用部署到多個(gè)tomcat實(shí)例上，由負(fù)載均衡將請(qǐng)求分發(fā)到不同實(shí)例上。
單體鎖（synchronized、ReentrantLock）是JVM層面的鎖，只能控制單個(gè)實(shí)例上的并發(fā)訪問(wèn)安全，多實(shí)例下依然存在數(shù)據(jù)一致性問(wèn)題。

分布式鎖

分布式鎖指的是，所有服務(wù)中的所有線程都去獲取同一把鎖，但只有一個(gè)線程可以成功的獲得鎖，其他沒(méi)有獲得鎖的線程必須全部等待，直到持有鎖的線程釋放鎖。

RedLock解決Redis集群主從不同步數(shù)據(jù)丟失問(wèn)題

Redisson使用主從集群模式，主節(jié)點(diǎn)掛掉，從節(jié)點(diǎn)沒(méi)有同步到鎖的情況：
使用RedLock，針對(duì)Redis中所有節(jié)點(diǎn)來(lái)進(jìn)行同步，能夠保證超過(guò)半數(shù)的Redis加鎖了才算加鎖成功，從而保證并發(fā)安全。

解決流程

多用戶并發(fā)操作的情況下，多個(gè)用戶嘗試購(gòu)買(mǎi)同一件商品，導(dǎo)致商品庫(kù)存不足或者超賣(mài)。
采用Redis提供的Redisson組件實(shí)現(xiàn)Redis分布式鎖，來(lái)控制并發(fā)訪問(wèn)。
當(dāng)一個(gè)線程去獲取鎖，鎖的VALUE中存入U(xiǎn)UID來(lái)保證鎖和當(dāng)前線程綁定，
當(dāng)前線程獲取鎖成功開(kāi)始處理業(yè)務(wù)時(shí)，內(nèi)部會(huì)有watch dog看門(mén)狗，每隔10s看當(dāng)前線程是否還持有鎖，如果持有則給鎖延長(zhǎng)生存時(shí)間。

當(dāng)Redis集群部署時(shí)，為了解決主節(jié)點(diǎn)掛掉從節(jié)點(diǎn)沒(méi)有同步到鎖的情況，使用RedLock，針對(duì)Redis中所有節(jié)點(diǎn)來(lái)進(jìn)行同步，能夠保證超過(guò)半數(shù)的Redis加鎖了才算加鎖成功，從而保證并發(fā)安全。

另外：用戶限流，防止同一用戶多次秒殺

使用布隆過(guò)濾器記錄用戶和商品ID來(lái)解決。
當(dāng)用戶參與秒殺時(shí)，判斷是否ID是否記錄存在布隆過(guò)濾器中，不存在證明該用戶是第一次參與秒殺改商品，放行繼續(xù)后續(xù)業(yè)務(wù)；
過(guò)濾器中存在，則禁止繼續(xù)秒殺。

7.基于Redis使用防重Token和lua腳本，防止重復(fù)提交訂單

lua腳本作用

使用lua腳本實(shí)現(xiàn)原子性的查詢并刪除操作。為了確保即使多個(gè)請(qǐng)求同時(shí)到達(dá)，也只有一個(gè)請(qǐng)求能夠成功刪除Token。

流程

用戶發(fā)起請(qǐng)求時(shí)，服務(wù)端生成唯一的token作為信息憑證。
將Token存入Redis并設(shè)定過(guò)期時(shí)間，防止Redis內(nèi)存溢出。
在后續(xù)請(qǐng)求中要攜帶這個(gè)Token，服務(wù)器收到后，在Redis中通過(guò)lua腳本進(jìn)行原子性的查詢并刪除操作，
如果Token存在并被成功刪除說(shuō)明是第一次請(qǐng)求則繼續(xù)處理業(yè)務(wù)生成訂單；如果不存在說(shuō)明是重復(fù)請(qǐng)求，則返回錯(cuò)誤提示。