モバイル クライアントからの API リクエストで提供されるデータを含むサーバーがあります。データは一種の永続性があり、更新頻度は非常に低いです (たとえば、1 週間に 1 回)。しかし、テーブルの設計は非常に重く、API リクエストの処理が遅くなります。
Web サービスは Yii + Postgre SQL で実装されています。
memcached を使用することもできますが、やはり誰もがデータベース サーバーにアクセスすることになります。あなたの場合、クエリ結果は一種の永続的であると言っているので、Web サービスからの JSON 応答をキャッシュする方が理にかなっているかもしれません。
これは、キャッシュが組み込まれたリバース プロキシを使用して実行できます。Jetty (Java) と NGINX を使った例は、次のように最も役立つと思います。
このセットアップでは、モバイル クライアント用の API を提供する Jetty (Java) インスタンスがあります。API は localhost:8080/api をリッスンしており、ローカルの Mysql データベースのいくつかのクエリから取得した JSON 結果を返します。
この時点で、API をクライアントに直接提供できますが、ここではリバース プロキシを使用します。
API の前には、0.0.0.0:80/ (どこでも、ポート 80) をリッスンする NGINX Web サーバーがあります。モバイル クライアントが 0.0.0.0:80/api に接続すると、組み込みのリバース プロキシが正確なクエリ文字列を取得しようとします。それはキャッシュです。これが失敗した場合、localhost:8080/api から取得し、キャッシュに入れ、キャッシュで見つかった新しい値を提供します。
利点：
キャッシュの無効化について考えてみましょう:
キャッシュの無効化について考える必要があります。たとえば、localhost:8080/api に対するすべての HTTP 200 リクエストに対して 1 週間、または他のすべての HTTP ステータス コードに対して 1 分間、キャッシュを保持するように NGINX に指示できます。しかし、API を 1 週間以内に更新したい時が来たら、キャッシュは無効なので、何らかの方法で削除するか、キャッシュ時間を 1 時間または 1 日に減らす必要があります (ほとんどの人がキャッシュ）。
これが私たちの仕事です。キャッシュが汚れている場合は、キャッシュを削除することにしました。Puppet を介してトリガーされたUpdate-API イベントをリッスンしているサーバー上で別の JOB が実行されています。JOB は、NGINX キャッシュのクリアを処理します。
もう 1 つのアイデアは、Web サービス内にキャッシュのクリア機能を追加することです。この解決策を採用しないことにした理由は、Web サービスがリバース プロキシの背後で実行されていることを認識しなければならないため、関心の分離が壊れてしまうからです。しかし、それはあなたが何を計画しているかによります。
Web サービスをより適切にするもう 1 つの方法は、各 JSON ファイルで正しい ETAG ヘッダーとキャッシュ有効期限ヘッダーを提供することです。繰り返しますが、ファイルごとに小さな更新イベントではなく、大きな更新イベントが 1 つあるため、これは行いませんでした。
補足:
したがって、Web サービス + SSL の前に Varnish を使用する場合は、NGINX -> Varnish -> Web Service のような構成を使用します。
参考文献: - NGINX サーバー: http://nginx.com - Varnish リバース プロキシ: https://www.varnish-cache.org - Puppet IT Automation: https://puppetlabs.com - NGINX リバース プロキシ チュートリアル: http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html