首頁  >  文章  >  Java  >  關於Java中關於高並發解決方案以及高負載優化的實例講解

關於Java中關於高並發解決方案以及高負載優化的實例講解

黄舟
黄舟原創
2017-07-27 10:51:141280瀏覽

 一個小型的網站,例如個人網站,可以使用最簡單的html靜態頁面就實現了,配合一些圖片達到美化效果,所有的頁面均存放在一個目錄下,這樣的網站對系統架構、性能的要求都很簡單,隨著網路事業的不斷豐富,網站相關的技術經過這些年的發展,已經細分到很細的方方面面,尤其對於大型網站來說,所採用的技術更是涉及面非常廣,從硬體到軟體、程式語言、資料庫、WebServer、防火牆等各個領域都有了很高的要求,已經不是原來簡單的html靜態網站所能比擬的。

大型網站,例如入口網站。在面對大量使用者存取、高並發請求方面,基本的解決方案集中在這樣幾個環節:使用高效能的伺服器、高效能的資料庫、高效率的程式語言、還有高效能的Web容器。但除了這幾個方面,還沒辦法根本解決大型網站面臨的高負載和高並發問題。

上面提供的幾個解決思路在一定程度上也意味著更大的投入,並且這樣的解決思路具備瓶頸,沒有很好的擴展性,下面我從低成本、高性能和高擴張性的角度來說說我的一些經驗。

1、HTML靜態化

其實大家都知道,效率最高、消耗最小的就是純靜態化的html頁面,所以我們盡可能讓我們的網站上的頁面採用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法。但對於大量內容且頻繁更新的網站,我們無法全部手動去挨個實現,於是出現了我們常見的資訊發布系統CMS,像我們常訪問的各個門戶網站的新聞頻道,甚至他們的其他頻道,都是透過資訊發布系統來管理和實現的,資訊發布系統可以實現最簡單的資訊輸入自動生成靜態頁面,還能具備頻道管理、權限管理、自動抓取等功能,對於一個大型網站來說,擁有一套高效、可管理的CMS是不可或缺的。

除了入口網站和資訊發布類型的網站,對於互動性要求很高的社群類型網站來說,盡可能的靜態化也是提高效能的必要手段,將社群內的貼文、文章進行即時的靜態化,有更新的時候再重新靜態化也是大量使用的策略,像Mop的大雜燴就是使用了這樣的策略,網易社群等也是如此。

同時,html靜態化也是某些快取策略使用的手段,對於系統中頻繁使用資料庫查詢但是內容更新很小的應用,可以考慮使用html靜態化來實現,例如論壇中論壇的公用設定信息,這些信息目前的主流論壇都可以進行後台管理並且存儲再數據庫中,這些信息其實大量被前台程序調用,但是更新頻率很小,可以考慮將這部分內容進行後台更新的時候進行靜態化,這樣避免了大量的資料庫存取請求。

2、圖片伺服器分離

大家知道,對Web伺服器來說,不管是Apache、IIS或其他容器,圖片是最消耗資源的,所以我們有必要將圖片與頁面進行分離,這是基本上大型網站都會採用的策略,他們都有獨立的圖片伺服器,甚至很多台圖片伺服器。這樣的架構可以降低提供頁面存取請求的伺服器系統壓力,並且可以確保系統不會因為圖片問題而崩潰,在應用程式伺服器和圖片伺服器上,可以進行不同的設定最佳化,例如apache在配置ContentType的時候可以盡量少支持,盡可能少的LoadModule,確保更高的系統消耗和執行效率。

3、資料庫叢集和庫表雜湊

大型網站都有複雜的應用,這些應用程式必須使用資料庫,那麼在面對大量存取的時候,資料庫的瓶頸很快就能顯現出來,這時一台資料庫很快就會無法滿足應用,於是我們需要使用資料庫叢集或是庫表散列。

在資料庫叢集方面,許多資料庫都有自己的解決方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是類似的方案,您使用了什麼樣的DB,就參考對應的解決方案來實作即可。

