ホームページ  >  記事  >  Java  >  Java システムにおける同時実行性の高さの問題の解決

Java システムにおける同時実行性の高さの問題の解決

黄舟
黄舟オリジナル
2017-09-21 10:22:561173ブラウズ

この記事は主に Java システム向けの高同時実行ソリューションを紹介します。内容は非常に充実しているので、必要な友人は参照してください。

個人の Web サイトなどの小規模な Web サイトは、いくつかの画像を使用して最も単純な HTML 静的ページを使用して実装できます。このような Web サイトには、システム アーキテクチャとパフォーマンスの要件があります。インターネットビジネスの高度化に伴い、Web サイト関連の技術は長年の開発を経て非常に細分化され、特に大規模な Web サイトでは、ハードウェアからソフトウェア、プログラミングに至るまで、広範囲にわたる技術が使用されています。言語、mysql" target="_blank" title="MySQL Knowledge Base"> データベース、Web サーバー、ファイアウォール、その他の分野には非常に高い要件があり、元の単純な HTML 静的 Web サイトとは比較できなくなりました。

大規模な Web サイト、ポータルなど、多数のユーザーのアクセスや同時リクエストに直面した場合、基本的なソリューションは、高性能サーバー、高性能データベース、効率的なプログラミング、および高性能 Web コンテナーの使用に重点を置きます。しかし、これらの側面とは別に、大規模な Web サイトが直面する高負荷と高同時実行の問題を根本的に解決する方法はありません

上記の解決策は、ある程度のコストがかかることを意味しており、この解決策にはボトルネックと問題があります。低コスト、高パフォーマンス、高スケーラビリティの観点から私の経験をいくつかお話します

1. 実際、純粋に HTML が最も効率的で消費量が少ないことは誰もが知っています。静的な HTML ページを使用するため、Web サイトのページにはこの最も単純な方法が最も効果的です。しかし、大量のコンテンツがあり、頻繁に更新される Web サイトでは、すべてを手動で実装することはできません。そこで私たちの共通情報公開システムCMSが登場し、私たちが頻繁に訪問するさまざまなポータルサイトのニュースチャンネルやその他のチャンネルもすべて情報公開システムを通じて管理および実装され、最も簡単な情報入力を実現できます。静的ページの自動生成も可能で、大規模なWebサイトでは効率的で管理しやすいCMSが必須です。高い対話性が求められるコミュニティ タイプの Web サイトでは、パフォーマンスを向上させるためにできるだけ静的であることも必要な手段です。また、コミュニティ内の投稿や記事をリアルタイムで静的にし、存在する場合に再静的にするという戦略も広く使用されています。 NetEase コミュニティと同様に、Mop の hodgepodge もこの戦略を使用します。同時に、静的 html は、システム内でデータベース クエリを頻繁に使用するが、非常に小さいキャッシュ戦略でも使用されます。コンテンツの更新を行うには、フォーラムの公開設定情報などの HTML 静的化を使用することを検討できます。この情報は現在、バックグラウンドで管理され、データベースに保存されます。フロントエンド プログラムによって大量に更新されますが、更新頻度は非常に低いため、バックグラウンド更新中にコンテンツのこの部分を静的にすることを検討して、大量のデータベース アクセス要求を回避できます。

2. 画像サーバーの分離

ご存知のとおり、Web サーバーでは、Apache、IIS、その他のコンテナーのいずれであっても、画像が最も多くのリソースを消費するため、画像をページから分離する必要があります。これは、基本的に大規模な Web サイトで採用されている戦略であり、すべての Web サイトには独立した画像サーバー、さらには多数の画像サーバーがあります。このようなアーキテクチャにより、ページ アクセス リクエストを提供するサーバー システムへの負荷が軽減され、画像の問題によってシステムがクラッシュすることがなくなります。たとえば、Apache では、アプリケーション サーバーと画像サーバーでさまざまな構成の最適化を実行できます。 ContentType を構成するときは、システム消費量と実行効率を高めるために、サポートを最小限にし、使用する LoadModule をできるだけ少なくしてください。

