大白話講解分佈式緩存併發衝突問題及其解決方案：zk分佈式鎖
一、背景介紹
如果您更喜歡看視頻教程，可以看本頭條號發佈的視頻教程，絕對大白話，手把手帶你體驗整個衝突的演示過程及解決方案：兩種方式，隨機挑選 緩存架構之實戰演練基於zk分佈式鎖解決分佈式緩存併發衝突問題
1、源架構：
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）併發正常演示
更多內容，請關注：
頭條號：極客慧
個人網站：極客慧 更多資料分享，請入羣討論：375412858