上述的資料庫叢集由於在架構、成本、擴張性方面都會受到所採用DB類型的限制,於是我們需要從應用程式的角度來考慮改善系統架構,庫表雜湊是常用且最有效的解決方案。我們在應用程式中安裝業務和應用程式或功能模組將資料庫分離,不同的模組對應不同的資料庫或表,再按照一定的策略對某個頁面或功能進行較小的資料庫雜湊,例如使用者表,依照使用者ID進行表散列,這樣就能夠低成本的提升系統的效能並且有很好的擴充性。 sohu的論壇就是採用了這樣的架構,將論壇的使用者、設定、貼文等資訊進行資料庫分離,然後對貼文、使用者依照板塊和ID進行雜湊資料庫和表,最終可以在設定檔中進行簡單的配置便能讓系統隨時增加一台低成本的資料庫進來補充系統效能。

4、快取

快取一詞搞技術的都接觸過,很多地方用到快取。網站架構和網站開發中的快取也是非常重要。這裡先講述最基本的兩種快取。高級和分散式的快取在後面講述。 
架構方面的緩存,對Apache比較熟悉的人都能知道Apache提供了自己的快取模組,也可以使用外加的Squid模組進行緩存,這兩種方式都可以有效的提升Apache的存取回應能力。
網站程式開發方面的緩存,Linux上提供的Memory Cache是​​常用的緩存接口,可以在web開發中使用,比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通信共享,一些大型社群使用了這樣的架構。另外,使用web語言開發的時候,各種語言基本上都有自己的快取模組和方法,PHP有Pear的Cache模組,Java就更多了,.net不是很熟悉,相信也肯定有。

5、鏡像

鏡像是大型網站常採用的提高效能和資料安全性的方式,鏡像的技術可以解決不同網路存取商和地理帶來的使用者存取速度差異,例如ChinaNet和EduNet之間的差異就促使了許多網站在教育網內建立鏡像站點,資料進行定時更新或即時更新。在鏡像的細節技術方面,這裡不闡述太深,有很多專業的現成的解決架構和產品可選。也有廉價的透過軟體實現的思路,例如Linux上的rsync等工具。

6、負載平衡

負載平衡將是大型網站解決高負載存取和大量並發請求採用的終極解決方案。

負載平衡技術發展了多年,有很多專業的服務提供者和產品可以選擇,我個人接觸過一些解決方法,其中有兩個架構可以給大家做參考。

1)硬體四層交換

第四層交換使用第三層和第四層資訊包的報頭訊息,根據應用區間識別業務流,將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就像是虛IP,指向實體伺服器。它傳輸的業務服從的協定多種多樣,有HTTP、FTP、NFS、Telnet或其他協定。這些業務在實體伺服器基礎上,需要複雜的載量平衡演算法。在IP世界,業務類型由終端TCP或UDP連接埠位址來決定,在第四層交換中的應用區間則由來源端和終端IP位址、TCP和UDP連接埠共同決定。

在硬體四層交換產品領域,有一些知名的產品可以選擇,例如Alteon、F5等,這些產品很昂貴,但是物有所值,能夠提供非常優秀的性能和很靈活的管理能力。 Yahoo中國當初接近2,000台伺服器使用了三、四台Alteon就搞定了。

2)軟體四層交換

大家知道了硬體四層交換器的原理後,基於OSI模型來實現的軟體四層交換也就應運而生,這樣的解決方案實現的原理一致,不過性能稍差。但滿足一定程度的壓力還是游刃有餘的,有人說軟體實現方式其實更靈活,處理能力完全看你配置的熟悉能力。

軟體四層交換我們可以使用Linux上常用的LVS來解決,LVS就是Linux Virtual Server,他提供了基於心跳線heartbeat的即時災難應變解決方案,提高系統的穩健性,同時可供了靈活的虛擬VIP配置和管理功能,可以同時滿足多種應用需求,這對於分散式的系統來說必不可少。

一個典型的使用負載平衡的策略就是,在軟體或硬體四層交換的基礎上搭建squid集群,這種思路在很多大型網站包括搜尋引擎上被採用,這樣的架構低成本、高效能還有很強的擴張性,隨時往架構裡面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下跟大家探討。

 

java處理高並發高負載類別網站中資料庫的設計方法(java教學,java處理大量數據,java高負載資料)

