Redis用作数据库

很久以前的问题了，Redis 又发展了两三年，数据结构更丰富了，使用场景增多，Redis 3.0支持集群（cluster）模式。 

是否可以用来作为数据库，还是看业务，架构是技术对业务妥协的结果！  

Redis在新浪微博有很多应用，主要是用来存关注关系。

新浪微博大多数的数据还是落地到mysql的，按照那边DB组同学说法，mysql在新浪只用来存储数据，Redis是用来抗量的。没有全用Redis，是基于历史原因、可靠性和成本考虑的。 

百度的LBS也大量的使用Redis，很多信息都交给Redis来存储，不过同样也是对Redis进行了定制和扩展——增加了数据切分、服务监控、自动扩容等。  按照业务来看，核心业务建议数据还是落地到mysql，redis在异常情况下回丢数据。

 非核心业务，比如运营推广，数据聚合统计这种允许数据少量丢失的业务可以全用redis，扩展方便，效率高，业务量也不大。特别是运营推广这种时效性很强的业务，在推广结束后数据接没用了，Redis内存压力也不会很大。  

按照发展阶段来看。 产品初期，业务需求多变，数据量很小，数据结构朝令夕改，这时候如果用mysql很有可能会在改数据库结构上疲于奔命，如果用Redis，由于没有Scheme约束，数据结构的变更相对容易，比起mysql能轻松不少。 

产品中期，业务需求逐渐稳定，可以将核心数据导到mysql中落地，其余数据仍然放在Redis中。 

产品后期，业务需求基本稳定，数据应该尽量都落地到mysql，Redis做高速缓存，或者先写到Redis，再异步刷到mysql。 

 按照对数据的需求来看 mysql能支持对各个字段的查询，Redis的查询仅限于对key的简单匹配，如果要对value进行复杂查询，不适合用Redis。Redis新增了计数器、bitmaps以及地理位置索引的支持，特别是地理位置索引，可以方便的做附近搜索，有需求的话可以考虑。

redis是目前公认的速度最快的基于内存的键值对数据库，但redis的缺点也非常明显，仅提供最基本的hash set, list, sorted set等基于数据类型，不分表，没有schema，没有索引，没有外键，缺少int/date等基本数据类型，多条件查询需要通过集合内联(sinter,zinterstore)和连接间接实现，操作不便，开发效率低，可维护性不佳；因此一般不将其视为完整的数据库单独使用，很多网站将redis作为高速缓存和session状态存储层，然后再与其他数据库搭配使用。