高性能高併發

時間 2019-11-18

標籤高性能併發简体版

原文原文鏈接

http://www.zhihu.com/search?q=%E9%AB%98%E5%B9%B6%E5%8F%91&type=questionhtml

http://storage.it168.com/a2012/0217/1313/000001313424_5.shtml前端

redis,nginx/Tengine,keeplive,DRBD,heartbeat這些小工具仍是能夠在虛擬機上面多開幾臺跑起來的.至於大業務場景,除了進大公司沒有別的辦法,由於有些工具運行的配置要求過高,必須多臺服務器配合才能完成.
若是有精力,業內很喜歡用perl,python,C來寫一些針對熱點業務的負載腳本.這須要有http協議等網絡封包的理論基礎.
一些建議處理高併發要學習的東西實在太多.要在沒有實際工做經驗的狀況下逐一瞭解太難,也很難深刻.對於高併發的學習,我建議除了多閱讀高併發架構的文檔學習基本的方法論之外,本身要去深刻學習網絡基礎,數據結構和算法.這些都是處理高併發熱點的理論基礎.node

-----------------------------------------------------------------------------------------------------------------------python

進程和線程模型，非阻塞IO，epoll/iocp這些不提，橫向擴展和讀寫分離，
hot standby這些老生常談的也不算，memcached/redis緩存也不算，
也不扯nodejs，twisted，gevent，tornado，erlang等等有助於高併發的工具，
這些都不算，有哪些祕密? 感受作太高併發的都看不起同行了，到底有啥絕活?nginx

SEDA or Actor這類的設計的東西？redis

-----------------------------------------------------------------------------------------------------------------------算法

業務數據庫 -》數據水平分割(分區分表分庫)、讀寫分離
業務應用 -》邏輯代碼優化(算法優化)、公共數據緩存
應用服務器 -》反向靜態代理、配置優化、負載均衡(apache分發，多tomcat實例)
系統環境 -》 JVM調優
頁面優化 -》減小頁面鏈接數、頁面尺寸瘦身spring

應用服務器配置優化，如鏈接數的優化，每一個請求都是獨立的鏈接線程，因此優化此配置能夠提升服務器接收HTTP併發請求的能力.固然，也不是支持的鏈接數越多越好。由於接收過多的HTTP請求，可能會致使服務器處理不了，宕機、癱瘓，相似鐵路局購票網的情況。大部分的站點會根據服務器處理能力來設置鏈接數上限。

提高應用服務器的處理能力：
如多服務器集羣，接收1000個請求分發多幾個服務器去處理。同時，CPU主頻，jvm，代碼邏輯都不一樣程度影響業務計算能力。

若是業務有對數據庫進行操做的，那麼磁盤的IO讀寫速率是影響服務器的處理能力的最大因素。
由於不管配置的鏈接數再多，也須要數據庫服務器執行SQL時進行的磁盤IO讀寫能力支撐才行。關於數據庫服務器將讀寫壓力分擔。經常使用的方法我上面已經總結了。。。sql

-----------------------------------------------------------------------------------------------------------------------數據庫

用Java作一個大流量、高併發的網站應該怎麼樣進行底層構架？採用哪些框架技術比較適合？

通用措施：
一、動態資源和靜態資源分離；
二、CDN；
三、負載均衡；
四、分佈式緩存；
五、數據庫讀寫分離或數據切分（垂直或水平）；
六、服務分佈式部署。

沒看到對業務的描述，業務不一樣面對的多是相差很大的方案，太早介入性能方面的考慮未必是好事，有可能浪費太多時間在一些彎路上，若是實在擔憂的話，儘可能採用一些擴展性強一點點的框架，仍是那句話，不要太早走極端。

多臺tomcat作負載均衡，即便你效率再高。對於高併發，單臺tomcat能管理的thread pool的線程數也是有限的
tomcat使用apr/nio模式增長吞吐量
對於大流量，動靜分離，tomcat處理靜態資源的能力比較差,交給nginx
緩存是重要的，把實時性要求不高的，或者能夠忍受一段時間內的實時，緩存起來。

