服務器高并發（三）
- 作者：新網
- 來源：新網
- 瀏覽：100
- 2018-05-10 17:51:26
多線程寫入同一個文件的時候，會存現“線程安全”的問題（多個線程同時運行同一段代碼，如果每次運行結果和單線程運行的結果是一樣的，結果和預期相同，就是線程安全的）。如果是MySQL數據庫，可以使用它自帶的鎖機制很好的解決問題，但是在大規模并發的場景中，是不推薦使用MySQL的。秒殺和搶購的場景中，還有另外一個問題，就是“超發”，如果在這方面控制不慎，會產生發送過多的情況，比如某些電商搞搶購活動，買家成功拍下后，商家卻不承認訂單有效，拒絕發貨。問題也許并不一定是商家奸詐，而是系統技術層面存在超發風險導致的。
3、高并發下的數據安全
多線程寫入同一個文件的時候，會存現“線程安全”的問題(多個線程同時運行同一段代碼，如果每次運行結果和單線程運行的結果是一樣的，結果和預期相同，就是線程安全的)。如果是MySQL數據庫，可以使用它自帶的鎖機制很好的解決問題，但是在大規模并發的場景中，是不推薦使用MySQL的。秒殺和搶購的場景中，還有另外一個問題，就是“超發”，如果在這方面控制不慎，會產生發送過多的情況，比如某些
電商搞搶購活動，買家成功拍下后，商家卻不承認訂單有效，拒絕發貨。問題也許并不一定是商家奸詐，而是系統技術層面存在超發風險導致的。
3.1、超發的原因
假設某個搶購場景中，一共只有100個商品，在最后一刻，我們已經消耗了99個商品，僅剩最后一個。這個時候，系統發來多個并發請求，這批請求讀取到的商品余量都是99個，然后都通過了這一個余量判斷，最終導致超發。這就導致了并發用戶B也“搶購成功”，多讓一個人獲得了商品。這種場景在高并發的情況下非常容易出現。
3.2、悲觀鎖思路
悲觀鎖也就是在修改數據的時候，采用鎖定狀態，排斥外部請求的修改，遇到加鎖的狀態，就必須等待，雖然上述的方案的確解決了線程安全的問題，但是我們的場景是“高并發”，也就是說會很多這樣的修改請求，每個請求都需要等待“鎖”，某些線程可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那里。同時這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連接數被耗盡，系統陷入異常。
3.3、FIFO隊列思路
直接將請求放入隊列中的，采用FIFO(First Input First Output，先進先出)，這樣的話就不會導致某些請求永遠獲取不到鎖。看到這里是不是有點強行將多線程變成單線程的感覺哈，現在解決了鎖的問題，全部請求采用“先進先出”的隊列方式來處理。那么新的問題來了，高并發的場景下，因為請求很多，很可能一瞬間將隊列內存“撐爆”，然后系統又陷入到了異常狀態。或者設計一個極大的內存隊列，也是一種方案，系統處理完一個隊列內請求的速度根本無法和瘋狂涌入隊列中的數目相比。也就是說隊列內的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。
3.4、樂觀鎖思路
樂觀鎖是相對于“悲觀鎖”采用更為寬松的加鎖機制，大都是采用帶版本號(Version)更新。這個數據所有請求都有資格去修改，但會獲得一個該數據的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。這樣的話我們就不需要考慮隊列的問題，不過它會增大CPU的計算開銷。但是綜合來說，這是一個比較好的
解決方案。有很多軟件和服務都“樂觀鎖”功能的支持，通過這個功能可以保證數據的安全。
4、隨著
互聯網的用戶越來越多，高并發的場景也變得越來越多，電商秒殺和搶購是兩個比較典型的高并發場景，雖然遇到的挑戰多，但是我們不怕，因為我們一直在努力。
以上就是我們關于什么是
服務器高并發的介紹，希望對大家有所幫助。
免責聲明：本文內容由互聯網用戶自發貢獻自行上傳，本網站不擁有所有權，也不承認相關法律責任。如果您發現本社區中有涉嫌抄襲的內容，請發送郵件至：operations@xinnet.com進行舉報，并提供相關證據，一經查實，本站將立刻刪除涉嫌侵權內容。
京公網安備11030102000056號
京ICP備09061941號-4 
商品已成功加入購物車
