Redis其实不仅是缓存，数据库这活儿它也能轻松应付

基于对Redis官方文档、多个技术社区案例分享以及《Redis实战》等书籍观点的综合理解）

很多人第一次接触Redis，都是在项目的缓存层，比如一个电商网站，商品详情页的信息每次都要去数据库里查，数据库压力大，页面打开也慢，这时候把商品信息丢进Redis，下次再访问直接从内存读取，速度飞快，数据库也轻松了，这确实是Redis的看家本领，也是它最广为人知的用途，但如果你觉得Redis只是个简单的缓存工具,那可就太小看它了。

Redis的能耐，远不止于此，它本质上是一个速度极快的“数据结构服务器”，这句话是关键，普通的缓存可能只能存一下简单的键值对，但Redis给你提供了丰富的数据结构，比如字符串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）、哈希（Hash）等等，正是这些强大的数据结构，让它有能力去直接处理一些传统上由关系型数据库（比如MySQL）负责的核心业务逻辑，甚至在某些场景下,做得更好。

举个例子，社交网站里常见的“点赞”功能，如果用户点一下赞，你就去数据库里更新一下点赞数量，高并发的时候数据库肯定吃不消，用Redis怎么做？你可以为每条内容（比如一条微博）设置一个键，类型用集合（Set），用户点赞时，直接把他的用户ID塞进这个集合里；取消点赞，就从集合里移除，这样一来，判断某个用户是否点过赞（检查用户ID在不在集合里）、获取点赞总数（查询集合的元素个数），这些操作在Redis里都是瞬间完成的，效率极高，而且非常直观，这个“点赞”的集合，它存储的就是核心的业务数据,而不仅仅是缓存了。

再比如，排行榜功能，这是Redis的经典应用场景，也是它作为数据库能力的绝佳展示，游戏里的玩家积分排行榜、新闻的热度榜，都需要实时更新和排序，如果用SQL数据库来做，每次有新的分数产生，都要更新数据然后做一次ORDER BY操作，数据量一大就很吃力，而Redis的有序集合（Sorted Set）天生就是为排行榜设计的，每个成员都有一个分数（score），你添加成员的同时就指定了分数，Redis会自动帮你按照分数排序，要获取Top 10？一个命令就行，要查看某个玩家的排名？也是一个命令，这种效率是传统数据库难以比拟的，它在这里扮演的就是一个高性能的、专门处理排序业务的数据库角色。

还有像购物车功能，电商网站里，用户的购物车是一个临时但结构复杂的数据，里面可能有商品ID、数量、选中状态等，用Redis的哈希（Hash）结构来存就非常合适，一个用户对应一个哈希键，哈希的字段（field）是商品ID，字段的值（value）可以存商品数量和属性，这样对购物车的增删改查，都变成了对哈希的高效操作，远比频繁读写数据库要快和方便，这个购物车数据,在用户下单前就是核心的业务数据。

甚至在一些实时性要求极高的场景，比如实时竞价系统（RTB）、股票价格推送、在线聊天室的在线用户列表，数据的读写速度是生命线，这些场景下，传统数据库的磁盘IO成了瓶颈，而完全基于内存的Redis就能大显身手，直接作为 primary database（主数据库）来承载这些高速变化的数据流。

说Redis能“轻松应付”数据库的活儿，也需要有个清醒的认识，它并非要取代MySQL或PostgreSQL这类关系型数据库，关系型数据库的优势在于复杂查询（SQL）、事务的强一致性（ACID）和数据关系的严谨性，而Redis的优势是速度和灵活的数据结构，在实际项目中，它们往往是互补的“黄金搭档”，核心的、需要持久化保证的、关系复杂的数据放在MySQL，而那些高频访问的、需要复杂数据结构支持的、实时性要求高的数据，则可以放心地交给Redis来直接管理和服务，这种架构通常被称为“多模数据库”架构,各取所长。

Redis确实是一个顶级的缓存方案，但它的身份绝不止于缓存，当你开始利用它的列表实现消息队列，用它的集合做交集运算来推荐共同好友，用它的地理空间索引查找附近的人时，你就会发现，Redis已经以一个功能强大、性能彪悍的数据库身份，深深地嵌入到了你应用的核心业务逻辑之中，它用一种更简单、更直接的方式，解决了传统数据库在某些场景下“不好用”或“跑得慢”的痛点。