0

だから私はRailsアプリケーションを持っています。現在、フロントエンドとバックエンド + データベースとして別々に実行されています。

複数のバックエンド サーバーを持つように拡張する必要があります。

バックエンド サーバーには Resque バックグラウンド ワーカーが実行されています (ユーザーのフロントエンド リクエストによって生成されます)。また、コールバックにも大きく依存しています。

以下の編成を予定しています。

|front-end| --- |load-balancer (haproxy or AWS ELB)| --- Server 1 ---- Postgresql Database (+++ other DBs added via replication later if needed)
                                                    \___ Server 2 ---/
                                                                    ++ (other servers added in the same fashion later )

この場合、データベースを別のマシンに配置する方法について懸念があります。

1) 最初のバックエンドと同じスキーマを持つ新しい空の Rails アプリを作成するつもりです。実行して HTTP 経由で更新/投稿を受け入れ、リモート SSH 経由で接続を維持します (バックエンドで :after_commit コールバックをトリガーするため)。それは良い考えですか？

2) Postgresql を使用していますが、必要に応じてエンタープライズ DB に切り替える予定です。現在必要なのは、データベースではなく処理を行うバックエンドの部分をスケーリングすることです。

3) このアプローチはスケーラブルに見えますか?

4

1 に答える 1

1

あなたの質問を本当に理解しているかどうかわかりません。通常、本番アプリケーションでは、データベース層はアプリケーション層から分離されています。これがあなたに当てはまるかどうかはわかりませんが、間違いなく興味深い時計です。http://vimeo.com/33263672 . Rails レイヤーと db レイヤーの間に redis レイヤーを使用してキューイングを容易にし、ゼロ ダウンタイム環境を作成することについて説明しています。2 番目の Rails スタックを使用するよりも優れたソリューションになると思われますか? 私はそれがこのように見えるべきだと思います;

|ELB| Web サーバー |ELB| アプリケーション サーバー |RRDNS| Redis サーバー | PostGreSQL サーバー |

私があなたの意味を理解していれば。そうでない場合でも、そのビデオ リンクは一見の価値があります :)

于 2012-10-04T23:42:29.537 に答える