3. データベース クラスターとデータベース テーブルのハッシュ
大規模な Web サイトには複雑なアプリケーションがあり、これらのアプリケーションでは大量のアクセスに直面すると、データベースのボトルネックがすぐに明らかになります。やがて、1 つのデータベースではアプリケーションを満足できなくなるため、データベース クラスタリングまたはデータベース テーブル ハッシュを使用する必要があります。


データベース クラスターに関しては、Oracle、Sybase などに独自のソリューションがあります。MySQL が提供する一般的なマスター/スレーブも同様のソリューションです。実装するには、対応するソリューションを参照してください。

上記のデータベース クラスターは、アーキテクチャ、コスト、拡張性の点で使用する DB の種類によって制限されるため、アプリケーションの観点からシステム アーキテクチャの改善を検討する必要があります。ライブラリ テーブルのハッシュは一般的に使用され、最もよく使用されます。効果的な解決策。アプリケーションにビジネス モジュールとアプリケーション モジュール、または機能モジュールをインストールして、データベースを分離します。さまざまなモジュールがさまざまなデータベースまたはテーブルに対応し、特定の戦略を使用して、特定のページまたは機能で小さなデータベース ハッシュ (ユーザー テーブルのハッシュなど) を実行します。ユーザー ID に応じてテーブルを作成することで、低コストでシステムのパフォーマンスを向上させることができ、優れた拡張性を備えています。 Sohu のフォーラムは、フォーラムのユーザー、設定、投稿などの情報をデータベースに分離し、投稿とユーザーをセクションと ID に従ってデータベースとテーブルにハッシュするという構造を採用しており、最後に設定で簡単に設定できます。これにより、システムはいつでも低コストのデータベースを追加して、システムのパフォーマンスを補うことができます。

4. キャッシュ

技術者なら誰でもキャッシュという言葉を聞いたことがあるでしょう。キャッシュは多くの場所で使用されています。 Web サイトのアーキテクチャおよび Web サイト開発におけるキャッシュも非常に重要です。ここではまず、最も基本的な 2 つのキャッシュについて説明します。高度な分散キャッシュについては後で説明します。

アーキテクチャ上のキャッシュに関しては、Apache に詳しい人なら誰でも、Apache が独自のキャッシュ モジュールを提供していること、またはキャッシュ用に追加の Squid モジュールを使用できることを知っているでしょう。どちらの方法でも、Apache のアクセス応答機能を効果的に向上させることができます。

Web サイトのプログラム開発におけるキャッシュ、Linux で提供される Memory Cache は、Web 開発で使用できる一般的なキャッシュ インターフェイスです。たとえば、Java で開発する場合、MemoryCache を呼び出して一部のデータをキャッシュし、通信することができます。大規模コミュニティはこのアーキテクチャを使用しています。さらに、Web 言語開発を使用する場合、基本的に各言語には独自のキャッシュ モジュールとメソッドがあり、PHP には Pear の Cache モジュールがあり、Java には .net にはさらに多くのモジュールがあるはずです。

5. ミラーリング

ミラーリング テクノロジーは、チャイナネットやネットワーク アクセス プロバイダーや地域によって生じるユーザーのアクセス速度の違いを解決するために、大規模な Web サイトでよく使用される方法です。 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 層スイッチの原理を誰もが知った後、そのようなソリューションの原理は一貫しています。 、パフォーマンスはわずかに悪くなります。ただし、ある程度の圧力に対処するのは簡単ですが、ソフトウェアの実装方法は実際にはより柔軟であり、処理能力は設定の習熟度に完全に依存するという人もいます。
Linux で一般的に使用されている LVS を使用して、ソフトウェア 4 層スイッチングを解決します。LVS は、ハートビート ラインに基づいたリアルタイムの災害対応ソリューションを提供し、システムの堅牢性を向上させ、柔軟な仮想化を提供します。構成および管理機能は、複数のアプリケーション要件を同時に満たすことができ、これは分散システムにとって不可欠です。

典型的な負荷分散戦略は、ソフトウェアまたはハードウェアの 4 層スイッチングに基づいて Squid クラスターを構築することです。このアイデアは、検索エンジンを含む多くの大規模 Web サイトで採用されており、低コストで高性能です。拡張性が高く、いつでもアーキテクチャにノードを追加または削除するのが非常に簡単です。この構造を詳しく整理して議論していきたいと思います。

