2016-08-08 8 views
2

私たちは実稼働環境で動作するmemcachedクラスタを持っています。ここでは、memcachedを永続キャッシュ層としてCouchbaseクラスタに置き換えます。問題は、この切り抜きを実装する方法と、Couchbaseバケットをウォームアップする方法です。当然のことながら、古いキャッシュから開始するとサイト全体がダウンするので、単にコールドCouchbaseに切り替えることはできません。Couchbaseウォームアップの戦略

私が考えていたオプションは、最初にmemcachedノードとしてCouchbaseをウォームアップすることでした。つまり、Couchbaseは(非永続的な)memcachedバケットを使用しており、他のmemcachedノードと同様にキャッシュセット/取得トラフィックを取得しています。良いことは、コードの変更が最小限で済むことです(必要なのは、memcachedトラフィックを受け取るようにmoxiプロキシを設定し、そのノードをmemcachedノードとして登録することです)。後で、すべてのmemcachedバケットをCouchbaseに変換します。しかし、Couchbaseがこれらの2種類のバケットの間の変換をサポートしているかどうかは分かりません。

第2のオプションは、最初に永続的なCouchbaseバケット(非永続的なmemcachedバケットではなく)を設定します。本番キャッシュクライアントを変更して、すべてのトラフィックをmemcachedクラスタとcoucbaseクラスタの両方に複製します。私たちはCouchbaseのバケツを監視し、キャッシュ項目が一定のサイズに達すると、カットオーバーを完了します。小さな欠点は、キャッシュクライアントを変更する余分な複雑さです。

思考?

2016年8月9日

上EDIT私は後でバケットはCouchbaseのではサポートされていませんCouchbaseのためにmemcachedのバケットを変換し、判明したよう。したがって、最初の選択肢は実現不可能です。

最後に、各アプリケーションホストにClient-side (standalone) proxyを設定することにしました。我々は、ホストからホストへと徐々にキャッシュトラフィックを増加させる。そうすれば、サイトの変更は十分に小さくなります。

答えて

1

あなたは簡単に、より少ない仕事をしたい場合は、とうまく動作することが証明、次の手順を実行します

  1. は、各アプリケーションサーバー上でMoxiクライアントを設定します。
  2. Couchbaseクラスター上のPoint MoxiからCouchbaseバケットへ。
  3. ローカルのMOXIインストールを指すようにWebアプリケーションサーバーを変更します。
  4. 次のコードリビジョンでは、memcachedではなくCouchbase SDKを使用してコードを変換します。

はい、キャッシュ内で物事が暑くならない時間がありますが、Couchbaseが読み込まれるまでに時間がかかりません。この方法は、常に切り替えて使用されます。それは簡単で、ほぼばかばかしい証拠です。私が人々が見たことの一つは、切り取る前に、既存のmemcachedサーバからCouchbaseにコピーしようとすることです。しかし、私が確信していないのは、memcachedの各価値の鍵がどう新しいかです。

また、Moxiはmemcachedから簡単に立ち去るための暫定的なステップですが、それは素晴らしいことですが、長期的にはSDKに切り替える方がはるかに優れています。 SDKには純粋なmemcachedよりも多くの機能があります。

memcachedバケットには、CouchbaseのHA、永続性などの機能がないため、使用しないでください。

+0

ありがとう、カーク。これが最終的に決まるのです。アプリケーション側の灸は合理的な選択のようです。現時点では、このような設定を残してSDKに切り替えることもできます。これは、コード内のキャッシュクライアントの切り替えが苦労するためです。 –

+0

また、切り取る前にmemcachedからcoucbbaseにコピーするのと同じ質問。それは問題を解決するよりも複雑さを増すようです。 –