服務(wù)器高并發(fā)解決方案

【關(guān)鍵字】解決服務(wù)器高并發(fā)解決方案篇一：JAVAWEB高并發(fā)解決方案java處理高并發(fā)高負(fù)載類網(wǎng)站中數(shù)據(jù)庫的設(shè)計(jì)方法（java教程,java處理大量數(shù)據(jù)，java高負(fù)載數(shù)據(jù)）一：高并發(fā)高負(fù)載類網(wǎng)站關(guān)注點(diǎn)之?dāng)?shù)據(jù)庫沒錯(cuò),首先是數(shù)據(jù)庫,這是大多數(shù)應(yīng)用所面臨的首個(gè)SPOF。尤其是的應(yīng)用，數(shù)據(jù)庫的響應(yīng)是首先要解決的。一般來說MySQL是最常用的，可能最初是一個(gè)mysql主機(jī),當(dāng)數(shù)據(jù)增加到100萬以上，那么，MySQL的效能急劇下降。常用的優(yōu)化措施是M-S（主-從）方式進(jìn)行同步復(fù)制，將查詢和操作和分別在不同的服務(wù)器上進(jìn)行操作。我推薦的是M-M-Slaves方式，2個(gè)主Mysql,多個(gè)Slaves，需要注意的是，雖然有2個(gè)Master,但是同時(shí)只有1個(gè)是Active，我們可以在一定時(shí)候切換。之所以用2個(gè)M,是保證M不會又成為系統(tǒng)的SPOF。Slaves可以進(jìn)一步負(fù)載均衡，可以結(jié)合LVS,從而將select操作適當(dāng)?shù)钠胶獾讲煌膕laves上。以上架構(gòu)可以抗衡到一定量的負(fù)載，但是隨著用戶進(jìn)一步增加，你的用戶表數(shù)據(jù)超過1千萬，這時(shí)那個(gè)M變成了SPOF。你不能任意擴(kuò)充Slaves，否則復(fù)制同步的開銷將直線上升，怎么辦？我的方法是表分區(qū)，從業(yè)務(wù)層面上進(jìn)行分區(qū)。最簡單的，以用戶數(shù)據(jù)為例。根據(jù)一定的切分方式，比如id,切分到不同的數(shù)據(jù)庫集群去。全局?jǐn)?shù)據(jù)庫用于meta數(shù)據(jù)的查詢。缺點(diǎn)是每次查詢，會增加一次，比如你要查一個(gè)用戶nightsailer你首先要到全局?jǐn)?shù)據(jù)庫群找到nightsailer對應(yīng)的clusterid,然后再到指定的cluster找到nightsailer的實(shí)際數(shù)據(jù)。每個(gè)cluster可以用m-m方式，或者m-m-slaves方式。這是一個(gè)可以擴(kuò)展的結(jié)構(gòu)，隨著負(fù)載的增加，你可以簡單的增加新的mysqlcluster進(jìn)去。需要注意的是：1、 禁用全部auto_increment的字段2、 id需要采用通用的算法集中分配3、 要具有比較好的方法來監(jiān)控mysql主機(jī)的負(fù)載和服務(wù)的運(yùn)行狀態(tài)。如果你有30臺以上的mysql數(shù)據(jù)庫在跑就明白我的意思了。4、不要使用持久性鏈接（不要用pconnect），相反，使用sqlrelay這種第三方的數(shù)據(jù)庫鏈接池，或者干脆自己做，因?yàn)閜hp4中mysql的鏈接池經(jīng)常出問題。二：高并發(fā)高負(fù)載網(wǎng)站的系統(tǒng)架構(gòu)之HTML靜態(tài)化其實(shí)大家都知道，效率最高、消耗最小的就是純靜態(tài)化/shtml/XX07/的html頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實(shí)現(xiàn)，這個(gè)最簡單的方法其實(shí)也是最有效的方法。但是對于大量內(nèi)容并且頻繁革新的網(wǎng)站，我們無法全部手動(dòng)去挨個(gè)實(shí)現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS,像我們常訪問的各個(gè)門戶站點(diǎn)的新聞?lì)l道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實(shí)現(xiàn)的，1文檔來源為:從網(wǎng)絡(luò)收集整理.word版本可編輯.歡迎下載支持.信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡單的信息錄入自動(dòng)生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動(dòng)抓取等功能，對于一個(gè)大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化，有革新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。同時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數(shù)據(jù)庫查詢但是內(nèi)容革新很小的應(yīng)用，可以考慮使用html靜態(tài)化來實(shí)現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實(shí)大量被前臺程序調(diào)用，但是革新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺革新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求高并發(fā)。網(wǎng)站HTML靜態(tài)化解決方案當(dāng)一個(gè)Servlet資源請求到達(dá)WEB服務(wù)器之后我們會填充指定的JSP頁面來響應(yīng)請求：HTTP請求Web服務(wù)器Servlet--業(yè)務(wù)邏輯處理--訪問數(shù)據(jù)--填充JSP--響應(yīng)請求HTML靜態(tài)化之后:HTTP請求Web服務(wù)器Servlet--HTML--響應(yīng)請求靜態(tài)訪求如下Servlet:publicvoiddoGet(HttpServletRequestrequest,HttpServletResponseresponse)throwsServletException,IOException{if(("chapterId")!=null){StringchapterFileName="bookChapterRead_"+("chapterId")+".html";StringchapterFilePath=getServletContext().getRealPath("/")+chapterFileName;FilechapterFile=newFile(chapterFilePath);if(()){(chapterFileName);return;}〃如果有這個(gè)文件就告訴瀏覽器轉(zhuǎn)向INovelChapterBiznovelChapterBiz=newNovelChapterBizImpl();NovelChapternovelChapter=((("chapterld")));//章節(jié)信息intlastPageId=(().getld(),());intnextPageld=(().getld(),());("novelChapter",novelChapter);("lastPageld",lastPageld);("nextPageld",nextPageld);2文檔來源為:從網(wǎng)絡(luò)收集整理.word版本可編輯.歡迎下載支持.newCreateStaticHTMLPage().createStaticHTMLPage(request,response,getServletContext(),chapterFileName,chapterFilePath,"/");}}生成HTML靜態(tài)頁面的類:package;import;import;import;import;import;import;import;import;import;import;import;import;/***創(chuàng)建HTML靜態(tài)頁面*功能：創(chuàng)建HTML靜態(tài)頁面*時(shí)間：XX年1011日地點(diǎn)：home@authormavk**/publicclassCreateStaticHTMLPage{/***生成靜態(tài)HTML頁面的方法@paramrequest請求對象*@paramresponse響應(yīng)對象@paramservletContextServlet上下文@paramfileName文件名稱@paramfileFullPath文件完整路徑@paramjspPath需要生成靜態(tài)文件的JSP路徑(相對即可)@throwsIOException@throwsServletException*/3文檔來源為:從網(wǎng)絡(luò)收集整理.word版本可編輯.歡迎下載支持.publicvoidcreateStaticHTMLPage(HttpServletRequestrequest,HttpServletResponseresponse,ServletContextservletContext,StringfileName,StringfileFullPath,StringjspPath)throwsServletException,IOException{("text/html;charset=gb2312");//^置HTML結(jié)果流編碼(即HTML文件編碼)RequestDispatcherrd=(jspPath);//得到JSP資源finalByteArrayOutputStreambyteArrayOutputStream=newByteArrayOutputStream();//用于從ServletOutputStream中接收資源finalServletOutputStreamservletOuputStream=newServletOutputStream(){//用于從HttpServletResponse中接收資源publicvoidwrite(byte[]b,intoff,intlen){(b,off,len);}publicvoidwrite(intb){(b);}};finalPrintWriterprintWriter=newPrintWriter(newOutputStreamWriter(byteArrayOutputStream));//把轉(zhuǎn)換字節(jié)流轉(zhuǎn)換成字符流HttpServletResponsehttpServletResponse=newHttpServletResponseWrapper(response){//用于從response獲取結(jié)果流資源(重寫了兩個(gè)方法)publicServletOutputStreamgetOutputStream(){篇二：高并發(fā)網(wǎng)站架構(gòu)解決方案一個(gè)小型的網(wǎng)站，比如個(gè)人網(wǎng)站，可以使用最簡單的html靜態(tài)頁面就實(shí)現(xiàn)了，配合一些圖片達(dá)到美化效果，所有的頁面均存放在一個(gè)目錄下，這樣的網(wǎng)站對系統(tǒng)架構(gòu)、性能的要求都很簡單，隨著互聯(lián)網(wǎng)業(yè)務(wù)的不斷豐富，網(wǎng)站相關(guān)的技術(shù)經(jīng)過這些年的發(fā)展，已經(jīng)細(xì)分到很細(xì)的方方面面，尤其對于大型網(wǎng)站來說，所采用的技術(shù)更是涉及面非常廣，從硬件到軟件、編程語言、數(shù)據(jù)庫、WebServer、防火墻等各個(gè)領(lǐng)域都有了很高的要求，已經(jīng)不是原來簡單的html靜態(tài)網(wǎng)站所能比擬的。大型網(wǎng)站，比如門戶網(wǎng)站。在面對大量用戶訪問、高并發(fā)請求方面，基本的解決方案集中在這樣幾個(gè)環(huán)節(jié)：使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫、高效率的編程語言、還有高性能的Web容器。但是除了這幾個(gè)方面，還沒法根本解決大型網(wǎng)站面臨的高負(fù)載和高并發(fā)問題。上面提供的幾個(gè)解決思路在一定程度上也意味著更大的投入，并且這樣的解決思路具備瓶頸，沒有很好的擴(kuò)展性，下面我從低成本、高性能和高擴(kuò)張性的角度來說說我的一些經(jīng)驗(yàn)。1、 HTML靜態(tài)化4文檔來源為:從網(wǎng)絡(luò)收集整理.word版本可編輯.歡迎下載支持.其實(shí)大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實(shí)現(xiàn)，這個(gè)最簡單的方法其實(shí)也是最有效的方法。但是對于大量內(nèi)容并且頻繁革新的網(wǎng)站，我們無法全部手動(dòng)去挨個(gè)實(shí)現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS,像我們常訪問的各個(gè)門戶站點(diǎn)的新聞?lì)l道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實(shí)現(xiàn)的，信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡單的信息錄入自動(dòng)生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動(dòng)抓取等功能，對于一個(gè)大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化，有革新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。同時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數(shù)據(jù)庫查詢但是內(nèi)容革新很小的應(yīng)用，可以考慮使用html靜態(tài)化來實(shí)現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實(shí)大量被前臺程序調(diào)用，但是革新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺革新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求。一下是一個(gè)SSH下的html靜態(tài)化例子用Article表來演示下頁面靜態(tài)化，在此做記錄，便于今后參考。這里是基于SSH2架構(gòu)來演示的。1.演示工程整體結(jié)構(gòu)概覽這里我引入了htdz_lib這么個(gè)UserLibraliry,包含了SSH2整合所需的jar以及。同時(shí)也已創(chuàng)建于WEB-INF下。表預(yù)覽我們給Article表增加個(gè)HadStatic字段，用以標(biāo)識此文章是否已靜態(tài)化。我們不建議添加一篇文章就直接生成對應(yīng)的靜態(tài)頁面，如果都沒有用戶來閱讀，服務(wù)器就徒增了大量html文件，浪費(fèi)資源。所以我們一般采用訪問生成策略：用戶訪問某文章，判斷服務(wù)器是否存在此文章對應(yīng)的靜態(tài)頁，存在則直接重定向到此靜態(tài)頁面，不存在則執(zhí)行靜態(tài)化，然后再重定向到生成的靜態(tài)頁。然而每次通過10去查找文件是否存在，耗費(fèi)性能，所以像Article這類表加個(gè)HadStatic字段，直接判斷字段的值來決定是否靜態(tài)化顯得合理多了。配置1.2.contextConfigLocation4.classpath:conf/spring/6.7.

7. struts9.40.UrlRewriteFilter41. struts2/*REQUESTFORWARDINCLUDEUrlRewriteFilterlogLevelWARNUrlRewriteFilterlogLevelWARNUrlRewriteFilter/*其它你懂的，就是修改了struts2的過濾器的，增加了幾個(gè)，WHY?后面會講到。另外再加了個(gè)urlrewrite的過濾器。配置1.2.3.其他dataSource、sessionFactory、事務(wù)等配置，不是本帖的重點(diǎn)，略去了。這里我在中用了default-autowire="byName"讓spring自動(dòng)裝配依賴的bean了。下面貼上各層的代碼以下是再是及篇三：高并發(fā)數(shù)據(jù)庫解決方案高并發(fā)高負(fù)載數(shù)據(jù)庫架構(gòu)策略在WEB網(wǎng)站的規(guī)模從小到大不斷擴(kuò)展的過程中，數(shù)據(jù)庫的訪問壓力也不斷的增加，數(shù)據(jù)庫的架構(gòu)也需要?jiǎng)討B(tài)擴(kuò)展，在數(shù)據(jù)庫的擴(kuò)展過程基本上包含如下幾步，每一個(gè)擴(kuò)展都可以比上一步驟的部署方式的性能得到數(shù)量級的提升。WEB應(yīng)用和數(shù)據(jù)庫部署在同一臺服務(wù)器上一般的小規(guī)模的網(wǎng)站采用這種方式，用戶量、數(shù)據(jù)量、并發(fā)訪問量都比較小，否則單臺服務(wù)器無法承受，并且在遇到性能瓶頸的時(shí)候升級硬件所需要的費(fèi)用非常高昂，在訪問量增加的時(shí)候，應(yīng)用程序和數(shù)據(jù)庫都來搶占有限的系統(tǒng)資源，很快就又會遇到性能問題。WEB應(yīng)用和數(shù)據(jù)庫部署在各自獨(dú)立的服務(wù)器上web應(yīng)用和數(shù)據(jù)庫分開部署，WEB應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器各司其職，在系統(tǒng)訪問量增加的時(shí)候可以分別升級應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，這種部署方式是一般小規(guī)模網(wǎng)站的典型部署方式。在將應(yīng)用程序進(jìn)行性能優(yōu)化并且使用數(shù)據(jù)庫對象緩存策略的情況下，可以承載較大的訪問量，比如XX用戶，200個(gè)并發(fā)，百萬級別的數(shù)據(jù)量。數(shù)據(jù)庫服務(wù)器采用集群方式部署（比如Oracle的一個(gè)數(shù)據(jù)庫多個(gè)實(shí)例的情況）數(shù)據(jù)庫集群方式能承擔(dān)的負(fù)載是比較大的，數(shù)據(jù)庫物理介質(zhì)為一個(gè)磁盤陣列，多個(gè)數(shù)據(jù)庫實(shí)例以虛擬IP方式向外部應(yīng)用服務(wù)器提供數(shù)據(jù)庫連接服務(wù)。這種部署方式基本上可以滿足絕大多數(shù)的常見WEB應(yīng)用，但是還是不能滿足大用戶量、高負(fù)載、數(shù)據(jù)庫讀寫訪問非常頻繁的應(yīng)用。數(shù)據(jù)庫采用主從部署方式在面向大眾用戶的博客、論談、交友、CMS等系統(tǒng)中，有上百萬的用戶，有上千萬的數(shù)據(jù)量，存在眾多的數(shù)據(jù)庫查詢操作，也有較多的數(shù)據(jù)庫寫操作，并且在多數(shù)情況下都是讀操作遠(yuǎn)大于寫操作的。在這個(gè)時(shí)候，假如能將數(shù)據(jù)庫的讀寫操作分離的話，對于系統(tǒng)來講是一個(gè)很大的提高啦。數(shù)據(jù)庫的主從部署方式就走到我們面前啦。主從復(fù)制：幾乎所有的主流數(shù)據(jù)庫都支持復(fù)制，這是進(jìn)行數(shù)據(jù)庫簡單擴(kuò)展的基本手段。下面以Mysql為例來說明，它支持主從復(fù)制，配置也并不復(fù)雜，只需要開啟主服務(wù)器上的二進(jìn)制日志以及在主服務(wù)器和從服務(wù)器上分別進(jìn)行簡單的配置和授權(quán)。Mysql的主從復(fù)制是一句主服務(wù)器的二進(jìn)制日志文件進(jìn)行的，主服務(wù)器日志中記錄的操作會在從服務(wù)器上重放，從而實(shí)現(xiàn)復(fù)制，所以主服務(wù)器必須開啟二進(jìn)制日志，自動(dòng)記錄所有對于主數(shù)據(jù)庫的革新操作，從服務(wù)器再定時(shí)到主服務(wù)器取得二進(jìn)制日志文件進(jìn)行重放則完成了數(shù)據(jù)的復(fù)制。主從復(fù)制也用于自動(dòng)備份。讀寫分離：為保證數(shù)據(jù)庫數(shù)據(jù)的一致性，我們要求所有對于數(shù)據(jù)庫的革新操作都是針對主數(shù)據(jù)庫的，但是讀操作是可以針對從數(shù)據(jù)庫來進(jìn)行。大多數(shù)站點(diǎn)的數(shù)據(jù)庫讀操作比寫操作更加密集，而且查詢條件相對復(fù)雜，數(shù)據(jù)庫的大部分性能消耗在查詢操作上了。主從復(fù)制數(shù)據(jù)是異步完成的，這就導(dǎo)致主從數(shù)據(jù)庫中的數(shù)據(jù)有一定的延遲，在讀寫分離的設(shè)計(jì)中必須要考慮這一點(diǎn)。以博客為例，用戶登錄后發(fā)表了一篇文章，他需要馬上看到自己的文章，但是對于其它用戶來講可以允許延遲一段時(shí)間（1分鐘/5分鐘/30分鐘），不會造成什么問題。這時(shí)對于當(dāng)前用戶就需要讀主數(shù)據(jù)庫，對于其他訪問量更大的外部用戶就可以讀從數(shù)據(jù)庫。數(shù)據(jù)庫反向代理：在讀寫分離的方式使用主從部署方式的數(shù)據(jù)庫的時(shí)候，會遇到一個(gè)問題，一個(gè)主數(shù)據(jù)庫對應(yīng)多臺從服務(wù)器，對于寫操作是針對主數(shù)據(jù)庫的，數(shù)據(jù)庫個(gè)數(shù)是唯一的，但是對于從服務(wù)器的讀操作就需要使用適當(dāng)?shù)乃惴▉矸峙湔埱罄?，尤其對于多個(gè)從服務(wù)器的配置不一樣的時(shí)候甚至需要讀操作按照權(quán)重來分配。對于上述問題可以使用數(shù)據(jù)庫方向代理來實(shí)現(xiàn)。就像WEB方向代理服務(wù)器一樣，MYsqlProxy同樣可以在SQL語句轉(zhuǎn)發(fā)到后端的Mysql服務(wù)器之前對它進(jìn)行修改。數(shù)據(jù)庫垂直分割主從部署數(shù)據(jù)庫中，當(dāng)寫操作占了主數(shù)據(jù)庫的CPU消耗的50%以上的時(shí)候，我們再增加從服務(wù)器的意義就不是很大了，因?yàn)樗械膹姆?wù)器的寫操作也將占到CPU消耗的50%以上，一臺從服務(wù)器提供出來查詢的資源非常有限。數(shù)據(jù)庫就需要重新架構(gòu)了，我們需要采用數(shù)據(jù)庫垂直分區(qū)技術(shù)啦。最簡單的垂直分區(qū)方式是將原來的數(shù)據(jù)庫中獨(dú)立的業(yè)務(wù)進(jìn)行分拆（被分拆出來的部分與其它部分不需要進(jìn)行Join連接查詢操作），比如WEB站點(diǎn)的BLOG和論壇，是相對獨(dú)立的，與其它的數(shù)據(jù)的關(guān)聯(lián)性不是很強(qiáng)，這時(shí)可以將原來的數(shù)據(jù)庫拆分為一個(gè)BLog庫，一個(gè)論壇庫，以及剩余的表所組成的庫。這三個(gè)庫再各自進(jìn)行主從數(shù)據(jù)庫方式部署，這樣整個(gè)數(shù)據(jù)庫的壓力就分擔(dān)啦。另外查詢擴(kuò)展性也是采用數(shù)據(jù)庫分區(qū)最主要的原因之一。將一個(gè)大的數(shù)據(jù)庫分成多個(gè)小的數(shù)據(jù)庫可以提高查詢的性能，因?yàn)槊總€(gè)數(shù)據(jù)庫分區(qū)擁有自己的一小部分?jǐn)?shù)據(jù)。假設(shè)您想掃描1億條記錄，對一個(gè)單一分區(qū)的數(shù)據(jù)庫來講，該掃描操作需要數(shù)據(jù)庫管理器獨(dú)立掃描一億條記錄，如果您將數(shù)據(jù)庫系統(tǒng)做成50個(gè)分區(qū)，并將這1億條記錄平均分配到這50個(gè)分區(qū)上，那么每個(gè)數(shù)據(jù)庫分區(qū)的數(shù)據(jù)庫管理器將只掃描200萬記錄。數(shù)據(jù)庫水平分割在數(shù)據(jù)庫的垂直分區(qū)之后，假如我們的BLOG庫又再次無法承擔(dān)寫操作的時(shí)候，我們又該怎么辦呢？數(shù)據(jù)庫垂直分區(qū)這種擴(kuò)展方式又無能為力了，我們需要的是水平分區(qū)。水平分區(qū)意味著我們可以將同一個(gè)數(shù)據(jù)庫表中的記錄通過特定的算法進(jìn)行分離，分別保存在不同的數(shù)據(jù)庫表中，從而可以部署在不同的數(shù)據(jù)庫服務(wù)器上。很多的大規(guī)模的站點(diǎn)基本上都是主從復(fù)制+垂直分區(qū)+水平分區(qū)這樣的架構(gòu)。水平分區(qū)并不依賴什么特定的技術(shù)，完全是邏輯層面的規(guī)劃，需要的是經(jīng)驗(yàn)和業(yè)務(wù)的細(xì)分。如何分區(qū)呢？對于大型的WEB站點(diǎn)來說，必須分區(qū)，并且對于分區(qū)我們沒有選擇的余地，對于那些頻繁訪問導(dǎo)致站點(diǎn)接近崩潰的熱點(diǎn)數(shù)據(jù)，我們必須分區(qū)。在對數(shù)據(jù)分區(qū)的時(shí)候，我們必須要存在一個(gè)分區(qū)索引字段，比如USER」D，它必須和所有的記錄都存在關(guān)系，是分區(qū)數(shù)據(jù)庫中的核心表的主鍵，在其它表中作為外鍵，并且在使用主鍵的時(shí)候，該主鍵不能是自增長的，必須是業(yè)務(wù)主鍵才可以。余數(shù)分區(qū)：我們可以將User」D%10后的值為依據(jù)存入到不同的分區(qū)數(shù)據(jù)庫中，該算法簡單高效，但是在分區(qū)數(shù)據(jù)庫個(gè)數(shù)有變動(dòng)的時(shí)候，整個(gè)系統(tǒng)的數(shù)據(jù)需要重新分布。范圍分區(qū)：我們可以將User_ID的范圍進(jìn)行分區(qū)，比如1-100000范圍為一個(gè)分區(qū)數(shù)據(jù)庫，100001-XX00范圍為一個(gè)分區(qū)數(shù)據(jù)庫，該算法在分區(qū)數(shù)據(jù)庫個(gè)數(shù)有變動(dòng)的時(shí)候，系統(tǒng)非常有利于擴(kuò)展，但是容易導(dǎo)致不同分區(qū)之間的壓力不同，比如老用戶所在的分區(qū)數(shù)據(jù)庫的壓力很大，但是新用戶的分區(qū)數(shù)據(jù)庫的壓力偏小。映射關(guān)系分區(qū)：將對分區(qū)索引字段的每個(gè)可能的結(jié)果創(chuàng)建一個(gè)分區(qū)映射關(guān)系，這個(gè)映射關(guān)系非常龐大，需要將它們寫入數(shù)據(jù)庫中。比如當(dāng)應(yīng)用程序需要知道User_id為10的用戶的BLOG內(nèi)容在那個(gè)分區(qū)時(shí)，它必須查詢數(shù)據(jù)庫獲取答案，當(dāng)然，我們可以使用緩存來提高性能。這種方式詳細(xì)保存了每一個(gè)記錄的分區(qū)對應(yīng)關(guān)系，所以各個(gè)分區(qū)有非常強(qiáng)的可伸縮性，可以靈活的控制，并且將數(shù)據(jù)庫從一個(gè)分區(qū)遷移到另一個(gè)分區(qū)也很簡單，也可以使各個(gè)分區(qū)通過靈活的動(dòng)態(tài)調(diào)節(jié)來保持壓力的分布平衡。大數(shù)據(jù)量高并發(fā)的數(shù)據(jù)庫優(yōu)化發(fā)表日期：XX-01-19一、數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計(jì)如果不能設(shè)計(jì)一個(gè)合理的數(shù)據(jù)庫模型，不僅會增加客戶端和服務(wù)器段程序的編程和維護(hù)的難度，而且將會影響系統(tǒng)實(shí)際運(yùn)行的性能。所以，在一個(gè)系統(tǒng)開始實(shí)施之前，完備的數(shù)據(jù)庫模型的設(shè)計(jì)是必須的。在一個(gè)系統(tǒng)分析、設(shè)計(jì)階段，因?yàn)閿?shù)據(jù)量較小，負(fù)荷較低。我們往往只注意到功能的實(shí)現(xiàn)，而很難注意到性能的薄弱之處，等到系統(tǒng)投入實(shí)際運(yùn)行一段時(shí)間后，才發(fā)現(xiàn)系統(tǒng)的性能在降低，這時(shí)再來考慮提高系統(tǒng)性能則要花費(fèi)更多的人力物力，而整個(gè)系統(tǒng)也不可避免的形成了一個(gè)打補(bǔ)丁工程。所以在考慮整個(gè)系統(tǒng)的流程的時(shí)候，我們必須要考慮，在高并發(fā)大數(shù)據(jù)量的訪問情況下，我們的系統(tǒng)會不會出現(xiàn)極端的情況。（例如：對外統(tǒng)計(jì)系統(tǒng)在7月16日出現(xiàn)的數(shù)據(jù)異常的情況，并發(fā)大數(shù)據(jù)量的的訪問造成，數(shù)據(jù)庫的響應(yīng)時(shí)間不能跟上數(shù)據(jù)刷新的速度造成。具體情況是：在日期臨界時(shí)（00：00：00），判斷數(shù)據(jù)庫中是否有當(dāng)前日期的記錄，沒有則插入一條當(dāng)前日期的記錄。在低并發(fā)訪問的情況下，不會發(fā)生問題，但是當(dāng)日期臨界時(shí)的訪問量相當(dāng)大的時(shí)候，在做這一判斷的時(shí)候，會出現(xiàn)多次條件成立，則數(shù)據(jù)庫里會被插入多條當(dāng)前日期的記錄，從而造成數(shù)據(jù)錯(cuò)誤。），數(shù)據(jù)庫的模型確定下來之后，我們有必要做一個(gè)系統(tǒng)內(nèi)數(shù)據(jù)流向圖，分析可能出現(xiàn)的瓶頸。為了保證數(shù)據(jù)庫的一致性和完整性，在邏輯設(shè)計(jì)的時(shí)候往往會設(shè)計(jì)過多的表間關(guān)聯(lián)，盡可能的降低數(shù)據(jù)的冗余（。例如用戶表的地區(qū)，我們可以把地區(qū)另外存放到一個(gè)地區(qū)表中）如果數(shù)據(jù)冗余低，數(shù)據(jù)的完整性容易得到保證，提高了數(shù)據(jù)吞吐速度，保證了數(shù)據(jù)的完整性，清楚地表達(dá)數(shù)據(jù)元素之間的關(guān)系。而對于多表之間的關(guān)聯(lián)查詢（尤其是大數(shù)據(jù)表）時(shí)，其性能將會降低，同時(shí)也提高了客戶端程序的編程難度，因此，物理設(shè)計(jì)需折衷考慮，根據(jù)業(yè)務(wù)規(guī)則，確定對關(guān)聯(lián)表的數(shù)據(jù)量大小、數(shù)據(jù)項(xiàng)的訪問頻度，對此類數(shù)據(jù)表頻繁的關(guān)聯(lián)查詢應(yīng)適

當(dāng)提高數(shù)據(jù)冗余設(shè)計(jì)但增加了表間連接查詢的操作，也使得程序的變得復(fù)雜，為了提高系統(tǒng)的響應(yīng)時(shí)間，合理的數(shù)據(jù)冗余也是必要的。設(shè)計(jì)人員在設(shè)計(jì)階段應(yīng)根據(jù)系統(tǒng)操作的類型、頻度加以均衡考慮。另外，最好不要用自增屬性字段作為主鍵與子表關(guān)聯(lián)。不便于系統(tǒng)的遷移和數(shù)據(jù)恢復(fù)對外統(tǒng)計(jì)系統(tǒng)映射關(guān)系丟失（）。對外統(tǒng)計(jì)系統(tǒng)映射關(guān)系丟失（）。原來的表格必須可以通過由它分離出去的表格重新構(gòu)建。使用這個(gè)規(guī)定的好處是，你可以確保不會在分離的表格中引入多余的列，所有你創(chuàng)建的表格結(jié)構(gòu)都與它們的實(shí)際需要一樣大。應(yīng)用這條規(guī)定是一個(gè)好習(xí)慣，不過除非你要處理一個(gè)非常大型的數(shù)據(jù)，否則你將不需要用到它。（例如一個(gè)通行證系統(tǒng)，我可以將USERID，USERNAME，USERPASSWORD,單獨(dú)出來作個(gè)表，再把USERID作為其他表的外鍵）表的設(shè)計(jì)具體注意的問題：1、數(shù)據(jù)行的長度不要超過8020字節(jié)，如果超過這個(gè)長度的話在物理頁中這條數(shù)據(jù)會占用兩行從而造成存儲碎片，降低查詢效率。2、能夠用數(shù)字類型的字段盡量選擇數(shù)字類型而不用字符串類型的（電話號碼），這會降低查詢和連接的性能，并會增加存儲開銷。這是因?yàn)橐嬖谔幚聿樵兒瓦B接回逐個(gè)比較字符串中每一個(gè)字符，而對于數(shù)字型而言只需要比較一次就夠了。3、對于不可變字符類型char和可變字符類型varchar都是8000字節(jié),char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節(jié)省存儲空間。在設(shè)計(jì)字段的時(shí)候可以靈活選擇，例如用戶名、密碼等長度變化不大的字段可以選擇CHAR，對于評論等長度變化大的字段可以選擇VARCHAR。4、字段的長度在最大限度的滿足可能的需要的前提下，應(yīng)該盡可能的設(shè)得短一些，這樣可以提高查詢的效率，而且在建立索引的時(shí)候也可以減少資源的消耗。二、查詢的優(yōu)化保證在實(shí)現(xiàn)功能的基礎(chǔ)上，盡量減少對數(shù)據(jù)庫的訪問次數(shù)；通過搜索參數(shù)，盡量減少對表的訪問行數(shù),最小化結(jié)果集，從而減輕網(wǎng)絡(luò)負(fù)擔(dān)；能夠分開的操作盡量分開處理，提高每次的響應(yīng)速度；在數(shù)據(jù)窗口使用SQL時(shí)，盡量把使用的索引放在選擇的首列；算法的結(jié)構(gòu)盡量簡單；在查詢時(shí)，不要過多地使用通配符如SELECT*FROMT1語句，要用到幾列就選擇幾列如：SELECTC0L1,C0L2FROMT1；在可能的情況下盡量限制盡量結(jié)果集行數(shù)如：SELECTTOP300COL1,COL2,COL3FROMT1,因?yàn)槟承┣闆r下用戶是不需要那么多的數(shù)據(jù)的。在沒有建索引的情況下，數(shù)據(jù)庫查找某一條數(shù)據(jù)，就必須進(jìn)行全表掃描了，對所有數(shù)據(jù)進(jìn)行一次遍歷，查找出符合條件的記錄。在數(shù)據(jù)量比較小的情況下，也許看不出明顯的差別，但是當(dāng)數(shù)據(jù)量大的情況下，這種情況就是極為糟糕的了。SQL語句在SQLSERVER中是如何執(zhí)行的，他們擔(dān)心自己所寫的SQL語句會被SQLSERVER誤解。比如：select*fromtable1wherename='zhangsan'andtID>10000和執(zhí)行:select*fromtable1wheretID>10000andname='zhangsan'一些人不知道以上兩條語句的執(zhí)行效率是否一樣，因?yàn)槿绻唵蔚膹恼Z句先后上看，這兩個(gè)語句的確是不一樣，如果tID是一個(gè)聚合索引，那么后一句僅僅從表的10000條以后的記錄中查找就行了；而前一句則要先從全表中查找看有幾個(gè)name='zhangsan'的，而后再文檔來源為:從網(wǎng)絡(luò)收集整理.word版本可編輯.歡迎下載支持.根據(jù)限制條件條件tlD＞10000來提出查詢結(jié)果。事實(shí)上，這樣的擔(dān)心是不必要的。SQLSERVER中有一個(gè)"查詢分析優(yōu)化器”，它可以計(jì)算出where子句中的搜索條件并確定哪個(gè)索引能縮小表掃描的搜索空間，也就是說，它能