Redis有时候真不太合适用，哪些场景其实更别碰它了？

关于Redis什么时候不合适用,或者说哪些场景最好别碰它，其实是一个特别重要的问题，因为现在好像什么项目都想用一下Redis，觉得它快，能解决所有性能问题，但事实是，如果用错了地方，它带来的麻烦会比解决的问题多得多，下面这些场景，你就得特别小心，最好考虑别的选择。

（来源：基于Redis官方文档的警告以及常见的工程实践教训）

第一，千万别拿Redis当主数据库用，尤其是存那种丢了就找不回来的核心数据。 Redis虽然提供了持久化功能（就是把内存数据写到硬盘上），但它的设计初衷是缓存，它的持久化有两种方式：RDB（像拍快照）和AOF（像记日记），RDB方式可能会丢失最后一次快照到宕机之间的数据，AOF方式虽然更安全点，但对性能有影响，而且在极端情况下（比如服务器突然断电）也不是100%保险，如果你的业务要求数据绝对不能丢，比如用户的账户余额、订单的支付状态，那你必须用一个像MySQL、PostgreSQL这样的关系型数据库作为“主数据库”，Redis只能作为它前面的一个加速缓存，你把最重要的家当放在一个可能因为内存满被清理掉，或者因为持久化延迟而丢失的系统里，这风险太大了。

（来源：Redis作者antirez在博客中多次强调Redis的定位是缓存和高速数据结构服务器，而非传统数据库）

第二，处理大尺寸的二进制文件，比如图片、视频、大型文档。 Redis之所以快，是因为它把所有数据都放在内存里，内存是很金贵的资源，如果你把一堆几个MB甚至几十MB的图片缓存到Redis里，很快就会把内存撑爆，即使你有很多内存，从网络上传送这么大的数据到Redis，以及Redis再把它送出去，都会消耗大量的网络带宽和CPU资源，反而可能成为瓶颈，这种场景下，用对象存储（比如阿里云OSS、AWS S3）或者本地文件系统，配合CDN加速，是更经济、更合适的方案，Redis更适合存一些小的、结构化的元数据信息。

第三，需要复杂查询和关联关系的场景。 Redis是一个键值存储，你基本上只能通过key来查找value，它虽然提供了一些数据结构，比如List、Set、Hash，但它的查询能力非常有限，你不能像在SQL数据库里那样，执行诸如“查找所有年龄大于30岁且城市是北京的用户”这样的复杂查询，虽然你可以通过一些设计模式（比如维护额外的索引集合）来模拟，但这会让你的应用代码变得非常复杂和脆弱，而且维护成本极高，如果你的业务逻辑天生就需要多维度、ad-hoc（即席）的查询，或者需要表与表之间的关联（JOIN），那么关系型数据库或者专门的搜索引擎（如Elasticsearch）才是你的菜。

（来源：在《Redis in Action》等书籍中，作者会特意说明Redis数据模型的局限性）

第四，数据量巨大，远超服务器内存容量的场景。 如果你的应用需要缓存的数据有几百个GB，甚至几个TB，而你的服务器内存只有几十个GB，那么你就要慎重了，Redis的核心数据模型要求所有数据必须在内存中，虽然Redis有虚拟内存之类的过时功能，但早已不被推荐使用，现在虽然有Redis on Flash这样的商业方案，但社区版不行，当数据量远大于内存时，你只能频繁地淘汰旧数据，这会导致缓存命中率急剧下降，失去了缓存的意义，这种情况下，可以考虑使用LevelDB、RocksDB这类磁盘型的键值数据库，或者进行数据分片，但分片本身又会带来管理和复杂度的提升。

第五，需要频繁进行批量写入或大规模数据分析的场景。 Redis是单线程处理命令的（指核心的数据操作部分），这个设计让它避免了锁的竞争，简单高效，但这也意味着，如果你需要一次性写入十万条数据，或者对一个非常大的集合进行求交集、排序等复杂操作，这个操作可能会阻塞其他所有的请求，导致整个Redis服务在几百毫秒甚至几秒钟内无法响应，这对于一个要求低延迟的在线服务来说是灾难性的，这种批处理任务或者分析任务，应该交给专门的分析型数据库（如ClickHouse）或者Hadoop/Spark这类大数据框架去做，而不是让Redis这个“前台接待”去干“后台仓库”的重体力活。

（来源：Redis官方文档在介绍单线程模型时，明确提到了长时间运行命令的危害）

第六，对事务一致性要求非常高的金融场景。 Redis支持事务（MULTI/EXEC），但它的事务和MySQL那种ACID事务完全不是一回事，Redis的事务只是保证了一系列命令被顺序地、不被打断地执行，但它不具备“原子性”里的“回滚”能力，也就是说，如果在执行事务的过程中，某个命令出错了，Redis不会自动回滚之前已经执行成功的命令，它更像是批处理，在需要强一致性的场景下，比如转账，A扣款和B加款必须同时成功或同时失败，用Redis原生事务是无法保证的，虽然可以通过Lua脚本来实现更复杂的逻辑，但依然无法提供像关系型数据库那样成熟、可靠的事务保证。

Redis是一把锋利的瑞士军刀，它在缓存、排行榜、消息队列（简单场景）、会话存储等特定任务上表现出色，但你不能指望它替代所有的工具，当你的需求涉及到海量数据且不能丢、复杂查询、数据远超内存、繁重批处理、强一致性事务时，就应该意识到，Redis可能不是合适的工具，甚至是个“火坑”，正确的做法是理解每种工具的长处和短板，让Redis在它最擅长的位置上发光发热，而把其他任务交给更专业的系统去处理。