optimisticlockexception 樂觀鎖的問題

今天在做數據抓取的時候遇到樂觀鎖的問題，所以仔細研究了下，主要是通過查找資料。首先明白樂觀鎖和悲觀鎖的區別。

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

兩種鎖各有優缺點，不可認爲一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適

由於使用play框架所以默認使用樂觀鎖，故在數據庫表中增加version字段，但是由於數據抓取過程查詢更改的頻率較高，在1s內有多次操作，如果version字段的最小單位是秒的話導致樂觀鎖，由於mysql5.6之後的timestamp和datetime支持6位的小數，可以避免。