問題タブ [high-availability]

mysql のマスター/スレーブ フェイルオーバー プロセスを簡単にする製品はありますか? 手動で修正するのではなく、自動的に発生する可能性があります。

Web アプリケーションのモジュール化に関する意見を募集しています。言語に関係なく、ほとんどのアプリケーションにはすでにバックエンド DB があり、それぞれの Web アプリケーション サーバー (Apache、IIS、Lighttp など) との連携をサポートしていますが、私が扱った多くの開発者は、Memcached などの使用に問題を抱えています。 Web アプリの即時プロセス空間の外側。

Web アプリケーションのモジュール化は、私が信じているように良いことなのか、それともビジネス ロジックの特定の部分を Web フロント エンドから移動することをシニア デベロッパーから CTO に至るまで躊躇させている何かが欠けているのでしょうか。特殊なバックエンド サービス?

たとえば、数年前、非常にトラフィックの多い Web サイトのプロジェクト設計会議で、フロント エンド フレームワークからプロセス集約型の ACL ロジックを取り除き、それをセミクラスタリング可能なサービス アプリケーションに変えることを提案したとき、私は打ちのめされました。バックエンド。私にとってのメリットは、コードをより明確に分離できることと、たとえば PHP と Python の間のブリッジとして REST/JSON を使用することで、複数の場所で ACL ロジックを再利用できることでした。

私のアイデアに反対した開発者は、「複雑すぎる」と主張しましたが、どうすればいいのかわかりませんでした。私の主張は、プレゼンテーション レイヤーにタグ スープが存在する可能性があるのと同じように、コードのロジック スープが存在する可能性があり、多くの場合、問題が発生した場合に「外科的」修正を実行することはほぼ不可能になる可能性があるということです。

要するに、大規模なアプリケーションを独立しているが協調的なプロセス（スレッドやサブリクエストではない）に分割することの短所と長所は何ですか。MySQL、Memcache、同様のサービス プロセスは優れていますが、他のサービス プロセスが優れているのはなぜでしょうか? この道のりはどのように「複雑すぎる」のでしょうか?

現在、Linux ボックスで Java 統合アプリケーションを実行しています。まずはアプリ概要から。

Java アプリケーションはスタンドアロン アプリケーションです (OracleAS、WebLogic、JBOSS などの Java EE アプリケーション サーバーにはデプロイされません)。スタンドアロンとは、デスクトップ アプリケーションではないことを意味します。ただし、メイン クラスのコマンド ラインから実行されます。ユーザーはこのアプリケーションを直接操作しません。メッセージはAPIを使用してキューにダンプされ、24時間年中無休で実行されているアプリケーションによって読み取られます。ユーザーはデスクトップ アプリと直接対話しないため、これをデスクトップ アプリとは見なしません (これがデスクトップ アプリとして認定する正しい理由かどうかはわかりません)。

Spring を使用し、WebSphere MQ および Oracle データベースに接続します。WebSphere MQ のキューをリッスンする Spring リスナー (Spring Message Driven POJO) を使用します。キューにメッセージがあると、アプリケーションは MQ からメッセージを読み取り、それをデータベースにダンプ (挿入/更新) します。

問題は次のとおりです。

1. このアプリケーションを水平方向にスケーリングするにはどうすればよいでしょうか? より多くのボックスを配置して、この同じアプリケーションの複数のインスタンスを実行するだけということですが、それは実行可能なアプローチですか?
2. Spring MDP から EJB MDB への移行を検討する必要がありますか? これにより、アプリケーション サーバーにデプロイされます。そうすることで何か追加の利点はありますか？
3. アプリケーションを高可用性 (HA) にする要求がありますか? スタンドアロン アプリケーションの HA を実現するために導入できる、推奨される方法論または戦略は何ですか?

Hibernate が生き残るデータベース (この場合は MySQL) への変更 (データ、スキーマなど) は?

これは、Hibernate のダウンタイムがゼロであるためです。

データベースを変更し、アプリ サーバーを 2 つのクラスターに分割し、クラスターの 1 つにアプリケーションを再デプロイして、アプリケーションを切り替えます。

ありがとうステファン

私はSOAの世界に全く慣れていません。そのため、私はいくつかの「SOAフレームワーク/テクノロジー」を調べ、それらを利用して高度にスケーラブルな（Facebookクラスの）Webサイトを構築する方法を理解しようとしています。

私がここで解決しようとしているいくつかの「痛み」があります：

1. 構成可能性（+依存関係の管理、Pub / Sub）
2. サービスの言語に依存しない
3. スケーラビリティとパフォーマンス
4. 高可用性

上記の基準のサブセットに答えるいくつかのテクノロジーを調べました。

1. Thrift -FacebookのクロスプラットフォームRPCプラットフォーム
2. WCF -SOAP、JSON、RESTをサポートしているため、言語の相互運用性があると見なすことができます。Javaプロキシの生成に使用できるWSDLファイルを生成します。
3. Microsoft DSS-私の調査にそれを含めただけですが、それは高度に状態主導で.NET固有であるため、関連性がないようです。
4. ウェブサービス

これで、上記から構成可能性と言語非依存性のいくつかの側面をどのように得るかを理解しました。しかし、スケーラビリティと高可用性のために上記/他のツールを使用する方法についての具体的な情報（話題ではない）はあまり見つかりませんでした。だから最後に私は私の質問に行きます：

