私たちは実稼働環境で動作する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を設定することにしました。我々は、ホストからホストへと徐々にキャッシュトラフィックを増加させる。そうすれば、サイトの変更は十分に小さくなります。
ありがとう、カーク。これが最終的に決まるのです。アプリケーション側の灸は合理的な選択のようです。現時点では、このような設定を残してSDKに切り替えることもできます。これは、コード内のキャッシュクライアントの切り替えが苦労するためです。 –
また、切り取る前にmemcachedからcoucbbaseにコピーするのと同じ質問。それは問題を解決するよりも複雑さを増すようです。 –