框架：spring
資料庫：innodb
**位址
isolation=isolation.serializable
事務1：序列化
事務2：不可重複讀（預設隔離級別）
執行順序
結果1開啟 - 2開啟 - 2結束 - 1結束
事務1正常，事務2發生死鎖異常
1開啟 - 2開啟 - 1結束 - 2結束
事務2的操作覆蓋了事務1的操作
2開啟 - 1開啟 - 1結束 - 2結束
事務2的操作覆蓋了事務1的操作
2開啟 - 1開啟 - 2結束 - 1結束
事務1正常，事務2發生死鎖異常
總結：事務1開啟時給資料上鎖，具體哪種鎖沒有研究
如果事務2先結束，提交事務時由於事務1沒有釋放鎖，所以會發生死鎖異常，這種結果可以保證一致性
如果事務2後結束，提交事務時事務1已經釋放了鎖，事務2使用舊資料更新資料庫導致資料不一致
前提：需要保證一致的邏輯在乙個事務中
先申請排他鎖
加鎖：select … for update
例如：
select id,
value
from t_pessimistic
where id =
1for
update
如果沒有其他事務對查詢結果中的任一行使用排他鎖時可以成功獲得鎖，否則會阻塞直到獲得鎖
如果發生衝突的機率較低，每次都加鎖會產生額外開銷
適合發生衝突機率高的情況
**中實現的樂觀鎖好像不太穩定
給需要保證一致性的表增加版本號字段
每次執行update或delete時，驗證版本號，如果不一致就重試
如果發生衝突的機率較高，可能會重試多次，反而影響效率
適合發生衝突機率低的情況
要保證資料的一致性，同乙個表應該使用同一種鎖
事務的一致性
首先,我們需要搞清楚為什麼會出現事務.這句話的大體含義就是,事務的產生,其實是為了當應用程式訪問資料庫的時候,事務能夠簡化我們的程式設計模型,不需要我們去考慮各種各樣的潛在錯誤和併發問題.可以想一下當我們使用事務時,要麼提交,要麼回滾,我們不會去考慮網路異常了,伺服器宕機了,同時更改乙個資料怎麼辦對...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
EtherCAT一致性測試
為了建立一致性測試環境，需要具備以下條件 1 一台採用windows作業系統的標準pc 網絡卡 支援100mbit,全雙工 2 ctt et9400 一致性測試軟體 3 要測試的裝置 dut 4 裝置描述檔案 esi 5 資料報分析軟體 如wireshark 測試內容 1 ethercat協議 es...