Race condition during clearByTag execution in Redis storage adapter

When utilizing the laminas-cache component with a Redis backend, latency spikes occur during high-concurrency invalidation events. While the adapter provides a unified interface for tagging, the implementation of clearByTag lacks inherent atomicity across distributed nodes.

In a high-load environment, multiple processes may trigger tag-based invalidations simultaneously. Because Laminas-cache does not provide built-in distributed locking for its storage adapters, a race condition emerges where one process may refresh a cache key while another is clearing its associated tag. This results in inconsistent cache states or cache stampedes.

How can the Redis storage adapter ensure atomicity during tag-clearing operations without external synchronization? Additionally, is there a recommended configuration within Laminas to prevent race conditions when O(n) complexity key-mapping occurs?