作為java的多年經(jīng)驗的碼農覺得老師的東西很怪異，CAS原理都不講的，你用mysql的鎖去應對秒殺基本就死在哪里了。

1、老師說得這個行鎖很怪異，mysql根本就沒有這個東西，沒有加for update你會有行鎖嗎？不知道老師所謂的行鎖是從天而降嗎？？這個稱為悲觀鎖。但是代價太大，我們基本不用。因為使用它，你所有的線程就等著掛起和等待了，系統(tǒng)就基本就死在哪里了。

2、一般我們即時使用數(shù)據(jù)庫，也不會這樣用，應該加一個version字段。

（1）首先是程序讀取select? version, left from table;

（2）然后記錄version字段（舊值），判定left - buyCount(購買數(shù)量)>=0，如果否退出，結束業(yè)務。否則繼續(xù)（3）

（3）開始執(zhí)行減庫存

update table set left = left - #{byCount} , version =? version+1

where count >0 and vesion = #{vesion}//這個version是舊值，而更新一次成功version就加1

這里數(shù)據(jù)庫并沒有任何鎖，但是這里巧妙的使用了version字段，符合一個CAS原理，就是我當初讀出的version（舊值）和實時數(shù)據(jù)庫的version（當前需要更新時刻的實時值）是否一致，如果一致，則我會認為這條記錄沒有被其他線程修改，則減庫存成功，如果不一致則我會認為其他線程修改過這個記錄。就不會進行操作這個被稱為樂觀鎖。這個時候我們會考慮重入，重復執(zhí)行（1）-（3）步驟直至（2）的退出或者（3）成功繼續(xù)我們的操作，這樣就是一個沒有鎖的機制。這就是一個樂觀鎖的機制，而沒有任何等待的機制，是一個非阻塞的過程。

3、企業(yè)的秒殺目前應該考慮使用redis，而不是mysql。

別和我說你mysql的性能和redis比，個人自測分別批量插入數(shù)據(jù)：

redis每秒在我的機子可以執(zhí)行40萬次的插入，而mysql只能執(zhí)行不到2萬次。這個性能差了幾十倍。你用mysql是自己找麻煩。這個級別根本不同級，其次redis提供的事務很好的符合了秒殺的功能。

首先任何線程執(zhí)行redis的操作的時候都是使用lua語言，redis在執(zhí)行l(wèi)ua語言的時候是原子性的，讓它執(zhí)行減庫存，并且記錄用戶購買記錄。

直至秒殺時間到期或者庫存為0，才考慮將redis緩存的數(shù)據(jù)批量一次性把減庫存和用戶購買的信息批量寫入mysql。整個秒殺過程基本在redis完成，而不是數(shù)據(jù)庫，不是你mysql的性能可比的，你服務器上mysql一秒可以4萬次，redis可以上百萬次，你怎么比？？