09.30 大白話講解分佈式緩存併發衝突及其解決方案：zookeeper分佈式鎖

如果您更喜歡看視頻教程，可以看本頭條號發佈的視頻教程，絕對

大白話，手把手帶你體驗整個衝突的演示過程及解決方案：兩種方式，隨機挑選

一、背景介紹

2、分佈式緩存併發衝突問題

二、項目整合

1、廣告服務系統

功能：為媒體提供廣告的源頭服務

• 從本地緩存中獲取廣告
• 從redis緩存中獲取廣告
• 從db獲取廣告，並更新到redis緩存

2、 緩存服務系統

• 消息監聽，實時增量更新redis緩存
• 定時全量更新redis緩存

3、廣告管理系統

• 廣告的增刪改查
• 發送廣告更改的mq消息

三、rabbitmq消息重複解決方案

1、是什麼造成了消息的重複呢？

生產者在使用publisher confirm機制的時候，發送完一條消息等待RabbitMQ返回確認通知，此時網絡斷開，生產者捕獲到異常情況，為了確保消息可靠性，選擇重新發送，這樣RabbitMQ中就有兩條同樣的消息。這樣，在消費者消費的時候，就會重複消費，尤其是在交易系統/充值系統/銀行轉賬系統……中，這問題就大了。

2、解決方案

這裡進介紹下思路，簡單說下處理方案，後面我們將分佈式事務的時候，再詳細介紹可靠性這一塊

• 生產者對於發的每條消息，都帶一個唯一UUID
• 消費者通過這個UUID來校驗消息的重複性
• 唯一UUID：
• 生產者：兩次發送的key必須一致（所以發送前，這個key必須持久化）
• 唯一key可以存儲到分佈式緩存中，如：redis，可以設置個緩存時間

public class AdMessage {
​
 /** 

 * 操作類型：1為新增，2是修改
 */
 private int operation;
​
 /**
 * 主鍵字段，值為具體的ID值
 */
 private Long id;
​
 /**
 * 消息的唯一key：用於消息去重
 */
 private String uuidKey;
​
 /**
 * 廣告信息：
 */
 private String content;
}

四、實戰演練基於zk分佈式鎖解決分佈式緩存併發衝突問題

代碼下載地址：https://gitee.com/jikeh/JiKeHCN-RELEASE.git

項目名：

廣告服務系統：spring-boot-ad-service

緩存服務系統：spring-boot-cache

廣告管理系統：spring-boot-ad

1、zk分佈式鎖

• 原生zookeeper實現分佈式鎖
• 使用curator框架實現zookeeper分佈式鎖

2、廣告服務系統應用zk分佈式鎖

3、廣告緩存系統應用zk分佈式鎖

4、實戰演練

1）模擬併發衝突場景

• 廣告服務系統redis緩存更新：設置一個sleep阻塞時間
• 啟動廣告服務系統
• 訪問接口：等待刷新redis（舊數據）
• 啟動緩存服務系統
• 啟動廣告管理系統
• 修改廣告，瞬時更新redis緩存 （新數據）
• 廣告服務系統成功更新redis：舊數據舊覆蓋了新數據==>造成緩存衝突問題

2）併發正常演示

如果覺得不是大白話，請看本頭條號發佈的視頻教程哈，絕對大白話

，帶你體驗整個衝突過程：

補充資料：