參照乙個大佬的文章，我也寫一篇高併發的文章，**一下這門高階的現象，以及一些解決措施。
乙個關於高併發的問題：
那位大佬說：如果真的幹過高併發系統的人，面試官是絕對不會對你提出這個問題的，否則就是他太不明智了。至於為嘛這樣說呢，因為如果設計乙個高併發系統，這句話就是錯誤的了，因為在脫離了業務的系統架構中都是一群紙上談兵，真正在複雜業務場景而且存在高併發的時候，那系統架構一定不是那麼簡單的，用個redis、訊息佇列就能解決？那不是扯淡嗎？在真實的實際開發中，系統架構配上了業務場景後，會比這種所謂的「高併發」要複雜的多多的。
為什麼會出現高併發呢？為啥高併發聽起來就很牛掰的乙個東西呢？乙個併發很厲害，加乙個高就更加高階了，都是服務級別了。
那麼到底什麼是高併發呢？
那麼從那個大佬帖子中共總結了6點，我就用我自己的理解來講解一下，有哪些併發系統設計的優化方案，向這些優化方案都是高階操作，所以大家能夠學習就堅決學習一下。
1.系統拆分：為啥要拆分？這就是做分布式的概念了，將整個系統按照各個服務進行劃分，各司其職，然後通過webservice或者rpc通訊機制，服務間內部通訊，一種面向服務（soa）的架構思維。就好比一堆人開個飯館，a側重做端菜，服務員的業務，b側重做炒菜的業務，c作為老闆，只是在前台安排一下新來的客人做**，然後安排a帶領去，然後收一下銀之類的；由於炒菜可能業務量比較重，為了讓菜炒得及時，炒得好吃，那麼b專職只炒菜；a呢，有可能早上的時候，人少，那麼也充當一下配菜的角色，幫助b進行一下早上的切菜，那這就是分布式思想了。那麼針對收銀，在超市裡面，我們通常可以看到有多個收銀的入口，這樣的話，是不是就分擔了收銀的壓力了呢？收銀員幹得活都一樣的。但是就是有好幾個人同時在收銀，那麼顧客看到**人排隊少，那麼顧客就會去那裡排隊，均攤每個收銀隊伍的長度了。那麼在系統中，也是模擬類似的思想來增加結賬的效率，我們可以通過一些分布式框架來搭建乙個分布式系統，然後有可能多個服務節點在分布式架構中註冊，然後做著同樣的業務處理，設計多個資料庫集群部署，那麼多個資料庫，乙個資料庫最大扛2000，多個2000，並行工作，那併發量的瓶頸就接觸了。
2.快取，快取這個概念其實在任何的裝置上都有直接的應用，怎麼理解呢？好比乙個手機，記憶體和硬碟，我們在打遊戲的時候，剛剛啟動和平精英，是不是需要彈乙個天美，，然後乙個燒雞？然後正在載入中？然後再一步步進到吃雞的執行介面中？是的，它正是從android系統中自帶的sqlite輕量資料庫讀取遊戲的資料資訊，這種db操作是很耗時，耗資源的。那我們已經啟動好了遊戲，臨時退出一下遊戲，去聊個天，然後再返回的時候，它並不需要像剛啟動那樣一點一點載入，而是直接就載入好的，這就是它遊戲資料直接在記憶體中準備好了，並沒有**。這個例子也不一定和快取，db的概念一模一樣，理解個大概意思。只需要記住，高速緩衝區不是資料庫直接能比的，要知道，redis可是輕輕鬆鬆單機應對幾萬的併發量的。所以在系統中快取必須要，尤其在於那些主read業務的服務中，可能就是配合多個快取服務工作的，快取的作用可不止那麼點，比如快取共享，分布式鎖，各種提高業務的處理能力的支援。那麼至於高併發系統中，快取是一員大將。
4.分庫分表，如果還問有什麼優化的空間，那就在資料庫的角度進行優化了，且不說那種粒度小的優化方式。可以從冷熱資料，按業務將資料庫的表分成幾個庫，幾個資料庫服務。如果是那種記錄表，可以按年月劃分不同時間段表，這樣，每一張表的io壓力就降低了，我就不信了，這還防不住併發？
5.讀寫分離：這其實也是也是資料庫角度的優化方案，我公司現在用到的一張表就是幾乎的讀操作，原始資料表，根本不讓更新，刪除操作，然後讀取的話，通常都是後台erp管理系統用於資料統計用到，這是在erp後台系統中，然後寫入操作，就是在examservice中進行檢測業務時進行佇列寫入的。那麼這裡我們也可以用乙個主從架構，主庫負責寫入，我負責生產，從庫負責讀取，那麼這樣再新增乙個從庫也是很方便的，多乙個消費服務就是了。
基本上來說，以上6點都是很常見的併發系統設計方案，對於選擇的時候，也要根據實際的業務場景來進行併發系統設計。需要考慮哪些表結構的哪個字段新增索引，索引新增不當，反而會效能降低；哪些需要分表，分表後，到時候有哪些業務需要鍊錶查詢，哪些的操作頻率高，我們都需要考慮取捨的。哪些資料是需要放到快取的，因為有些需要實時更新的，我們需要實時的從db中讀取，哪些資料的併發訪問的，這些地方都要考慮快取擊穿，快取穿透，快取雪崩。所以說，設計乙個高併發的系統，設計好了，無疑是好的，是可以抗很大併發壓力的，但是要知道有些時候，殺雞用牛刀，你多浪費的力氣做什麼。系統整合的架構越多，維護的成本就會越大，而且，併發系統在市面上都是通用的，並不是針對某個公司現狀針對設計的，所以得結合公司專案自身的情況來進行適當的選擇。
祝各位**無bug！！
這裡拷貝一張別人的圖：
實際專案中如何應對高併發等場景
高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per second 併發使用者數等。吞吐量 單位時間內處理的請求數量。qps 每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。1.採用前後端分離的模式，前...
Mysql主從複製應對高併發
這裡有我之前寫的一篇文章 分庫分表會用到讀寫分離，因為使用不同的儲存引擎，來分別應對讀場景和寫場景。那用到讀寫分離，就一定要用到主從複製，比方說我們需要向乙個庫裡邊寫資料，另外乙個庫之讀，這就考慮到資料同步的問題。顧名思義，高併發就是每秒很多的事要去處理。其實所謂的高併發的解決方案，也就是分散壓力。...
高併發，如何提高併發量
一 什麼是高併發 高併發 high concurrency 是網際網路分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per se...