Feature key prefixes

[vallbo]

Adding possibility to create a keys with prefix, because of multiple instances using one Redis server.

[enumag]

Add this to your gitignore_global, not here.

[vallbo]

deleted in 27657e1

[fprochazka]

This is what databases are for, no?

[vallbo]

Yes, it is an option for using redis with multiple instances of one application.
The question about multiple database was also discussed on the StackOverflow (http://stackoverflow.com/questions/16221563/whats-the-point-of-multiple-redis-databases).
At the moment application is using wrapper for this library and working without any problems.
But i think it will be more elegant if option of key prefixes will be directly in this library.

[hrach]

Databases have limited count + its possible to distinguished them only by a number (impossible to use it for simultanous app revisions, etc.)

[vallbo]

@fprochazka Is there some progress, because our company is waiting for this pull request. Thank you for answer.

[hranicka]

👍 for option of key prefixes.

In the current master there is no way of custom keys specification. Only hard-coded "Nette" prefixes are present via constants (eg. https://github.com/Kdyby/Redis/blob/master/src/Kdyby/Redis/RedisStorage.php#L29).

[fprochazka]

you should upgrade your PhpStorm, the new one doesn't break the indentation in here :)

[fprochazka]

Also, I'm gonna have to ask you to write tests for this.

[fprochazka]

Also, before you continue. Wouldn't it make more sense to implement this on the client level? Just asking, I know it would be much more complex.

[fprochazka]

Now that I think about it, someone might misinterpret this as adding the prefix to the client object - it would be a little more writing, but it would also make a lot more sense to me having them under the specific sections.

parameters:
    redis:
        namespace: instance1

redis:
    host: 127.0.0.1
    port: 6379
    journal:
        namespace: %redis.namespace%
    session:
        namespace: %redis.namespace%
    storage:
        namespace: %redis.namespace%
    debugger: off

[fprochazka]

Now that I've reviewed your PR. Let me repeat few important facts

• I still think increasing the max databases count and having separate database for session and separate database for cache for each application is better then namespacing keys. You cannot call flushdb on deploy when you wanna clear cache, if all your applications are sharing a database. You have to call keys instance1_ and pipe that to del command. Which basically murders redis performance. Using only one database doesn't scale! It's best to have an instance of redis for session and another instance for cache-related data.
• Redis is single threaded => if your application manages to block the only instance that the other 20 applications are using, you've managed to kill 20 applications. Remember that once you've started session, it blocks the request untill it acquires the key, which it cannot do if the instance is blocked. It can only use one cpu. This can effetively cause multiple waiting requests in PHP - they will queue up untill all the workers are bussy and your webserver will start returning errors. This escalates wery easily.
• Redis has basically nonexistent memory footprint and running 2 instances per application on one machine consumes very little memory. Read Redis Partitioning they're mostly writing about paritioning one dataset of one application but it's interesting.
• If your cache and sessions combined from 20+ applications in one database is not a performance problem, or inconvinience for you, you probably don't need redis and filesystem cache is more then enough for you.

[hrach]

How do you solve continuos deployment when you have multiple instances. You can't flush the old db, you have to have another separated storage. Not advocating this solution, just asking :-)

[juniwalk]

👎 for me, using single database for multiple apps sounds really bad practise to me.

[fprochazka]

@hrach

• version prefix - https://github.com/doctrine/cache/blob/e0ef9e9833ca024d251e77e8d82a00ca92b0aa71/lib/Doctrine/Common/Cache/CacheProvider.php#L162-L174 - this is really nice, but it doesn't solve deleting the cache
• switching databases - you can have 2 or more databases for cache and on deploy, you just tell the application to use the other/next one (++$i % $n) and on the next deployment, you can delete the old one, because you know you won't be rollbacking to it
• docker - you really have to backup (write to disk) only sessions (sometimes you don't have to do even that) - the resulting solution is obvious

Either way, I'd strongly suggest having a separate instance for cache (and another one for sessions) for each application.

[enumag]

I don't use Redis yet because of this very problem - databases are numbered and making sure that each app uses a different database is a real pain. That said I have to agree with @fprochazka. This doesn't seem to be the correct solution to me. 👎