使用cdn緩存

1：框架用最熟悉的；
2：優化從最上層的業務邏輯開始；
3：硬件捨得投入。

跟框架沒必然聯繫，另外直接使用serverlet對性能提高微乎其微。關健還在於負載均衡的多層次使用，緩存的合理使用，數據垂直和水平切分，異步方案，多系統間的同步，最後千萬別忘了可用性。

框架對性能影響仍是很大的，若是部署到分佈式架構上的話，系統不只性能獲得了提高，容錯性和可擴展性都會大大改善。前臺能夠用Tuscany進行邏輯劃分，子系統分佈到不一樣的服務器上，後臺可使用Hadoop進行分佈式存儲。可是分佈式須要面臨不少的技術問題：分佈式緩存，分佈式數據庫等等，對技術人員要求較高。此外，還可使用nginx作負載均衡分發給tomcat。

框架對性能的影響微乎其微，Java的話挑熟悉的好用的就好了。更重要的是總體架構的設計、數據庫的設計和優化、緩存系統等等。用Tomcat的話不要用Apache，小併發量還能用用，一旦請求多了會很麻煩，用Nginx。JVM特別是GC的調優也能夠看看。

有幾個經常使用的措施
一、對經常使用功能創建緩存模塊
二、網頁儘可能靜態化
三、使用單獨的圖片服務器，下降服務器壓力，使其不會由於圖片加載形成崩潰
四、使用鏡像解決不一樣網絡接入商和不一樣地域用戶訪問差別
五、數據庫集羣圖表散列
六、增強網絡層硬件配置，硬的不行來軟的。
七、終極辦法：負載均衡

大流量，高併發的網站主要考慮的是可伸縮性，當用戶量，流量增大的時候，能夠經過增長機器來分擔壓力。。至於直接用不用servlet，這個看你的架構。。性能和複雜性通常都不能兼得。。

我的認爲框架並不能爲系統的性能獲得多大的提高，框架可以幫助開發人員提升開發效率，濫用框架反而會致使系統性能的降低。
建議使用開發團隊最熟悉的框架，關注代碼自己，防止出現內存溢出的狀況。
大流量，高併發的網站主要的壓力應該是在數據庫的io操做上，儘可能避免系統頻繁請求數據庫，優化查詢語句，合理使用索引，減小sql語句執行的時間。
可使用一些緩存技術，如memcache，將頻繁讀取，不常常變化的數據放入緩存中。

面對大流量，高併發的問題，最好的方法是增長硬件投入。另外，我不認爲servlet去處理底層數據是個明智的選擇。servlet玩的就是request和response，處理和響應客戶端請求爲主。推薦一本書《構建高性能WEB站點》。

底層架構是指服務器嗎？

服務器上的集羣優化很重要的。
嘗試下 Apache + Tomcat 吧。多個Tomcat集羣，Apache作前端，負責靜態內容。再加幾臺服務器，分別作memcached（多臺）、數據庫服務器。

Apache和Tomcat之間的溝通採用AJP協議，聽說效率很高。

這麼下來，這麼多臺服務器，足夠撐不少用戶了。

http://www.zhihu.com/question/19809311

-----------------------------------------------------------------------------------------------------------------------

先學測試吧。不是那種業務功能的測試，是系統的測試。由於要解決大數據量、高併發的問題，我我的的知識與經驗是：

一、先用單機測試。用工具產生大併發量去轟擊服務器，直至服務器緩慢，甚至接近崩潰；

二、在服務器艱難地工做的時候，用工具測試服務器，仔細分析，是什麼使得服務器如此艱難，是 cpu ？是網絡？仍是硬盤 io ？又或者是你的應用？數據庫？

三、找到系統瓶頸後，優化，解決這個瓶頸，而後再循環測試。這時你又會發現新的瓶頸，再解決。循環1 - 3步，直到各方面基本平衡爲止。

