資料：
（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.原子性（Atomicity）（要么不執行，要么全部執行）
2.一致性（Consistency）（假設有多個數據庫服務器，當修改了某一個數據庫中的某一記錄之后，【其他的數據庫也要進行同步修改】）
3.隔離性（Isolation）（假設有事務1和事務2，則事務1絕不可以影響到事務2，事務2也絕不可以影響到事務1，即【事務1和事務2是相互獨立的事件】）
4.持久性（Durability）（將【某應用服務器】的事務通過事務管理器記錄到日志文件中，則當該應用服務器重啟時，可以讀取這些日志文件）
二、悲觀鎖和樂觀鎖的區別：
三、MySQL事務隔離級別：
1.讀未提交：一個事務可以讀取到另一個事務未提交的修改。這會帶來臟讀、幻讀、不可重復讀問題。（基本沒用）
2.讀已提交（Committed-Read）：一個事務只能讀取另一個事務已經提交的修改。其避免了臟讀，但仍然存在不可重復讀和幻讀問題。
3.可重復讀（Repeatable-Read）（樂觀鎖）：同一個事務中多次讀取相同的數據返回的結果是一樣的。其避免了臟讀和不可重復讀問題。
4.串行化（Serializable_Read）（悲觀鎖）：事務串行執行。避免了以上所有問題，包括幻讀。
MySQL默認的隔離級別是【可重復讀】。
四、避免庫存超賣
（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）在秒殺的情況下，肯定不能如方法一那樣高頻率的去讀寫數據庫，會嚴重造成性能問題的，
必須使用緩存，將需要秒殺的商品放入緩存中，再為每個緩存商品建立請求隊列，以最快的速度緩存請求並響應客戶端，最后再悠閑地處理隊列中的請求。
五、各個消息隊列的比較
1.利用redis實現的消息隊列：一個輕量級的消息隊列（數據量越大，效率越低，一般用於數據量較小的即時秒殺系統）
2.rabbitmq：一個重量級的、可靠的消息隊列（數據量越大，效率越低，一般用於緩存可延遲的操作，比如銀行轉賬）
3.kafka/Jafka：一個追求高吞吐量的、較不可靠的消息隊列（一般用於緩存大數據中采集的數據）