1

私はアプリを持っています...

このアプリは、金融商品の市場比較を行います。特定の見積もり要求に対して、他のいくつかのサイトに連絡して見積もりを求めます。次に、ユーザーに結果 (詳細のいくつかの引用符) を提供します。

これらのリクエストを管理するために、リクエストは MySQL に保存され、アプリが起動して保留中の見積もりを取得し、これらをスレッド (すべて同じ Linux ボックス) にファームして、各サイト ルックアップを処理します。

スレッド/データベース関連の問題があったため、JRuby を使用しています。Java スレッドプールを使用してスレッド数を制御します。現在のハードウェア/VPS では、約 200 スレッドを処理できます。多くの制限は、各スレッドが独自の MySQL 接続を取得することに関連しているようです - 見積もりの​​詳細を取得し、結果を保存します。より多くの同時スレッドを処理したいので、スケールアップする方法を探しています。

どっちにしようか迷う…

  1. より大きなハードウェア...
  2. より多くのマシンと、ある種のキューイング メカニズム (優先順位付き) を使用して、マシン間で負荷を共有するため、スレッドはデータベースに触れず、すべての詳細/応答はキューを介して送信されるため、DB ヒットは少なくなりますが、おそらく私は問題をキューに入れているだけです。キューにMongoDBのようなものを使用することを考えていますが、提案は受け付けています-Rubyで簡単に使用できるもの:)
  3. ある種のリモート/RPC メカニズム、たとえば dRb - 理論的にはこれは良いオプションのように見えますが、これがどれほど複雑になるかを知るためにまだ何もしていません。
  4. 他に何か…？

このリンクからスケールアップしない理由と-アウト? - この問題は、より多くのマシンを実行して解決するのに適しているようです。

では、どの道に進むべきかについての考えは...

乾杯、クリス

4

2 に答える 2

2

このような問題に対する私の通常のアプローチは、作成しているデータベース クエリに細心の注意を払い、積極的に調整することです。明示的に使用されていない列をスキップして、必要なものだけを取得し、必要のないもの全体を熱心にロードすることには十分注意してください。

インデックスを追加したり、データベース内の特定の属性を戦略的に非正規化したりして、醜く時間のかかるJOIN操作を回避することで、速度が大幅に向上することがよくあります。

さらに、キャッシングについて考えてみてください。最速のデータベース呼び出しは、一度も行われたことがない呼び出しです。Memcached のようなものを利用して、適度に時間のかかるレコード取得の結果を保存することは難しくありません。慎重に行えば、更新をいくつかの方法でチャネル化すれば、これを無効にして期限切れにすることさえ簡単です。

ワーカーをスケジューリングするために、単純な先入れ先出しキューを Redis に実装して、MySQL 自体から多くの処理オーバーヘッドをオフロードできます。これは通常、例に従えば非常に簡単に追加できます。

Memcached のようなキャッシュは非常に大量のトラフィックを処理できるため、可能な限りこれに対してキャッシュして、最後のすべてのデータベースにアクセスしないようにします。

これらのオプションを使い果たした場合は、フロントエンド サーバーを追加し、データベースの容量をさらに増やす必要があります。

于 2013-01-08T21:08:14.900 に答える
1

キューイングは、実装するのが最も簡単な方法です。次のようなものを使用してください：http：//beanstalkd.github.com/beaneater/

基本的に、メソッドの前にメソッドを追加して、async.それらをキューに入れて実行することができます。それらはキューに入れられ、ワーカーは同じサーバーでも別のサーバーでもかまいません。

于 2013-01-08T21:15:39.827 に答える