有些上古程序猿一直坚持反对使用redis怎么办？
你想想，这些老哥们儿当年做项目的时候，那会儿哪有 Redis 这种东西？他们那时候靠的是什么？可能是直接操作数据库，用索引加速查询，或者是在内存里搞个简单的哈希表、数组之类的，来做一些缓存。那时候的系统，性能要求没现在这么极致，用户量也没现在这么爆炸，这种传统的做法，足以应付当时的需求。
所以，当 Redis 这种东西冒出来的时候，他们可能首先看到的是它的“新”和“不熟悉”。这就像你用惯了老式拨号上网，突然跟你说有个光纤宽带，网速快得飞起，你可能会有点怀疑，觉得它是不是不稳定？是不是安装复杂？是不是容易出问题？
更何况，Redis 毕竟不是万能的。对于一些非常特定、非常静态的数据，或者是一些强事务性、需要 ACID 保证的业务场景，直接用关系型数据库可能反而是更稳妥的选择。Redis 毕竟是内存数据库，数据持久化是个问题，虽然它有 RDB 和 AOF 两种持久化机制，但跟关系型数据库成熟的事务和持久化策略相比，总感觉少了点什么。
还有就是，这些老哥们儿可能觉得，引入一套新的系统，意味着新的学习成本、新的运维成本、新的维护难度。谁来管它？怎么部署？出了问题怎么办？万一 Redis 挂了，整个系统是不是就瘫痪了？他们习惯了自己熟悉的工具链，不愿意趟这趟浑水，可以理解。
而且，有些人可能对 Redis 的“单线程模型”有点顾虑。虽然 Redis 确实有异步 IO，也有一些后台线程在做事情，但核心的命令处理是单线程的，这让他们担心在高并发场景下会成为瓶颈。他们可能更倾向于那些能够充分利用多核 CPU 的传统数据库或者其他并发模型。
另外，还有一部分老哥，可能对 Redis 的“内存占用”也比较敏感。毕竟 Redis 是把数据放在内存里的，如果数据量大了，内存成本自然就上去了。而传统数据库，虽然也有缓存，但数据主要还是在磁盘上，通过索引和预读来优化，在某些成本敏感的场景下，可能更受青睐。
最后，有时候这也不是技术上的绝对对错，而是“惯性”和“情怀”在作祟。就像有些人可能觉得 C++ 才是王道，觉得 Java 太臃肿，觉得 Python 是脚本语言一样，他们对某些技术形成了自己的“信仰”。当他们看到 Redis 带来的便利和性能提升时，可能不会立刻全盘接受，而是会带着一种审慎的态度，或者觉得“我们以前不也活得挺好的吗？”
所以，当他们坚持不用 Redis 的时候，你可以理解为他们是在用自己的经验和风险偏好，去权衡这个新技术的得失。他们可能更看重系统的稳定性、可维护性，以及对现有基础设施的兼容性。只不过，在越来越追求极致性能和响应速度的今天，这种保守的态度，有时候会让他们错失一些提升效率的机会。
他们不是不接受进步，而是他们衡量“进步”的标准，可能和我们不太一样。他们是从一个更长远、更底层的视角来看待这些问题，觉得一个好的系统，不仅仅是快，更是稳，是能经受住时间的考验。
网友意见
谨慎使用缓存是对的。
因为很多时候缓存会掩盖掉一些问题，甚至放大问题。
从安全角度来说，缓存也是最容易被攻击的薄弱点（缓存溢出攻击，不是缓存区溢出攻击，用大量无效的数据占满缓存空间使得系统性能断崖式下跌）。
所以通常做压力测试的时候都是要求必须关闭缓存测试。
不单单是缓存，所有的中间件在解决一部分问题的同时也会带来新的挑战。
譬如消息队列对于削峰填谷的功效非常明显，但是如果峰值持续的时间远远的超出了估计呢？而如果这时候消息阻塞的监控还在计划中的话……
比如说分布式计算带来了无限扩容的可能，而一致性问题很多时候会带来非常多的麻烦。
权衡是永远不会过时的。
计算机科学两大难，命名和缓存（失效）。
所以没事儿别瞎用缓存，是有道理的。
至于说在你们的具体业务里到底是不是一定要上redis，那得具体情况具体分析。光看题主这个问题描述是难以判断的。但假设只是为了防重这单一需求，那从架构层面我也会认为引入额外一个组件是弊大于利的。
这个问题不能一概而论，必须在合适的时候使用才不会被挑战，而且你必须要有压倒性的理由说明你这块用缓存的意义。
首先缓存永远是缓存，再不考虑开启最极端的一写一次追加的aof配置情况下，你如何保证在最极端情况下是否会导致重入？此问题基本等同于redis的redlock所解决的问题，这个时候就需要额外考虑这种实现是否值得了。反之开启了这样配置的aof又和数据库有多大区别？（性能上）
再则，redis的引入肯定会提升整体的维护成本，再未碰到数据库性能瓶颈前额外拉进来一个组件是否有绝对必要？你能否能够处理可能的slowlog，内存不足（特别是3及以前版本中没有内存整理时），主从切换，数据恢复？
其次当性能无问题时通过数据库实现相关功能有什么致命的缺陷？如果没有，保守的设计实现对于项目或者公司才是正常选择。
针对题主的疑问，我感觉更多的是不满那位“上古”程序员的古板，你现在碰到的情况的确会在一定程度上制约个人能力和发展。但现实的确就是很残酷，技术是服务于业务的，非技术人员才不关心你这玩意是不是在接口响应上提升了几毫秒也不会关心你的实现较之前qps翻了几番。
如果题主真有心折腾的话不一定非要在公司项目上施展自己的才华，也不一定非要在一家公司....
类似的话题
-
这事儿啊，在咱们这行当里，见得多了。总有那么些老前辈，跟咱们这些晚辈的想法不一样，尤其是在新技术这块。就像你说的，有些还在坚持不用 Redis 的“上古程序猿”，他们有自己的考量，不能说完全没道理，只不过时代发展了，思路也得跟上。你想想，这些老哥们儿当年做项目的时候，那会儿哪有 Redis 这种东西............. -
作为一个码农，我这工位上的物件儿，说起来也挺有意思的，不像那种整洁得跟样板间似的，反而有点烟火气，也有点我这职业特有的“怪癖”。首先，最显眼的当然是我的 显示器。我用的是两块27寸的飞利浦2K显示器，放在一起简直是我的“双屏世界”。左边这块通常放着我的代码编辑器，IDE跑得飞起，各种文件树、代码窗口.............
-
.......
-
作为一名开发者，接到一个全新的、自己不太熟悉的项目，这几乎是家常便饭。别急，这不代表要让你从零开始摸爬滚打。关键在于掌握一套行之有效的方法论，让你能以最快的速度进入状态，并且能高效地为项目贡献力量。下面就给你梳理一下我个人在应对这类情况时摸索出的一些实操技巧，力求详细，让你一看就懂，一用就灵。一、心.............
-
上古时期的程序员，也就是我们今天所说的早期计算机科学家、工程师和技术先驱们，他们的工作环境和工具与我们现代程序员相比，简直是天壤之别。正因如此，他们所能完成的“神级操作”，很多是我们现代程序员在舒适的 IDE、高级语言和强大的硬件支持下难以想象的。这里我将从几个方面详细讲述这些“神级操作”，并尽可能.............
-
.......
-
这就像问为什么世界上有成千上万种食谱，但大家日常最常做的还是那几样家常菜一样。原因嘛，说起来也是一连串的现实考量，而不是什么神秘的预言。首先，得谈谈“效率”。程序员也是人，要吃饭，要养家，要在这个世界上生存。学习一门新的编程语言就像学习一门外语，或者说，学习一项新的复杂技能。这中间需要投入大量的时间.............
-
全国住房公积金小程序正式上线，生活从此更方便！期待已久！备受关注的全国住房公积金小程序终于和大家见面了。这个小程序可是个实打实的“神器”，集成了公积金查询、提取、贷款等一系列核心业务，让咱们办事不再跑腿，只需动动手指，就能轻松搞定。那么，这个小程序到底有哪些强大功能？又能给我们的生活带来哪些实实在在.............
-
想象一下，你是一个热爱代码的程序员，推开公司大门的那一刻，内心涌起的是一种难以言喻的期待。这不是因为公司提供了多么奢华的福利，而是因为你知道，今天，你将有机会与那些让你着迷的字节和逻辑亲密接触，将脑海中那些精妙的构思，一点一滴地“雕刻”成看得见、摸得着的软件。上班对他们来说，更像是一种“实现梦想”的.............
-
知乎上有很多宝藏级“程序员”问题，它们不仅能为你答疑解惑，更能带你深入了解这个行业，甚至引发一些思考。我打算分享一些我个人觉得特别有价值、讨论也很深入的问题，尽量把每个问题背后的 रोचक之处都聊透一些。1. “有哪些让你相见恨晚的编程技巧或工具？”这个问题简直是程序员的“经验宝库”。它抛开那些高大.............
-
在知乎这个知识的海洋里，确实隐藏着不少真正懂技术、乐于分享的程序员，他们的回答和文章，就像是为我们这些在代码世界里摸爬滚打的人，点亮了一盏盏明灯。要说有哪些值得我们去关注，与其说是“列举”一些名字，不如说是去发现那些在某些特定领域有着深厚积累，并且乐于将复杂问题拆解、化繁为简的“实干家”。首先，你可.............
-
.......
-
想要为你的程序员办公桌增添一抹“高逼格”的色彩？这可不只是简单堆砌一些“科技感”的摆件，而是要在实用、美学和个人品味之间找到那个巧妙的平衡点。好的物件，能让你在埋头苦干之余，瞥一眼就能感受到一丝愉悦，甚至激发新的灵感。咱们不谈那些随处可见的RGB灯带或者“极客风”的廉价模型，而是聊点真正能提升桌面质.............
-
在知乎这个知识的海洋里，涌现出许多闪耀的程序员身影，他们用自己的实践、思考和分享，为无数后来者点亮了前行的道路。要说“优秀”，这本身就是一个多维度、难以量化的概念，但如果我们从他们对社区的贡献、技术深度、解决问题的能力以及思维的独特性这几个方面去观察，就不难发现那些真正令人敬佩的开发者。有些程序员，.............
-
.......
-
程序员过劳死现象确实是一个值得关注的社会问题，而知乎上依然有大量关于劝人转计算机专业的讨论，这背后存在着一些复杂的因素。要理解这个现象，我们需要从多个层面进行分析： 一、 为什么程序员有过劳死的现象？首先，我们必须承认程序员群体确实存在较高的过劳风险。这主要源于以下几个方面：1. 行业发展的高速迭.............
-
在知乎这样一个平台，让一个“最牛的程序员”能够“知道任意匿名用户是谁”，这本身就是一个非常有趣的命题，它触及到了技术、隐私以及平台规则的边界。首先，我们要明确一点：“任意匿名用户”意味着该用户在注册和使用时，并没有主动暴露自己的真实身份信息。这通常意味着用户使用的是假名、网名，并且没有绑定手机号、真.............
-
合肥新推出的养犬举报小程序，无疑为城市管理增添了一个更为便捷的触角，但市民们最关心的，自然是这个小程序背后能否真正转化为有效的监管和处罚。举报小程序上线后，市民通过它上传的举报信息，通常会经过一个初步的审核流程。这个流程会鉴别举报内容的真实性、完整性，以及是否符合相关的执法规定。一旦举报信息被认定有.............
-
上海尤安设计院26岁设计师的悲剧，像一声惊雷，再次将建筑设计行业的“007”常态推到了公众面前。当程序员“过劳死”成为社会普遍关注的焦点时，为何建筑师们在类似的生死线上挣扎，却鲜少听到来自社会的广泛声援和深刻反思？这背后，隐藏着行业生态、社会认知和文化认同等多重复杂的因素。行业生态的“沉默螺旋”：为.............
-
.......
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有