2

AWS ロード バランサーの背後にある 2 つのサーバーで実行されている SilverStripe のインスタンスがあります。セッション情報を共有するために、Elasticache Redis サーバーを実行しています。私は自分のphpセッションストア情報を次のように設定しています:

ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://127.0.0.1:6379');

CMS の管理セクションにサインインした後、サーバー間をジャンプして記憶することができますが、CMS でセクションを切り替えると、メイン セクションがレンダリングされません (AJAX 呼び出し)。私が言えることから、他のサーバーが認識していないこと (2 番目に要求したもの) は既に CMS 管理者がロードされており、応答ヘッダーで JS 依存関係の新しいバージョンをロードするように指示されており、それが管理者を追い出します。読み込まれません。

ドキュメントを読むSilverStripe は、いくつかの追加情報のために Zend_Cache を使用しています。管理インターフェイスをロードしてからキャッシュディレクトリを削除すると、問題が再現されると思います。そうではありません。

次に、このモジュールを使用して、Zend_Cache が使用しているストレージ エンジンを変更しようとしました。追加した：

SS_Cache::add_backend(
    'primary_redis', 
    'Redis',
    array(
        'servers' => array(
            'host' => 'localhost', 
            'port' => 6379, 
            'persistent' => true, 
            'weight' => 1, 
            'timeout' => 5,
            'retry_interval' => 15, 
            'status' => true, 
            'failure_callback' => null
        )
    )
);
SS_Cache::pick_backend('primary_redis', 'any', 10);

私の mysite/_config.php に、これはいくつかの cms 情報を key のように redis に保存CMSMain_SiteTreeHints9b258b19199db9f9ed8264009b6c351bしていますが、負荷分散された環境でサーバー間で変更する問題はまだ解決されていません。

SilverStripe は他にどこにキャッシュ データを保存できますか? モジュールを正しく実装しましたか?

4

2 に答える 2

2

デフォルトの管理インターフェース (3.x を使用していると仮定) は、 と呼ばれる javascript ライブラリを使用しますjquery.ondemand- これは、既に含まれているファイルを追跡します (' require.js' などのかなり古い種類の前身です - AMD を使用せず、CSS を使用する場合のみ)サポート）。

この目的のために、これが CMS 自体と関係がある可能性は最小限です。Web は本質的にステートレスであり、状態を保存するために使用している方法がサーバー間で共有されていることを考えると (データベースとセッション データの両方)。 .

HA クラスター内の個々のインスタンス間で共有されないのは、物理ファイルです。ここでの原因はmtime、提供された URI の末尾のスタンプである可能性があります (ただし、確実ではありません) ondemand。もともとは、テーマの変更 (開発者が作成したか、自動化されたもの) に関するブラウザーのキャッシュの問題を回避することを目的としていました。

間違いなく検査したヘッダーには ( HAProxy、nginx、ELB などによって選択されたエンドポイントに関係なく、常にX-Include-CSS)とX-Include-JS- その例は次のようになります。

X-Include-JS:/framework/thirdparty/jquery/jquery.js?m=1481487203,/framework/javascript/jquery-ondemand/jquery.ondemand.js?m=1481487186,/framework/admin/javascript/lib.js?m=1481487181[...]

これは各リクエストにあり、ondemandすでに含まれているものと追加する必要があるものを調べて確認できます。

(ちなみに、これらのヘッダーのサイズは、「デフォルト」設定でnginxヘッダー バッファーの問題を引き起こす原因です。)502

それで、何をしますか？

静的コードをデプロイしている場合、静的ファイルはバランスの取れたインスタンス間で同じ mtime を維持する必要がありますが、これは確認する必要があります。一方、生成されたファイル ( などRequirements::combine_files) は、サイトのすべての場合と同様に、すべてのインスタンス間で (再) 生成時に同期する必要があります/assets。この場合、mtime は保持されます。Zend_cache要因である可能性はありますが、ここで影響を与える可能性はほとんどありませんAPC。もちろん、どのような場合でも最初に確認することは、私の前提が正しいかどうかです。たとえば、差分ツールを介して両方のバックエンドからヘッダー応答を実行するなどです。

于 2017-01-09T19:59:15.037 に答える
0

これに遭遇する可能性があり、CMS に接続するソリューションが必要な人を助けるために、私は次のことを行いました。

class SyncRequirements_Backend extends Requirements_Backend implements Flushable {

    protected static $flush = false;

    public static function flush() {
        static::$flush = true;
    }

    public function process_combined_files() {
        // You can write your own or copy from framework/view/Requirements.php
        // Do the required syncing like rsync at the appropriate spot like on successfulWrite
    }
}

_config.phpに追加Requirements::set_backend(new SyncRequirements_Backend());します (私のものは別の拡張機能ですが、mysite も機能します)。

このソリューションの問題は、コア Requirements_Backend が更新された場合、古いバージョンのコードを実行することになりますが、何かが壊れる可能性はほとんどなく、同じコードを使用する独自の Requirements バックエンドを実装しただけです。すべてを自分で行う代わりに親を呼び出すこともできますが、ファイルの書き込み時にのみ同期を実行する方法が見つかりませんでした。結合されたファイルが要求されるたびに実行されます。

于 2017-01-10T03:39:47.957 に答える