There is a lot to think about if you plan on using Redis. I'm no expert but I will try and answer you to the best of my knowledge.
First thing first, Redis is an in memory key value store. It's not capable of being queried in the same way a MySQL database can be. So keeping this in mind, you need to know the key of what ever you want to retrieve. A lot of thought will need to be put into your naming convention because of this.
Some gotchas or caveats, as it's in memory, the amount of memory available on the server will limit the amount of data you can store. Out of the box, it also doesn't write anything to disk. You can enable snapshots which will write a copy of what's stored to disk on a time schedule or when a certain number of changes have been made. Without this, if your server reboots, you will lose everything in memory. With it, it will take a while for your Redis server to recover when it restarts. You will lose anything that was changed since the last snapshot.
Redis is generally used for caching and not a standalone storage service. My use of Redis uses MySQL as the main storage engine and Redis for reading. So the workflow would be:
Write to MySQL followed by writing to Redis. So anything that gets updated in MySQL also gets updated in Redis. From a reading point of view everything is read from Redis first, if it isn't there I will read it from MySQL and write it to Redis. With this method it takes less time to recover if your Redis server goes down. Reads will be a bit slower to start with, but at least the data will be available straight away.
Redis is a fantastic layer to add for caching, a typical MySQL query might take 200ms, pulling the same data from Redis will take 10-20ms, so it is great for speeding sites up.
Hopefully this gives you some idea of how to get around failures. If you have any further questions, I will try to answer them.