MySQL 迁移到 Redis 记

标签：复杂度   更新   asc   cache   检查   mon   替换   影响   计时   

前些日子，一个悠闲又不悠闲的下午，我还在用 Node.js 写着某个移动互联网应用的 API 服务端。那时还是用 MySQL 作为数据库，一切都很好，所有功能正常运行。可是有很多问题让人不安：

1. 频繁的产品功能变化让MySQL跟不上 产品初期功能变化很频繁，其中很多变化都不得不对数据库结构做出更改。对于MySQL来说，也许是改一个字段名方便SELECT，也许是把一个字段移到另一个表方便索引，也许是要对多个表重新设计来达到修改要求（这种情况最惨烈，但开发过程中遇到过不止一次<char_group class="biaodian cjk">）。

2. 符合范式的设计让JOIN在SELECT语句中大行其道

   尽管在设计时已经做好规划，保证在多数查询时不会用到JOIN，但是在其它不少地方仍然很难回避两表甚至多表联查，一些模块中SQL语句的复杂度甚至能达到大学数据库原理考试时考查的SQL语句题目的水平。写起来烦，想想实际运行情况，也不禁为MySQL同学捏一把汗。于是后来对复杂的MySQL语句增加了Cache，Redis第一次在这个项目登场就是干这个的，当时Cache的设计思路是：

   Redis存储两份数据，一份是数据缓存，一份是数据的最新版本号，执行复杂SQL查询时先检查这个查询在Redis里有没有数据缓存且对比数据的最新的版本号看当前数据缓存是不是最新的，是的话就读出来直接返回，不是的话查询MySQL得出结果并保存在Redis数据缓存中。如果更新了会影响这个查询结果的数据的话则简单地将Redis里该数据的最新版本号加1即可。

   这个设计很简单实用，但很快问题就暴露出来了：因为缓存的加入导致整个系统更复杂，而且随着MySQL数据库结构的不断复杂，单纯加入缓存无法根本上解决这一问题。更重要的是，由于读写频率基本保持在1:1，导致缓存命中率极低，不如不用。

3. 一切问题的解决方案都是NoSQL 上述问题让我重新考虑是否用NoSQL替换MySQL。关于NoSQL数据库我接触过的为MongoDB和Redis，最后选择Redis的原因是因为系统中已经使用了Redis做Cache，对Redis了解更多。

   现在的API服务端代码已经从Node.js(JavaScript) + C + MySQL迁移到Node.js(CoffeeScript) + C + Redis。通过实践，使用Redis后的代码更易维护，更加整洁，性能也更高。同时在迁移时写了一个简单的Redis ORM模块，用起来十分方便。

MySQL 迁移到 Redis 记

标签：复杂度   更新   asc   cache   检查   mon   替换   影响   计时   

原文地址：https://www.cnblogs.com/edda/p/12846159.html