用Redis当数据库其实没那么难，自己动手搭建也挺方便的感觉

综合自网络技术博客、开发者社区讨论以及个人实践经验）

直接用Redis当数据库，听起来好像是个挺大胆的想法，一般我们想到数据库都是MySQL、PostgreSQL那种大家伙，得建表、写SQL语句，事务ACID啥的搞得挺复杂，而Redis给我们的印象就是个缓存，放点临时数据，重启可能就没了，但说实话，如果你做的是一些对数据可靠性要求不是特别高，但又对速度有极致追求的小应用、小工具，用Redis来当主数据库，其实没那么吓人，自己动手搭一下,感觉还挺轻便的。

首先得搞清楚，Redis它自己有两种主要的持久化方式，这就是它能当数据库的底气所在，不然一断电数据全飞了，那肯定不行，一种叫RDB，你可以理解为“拍快照”，Redis会每隔一段时间，或者满足一定条件时，把内存里所有的数据完整地备份到一个文件里，比如叫dump.rdb，这个文件比较小，恢复起来也快，缺点就是如果还没到下次拍快照的时间服务器宕机了，那么从上一次快照到宕机之间的数据就丢了，另一种叫AOF，这个就有点像“写日记”了，你每执行一个写命令，比如set一个key，Redis就会把这个命令本身追加到一个文件的末尾，这样即使服务器突然宕机，重启的时候只要把这份“日记”从头到尾重新执行一遍，数据就能恢复到宕机前的状态，丢数据的风险非常小，生产环境会把这两种方式结合起来用，用AOF来保证数据安全，同时定期用RDB来做一次快照，方便备份和快速恢复，你看，有了这些机制，数据就不是完全活在内存里了,也就有了当数据库的基本条件。

然后就是数据模型的问题，用惯了关系型数据库的人，一开始可能会有点懵，不知道怎么存数据，关系型数据库是规规矩矩的表格，一行一行的，Redis是键值对，但这个“值”的类型很丰富，不只是简单的字符串，比如有List（列表），你可以用它来实现一个简单的消息队列，或者存用户的时间线，有Set（集合），可以很方便地求交集、并集，比如用来存共同好友，有Sorted Set（有序集合），带分数的，可以用来做排行榜，还有Hash（哈希），这个就特别有用了，它就像一个小的文档，里面可以存多个字段和值，比如你要存一个用户的信息，不像在MySQL里得拆成id、name、age好几个列，在Redis里你可以直接用一个Hash类型的key，比如user:1001，然后在这个key里面设置field和value，比如name "张三"，age "25"，取的时候也很方便，可以一次性获取所有字段，也可以只获取某个字段，这种结构对于某些简单的对象存储来说,反而比关系型数据库更直接。

自己动手搭一个这样的环境试试看，感觉会非常直观，你不需要去安装一个庞大的数据库软件，配置一堆复杂的参数，Redis本身非常轻量，下载一个可执行文件，在命令行里敲redis-server就启动起来了，再开一个窗口敲redis-cli就能连上去进行操作，你马上就能用set mykey "hello redis"这样的命令存数据，用get mykey取数据，瞬间得到结果，那种速度感是传统数据库很难比拟的，你会感觉这个数据库完全在你的掌控之中,没有那么多抽象层和复杂的约束。

当然啦，这么方便肯定也是有代价的，Redis当数据库，最大的问题就是它不像关系型数据库那样有严格的Schema（结构）和强大的关联查询能力，你没法像写SQL那样进行复杂的多表关联查询、分组统计，所有的数据关系和查询逻辑，基本上都得在你的应用程序代码里自己实现，比如你要查“所有年龄大于20岁的用户”，在MySQL里一句SQL就行，在Redis里，你可能需要自己维护一个Sorted Set，把用户的年龄作为分数，然后通过范围查询来获取，这就要求你在设计数据存储结构的时候，必须提前想好后面要怎么查，这是一种完全不同的思路，所以它特别适合那种数据模型相对简单,查询模式也比较固定的场景。

因为所有数据都放在内存里，所以能存的数据总量受限于你的内存大小，成本会比存在硬盘上的数据库高，虽然Redis有虚拟内存之类的机制，但核心优势还是在于内存速度，所以它不太适合存海量的、冷冰冰的历史数据,更适合存那些需要被快速访问的热点数据。

总结一下就是，用Redis当数据库，并不是要它去取代MySQL这样的传统关系型数据库，而是在某些特定的场景下，提供了一个更简单、更快速的替代方案，比如做一个实时排行榜、一个简单的消息系统、一个会话（Session）存储中心，或者一个功能简单的计数器系统，这些用Redis来实现会非常顺手，开发效率高，运行起来也快，自己从零开始搭一个这样的服务，整个过程很直接，没有太多弯弯绕绕，会让你对数据存储和操作有一种“亲手打造”的感觉，挺有成就感的，下次如果你的项目有类似的需求，不妨大胆考虑一下Redis,它可能没你想象中那么难驾驭。