我有一個(gè)方法@Transactionalpublic void updateSharedStateByCommunity(List[]idList)從以下 REST API 調(diào)用此方法：@RequestMapping(method = RequestMethod.POST)public ret_type updateUser(param) { // call updateSharedStateByCommunity}現(xiàn)在ID列表非常大，比如200000，當(dāng)我嘗試處理它時(shí)，需要花費(fèi)很多時(shí)間并且在客戶端發(fā)生超時(shí)錯(cuò)誤。因此，我想將其拆分為兩個(gè)調(diào)用，每個(gè)調(diào)用的列表大小為 100000。但是，問題是，它被視為兩個(gè)獨(dú)立的交易。注意：2次呼叫只是一個(gè)例子，如果號(hào)碼id更大的話，它可以分為多次。我需要確保對(duì)單個(gè)事務(wù)進(jìn)行兩次單獨(dú)的調(diào)用。如果這 2 個(gè)調(diào)用中的任何一個(gè)失敗，那么它應(yīng)該回滾到所有操作。另外，在客戶端，我們需要顯示進(jìn)度對(duì)話框，所以我不能只使用超時(shí)。
4 回答
繁星點(diǎn)點(diǎn)滴滴
TA貢獻(xiàn)1803條經(jīng)驗(yàn) 獲得超3個(gè)贊
IMO 對(duì)您的問題最明顯的直接答案是稍微更改代碼：
@RequestMapping(method = RequestMethod.POST)
public ret_type updateUser(param) {
updateSharedStateByCommunityBlocks(resolveIds);
}
...
And in Service introduce a new method (if you can't change the code of the service provide an intermediate class that you'll call from controller with the following functionality):
@Transactional
public updateSharedStatedByCommunityBlocks(resolveIds) {
List<String> [] blocks = split(resolveIds, 100000); // 100000 - bulk size
for(List<String> block :blocks) {
updateSharedStateByCommunity(block);
}
}
如果此方法位于同一服務(wù)中，則@Transactional原始方法updateSharedStateByCommunity不會(huì)執(zhí)行任何操作，因此它會(huì)起作用。如果您將此代碼放入其他類中，那么它將起作用，因?yàn)?spring 事務(wù)的默認(rèn)傳播級(jí)別是“必需”
因此它滿足了苛刻的要求：您想要進(jìn)行一次交易 - 您已經(jīng)做到了?，F(xiàn)在所有代碼都在同一個(gè)事務(wù)中運(yùn)行?，F(xiàn)在每個(gè)方法都使用 100000 個(gè) ID 運(yùn)行，而不是使用所有 id，一切都是同步的:)
然而，這種設(shè)計(jì)由于許多不同的原因而存在問題。
正如您在問題的最后一句中所說，它不允許跟蹤進(jìn)度（向用戶顯示）。REST 是同步的。
它假設(shè)網(wǎng)絡(luò)是可靠的，并且等待 30 分鐘在技術(shù)上不是問題（不考慮 UX 和必須等待的“緊張”用戶:)）
除此之外，網(wǎng)絡(luò)設(shè)備可以強(qiáng)制關(guān)閉連接（例如具有預(yù)先配置的請(qǐng)求超時(shí)的負(fù)載均衡器）。
這就是為什么人們建議某種異步流。
我可以說，您仍然可以使用異步流，生成任務(wù)，并在每次批量更新后一些共享狀態(tài)（在單個(gè)實(shí)例的情況下在內(nèi)存中）和持久狀態(tài)（如集群情況下的數(shù)據(jù)庫）。
這樣與客戶端的交互就會(huì)改變：
客戶端使用 200000 個(gè) id 調(diào)用“updateUser”
服務(wù)會(huì)“立即”響應(yīng)，例如“我收到了您的請(qǐng)求，這是一個(gè)請(qǐng)求 ID，請(qǐng)偶爾對(duì)我進(jìn)行 ping 操作，看看會(huì)發(fā)生什么情況。
服務(wù)啟動(dòng)異步任務(wù)并在單個(gè)事務(wù)中逐塊處理數(shù)據(jù)
客戶端使用該 id 調(diào)用“get”方法，服務(wù)器從共享狀態(tài)讀取進(jìn)度。
一旦準(zhǔn)備好，“獲取”方法將響應(yīng)“完成”。
如果事務(wù)執(zhí)行期間出現(xiàn)故障，則回滾完成，并且進(jìn)程將數(shù)據(jù)庫狀態(tài)更新為“失敗”。
您還可以使用更現(xiàn)代的技術(shù)來通知服務(wù)器（例如網(wǎng)絡(luò)套接字），但這超出了這個(gè)問題的范圍。
這里需要考慮的另一件事是：據(jù)我所知，處理 200000 個(gè)對(duì)象應(yīng)該在不到 30 分鐘的時(shí)間內(nèi)完成，對(duì)于現(xiàn)代 RDBMS 來說還不夠。當(dāng)然，在不知道您的用例的情況下，很難判斷那里發(fā)生了什么，但也許您可以優(yōu)化流程本身（使用批量操作、減少對(duì)數(shù)據(jù)庫的請(qǐng)求數(shù)量、緩存等）。
四季花海
TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超5個(gè)贊
在這些場景中，我的首選方法是使調(diào)用異步（Spring Boot 允許使用注釋@Async），因此客戶端不會(huì)期望任何 HTTP 響應(yīng)。該通知可以通過 WebSocket 完成，該 WebSocket 將向客戶端推送一條消息，其中包含每個(gè) X 項(xiàng)的處理進(jìn)度。
當(dāng)然，它會(huì)給您的應(yīng)用程序增加更多的復(fù)雜性，但如果您正確設(shè)計(jì)該機(jī)制，您將能夠?qū)⑵渲赜糜谀鷮砜赡苊媾R的任何其他類似操作。
MYYA
TA貢獻(xiàn)1868條經(jīng)驗(yàn) 獲得超4個(gè)贊
從技術(shù)角度來看，可以通過傳播來完成org.springframework.transaction.annotation.Propagation#NESTED，NESTED 行為使嵌套 Spring 事務(wù)使用相同的物理事務(wù)，但在嵌套調(diào)用之間設(shè)置保存點(diǎn)，因此內(nèi)部事務(wù)也可以獨(dú)立于外部事務(wù)回滾，或者讓它們傳播。但限制僅適用于org.springframework.jdbc.datasource.DataSourceTransactionManager數(shù)據(jù)源。
但是對(duì)于非常大的數(shù)據(jù)集，它仍然需要更多的時(shí)間來處理并使客戶端等待，因此從解決方案的角度來看，也許使用異步方法會(huì)更好，但這取決于您的要求。
一只斗牛犬
TA貢獻(xiàn)1784條經(jīng)驗(yàn) 獲得超2個(gè)贊
該@Transactional注釋接受 atimeout（盡管并非所有底層實(shí)現(xiàn)都支持它）。我反對(duì)嘗試將 ID 拆分為兩個(gè)調(diào)用，而是嘗試修復(fù)超時(shí)（畢竟，您真正想要的是單個(gè)、全有或全無的事務(wù)）。您可以為整個(gè)應(yīng)用程序設(shè)置超時(shí)，而不是針對(duì)每個(gè)方法設(shè)置超時(shí)。
添加回答
舉報(bào)
0/150
提交
取消