不只是改容量，redis还能满足更多复杂应用的各种需求嘛

当然可以，Redis 绝不仅仅是一个扩大缓存容量的工具，它内置的多种数据结构和对持久化、高可用等特性的支持，使其能够优雅地解决许多看似与缓存无关的复杂问题,下面就是一些实实在在的应用场景。

实时排行榜与社交动态 这是Redis最经典的应用之一，比如一个游戏里的全球积分榜，或者微博的热搜榜，如果用传统数据库，每次查询都要“ORDER BY score DESC LIMIT 100”，数据量巨大时性能压力很大，而Redis的有序集合（Sorted Set） 结构天生就是为排行榜设计的（来源：Redis官方文档对数据结构的介绍），每个成员都有一个分数，可以毫秒级地实现插入、更新分数、按名次查询、查看某个用户排名等操作，微博的热搜榜正是利用Sorted Set来实时统计和排序热点话题（来源：多个国内技术社区对微博架构的案例分析）。

秒杀与库存控制 电商秒杀场景中，最关键的难点是超卖和系统承压，Redis的单线程特性和原子操作可以完美解决超卖问题，利用 DECR 命令扣减库存，因为它是原子性的，即使十万人同时抢购，Redis也会确保库存数量被正确地顺序减一，不会出现负数（即超卖），将库存预热到Redis中，也避免了秒杀请求直接击穿数据库（来源：高并发相关技术书籍及文章普遍将此作为经典案例）。

社交关系与消息推送 在社交网络中，关注列表、粉丝列表、共同好友这些关系查询非常频繁，Redis的集合（Set） 可以存储一个用户的所有关注者，求两个集合的交集（SINTER）就能瞬间得到共同关注，微博的“关注”功能就大量使用了Set结构（来源：同上微博架构分析），当用户发布新动态后，系统可以快速查出其所有粉丝的集合，然后将新动态ID推送到每个粉丝的“收件箱”（另一个List或Sorted Set）,实现消息的实时推送流。

实时统计与限流 很多业务需要实时统计，比如一个网页在一天内有多少独立访客，Redis的位图（Bitmap） 可以用极小的内存，通过记录用户ID的访问位，来统计每日活跃用户。HyperLogLog 这种数据结构可以用固定且极小的内存（约12KB）来估算海量数据的独立访客数，虽不精确但误差率很低，非常适合大数据量的UV统计（来源：Redis官方文档对HyperLogLog的说明），在限流方面，可以轻松实现“一分钟内最多允许请求60次”的API限流,保护后端服务。

会话共享与购物车 在分布式网站中，用户登录信息（Session）如果存储在单台服务器上，其他服务器就无法识别，将Session统一存储在Redis中，所有Web服务器都能访问，实现了分布式会话共享，同样，电商购物车也可以用Redis的哈希（Hash） 结构来存储，键是用户ID，字段是商品ID，值是商品数量，增删改查都非常高效,并且可以持久化。

轻量级的消息队列 虽然Redis不是专业的消息队列（如Kafka、RabbitMQ），但其列表（List） 的阻塞式弹出命令（BLPOP/BRPOP）和发布/订阅（Pub/Sub）功能，足以应对很多轻量级的异步和解耦场景，将耗时的任务（如发送邮件）数据放入List，由后台的工作进程取出处理，实现简单的任务队列（来源：Redis官方文档对列表和发布订阅模式的介绍）。

地理空间与附近的人 Redis的 GEO 功能基于有序集合实现，可以存储地理位置（经纬度），并快速计算两个点之间的距离，或者查找某个地点半径内的所有其他地点，这直接支撑了“附近的人”、“附近的餐厅”等LBS（基于位置的服务）功能，无需依赖复杂的外部地理数据库（来源：Redis官方文档对GEO命令的详细介绍）。

实时协作与数据同步 例如在线协作文档，当一方编辑时，需要将改动实时同步给其他协作者，Redis的发布/订阅（Pub/Sub）或更强大的Redis Streams（一种更可靠的消息流数据结构）可以作为实时消息通道，将编辑操作快速广播给所有在线用户，实现低延迟的协同体验（来源：Redis官方文档将Streams描述为用于实时消息传递的日志数据结构）。

Redis通过其丰富的数据结构（String, Hash, List, Set, Sorted Set, Bitmap, HyperLogLog, GEO, Streams）和原子操作，已经演变成一个高性能的“多模型”内存数据平台，它从简单的缓存，变成了解决实时性要求高、数据模型复杂、并发量巨大等问题的“瑞士军刀”，在社交、游戏、电商、实时分析等众多领域扮演着核心角色（来源：综合其对多种复杂场景的支持能力总结），它的价值，早已远远超出了单纯“扩大容量”的范畴。