1: 同時実行性が高く負荷の高い Web サイトで中心となるデータベース

はい、最初はデータベースで、これはほとんどのアプリケーションが直面する最初の SPOF です。特に Web2.0 アプリケーションの場合、データベースの応答を最初に解決する必要があります。

一般的に、最初は 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. php4 の mysql 接続プールには問題が発生することが多いため、永続リンクを使用しないでください (pconnect を使用しないでください)。代わりに、sqlrelay などのサードパーティのデータベース接続プールを使用するか、単に自分で実行します。

2: 同時実行性が高く負荷の高い Web サイトのシステム アーキテクチャのための静的 HTML

実際、最も効率的で消費量が最も少ないのは純粋に静的なページであることは誰もが知っているので、私たちは当社 Web サイトのページ これを実現するために静的ページを使用するのが最も簡単な方法であり、実際に最も効果的な方法です。しかし、コンテンツ量が多く、更新頻度も高いWebサイトでは、1つ1つ手作業で導入することはできません。そこで、私たちがよく見るさまざまなポータルサイトのニュースチャンネルや、その他のポータルサイトのニュースチャンネルなど、共通の情報公開システムCMSが登場しました。情報公開システムは、最も簡単な情報入力を実現し、チャネル管理、権限管理、自動クローリングなどの機能を備えています。大規模な Web サイトには、効率的で管理しやすい CMS が不可欠です。ポータルや情報公開 Web サイトに加えて、高い対話性が求められるコミュニティ型 Web サイトの場合、コミュニティ内の投稿や記事をリアルタイムで静的に更新し、可能な限り静的であることもパフォーマンスを向上させるために必要な手段です。 -静的化は、NetEase コミュニティと同様に、Mop の hodgepodge も広く使用されている戦略です。

同時に、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的),并指定域名为res1.***.com,res2.***.com,采用

ajp协议

步骤二:修改Apache httpd.conf配置

原来应用的文件上传功能网址为:

1、/fileupload.html

2、/otherupload.html

httpd.conf中增加如下配置


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
#
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
< /VirtualHost>

步骤三,修改业务逻辑:

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

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

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

大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

  在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。

上記のデータベースクラスタは、アーキテクチャ、コスト、スケーラビリティの点で使用するDBの種類によって制限されるため、アプリケーションの観点からシステムアーキテクチャの改善を検討する必要があります。ライブラリテーブルのハッシュは一般的に使用され、最もよく使用されます。効果的な解決策。アプリケーションにビジネス モジュールとアプリケーション モジュール、または機能モジュールをインストールして、データベースを分離します。さまざまなモジュールがさまざまなデータベースまたはテーブルに対応し、特定の戦略を使用して、特定のページまたは機能で小さなデータベース ハッシュ (ユーザー テーブルのハッシュなど) を実行します。ユーザー ID に応じてテーブルを作成することで、低コストでシステムのパフォーマンスを向上させることができ、優れた拡張性を備えています。 Sohu のフォーラムは、フォーラムのユーザー、設定、投稿などの情報をデータベースに分離し、そのデータベースと投稿とユーザーのテーブルをセクションと ID に応じてハッシュ化し、最後に設定で簡単に設定できる構造を採用しています。これにより、システムはいつでも低コストのデータベースを追加して、システムのパフォーマンスを補うことができます。

クラスター ソフトウェアの分類:

