Redis用着挺方便，可真要说远离它，也不是没理由，得好好琢磨下到底为啥要躲着点Redis

（一）

Redis用着是顺手，一把钥匙开一把锁，存取数据快得像闪电，但有时候，正是这种“太方便”的感觉，容易让人忘了它骨子里是个什么脾性，用着用着就踩了坑，这就像家里有把特别锋利的菜刀，切菜省力，可要是一个不留神，也能伤着自己，真不是说要完全不用Redis，而是得心里有数，知道在哪些节骨眼上得特别留神,甚至得琢磨琢磨是不是有更合适的家伙事儿能替它。

头一个得琢磨的，就是它那“记性”，Redis的数据都放在内存里，这才有了风驰电掣的速度，可内存这东西，比硬盘金贵多了，也有限多了，你要是可着劲儿地往里塞数据，特别是些大块头的数据，比如长长的列表、巨大的集合，或者存了不少图片的二进制数据，那内存消耗起来可是嗖嗖的，服务器内存一旦告急，Redis要么开始往外踢数据（按照你设定的策略，比如淘汰最久没用的），要么干脆摆挑子不干了，拒绝新的写入请求，这麻烦就来了：你以为是稳稳存在那里的数据，说不定啥时候就无声无息地消失了，这要是关键数据，那可就是一场事故，有人可能说，可以设置持久化，让数据也往硬盘上存一份，没错，Redis有RDB快照和AOF日志两种方式，但RDB是隔一段时间拍个照，两次拍照之间要是服务器宕机，这段时间的数据就全丢了，AOF呢，日志文件会越积越大，恢复起来也慢，持久化是为了保底，但它影响了Redis最引以为傲的速度，而且并不能从根本上解决内存容量有限这个问题，当你需要存储海量数据，或者对数据可靠性要求极高，一点都不能丢的时候，就得好好想想，Redis这把“快刀”是不是有点“小气”了,能不能扛住你的数据体量和可靠性要求。

（二）

再往下琢磨，Redis的“单线程”模式也是个需要掂量的点，它用单个线程处理所有命令，这避免了多线程的复杂锁问题，保证了操作的原子性，简单又高效，可这就像一条单车道，平时车少跑得飞快，一旦遇上大堵车，所有车都得排队等着，要是有个特别耗时的命令进来，比如对一个包含几百万个元素的集合进行KEYS *操作（这个命令在生产环境基本是禁用的），或者一个复杂的Lua脚本执行起来没完，那整个Redis服务器就会被这个慢操作“卡住”，后续所有的请求都得干等着，响应延迟瞬间飙升，整个应用可能就感觉“卡死了”，虽然Redis后来引入了非阻塞式的命令异步处理和一些后台线程来处理耗时的操作（比如持久化、网络IO），但核心的数据操作还是单线程，这意味着，它对那种需要高并发、且每个操作都要求极低延迟的场景非常适合，但如果你的业务里不可避免地会混入一些慢查询，或者数据模型设计得不合理，导致某些操作特别费劲，那这个单线程模型就可能成为瓶颈，一颗老鼠屎坏了一锅汤，你得非常小心地设计键值结构，避免使用那些时间复杂度高的命令,这无疑增加了使用的复杂度和心累程度。

（三）

然后就是功能上的“局限性”，Redis提供了丰富的数据结构，字符串、列表、集合、有序集合、哈希等等，应对常见场景很灵活，但它毕竟不是个全功能的关系型数据库，它不支持复杂的查询，比如你想做多表关联查询，或者根据多个条件灵活地筛选数据，Redis就无能为力了，它也没有严格的表结构（Schema），数据之间的关系需要你在应用层通过键的设计来维护，这在一定程度上把数据库层面的复杂性转移到了应用程序代码里，如果你的业务逻辑非常复杂，数据关联性很强，频繁需要各种复杂查询，那强用Redis就会觉得特别别扭，代码会写得很啰嗦，而且容易出错，这时候，传统的SQL数据库或者其他更强大的NoSQL数据库可能才是更自然的选择，Redis更像一个功能强大的瑞士军刀,但你不能指望它去干大型机床的活儿。

（四）

还有个躲不开的话题是“数据安全与持久化”的权衡，前面提到了持久化会影响性能，这里再从数据安全角度说说，即便你配置了AOF持久化，并且设置为每次写入都同步到磁盘（最安全模式），这依然会带来性能损耗，Redis默认是不加密的，如果部署在不受信任的网络环境中，数据有被窃听的风险，虽然可以通过SSL/TLS加密客户端连接，或者配合VPN等网络手段来加强安全，但这又增加了部署和管理的复杂度，相比之下，一些云服务商提供的完全托管的数据库服务，可能在安全、备份、扩缩容方面做得更省心，如果你团队里没有专门的运维人员来精心照料Redis，那么它潜在的数据安全和运维负担，也是个需要“躲着点”的理由。

（五）

就是“成本”问题，这里说的成本不光是钱，还有精力和复杂度，内存的成本比硬盘高，如果数据量巨大，纯靠内存存储，硬件成本会显著增加，虽然Redis有集群模式可以横向扩展，但搭建和维护一个Redis集群比单实例要复杂得多，你需要考虑数据分片、故障转移、网络配置等一系列问题，这引入了额外的运维负担和技术门槛，如果你的应用规模还没到那个程度，或者团队人力紧张，为一个缓存层投入这么大的运维精力，可能就有点得不偿失了，用一个更简单、更“笨”的方案，或者直接使用云数据库服务，把运维的麻烦事交给更专业的人，反而总体成本更低,也更省心。

所以说，Redis是个极好的工具，但它不是银弹，它的快，是用内存的代价换来的；它的简单，伴随着功能和查询灵活性的局限；它的高效，依赖于精巧的数据模型设计和命令使用，远离它，不是要全盘否定它，而是要清醒地认识到它的边界，在决定把Redis引入项目之前，最好先琢磨清楚：我的数据量到底有多大？对数据持久性要求多高？业务查询有多复杂？团队的运维能力跟不跟得上？想明白了这些，你才能决定是毫不犹豫地拥抱Redis这把“快刀”，还是在某些场景下，明智地“躲着点”，选择其他更趁手的工具，用好工具的关键，不在于工具本身有多强大，而在于你是否真正了解它,并把它用在最适合它的地方。