没有不值得去解决的问题,也没有不值得去学习的技术!

Investigating Changing API Response Data Within 5 Minutes: A Varnish Deployment Issue

Clicking through confirmed that 3 containers are indeed Running.

1. Reference URL: https://www.shuijingwanwq.com/2021/11/10/5453/ . After disabling a single data item in the list from the backend, it should have remained hidden. However, within a few minutes, it kept appearing and disappearing. Only after waiting about 5 minutes did it finally disappear permanently.

2. Searching for Varnish in Rancher on k8s revealed 3 running containers. See Figure 1.

Searching for Varnish in Rancher on k8s revealed 3 running containers.
Figure 1

3. Clicking through confirmed that 3 containers are indeed Running. See Figure 2.

Clicking through confirmed that 3 containers are indeed Running.
Figure 2

4. Checking the environment variables shows APP_CHECKINTERVAL=10s. See Figure 3.

Checking the environment variables shows APP_CHECKINTERVAL=10s.
Figure 3

5. Varnish is a high-performance, open-source HTTP accelerator that effectively reduces web server load and improves access speed. According to official documentation, Varnish is a caching HTTP reverse proxy. Deploying Varnish changes how web requests are processed. Client requests are first received by Varnish, which analyzes them and forwards them to the backend web server. The backend web server processes the requests normally and returns the results to Varnish. Varnish’s core function is to cache the results returned by the backend web server; if identical requests follow, Varnish serves the cached results instead of forwarding them to the web server. This effectively reduces web server load, improves response speed, and handles more requests per second. Another primary reason for Varnish’s speed is that its cache resides entirely in memory, which is much faster than disk storage. The cache processing sequence is: receive request – analyze request (analyze URL, analyze headers) — hash calculation — cache lookup — freshness check — access origin — cache – build response – respond and log.

6. When using Varnish, if requests for a single URL are distributed to different Varnish servers via HA/F5 (load balancing), each targeted Varnish server forwards the request to the backend. Identical requests are then cached across multiple servers, causing resource waste and performance degradation in Varnish. Furthermore, because the cache differs across Varnish servers, the list API’s response data constantly changes—each request hits a different Varnish server. Therefore, if you need to cache list APIs at this stage, configure them for single-node deployment. If data that should disappear from the list still exists, clicking into the detail page will show: “Activity does not exist.” For cluster deployments, it is recommended to support only detail APIs and similar endpoints.

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者,自 2013 年起持续运营个人技术博客,记录工作与个人项目中遇到的真实问题,以及解决问题过程中的探索、实践和思考。

除了技术写作,我也在持续开发和维护自己的独立项目,探索新技术和新工具在实际场景中的应用。我始终相信,没有不值得去解决的问题,也没有不值得去学习的技术。

如果这篇文章对你有所帮助,欢迎浏览博客中的其他文章,也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系