Redis只能做缓存？太out了！

大多数数据库，由于经常和磁盘打交道，在高并发场景下，响应会非常的慢。为了解决这种速度差异，大多数系统都习惯性的加入一个缓存层，来加速数据的读取。redis由于它优秀的处理能力和丰富的数据结构，已经成为了事实上的分布式缓存标准。

但是，如果你以为redis只能做缓存的话，那就太小看它了。

redis丰富的数据结构，使得它的业务使用场景非常广泛，加上rdb的持久化特性，它甚至能够被当作落地的数据库使用。在这种情况下，redis能够撑起大多数互联网公司，尤其是社交、游戏、直播类公司的半壁江山。

1. Redis能够胜任存储工作

redis提供了非常丰富的集群模式：主从、哨兵、cluster，满足服务高可用的需求。同时，redis提供了两种持久化方式：aof和rdb，常用的是rdb。

通过bgsave指令，主进程会fork出新的进程，回写磁盘。bgsave相当于做了一个快照，由于它并没有WAL日志和checkpoint机制，是无法做到实时备份的。如果机器突然断电，那就很容易丢失数据。

幸运的是，redis是内存型的数据库，主丛同步的速度是非常快的。如果你的集群维护的好，内存分配的合理，那么除非机房断电，否则redis的SLA，会一直保持在非常高的水平。

听起来不是绝对可靠啊，有丢失数据的可能！这在一般CRUD的业务中，是无法忍受的。但为什么redis能够满足大多数互联网公司的需求？这也是由业务属性所决定的。

在决定最大限度拥抱redis之前，你需要确认你的业务是否有以下特点：

除了核心业务，是否大多数业务对于数据的可靠性要求较低，丢失一两条数据是可以忍受的？

1. 面对的是C端用户，可根据用户ID快速定位到一类数据，数据集合普遍较小？无大量范围查询需求？
2. 是否能忍受内存型数据的成本需求？
3. 是否业务几乎不需要事务操作？

很幸运的是，这类业务需求特别的多。比如常见的社交，游戏、直播、运营类业务，都是可以完全依赖Redis的。

2. Reids应用场景

Redis具有松散的文档结构，丰富的数据类型，能够适应千变万化的scheme变更需求，接下来我将介绍Redis除缓存外的大量的应用场景。

2.1 基本用户数据存储

在传统的数据库设计中，用户表是非常难以设计的，变更的时候会伤筋动骨。使用Redis的hash结构，可以实现松散的数据模型设计。某些不固定，验证型的功能属性，可以以JSON接口直接存储在hash的value中。使用hash结构，可以采用HGET和HMGET等指令，只获取自己所需要的数据，在使用上也是非常便捷的。

>HSET user:199929 sex m
>HSET user:199929 age 22
>HGETALL user:199929
1) "sex"
2) "m"
3) "ag