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