springcloud 中使用redis以及rabbitMQ實現分散式事務
分散式事務的補償機制,在很多成熟的案例都是使用TCC機制,來實現資源凍結,以及提交,失敗則釋放資源,很多情況下,處理業務的特殊情況需要對不支援事務的redis進行手動的事務補償。
比如,現在人臉識別入庫的服務,演算法識別人臉的服務,這兩個是依賴性比較高的服務,而且存在長事務,如果需要查詢頻繁的操作,就需要把資料放到redis,快取 減輕資料庫的壓力,而發生事務的操作,在方法上即使使用了@Transactional註解只是針對有事務性質的JDBC操作,而redis則需要手動的事務補償,進行異常後處理。
通常的做法是人臉識別的事務先提交,返回事務的結果,然後演算法庫識別事務進行,如果演算法事務出了異常,就回滾操作,而人臉識別的事務再做事務的回滾,做到的是最終一致性
即使後面使用rabbitMQ來處理這種事務補償,最終也只能達到最終一致性,RabbitMQ提供,類似TTL,DLX等定時任務的操作,這種針對秒殺,定時付款等場景還是挺適用,但是對資料要求實時強一致性,可能就需要到zk+dubbo之類的RPC框架來支援。後續這個專題,嘗試從其他的資料找到相應的實際的解決分散式事務的補償機制的更好實現提供給讀者。
目前本月的專題為springcloud結合人工智慧專案的實踐,如果需要程式碼可以留言獲取,截圖的程式碼為慕課網的例項。
相關推薦
springcloud 中使用redis以及rabbitMQ實現分散式事務
分散式事務的補償機制,在很多成熟的案例都是使用TCC機制,來實現資源凍結,以及提交,失敗則釋放資源,很多情況下,處理業務的特殊情況需要對不支援事務的redis進行手動的事務補償。 比如,現在人臉識別入庫的服務,演算法識別人臉的服務,這兩個是依賴性比較高的服務,而且存在長事務,如果需要查詢頻繁
高併發場景系列(一) 利用redis實現分散式事務鎖,解決高併發環境下減庫存
問題描述:某電商平臺,首發一款新品手機,每人限購2臺,預計會有10W的併發,在該情況下,如果扣減庫存,保證不會超賣 方案一 利用資料庫鎖機制,對記錄進行鎖定,再進行操作 SELECT * from goods where ID =1 for updat
利用redis實現分散式事務鎖,解決高併發環境下減庫存
http://download.redis.io/releases/ 安裝: sudo make test 測試編譯 sudo make install 啟動: redis-servre cd “安裝目錄” redis-server ./redis-3.2.9/redis
[轉載]使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案
前陣子從支付寶轉賬1萬塊錢到餘額寶,這是日常生活的一件普通小事,但作為網際網路研發人員的職業病,我就思考支付寶扣除1萬之後,如果系統掛掉怎麼辦,這時餘額寶賬戶並沒有增加1萬,資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子,比如在電商系統中,當有使用者下單後,除了在訂單表插
redis與zk實現分散式鎖
概述 分散式鎖,如果你有多個機器在訪問同一個共享資源, 那麼這個時候,如果你需要加個鎖,讓多個分散式的機器在訪問共享資源的時候序列起來 那麼這個時候,那個鎖,多個不同機器上的服務共享的鎖,就是分散式鎖 分散式鎖當然有很多種不同的實現方案,redis分散式鎖,
關於利用MQ實現分散式事務的想法【轉】
轉自:https://www.jianshu.com/p/bafb09954f18 假設:訊息服務不丟訊息 場景 服務A 服務B 服務C 訊息服務Q 虛擬碼 服務A中 transaction{ A本地事務 B.callB(); C.callC(); A本地事務
使用redis和zookeeper實現分散式鎖
1.分散式鎖 分散式鎖一般用在分散式系統或者多個應用中,用來控制同一任務是否執行或者任務的執行順序。在專案中,部署了多個tomcat應用,在執行定時任務時就會遇到同一任務可能執行多次的情況,我們可以藉助分散式鎖,保證在同一時間只有一個tomcat應用執行了定時任務。 &nb
【連載】redis庫存操作,分散式鎖的四種實現方式[三]--基於Redis watch機制實現分散式鎖
一、redis的事務介紹 1、 Redis保證一個事務中的所有命令要麼都執行,要麼都不執行。如果在傳送EXEC命令前客戶端斷線了,則Redis會清空事務佇列,事務中的所有命令都不會執行。而一旦客戶端傳送了EXEC命令,所有的命令就都會被執行,即使此後客戶端斷線也沒關係,因為Redis中已經記錄了所有要執行的
Java採用Redis相關命令實現分散式鎖
Java本地鎖(synchronized或J.U.C.Lock)只能解決當前jvm下的併發問題,如果是叢集環境下或者一個機器跑多個jvm例項且相互間有互動或重疊時,此時需要一個“中央鎖”來進行控制。 命令 SET resource-name anystring NX E
使用Redis SETNX 命令實現分散式鎖
Redis有一系列的命令,特點是以NX結尾,NX是Not eXists的縮寫,如SETNX命令就應該理解為:SET if Not eXists。這系列的命令非常有用,這裡講使用SETNX來實現分散式鎖。 用SETNX實現分散式鎖利用SETNX非常簡單地實現分散式鎖。例如:某
介紹下用訊息佇列實現分散式事務
在OIE的時代, 上層應用開發人員總是認為資料庫足夠強大, 所以很多業務可以做的非常簡單。 比如A轉賬50元給B這個過程, 只要寫一個簡單sql語句塊就ok了。 開始事務; A賬戶減去50 B賬戶增加50 提交事務。
使用SQL SERVER的Link Server實現分散式事務
ansi_warning和ansi_nulls 兩個選項必須開啟,好像對系統也沒啥影響。 樓主再檢查一下兩個地方,經測試,在要使用分散式事務時,這是必須要設定的。 1、連結伺服器和名稱解析問題 -- 建立連結伺服器 EXEC sp_addlinkedserver
RocketMq在閹割訊息回查checkTransactionState後實現分散式事務
利用rocketMQ解決分散式事務 在rocketMQ中生產者有三種角色 NormalProducer(普通)、OrderProducer(順序)、TransactionProducer(事務) 根據名字大概可以看出各個代表著什麼作用,我們這裡用 Trans
利用Rocketmq4.2版來實現分散式事務
花了點時間學了RocketMQ,下面是本人的一點點心得,如果覺的寫的好就點個贊,但如果你要借鑑話,我還是勸你看下面參考資料裡的視訊(作者為阿里牛人),雖然他分享的視訊是為了推銷阿里雲的DRDS、ONS(RocketMQ阿里版),只是講了個大概,沒有細說,但是指明一個大的方向,
CentOS中redis以及python中redis模組的安裝
CentOS下redis的安裝 1.下載redis的安裝包 2.tar -zxfz redis-3.2.0.tar.gz 進行解壓 3.進入其安裝目錄底下 4.make安裝 5.啟動服務端
用訊息系統實現分散式事務
從支付寶轉賬1萬塊錢到餘額寶,這是日常生活的一件普通小事,但作為網際網路研發人員的職業病,我就思考支付寶扣除1萬之後,如果系統掛掉怎麼辦,這時餘額寶賬戶並沒有增加1萬,資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子,比如在電商系統中,當有使用者下單後,除
使用Redis SETNX 命令實現分散式鎖”
使用Redis的 SETNX 命令可以實現分散式鎖,本文介紹其實現方法。 直接進入正題,現在分散式的應用場景很多,為了保持資料的一致性,經常碰到需要對資源加鎖的情形。 利用redis來實現分散式鎖就是其中的一種實現方案。 SETNX命令簡介 命令格式 SETNX
使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案(三)
Begin transaction update A set amount=amount-10000 where userId=1; update B set amount=amount+10000 where userId=1; End t
Redis 以及 Session 實現使用者登入的整體流程
說在前面 簡單總結一下專案中登入的整個流程。 其中包含 使用者登入失敗次數 使用者資訊儲存 請求Url攔截 使用者登入失敗次數 定義一個次數限制的介面: 定義一個類,單獨把RedisUtil抽離: 最後定義一個密碼錯誤計數限制策略類,去繼承 Abstr
RocketMQ中介軟體實現分散式事務原理分析
案例:Bob向Smith轉賬,那我們到底是先發送訊息,還是先執行扣款操作? 好像都可能會出問題。如果先發訊息,扣款操作失敗,那麼Smith的賬戶裡面會多出一筆錢。反過來,如果先執行扣款操作,後傳送