Replies: 5 comments 6 replies
-
|
对于 CDN 的资源会不会出现第一次点击打不开，第二次点击才打开的情况，毕竟 CDN 的 TTL 本身就很短 |
Beta Was this translation helpful? Give feedback.
-
|
有可能，这是最大的问题😬 |
Beta Was this translation helpful? Give feedback.
-
|
反对。lazy update 的方式用在 dns 上有些不妥。 不过主动更新是可以的，类似 unbound 的 prefetch https://nlnetlabs.nl/documentation/unbound/unbound.conf/ 比如主动更新缓存里最常用的前 10% 的域名。 |
Beta Was this translation helpful? Give feedback.
-
|
哈哈，果然不太行😝 |
Beta Was this translation helpful? Give feedback.
-
|
即使是30秒的TTL也会对客户端造成很大困扰， 这就像程序出现一个本来应该抛出去的异常， 你给他忽略了， 客户端说不准啥时候暴雷， 这类似于违反快速失败原则 |
Beta Was this translation helpful? Give feedback.
-
|
纯属雷同 已有按照这个思路实现的dns服务器 AdGuardHomes上也有这样的[Feature Request] |
Beta Was this translation helpful? Give feedback.
-
|
我不太懂go，想自己实现这个插件出来，本以为拿原本的cache插件稍微改改就行了 结果，[拿到过期缓存直接返回并请求上游去更新缓存]这一步完全搞不定🤣 |
Beta Was this translation helpful? Give feedback.
-
|
参考“最终一致性系统”。DNS 就是一个 “最终一致性系统”。所以我一直坚持 ttl 只能变小不能变大，也就是说只能 prefetch，不能 lazy update。
你可以让用户指定一个更新用的 插件 tag。然后去执行它。 |
Beta Was this translation helpful? Give feedback.
-
|
嗯，插件的我再研究研究 这里呢我主要讲究实用性，这玩意主要拿来自用的，实用第一 |
Beta Was this translation helpful? Give feedback.
-
|
我是dcompass的作者，关于lazy update的问题，其实就是为了缓解极差网络环境下且遇到大量inbounding请求的情况。不过失效后第一个请求的程序必然会得到outdated的结果，但是一般程序都是resilient的，加上outdated的responses也不是不可用。 |
Beta Was this translation helpful? Give feedback.
-
|
cache应该是共享的，比如A请求了www.google.com，返回结果放在cache缓存。 ×如果在ttl的时间内，B请求www.google.com，就应该立即返回缓存的结果，不管是不是带有cookie的等选项； 上面的机制应该是unbond的模式，我使用了这种模式大概有1年的时间，正常的家庭上网、看剧、玩游戏，没有什么异常,DNS的响应速度也很快。dcompass的问题是返回的ttl永远都不变，而不是随上游的DNS服务器进行更新的。 |
Beta Was this translation helpful? Give feedback.
-
首次请求->检查缓存当然没有->请求上游->得到结果返回并写入缓存（假设ttl=5分钟）
5分钟后再次请求->检查缓存有一个过期的记录但是别删->直接返回（注意，返回的时候把ttl改得很小，比如就30秒吧）->同时去请求上游得到新的结果更新进缓存
这样除了首次之外，后续都直接从缓存返回非常快，即便偶尔拿到过期的记录但由于ttl被改得很小，可以让客户端尽快再次请求拿到最新结果，最大限度的发挥缓存的作用
目前来讲memory cache，默认size是1024条，我很怀疑真的有人能让缓存同时超过1024条吗，不到这个数目LRU根本没活干，它就是个摆设，如果按照这思路实现，定时清除器可以去掉了，LRU很快就有活干了
但是redis cache好像就难搞了🤣
@IrineSistiana 怎么看😎
Beta Was this translation helpful? Give feedback.
All reactions