① 如何搭建apache+tomcat集群
在實際應用中，如果網站的訪問量很大，為了提高訪問速度，可以與多個Tomcat伺服器與Apache伺服器集成，讓他們共同運行servlet/jsp組件的任務，多個Tomcat伺服器構成了一個集群（Cluster）系統，共同為客戶提供服務。集群系統具有以下優點：
高可靠性（HA）：利用集群管理軟體，當主伺服器故障時，備份伺服器能夠自動接管主伺服器的工作，並及時切換過去，以實現對用戶的不間斷服務。
高性能計算（HP）：即充分利用集群中的每一台計算機的資源，實現復雜運算的並行處理，通常用於科學計算領域，比如基因分析，化學分析等。
負載平衡：即把負載壓力根據某種演算法合理分配到集群中的每一台計算機上，以減輕主伺服器的壓力，降低對主伺服器的硬體和軟體要求。
原理：JK插件的負載均衡器根據在worker.properties中配置的lbfactor（負載平衡因數），負責為集群系統中的Tomcat伺服器分配工作負荷，以實現負載平衡。每個Tomcat伺服器間用集群管理器（SimpleTcpCluster）進行通信，以實現HTTP回話的復制，比如Session。
下面我們在一台機器上配置一個Apache和兩個Tomcat伺服器集群：
2.安裝Apache，安裝兩個Tomcat，並把一個測試項目放到兩個Tomcat的webapps目錄下以便以後測試。
3.把mod_jk.so復制到<apache_home>/moles下。
4.在<apache_home>/conf目錄下創建：workers.properties文件：
"pln">worker "pun">. "pln">list "pun">= "pln">worker1 "pun">, "pln">worker2 "pun">, "pln">loadbalancer "com">#apache把Tomcat看成是工人，loadbalancer是負載均衡器
worker.worker1.host=localhost#Tomcatworker1伺服器
worker.worker1.port=8009#Tomcat埠
worker.worker1.type=ajp13#協議
worker.worker1.lbfactor=100#負載平衡因數
worker.worker2.host=localhost#Tomcatworker2伺服器
worker.worker2.port=8009#因為在一台機器上所以埠不能一樣
worker.worker2.type=ajp13#協議
worker.worker2.lbfactor=100#設為一樣代表兩台機器的負載相同
worker.loadbalancer.type=1b
worker.loadbalancer.balanced_workers=worker1,worker2
worker.loadbalancer.sticky_seesion=false
worker.loadbalancer.sticky_session_force=false
說明：1.worker.loadbalancer.sticky_seesion如果設為true則說明會話具有「粘性」，也就是如果一個用戶在一個Tomcat中建立了會話後則此後這個用戶的所有操做都由這個Tomcat伺服器承擔。集群系統不會進行會話復制。如果設為false則下面的 sticky_session_force無意義。
2.sticky_session_force：假設sticky_session設為true，用戶會話具有了粘性，當當前Tomcat伺服器停止服務後，如果sticky_session_force為true也就是強制會話與當前Tomcat關聯，那麼會報500錯誤，如果設為false則會轉到另外的Tomcat伺服器。
5.修改<apache_home>/conf/httpd.conf文件，在文件後面加上：
"com">#Tomcat集群配置
"com">LoadMolejk_molemoles/mod_jk.so
JkWorkersFileconf/workers.properties
#我的工人們
JkLogFilelogs/mod_jk.log
#日誌文件
JkLogLeveldebug
#tomcat運行模式
JkMount/*.jsploadbalancer
#收到.jsp結尾的文件交給負載均衡器處理
JkMount/helloapp/*loadbalancer
#收到helloapp/路徑交給負載均衡器處理
6.修改兩個Tomcat的conf/service.xml文件。
6.1首先要修改AJP埠，確保他們與workers.properties中配置的一樣
例如按我們上面的配置，只需要把Tomcat2中的AJP埠該為8109即可。
6.2此外在使用了loadbalancer後，要求worker的名字與Tomcat的service.xml中的Engine元素的jvmRoute屬性一致，
例如worker1修改為： <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">
6.3另外，如果兩台Tomcat伺服器裝在一台機器上，必須確保他們的埠沒有沖突，Tomcat中一共配置了三個埠：
<Server port="8005" shutdown="SHUTDOWN">
<Connector port="8080" .../>
<Connector port="8109" protocol="AJP/1.3" redirectPort="8443" />
把其中一個該了讓它們不一樣就行了。
完成了以上步驟我們的集群算是基本完成了，打開Apache和兩個Tomcat 瀏覽器進入：localhost/demo/ 能夠正確訪問。
為了測試，我們寫一個jsp文件：test.jsp
"tag"><html>
<head>
<title>test</title>
</head>
<body>
<%
System.out.printfln("calltest.jsp");
%>
session:<%=session.getId()%>
</body></html>
把它放到兩個Tomcat中的demo項目中，瀏覽器訪問這個頁面，每次訪問只在一個Tomcat控制台列印語句。
然而頁面中的Session Id是會變的。這種情況下如果一個用戶正在訪問時，如果跳到另一個Tomcat伺服器，那麼他的session就沒有了，可能導致錯誤。
7.配置集群管理器
如果讀者對HttpSession有了解應該知道，用戶的會話狀態保存在session中，一個瀏覽器訪問多個網頁它們的請求始終處於一個會話范圍中，因此SessionID應該是不變的。
以上我們看到的瀏覽器中的SessionID不同，因為轉到另一個Tomcat後當前會話就結束了，又在另一個伺服器上開啟了一個新的會話。那麼怎麼讓多個Tomcat伺服器共享一個會話呢?
為了解決上述問題，我們啟用Tomcat的集群管理器（SimpleTcpCluster）：
7.1修改Tomcat1和Tomcat2的servlet.xml文件，在Engine元素中加入以下Cluster元素
"tag"><Cluster "pln"> "atn">className "pun">= "atv">"org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<ManagerclassName="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<ChannelclassName="org.apache.catalina.tribes.group.GroupChannel">
<MembershipclassName="org.apache.catalina.tribes.membership.McastService"
bind="127.0.0.1"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<ReceiverclassName="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<SenderclassName="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<TransportclassName="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<InterceptorclassName="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<InterceptorclassName="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<ValveclassName="org.apache.catalina.ha.tcp.ReplicationValve"filter=""/>
<ValveclassName="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<DeployerclassName="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListenerclassName="org.apache.catalina.ha.session."/>
<ClusterListenerclassName="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
關於Cluster的相關介紹參照：<tomcat-home>webappsdocscluster-howto.html <tomcat-home>webappsdocsconfigcluster.html
7.2分別修改Tomcat1和Tomcat2 demo項目的web.xml文件，在後面加入<distributable>元素
"tag"><web-app>
"pln">...
"tag"><distributable/>
</web-app>
如果一個web項目的web.xml文件中指定了<distributable/>元素那麼Tomcat伺服器啟動這個Web應用時，會為它創建由<Cluster>元素指定的會話管理器，這里我們用的是DeltaManager,他們把會話從一個Tomcat伺服器復制到集群中另一個Tomcat伺服器。
7.3重新啟動兩個Tomcat，發現Tomcat控制台還是依次列印出Call test.jsp 頁面中的SessionID卻不變了。測試完成。
重要說明：(1).如果項目要發布到集群上，那麼與會話有關的類需要實現java.io.Serializable序列化介面。
(2).集群中Tomcat間用組播方式進行通信，如果機器上有多個網卡則可能導致組播失敗，解決的辦法是<Cluster>元素的<Membership>元素配置bind屬性，它用於明確知道組播地址：
<Membership className="org.apache.catalina.tribes.membership.McastService"bind="127.0.0.1".../>
(3).如果集群較小，可以採用DeltaManager會話管理器，如果多的話建議使用BackupManager
(4).<Membership>的address設為"228.0.0.4"，運行時須確保機器聯網能訪問到該地址，否則可能運行失敗。
② ISSweb伺服器的集群技術
集群技術的出現和IA架構伺服器的快速發展為社會的需求提供了新的選擇。它價格低廉，易於使用和維護，而且採用集群技術可以構造超級計算機，其超強的處理能力可以取代價格昂貴的中大型機，為行業的高端應用開辟了新的方向。
集群技術是一種相對較新的技術，通過集群技術，可以在付出較低成本的情況下獲得在性能、可靠性、靈活性方面的相對較高的收益。
目前，在世界各地正在運行的超級計算機中，有許多都是採用集群技術來實現的。
集群是由一些互相連接在一起的計算機構成的一個並行或分布式系統。這些計算機一起工作並運行一系列共同的應用程序，同時，為用戶和應用程序提供單一的系統映射。從外部來看，它們僅僅是一個系統，對外提供統一的服務。集群內的計算機物理上通過電纜連接，程序上則通過集群軟體連接。這些連接允許計算機使用故障應急與負載平衡功能，而故障應急與負載平衡功能在單機上是不可能實現的。
伺服器集群系統通俗地講就是把多台伺服器通過快速通信鏈路連接起來，從外部看來，這些伺服器就像一台伺服器在工作，而對內來說，外面來的負載通過一定的機制動態地分配到這些節點機中去，從而達到超級伺服器才有的高性能、高可用。
集群的優點
高可伸縮性：伺服器集群具有很強的可伸縮性。隨著需求和負荷的增長，可以向集群系統添加更多的伺服器。在這樣的配置中，可以有多台伺服器執行相同的應用和資料庫操作。
高可用性：高可用性是指，在不需要操作者干預的情況下，防止系統發生故障或從故障中自動恢復的能力。通過把故障伺服器上的應用程序轉移到備份伺服器上運行，集群系統能夠把正常運行時間提高到大於99.9%，大大減少伺服器和應用程序的停機時間。
高可管理性：系統管理員可以從遠程管理一個、甚至一組集群，就好像在單機系統中一樣。
③ 企業為什麼搭建群集環境和web網站
兄弟 您好上海獻峰Web伺服器集群搭建如下
一 需求分析：
1.整體需求：搭建一個高可用的網站伺服器集群，能承受高並發請求，能抵禦一般的網路攻擊，任何一台伺服器的退服不影響整個集群的運作，並且能對各伺服器的運行情況作出實時監控。
2.詳細需求分析：
根據需求，計劃根據以下拓撲搭建運行環境：
二 詳細功能描述：
1.前端伺服器採用nginx實現反向代理和負載均衡，用keepalive實現HA。此部分由centos1和centos4實現，centos1作為主伺服器，centos4作為熱備伺服器。Nginx會根據不同的請求ip機會均等地把請求發送到後端兩台伺服器，並且以ip hash的方式保持各個ip的會話。
2.後端伺服器構建在centos2與centos3上，採用apache作為web發布軟體，mysql作為資料庫，測試網頁用Django來實現。兩台伺服器的資料庫能夠自動同步。
3.作為熱備伺服器，centos4在centos1沒有故障時並沒有業務流量，處於相對空閑的狀態，因此在centos4上配置nfs使它成為文件共享伺服器，網站文件放在這台伺服器上。
4.centos5作為監控伺服器，運行nagios監控各伺服器狀態。出現告警時通過告警通知管理員。另外centos5還作為saltstack的伺服器，其他主機的軟體安裝、文件傳輸、命令運行等操作均通過saltstack批量實現。
三 總體部署描述：
1.各個伺服器均安裝centos6.4 64位版本，採用cobbler實現批量自動安裝。
2.各個軟體均安裝最新的穩定版，centos自帶的軟體也要進行升級，例如python，Centos自帶的版本比較久，會影響Django的運行。
四 詳細部署描述：
1.nginx設置
Nginx在這里的作用主要是反向代理、作為用戶以及伺服器之間的緩存、以及以負載均衡的方式把請求發送到後端兩台伺服器。
採用編譯安裝的方式安裝nginx，具體過程就不在此記述了，不過為了更好地抵擋入侵，建議編譯前修改一下安裝文件，使入侵者難以查出nginx的版本號，修改安裝文件中的nginx.h，把相關欄位修改如下：
NGINX_VERSION "1.0" NGINX_VER "webserver" NGINX_VERSION
Nginx的配置文件如下：
212800
default_type application/octet- zone=20;
send_timeout 20;
client_body_buffer_size 1k;
client_header_buffer_size 1k;
large_client_header_buffers 2 1k;
server_tokens off;
client_body_timeout 20;
client_header_timeout 20;
ip_hash;
server 10.0.0.3;
server 10.0.0.280///100;
limit_rate 500k; 500 502 503 504 /= /
因為後端測試網頁是用Django寫的，因此nginx就不用處理php等動態網頁的請求了。
設置完畢後，把nginx設置為開機啟動，可以用如下方式：
echo 「/usr/local/nginx/sbin/nginx」 >>/etc/rc.local
2.Keeplive設置
Keeplive的作用是在兩台伺服器（centos1、centos4）之間，以VRRP協議實現HA。通過虛擬出一個Virtul IP（本例子中是192.168.00.000）來對外發布業務。兩台伺服器中的任一台退服了，keeplive會自動把業務轉到另一台上。在這里centos1是主伺服器，centos4是備用伺服器。平時的數據流量只會通過centos1，只有centos1退服了，數據流量才會割接到centos4上。
centos1上的keepalive配置：
! Configuration File @test.com @127.0.0.130
virtual_router_id 51192.168.48.139
priority 100
advert_int 1 1111192.168.48.138
對於從伺服器centos4，只需要把以上配置文件的部分內容修改即可：
192.168.48.14090
同樣，配置好配置文件後，把keepalive添加到開機啟動中。
對於keepalive，由於是使用VRRP協議來檢查對端是否在線的，只要對端能ping通，那麼keeplive就會認為對端在線。但也有一種情況是對端伺服器沒有宕機，但nginx出錯關閉了，這種情況下keepalive仍然會判斷對端在線，不會把業務割接到備用伺服器。因此我們需要在伺服器上運行一個腳本，監控nginx進程的狀態。假如nginx進程關閉了，先嘗試重啟nginx，無法重啟時就關閉keepalive的進程，使業務割接到備用端。
④ 伺服器集群怎麼搭建Linux平台的
linux伺服器集群平台的搭建比較簡單，有專門的均衡軟體，比如lvs，lvs是一個集群系統，由很多伺服器組成，可以根據需要，把它門分為三層，一層是前端機，用於均衡，相當於公平為系統分配工作，二層是伺服器群，比如web伺服器群，DNS，mail群等，這些就是接待員，把均衡器分配的工作進行處理，第三層是存儲設備，用於存儲數據，相當於檔案庫。
知道這些後，要搭建就非常容易，有現成的軟體，比如我有四台web伺服器，2台資料庫，1台前置機 ，安裝linux系統，安裝lvs軟體，比如
heartbeat-2.1.4-9.el5.i386.rpm
heartbeat-ldirectord-2.1.4-9.el5.i386.rpm
libnet-1.1.4-3.el5.i386.rpm
heartbeat-devel-2.1.4-9.el5.i386.rpm
heartbeat-pils-2.1.4-10.el5.i386.rpm
perl-MailTools-1.77-1.el5.noarch.rpm
heartbeat-gui-2.1.4-9.el5.i386.rpm
heartbeat-stonith-2.1.4-10.el5.i386.rpm
當然還需要配置，你可以自己網路有關lvs集群的詳細安裝說明。希望能幫助你。
⑤ web伺服器的工作原理是什麼啊
Web服務的工作原理是各公司從注冊表(ebXML或UDDI的注冊表)獲得發布信息，建立滿足要求的執行過程，然後向注冊表發布它們的服務。以後，其他公司發現注冊表中列出的一項服務，同意已制定的標准，然後開展業務。一旦在標准上取得一致並且約定的規則得到滿足，應用程序就可以接管交易處理，因而從開展業務的開銷中去除了人工互動。在這種模型中，通過利用現有基礎設施，應用可以交換有關公司希望提供和消費的服務的信息。此外，應用還可以查詢注冊表，查找可以以更優惠條件提供同樣服務的其他應用(公司)。
在標准方面，UDDI作為一種用於Web的黃頁被編制出來，它可以通過WSDL訪問。WSDL支持類似於UDDI特性的ebXML注冊特性。除了與UDDI的資料庫特性競爭外，ebXML的Web服務部分曾被考慮與SOAP標准進行競爭。幸運的是，OASIS已將SOAP集成到ebXML中。目前，這些協議既相互重疊(UDDI和ebXML)又相互補充(SOAP和ebXML)。
·UDDI(通用描述、發現和集成)：UDDI是Microsoft、IBM和Ariba為制定一項用於描述、注冊和發現Web服務的Internet標准而成立的聯盟。由此而來的UDDI框架是「一個企業可以注冊其Web服務並查找其他Web服務的資料庫集合。」應用程序使用SOAP API來讀取或提供與UDDI相關的WSDL文檔。
·WSDL(Web服務描述語言)：WSDL文件，即UDDI和ebXML注冊表的子集合，提供聯系信息、Web服務的描述、它們的位置以及如何調用它們的規范。UDDI注冊表按行業類別和地理位置細分。WSDL文件常常由另外的信息源(如，COM IDL或CORBA文件或EJB類定義)生成。WSDL用於描述通過Internet（或其他網路）可訪問的程序以及同這些程序進行交流的信息格式和協議。它可以使Web服務的功能通過標準的方式展示出來，從而使Web服務和開發工具更易兼容。
·SOAP(簡單對象訪問協議)：SOAP是使用XML通過Internet發送信息和訪問動態Web服務的友好界面。其主要作用在於確保信息通過互聯網在業務應用之間傳輸的可靠性。作為一種用在分布式環境中交換結構化數據的協議，它包括三個部分：信封、報頭(可選)和協議消息體。信封標記SOAP消息的開始與結束。它還可以規定在網路上數據的編碼規則。SOAP報頭可以包含發送給一個地址或多個地址的郵件、一個支付代碼或有關RPC類型互動的信息。一個信封中可以有多個報頭或完全沒有報頭。SOAP消息體傳送自描述結構或RPC類型介面格式的數據。
·ebXML(電子業務XML)：ebXML標準是由OASIS和UN/CEFACT為幫助使XML成為開展電子數據交易的世界性語言。ebXML架構以業務過程和信息模型開始，將這個模型映射到XML文件並定義處理這些文件以及在交易夥伴之間交換這些文件的應用程序的要求。同UDDI注冊表一樣，ebXML注冊表以標準的文檔格式列出一家公司的能力的清單，使企業可以通過這個注冊表找到其他企業、定義協議以及交換幫助開展商務交易的XML消息。ebXML的目標是使所有這些事務可以在Internet上被自動執行，無需人工干預。