1、請求應用伺服器宕機負載均衡伺服器怎麼處理
fall=5 改成 fall=1
interval=1000 改成 interval=10000
再試
2、Java 伺服器請求和處理該怎麼寫
有三種方抄式：實現servlet介面、繼承GenericServlet、繼承HttpServlet
用Myeclipse直接寫，重寫方法的時候用「Ctrl+/」有提示
現在用的最多的是繼承HttpServlet的方法：直接重寫doGet和doPost方法，在方法裡面就可以任意寫你想用的方法了。
3、如何提高伺服器並發處理能力
有什麼方法衡量伺服器並發處理能力
1. 吞吐率
吞吐率，單位時間里伺服器處理的最大請求數，單位req/s
從伺服器角度，實際並發用戶數的可以理解為伺服器當前維護的代表不同用戶的文件描述符總數，也就是並發連接數。伺服器一般會限制同時服務的最多用戶數，比如apache的MaxClents參數。
這里再深入一下，對於伺服器來說，伺服器希望支持高吞吐率，對於用戶來說，用戶只希望等待最少的時間，顯然，雙方不能滿足，所以雙方利益的平衡點，就是我們希望的最大並發用戶數。
2. 壓力測試
有一個原理一定要先搞清楚，假如100個用戶同時向伺服器分別進行10個請求，與1個用戶向伺服器連續進行1000次請求，對伺服器的壓力是一樣嗎？實際上是不一樣的，因對每一個用戶，連續發送請求實際上是指發送一個請求並接收到響應數據後再發送下一個請求。這樣對於1個用戶向伺服器連續進行1000次請求, 任何時刻伺服器的網卡接收緩沖區中只有1個請求，而對於100個用戶同時向伺服器分別進行10個請求，伺服器的網卡接收緩沖區最多有100個等待處理的請求，顯然這時的伺服器壓力更大。
壓力測試前提考慮的條件
並發用戶數: 指在某一時刻同時向伺服器發送請求的用戶總數(HttpWatch)
總請求數
請求資源描述
請求等待時間(用戶等待時間)
用戶平均請求的等待時間
伺服器平均請求處理的時間
硬體環境
壓力測試中關心的時間又細分以下2種:
用戶平均請求等待時間（這里暫不把數據在網路的傳輸時間，還有用戶PC本地的計算時間計算入內）
伺服器平均請求處理時間
用戶平均請求等待時間主要用於衡量伺服器在一定並發用戶數下，單個用戶的服務質量；而伺服器平均請求處理時間就是吞吐率的倒數，一般來說，用戶平均請求等待時間 = 伺服器平均請求處理時間 * 並發用戶數
怎麼提高伺服器的並發處理能力
1. 提高CPU並發計算能力
伺服器之所以可以同時處理多個請求，在於操作系統通過多執行流體系設計使得多個任務可以輪流使用系統資源，這些資源包括CPU，內存以及I/O. 這里的I/O主要指磁碟I/O, 和網路I/O。
多進程 & 多線程
多執行流的一般實現便是進程，多進程的好處可以對CPU時間的輪流使用，對CPU計算和IO操作重疊利用。這里的IO主要是指磁碟IO和網路IO，相對CPU而言，它們慢的可憐。
而實際上，大多數進程的時間主要消耗在I/O操作上。現代計算機的DMA技術可以讓CPU不參與I/O操作的全過程，比如進程通過系統調用，使得CPU向網卡或者磁碟等I/O設備發出指令，然後進程被掛起，釋放出CPU資源，等待I/O設備完成工作後通過中斷來通知進程重新就緒。對於單任務而言，CPU大部分時間空閑，這時候多進程的作用尤為重要。
多進程不僅能夠提高CPU的並發度。其優越性還體現在獨立的內存地址空間和生命周期所帶來的穩定性和健壯性，其中一個進程崩潰不會影響到另一個進程。
但是進程也有如下缺點：
fork()系統調用開銷很大: prefork
進程間調度和上下文切換成本: 減少進程數量
龐大的內存重復：共享內存
IPC編程相對比較麻煩
4、伺服器如何實現承受如此大量的用戶請求?
首先我想說樓主的提問列表很程序員，從0開始的。
這個當然是不一定的，樓主已經知道問題是負載均衡了，現在大型伺服器一般都會做成分布式的。
其實你說的意思應該是直接處理這個請求還是我找另外一個機器處理你的請求。
伺服器分發請求有很多種策略，舉個簡單的例子。某個伺服器在登錄的時候根據用戶的ID取模，然後選擇對應的一台機器進行轉發，這是一種比較簡單的分發請求策略了。再比如很多游戲伺服器會分網通、電信等大區，然後大區下有分1,2,3...多個房間，這些其實都是分發請求的例子。
根據你的業務類型，可能會存在一個必須有集中處理的過程。比如登錄校驗這個過程，所有的請求最終都要去查詢db，那麼如果db只有一台的話就會存在你說的集中處理情況。現在的開發很聰明的，無論是高並發還是容災都不會只搞一台db的，他們可以分庫分表，可會主從備份，甚至是讀寫分離。
在設計伺服器的時候，肯定會相對會有4中的情況，我們當然不希望因為4中的情況而影響整個伺服器的性能。
我們可以把分發策略放在客戶端，比如登錄的時候在客戶端進行選擇，直接登錄到負載較低的伺服器上。你會說客戶端查詢各個伺服器的負載情況這個功能介面會壓力很大，其實不做IO操作的話，僅僅是獲取內存中的數據性能會很高的。
如果樓主需要進行伺服器壓力測試的話可以試試騰訊公司的一款工具WeTest伺服器性能，用來測試伺服器各個介面的性能情況很有效，附個鏈接：http://wetest.qq.com/gaps/。
5、伺服器的原理，如何處理請求
問題挺多的。首先，你們老師說得已經非常簡潔了，如果要更深層次，從內網（區域網，比如你們的校園網）發送數據出去就已經夠寫好幾千字了，更別說還從內網說到外網。
伺服器只是一個相對的概念，假如別人需要訪問的網站在你的電腦上，你的電腦為別人服務，那麼你的電腦相對於別人的電腦來說就是一台伺服器。你輸入網址之後，你就向伺服器傳送了數據，數據的傳送分上傳和下載，也是相對的，你想伺服器傳送數據，對於你而言是上傳數據，對伺服器而言就變成了下載數據；然後伺服器把數據返回給你，這個過程伺服器就變成了上傳數據到你的電腦，而對於你而言，這個過程你在下載伺服器的數據。
IIS和TOMCAT這些叫WEB容器。把網站放進容器裡面，你才能訪問到網站，假如伺服器是老闆，那麼容器就是他們的秘書，他們會向老闆匯報，並讓老闆分配工作。
初學者還是先慢慢來吧，先學好底層的各種協議。
6、Python web伺服器怎麼處理請求
web伺服器處理連接請求的四種架構方式：
1、單線程web伺服器
此種架構方式中,web伺服器一次處理一個請求,結束後讀取並處理下一個請求。在某請求處理過程中,其它所有的請求將被忽略,因此,在並發請求較多的場景中將會出現嚴重的必能問題。
相關推薦：《Python教程》
2、多進程/多線程web伺服器
此種架構方式中,web伺服器生成多個進程或線程並行處理多個用戶請求,進程或線程可以按需或事先生成。有的web伺服器應用程序為每個用戶請求生成一個單獨的進程或線程來進行響應,不過,一旦並發請求數量達到成千上萬時,多個同時運行的進程或線程將會消耗大量的系統資源。
3、I/O多路復用web伺服器
為了能夠支持更多的並發用戶請求,越來越多的web伺服器正在採用多種復用的架構——同步監控所有的連接請求的活動狀態,當一個連接的狀態發生改變時(如數據准備完畢或發生某錯誤),將為其執行一系列特定操作;在操作完成後,此連接將重新變回暫時的穩定態並返回至打開的連接列表中,直到下一次的狀態改變。由於其多路復用的特性,進程或線程不會被空閑的連接所佔用,因而可以提供高效的工作模式。
4、多路復用多線程web伺服器
將多進程和多路復用的功能結合起來形成的web伺服器架構,其避免了讓一個進程服務於過多的用戶請求,並能充分利用多CPU主機所提供的計算能力。 web伺服器自身並不處理任何動態內容,它是如何響應客戶端的動態內容請求呢? 通過某種協議調用額外的其它進程來運行這個動態頁面,並將結果取回來以後返回給WEB伺服器,進而響應客戶端。
7、ssh框架伺服器如何處理post請求
和保存文件是一個道理，你接受圖片後保存到一個目錄下，然後在資料庫中保存對版應的路徑就行。
struts配置文權件詳解：http://blog.csdn.net/baple/article/details/9420877 自己看看