一:高並發高負載類別網站關注點之資料庫

沒錯,首先是資料庫,這是大多數應用所面臨的首個SPOF。尤其是Web2.0的應用,資料庫的回應是首先要解決的。
一般來說MySQL是最常用的,可能原本就是一個mysql主機,當資料增加到100萬以上,那麼,MySQL的效能急劇下降。常用的最佳化措施是M-S(主-從)方式進行同步複製,將查詢和操作和分別在不同的伺服器上進行操作。我推薦的是M-M-Slaves方式,2個主Mysql,多個Slaves,要注意的是,雖然有2個Master,但同時只有1個是Active,我們可以在一定時候切換。之所以用2個M,是保證M不會再成為系統的SPOF。
Slaves可以進一步負載平衡,可以結合LVS,從而將select操作適當的平衡到不同的slaves上。
以上架構可以抗衡到一定量的負載,但隨著用戶進一步增加,你的用戶表資料超過1千萬,這時那個M變成了SPOF。你不能任意擴充Slaves,否則複製同步的開銷會直線上升,怎麼辦?我的方法是表格分區,從業務層面進行分區。最簡單的,以使用者資料為例。根據一定的切分方式,例如id,切分到不同的資料庫集群去。

全域資料庫用於meta資料的查詢。缺點是每次查詢,會增加一次,例如你要查一個用戶nightsailer,你首先要到全域資料庫群找到nightsailer對應的cluster id,然後再到指定的cluster找到nightsailer的實際資料。
每個cluster可以用m-m方式,或是m-m-slaves方式。這是一個可以擴展的結構,隨著負載的增加,你可以簡單的增加新的mysql cluster進去。

要注意的是:
1、禁用全部auto_increment的欄位
2、id需要採用通用的演算法集中分配
3、要具有比較好的方法來監控mysql主機的負載和服務的運作狀態。如果你有30台以上的mysql資料庫在跑就明白我的意思了。
4、不要使用持久性連結(不要用pconnect),相反,使用sqlrelay這種第三方的資料庫連結池,或乾脆自己做,因為php4中mysql的連結池經常出問題。

二:高併發高負載網站的系統架構之HTML靜態化

#其實大家都知道,效率最高、消耗最小的就是純靜態化 http:/ /www.ablanxue.com/shtml/201207/776.shtml的html頁面,所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法。但對於大量內容且頻繁更新的網站,我們無法全部手動去挨個實現,於是出現了我們常見的資訊發布系統CMS,像我們常訪問的各個門戶網站的新聞頻道,甚至他們的其他頻道,都是透過資訊發布系統來管理和實現的,資訊發布系統可以實現最簡單的資訊輸入自動生成靜態頁面,還能具備頻道管理、權限管理、自動抓取等功能,對於一個大型網站來說,擁有一套高效、可管理的CMS是不可或缺的。
  
  除了入口網站和資訊發佈類型的網站,對於互動性要求很高的社群類型網站來說,盡可能的靜態化也是提高效能的必要手段,將社群內的貼文、文章進行即時的靜態化,有更新的時候再重新靜態化也是大量使用的策略,像Mop的大雜燴就是使用了這樣的策略,網易社群等也是如此。
  
   同時,html靜態化也是某些快取策略使用的手段,對於系統中頻繁使用資料庫查詢但是內容更新很小的應用,可以考慮使用html靜態化來實現,例如論壇中論壇的公用設定信息,這些信息目前的主流論壇都可以進行後台管理並且存儲再數據庫中,這些信息其實大量被前台程序調用,但是更新頻率很小,可以考慮將這部分內容進行後台更新的時候進行靜態化,這樣避免了大量的資料庫存取請求高並發。
  

網站HTML靜態化解決方案 
當一個Servlet資源請求到達WEB伺服器之後我們會填入指定的JSP頁面來回應請求:

HTTP請求---Web伺服器---Servlet--業務邏輯處理--存取資料--填入JSP--回應請求

HTML靜態化之後:

HTTP請求---Web伺服器---Servlet --HTML--回應請求

靜態存取求如下

Servlet:


