處理高併發，防止庫存超賣

資料：

（1）分佈式系統事務一致性解決方案：

http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

（2）MySQL事務隔離級別的實現原理：

https://www.cnblogs.com/cjsblog/p/8365921.html

（3）當前讀和快照讀：

https://www.cnblogs.com/cat-and-water/p/6427612.html

（4）mysql處理高併發，防止庫存超賣：

https://blog.csdn.net/caomiao2006/article/details/38568825?utm_source=blogxgwz2

（5）Redis和Memcache對比及選擇：

https://blog.csdn.net/sunmenggmail/article/details/36176029

（6）高併發下防止商品超賣的Redis實現（經過 jMeter 模擬併發）：

https://blog.csdn.net/Allen_jinjie/article/details/79292163?utm_source=blogxgwz0

（7）Redis和請求隊列解決高併發：

 https://blog.csdn.net/ZHJUNJUN93/article/details/78560700?utm_source=blogxgwz17

（7）redis集羣和kafka集羣做爲消息隊列比較（優先考慮kafka）：

https://www.2cto.com/kf/201701/587505.html

（8）面試中關於Redis的問題看這篇就夠了（業務上避免過分複用一個 redis，它只是一個單線程。既用它作緩存、作計算，還拿它作任務隊列，這樣很差。）：

https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA%3D%3D&idx=1&mid=2247483867&sn=39a06fa3d6d8f09eefaaf3d2b15b40e4

（9）Kafka，Mq和Redis做爲消息隊列使用時的差別有哪些？

https://www.wukong.com/answer/6527968849956962568/

（10）Redis與RabbitMQ做爲消息隊列的比較：

https://blog.csdn.net/gb4215287/article/details/79457445

（11）如何設計一個秒殺系統：

https://www.cnblogs.com/wangzhongqiu/p/6557596.html

（12）基於 SpringBoot+Mybatis+Redis+RabbitMQ 秒殺系統：

https://blog.csdn.net/qq_33524158/article/details/81675011

 

1、事務的四大特性：

1.原子性（Atomicity）（要麼不執行，要麼所有執行）

2.一致性（Consistency）（假設有多個數據庫服務器，當修改了某一個數據庫中的某一記錄以後，【其餘的數據庫也要進行同步修改】）

3.隔離性（Isolation）（假設有事務1和事務2，則事務1毫不能夠影響到事務2，事務2也毫不能夠影響到事務1，即【事務1和事務2是相互獨立的事件】）

4.持久性（Durability）（將【某應用服務器】的事務經過事務管理器記錄到日誌文件中，則當該應用服務器重啓時，能夠讀取這些日誌文件）

 

 

2、悲觀鎖和樂觀鎖的區別：

1.悲觀鎖，前提是，必定會有併發搶佔資源，強行獨佔資源，在整個數據處理過程當中，將數據處於鎖定狀態。

2.樂觀鎖，前提是，不會發生併發搶佔資源，只有在提交操做的時候檢查是否違反數據完整性。只能防止髒讀後數據的提交，不能解決髒讀。

 

3、MySQL事務隔離級別：

1.讀未提交：一個事務能夠讀取到另外一個事務未提交的修改。這會帶來髒讀、幻讀、不可重複讀問題。（基本沒用）

2.讀已提交（Committed-Read）：一個事務只能讀取另外一個事務已經提交的修改。其避免了髒讀，但仍然存在不可重複讀和幻讀問題。

3.可重複讀（Repeatable-Read）（樂觀鎖）：同一個事務中屢次讀取相同的數據返回的結果是同樣的。其避免了髒讀和不可重複讀問題。

4.串行化（Serializable_Read）（悲觀鎖）：事務串行執行。避免了以上全部問題，包括幻讀。

 MySQL默認的隔離級別是【可重複讀】。

 

4、避免庫存超賣

（1）非秒殺的正常的、避免庫存超賣的方法（利用關係型數據庫的Repeatable-Read事務隔離級別）

beginTranse(開啓事務)

try{

    //quantity爲請求減掉的庫存數量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');

}catch($e Exception){

    rollBack(回滾)

}

commit(提交事務)

（2）在秒殺的狀況下，確定不能如方法一那樣高頻率的去讀寫數據庫，會嚴重形成性能問題的，
必須使用緩存，將須要秒殺的商品放入緩存中，再爲每一個緩存商品創建請求隊列，以最快的速度緩存請求並響應客戶端，最後再清閒地處理隊列中的請求。

 

5、各個消息隊列的比較

1.利用redis實現的消息隊列：一個輕量級的消息隊列（數據量越大，效率越低，通常用於數據量較小的即時秒殺系統）

2.rabbitmq：一個重量級的、可靠的消息隊列（數據量越大，效率越低，通常用於緩存可延遲的操做，好比銀行轉帳）

3.kafka/Jafka：一個追求高吞吐量的、較不可靠的消息隊列（通常用於緩存大數據中採集的數據）