spring cloud服務(wù)連接超時問題及解決
一 . feign連接超時解決方法
在配置文件中添加配置(application.propeties)
設(shè)置超時時間5秒
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
或者設(shè)置不超時
hystrix.command.default.execution.timeout.enabled: false
二 . 超時案例
做項目時有一個接口,服務(wù)A調(diào)用服務(wù)B,服務(wù)B又調(diào)用服務(wù)C,服務(wù)C返回服務(wù)B,服務(wù)B有調(diào)用服務(wù)A。。。。
好暈,直接上圖吧。
因?yàn)閞equest更改了數(shù)據(jù)表,之后調(diào)用workflow,事務(wù)沒有提交在等待方法執(zhí)行完,workflow又反過來調(diào)用request更新數(shù)據(jù)表,因?yàn)槭峭粭l數(shù)據(jù),之前的沒提交,所以就一直等待他提交,這樣就死鎖了,不管怎么設(shè)置超時時間都沒有用的。
在這里惡補(bǔ)一下數(shù)據(jù)庫的事務(wù)問題。
事務(wù)隔離級別
事務(wù)隔離級別由弱到強(qiáng)分別是:
- READ_UNCOMMITTED(未提交讀)
- READ_COMMITTED(提交讀)
- REPEATABLE_READ(重復(fù)讀)
- SERIALIZABLE(串行讀)
隔離界別 | 臟讀 | 不可重復(fù)讀 | 幻讀 |
---|---|---|---|
READ_UNCOMMITTED | 允許 | 允許 | 允許 |
READ_COMMITTED | 不允 | 允許 | 允許 |
REPEATABLE_READ | 不允 | 不允 | 允許 |
SERIALIZABLE | 不允 | 不允 | 不允許 |
臟讀:
- 臟讀指的是一個事務(wù)允許讀取其他正在運(yùn)行的事務(wù)還沒有提交的數(shù)據(jù),這種情況的發(fā)生主要因?yàn)闆]有加鎖。
不可重復(fù)讀:
- 是指在一個事務(wù)內(nèi),多次讀同一數(shù)據(jù)。在這個事務(wù)還沒有結(jié)束時,另外一個事務(wù)也訪問該同一數(shù)據(jù)。那么,在第一個事務(wù)中的兩次讀數(shù)據(jù)之間,由于第二個事務(wù)的修改,那么第一個事務(wù)兩次讀到的的數(shù)據(jù)可能是不一樣的。這樣就發(fā)生了在一個事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的,因此稱為是不可重復(fù)讀。(即不能讀到相同的數(shù)據(jù)內(nèi)容)
- 例如,一個編輯人員兩次讀取同一文檔,但在兩次讀取之間,作者重寫了該文檔。當(dāng)編輯人員第二次讀取文檔時,文檔已更改。原始讀取不可重復(fù)。如果只有在作者全部完成編寫后編輯人員才可以讀取文檔,則可以避免該問題。
- 要達(dá)到允許可重復(fù)讀,必須讓當(dāng)前事務(wù)保持一個讀共享鎖。
幻讀:
幻讀指的是事務(wù)不是串行發(fā)生時發(fā)生的一種現(xiàn)象,是事務(wù)A讀取了事務(wù)B已提交的新增數(shù)據(jù)。
- 例如第一個事務(wù)對一個表的所有數(shù)據(jù)進(jìn)行修改,同時第二個事務(wù)向表中插入一條新數(shù)據(jù)。
- 那么操作第一個事務(wù)的用戶就發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行,就像發(fā)生了幻覺一樣。
- 解決幻讀的方法是增加范圍鎖或者表鎖。
MySQL的默認(rèn)事務(wù)隔離級別是REPEATABLE_READ,ORACLE、SQL Server、DB2和PostgreSQL的默認(rèn)事務(wù)隔離級別是READ_COMMITED
事務(wù)的特性(ACID特性)
原子性(Atomicity)
- 事務(wù)是數(shù)據(jù)庫的邏輯工作單位,事務(wù)中包括的諸操作要么全做,要么全不做。
一致性(Consistency)
- 事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。一致性與原子性是密切相關(guān)的。
隔離性(Isolation)
- 一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾。
持續(xù)性/永久性(Durability)
- 一個事務(wù)一旦提交,它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的。
流程2和流程1的區(qū)別是request的更新操作是在返回3之后,返回3是workflow調(diào)用request服務(wù)進(jìn)行更新操作,此刻更完之后就會提交,之后request中又進(jìn)行一次更新操作。
能成功的原因是,workflow調(diào)用request服務(wù)進(jìn)行更新操作的事務(wù)和request服務(wù)自己更新操作的事務(wù)不是一個,不存在等待。
總結(jié)
以上為個人經(jīng)驗(yàn),希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
Java工程mybatis實(shí)現(xiàn)多表查詢過程詳解
這篇文章主要介紹了Java工程mybatis實(shí)現(xiàn)多表查詢過程詳解,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2020-06-06Java8實(shí)現(xiàn)對List<Integer>的求和
這篇文章主要介紹了Java8實(shí)現(xiàn)對List<Integer>的求和方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-05-05springboot 多數(shù)據(jù)源配置不生效遇到的坑及解決
這篇文章主要介紹了springboot 多數(shù)據(jù)源配置不生效遇到的坑及解決,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-11-11