個人の Web サイトなどの小規模な Web サイトは、いくつかの画像を使用して最も単純な HTML 静的ページを使用して実装できます。このような Web サイトには、システム アーキテクチャとパフォーマンスの両方の要件があります。インターネット ビジネスの継続的な充実に伴い、Web サイト関連の技術は長年の開発を経て非常に細分化されており、特に大規模な Web サイトでは、使用される技術はハードウェアから技術まで多岐にわたります。ソフトウェア、プログラミング言語、データベース、Web サーバー、ファイアウォールなどのさまざまな分野で、元の単純な HTML 静的 Web サイトとは比較できなくなりました。
ポータルなどの大規模な Web サイト。多数のユーザー アクセスと高い同時リクエストに直面して、基本的なソリューションは、高性能サーバー、高性能データベース、高効率プログラミング言語、および高性能 Web コンテナーの使用に重点を置いています。しかし、これらの側面を除けば、大規模な Web サイトが直面する高負荷と高同時実行の問題に対する根本的な解決策はありません。
上記のいくつかのソリューションのアイデアは、ある程度大きな投資を意味しますが、そのようなソリューションのアイデアにはボトルネックがあり、拡張性が高くありません。以下では、低コスト、高パフォーマンス、高拡張性の観点から説明します。私の経験のいくつかについて話します。
1. 静的 HTML
実際、最も効率的で消費が最も少ないのは純粋に静的な HTML ページであることは誰もが知っているため、私たちは Web サイトのページには静的ページを使用するよう最善を尽くしています。これが最も簡単な方法です。実は最も効果的な方法なのです。しかし、コンテンツ量が多く、更新頻度も高いWebサイトでは、1つ1つ手作業で導入することはできません。そこで、私たちがよく見るさまざまなポータルサイトのニュースチャンネルや、その他のポータルサイトのニュースチャンネルなど、共通の情報公開システムCMSが登場しました。情報公開システムは、最も簡単な情報入力を実現し、チャネル管理、権限管理、自動クローリングなどの機能を備えています。大規模な Web サイトには、効率的で管理しやすい CMS が不可欠です。
ポータルや情報公開タイプの Web サイトに加えて、高い対話性が要求されるコミュニティタイプの Web サイトの場合、コミュニティ内の投稿や記事をリアルタイムで静的にすることも、パフォーマンスを向上させるために必要な手段です。更新時の静的化も、NetEase コミュニティなどと同様に、広く使用されている戦略です。
同時に、HTML 静的化は、一部のキャッシュ戦略で使用される手段でもあり、データベース クエリを頻繁に使用するものの、コンテンツの更新が非常に少ないシステム内のアプリケーション (パブリック アプリケーションなど) では、これを実現するために HTML 静的化の使用を検討できます。フォーラムの設定情報は、現在主流のフォーラムで管理し、データベースに保存することができますが、実際には、この情報の多くはフロントエンドプログラムによって呼び出されますが、更新頻度は非常に低いと考えられます。大量の情報データベースへのアクセス要求を回避するために、背景を更新するときにコンテンツのこの部分を静的にします。
2. 画像サーバーの分離
ご存知のとおり、Web サーバーでは、Apache、IIS、その他のコンテナーのいずれであっても、画像が最も多くのリソースを消費するため、画像をページから分離する必要があります。基本 これは、大規模な Web サイトで使用される戦略であり、すべての Web サイトには独立した画像サーバー、または複数の画像サーバーが存在します。このようなアーキテクチャにより、ページ アクセス リクエストを提供するサーバー システムへの負荷が軽減され、画像の問題によってシステムがクラッシュすることがなくなります。たとえば、Apache では、アプリケーション サーバーと画像サーバーでさまざまな構成の最適化を実行できます。 ContentType を構成するときは、システム消費量と実行効率を高めるために、サポートを最小限にし、使用する LoadModule をできるだけ少なくしてください。
3. データベースクラスターとデータベーステーブルハッシュ
大規模な Web サイトには複雑なアプリケーションがあり、これらのアプリケーションは大量のアクセスに直面すると、データベースのボトルネックがすぐに明らかになります。 1 つのデータベースではすぐにアプリケーションを満たすことができなくなるため、データベース クラスタリングまたはデータベース テーブル ハッシュを使用する必要があります。
データベース クラスターに関しては、Oracle、Sybase などに独自のソリューションがあります。MySQL が提供する一般的に使用されるマスター/スレーブも同様のソリューションです。どのような種類の DB を使用しているかを参照してください。対応するソリューションを実装できます。
上記のデータベース クラスターは、アーキテクチャ、コスト、拡張性の点で使用する DB の種類によって制限されるため、アプリケーションの観点からシステム アーキテクチャの改善を検討する必要があります。ライブラリ テーブルのハッシュは一般的に使用され、最もよく使用されます。効果的な解決策。アプリケーションにビジネス モジュールとアプリケーション モジュール、または機能モジュールをインストールして、データベースを分離します。さまざまなモジュールがさまざまなデータベースまたはテーブルに対応し、特定の戦略を使用して、特定のページまたは機能で小さなデータベース ハッシュ (ユーザー テーブルのハッシュなど) を実行します。ユーザー ID に応じてテーブルを作成することで、低コストでシステムのパフォーマンスを向上させることができ、優れた拡張性を備えています。 Sohu のフォーラムは、フォーラムのユーザー、設定、投稿などの情報をデータベースに分離し、そのデータベースと投稿とユーザーのテーブルをセクションと ID に応じてハッシュ化し、最後に設定で簡単に設定できる構造を採用しています。これにより、システムはいつでも低コストのデータベースを追加して、システムのパフォーマンスを補うことができます。
4. キャッシュ
技術者なら誰でもキャッシュという言葉を聞いたことがあるでしょう。キャッシュはさまざまな場所で使用されています。 Web サイトのアーキテクチャおよび Web サイト開発におけるキャッシュも非常に重要です。ここではまず、最も基本的な 2 つのキャッシュについて説明します。高度な分散キャッシュについては後で説明します。
アーキテクチャ上のキャッシュに関しては、Apache に詳しい人なら誰でも、Apache が独自のキャッシュ モジュールを提供していること、または追加の Squid モジュールをキャッシュに使用できることを知っているでしょう。どちらの方法でも、Apache のアクセス応答機能を効果的に向上させることができます。
Webサイトのプログラム開発におけるキャッシュ Linuxで提供されているMemory Cacheはよく使われるキャッシュインターフェースで、例えばJavaで開発する場合、MemoryCacheを呼び出して一部のデータをキャッシュして通信したり共有したりすることができます。いくつかの大きなコミュニティによって。さらに、Web 言語開発を使用する場合、基本的に各言語には独自のキャッシュ モジュールとメソッドがあり、PHP には Pear の Cache モジュールがあり、Java には .net にはさらに多くのモジュールがあるはずです。
5. ミラーリング
ミラーリングは、パフォーマンスとデータのセキュリティを向上させるために大規模な Web サイトでよく使用される方法であり、ChinaNet と EduNet の間など、ネットワーク アクセス プロバイダーや地域によって生じるユーザーのアクセス速度の違いを解決できます。これらの違いにより、多くの Web サイトが教育ネットワーク内にミラー サイトを構築し、データは定期的またはリアルタイムで更新されています。ミラーリングの詳細なテクノロジーについては、ここではあまり詳しく説明しません。専門的な既製のソリューション アーキテクチャと製品が多数あります。 Linux 上の rsync やその他のツールなどのソフトウェアを使用して安価に実装する方法もあります。
6. 負荷分散
負荷分散は、大規模な Web サイトの高負荷アクセスと多数の同時リクエストを解決するための究極のソリューションになります。
負荷分散テクノロジーは長年にわたって開発されており、多くの専門的なサービスプロバイダーや製品から選択できます。私は個人的にいくつかのソリューションを見つけました。そのうちの 2 つは参考として使用できます。
1) ハードウェア 4 層スイッチング
4 層目のスイッチングでは、3 層目と 4 層目のパケットのヘッダー情報を使用して、アプリケーション間隔に応じてビジネス フローを識別し、間隔セグメント全体のビジネス フローを適切なセグメントに割り当てます。処理用のアプリケーションサーバー。 レイヤ 4 スイッチング機能は、物理サーバーを指す仮想 IP のようなものです。送信されるサービスは、HTTP、FTP、NFS、Telnet、その他のプロトコルなど、さまざまなプロトコルに従います。これらのサービスには、物理サーバーに基づく複雑な負荷分散アルゴリズムが必要です。 IP の世界では、サービス タイプは端末の TCP または UDP ポート アドレスによって決まります。レイヤ 4 スイッチングでは、アプリケーションの範囲は送信元と端末の IP アドレス、TCP および UDP ポートによって決まります。
ハードウェア 4 層スイッチング製品の分野では、Alteon、F5 などの有名な製品がいくつかあります。これらの製品は高価ですが、お金を払う価値があり、非常に優れたパフォーマンスとパフォーマンスを提供します。非常に柔軟な管理機能。 Yahoo China は、2,000 台近くのサーバーを処理するために 3 ~ 4 台の Alteons を使用しました。
2) ソフトウェア 4 層スイッチング
ハードウェア 4 層スイッチの原理を誰もが知った後、OSI モデルに基づくソフトウェア 4 層スイッチングが登場しました。このようなソリューションの原理は同じですが、パフォーマンスは異なります。若干悪い。ただし、ある程度の圧力に対処するのは依然として簡単であり、ソフトウェアの実装方法は実際にはより柔軟であり、処理能力は完全に構成の習熟度に依存すると言う人もいます。
Linux で一般的に使用されている LVS を使用すると、ソフトウェアの 4 層スイッチングを解決できます。LVS は、ハートビート ラインに基づいたリアルタイムの災害対応ソリューションを提供し、システムの堅牢性を向上させます。柔軟な仮想 VIP 構成と管理機能を提供し、分散システムに不可欠な複数のアプリケーション要件を同時に満たすことができます。
典型的な負荷分散戦略は、ソフトウェアまたはハードウェアの 4 層スイッチングに基づいて Squid クラスターを構築することです。このアイデアは、検索エンジンを含む多くの大規模 Web サイトで採用されており、低コストで高性能であり、拡張性が高くなります。 、いつでもアーキテクチャにノードを追加または削除することが非常に簡単です。この構造を詳しく整理して議論していきたいと思います。
高同時実行性と高負荷の Web サイトを処理するために Java でデータベースを設計する方法 (Java チュートリアル、Java による大量のデータの処理、Java 高負荷データ)
1: 高同時実行性と高負荷に重点を置いたデータベース高負荷のウェブサイト
はい、最初はデータベースで、これはほとんどのアプリケーションが直面する最初の SPOF です。特に Web2.0 アプリケーションの場合、データベースの応答を最初に解決する必要があります。
一般的に、MySQL が最も一般的に使用されます。最初は MySQL ホストであり、データが 100 万を超えると、MySQL のパフォーマンスが急激に低下します。一般的に使用される最適化手段は、同期レプリケーションの M-S (マスター/スレーブ) モードです。このモードでは、クエリと操作が異なるサーバーで実行されます。私が推奨するのは、M-M-Slaves 方式です。2 つのマスター Mysql、複数のスレーブがありますが、同時にアクティブになるのは 1 つだけです。 M を 2 つ使用する理由は、M が再びシステムの SPOF にならないようにするためです。
スレーブはさらに負荷分散でき、LVS と組み合わせて、さまざまなスレーブに対する選択操作のバランスを適切にとることができます。
上記のアーキテクチャでもある程度の負荷には対応できますが、ユーザー数がさらに増えるとユーザーテーブルのデータが1000万を超え、MがSPOFになってしまいます。スレーブを任意に拡張することはできません。そうしないと、レプリケーション同期のコストが跳ね上がります。私の方法はテーブルパーティショニング、つまりビジネスレベルからのパーティショニングです。最も単純な例として、ユーザー データを取り上げます。 ID などの特定の分割方法に従って、異なるデータベース クラスターに分割されます。
グローバルデータベースはメタデータクエリに使用されます。欠点は、クエリを実行するたびに一度追加されることです。たとえば、ユーザー nightsailer をクエリする場合は、まずグローバル データベース グループに移動して、nightsailer に対応するクラスター ID を見つけてから、指定されたクラスターを使用して、nightsailer の実際のデータを検索します。
各クラスターは、m-m モードまたは m-m-slaves モードを使用できます。これはスケーラブルな構造であり、負荷が増加した場合でも、新しい mysql クラスターを追加するだけで済みます。
注意すべき点は次のとおりです:
1. すべての auto_increment フィールドを無効にする
2. ID は共通のアルゴリズムを使用して一元的に割り当てる必要がある
3. mysql ホストの負荷と実行ステータスを監視するためのより良い方法がある必要があります。サービス。 30 を超える mysql データベースを実行している場合は、私の言っている意味が理解できるでしょう。
4. 永続リンクを使用しないでください (pconnect を使用しないでください)。php4 の mysql 接続プールには問題が発生することが多いため、代わりに sqlrelay などのサードパーティのデータベース接続プールを使用するか、単に自分で実行します。
2: 同時実行性が高く負荷の高い Web サイトのシステム アーキテクチャの HTML 静的化
実際、最も効率的で低コストの方法が純粋な静的化であることは誰もが知っています http://www.ablanxue.com/shtml /201207/776 .shtml html ページなので、Web サイトのページには静的ページを使用するよう最善を尽くしています。この最も単純な方法が実際には最も効果的です。しかし、コンテンツ量が多く、更新頻度も高いWebサイトでは、1つ1つ手作業で導入することはできません。そこで、私たちがよく見るさまざまなポータルサイトのニュースチャンネルや、その他のポータルサイトのニュースチャンネルなど、共通の情報公開システムCMSが登場しました。情報公開システムは、最も簡単な情報入力を実現し、チャネル管理、権限管理、自動クローリングなどの機能を備えています。大規模な Web サイトには、効率的で管理しやすい CMS が不可欠です。
ポータルや情報公開型の Web サイトに加えて、高い対話性が要求されるコミュニティ型の Web サイトでは、コミュニティ内の投稿や記事をリアルタイムで静的にすることも、パフォーマンスを向上させるために必要な手段です。更新時の静的化も、NetEase コミュニティなどと同様に、広く使用されている戦略です。
同時に、HTML 静的化は、一部のキャッシュ戦略で使用される手段でもあり、データベース クエリを頻繁に使用するものの、コンテンツの更新が非常に少ないシステム内のアプリケーション (パブリックなど) では、これを実現するために HTML 静的化の使用を検討できます。フォーラムの設定情報は、現在主流のフォーラムで管理し、データベースに保存することができますが、実際には、この情報の多くはフロントエンドプログラムによって呼び出されますが、更新頻度は非常に低いと考えられます。大量の情報が同時に発生することを避けるために、バックグラウンドを更新するときにコンテンツのこの部分を静的にします。
WebサイトのHTML静的ソリューション
サーブレットリソースリクエストがWEBサーバーに到達すると、指定されたJSPページに入力してリクエストに応答します:
HTTPリクエスト---Webサーバー---サーブレット--ビジネスロジック処理-- データへのアクセス -- JSP の入力 -- 応答リクエスト
静的 HTML:
HTTP リクエストの後 --- Web サーバー --- サーブレット -- HTML -- 応答リクエスト
静的アクセスリクエストは次のとおりです
サーブレット:
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);//发送指定文件流到客户端 } }
3 つ: 高同時実行性と高負荷の Web サイトは、キャッシュ、負荷分散、ストレージに重点を置いています
キャッシュも大きな問題です。通常、これには memcached を使用します。一般的に、約 10 個のキャッシュ クラスターがデプロイされます (10g メモリ プール)。注意すべき点は、
swap を使用しないことです。Linux スワップをオフにするのが最善です。
负载均衡/加速
可能上面说缓存的时候,有人第一想的是页面静态化,所谓的静态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)统治着集群数据库市场
六:高并发高负载网站的系统架构之缓存
技術者なら誰でもキャッシュという言葉を聞いたことがあるでしょう。キャッシュはさまざまな場所で使用されています。 Web サイトのアーキテクチャおよび Web サイト開発におけるキャッシュも非常に重要です。ここではまず、最も基本的な 2 つのキャッシュについて説明します。高度な分散キャッシュについては後で説明します。
アーキテクチャ上のキャッシュに関しては、Apache に詳しい人であれば、Apache が独自のキャッシュ モジュールを提供するか、追加の Squid モジュールをキャッシュに使用できることをご存知でしょう。どちらの方法でも、Apache のアクセス応答機能を効果的に向上させることができます。
Webサイトのプログラム開発におけるキャッシュ、Linuxで提供されているMemory Cacheは、Web開発でよく使われるキャッシュインターフェースで、例えばJavaで開発する場合、MemoryCacheを呼び出して一部のデータをキャッシュしたり通信したりすることができます。いくつかの大きなコミュニティによって。また、Web 言語開発を使用する場合、基本的に各言語には独自のキャッシュ モジュールとメソッドがあり、PHP には Pear の Cache モジュールがあり、.net には詳しくありませんが、それ以外にもあるはずです。
Java オープンソース キャッシュ フレームワーク
JBossCache/TreeCache JBossCache は、エンタープライズ レベルのアプリケーション データをキャッシュしてパフォーマンスを向上させることができる複製されたトランザクション キャッシュです。キャッシュ データは自動的に複製されるため、Jboss サーバー間でクラスタ作業を簡単に実行できます。 JBossCache は、Jboss Application Service または他の J2EE コンテナを通じて MBean サービスを実行できます。もちろん、独立して実行することもできます。 JBossCache には、TreeCache と TreeCacheAOP という 2 つのモジュールが含まれています。 TreeCache -- ツリー構造のレプリケートされたトランザクション キャッシュです。 TreeCacheAOP -- AOP を使用して POJO を動的に管理する「オブジェクト指向」キャッシュです。
OSCache OSCache タグ ライブラリは OpenSymphony によって設計されており、既存の JSP ページに機能を提供する画期的な JSP カスタム タグ アプリケーションです。内部の高速メモリバッファリング機能。 OSCache は、広く採用されている高性能 J2EE キャッシュ フレームワークであり、あらゆる Java アプリケーションの共通のキャッシュ ソリューションとして使用できます。 OSCache には次の特性があります。あらゆるオブジェクトをキャッシュし、JSP ページまたは HTTP リクエストの一部を制限なくキャッシュでき、あらゆる Java オブジェクトをキャッシュできます。 包括的な API を備えています - OSCache API は、すべての OSCache 機能を制御するための包括的なプログラムを提供します。 永続的なキャッシュ - キャッシュは自由にディスクに書き込むことができるため、アプリケーションが再起動されても、作成にコストがかかるデータをキャッシュしたままにすることができます。 クラスタリングをサポート - コードを変更せずにクラスタ キャッシュ データを個別に構成できます。 キャッシュ レコードの有効期限 - プラグ可能な更新戦略 (デフォルトのパフォーマンスに必要ない場合) を含め、キャッシュされたオブジェクトの有効期限を最大限に制御できます。
JCACHE JCACHE は、オブジェクトの作成、共有アクセス、スプーリング、無効化、各 JVM の一貫性などを含む、Java オブジェクトをメモリに一時的にキャッシュする方法を記述する次期標準仕様 (JSR 107) です。製品カタログや価格表など、JSP 内で最も頻繁に読み取られるデータをキャッシュするために使用できます。 JCACHE を使用すると、データをキャッシュすることでほとんどのクエリの応答時間が短縮されます (内部テストでは、応答時間が約 15 倍速くなることが示されています)。
Ehcache Ehcache は Hibernate から来ており、Hibernate でデータ キャッシュ ソリューションとして使用されます。
Java キャッシュ システム JCS は、ジャカルタのプロジェクト Turbine のサブプロジェクトです。複合バッファツールです。オブジェクトはメモリとハードディスクにバッファリングできます。バッファオブジェクトの有効期限設定があります。 JCS によるバッファリングを備えた分散アーキテクチャを構築して、高パフォーマンスのアプリケーションを実現することもできます。 頻繁にアクセスする必要があり、アクセスされるたびに多くのリソースを消費する一部のオブジェクトについては、それらを一時的にバッファーに保管することで、サービスのパフォーマンスを向上させることができます。 JCS は優れたバッファリング ツールです。バッファリング ツールは、書き込み操作よりも読み取り操作がはるかに多いアプリケーションのパフォーマンスを大幅に向上させることができます。
SwarmCache SwarmCache は、シンプルでありながら強力な分散キャッシュ メカニズムです。 IP マルチキャストを使用して、キャッシュされたインスタンス間で効率的に通信します。これは、クラスター化された Web アプリケーションのパフォーマンスを迅速に向上させるのに最適です。
ShiftOne ShiftOne オブジェクト キャッシュこの Java ライブラリは、基本的なオブジェクト キャッシュ機能を提供します。実装される戦略は、先入れ先出し (FIFO)、最近使用されたもの (LRU)、および最も使用頻度の低いもの (LFU) です。すべての戦略は、要素のサイズを最大化し、その生存時間を最大化します。
WhirlyCache Whirlycache は、高速で構成可能なオブジェクトのメモリ内キャッシュです。データベースやその他のコストのかかるプロセスにクエリを実行して構築する必要があるオブジェクトをキャッシュすることで、Web サイトやアプリケーションを高速化できます。
Jofti Jofti は、キャッシュ層 (EHCache、JBossCache、OSCache をサポート) または Map インターフェースをサポートするストレージ構造内のオブジェクトのインデックス付けと検索を行うことができます。このフレームワークは、インデックス内のオブジェクトの追加、削除、変更に対する透過性と、検索のための使いやすいクエリ機能も提供します。
cache4j catch4j は、シンプルな API と高速な実装を備えた Java オブジェクト キャッシュです。その機能には、マルチスレッド環境向けに設計されたメモリ内のキャッシュ、2 つの実装: 同期とブロッキング、複数のキャッシュ クリア戦略: LFU、LRU、FIFO、強参照 (強参照) およびソフト参照 (ソフト参照) ストレージの使用が含まれます。物体。
Open Terracotta 以下を提供する JVM レベルのオープンソース クラスタリング フレームワーク: HTTP セッション レプリケーション、分散キャッシュ、POJO クラスタリング、および分散アプリケーションの調整を実現するクラスタ全体にわたる JVM (コード インジェクションを使用するため、何も変更する必要はありません) )。
sccache SHOP.COM によって使用されるオブジェクト キャッシュ システム。 sccache は、インプロセス キャッシュおよび第 2 レベルの共有キャッシュです。キャッシュされたオブジェクトをディスクに保存します。関連するキー、任意のサイズのキー、および任意のサイズのデータをサポートします。ガベージ コレクションを自動的に実行する機能。
Shoal Shoal は、フォールトトレラントで信頼性が高く、利用可能な Java アプリケーションを構築するためのインフラストラクチャ サポートを提供する、Java ベースのスケーラブルな動的クラスタリング フレームワークです。このフレームワークは、特定の通信プロトコルに関連付けられたくないが、クラスターおよび分散システムのサポートが必要な Java 製品に統合することもできます。 Shoal は、GlassFish および JonAS アプリケーション サーバー用のクラスタリング エンジンです。
Simple-Spring-Memcached Simple-Spring-Memcached は、MemCached への呼び出しをカプセル化し、MemCached クライアントの開発を非常にシンプルにします。
以上がJava での高同時実行ソリューションと高負荷最適化の例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。