Symfony Cache コンポーネントはしばしば開発者のアーセナルで最も使用されていないツールです. ほとんどの実装は「Redis をインストールする」で停止し、いくつかのデータベース呼び出しを 1 つに包装します。 機能的である一方で、これは高流量、分散環境でコンポーネントができることの表面をめちゃくちゃにします。 $cache->get() Symfony 7.3 では、キャッシュ コンポーネントはキー 価値のストアだけではなく、レイアウト アーキテクチャ、確率的なスタンプ 保護、透明な暗号化を可能にする高度なシステムです。 この記事では、高価な建築問題を解決する重要なキャッシュ戦略について説明します。 で、 (牛の群れ) (※) )および . latency concurrency security GDPR distributed invalidation The Architecture of Latency: Tiered (Chain) Caching(レイヤード・チェーン・キャッシュ) マイクロサービスアーキテクチャや高トラフィックモノリスでは、Redisへのネットワーク呼び出し(通常1～3ms)は、最終的にローカルメモリ(ナノ秒)に比べてボトルネックになる可能性があります。 解決策はA 効果的に行動するように、 あなたのアプリケーションのためのキャッシュ で、 . Chain Cache L1/L2 CPU L1 is local (APCu) L2 is shared (Redis) 構成 APCu から読み取るプールを最初に設定します. 見逃した場合は、Redis から読み取ります. 次に APCu から読み取ります. composer require symfony/cache symfony/orm-pack redis
 コンピュータ( ) : config/packages/cache.yaml framework:
    cache:
        # Prefix all keys to avoid collisions in shared Redis instances
        prefix_seed: '%env(APP_SECRET)%'

        pools:
            # L2 Cache: Redis (Shared)
            cache.redis:
                adapter: cache.adapter.redis
                provider: 'redis://%env(REDIS_HOST)%:6379'
                default_lifetime: 3600 # 1 hour

            # L1 Cache: APCu (Local Memory)
            cache.apcu:
                adapter: cache.adapter.apcu
                default_lifetime: 60 # Short TTL to prevent stale local data

            # The Chain: L1 + L2
            cache.layered:
                adapter: cache.adapter.chain
                provider: [cache.apcu, cache.redis]
 利用 ターゲット属性を使用して特定のプールを注入します。 namespace App\Service;

use Symfony\Component\DependencyInjection\Attribute\Target;
use Symfony\Contracts\Cache\CacheInterface;
use Symfony\Contracts\Cache\ItemInterface;

class DashboardService
{
    public function __construct(
        #[Target('cache.layered')]
        private readonly CacheInterface $cache
    ) {}

    public function getStats(): array
    {
        // 1. Checks APCu. Hit? Return.
        // 2. Miss? Checks Redis. Hit? Populate APCu & Return.
        // 3. Miss? Run Callback. Populate Redis & APCu.
        return $this->cache->get('stats_v1', function (ItemInterface $item): array {
            $item->expiresAfter(3600);
            return $this->computeHeavyStats();
        });
    }
    
    private function computeHeavyStats(): array 
    { 
        // Simulation of heavy work
        return ['users' => 10500, 'revenue' => 50000]; 
    }
}
 検証 
 
 
 
 
 
 クリーンキャッシュ:bin/console cache:pool:clear cache.layered ページを求める チェック Redis (CLI): KEYS * (あなたはキーを見る) APCu(Web Panel)をチェック:キーが表示されます。 アプリは、APCuから60秒間サービスを継続します。 The Thundering Herd: Probabilistic Early Expiration を解く “Cache Stampede” (または Thundering Herd) は、ホットキャッシュキーが有効期限が切れたときに発生します. 突然、1000の同時リクエストが同時にキャッシュを逃し、同じ値を計算するためにデータベースに当たります. データベースは崩壊します. シンフォニーが解決 複雑なロックメカニズム(Semaphoreのような) . without Probabilistic Early Expiration どのように機能する 正確に12:00に到着する代わりに、キャッシュは有効期限の少し前に空であると主張しますが、一部のリクエストの場合のみです。有効期限に近づくほど、ミスの可能性が高くなります。 実施について あなたは新しい構成を必要としません; you need to use the 契約のパラメータ $beta // $beta of 1.0 is standard. 