四、當單機沒法解決問題的時候，接着開始考慮負載均衡，考慮分佈式方案，而後再用 1 - 3 的步驟分析與測試。

最後，你的問題是，要學什麼？答案就是：學要完成上述的步驟，解決其中產生的問題所涉及的各類知識。這不是一兩本書能夠講得完的。

-----------------------------------------------------------------------------------------------------------------------

大流量: Varnish, Nginx, HAproxy

高併發: Node.js, Nginx, Redis, No-SQL

靜態化，CDN

-----------------------------------------------------------------------------------------------------------------------

你須要瞭解大數據高併發的瓶頸在哪裏，通常都是數據庫層面的，機械硬盤承載不起很是快速的讀寫操做，cpu承載不起大量的邏輯運算，因此最基本的解決思路就是：
1.換固態硬盤加快硬盤的讀寫效率。
2.創建緩存中間件下降對硬盤的讀寫次數，緩存不用多說了，最最最基本和重要的優化策略。
3.將硬盤的讀寫或者數據的計算分攤到多臺機器上，也就是集羣。hadoop就是基於這個層面的。
4.良好的查詢算法，下降讀的次數，分表，分庫，索引等都是基於這層面的。

理論上來說，在帶寬充裕的狀況下，只要遵循上面的4個思路進行延伸就能夠解決大部分的高併發問題。

-----------------------------------------------------------------------------------------------------------------------

怎樣學習才能擁有所謂「高併發」的經驗？

這個問題徹底能夠重定向到如何處理高併發業務場景. 如下只是我工做一年多接觸到的一些基礎,也許有誤差,要具有高併發的經驗確實須要有實際項目,由於業務邏輯其實很容易理清,可是要在高併發的狀況下如何找到業務繁忙的熱點並進行優化,徹底只能憑經驗.
假如沒有靠譜的公司,接觸不到高併發的業務場景怎麼辦? 從處理技巧上,能夠經過大牛學習高併發的架構,好比張宴:張宴的博客 - Web系統架構與底層研發.至少你能夠知道處理高併發的業務邏輯是:

前端:異步請求+資源靜態化+cdn
後端:請求隊列+輪詢分發+負載均衡+共享緩存
數據層:redis緩存+數據分表+寫隊列
存儲:raid陣列+熱備
網絡:dns輪詢+DDOS攻擊防禦

對於高併發並無什麼通用解決方案,必須根據業務場景進行分析,不一樣的業務場景對於架構的取捨是不同的.但萬變不離其宗,掌握這些處理高併發的分析方法仍是頗有必要的.
如何學習高併發的工具? 處理高併發的開源輪子其實不少.不少高併發的架構分享都會說起使用的工具,本身多留心,再看看手冊,有條件本身搭起來跑一跑. redis,nginx/Tengine,keeplive,DRBD,heartbeat這些小工具仍是能夠在虛擬機上面多開幾臺跑起來的.至於大業務場景,除了進大公司沒有別的辦法,由於有些工具運行的配置要求過高,必須多臺服務器配合才能完成.
如何模擬高併發場景? 並非只有實際生產環境才能測試高併發,其實模擬高併發的輪子也不少,最經常使用的apache benchmark,winrunner,loadrunner,這些教程不少,用來模擬基本的高併發業務綽綽有餘,本身安裝試用版,學學如何用,模擬些經常使用的業務. 若是有精力,業內很喜歡用perl,python,C來寫一些針對熱點業務的負載腳本.這須要有http協議等網絡封包的理論基礎.
一些建議 處理高併發要學習的東西實在太多.要在沒有實際工做經驗的狀況下逐一瞭解太難,也很難深刻.對於高併發的學習,我建議除了多閱讀高併發架構的文檔學習基本的方法論之外,本身要去深刻學習網絡基礎,數據結構和算法.這些都是處理高併發熱點的理論基礎.