我有一个任务，大概 15 秒要访问一次服务器配置以决定是否继续，服务器配置表其实就一条数据，表里面的内容也不多。
从性能角度来讲，是不是放到 Redis 里比较好？ Postgres 对于这样经常访问的数据应该也有优化才对，但是我看 Debug 日志倒是成片成片的，是不是眼不见为净就算了？

是的，放在内存里比较好，所以你的数据库和你的操作系统都会把经常访问的数据存在内存里。

加缓存的话需要注意下数据一致性

确实，但...
15 秒访问一次还考虑什么 redis 数据库？
放 redis 还要考虑持久化、可配置、一致性这三者怎么同时满足。还不如直接放数据库。你要是说 1 秒 15 次，还可以考虑缓存一下。

没啥问题为什么要改呢?

一天也就 4 60 24 = 5760 次，数据库一秒的 pps 也不止这个数了

只看这点描述，完全没必要想这么多啊，所以忽略你的其他背景的情况下：

  1. 先正确实现业务，用最熟悉的存储后端
  2. 优化性能表现，最简单的就在 1 基础上插入一成缓存，最好缓存后端灵活点，单机就内存，replicate 就弄个外部的缓存

总结来说就是，都要

就这个频率而言，你放 pgsql 里完全没问题，或者像楼上所说的，在程序层面加个缓存就够了

小文件，15 秒访问一次，I/O 负担不值一提。放内存会稍微快一点，但也不明显

代码本身需要使用 Redis 那可以顺便放 Redis ，如果本身没用到就没必要专门去连接了，不放也不会有什么性能问题

这种没什么负担的，保持每 15 秒查一次数据库，无需引入复杂的设计，也有利于将来能减轻设计负担。

有限小批量数据放内存是最佳选择，但要注意多机一致性
如果量是递增的最好是放到 redis ，防止 oom 。但读频率非常高的话 redis io 也可能成为瓶颈，所以还是要看下实际业务情况权衡

15 秒一次这个访问频率没必要引入额外的 redis, 放在 pg 里就够了.
如果已经有现成的 redis, 而且不是做缓存用途是作为数据库的, 倒是可以选择放进去

15 秒一次实在没必要，除非这个过程对整体系统有较大影响

如果确实像放内存，可以先试一下 sqlite3 内存模式，你可以容易接受（上手）一些。

放在 CPU 的 Cache 里

15 秒一次何必这么紧张…还以为是抢鸡蛋呢

访问频率这么低。。。没必要过度优化

15 秒访问一次，QPS ~= 0.066 ，但是如果 10 万设备在线呢，马上 6666 了。
如果每次请求产生 10 次 read 和 3 次 write ，那就 9 万次读写了，偶尔小高峰抖一下轻松破 10 万。

又不是 15 毫秒

上 cdn 协商缓存更有效,扔内存,治标不治本

他这是个定时任务，按道理跟并发没啥关系...即使有，完全可以服务器端访问一次，然后并发给 10 万设备用。