You can use Redis as an authoritative store in a number of different ways:

• Turn on AOF (Append-only File store) see AOF docs . This will keep a log of all Redis commands made against your dataset in real-time.
• Run Redis using Master-Slave replication see replication docs . This will allow you to provide high-availability if one of your instances fails.
• If you're running on something like EC2 you can EBS back your Redis partition to provide another layer of protection against instance failure.

On the horizon is Redis Cluster - this is specifically designed as a way to run Redis in a way that should help with HA and scalability. However, this won't appear for at least another six months or so.

Redis是一个内存存储，它也可以将数据写回光盘。你可以指定执行fsync的次数，以使Redis更安全（但也更慢=〉权衡）。
但是我仍然不确定redis是否已经进入了真正存储关键数据的状态。例如，如果再多一条tweet（twitter.com）或类似的东西丢失不是一个大问题，那么我肯定会使用redis。在redis自己的网站上也有很多关于persistence的信息。
你也应该知道some persistence problems，这可能发生在阅读antirez（redis维护者）的博客文章。你应该阅读他的博客，因为他有一些有趣的文章。

As Redis is an in-memory storage, you cannot store large data that won't fit you machine's memory size. Redis usually work very bad when the data it stores is larger than 1/3 of the RAM size. So, this is the fatal limitation of using Redis as a database.
Certainly, you can distribute you big data into several Redis instances, but you have to do it all on your own manually. The operation usually be done like this(assuming you have only 1 instance from start):

1. Use its master-slave mechanism to replicate data to the second machine, Now you have 2 copies of the same data.
2. Cut off the connection between master and slave.
3. Delete the first half(split by hashing, etc) of data on the first machine, and delete the second half of data on the second machine.
4. Tell all clients(PHP, C, etc...) to operate on the first machine if the specified keys are on that machine, otherwise operate on the second machine.
   This is the way how Redis scales! You also have to stop your service to prevent any writes during the migration.
   To the expierence we encounter, we have this conclusion to Redis: Redis is not the right choice to store more than 30G data, Redis is not scalable, Redis is quite suitable for prototype development.
   We later find an alternative to Redis, that is SSDB( https://github.com/ideawu/ssdb ), a leveldb server that supports nearly all the APIs of Redis, it is suitable for storing more than 1TB of data, that only depends on the size of you harddisk.

我想分享一下我们在使用Redis作为我们服务的主数据库时学到的一些东西。我们选择Redis是因为我们的数据不能被分区。我们想从一个盒子里得到最好的性能

优点：

• Redis在原始性能方面是无与伦比的。我们可以实现每秒10K的交易量（注意，一个交易涉及多个Redis命令）。经过几次优化和LUA脚本，我们可以达到每秒25K以上的交易量。因此，在每台机器的性能方面，Redis是无与伦比的。
• 与其他SQL和NoSQL数据库相比，Redis的设置非常简单，学习曲线非常短。
  缺点：
• Redis只支持一些基本的数据结构，如哈希，集合，列表等，以及对这些数据结构的操作。当你把Redis作为缓存使用时，这些已经足够了，但是如果你想把Redis作为一个成熟的主数据存储，你会觉得受到限制。我们很坚韧用这些简单的类型来建模我们的数据需求。
• Redis最大的问题是缺乏灵活性。一旦你解决了数据结构，任何对存储需求或访问模式的修改都需要重新考虑整个解决方案。不确定是否所有的NoSQL数据存储都是这样（我听说MongoDB更灵活，但我自己没有使用过）
• 由于Redis是单线程的，CPU利用率很低，不能在同一台机器上放置多个Redis示例来提高CPU利用率，因为它们会竞争同一个磁盘，磁盘成为瓶颈。
• 缺乏水平可伸缩性是其他答案中提到的一个问题。

Redis is a database, that means we can use it for persisting information for any kind of app, information like user accounts, blog posts, comments and so on. After storing information we can retrieve it later on by writing queries.
Now this behavior is similar to just about every other database, but what is the difference? Or rather why would we use it over any other database?
Redis is fast.
Redis is not fast because its written in a special programming language or anything like that, its fast because all data is stored in-memory.
Most databases store all their information between both the memory of a computer and the hard drive. Accessing data in-memory is fast, but getting it stored on a hard disk is relatively slow.
So rather than storing memory in hard disk, Redis decided to store it in memory.
Now, the downside to this is that working with data that is larger than the amount of memory your computer has, that is not going to work.
That may sound like a tremendous problem, but Redis has clear strategies for working around this limitation.
The above is just the first reason why Redis is so fast.
The second reason is that Redis stores all of its data or rather organizes all of its data in simple data structures such as Doubly Linked Lists, Sorted Sets and so on.
These data structures have well-known and well-understood performance characteristics. So as developers we can decide exactly how our information is organized and how to efficiently query data.
Its also very fast because Redis is simple in nature, its not feature heavy, feature heavy datastores like Postgres has performance penalties.
So to use Redis as a database you have to know how to store in limited space, you have to know how to organize it into these simple data structures mentioned above and you have to understand how to work around the limited feature set.
So as far as mitigating risks, the way you start to do that is to start to think Redis Design Methodology and not SQL Database Design Methodology. What do I mean?
So instead of, step 1. Put the data in tables, step 2. figure out how we will query it.
With Redis its more:
Step 1. Figure out what queries we need to answer. Step 2. Structure data to best answer those queries.