1、.：.；數據庫壓力處理方法 目前言兌網訪問量，越來越大了，言兌網全部是動態(tài)頁，需求數據及時呼應給客戶，目前CPU占用率曾經在10%-80%中浮動，假設不設置緩存，那么直接會導致大家訪問不了本站或者呼應速度很慢。為了以后做預備，特別搜集了一下數據庫壓力處理資料，為以后做預備，基于目前的情況我們的目的是用最少的資金獲取最大的性能效益。數據庫效力器負載平衡集群的實現：MS SQL Server數據庫 HYPERLINK server.it168/效力器可以說是運用范圍最廣的數據庫產品，并且越來越多地在大型和比較關鍵的運用系統中提供效力。當企業(yè)運用越來越復雜、數據量越來越大的時候，SQL Server

2、數據庫要不停的進展處置、 HYPERLINK storage.it168/存儲、查詢的任務，這個時候企業(yè)就要思索SQL Server數據庫效力器的性能和速度及 HYPERLINK safe.it168/平安性了。 SQL Server 2005依然不直接地支持負載平衡但是它為以前SQL Server版本中可用的所有負載平衡方法提供了令人激動的改善和支持。 目錄1、端到端拓撲的事務性復制2、表分割3、備份和重新存儲上的改善(片段式重新存儲)4、數據庫鏡像和快照端到端拓撲的事務性復制SQL Server 2005對端到端(P2P)的拓撲構造上的事務性的復制加強了支持。SQL Server 2000

3、支持雙向的復制，這就可以讓兩臺效力器同時對彼此發(fā)布和訂閱數據。效力器可以更新同一個共享數據，但是在這樣的拓撲中他被限制在兩臺效力器上。P2P的拓撲構造支持無限的發(fā)布效力器，他們彼此之間可以相互交換事務。當然，當參加的發(fā)布者的數量添加之后，事務性的延遲也就更大了。雖然在他的P2P拓撲構造中對節(jié)點的數量沒有實際上的限制，但是只需在某個確定的數字之下才可以提供可接受的性能。微軟引薦低于12個節(jié)點，以保證性能的優(yōu)化。無論怎樣，P2P拓撲都是SQL Server的一個宏大提高：如今，多端點效力器可以更改數據，并且向其他的發(fā)布者復制事務。這就是說，訂閱效力器不再被限制在主要的報告環(huán)境中。他可以經過事務性負

4、載全球共享的方式將效力器分布開來。當用戶的數量添加的時候，只需簡單地向這個群體中添加效力器即可。除了將負載分布之外，這個拓撲構造還添加了可用性。假設任何一個點的效力器不可達，那么池中其它的效力器就會共享這個負載，由于每個效力器都有其它一切效力器上可獲得的全部數據集合。以下的表列出了運用P2P拓撲構造來進展負載平衡的優(yōu)點和缺陷。優(yōu)點:一切參與的效力器都有完全的數據集合。 用戶可以銜接到任何一個點的效力器上來讀取或者修正數據。由于負載在效力器之間進展了平衡，讀取的性能得到了很大程度的改善。 缺陷:多個效力器會修正同一個數據，這會導致沖突。事務性復制不支持具有超出常規(guī)的沖突處理方案。他必需找出處理或

5、者防止?jié)撛跊_突的處理方法。 當端點效力器的數量添加的時候，性能會大幅下降。寫活動反復，由于一切的數據都在同一臺效力器上。 留意：復制在處置數據庫方案無縫修正方面也進展了加強。在以前的發(fā)布中，修正復制的對象的方案需求關機時間。但是在SQL Server 2005中就不是這樣的情況了。表分割分布式分區(qū)視圖的任務方式在SQL Server 2005中與以前版本中的任務方式一樣。然而，SQL Server 2005還支持表分區(qū)，這可以讓他經過分布讀寫負載到多個磁盤(或者磁盤陣列)上來改善性能。對于分區(qū)表，他必需識別分區(qū)要用的是哪一個卷，還有每個分區(qū)的范圍。例如，一個標識字段的數值可以定義分區(qū)范圍;一個

6、分區(qū)內可以允許從1到1百萬的數值，在第二個分區(qū)內可以允許1百萬到2百萬，以此類推。分區(qū)范圍可以經過分區(qū)函數來指定.然后他還必需創(chuàng)建一個分區(qū)方案來講分區(qū)函數中定義的每個范圍值映射到分別的文件組上去。每個文件組都可以放在不同的磁盤上。以下的表給出了表分區(qū)的優(yōu)缺陷：表分區(qū)的優(yōu)缺陷優(yōu)點運用分區(qū)方案和函數很容易建立 簡化了對大表的維護(有幾十億行記錄) 允許為每個分區(qū)創(chuàng)建獨立的索引缺陷 分區(qū)字段支持的數據類型有一定限制 必需為每個單獨的分區(qū)建立一個表都，但是他可以在多個表上反復運用同一個分區(qū)函數。表分區(qū)可以讓他將負載擴展到磁盤上去。然而，一切的數據都必需被同一個效力器管理。假設他的性能瓶頸與CPU或者內

