Understanding Redis ZSET Score Precision and Its Interaction with Java Double

In server‑side development, Redis ZSET is frequently used because its elements are unique and each element carries a score, making it ideal for ordered queues and sorting based on the score value.

The score must be a floating‑point number; attempting to use non‑numeric strings results in the error "(error) value is not a valid float". Numeric types such as int, long, float, double are accepted, but floating‑point values have inherent precision limits that can affect business logic.

Java’s double type exhibits precision issues: two double variables with many identical digits may compare as equal after rounding to about 18 significant digits, and arithmetic operations often produce small errors (e.g., deviations of 0.0000…1). For commercial calculations, java.math.BigDecimal is recommended, yet the Jedis driver still uses double for ZSET operations.

When inserting a value like 3.14 into a ZSET via Jedis, redis-cli shows 3.1400000000000001 while Java reads it back as 3.14 . The discrepancy originates from Redis’s own floating‑point storage precision rather than the insertion process.

Experiments with timestamps (14‑digit long integers) used as scores show no precision loss after conversion to double, because loss only occurs when the integer exceeds 17 digits. Therefore, timestamps are safe as scores, but numbers longer than 17 digits should be avoided or pre‑processed if necessary.

In summary, developers should be aware of Redis’s floating‑point precision limits, prefer BigDecimal for critical monetary or scientific calculations, and avoid using overly large numeric scores in ZSETs to prevent subtle bugs.