#
public void doGet(HttpServletRequest request, HttpServletResponse response)  
        throws ServletException, IOException {  
    if(request.getParameter("chapterId") != null){  
        String chapterFileName = "bookChapterRead_"+request.getParameter("chapterId")+".html";  
        String chapterFilePath = getServletContext().getRealPath("/") + chapterFileName;  
        File chapterFile = new File(chapterFilePath);  
        if(chapterFile.exists()){response.sendRedirect(chapterFileName);return;}//如果有这个文件就告诉浏览器转向   
        INovelChapterBiz novelChapterBiz = new NovelChapterBizImpl();  
        NovelChapter novelChapter = novelChapterBiz.searchNovelChapterById(Integer.parseInt(request.getParameter("chapterId")));//章节信息   
        int lastPageId = novelChapterBiz.searchLastCHapterId(novelChapter.getNovelId().getId(), novelChapter.getId());  
        int nextPageId = novelChapterBiz.searchNextChapterId(novelChapter.getNovelId().getId(), novelChapter.getId());  
        request.setAttribute("novelChapter", novelChapter);  
        request.setAttribute("lastPageId", lastPageId);  
        request.setAttribute("nextPageId", nextPageId);  
        new CreateStaticHTMLPage().createStaticHTMLPage(request, response, getServletContext(),   
                chapterFileName, chapterFilePath, "/bookRead.jsp");  
    }  
}

產生HTML靜態頁面的類別:


