redi.php: A Redisson-Compatible Distributed Data Structures Library for PHP - In-Depth Research Report

Forum topic · ✨步子哥 · 2025-11-14

Summary

redi.php is an open-source PHP library by linkerlin that positions itself as a pure PHP implementation of Java's Redisson, offering high-level distributed data structures such as maps, sets, queues, semaphores, atomic counters, and reentrant distributed locks, with claimed full cross-language compatibility with Redisson-created structures. It requires PHP 7.4+ and depends on the C extension ext-redis for fast communication, combining high-level PHP logic with low-level C networking. This report analyzes its architecture, compares it with phpredis and Predis, examines security concerns (including Redisson's deserialization vulnerability CVE-2023-42809 as a potential inherited risk), and evaluates performance using published benchmarks showing pipelining boosts phpredis throughput roughly 8x. Suggested use cases include distributed locks for inventory/order processing, task queues, distributed caching and session storage, and real-time pub/sub analytics. The report closes with deployment guidance (Sentinel/Cluster, TLS, Redis ACL) and recommendations for the project's future development.

Key points

What it is: redi.php is an open-source PHP library (by developer linkerlin) that aims to be a pure PHP equivalent of Java's Redisson, providing high-level distributed data structures over Redis rather than a raw command interface.
Core compatibility claim: Per its composer.json, it aims for full cross-language compatibility with data structures created by Redisson, enabling PHP services to interoperate with Java services in heterogeneous microservice architectures (e.g., a PHP script acquiring a lock created by a Java service via Redisson).
Feature set: Distributed Map (RMap), Set (RSet), List (RList), Queue / BlockingQueue, reentrant distributed Lock (RLock) with auto-expiry, Semaphore, AtomicLong, and Pub/Sub — built on Redis atomic commands and Lua scripts for atomicity.
Tech requirements: PHP ≥ 7.4; depends on the ext-redis C extension (any version, *), which handles low-level network I/O for performance while high-level logic stays in PHP.

Architecture analysis

Hybrid design: "high-level logic in PHP, low-level communication in C" — easy Composer-based deployment plus acceptable performance, avoiding Predis-style pure-PHP networking overhead.
Probable module layout: connection management, distributed objects (per-class files like RMap.php, RLock.php), a serialization layer that must mirror Redisson's encoding (e.g., JSON in Redis Hashes), and utilities.
Compatibility challenges: matching Redisson's API shapes *and* its serialization formats so data written by either library is readable by the other.

Comparison with other PHP Redis clients

| Aspect | redi.php | phpredis (C ext) | Predis (pure PHP) | |---|---|---|---| | Abstraction level | High-level distributed objects | Raw Redis commands | Raw commands + sharding | | Performance | Higher (via ext-redis), below phpredis | Highest | Lowest (up to ~10x slower in benchmarks) | | Deployment | Composer + ext-redis required | Must compile/install extension | Composer only | | Best for | Distributed systems, Java interop | Raw speed | Environments without C extensions |

Benchmark data (100k/500k set + expire): phpredis 16s/79s vs Predis 21s/104s; with pipelining phpredis drops to 2s/12s (~8x speedup). redi.php's own benchmarks are not published.

Security assessment

No actual static scan was performed; recommended tooling includes PHPStan, Psalm, RIPS, SonarQube. Watch for command/Lua injection if lock keys or values come from user input.
Inherited risk: since it mirrors Redisson, historical Java-side vulnerabilities like CVE-2023-42809 (deserialization-related RCE) warrant scrutiny; avoid PHP native unserialize() on Redis data and prefer whitelisting or safe formats (JSON/MessagePack).
Server hardening: strong requirepass, bind to internal IPs, rename/disable dangerous commands (FLUSHALL, CONFIG), enable protected mode, use TLS (rediss://), and prefer Redis 6+ ACLs with least-privilege per-service users.
Audit ext-redis CVEs and run composer audit / Dependabot on dependencies.

Stability considerations

Connection pooling, retry with exponential backoff, idempotent retryable operations, and network-failure handling matter; Redisson's own pitfalls (connection storms on failover, retry not switching channels) are instructive cautionary examples.

Use cases & deployment

Distributed locks for order processing/inventory; task queues via blocking queues; distributed cache/session storage via RMap/RBucket; real-time pub/sub analytics and atomic counters for PV/UV.
Install: PHP 7.4+, enable ext-redis, then composer require linkerlin/redi.php. Keep credentials in env/config, not code.
Production: deploy Redis Sentinel or Cluster for HA, colocate PHP and Redis in the same intranet, monitor with redis-cli info or Prometheus + Grafana.

Limitations & outlook

Risks: unproven performance vs phpredis, inherited Redisson security concerns, limited community maturity/documentation, hard dependency on ext-redis.
Suggested roadmap: publish benchmarks, prioritize security hardening against Redisson CVE patterns, build Laravel/Symfony integrations, improve retry/reconnect robustness, and grow community docs.