多執行緒與高併發基礎一（超發--悲觀鎖，樂觀鎖）
關鍵詞：
執行緒，同步，單例，高併發，高訪問，死鎖
一、大規模併發帶來的挑戰
在過去的工作中，我曾經面對過5w每秒的高併發秒殺功能，在這個過程中，整個Web系統遇到了很多的問題和挑戰。如果Web系統不做針對性的優化，會輕而易舉地陷入到異常狀態。我們現在一起來討論下，優化的思路和方法哈。
1. 請求介面的合理設計
一個秒殺或者搶購頁面，通常分為2個部分，一個是靜態的HTML等內容，另一個就是參與秒殺的Web後臺請求介面。
通常靜態HTML等內容，是通過CDN的部署，一般壓力不大，核心瓶頸實際上在後臺請求介面上。這個後端介面，必須能夠支援高併發請求，同時，非常重要的一點，必須儘可能“快”
當然，也有一些秒殺和搶購採用“滯後反饋”，就是說秒殺當下不知道結果，一段時間後才可以從頁面中看到使用者是否秒殺成功。但是，這種屬於“偷懶”行為，同時給使用者的體驗也不好，容易被使用者認為是“暗箱操作”。
2. 高併發的挑戰：一定要“快”
我們通常衡量一個Web系統的吞吐率的指標是QPS（Query Per Second，每秒處理請求數），解決每秒數萬次的高併發場景，這個指標非常關鍵。舉個例子，我們假設處理一個業務請求平均響應時間為100ms，同時， 系統內有20臺Apache的Web伺服器，配置MaxClients為500個（表示Apache的最大連線數目）。
那麼，我們的Web系統的理論峰值QPS為（理想化的計算方式）：
20*500/0.1 = 100000 （10萬QPS）
咦？我們的系統似乎很強大，1秒鐘可以處理完10萬的請求，5w/s的秒殺似乎是“紙老虎”哈。實際情況，當然沒有這麼理想。在高併發的實際場景下，機器都處於高負載的狀態，在這個時候平均響應時間會被大大增加。
就Web伺服器而言，Apache打開了越多的連線程序，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然後就直接導致平均響應時間 增加。因此上述的MaxClient數目，要根據CPU、記憶體等硬體因素綜合考慮，絕對不是越多越好。可以通過Apache自帶的abench來測試一 下，取一個合適的值。然後，我們選擇記憶體操作級別的儲存的Redis，在高併發的狀態下，儲存的響應時間至關重要。網路頻寬雖然也是一個因素，不過，這種 請求資料包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統瓶頸的情況比較少，在這裡不做討論哈。
那麼問題來了，假設我們的系統，在5w/s的高併發狀態下，平均響應時間從100ms變為250ms（實際情況，甚至更多）：
20*500/0.25 = 40000 （4萬QPS）
於是，我們的系統剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。
然後，這才是真正的惡夢開始。舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘只能通過4部車，車流量仍然依舊，結果必定出現大塞車。（5條車道忽然變成4條車道的感覺）
同理，某一個秒內，20*500個可用連線程序都在滿負荷工作中，卻仍然有1萬個新來請求，沒有連線程序可用，系統陷入到異常狀態也是預期之內。
其實在正常的非高併發的業務場景中，也有類似的情況出現，某個業務請求接口出現問題，響應時間極慢，將整個Web請求響應時間拉得很長，逐漸將Web伺服器的可用連線數佔滿，其他正常的業務請求，無連線程序可用。
更可怕的問題是，是使用者的行為特點，系統越是不可用，使用者的點選越頻繁，惡性迴圈最終導致“雪崩”（其中一臺Web機器掛了，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛，然後惡性迴圈），將整個Web系統拖垮。
3. 重啟與過載保護
如果系統發生“雪崩”，貿然重啟服務，是無法解決問題的。最常見的現象是，啟動起來後，立刻掛掉。這個時候，最好在入口層將流量拒絕，然後再將重啟。如果是redis/memcache這種服務也掛了，重啟的時候需要注意“預熱”，並且很可能需要比較長的時間。
秒殺和搶購的場景，流量往往是超乎我們系統的準備和想象的。這個時候，過載保護是必要的。如果檢測到系統滿負載狀態，拒絕請求也是一種保護措施。在前端設定過濾是最簡單的方式，但是，這種做法是被使用者“千夫所指”的行為。更合適一點的是，將過載保護設定在CGI入口層，快速將客戶的直接請求返回。
二、作弊的手段：進攻與防守
秒殺和搶購收到了“海量”的請求，實際上裡面的水分是很大的。不少使用者，為了“搶“到商品，會使用“刷票工具”等型別的輔助工具，幫助他們傳送儘可 能多的請求到伺服器。還有一部分高階使用者，製作強大的自動請求指令碼。這種做法的理由也很簡單，就是在參與秒殺和搶購的請求中，自己的請求數目佔比越多，成功的概率越高。
這些都是屬於“作弊的手段”，不過，有“進攻”就有“防守”，這是一場沒有硝煙的戰鬥哈。
1. 同一個賬號，一次性發出多個請求
部分使用者通過瀏覽器的外掛或者其他工具，在秒殺開始的時間裡，以自己的賬號，一次傳送上百甚至更多的請求。實際上，這樣的使用者破壞了秒殺和搶購的公平性。
這種請求在某些沒有做資料安全處理的系統裡，也可能造成另外一種破壞，導致某些判斷條件被繞過。例如一個簡單的領取邏輯，先判斷使用者是否有參與記 錄，如果沒有則領取成功，最後寫入到參與記錄中。這是個非常簡單的邏輯，但是，在高併發的場景下，存在深深的漏洞。多個併發請求通過負載均衡伺服器，分配到內網的多臺Web伺服器，它們首先向儲存傳送查詢請求，然後，在某個請求成功寫入參與記錄的時間差內，其他的請求獲查詢到的結果都是“沒有參與記錄”。 這裡，就存在邏輯判斷被繞過的風險。
應對方案：
在程式入口處，一個賬號只允許接受1個請求，其他請求過濾。不僅解決了同一個賬號，傳送N個請求的問題，還保證了後續的邏輯流程的安全。實現方案， 可以通過Redis這種記憶體快取服務，寫入一個標誌位（只允許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加。
或者，自己實現一個服務，將同一個賬號的請求放入一個佇列中，處理完一個，再處理下一個。
2. 多個賬號，一次性發送多個請求
很多公司的賬號註冊功能，在發展早期幾乎是沒有限制的，很容易就可以註冊很多個賬號。因此，也導致了出現了一些特殊的工作室，通過編寫自動註冊腳 本，積累了一大批“殭屍賬號”，數量龐大，幾萬甚至幾十萬的賬號不等，專門做各種刷的行為（這就是微博中的“殭屍粉“的來源）。舉個例子，例如微博中有轉 發抽獎的活動，如果我們使用幾萬個“殭屍號”去混進去轉發，這樣就可以大大提升我們中獎的概率。
這種賬號，使用在秒殺和搶購裡，也是同一個道理。例如，iPhone官網的搶購，火車票黃牛黨。
應對方案：
這種場景，可以通過檢測指定機器IP請求頻率就可以解決，如果發現某個IP請求頻率很高，可以給它彈出一個驗證碼或者直接禁止它的請求：
- 彈出驗證碼，最核心的追求，就是分辨出真實使用者。因此，大家可能經常發現，網站彈出的驗證碼，有些是“鬼神亂舞”的樣子， 有時讓我們根本無法看清。他們這樣做的原因，其實也是為了讓驗證碼的圖片不被輕易識別，因為強大的“自動指令碼”可以通過圖片識別裡面的字元，然後讓指令碼自 動填寫驗證碼。實際上，有一些非常創新的驗證碼，效果會比較好，例如給你一個簡單問題讓你回答，或者讓你完成某些簡單操作（例如百度貼吧的驗證碼）。
- 直接禁止IP，實際上是有些粗暴的，因為有些真實使用者的網路場景恰好是同一出口IP的，可能會有“誤傷“。但是這一個做法簡單高效，根據實際場景使用可以獲得很好的效果。
3. 多個賬號，不同IP傳送不同請求
所謂道高一尺，魔高一丈。有進攻，就會有防守，永不休止。這些“工作室”，發現你對單機IP請求頻率有控制之後，他們也針對這種場景，想出了他們的“新進攻方案”，就是不斷改變IP。
有同學會好奇，這些隨機IP服務怎麼來的。有一些是某些機構自己佔據一批獨立IP，然後做成一個隨機代理IP的服務，有償提供給這些“工作 室”使用。還有一些更為黑暗一點的，就是通過木馬黑掉普通使用者的電腦，這個木馬也不破壞使用者電腦的正常運作，只做一件事情，就是轉發IP包，普通使用者的電 腦被變成了IP代理出口。通過這種做法，黑客就拿到了大量的獨立IP，然後搭建為隨機IP服務，就是為了掙錢。
應對方案：
說實話，這種場景下的請求，和真實使用者的行為，已經基本相同了，想做分辨很困難。再做進一步的限制很容易“誤傷“真實使用者，這個時候，通常只能通過設定業務門檻高來限制這種請求了，或者通過賬號行為的”資料探勘“來提前清理掉它們。
殭屍賬號也還是有一些共同特徵的，例如賬號很可能屬於同一個號碼段甚至是連號的，活躍度不高，等級低，資料不全等等。根據這些特點，適當設定參與門檻，例如限制參與秒殺的賬號等級。通過這些業務手段，也是可以過濾掉一些殭屍號。
4. 火車票的搶購
看到這裡，同學們是否明白你為什麼搶不到火車票？如果你只是老老實實地去搶票，真的很難。通過多賬號的方式，火車票的黃牛將很多車票的名額佔據，部分強大的黃牛，在處理驗證碼方面，更是“技高一籌“。
高階的黃牛刷票時，在識別驗證碼的時候使用真實的人，中間搭建一個展示驗證碼圖片的中轉軟體服務，真人瀏覽圖片並填寫下真實驗證碼，返回給中轉軟體。對於這種方式，驗證碼的保護限制作用被廢除了，目前也沒有很好的解決方案。
因為火車票是根據身份證實名制的，這裡還有一個火車票的轉讓操作方式。大致的操作方式，是先用買家的身份證開啟一個搶票工具，持續傳送請 求，黃牛賬號選擇退票，然後黃牛買家成功通過自己的身份證購票成功。當一列車廂沒有票了的時候，是沒有很多人盯著看的，況且黃牛們的搶票工具也很強大，即 使讓我們看見有退票，我們也不一定能搶得過他們哈。
最終，黃牛順利將火車票轉移到買家的身份證下。
解決方案：
並沒有很好的解決方案，唯一可以動心思的也許是對賬號資料進行“資料探勘”，這些黃牛賬號也是有一些共同特徵的，例如經常搶票和退票，節假日異常活躍等等。將它們分析出來，再做進一步處理和甄別。
三、高併發下的資料安全
我們知道在多執行緒寫入同一個檔案的時候，會存現“執行緒安全”的問題（多個執行緒同時運行同一段程式碼，如果每次執行結果和單執行緒執行的結果是一 樣的，結果和預期相同，就是執行緒安全的）。如果是MySQL資料庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模併發的場景中，是不推薦使用 MySQL的。秒殺和搶購的場景中，還有另外一個問題，就是“超發”，如果在這方面控制不慎，會產生髮送過多的情況。我們也曾經聽說過，某些電商搞搶購活動，買家成功拍下後，商家卻不承認訂單有效，拒絕發貨。這裡的問題，也許並不一定是商家奸詐，而是系統技術層面存在超發風險導致的。
1. 超發的原因
假設某個搶購場景中，我們一共只有100個商品，在最後一刻，我們已經消耗了99個商品，僅剩最後一個。這個時候，系統發來多個併發請求，這批請求讀取到的商品餘量都是99個，然後都通過了這一個餘量判斷，最終導致超發。（同文章前面說的場景）
在上面的這個圖中，就導致了併發使用者B也“搶購成功”，多讓一個人獲得了商品。這種場景，在高併發的情況下非常容易出現。
2. 悲觀鎖思路
解決執行緒安全的思路很多，可以從“悲觀鎖”的方向開始討論。
悲觀鎖，也就是在修改資料的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。
雖然上述的方案的確解決了執行緒安全的問題，但是，別忘記，我們的場景是“高併發”。也就是說，會很多這樣的修改請求，每個請求都需要等待 “鎖”，某些執行緒可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連線數被耗 盡，系統陷入異常。
3. FIFO佇列思路
那好，那麼我們稍微修改一下上面的場景，我們直接將請求放入佇列中的，採用FIFO（First Input First Output，先進先出），這樣的話，我們就不會導致某些請求永遠獲取不到鎖。看到這裡，是不是有點強行將多執行緒變成單執行緒的感覺哈。
然後，我們現在解決了鎖的問題，全部請求採用“先進先出”的佇列方式來處理。那麼新的問題來了，高併發的場景下，因為請求很多，很可能一瞬 間將佇列記憶體“撐爆”，然後系統又陷入到了異常狀態。或者設計一個極大的記憶體佇列，也是一種方案，但是，系統處理完一個佇列內請求的速度根本無法和瘋狂湧 入佇列中的數目相比。也就是說，佇列內的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。
4. 樂觀鎖思路
這個時候，我們就可以討論一下“樂觀鎖”的思路了。樂觀鎖，是相對於“悲觀鎖”採用更為寬鬆的加鎖機制，大都是採用帶版本號 （Version）更新。實現就是，這個資料所有請求都有資格去修改，但會獲得一個該資料的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。 這樣的話，我們就不需要考慮佇列的問題，不過，它會增大CPU的計算開銷。但是，綜合來說，這是一個比較好的解決方案。
有很多軟體和服務都“樂觀鎖”功能的支援，例如Redis中的watch就是其中之一。通過這個實現，我們保證了資料的安全。
四、小結
網際網路正在高速發展，使用網際網路服務的使用者越多，高併發的場景也變得越來越多。電商秒殺和搶購，是兩個比較典型的網際網路高併發場景。雖然我們解決問題的具體技術方案可能千差萬別，但是遇到的挑戰卻是相似的，因此解決問題的思路也異曲同工。
五、關於併發
通過上面的搶購和秒殺的例子來探討併發的出現場景及處理高併發的相應技術。
關於多執行緒和併發的知識：
1、 什麼是併發？
在網際網路時代，所講的併發、高併發，通常是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。（PV（page view）即頁面瀏覽量。）
一臺伺服器在單位時間裡能處理的請求越多，伺服器的能力越高，也就是伺服器併發處理能力越強。伺服器的本質工作就是，爭取以最快的速度將核心緩衝區中的使用者請求資料一個不剩地都拿出來，然後儘快處理，再將響應資料放到一塊又能夠與傳送資料的緩衝區中，接著處理下一撥請求。
2、 衡量伺服器併發處理能力？
高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），併發使用者數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。
吞吐量：單位時間內處理的請求數量。
QPS：每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。
併發使用者數：同時承載正常使用系統功能的使用者數量。例如一個即時通訊系統，同時線上量一定程度上代表了系統的併發使用者數。
3、 如何提高伺服器的併發處理能力？
有兩種方式：第一種就是提高單機的效能；
第二種就是網際網路的分散式開發架構，增加機器的數量。
其實還可以通過減少無用請求來降低伺服器的壓力。例如微博的殭屍粉，購票的黃牛。
【1】提高CPU併發計算能力
（1）多程序&多執行緒
（2）減少程序切換，使用執行緒，考慮程序繫結CPU
（3）減少使用不必要的鎖，考慮無鎖程式設計
（4）考慮程序優先順序
（5）關注系統負載
（6）關注CPU使用率，除了使用者空間和核心空間的CPU使用率以外，還要關注I/O wait
【2】減少系統呼叫
【3】考慮減少記憶體分配和釋放
（1）改善資料結構和演算法複製度
（2）使用記憶體池
（3）考慮使用共享記憶體
【4】考慮使用持久連線
【5】改進I/O模型
(1)DMA技術
(2)非同步I/O
(3)改進多路I/O就緒通知策略，epoll
(4)Sendfile
(5)記憶體對映
(6)直接I/O
【6】改進伺服器併發策略
（1）一個程序處理一個連線，非阻塞I/O，使用長連線
（2）一個程序處理多個連線，非同步I/O,使用長連線
【7】改進硬體環境
4、 總結
高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
提高系統併發能力的方式，方法論上主要有兩種：垂直擴充套件（Scale Up）與水平擴充套件（Scale Out）。前者垂直擴充套件可以通過提升單機硬體效能，或者提升單機架構效能，來提高併發性，但單機效能總是有極限的，網際網路分散式架構設計高併發終極解決方案還是後者：水平擴充套件。
網際網路分層架構中，各層次水平擴充套件的實踐又有所不同：
（1）反向代理層可以通過“DNS輪詢”的方式來進行水平擴充套件；
（2）站點層可以通過nginx來進行水平擴充套件；
（3）服務層可以通過服務連線池來進行水平擴充套件；
（4）資料庫可以按照資料範圍，或者資料雜湊的方式來進行水平擴充套件；
各層實施水平擴充套件後，能夠通過增加伺服器數量的方式來提升系統的效能，做到理論上的效能無限。
5、 多執行緒和併發有什麼關係？
【1】多執行緒
（1）java本身就是多執行緒的；
（2）java的多執行緒是一種程式設計思想，一個程式執行之後就成為一個程序，所謂的多執行緒就是在一個程序中有多個執行緒存在，在巨集觀上是多個執行緒同時執行，可以使程序同時完成多件事，微觀上是cpu在多個執行緒之間切換，在某一時刻還是執行一個執行緒。
【2】併發
（3）併發一般指 "併發訪問", 如若干應用程式從不同的客戶端同時訪問同一個伺服器端的資料庫,伺服器應用一定的承受能力處理併發的請求，併發請求被程序或是程序裡面的執行緒處理，併發訪問用併發程式設計處理其實最好的解決辦法就是多執行緒。
（4）併發程式設計是多執行緒程式設計的一種應用。
（5）無論你是做web開發，還是資料庫開發，還是桌面開發，都會用到多執行緒的。
（6）因為有併發的這個實際的需求，所以出現了多執行緒。
【3】
（1）高併發不是JAVA的專有的東西，是語言無關的廣義的，為提供更好網際網路服務而提出的概念。舉個極端的例子，就是100個人，1人分配1臺web伺服器，那麼伺服器資源是他們獨佔的，他們不需要搶佔伺服器資源，100個請求被100臺伺服器並行處理，速度必定很快，這就是高併發。當然這是不可能的，但是，我們總是努力去做，讓少量的伺服器也能達到近似的能力。這就需要伺服器的HTML畫面，後臺業務邏輯，db資料存取等等細節上的處理都達到一個並行的極致，以此來實現整個伺服器對所有請求的高並行。這是戰略上的並行。多執行緒只是為了達到高併發目的，在某個細節點上，為實現某併發功能而採用的一種具體的實現方法，這種功能也可以由多程序實現，當然，也可以由多程序，多執行緒一起實現。這是戰術上的並行。那麼可以說，高併發是目的，多執行緒是某種手段（不是唯一的），高併發可以由多執行緒實現，但是多執行緒不代表就是高併發。
（2）併發與多執行緒之間的關係就是目的與手段之間的關係。併發（Concurrent）的反面是序列。序列好比多個車輛行駛在一股車道上，它們只能“魚貫而行”。而併發好比多個車輛行駛在多股車道上，它們可以“並駕齊驅”。併發的極致就是並行（Parallel）。多執行緒就是將原本可能是序列的計算“改為”併發（並行）的一種手段、途徑或者模型。因此，有時我們也稱多執行緒程式設計為併發程式設計。當然，目的與手段之間常常是一對多的關係。併發程式設計還有其他的實現途徑，例如函式式（Functional programming）程式設計。多執行緒程式設計往往是其他併發程式設計模型的基礎，所以多執行緒程式設計的重要性不言而喻。
綜合上面幾點可以看出：併發，就是伺服器同時處理多個請求的能力，而處理併發的最好的辦法，就是採用多執行緒。cpu快速呼叫不同的就緒佇列，看起來好像是同步進行，實際還是一個執行緒一個執行緒的處理的，但這樣，就大大提高了伺服器的效率，減少了執行緒的等待時間。
即可以這麼理解：多執行緒是處理高併發的一種程式設計方法。即併發需要用多執行緒實現。
當有海量的請求時，伺服器沒有連線的程序可用，系統就會產生異常。
6、 在具體專案中，什麼情況下用到了多執行緒？
【1】如果做 java web方面開發的話幾乎用不到多執行緒！因為有多執行緒的地方 servlet 容器或者其他開發框架都已經實現掉了！一般在網路應用程式中使用多執行緒的地方非常多！另外，拷貝檔案使用多執行緒，是沒有用的！以多執行緒來提高效率的場景一般在 CPU 計算型，而不是在 IO 讀寫型。CPU 可以會有多個核心並行處理計算，但是磁碟 IO 就沒這功能了，磁頭只有一個，根本不可能靠多執行緒提高效率！一般來說，磁碟 IO 的併發能力為 0，也就是說無法支援併發！網路 IO 的話由於頻寬的限制的，使用多執行緒處理最多也只能達到頻寬的極值。對於磁碟 IO 來說，多執行緒可以用於一個執行緒專門用於讀寫檔案，其他的執行緒用於對讀取資料進行處理，這樣才有可能更好地利用 CPU 資源。如果僅僅是單純的檔案複製，使用多執行緒操作的話，會使用磁頭在磁碟上不停地進行尋道操作，使得效率更為低下！
【2】壓力測試時，會用到多執行緒。
【3】伺服器程式設計時，會用到多執行緒。
【4】使用監聽器時，可能會用到多執行緒。
【5】跑ＪＯＢ時，可能會用到多執行緒。
【6】還有一種極為普遍的使用多執行緒的場景是UI程式設計,一般UI介面繪製於主執行緒,為了不阻塞主執行緒讓使用者體驗更流暢,需要建立單獨的執行緒處理耗時操作,處理完了再更新主介面,典型的案例就是android應用開發。
【7】一些C/S模式比如說網路遊戲（基於socket協議）一般在伺服器那邊處理的時候一個客戶端，一個執行緒；還有就是一些銀行軟體，用到了執行緒同步等等。
7、 高併發事件的出現的場景
（1） 伺服器在每秒內處理請求數是一定，當訪問量太大時，沒有多餘的程序來處理這些請求，就會造成系統的癱瘓。系統崩潰，例如前段時間微博的癱瘓，就是短時間內流量太大了，導致系統處於異常狀態，頁面無法顯示，使用者無法登陸等；電商中搶購，秒殺中出現超發的情況，多個使用者同時購買同一物品，訪問修改同一資料等情況。
（2） 由於購票、查詢和瀏覽的數量激增，12306網站每天訪問量比平時增長數十倍，經常出現登入難的現象，近日甚至出現了付款不出票、系統乾脆癱瘓的情況。網路訂票原本是一項便民利民的措施，卻由於鐵道部未正確預估網站併發情況、技術支援不足而導致相反的結果。IT業界人士紛紛指出，12306網站癱瘓最大的原因是“技術之罪”。並針對高併發網站引發的技術考驗，紛紛獻技獻策、展開討論，提出了很多具指導意義的技術解決方案。
（3） 此次12306網站難登入並癱瘓是系統架構規劃的問題，導致不能有效支援大併發量集中訪問。同時，12306在IT管理上也有問題，未能進行有效的壓力測試和執行模擬。
8、 高併發下出現的超發問題的解決方案
專案中：
【1】在點選購物車的提交訂單按鈕時，會判斷庫存是否足夠，不足，會拒絕提交訂單。
【2】當庫存只有一件時，兩個客戶，或多個客戶經過在購物車提交訂單判斷，在訂單頁面進行支付時判斷，同時都滿足了購買一件產品的需求，那麼，讓誰購買成功？豈不是多個使用者同時都支付了這同一件商品？這種情況就是超發，下面將解決高併發下的這種超發的問題。
【3】假設 個，B客戶購買6個：
（1）在點選提交訂單時，兩這同時判斷庫存滿足，進入到訂單介面；（2）然後 A先支付完成，在支付時，減少庫存（此時做判斷，如果庫存足夠，支付成功，否則支付失敗）---》PS：跟12306購票系統相似。（3）然後B慢一步也進入到支付，判斷，此時庫存只有5個，不讓支付，支付失敗。（4）如果兩者同時進行支付呢？怎麼改變庫存，讓誰購買成功？這就涉及到了加鎖，同步的問題。下面就討論這個問題 的解決方案。、
【4】涉及到的知識點技術
(1) 悲觀鎖：解決執行緒安全的思路很多，可以從“悲觀鎖”的方向開始討論。悲觀鎖，也就是在修改資料的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。雖然上述的方案的確解決了執行緒安全的問題，但是，別忘記，我們的場景是“高併發”。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些執行緒可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連線數被耗盡,系統陷入異常。
自己理解：悲觀鎖就是給要修改的資料加上鎖，同步。其他請求需要等待。把資料鎖住。
怎麼實現？具體怎麼在程式碼中寫。需要了解的。
一般意義上的加鎖指兩個層面：程式碼層次，如java中的同步鎖，典型的就是同步關鍵字synchronized ；資料庫層次，如悲觀鎖（物理鎖）和樂觀鎖。
悲觀鎖：通過資料庫的forupdate欄位實現加鎖。
for update要放到mysql的事務中，即begin和commit中，否者則不起作用。
（2）FIFO佇列思路
那好，那麼我們稍微修改一下上面的場景，我們直接將請求放入佇列中的，採用FIFO（First Input FirstOutput，先進先出），這樣的話，我們就不會導致某些請求永遠獲取不到鎖。看到這裡，是不是有點強行將多執行緒變成單執行緒的感覺哈。
然後，我們現在解決了鎖的問題，全部請求採用“先進先出”的佇列方式來處理。那麼新的問題來了，高併發的場景下，因為請求很多，很可能一瞬間將佇列記憶體“撐爆”，然後系統又陷入到了異常狀態。或者設計一個極大的記憶體佇列，也是一種方案，但是，系統處理完一個佇列內請求的速度根本無法和瘋狂湧 入佇列中的數目相比。也就是說，佇列內的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。（3）樂觀鎖思路
這個時候，我們就可以討論一下“樂觀鎖”的思路了。樂觀鎖，是相對於“悲觀鎖”採用更為寬鬆的加鎖機制，大都是採用帶版本號（Version）更新。實現就是，這個資料所有請求都有資格去修改，但會獲得一個該資料的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。這樣的話，我們就不需要考慮佇列的問題，不過，它會增大CPU的計算開銷。但是，綜合來說，這是一個比較好的解決方案。有很多軟體和服務都“樂觀鎖”功能的支援，例如Redis中的watch就是其中之一。通過這個實現，我們保證了資料的安全。
自己理解：修改版本號，version。
假設資料庫中帳戶資訊表中有一個 version欄位，當前值為 1 ；而當前帳戶餘額欄位（ balance ）為 $100 。 操作員 A 此時將其讀出（ version=1 ），並從其帳戶餘額中扣除 $50（ $100-$50 ）。 2 在操作員 A 操作的過程中，操作員 B 也讀入此使用者資訊（ version=1 ），並 從其帳戶餘額中扣除 $20 （ $100-$20 ）。 3 操作員 A完成了修改工作，將資料版本號加一（ version=2 ），連同帳戶扣 除後餘額（ balance=$50 ），提交至資料庫更新，此時由於提交資料版本大 於資料庫記錄當前版本，資料被更新，資料庫記錄 version 更新為 2 。 4 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交資料（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 B提交的 資料版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足“ 提交版本必須大於記 錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基於
version=1 的舊資料修改的結果覆蓋操作員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員 A和操作員 B 操作過程中，都沒有對資料庫資料加鎖），大大提升了大併發量下的系統整體效能表現。
（4）Mysql的資料庫的鎖機制
鎖
（5）關於事務和髒資料
髒資料，不可重複讀，幻讀
解決：
9、 我對多執行緒及高併發的瞭解
我對執行緒和併發的瞭解可能比較淺顯，理論化，基礎化，因為我接觸的專案中，並沒有深入的處理過併發和多執行緒的處理，我對於併發的處理只是在分散式開發和負載均衡中提高專案的併發處理能力。多執行緒的瞭解就是對同步（就是加鎖）和servlet的單例多執行緒有一定的瞭解。
談到高併發，就是伺服器端同時處理海量請求的能力。當出現高併發時，可能會出現超發的情況：（詳細介紹，結合自己專案中遇到的超發問題）
當請求超過伺服器的承受限制，還可能會使伺服器崩潰。此時，我們可以通過分散式開發的架構，將業務細化為多個子業務，這樣既可以增加了後臺伺服器對高訪問的業務的請求處理能力，同時還便於後期的升級維護，各個子業務之間的維護升級更加簡單，通過遠端呼叫來實現各個子業務之間的聯絡。此外，還可以通過叢集，來提高伺服器的併發能力。這種提高伺服器的併發能力的方式也成為水平提高伺服器的併發能力，這也是未來發展的趨勢。
此外，就是通過單機，通過提高cpu等單個物理機器的效能，來提高伺服器的併發能力。
PS：web伺服器都是已經實現了多執行緒的。
所以我要了解的就是怎麼處理超發的問題，在處理超發的前提下，我要對什麼是高併發，高併發和多執行緒有什麼關係搞清楚。
關於實際中編碼中我所接觸到的對於多執行緒，和併發訪問有四點：
【1】在講多執行緒時，關於火車票的簡單程式碼和同步程式碼塊，瞭解了多執行緒的底層程式碼。
【2】在講servlet時的單例多執行緒。
雙重檢驗，為什麼要用多執行緒？就是為了提高cpu的利用率，（提高併發能力）如果同步方法，跟單執行緒的區別並不大，所以，同步共同的資源物件，縮小鎖定的範圍，故用雙重檢驗。
【3】在講解電商專案時，分散式開發和Nginx的負載均衡的叢集建立。
【4】Web伺服器都是實現了多執行緒的，現階段不需要編寫多執行緒。