一 . feign連接超時解決方法

在配置文件中添加配置(application.propeties)

設置超時時間5秒

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000

或者設置不超時

hystrix.command.default.execution.timeout.enabled: false

二 . 超時案例

做項目時有一個接口，服務A調用服務B，服務B又調用服務C，服務C返回服務B，服務B有調用服務A。。。。

好暈，直接上圖吧。

因為request更改了數(shù)據(jù)表，之后調用workflow,事務沒有提交在等待方法執(zhí)行完，workflow又反過來調用request更新數(shù)據(jù)表，因為是同一條數(shù)據(jù)，之前的沒提交，所以就一直等待他提交，這樣就死鎖了，不管怎么設置超時時間都沒有用的。

在這里惡補一下數(shù)據(jù)庫的事務問題。

事務隔離級別

事務隔離級別由弱到強分別是：

• READ_UNCOMMITTED(未提交讀)
• READ_COMMITTED（提交讀）
• REPEATABLE_READ（重復讀）
• SERIALIZABLE（串行讀）

臟讀：

• 臟讀指的是一個事務允許讀取其他正在運行的事務還沒有提交的數(shù)據(jù)，這種情況的發(fā)生主要因為沒有加鎖。

不可重復讀：

• 是指在一個事務內，多次讀同一數(shù)據(jù)。在這個事務還沒有結束時，另外一個事務也訪問該同一數(shù)據(jù)。那么，在第一個事務中的兩次讀數(shù)據(jù)之間，由于第二個事務的修改，那么第一個事務兩次讀到的的數(shù)據(jù)可能是不一樣的。這樣就發(fā)生了在一個事務內兩次讀到的數(shù)據(jù)是不一樣的，因此稱為是不可重復讀。（即不能讀到相同的數(shù)據(jù)內容）
• 例如，一個編輯人員兩次讀取同一文檔，但在兩次讀取之間，作者重寫了該文檔。當編輯人員第二次讀取文檔時，文檔已更改。原始讀取不可重復。如果只有在作者全部完成編寫后編輯人員才可以讀取文檔，則可以避免該問題。
• 要達到允許可重復讀，必須讓當前事務保持一個讀共享鎖。

幻讀：

幻讀指的是事務不是串行發(fā)生時發(fā)生的一種現(xiàn)象，是事務A讀取了事務B已提交的新增數(shù)據(jù)。

• 例如第一個事務對一個表的所有數(shù)據(jù)進行修改，同時第二個事務向表中插入一條新數(shù)據(jù)。
• 那么操作第一個事務的用戶就發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行，就像發(fā)生了幻覺一樣。
• 解決幻讀的方法是增加范圍鎖或者表鎖。

MySQL的默認事務隔離級別是REPEATABLE_READ，ORACLE、SQL Server、DB2和PostgreSQL的默認事務隔離級別是READ_COMMITED

事務的特性(ACID特性)

原子性(Atomicity)

• 事務是數(shù)據(jù)庫的邏輯工作單位，事務中包括的諸操作要么全做，要么全不做。

一致性(Consistency)

• 事務執(zhí)行的結果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。一致性與原子性是密切相關的。

隔離性(Isolation)

• 一個事務的執(zhí)行不能被其他事務干擾。

持續(xù)性/永久性(Durability)

• 一個事務一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應該是永久性的。

流程2和流程1的區(qū)別是request的更新操作是在返回3之后，返回3是workflow調用request服務進行更新操作，此刻更完之后就會提交，之后request中又進行一次更新操作。

能成功的原因是，workflow調用request服務進行更新操作的事務和request服務自己更新操作的事務不是一個，不存在等待。

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論