TYPO3 Core

The following patch was committed to trunk rev.

Type: Feature

BT:

Branches: trunk

Problem:
Redis [1] is a noSQL database with very good scaling characteristics in relation to the amount of entries and data size. This makes redis perfectly fit our needs as a caching backend. redis is a key-value store like memcache, but does not have the cache integrity problems we have with memcache if used right.

Solution:
Implement redis as a cache backend using the phpredis PHP module [2]

Notes:
- This is the v4 backport of [3], merged to FLOW3 with git revisions 7f11528521db7d04845e652d948a429b93f2f2e9, 923af427d12e5c7e1d7420ac547a8bfeb9f14af5 and dd78aca101a46f41bbbc3376b2524ff0885e91f6
- In addition to FLOW3 version, the API methods findIdentifiersByTags() and flushByTags() where added to comply to v4 interfaces.
- The code has pretty high unit test code coverage, far more than all other existing cache backends.

Available backend options:
- database > database number (should be set!)
compression > enable zlib data compression, identical to db backend (TRUE / FALSE, default: FALSE)
compressionLevel > zlib compression level, identical to db backend, integer -1 (default zlib compression), 0 .. 9 (default: -1)
hostname > server hostname
port > server port
password -> server password

Thanks to:
- Christopher Hlubek for the initial implementation with ext:rediscache
- Andre Heydt for help with the big O notation for all relevant methods
- FLOW3 team for quick reviews and merge to make this feature core ready before feature freeze of 4.5

Warning:
- redis and phpredis are young projects with high development speed. In future internal structures might change!
- This implementation was tested with:
-- redis 2.0.x, redis git revision 9fd01051bf8400babcca73a76a67dfc1847633ff
-- phpredis git revision 12769b03c8ec17b25573e0453003712011bba241
- redis scales far better than every other existing cache backend with big data sizes and tons of cache entries, but only if redis is fully RAM driven. Make sure to tune your redis settings for production use, there are plenty of options, see redis.conf for details.
- Be aware that redis can be very memory hungry. Again: It's important to configure redis options to suite your production needs.
- Make sure every cache is assigned to an own redis database. flushdb() will "truncate" the whole database (very quickly), do not mix different caches in one database because of this!
- Do not use redis database number 0 and 1 in production, they are utilized and flushed (!) when running the unit tests.

How to test / use:
phpredis:
git clone https://github.com/owlient/phpredis.git
cd phpredis
phpize
./configure
make
make install

1. Load redis php extension for debian:
   echo 'extension="redis.so"' >> /etc/php5/conf.d/redis.ini
2. Restart webserver ...

redis:
download redis 2.0.x, or:
git clone https://github.com/antirez/redis.git
cd src
make
make install
./redis-server

1. Sample configuration in localconf.php for redis as cache backend for pages cache:
   $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages'] = array(
   'frontend' => 't3lib_cache_frontend_StringFrontend',
   'backend' => 't3lib_cache_backend_RedisBackend',
   'options' => array(
   'database' => 2,
   ),
   );

Regards
Christian

[1] http://code.google.com/p/redis/
[2] https://github.com/owlient/phpredis
[3] http://forge.typo3.org/issues/9017

(issue imported from #M16410)