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

1、老師說(shuō)得這個(gè)行鎖很怪異，mysql根本就沒(méi)有這個(gè)東西，沒(méi)有加for update你會(huì)有行鎖嗎？不知道老師所謂的行鎖是從天而降嗎？？這個(gè)稱為悲觀鎖。但是代價(jià)太大，我們基本不用。因?yàn)槭褂盟?，你所有的線程就等著掛起和等待了，系統(tǒng)就基本就死在哪里了。

2、一般我們即時(shí)使用數(shù)據(jù)庫(kù)，也不會(huì)這樣用，應(yīng)該加一個(gè)version字段。

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

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

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

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

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

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

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

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

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

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

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