这是一个创建于 1598 天前的主题，其中的信息可能已经有所发展或是发生改变。
我有一个任务，大概 15 秒要访问一次服务器配置以决定是否继续，服务器配置表其实就一条数据，表里面的内容也不多。
从性能角度来讲，是不是放到 Redis 里比较好？ Postgres 对于这样经常访问的数据应该也有优化才对，但是我看 Debug 日志倒是成片成片的，是不是眼不见为净就算了？
 | 1 msg7086 2021 年 11 月 23 日  2 是的，放在内存里比较好，所以你的数据库和你的操作系统都会把经常访问的数据存在内存里。 |
 | 2 7911364440 2021 年 11 月 23 日 加缓存的话需要注意下数据一致性 |
 | 3 Vegetable 2021 年 11 月 23 日 确实，但... 15 秒访问一次还考虑什么 redis 数据库？ 放 redis 还要考虑持久化、可配置、一致性这三者怎么同时满足。还不如直接放数据库。你要是说 1 秒 15 次，还可以考虑缓存一下。 |
 | 4 securityCoding 2021 年 11 月 23 日 没啥问题为什么要改呢? |
 | 5 matrix67 2021 年 11 月 23 日 一天也就 4* 60 *24 = 5760 次，数据库一秒的 pps 也不止这个数了 |
 | 6 thevita 2021 年 11 月 23 日 只看这点描述，完全没必要想这么多啊，所以忽略你的其他背景的情况下： 1. 先正确实现业务，用最熟悉的存储后端 2. 优化性能表现，最简单的就在 1 基础上插入一成缓存，最好缓存后端灵活点，单机就内存，replicate 就弄个外部的缓存 总结来说就是，都要 |
 | 7 Huelse 2021 年 11 月 23 日 就这个频率而言，你放 pgsql 里完全没问题，或者像楼上所说的，在程序层面加个缓存就够了 |
 | 8 eason1874 2021 年 11 月 23 日 小文件，15 秒访问一次，I/O 负担不值一提。放内存会稍微快一点，但也不明显 代码本身需要使用 Redis 那可以顺便放 Redis ，如果本身没用到就没必要专门去连接了，不放也不会有什么性能问题 |
 | 9 yidinghe 2021 年 11 月 23 日 via Android 这种没什么负担的，保持每 15 秒查一次数据库，无需引入复杂的设计，也有利于将来能减轻设计负担。 |
 | 10 dddd1919 2021 年 11 月 23 日 有限小批量数据放内存是最佳选择，但要注意多机一致性 如果量是递增的最好是放到 redis ，防止 oom 。但读频率非常高的话 redis io 也可能成为瓶颈，所以还是要看下实际业务情况权衡 |
 | 11 karloku 2021 年 11 月 23 日 15 秒一次这个访问频率没必要引入额外的 redis, 放在 pg 里就够了. 如果已经有现成的 redis, 而且不是做缓存用途是作为数据库的, 倒是可以选择放进去 |
 | 12 Feiex 2021 年 11 月 23 日 15 秒一次实在没必要，除非这个过程对整体系统有较大影响 |
 | 13 loading 2021 年 11 月 23 日 如果确实像放内存，可以先试一下 sqlite3 内存模式，你可以容易接受（上手）一些。 |
 | 14 shayuvpn0001 2021 年 11 月 23 日 放在 CPU 的 Cache 里 |
 | 15 adoal 2021 年 11 月 23 日 via iPhone 15 秒一次何必这么紧张…还以为是抢鸡蛋呢 |
 | 16 jusonalien 2021 年 11 月 23 日 访问频率这么低。。。没必要过度优化 |
 | 17 sagaxu 2021 年 11 月 23 日 15 秒访问一次，QPS ~= 0.066 ，但是如果 10 万设备在线呢，马上 6666 了。 如果每次请求产生 10 次 read 和 3 次 write ，那就 9 万次读写了，偶尔小高峰抖一下轻松破 10 万。 |
 | 18 ch2 2021 年 11 月 24 日 又不是 15 毫秒 |
 | 19 TomVista 2021 年 11 月 24 日 上 cdn 协商缓存更有效,扔内存,治标不治本 |
Select Language