0

The Redis command reference for EXPIRE says:

Redis keys are expired in two ways: a passive way, and an active way.

A key is passively expired simply when some client tries to access it, and the key is found to be timed out.

Does passive expiration block the client command which triggered the expiration?

For example, imagine I have a massive ZSET containing M entries.

If I delete the ZSET using a DEL command, the operation has time complexity of O(M), and will potentially block for a long time while the ZSET is deleted.

If the ZSET is instead scheduled for deletion via an EXPIRE command, I'd assume Redis at some point needs to perform a similar O(M) delete operation.

Does that O(M) deletion happen inline with (and therefore block) the client command which attempted to access the ZSET's key and hence triggered the passive expiration?

If not, does it have any other blocking implications for the main Redis event loop?

tomato
  • 3,373
  • 1
  • 25
  • 33

1 Answers1

1

Does passive expiration block the client command which triggered the expiration?

With old version of Redis, yes, it will block.

However, with new version of Redis (I cannot remember from which version, check if your redis.conf has the following configuration), you can config your Redis with lazyfree-lazy-expire yes, and the key will be freed asynchronously, and won't block.

If I delete the ZSET using a DEL command, the operation has time complexity of O(M), and will potentially block for a long time while the ZSET is deleted.

You'd better call UNLINK (since Redis 4.0) instead, which delete key asynchronously. Or with newer version, config lazyfree-lazy-user-del yes to make Redis run DEL as UNLINK.

If the ZSET is instead scheduled for deletion via an EXPIRE command, I'd assume Redis at some point needs to perform a similar O(M) delete operation.

With newer version Redis, it depends on whether you config lazyfree-lazy-expire yes. If you do, it won't block. See above for detail.

for_stack
  • 21,012
  • 4
  • 35
  • 48