// Higher = recompute earlier. 
// 0 = disable. 
// INF = force recompute.
$beta = 1.0; 

$value = $this->cache->get('stock_ticker_aapl', function (ItemInterface $item) {
    // The item ACTUALLY expires in 1 hour
    $item->expiresAfter(3600);
    
    return $this->stockApi->fetchPrice('AAPL');
}, $beta);
 数学検証 確率を「証明」する CLI コマンドはありませんが、再計算をログできます。 
 
 
 
 $item->expiresAfter(10)を設定します。 このキャッシュキーを100msごとに打つループを作成します。 リクエストは10秒が過ぎ去る前に起動し、通常は一度だけ起動し、バックエンドが保護されていることを確認してください。 「ブラックボックス」:ナトリウムによる透明な暗号化 キャッシュ (PII) in Redis is a 攻撃者があなたの Redis メモリを捨てたら、彼らはデータを持っています。 Personal Identifiable Information GDPR/security risk Symfony では、キャッシュ アダプタを 1 つに包むことができます。 . we will use the PHP を離れる前にデータを透明に暗号化し、リサイクル時に解読する。 Marshaller SodiumMarshaller 確保 は その拡張は、 PHP 8.x です。 libsodium installed enabled 構成 私たちはデフォルトのマーシャルを装飾する必要があります. We will use a “ ” marshaller (to compress data) wrapped inside a ” 「マーシャル(暗号化する)」 Deflate Sodium #config/services.yaml

services:
    # 1. Generate a key: php -r "echo bin2hex(random_bytes(SODIUM_CRYPTO_SECRETBOX_KEYBYTES));"
    # Store this in .env.local: CACHE_DECRYPTION_KEY=your_hex_key
    
    # 2. Define the Marshaller Service
    app.cache.marshaller.secure:
        class: Symfony\Component\Cache\Marshaller\SodiumMarshaller
        arguments: 
            - ['%env(hex2bin:CACHE_DECRYPTION_KEY)%']
            - '@app.cache.marshaller.deflate' # Chain encryption OVER compression

    app.cache.marshaller.deflate:
        class: Symfony\Component\Cache\Marshaller\DeflateMarshaller
        arguments: ['@default_marshaller']
        
    default_marshaller:
        class: Symfony\Component\Cache\Marshaller\DefaultMarshaller

    # 3. Use the custom marshaller in your cache adapter
    Symfony\Component\Cache\Adapter\RedisAdapter:
        arguments:
            $marshaller: '@app.cache.marshaller.secure'
 #config/packages/cache.yaml

framework:
    cache:
        pools:
            cache.secure:
                adapter: cache.adapter.redis
                # We need to point the 'default_marshaller' of this pool to our secure one?
                # Actually, defining the adapter service globally as we did above 
                # is the cleanest way if you want ALL redis caches encrypted.
                # Alternatively, use the provider syntax:
                
                # For specific pool encryption, we often have to define the service manually 
                # or use a factory because framework.yaml config is limited for complex DI.
 Refined Approach for Symfony (Best Practice): グローバル・アダプターを優先する代わりに、プール・サービスを明示的にマーシャラーを注入するように定義します。 # config/services.yaml
services:
    app.cache.secure_pool:
        class: Symfony\Component\Cache\Adapter\RedisAdapter
        arguments:
            $redis: 'redis://%env(REDIS_HOST)%:6379'
            $marshaller: '@app.cache.marshaller.secure'
        tags: ['cache.pool']
 利用 public function storeUserAddress(int $userId, string $address): void
{
    // This data is compressed and encrypted in Redis
    $cacheItem = $this->securePool->getItem('user_addr_' . $userId);
    $cacheItem->set($address);
    $this->securePool->save($cacheItem);
}
 検証 
 
 
 
 
 
 データをキャッシュに保存する CLI: redis-cli で Redis に接続します。 鍵を手に入れ 結果: バイナリーゴミ(暗号化された文字列)が表示されますが、単語アドレスではありません。 PHP で検索する: plaintext アドレスを取得します。 分散障害:タグ&メッセンジャー コンピュータサイエンスで最も困難な問題は、キャッシュの無効化です。5つのウェブサーバー(ポッド)があると、より困難になります。サーバAが製品を更新する場合、サーバBのAPCuキャッシュは古い製品を保持します。 この問題は、Symfony Messengerを通じて無効化メッセージを送信することによって解決します。 戦略 
 
 
 
 
 Redis (Share) に書き込む APCu (for speed) でローカルにキャッシュします。 データが変更された場合は、バスにメッセージを送信します。 すべてのサーバーはメッセージを消費し、その特定のタグのローカルAPCuをクリアします。 構成 composer require symfony/messenger
 すべてのサーバーがメッセージを受け取るように「Pub/Sub」(Fanout)をサポートするトランスポートが必要です。 #config/packages/messenger.yaml