7、存有關，那么這種方法看起來不是他最好的選擇。 備份和重新存儲方面的改善(片段式重新存儲)SQL Server的備份和重新存儲特性沒有很大的改動，但是微軟確實添加了一些新的函數來允許用戶比以前更快地訪問被重新存儲的數據庫。SQL Server 2005如今支持片段式數據庫重新存儲。片段式重新存儲可以讓他首先重新存儲主要的文件組，然后將數據庫啟動，處于在線形狀。然后，可用的第二個文件組也可以被重新存儲。只需第一文件組被重新存儲了，那么用戶就可以銜接到數據庫了。其他的文件組可以繼續(xù)重新存儲，與此同時，數據庫也可以為查詢和事務提供效力。正在重新存儲的文件組標志為離線。假設他有一個100GB的數據庫，其

8、中的75GB是歷史性數據，很少被訪問到。他可以將這些歷史性數據放在它本人的文件組里面，然后讓那些頻繁訪問的數據放在另外一個文件組。假設他將最近的數據放在第一文件組中，那么他就只需求重新存儲25GB的數據就可以讓用戶銜接到他的數據庫上。然后他再重新存儲其它的保管歷史性數據的文件組。以下的表列出了這個備份和重新存儲處理方案的優(yōu)缺陷：備份和重新存儲的優(yōu)缺陷：優(yōu)點實現和維護非常簡單 允許對報告數據庫進展讀取和寫入缺陷 不能提供最新的數據 在重新存儲的時候，數據庫不能訪問。這就意味著報告無法生成。 數據庫鏡像和快照SQL Server 2005引入了數據庫鏡像的概念來協助 獲得高可用性。特別提示的是，只

9、需它正是發(fā)布了，數據庫鏡像就可以在SQL Server 2005上運用。然而，只需到SQL Server 2005 Service Pack 1才會支持鏡像，暫定在2006年年初發(fā)布。從本質上來說，鏡像的任務方式與日志傳輸類似。1、事務日志記錄可以運用在兩個效力器中的數據庫文件上。與日志傳輸不同的是，數據庫鏡像不需求他備份事務日志，也不需求拷貝備份到備份效力器上。2、數據庫鏡像延續(xù)兩次寫入數據。與日志傳輸不同，備份的數據庫必需堅持在非恢復的方式中，這可以防止對數據的訪問，即使是只讀的方式。然而，鏡像允許對備份數據庫進展快照。數據庫快照是SQL Server 2005中引入的另一項特性?？煺帐悄?/p>

