Add configurable deletion strategy for Redis repository operations #2294

[kssumin]

Summary

This PR implements configurable deletion strategy for Redis repository operations, allowing applications to choose between synchronous DEL and asynchronous UNLINK commands for better performance optimization.

Background

Currently, Spring Data Redis repositories always use the blocking DEL command when updating existing keys, which can cause performance issues in update-intensive applications, especially when dealing with large data structures. Redis 4.0+ introduced the non-blocking UNLINK command as an alternative.

Changes

Core Implementation

• DeletionStrategy enum: Defines DEL (default) and UNLINK options
• RedisKeyValueAdapter:
  • Added setDeletionStrategy() and getDeletionStrategy() methods
  • Updated put(), delete(), and expiration handling to use configured strategy
  • Added applyDeletionStrategy() utility method
• @EnableRedisRepositories: Extended with deletionStrategy attribute
• RedisRepositoryConfigurationExtension: Updated to propagate configuration

Test Coverage

• RedisKeyValueAdapterTests: Basic functionality and configuration tests
• RedisRepositoryConfigurationExtensionUnitTests: Annotation configuration tests

Closes #2294

• [x] You have read the Spring Data contribution guidelines.
• [x] You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• [x] You submit test cases (unit or integration tests) that back your changes.
• [x] You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[christophstrobl]

Thank you for getting in touch and taking the time to craft the PR. There is a potential benefit of UNLINK when working with large data structures as you mentioned. However I'm not fully convinced we need to have the behaviour configurable here. UNLINK calculates the cost of deleting the key and freeing the memory (in case of hash by looking at the number of elements). So it may do it immediately or later. Since Redis 6.0 lazyfree-lazy-user-del offers a server side flag to mrodify the default behaviour of DEL to act like UNLINK.