framework:
    messenger:
        transports:
            # Use a fanout exchange so ALL pods receive the message
            cache_invalidation: 
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    exchange:
                        type: fanout
                        name: cache_invalidation_fanout
 コード 1. The Invalidation Message namespace App\Message;

final readonly class InvalidateTagsMessage
{
    public function __construct(
        public array $tags
    ) {}
}
 2. The Handler This handler runs on every server. namespace App\MessageHandler;

use App\Message\InvalidateTagsMessage;
use Symfony\Component\Messenger\Attribute\AsMessageHandler;
use Symfony\Contracts\Cache\TagAwareCacheInterface;
use Symfony\Component\DependencyInjection\Attribute\Target;

#[AsMessageHandler]
final readonly class InvalidateTagsHandler
{
    public function __construct(
        #[Target('cache.layered')] // Target our Chain Cache
        private TagAwareCacheInterface $cache
    ) {}

    public function __invoke(InvalidateTagsMessage $message): void
    {
        // This invalidates the local APCu layer AND the shared Redis layer
        $this->cache->invalidateTags($message->tags);
    }
}
 3. The Service Triggering the Change namespace App\Service;

use App\Message\InvalidateTagsMessage;
use Symfony\Component\Messenger\MessageBusInterface;
use Symfony\Contracts\Cache\TagAwareCacheInterface;

class ProductService
{
    public function __construct(
        private TagAwareCacheInterface $cache,
        private MessageBusInterface $bus
    ) {}

    public function updateProduct(int $id, array $data): void
    {
        // 1. Update Database...
        
        // 2. Invalidate
        // We do NOT call $cache->invalidateTags() directly here.
        // Because that would only clear THIS server's APCu and the shared Redis.
        // Other servers would remain stale.
        
        $this->bus->dispatch(new InvalidateTagsMessage(["product_{$id}"]));
    }
}
 The #[Cacheable] Attribute シングル 書くより boilerplate in every service method, let's create a that handles caching automatically using the または . $cache->get() PHP 8 Attribute Decorator Pattern Event Subscription 以下は、Aを使用するクリーンな実装です。 聞き手は、効率的で論理しやすい。 Kernel::CONTROLLER_ARGUMENTS The Attribute namespace App\Attribute;

use Attribute;

#[Attribute(Attribute::TARGET_METHOD)]
final readonly class Cacheable
{
    public function __construct(
        public string $pool = 'cache.app',
        public int $ttl = 3600,
        public ?string $key = null
    ) {}
}
 イベントサブスクリプター This listener intercepts controller calls, checks for the attribute, and attempts to serve from cache. このオーディオは、コントローラの呼び出し、属性のチェック、およびキャッシュからサービスを試みます。 このシンプルな実装では、コントローラが一般的な serializable 応答 (JSON または Array など) を返します。 namespace App\EventSubscriber;

use App\Attribute\Cacheable;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\ControllerEvent;
use Symfony\Component\HttpKernel\KernelEvents;
use Symfony\Component\DependencyInjection\ServiceLocator;
use Symfony\Contracts\Cache\ItemInterface;

class CacheableSubscriber implements EventSubscriberInterface
{
    public function __construct(
        private ServiceLocator $cachePools // Inject locator to find pools dynamically
    ) {}

    public static function getSubscribedEvents(): array
    {
        return [
            // High priority to catch request before execution
            KernelEvents::CONTROLLER => ['onKernelController', 10], 
        ];
    }

