redi.php: A Deep-Dive Research Report on a PHP Implementation of Redisson

Key points

• What it is: redi.php is an open-source, pure-PHP library by developer linkerlin that positions itself as the PHP equivalent of Java's Redisson, providing high-level distributed data structures and synchronization tools rather than a raw Redis command interface.
• Core goal: Full functional and data-format compatibility with Redisson, so data written by a Java service via Redisson can be read and manipulated by a PHP application via redi.php — and vice versa — enabling cross-language collaboration in heterogeneous microservice architectures.

Features

The library wraps Redis commands and Lua scripts into higher-level distributed objects, reportedly including:

• Distributed Map (RMap) – shared, atomically-operated key-value maps across instances.
• Distributed Set (RSet) and List (RList) – deduplicated collections and deque-like structures.
• Queues (RQueue / RBlockingQueue) – FIFO queues with blocking take/put for task and messaging systems.
• Distributed Lock (RLock) – reentrant locks with automatic expiry, typically built on SET NX PX plus Lua scripts for safe release; fair locks and RedLock-style multi-node locking may also be supported.
• Semaphore (RSemaphore) and AtomicLong (RAtomicLong) – concurrency limiting and distributed atomic counters.
• Pub/Sub – lightweight real-time messaging for event buses and notifications.

All atomicity guarantees rely on Redis's single-threaded command model and server-side atomic Lua script execution.

Technical stack

• Requires PHP ≥ 7.4 (typed properties, arrow functions, performance gains).
• Depends on the ext-redis C extension (any version per composer.json) for low-level communication — a hybrid approach: high-level logic in PHP, protocol/network I/O in C. Installation is via composer require linkerlin/redi.php.

Compatibility and architecture

Compatibility operates on two levels:

1. API design — mirroring Redisson interface names and method semantics (e.g., put(), get(), remove()), lowering the learning curve for Java developers. 2. Data serialization — matching Redisson's encoding (e.g., JSON stored in Redis Hash structures) so cross-language reads/writes are correct. This is the harder challenge and the key to true interoperability.

Likely module organization: connection management, distributed objects, serialization, and utilities — keeping the codebase modular and selectively usable.

Comparison with other PHP Redis clients

| Feature | redi.php | phpredis | Predis | | :--- | :--- | :--- | :--- | | Implementation | Pure PHP + ext-redis driver | C extension | Pure PHP | | Abstraction level | High-level distributed objects, Redisson-compatible | Raw Redis commands | Raw commands + sharding | | Performance | High (via ext-redis), below phpredis | Highest benchmark in PHP ecosystem | Lowest | | Deployment | Composer, but ext-redis required | Compile/install C extension | Composer only |

Benchmarks (100k/500k set+expire operations): phpredis ≈ 16s/79s vs Predis ≈ 21s/104s; with pipelining, phpredis drops to 2s/12s — an 8x gain. Pipelining support is therefore a critical performance factor for redi.php in batch scenarios.

Security considerations

• Redisson-inherited risks: compatibility with Redisson's encoding may also inherit its vulnerabilities, e.g., CVE-2023-42809 (deserialization-related RCE). Implementations must avoid unsafe unserialize() on user-controllable data and prefer safe formats (JSON/MessagePack) or whitelisted classes.
• Input validation: lock keys/values and Lua scripts must never concatenate user input; use parameterized EVAL arguments to prevent Redis/Lua injection.
• Server hardening: strong requirepass, bind to internal IPs, rename/disable dangerous commands (FLUSHALL, CONFIG), enable protected-mode.
• Transport security: use TLS (rediss://) via ext-redis for encrypted connections, especially across data centers or clouds.
• Redis 6+ ACL: dedicated least-privilege users per service with command-level permissions.

Stability and performance evaluation

• Connection pooling: needs configurable min/max connections, timeouts, and validity checks (e.g., PING). Note that Redisson's overly large default minimum pool size has caused "connection storms" during failover — a cautionary pattern.
• Retries: smart retry with exponential backoff, typed exceptions, and idempotent operations are essential; Redisson has had bugs where retries failed to switch channels after timeouts.
• Network faults: redi.php relies partly on ext-redis for network exception handling but should detect dead connections and reconnect properly.

Use cases and deployment

• Distributed cache and session storage via RMap/RBucket for shared, consistent state.
• Distributed locks and task queues for order processing, inventory deduction, and async background jobs (email, image processing, data sync).
• Real-time analytics via pub/sub topics and atomic counters for PV/UV and online-user metrics.

Deployment checklist: PHP 7.4+, ext-redis installed, stable Redis server, Composer install; credentials via env/config (no hardcoding); monitor application metrics and Redis health (redis-cli info, Prometheus + Grafana). For production HA, use Redis Sentinel (automatic failover) or Redis Cluster (sharding), keeping PHP and Redis servers in the same internal network.

Conclusion

redi.php fills a genuine gap in the PHP ecosystem: a Redisson-compatible, high-abstraction toolkit for distributed coordination and Java–PHP interoperability. Its main trade-offs are performance below phpredis, potential inheritance of Redisson's historical security weaknesses, and the maturity risks of a relatively young project. Recommended future directions include performance optimization (pools, pipelining), security hardening, richer documentation, framework integrations (Laravel/Symfony), and more robust error handling and failover strategies.