一般的に、クラスター ソフトウェアは、焦点の方向性と解決しようとしている問題に基づいて、ハイ パフォーマンス クラスター (HPC)、ロード バランシング クラスター (ロード バランス クラスター (LBC)、高可用性クラスター (高可用性クラスター、HAC)。

ハイ パフォーマンス クラスター (HPC) は、クラスター内の複数のコンピューターを使用して同じタスクを完了するため、タスクを完了する速度と信頼性が単一のコンピューターよりもはるかに高くなります。単体パフォーマンスの欠点を補います。このクラスターは、天気予報や環境監視など、大量のデータと複雑な計算を行う環境で広く使用されています。

ロード バランス クラスター (LBC) は、クラスター内の複数の単一マシンを使用して、多数の並列タスクの小規模ジョブを完了します。一般に、アプリケーションを使用する人が増えると、ユーザーの要求に対する応答時間が長くなり、負荷分散クラスターが使用されている場合は、クラスター内のすべてのマシンがユーザーの要求に応答できるようになります。これにより、ユーザーがサービス リクエストを発行した後、クラスターは、リクエストを受け入れて応答するために最も負荷が低く、最適なサービスを持つマシンを選択します。これにより、クラスターを使用して可用性と安定性を向上させることができます。システムの。このタイプのクラスターは Web サイトでよく使用されます。

高可用性クラスター (HAC) は、クラスター内のシステムの冗長性を利用して、システム内のマシンが損傷した場合に、他のバックアップ マシンがそれを迅速に引き継いで起動します。サービスに連絡し、故障したマシンの修理と返却を待ちます。クラスター内のサービスの可用性を最大化します。このタイプのシステムは、一般に銀行や通信サービスなど、システムの信頼性が要求される分野で広く使用されています。

2 データベースクラスターの現状

データベースクラスターは、コンピュータークラスターテクノロジーをデータベースに導入することによって実装されていますが、各メーカーが自社のアーキテクチャがいかに完璧であるかを主張していますが、Oracle が主導権を握っており、誰もが完璧であるという事実を変えることはできません。 Oracle RAC は、高可用性、高パフォーマンス、データベースの負荷分散、および便利な拡張に対する顧客のニーズを満たすことができるクラスター ソリューションの点で、依然として Microsoft を含む他のデータベース ベンダーよりも優れています。 S ORACLE の Real Application Cluster (RAC)

Microsoft SQL Cluster Server (MSCS)

IBM の DB2 UDB 高可用性クラスター (UDB)

Sybase Ase 高可用性クラスター (ASE)

Mysql 高可用性クラスター ( MySQL CS)


IO に基づくサードパーティ HA (高可用性) クラスター

現在の主要なデータベース クラスター テクノロジには上記の 6 つのカテゴリが含まれており、データベース メーカー自身が開発したものもあれば、サードパーティが開発したものもあります。クラスタ企業 ; サードパーティのクラスタ企業と協力して開発するデータベース メーカーもあり、クラスタごとに実装される機能やアーキテクチャも異なります。


RAC (Real Application Cluster、リアルアプリケーションクラスター)

は、Oracle9iデータベースで使用される新しいテクノロジーであり、グリッドコンピューティング環境をサポートするOracleデータベースの中核テクノロジーでもあります。その登場により、従来のデータベース アプリケーションが直面していた重要な問題、つまり高性能、高い拡張性、低価格の間の矛盾が解決されました。長い間、Oracle は Real Application Cluster (RAC) テクノロジーでクラスター データベース市場を独占してきました


6: 高同時実行性と高負荷の Web サイトのシステム アーキテクチャ - キャッシュ

キャッシュという言葉テクノロジーに携わる人々はそれにさらされており、キャッシュは多くの場所で使用されています。 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 タグ ライブラリは、既存の 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 Object Cache は、基本的なオブジェクト キャッシュ機能を提供する Java ライブラリです。実装される戦略は、先入れ先出し (FIFO)、最近使用されたもの (LRU)、および最も使用頻度の低いもの (LFU) です。すべての戦略は、要素のサイズを最大化し、その生存時間を最大化します。

WhirlyCache Whirlycache は、メモリ内に存在するオブジェクトの高速で構成可能なキャッシュです。データベースやその他のコストのかかるプロセスにクエリを実行して構築する必要があるオブジェクトをキャッシュすることで、Web サイトやアプリケーションを高速化できます。

Jofti Jofti は、キャッシュ層 (EHCache、JBossCache、および OSCache をサポート) または Map インターフェースをサポートするストレージ構造内のオブジェクトのインデックス付けと検索を行うことができます。このフレームワークは、インデックス内のオブジェクトの追加、削除、変更に対する透過性と、検索のための使いやすいクエリ機能も提供します。
cache4jcache4j は、シンプルな 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 サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。