上記で定義した問題を解決するために、SOAテクノロジーをどのように活用しますか？そのためのテクニカルガイドはどこにありますか？システム図だけでなく、実際のライブラリ、コードサンプル、APIを探しています...

私は社内の予測ダイヤラ製品を持っているソフトウェアショップで働いており、DO-NOT-CALLリストに従うためのソリューションを実装する必要があります。

基本的に、私は電話をかける必要のある顧客/見込み客のデータベースと、電話をかけられない電話番号のデータベースを持っています。システムは予測ダイヤラーであるため、操作のパフォーマンス、時間平均などに基づいて、ログに記録されたシステムユーザーごとに多かれ少なかれコールをダイヤルします。通常、この「マジック」番号は、ログに記録されたエージェントごとに約3〜4回の呼び出しです。

予測ダイヤラの電話番号リポジトリはPostgreSQLデータベースです。予測ダイヤラはデータベースから一連の番号を取得し、その束をダイヤルするコマンドをpbxに送信します。その後、ビジネスロジックは、有効な通話をコールセンターの担当者などに転送します（これは私の場合は関係ありません）。問題は電話の前にあります）。

呼び出し禁止リスト機能を実装する必要があります。この電話禁止リストは、政府機関からCSVファイルで毎日提供されます。新しいCSVファイルを受け取るたびに、古いdo-not-call-listを削除して、新しいファイルを配置する必要があります。

それを実装するための私の最初の考えは、バッチ処理を実行し、DO NOTCALLLISTを現在の顧客データベースと相互参照することでした。ただし、両方のデータベースのサイズによっては、相互参照のパフォーマンスが非常に高くなり、一晩で完了できない場合もあると思います。私は以前にバッチ処理でこの種の問題を抱えていましたが、それを見るのは良いことではありません。

私の2番目のアイデアは、大規模な機関がクレジットカードやユーザー認証/承認などの高性能で高スループットの承認システムをどのように処理するかを考えたときに思いついたものです。DO NOT CALL LIST番号の認証サービスを作成し、ダイヤラのアルゴリズムを変更して、ダイヤルする前にこの認証サービスに対して各番号をチェックするのが適切だと思いました。

私はここで作話をしているだけなので、どちらのアイデアが最適か、または完全に間違っていて別の方向に目を向けるべきかどうかはわかりません。だから、私の質問は：あなたの推薦は何でしょうか？CSVファイルをメモリに保存しますか？LDAPを使用しますか？MySQLを使用しますか？PostgreSQL？バッチ処理はしますか？それとも私は間違いなくねじ込まれていますか？

このような問題を抱えているのは私が世界で初めてではないことを私は知っているので、私に教えてください。

高可用性とディザスタリカバリに関してJavaアプリケーションの最悪の慣行を監査する必要がある場合は、ハードコードされたIPアドレスとバインドハンドルの最適ではないキャッシングを探すことになるでしょう。他に何を考慮する必要がありますか？

同様に、避けるべき設計パターンはありますか?

したがって、次のように設定されたNサイズのサーバー配列があるとしましょう。

代替テキスト http://www.terracotta.org/web/download/attachments/43909161/ServerArrayMirrorGroup.png

私は単純な JavaBean/POJO を持っています:

ここで、クライアントの 1 つが TC ルート (データ構造) の Person オブジェクトで Person.setObj(OtherObject) を呼び出すと、そのクライアントの同期ブロック(Person.setObj(OtherObject) 内) が保持されます。

1) Nサイズのサーバー配列内のN個のサーバーすべてがその Person.obj 属性と同期/更新されるまで?

また

2) 「アクティブな」サーバーがその更新された Person.obj 属性と同期されるまで? 次に、アレイ内の他の ( N-1 ) サーバーは可能な限り同期されますか?

また

3）私が見ている他の方法はありますか？

ActiveMQ サービスの HA を実装するのに少し問題があります。現在、Active MQ のマスター/スレーブ ブローカーを正しく実装しているため、マスターが停止すると、スレーブが透過的にメッセージ配信を引き継ぎます。どちらも Microsoft SQL データベースを共有してメッセージを保存します。

データベースのミラーリングを確実にするために、別のレベルの高可用性を追加したいと考えていました。このように、プリンシパル DB サーバーが停止すると、ブローカーはミラー化されたサーバーに切り替わります。ミラーリングを正しくセットアップしました。(データはセカンダリ DB サーバーに正しくミラーリングされます)。

問題は、DB フェイルオーバーがすべてを台無しにすることです。

ご存じのとおり、ActiveMq ブローカーのマスター/スレーブ HA は次のように機能します。マスターは DB のロックを取得し、スレーブはそれを取得しようとします。マスターが停止するとすぐにロックが解放され、スレーブが引き継ぎ、クライアントは新しいマスターに切り替わります。DB ミラーリングに問題があります。プリンシパル DB サーバーをシャットダウンすると、マスターはデータベース ロックの更新に失敗します。一方、スレーブは、プリンシパル DB サーバーでロックを取得できない場合、セカンダリを試行しますが、ミラーリングされた状態であるため、もちろんできません。

ActiveMQ にマスター/スレーブ HA を使用しない場合 (その場合は 1 つのブローカーのみ)、DB ミラーリングは機能します。

マスターの構成ファイルとログは次のとおりです。

そしてマスターの出力：

スレーブの構成ファイル: