项目里把Redis缓存给剔除掉，想说说去掉它的那些事儿和影响

这事儿得从头说起，当初在项目里引入Redis，主要是因为数据库有点扛不住了，每次用户一多，页面加载就转圈圈，查了一下，全是直接去数据库里捞数据，数据库压力山大，那时候，听大家都说Redis是解决性能问题的“银弹”，速度快得像闪电，就把一些经常被访问但又不太变动的数据，比如用户的基本信息、一些页面的配置项、还有首页的热门文章列表，都给塞到Redis里了，效果确实是立竿见影，页面刷新的速度快多了，数据库也终于能喘口气了。（来源：项目初期引入Redis的背景和目的）

那为啥现在又要把它给剔除掉呢？这事儿不是一拍脑袋决定的,有几个原因凑到一块儿了。

最直接的原因是，我们的项目规模其实没想象中那么大，一开始想着用户量会爆发式增长，但实际运营下来，虽然用户数在稳步增加，但远没到那种需要Redis这种“重型武器”来支撑的地步，大部分时间里，数据库自己完全能处理得来，这就好比杀鸡用牛刀，刀是很快，但总觉得有点大材小用，还得多费心去保养这把刀。（来源：项目实际负载评估）

也是让我们下决心去掉它的关键点，就是复杂度上去了，以前觉得加个缓存很简单，但真用起来才发现，带来的麻烦事不少，最头疼的就是数据一致性问题，后台管理员修改了某个用户的昵称，数据库里是改成功了，但要是Redis里的旧数据没及时清理掉，用户看到的就还是老名字，为了处理这种问题，我们得写额外的代码，在更新数据库的同时，去删除或者更新Redis里对应的缓存，有时候代码逻辑没处理好，或者网络抽风一下，缓存没删掉，脏数据就能在那儿存好久，时不时就有用户来投诉，这就像家里多了一个储物间，东西是放得快了，但你要记得哪个东西放在哪个角落，不然要用的时候死活找不到，或者找到的是过期的。（来源：实践中遇到的数据一致性难题）

Redis本身也需要维护，虽然它很稳定，但也不是完全不用管，我们得操心它的内存够不够用，要不要配置持久化以防万一服务器重启数据丢了，还得监控它的运行状态，项目里就我们几个开发，又要写业务逻辑，又要管数据库，现在还得额外分心照顾Redis，感觉精力被分散了，服务器成本也是一点点在增加。（来源：运维复杂度和成本考虑）

把Redis剔除掉之后，带来了哪些影响呢？说实话，有好的方面,也有需要适应的地方。

好的变化非常明显：

1. 系统一下子简单多了，最直观的感受就是心里踏实了，现在数据只有一个来源——数据库，我们再也不用担心缓存和数据库数据对不上的问题了，那种因为缓存不一致导致的诡异Bug也随之消失了，代码库也清爽了，所有关于Redis的设置、连接、读写、失效处理的代码全都删掉了,维护起来省心不少。
2. 部署变得更简单，以前部署新版本，还得确保Redis服务先起来，配置好连接信息，现在不用了，直接搞定数据库就行,部署流程缩短了。
3. 成本降了，省下了一台专门跑Redis的服务器费用，虽然不多,但能省一点是一点。

也带来了一些挑战和变化：

1. 最担心的性能问题，刚开始那几天，我们紧盯着数据库的监控和网站的响应速度，确实，在个别访问量集中的时候，比如某个热门活动页面，页面响应速度比有缓存的时候慢了一些，能感觉到轻微的延迟，但出乎意料的是，对于绝大多数日常操作，用户基本感知不到差别,这说明我们之前可能高估了缓存的必要性。
2. 对数据库的依赖更重了，所有的压力都回到了数据库身上，这就要求我们必须更加优化数据库，比如给常用的查询字段加上合适的索引，避免写出慢SQL语句,这算是倒逼着我们去做之前可能忽略的数据库优化工作。
3. 思维方式的转变，用了太久缓存，有时候写代码会不自觉地想“这个地方可以缓存一下”，现在得改掉这个习惯，先想想是不是真的有必要，能不能通过优化查询来解决,这是一种回归简单的设计思路。

回过头看这次“去Redis”的经历，我的体会是，技术选型真的不能盲目跟风，Redis绝对是个好东西，但它不是免费的午餐，它会引入额外的复杂性，对于像我们这样处于特定发展阶段、业务逻辑还不是超级复杂的项目来说，过早引入它，带来的维护成本可能已经超过了它的性能收益。（来源：项目复盘后的核心总结）

现在我们的原则变成了：除非有确凿的证据表明数据库已经成为明确的性能瓶颈，并且优化SQL和数据库索引这些简单手段都效果不佳时，才会考虑重新引入缓存，现阶段，我们更愿意把精力花在写好SQL、做好数据库优化上，让系统保持尽可能的简洁和可控，这件事也提醒我们，在软件开发里，减法”比“加法”更需要勇气和智慧。