0

問題は（一言で言えば）次のとおりです。

現在のソリューションは遅すぎます。

  1. Symfony Security コンポーネントは、すべてのページビューでユーザーをリロードします。
  2. ユーザーは、低速の外部 API にアクセスする独自の UserProvider から読み込まれます。

私たちの頭に浮かぶ最初のアイデアは次のとおりです。

外部 API からの情報をローカル データベースまたは memcache にキャッシュできます。

私の質問:

  1. これを実現するのに役立つバンドルはありますか?
  2. 独自の UserProvider ですべてのキャッシュを処理する必要がありますか?
  3. キャッシュする必要があるユーザーをドクトリンエンティティに入れ、チェーンプロバイダーを使用して最初にドクトリンからロードする方が良いでしょうか? この場合、ユーザー オブジェクトの限られた有効期間をどのように処理すればよいでしょうか。
  4. 何もキャッシュせずに、プロバイダーの更新関数を作成して、最後のリロードがあまりにも前に発生した場合にのみユーザーをリロードするようにするのはどうですか?

これを効率的に行う方法に関する他のアイデアはありますか?

乾杯、

ティモン

4

1 に答える 1

0

外部プロバイダーの変更 (パスワードの変更など) が発生したときにユーザーを無効にするロジックを実装する必要があるため、キャッシュも連鎖プロバイダーも「完璧な」ソリューションではありません。私の理解が正しければ、API を頻繁にチェックする必要があります。パフォーマンスと更新の頻繁なチェックとの間で、何らかの方法で妥協する必要があるようです。

そうは言っても、API を介してユーザーを読み取るカスタム ユーザー プロバイダーが既にあると仮定し、それに依存関係としてキャッシュを追加したり、UserProvider の隣に 2 つ目の CacheApiUserProvider を作成したりすることに問題はないと思います。キャッシュバックエンドに問題がある場合は、それらの間で。そのために必要な追加のバンドルはないと思いますが、キャッシングバンドルを探すことをお勧めします。

(3) で提案されているような連鎖プロバイダーがどのように役立つかわかりません。キャッシュと同じように、外部プロバイダーの変更を頻繁に確認するという同じ制限があるためです。私が選択しなければならない場合、私は CachedProvider を使用します。それはあなたがやろうとしていることのほとんどです.シンプルです）。

API が提供するものによっては、API から新しいユーザーと既存のユーザーへの変更を自動的に取得し、それらを (ローカル) データベースに移動するワーカーをバックグラウンドで実行できる場合がありますが、その場合はわざわざ設定する必要はありませんチェーンされたプロバイダーを起動し、データベースが最新であることだけに依存します。

于 2013-10-22T14:33:21.637 に答える