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