Thank you for the valuable feedback from @noojung regarding the potential risks of MGET in shared Redis environments.

Addressing the Concerns

1. Redis Single-Thread Blocking

You're absolutely right that MGET with large batch sizes can block Redis. This is why the implementation includes:

• Default batchSize = 1: No change from current behavior unless explicitly opted in
• Maximum limit of 1000: Prevents excessive blocking even when configured
• User control: Administrators can tune based on their specific environment

2. Shared Environment Considerations

For environments where batch and online applications share Redis:

• Recommended batch sizes:
  • Dedicated Redis: 100-500
  • Shared Redis: 10-50
  • High-latency networks: May benefit from larger sizes despite blocking risk

3. Documentation Enhancement

I suggest adding comprehensive documentation warning about these trade-offs:

/**
 * WARNING: Large batch sizes can block Redis for extended periods.
 * Consider your environment carefully:
 * - Monitor Redis SLOWLOG to detect blocking issues
 * - Start with small batch sizes and increase gradually
 * - In shared environments, prefer smaller batches (10-50)
 */

Alternative Approaches for Future

1. Pipeline mode: Could be less blocking than MGET
2. Async processing: Using Lettuce's async API
3. Dynamic batch sizing: Adjust based on Redis response times

Conclusion

The current implementation provides a safe, opt-in performance optimization that:

• Maintains 100% backward compatibility
• Gives users control based on their environment
• Can provide significant performance gains when used appropriately

The concerns are valid and should be clearly documented, but the feature can still provide value when used with proper understanding of the trade-offs.