10、一個時間點上的數據庫的克隆。只需他的鏡像的數據庫進展了快照，他就可以讓用戶查詢快照?？煺盏纳赏ǔＶ恍枨髱酌腌姡捎谒鼘嵺`上在這個過程中拷貝任何數據。因此，要把負載分布到他的主效力器和備用效力器上，他可以將他的數據庫鏡像，然后階段性地對備份效力器進展快照。他還可以運用快照在主效力器上進展報告。以下的表列出了數據庫鏡像和快照的優(yōu)缺陷：數據庫鏡像和快照的優(yōu)缺陷優(yōu)點從鏡像數據庫中生成快照非?？?數據是最新的，由于它是繼續(xù)寫入鏡像 在同一個數據庫上可以生成多個快照缺陷: 快照提供了對數據的只讀訪問. 擁有快照，會添加效力器的負擔，對性能產生負面影響 假設他正好對鏡像效力器進展錯誤恢復，那么事務和報告活

11、動都會指向同一個效力器但是不同的數據庫。然而，長期以來，SQL SERVER數據庫效力器都只需“熱備的處理方案，而沒有“ HYPERLINK product.it168/list/b/0462_1.shtml負載平衡和“集群的處理方案。這種處理方案固然提升了系統的可靠性，但也存在一些問題：面對大數據量和大量的數據庫查詢懇求，只能采取縱向提升效力器檔次的方法，而縱向提升的本錢遠遠高于橫向擴展。 在熱備時，數據庫效力器只需一臺在任務，另一臺處于閑置備份的形狀，呵斥了投資的浪費。 非實時切換。而數據庫 HYPERLINK product.it168/files/0409search.shtml路由器

12、 HYPERLINK software.it168/軟件ICX的出現，為基于MS SQL Server的數據庫系統提供了一種更優(yōu)秀的集群處理方案。它可以真正的實現SQL Server數據庫效力器的動態(tài)負載平衡，提高性能和速度；它可以真正的保證SQL Server數據庫效力器不延續(xù)的提供效力，在效力器發(fā)生缺點的時候實時切換到其他效力器上繼續(xù)提供效力，切換時間為“零。數據庫路由器是實時并發(fā)數據庫事務處置同步復制器和負載平衡器。數據庫路由器-ICX意思是：I SEE X DATABASE SERVERS，也就是說，在ICX后面可以同時銜接N個數據庫，構造如以下圖所示：1一切的數據庫客戶都經過ICX訪

13、問數據庫。當訪問、查詢SQL Server數據庫的時候ICX可以根據實踐情況分配效力器來提供效力，大大提高效力速度和優(yōu)化性能，完成負載平衡。2ICX可以同時銜接多臺數據庫2-16臺，詳細連多少臺，看客戶的詳細需求而定，這假設干臺數據庫的內容在任何時辰由ICX保證是完全一致的。也就是說，ICX采用了全新的并發(fā)事務處置的方式，向銜接的N臺數據庫同步復制事務處置，使得系統在任何時辰具有多個一致的最新邏輯數據庫數據集。當其中一臺數據庫效力器發(fā)生缺點的時候，ICX可以實時的、第一時間切換到其他效力器上來繼續(xù)提供效力。真正的實現零時間的效力器切換，大大提高平安性，真正意義的實現效力器不延續(xù)服網站大流量壓力

14、 如何進展系統應對？ 當一個企業(yè)的網站訪問量越來越大時，當一個博客開展為知名博客的時候，博客的訪問量通常都會非常大，運用運用虛擬主機的話，個人博客由于訪問量過大經常會而引起url=server.ctocio/效力器/url性能問題，這是很多人的煩惱，有人運用取消url=whatis.ctocio/searchwhatis/251/6093751.shtmlRSS/url等錯誤的方法來處理問題，顯然是下錯藥，那么對于網站大流量帶來的問題，正確的處理方法應該是什么呢?下面是我個人總結的一些閱歷，供大家參考。第一步：確認效力器硬件才干普通的url=whatis.ctocio/searchwhatis

15、/383/6025883.shtmlP4/url效力器普通最多能支持每天10萬獨立url=whatis.ctocio/searchwhatis/191/6025691.shtmlIP/url，假設訪問量比這個還要大，那么必需首先配置一臺更高性能的公用效力器才干處理問題，否那么怎樣優(yōu)化都不能夠徹底處理性能問題。第二步：優(yōu)化url=database.ctocio/數據庫/url訪問效力器的負載過大，一個重要的緣由是url=whatis.ctocio/searchwhatis/461/5947461.shtmlCPU/url負荷過大，降低效力器CPU的負荷，才可以有效突破url=whatis.cto

16、cio/searchwhatis/146/7475146.shtml瓶頸/url。而運用靜態(tài)頁面可以使得CPU的負荷最小化。前臺實現完全的靜態(tài)化當然最好，可以完全不用訪問數據庫，不過對于頻繁更新的網站，靜態(tài)化往往不能滿足某些功能。緩存技術就是另一個處理方案，就是將動態(tài)數據url=storage.ctocio/存儲/url到緩存文件中，動態(tài)網頁直接調用這些文件，而不用再訪問數據庫，WordPress和Z-url=whatis.ctocio/searchwhatis/366/5946866.shtmlBlog/url都大量運用這種緩存技術。我本人也寫過一個Z-Blog的計數器插件，也是基于這樣的原

17、理。假設確實無法防止對數據庫的訪問，那么可以嘗試優(yōu)化數據庫的查詢SQL.防止運用Select * from這樣的語句，每次查詢只前往本人需求的結果，防止短時間內的大量SQL查詢。第三，制止外部的盜鏈。外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴厲限制外部對于本身的圖片或者文件盜鏈，好在目前可以簡單地經過refer來控制盜鏈，url=whatis.ctocio/searchwhatis/299/6025299.shtmlApache/url本人就可以經過配置來制止盜鏈，url=whatis.ctocio/searchwhatis/452/6025452.shtmlIIS/url

18、也有一些第三方的url=whatis.ctocio/searchwhatis/229/6025729.shtmlISAPI/url可以實現同樣的功能。當然，偽造refer也可以經過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去思索，或者運用非技術手段來處理，比如在圖片上添加水印。第四，控制大文件的下載。大文件的下載會占用很大的流量，并且對于非url=whatis.ctocio/searchwhatis/427/5948927.shtmlSCSI/url硬盤來說，大量文件下載會耗費CPU，使得網站呼應才干下降。因此，盡量不要提供超越2M的大文件下載，假設需求提供，建議將大文件放在另外一臺效力器上。目前有不少免費的url=whatis.ctocio/searchwhatis/445/7372445.shtmlWeb 2.0/url網站提供圖片分享和文件分享功能，因此可以盡量將圖片和文件上傳到這些分享網站。第五，運用不同主機分流主要流量將文件放在不同的主機上，提供不同的鏡像供用戶下載。比如假設覺得RSS文件占用流量大，那么運用FeedBurner或者FeedSky等