package com.jb.y2t034.thefifth.web.servlet;  
import java.io.ByteArrayOutputStream;  
import java.io.FileOutputStream;  
import java.io.IOException;  
import java.io.OutputStreamWriter;  
import java.io.PrintWriter;  
import javax.servlet.RequestDispatcher;  
import javax.servlet.ServletContext;  
import javax.servlet.ServletException;  
import javax.servlet.ServletOutputStream;  
import javax.servlet.http.HttpServletRequest;  
import javax.servlet.http.HttpServletResponse;  
import javax.servlet.http.HttpServletResponseWrapper;  
/** * 创建HTML静态页面 
* 功能:创建HTML静态页面 
* 时间:2009年1011日 
* 地点:home 
* @author mavk 
* 
*/  public class CreateStaticHTMLPage {  
    /** 
     * 生成静态HTML页面的方法 
     * @param request 请求对象 
     * @param response 响应对象 
     * @param servletContext Servlet上下文 
     * @param fileName 文件名称 
     * @param fileFullPath 文件完整路径 
     * @param jspPath 需要生成静态文件的JSP路径(相对即可) 
     * @throws IOException 
     * @throws ServletException 
     */  
    public void createStaticHTMLPage(HttpServletRequest request, HttpServletResponse response,ServletContext servletContext,String fileName,String fileFullPath,String jspPath) throws ServletException, IOException{  
        response.setContentType("text/html;charset=gb2312");//设置HTML结果流编码(即HTML文件编码)   
        RequestDispatcher rd = servletContext.getRequestDispatcher(jspPath);//得到JSP资源   
        final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();//用于从ServletOutputStream中接收资源   
        final ServletOutputStream servletOuputStream = new ServletOutputStream(){//用于从HttpServletResponse中接收资源   
            public void write(byte[] b, int off,int len){  
                byteArrayOutputStream.write(b, off, len);  
            }  
            public void write(int b){  
                byteArrayOutputStream.write(b);  
            }  
        };  
        final PrintWriter printWriter = new PrintWriter(new OutputStreamWriter(byteArrayOutputStream));//把转换字节流转换成字符流   
        HttpServletResponse httpServletResponse = new HttpServletResponseWrapper(response){//用于从response获取结果流资源(重写了两个方法)   
            public ServletOutputStream getOutputStream(){  
                return servletOuputStream;  
            }  
            public PrintWriter getWriter(){  
                return printWriter;  
            }  
        };  
        rd.include(request, httpServletResponse);//发送结果流   
        printWriter.flush();//刷新缓冲区,把缓冲区的数据输出   
        FileOutputStream fileOutputStream = new FileOutputStream(fileFullPath);  
        byteArrayOutputStream.writeTo(fileOutputStream);//把byteArrayOuputStream中的资源全部写入到fileOuputStream中   
        fileOutputStream.close();//关闭输出流,并释放相关资源   
        response.sendRedirect(fileName);//发送指定文件流到客户端       }  
}

三:高並發高負載類別網站關注點之緩存、負載平衡、儲存

##快取是另一個大問題,我一般用memcached來做快取集群,一般來說部署10台左右就差不多(10g記憶體池)。要注意一點,千萬不能用使用

swap,最好關閉linux的swap。

负载均衡/加速

可能上面说缓存的时候,有人第一想的是页面静态化,所谓的静态html,我认为这是常识,不属于要点了。页面的静态化随之带来的是静态服务的
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS b3c39e73f82b358bad409308ba9884dclighttped====>squid(s) ====lighttpd

上面是我经常用的。注意,我没有用apache,除非特定的需求,否则我不部署apache,因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。

squid的使用可以解决文件的同步等等问题,但是需要注意,你要很好的监控缓存的命中率,尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论,这里不赘述。

存储
存储也是一个大问题,一种是小文件的存储,比如图片这类。另一种是大文件的存储,比如搜索引擎的索引,一般单文件都超过2g以上。
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS,优点是应用透明,缺点是费用较高。我是指
你购买盘阵的问题。我的项目中,存储量是2-10Tb,我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余,这方面可以参考google的gfs的论文。
大文件的存储,可以参考nutch的方案,现在已经独立为hadoop子项目。(你可以google it)

其他:
此外,passport等也是考虑的,不过都属于比较简单的了。
四:高并发高负载网站的系统架构之图片服务器分离 
大家知道,对于Web 服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他 们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用 服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的LoadModule, 保证更高的系统消耗和执行效率。


利用Apache实现图片服务器的分离
缘由: 
起步阶段的应用,都可能部署在一台服务器上(费用上的原因) 
第一个优先分离的,肯定是数据库和应用服务器。 
第二个分离的,会是什么呢?各有各的考虑,我所在的项目组重点考虑的节约带宽,服务器性能再好,带宽再高,并发来了,也容易撑不住。因此,我这篇文章的重点在这里。这里重点是介绍实践,不一定符合所有情况,供看者参考吧, 
环境介绍: 
WEB应用服务器:4CPU双核2G, 内存4G 
  部署:Win2003/Apache Http Server 2.1/Tomcat6 
数据库服务器:4CPU双核2G, 内存4G 
  部署:Win2003/MSSQL2000 
步骤: 
步骤一:增加2台配置为:2CPU双核2G,内存2G普通服务器,做资源服务器 
  部署:Tomcat6,跑了一个图片上传的简单应用,(记得指定web.xml的682fa04e96c314670032152167ed6ade),并指定域名为res1.***.com,res2.***.com,采用ajp协议 
步骤二:修改Apache httpd.conf配置 
  原来应用的文件上传功能网址为: 
   1、/fileupload.html 
   2、/otherupload.html 
  在httpd.conf中增加如下配置

<VirtualHost *:80>   
  ServerAdmin webmaster@***.com   
  ProxyPass /fileupload.html balancer://rescluster/fileupload lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3      
  ProxyPass /otherupload.html balancer://rescluster/otherupload.html lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3      
  #<!--负载均衡-->   
  <Proxy balancer://rescluster/>   
    BalancerMember ajp://res1.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat1  
    BalancerMember ajp://res2.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat2  
  </Proxy>   
   
< /VirtualHost>

步骤三,修改业务逻辑: 
  所有上传文件在数据库中均采用全url的方式保存,例如产品图片路径存成:http://res1.***.com/upload/20090101/product120302005.jpg

现在,你可以高枕无忧了,带宽不够时,增加个几十台图片服务器,只需要稍微修改一下apache的配置文件,即可。

五:高并发高负载网站的系统架构之数据库集群和库表散列

大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。
  
  在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。
  
   上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并 且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者 功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的 架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系 统随时增加一台低成本的数据库进来补充系统性能。


集群软件的分类:
一般来讲,集群软件根据侧重的方向和试图解决的问题,分为三大类:高性能集群(High performance cluster,HPC)、负载均衡集群(Load balance cluster, LBC),高可用性集群(High availability cluster,HAC)。
高性能集群(High performance cluster,HPC),它是利用一个集群中的多台机器共同完成同一件任务,使得完成任务的速度和可靠性都远远高于单机运行的效果。弥补了单机性能上的不足。该集群在天气预报、环境监控等数据量大,计算复杂的环境中应用比较多;
负载均衡集群(Load balance cluster, LBC),它是利用一个集群中的多台单机,完成许多并行的小的工作。一般情况下,如果一个应用使用的人多了,那么用户请求的响应时间就会增大,机器的性能也会受到影响,如果使用负载均衡集群,那么集群中任意一台机器都能响应用户的请求,这样集群就会在用户发出服务请求之后,选择当时负载最小,能够提供最好的服务的这台机器来接受请求并相应,这样就可用用集群来增加系统的可用性和稳定性。这类集群在网站中使用较多;
高可用性集群(High availability cluster,HAC),它是利用集群中系统 的冗余,当系统中某台机器发生损坏的时候,其他后备的机器可以迅速的接替它来启动服务,等待故障机的维修和返回。最大限度的保证集群中服务的可用性。这类系统一般在银行,电信服务这类对系统可靠性有高的要求的领域有着广泛的应用。
2 数据库集群的现状
数据库集群是将计算机集群技术引入到数据库中来实现的,尽管各厂商宣称自己的架构如何的完美,但是始终不能改变Oracle当先,大家追逐的事实,在集群的解决方案上Oracle RAC还是领先于包括微软在内的其它数据库厂商,它能满足客户高可用性、高性能、数据库负载均衡和方便扩展的需求。

Oracle’s Real Application Cluster (RAC)
Microsoft SQL Cluster Server (MSCS)
IBM’s DB2 UDB High Availability Cluster(UDB)
Sybase ASE High Availability Cluster (ASE)
MySQL High Availability Cluster (MySQL CS)

基于IO的第三方HA(高可用性)集群
当前主要的数据库集群技术有以上六大类,有数据库厂商自己开发的;也有第三方的集群公司开发的;还有数据库厂商与第三方集群公司合作开发的,各类集群实现的功能及架构也不尽相同。
RAC(Real Application Cluster,真正应用集群)是Oracle9i数据库中采用的一项新技术,也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题:高性能、高可伸缩性与低价格之间的矛盾。在很长一段时间里,甲骨文都以其实时应用集群技术(Real Application Cluster,RAC)统治着集群数据库市场

六:高并发高负载网站的系统架构之缓存

快取一詞搞技術的都接觸過,很多地方都用到快取。網站架構和網站開發中的快取也是非常重要。這裡先講述最基本的兩種快取。高級和分散式的快取在後面講述。 
  架構方面的緩存,對Apache比較熟悉的人都能知道Apache提供了自己的緩存模組,也可以使用外加的Squid模組進行緩存,這兩種方式均可以有效的提高Apache的存取響應能力。
   網站程式開發方面的緩存,Linux上提供的Memory Cache是​​常用的緩存接口,可以在web開發中使用,比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通信共享,一些大型社群使用了這樣的架構。另外,使用web語言開發的時候,各種語言基本上都有自己的快取模組和方法,PHP有Pear的Cache模組,Java就更多 了,.net不是很熟悉,相信也肯定有。

Java開源快取框架 

JBossCache/TreeCache JBossCache 是複製的事務處理緩存,它允許你快取企業級應用資料來更好的改善效能。快取資料被自動複製,讓你輕鬆進行Jboss伺服器之間的叢集工作。 JBossCache能夠透過Jboss應用服務或其他J2EE容器來運行一個Mbean服務,當然,它也能獨立運作。 JBossCache包含兩個模組:TreeCache和TreeCacheAOP。 TreeCache --是一個樹狀結構複製的交易處理快取。 TreeCacheAOP --是一個「物件導向」緩存,它使用AOP來動態管理POJO.

OSCache OSCache標記庫由OpenSymphony設計,它是一種開創性的JSP自訂標記應用,提供了在現有JSP頁面之內實現快速記憶體緩衝的功能。 OSCache是​​個廣泛採用的高效能的J2EE快取框架,OSCache能用於任何Java應用程式的普通的快取解決方案。 OSCache有以下特點:快取任何對象,你可以不受限制的快取部分jsp頁面或HTTP請求,任何java對像都可以快取。 擁有全面的API--OSCache API給你一個全面的程式來控制所有的OSCache特性。 永久緩存--快取能隨意的寫入硬碟,因此允許昂貴的創建(expensive-to-create)資料來保持緩存,甚至能讓應用程式重啟。 支援集群--集群快取資料能被單一的進行參數配置,不需要修改代碼。 快取記錄的過期--你可以有最大限度的控制快取物件的過期,包括可插入式的刷新策略(如果預設效能不需要時)。

JCACHE JCACHE是一種即將公佈的標準規格(JSR 107),說明了一種對Java物件暫時在記憶體中進行快取的方法,包括物件的建立、共享訪問、假脫機(spooling)、失效、各JVM的一致性等。它可被用於快取JSP內最常讀取的數據,如產品目錄和價格列表。利用JCACHE,多數查詢的反應時間會因為有快取的資料而加快(內部測試顯示反應時間大約快15倍)。

Ehcache Ehcache出自Hibernate,並在Hibernate中使用它作為資料快取的解決方案。

Java Caching System JCS是Jakarta的專案Turbine的子專案。它是一個複合式的緩衝工具。可以將物件緩衝到記憶體、硬碟。具有緩衝物件時間過期設定。還可以透過JCS建構具有緩衝的分散式架構,以實現高效能的應用。 對於一些需要頻繁存取而每訪問一次都非常消耗資源的對象,可以暫時存放在緩衝區中,這樣可以提高服務的效能。而JCS正是一個很好的緩衝工具。緩衝工具對於讀取操作遠遠多於寫入操作的應用效能提升非常顯著。

SwarmCache SwarmCache是一個簡單且功能強大的分散式快取機制。它使用IP組播來有效地在快取的實例之間進行通訊。它是快速提高叢集式Web應用程式的效能的理想選擇。

ShiftOne ShiftOne Object Cache這個Java庫提供了基本的物件快取能力。實現的策略有先進先出(FIFO),最近使用(LRU),最不常使用(LFU)。所有的策略可以最大化元素的大小,最大化其生存時間。

WhirlyCache Whirlycache是一個快速的、可設定的、存在於記憶體中的物件的快取。它能夠透過快取物件來加快網站或應用程式的速度,否則就必須透過查詢資料庫或其他代價較高的處理程序來建立。

Jofti Jofti可對在快取層中(支援EHCache,JBossCache和OSCache)的物件或在支援Map介面的儲存結構中的物件進行索引與搜尋。這個框架也為物件在索引中的增刪改提供透明的功能同樣也為搜尋提供易於使用的查詢功能。

cache4j cache4j是一個有簡單API與實作快速的Java物件快取。它的特性包括:在記憶體中進行緩存,設計用於多線程環境,兩種實現:同步與阻塞,多種緩存清除策略:LFU, LRU, FIFO,可使用強引用(strong reference)與軟引用( soft reference)儲存物件。

Open Terracotta 一個JVM級的開源叢集框架,提供:HTTP Session複製,分散式緩存,POJO群集,跨越群集的JVM來實現分散式應用程式協調(採用程式碼注入的方式,所以你不需要修改任何)。

sccache SHOP.COM所使用的物件快取系統。 sccache是​​一個in-process cache和二級、共享快取。它將快取物件儲存到磁碟上。支援關聯Key,任意大小的Key和任意大小的資料。能夠自動進行垃圾收集。

Shoal Shoal是一個基於Java可擴展的動態叢集框架,能夠為建立容錯、可靠且可用的Java應用程式提供了基礎架構支援。這個框架還可以整合到不希望綁定到特定通訊協議,但需要叢集和分散式系統支援的任何Java產品中。 Shoal是GlassFish和JonAS應用伺服器的叢集引擎。

Simple-Spring-Memcached Simple-Spring-Memcached,它封裝了對MemCached的調用,使MemCached的客戶端開發變得超乎尋常的簡單。

以上是關於Java中關於高並發解決方案以及高負載優化的實例講解的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn