- 事務(wù)隔離(針對可重復(fù)讀和串行化級別)
mysql使用的是二階鎖方案赋朦。得到鎖之前會一直等待辉川，這種方式的缺點(diǎn)是性能不好诅愚，優(yōu)點(diǎn)是不需要失敗后重試寒锚。屬于悲觀鎖方案。
postgresql使用的是SSI——Serialized Snopshot Isolation呻粹，任何操作不需要等待壕曼，但是提交數(shù)據(jù)時若檢測到數(shù)據(jù)有沖突會拋出異常并回滾。優(yōu)點(diǎn)是不會出現(xiàn)死鎖等浊，缺點(diǎn)是當(dāng)失敗時需要不斷重試，當(dāng)失敗的次數(shù)比較多時頻繁重試會大量消耗性能摹蘑。屬于樂觀鎖方案筹燕。
引用
http://www.reibang.com/p/cb97f76a92fd
文中的一段話
在MySQL中，很多開發(fā)者傾向于自己在默認(rèn)隔離級別之外手工加鎖衅鹿。而PostgreSQL則建議盡量避免直接加鎖撒踪，因?yàn)槠銻epeatable Read和Serializable的實(shí)現(xiàn)已經(jīng)相當(dāng)完善，開發(fā)者沒必要自找麻煩大渤。
- 顯式指定數(shù)據(jù)庫行鎖
人工給記錄加鎖制妄，當(dāng)然人工處理鎖問題自然是比較麻煩還容易出錯
mysql可用這種方式
- php處理
對于yii2框架來說ActiveRecord中已經(jīng)集成了樂觀鎖的功能，悲觀鎖需自己或參考第三方實(shí)現(xiàn)
具體參考這篇文章
http://www.digpage.com/lock.html
如果用mysql數(shù)據(jù)庫可以考慮這種方式泵三，只是性能會比數(shù)據(jù)庫行鎖低一些耕捞。
- 業(yè)務(wù)級控制
redis鎖衔掸，postgresql的advisory lock
這種主式比較靈活，需要自己控制俺抽，用的好可以實(shí)現(xiàn)性能最優(yōu)敞映，用不好也會性能比較差。單純從鎖性能來說應(yīng)該是以上三種方案的磷斧。
關(guān)于秒殺的問題
秒殺的場景通常是有限的商品海量的人員去爭搶振愿，能搶到手的通常只有前幾名人員。
- 如果是悲觀鎖方案弛饭，所有人(不管搶到?jīng)]搶到)都會等待獲取鎖冕末，直到超時結(jié)束。這會讓沒有搶到人的做不必要的等待侣颂。這個用無等待鎖即可档桃，直接返回請重試或搶購結(jié)束。
- 如果是樂觀鎖方案横蜒，所有人(不管搶到?jīng)]搶到)都會去提交事務(wù)胳蛮，這會浪費(fèi)不必要的系統(tǒng)資源，使系統(tǒng)卡住丛晌。即使不重試也需要事務(wù)回滾仅炊，沒有想到很好的避免方法。
