用Redis来存常用配置表，感觉访问快又方便，适合动态改配置信息

最近在琢磨系统配置管理的事儿，以前老做法是把一些常用配置，比如开关设置、参数阈值、业务规则啥的，直接写死在代码配置文件里，像 properties 文件或 yaml 文件，每次想改点东西，哪怕就调个数字或者开个功能，都得去重新修改配置文件，然后打包、部署、重启应用，这一套流程下来，不光麻烦，关键是服务还得中断一会儿，特别不灵活，后来也试过用关系型数据库，MySQL 来存配置，虽然改起来不用重启了，直接在数据库里 update 一下就行，但每次读取配置都得去连一次数据库，执行一次 SQL 查询，如果配置被频繁访问，哪怕它不怎么变，也会对数据库造成不必要的压力，感觉有点大材小用,而且速度上总觉得不够理想。

后来了解到可以用 Redis 来存这些常用的配置表，试了试，感觉确实挺不错的，主要就是两点：访问快、改起来方便,下面具体说说我的理解。

先说为什么访问快。 这跟 Redis 本身的特点分不开，Redis 是一种内存数据库，它主要把数据放在服务器的内存里，我们都知道，从内存里读数据的速度，比从硬盘（比如传统数据库的数据文件）读要快太多了，根本不是一个数量级的，当应用需要获取某个配置值时，比如查询“用户每日签到最大积分限制”是多少，直接向 Redis 发起一个简单的 GET 命令，瞬间就能从内存里拿到结果，响应速度非常快，通常都在毫秒级别，这对于那些对性能要求高的场景，比如高并发下的业务逻辑判断，能大大减少等待时间，提升整体响应速度，相比之下，每次读配置都去查询关系型数据库，即使有缓存，也可能涉及到网络开销和 SQL 解析的消耗，速度上自然没法和直接操作内存的 Redis 比，Redis 支持丰富的数据结构，比如字符串（String）、哈希（Hash）、列表（List）、集合（Set）等，我们可以根据配置项的特点灵活选择，一组相关的配置项（比如邮件服务器的配置：host、port、username、password），可以用一个 Hash 结构来存储，一次操作就能取回所有相关字段,非常高效。

再说动态修改配置的方便性。 这是让我觉得特别省心的地方，用 Redis 存配置，当需要修改某个配置值时，运维人员或者通过管理后台，可以直接连上 Redis，使用 SET 或 HSET 这样的命令，在线就能修改，修改操作几乎是立即生效的，因为数据就在内存里更新了，之后所有再来读取这个配置的应用实例，拿到的就是最新的值，完全不需要重启应用服务，实现了真正意义上的热更新，这就解决了之前写死配置需要重启的痛点，搞运营活动的时候，需要临时把某个商品的下单频率限制从每分钟 5 次调到 10 次，直接在 Redis 里把对应配置值一改，全网的服务器立马就感知到了，活动可以马上按照新规则跑起来，特别灵活，再比如，遇到某个功能有 bug 需要紧急下线，可以把对应的功能开关配置从“开启”改成“关闭”,问题就能快速被屏蔽掉。

用 Redis 存配置也不是说就完美无缺，一点注意事项都没有，因为数据主要存在内存里，所以配置项的总量得控制一下，不能毫无节制地往里塞，得考虑内存容量，不过对于通常的“配置表”数据量一般都不会太大，这点通常不是问题，虽然 Redis 本身有持久化机制（可以把内存数据定期存到硬盘上），以防止服务器断电重启导致数据丢失，但我们需要根据配置数据的重要程度，合理配置 RDB 快照或 AOF 日志的持久化策略，确保关键配置不会丢，配置数据不算特别海量,开启持久化后可靠性是有保障的。

对于那些需要频繁读取、又可能经常需要动态调整的常用配置信息，把它们从传统的配置文件或者关系型数据库里挪到 Redis 中，确实是一个很值得考虑的方案，它充分发挥了内存读写的高速特性，又赋予了系统运行时动态调整配置的灵活性，让整个系统的响应能力和可维护性都得到了提升，感觉在很多中小型项目或者大型项目的特定模块里,这种用法都挺合适的。