    public function onKernelController(ControllerEvent $event): void
    {
        $controller = $event->getController();

        // Handle array callables [$object, 'method']
        if (is_array($controller)) {
            $method = new \ReflectionMethod($controller[0], $controller[1]);
        } elseif (is_object($controller) && is_callable($controller)) {
            $method = new \ReflectionMethod($controller, '__invoke');
        } else {
            return;
        }

        $attributes = $method->getAttributes(Cacheable::class);
        if (empty($attributes)) {
            return;
        }

        /** @var Cacheable $cacheable */
        $cacheable = $attributes[0]->newInstance();

        if (!$this->cachePools->has($cacheable->pool)) {
            return;
        }

        $pool = $this->cachePools->get($cacheable->pool);
        
        // Generate a key based on Controller Class + Method + Request Params
        // This is a simplified key generation strategy
        $request = $event->getRequest();
        $cacheKey = $cacheable->key ?? 'ctrl_' . md5($request->getUri());

        // We cannot easily "skip" the controller execution inside a Listener 
        // using the Cache Contract pattern nicely without replacing the controller.
        // 
        // For a TRULY robust attribute implementation, one should use 
        // a "Service Decorator" logic, but for Controllers, we can replace the 
        // controller callable with a closure that wraps the cache logic.
        
        $originalController = $event->getController();
        
        $newController = function() use ($pool, $cacheKey, $cacheable, $originalController, $request) {
            return $pool->get($cacheKey, function (ItemInterface $item) use ($cacheable, $originalController, $request) {
                $item->expiresAfter($cacheable->ttl);
                
                // Execute the original controller
                // Note: We need to manually resolve arguments or pass the request
                // This part is tricky in raw PHP. 
                // In Symfony we can simply execute the original callable 
                // IF we have the resolved arguments.
                
                // SIMPLIFICATION for article:
                // Assuming controller takes Request object or no args
                return $originalController($request);
            });
        };

        $event->setController($newController);
    }
}
 You must have your cache polls in a for the ダイナミックにアクセスできます。 register ServiceLocator Subscriber 上記のコードは、変更を示します。 理想的には、サービスのために、あなたは使用します。 サービスの定義ではありますが、コントローラーにとって、イベントをキャプチャすることはシンフォニーのやり方です。 Kernel execution flow #[AsDecorator] 結論 実施 シンプルで、ネットワークパーティションを生き残るキャッシュ戦略を構築し、 監査、そして スパイスは規律です。 CacheInterface GDPR Black Friday traffic ここで述べた戦略は、 ラテンシアチブのため、 競合のため、 セキュリティのため、そして 一貫性のために — 脆弱な最適化から脆弱なエンジニアリングに向かってアプリケーションを移行します. Symfony はこれらの原始性を箱から外し、重い第三者インフラを導入することなく、複雑な分散システムの問題を解決することができます。 Chain Caching Probabilistic Expiration Sodium Encryption Messenger-based Invalidation あなたのキャッシュを一時的なダンピング地として扱うのをやめましょう. Treat it as a critical, secured layer of your data persistence strategy. 議論を続ける パフォーマンスの高いPHPアーキテクチャは絶え間なく進化する景観です. あなたが遺産のモノリットを再構築したり、Symfonyで分散システムを設計しているなら、あなたが直面している課題について聞きたいです。 特定のコンプライアンスニーズのためにカスタマイズされた Marshaller を実装しましたか? 複数の地域の展開でキャッシュの無効化をどのように処理していますか。 LinkedIn で直接私に連絡をとり、建築について学び、戦争ストーリーを共有し、より良いソフトウェアを構築しましょう。

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

重要なキャッシュ戦略:シンフォニーで強力なキャッシュを作成する方法

About Author

コメント

ラベル

この記事は

Related Stories

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユニークなエコシステムを支えるビットコインUTXOのモデル

暗号通貨の成長: 効果的なユーザーペルソナの作成

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユニークなエコシステムを支えるビットコインUTXOのモデル

暗号通貨の成長: 効果的なユーザーペルソナの作成

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps