10 ਜੂਨ 2025·8 ਮਿੰਟ
ਕੈਸ਼ ਲੇਅਰ ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ—ਪਰ ਉਹ ਛੁਪੇ ਹੋਏ ਜਟਿਲਤਾ ਲਿਆਉਂਦੇ ਹਨ
ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਲੇਟੈਂਸੀ ਅਤੇ origin ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਨਵੇਂ ਫੇਲ ਮੋਡ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਲਿਆਉਂਦੇ ਹਨ। ਆਮ ਲੇਅਰਾਂ, ਖ਼ਤਰਨਾਂ ਅਤੇ ਜਟਿਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮੈਨੇਜ ਕਰਨਾ ਹੈ, ਇਹ ਜਾਣੋ।
ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਲੇਟੈਂਸੀ ਅਤੇ origin ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਨਵੇਂ ਫੇਲ ਮੋਡ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ ਲਿਆਉਂਦੇ ਹਨ। ਆਮ ਲੇਅਰਾਂ, ਖ਼ਤਰਨਾਂ ਅਤੇ ਜਟਿਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮੈਨੇਜ ਕਰਨਾ ਹੈ, ਇਹ ਜਾਣੋ।
ਕੈਸ਼ਿੰਗ ਡਾਟਾ ਦੀ ਇੱਕ ਨਕਲ ਉਸ ਥਾਂ ਨੇੜੇ ਰੱਖਦੀ ਹੈ ਜਿੱਥੇ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜੋ ਬਿਨੈ ਸ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾ ਕੀਤੀ ਜਾ ਸਕੇ ਅਤੇ ਕੋਰ ਸਿਸਟਮਾਂ ਤੱਕ ਘੱਟ ਯਾਤਰਾ ਹੋਵੇ। ਨਤੀਜਾ ਆਮ ਤੌਰ 'ਤੇ ਮਿਲiaq ਹੁੰਦਾ ਹੈ: ਸਪੀਡ (ਘੱਟ ਲੇਟੈਂਸੀ), ਲਾਗਤ (ਘੱਟ ਮਹਿੰਗੀਆਂ ਡੇਟਾਬੇਸ ਪੜਤਾਲਾਂ ਜਾਂ ਉਪਸਟਰੀਮ ਕਾਲਾਂ) ਅਤੇ ਢਿੱਲਪਨ (ਓਰਿਜਿਨ ਸਰਵਿਸਜ਼ ਟਰੈਫਿਕ ਸਪਾਈਕਸ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੀਆਂ ਹਨ)।
ਜਦੋਂ ਕੈਸ਼ ਦੇ ਕੋਲ ਅੰਸਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ “ਓਰਿਜਿਨ” (ਐਪ ਸਰਵਰ, ਡੇਟਾਬੇਸ, ਤੀਸਰਾ ਪੱਖ) ਘੱਟ ਕਰਦਾ ਹੈ। ਇਹ ਕਮੀ ਨਾਂ ਦੇ ਨਾਂ ਹੀ ਡ੍ਰਾਮੈਟਿਕ ਹੋ ਸਕਦੀ ਹੈ: ਘੱਟ ਕ੍ਵੈਰੀਜ਼, ਘੱਟ CPU ਸਾਈਕਲ, ਘੱਟ ਨੈਟਵਰਕ ਹੌਪ ਅਤੇ ਘੱਟ ਟਾਈਮਆਊਟ ਮੌਕੇ।
ਕੈਸ਼ਿੰਗ ਧੜੱਕਿਆਂ ਨੂੰ ਵੀ ਸਮਤਲ ਕਰਦੀ ਹੈ—ਇਹ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਜਿਹੜੇ ਸਿਸਟਮ ਮਸ਼ੀਨ ਗੜ੍ਹਨ ਵਾਲੇ ਲੋਡ ਲਈ ਸਾਈਜ਼ ਕੀਤੇ ਗਏ ਹਨ ਉਹ ਚੋਟੀ ਵਾਲੇ ਮੋਮੈਂਟ ਨੂੰ ਬਿਨਾਂ ਤੁਰੰਤ ਸਕੇਲਿੰਗ (ਜਾਂ ਫੇਲ) ਕਰ ਸਕਣ।
ਕੈਸ਼ਿੰਗ ਕੰਮ ਨੂੰ ਹਟਾਉਂਦੀ ਨਹੀਂ; ਇਹ ਕੰਮ ਨੂੰ ਡਿਜ਼ਾਈਨ ਅਤੇ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਨਵੇਂ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਵਾਰਸਦਾਰ ਬਣਾਉਂਦੇ ਹੋ:
ਹਰ ਕੈਸ਼ ਲੇਅਰ ਨਵੀਂ ਕੰਫਿਗਰੇਸ਼ਨ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਐਜ ਕੇਸ ਲਿਆਉਂਦਾ ਹੈ। ਇੱਕ ਕੈਸ਼ ਜੋ 99% ਬਿਨਤੀਆਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਫਿਰ ਵੀ 1% ਘਟਨਾਵਾਂ ਵਿੱਚ ਦਰਦਨਾਕ ਘਟਨਾਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ: ਸਮਕਾਲੀ ਐਕਸਪਾਇਰੀਜ਼, ਅਸੰਗਤ ਯੂਜ਼ਰ ਅਨੁਭਵ, ਜਾਂ ਓਰਿਜਿਨ ਵੱਲ ਅਚਾਨਕ ਬਹਿਭਾਰ।
ਇੱਕ ਇੱਕੱਲਾ ਕੈਸ਼ ਇੱਕ ਸਟੋਰ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਐਪ ਦੇ ਨਾਲ ਇੱਕ in-memory cache)। ਇੱਕ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਮੰਗ ਪਾਥ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਚੈਕਪਾਇੰਟ ਹੈ—CDN, ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼, ਐਪ ਕੈਸ਼, ਡੇਟਾਬੇਸ ਕੈਸ਼—ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਨਿਯਮ ਅਤੇ ਫੇਲਿਓਰ ਮੋਡ ਹੁੰਦੇ ਹਨ।
ਇਹ ਪੋਸਟ ਬਹੁ-ਲੇਅਰਾਂ ਨਾਲ ਆਉਂਦੀ ਪ੍ਰਯੋਗਿਕ ਜਟਿਲਤਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀ ਹੈ: ਸਹੀਪਨ, ਅਣਵੈਲੀਡੇਸ਼ਨ, ਅਤੇ ਓਪਰੇਸ਼ਨ (ਨੀਚਲੇ ਸਤਰ ਦੇ ਕੈਸ਼ ਅਲਗੋਰਿਦਮ ਜਾਂ ਵੈਂਡਰ-ਨਿਰਧਾਰਿਤ ਟਿਊਨਿੰਗ ਨਹੀਂ)।
ਕੈਸ਼ਿੰਗ ਨੂੰ ਤਰਕਸ਼ੀਲ ਬਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਬਿਨੈ ਨੂੰ ਕਈ “ਸ਼ਾਇਦ ਮੇਰੇ ਕੋਲ ਹੈ” ਚੈਕਪਾਇੰਟਸ ਦੀ ਸਟੈਕ ਰੂਪ ਵਿੱਚ ਸੋਚਦੇ ਹੋ।
ਇੱਕ ਆਮ ਪਾਥ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
ਹਰ ਹੋਪ 'ਤੇ, ਸਿਸਟਮ ਜਾਂ ਤਾਂ ਇੱਕ ਕੈਸ਼ ਕੀਤੀ ਹੋਈ ਰਿਸਪਾਂਸ (hit) ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਅਗਲੇ ਲੇਅਰ ਨੂੰ ਅਗੇ ਭੇਜ ਸਕਦਾ ਹੈ (miss)। ਜਿੰਨੀ ਪਹਿਲਾਂ ਹਿੱਟ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਏਜ 'ਤੇ), ਉਤਨਾ ਹੀ ਡੀਪ ਵਿੱਚ ਲੋਡ ਘਟਦਾ ਹੈ।
ਹਿੱਟ ਡੈਸ਼ਬੋਰਡਾਂ ਨੂੰ ਚੰਗਾ ਦਿਖਾਉਂਦੇ ਹਨ। ਮਿਸ ਉਹ ਹਨ ਜਿੱਥੇ ਜਟਿਲਤਾ ਆਉਂਦੀ ਹੈ: ਉਹ ਅਸਲ ਕੰਮ ਚਲਾਉਂਦੀਆਂ ਹਨ (ਐਪ ਲੋਜਿਕ, ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀਜ਼) ਅਤੇ ਓਵਰਹੈੱਡ ਜੋੜਦੀਆਂ ਹਨ (ਕੈਸ਼ ਲੁੱਕਅੱਪ, ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ, ਕੈਸ਼ ਲਿਖਾਈ). ਇੱਕ ਮਦਦਗਾਰ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ: ਹਰ ਮਿਸ ਕੈਸ਼ ਲਈ ਦੋ ਵਾਰੀ ਭੁਗਤਾਨ ਕਰਦੀ ਹੈ—ਤੁਸੀਂ ਅਜੇ ਵੀ ਅਸਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਨਾਲ ਹੀ ਉਸਦੇ ਆਲੇ ਦੁਆਲੇ ਕੈਸ਼ਿੰਗ ਕੰਮ ਵੀ ਹੁੰਦੇ ਹਨ।
ਕੈਸ਼ ਲੇਅਰ ਜੋੜਨਾ ਰੇਅਰਲੀ ਬੋਤਲਨੈਕਸ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ; ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਮੂਵ ਕਰਦਾ ਹੈ:
ਮੰਨੋ ਤੁਹਾਡੀ ਉਤਪਾਦ ਪੇਜ CDN 'ਤੇ 5 ਮਿੰਟ ਲਈ ਕੈਸ਼ ਹੈ, ਅਤੇ ਐਪ ਵੀ ਉਤਪਾਦ ਵੇਰਵੇ Redis ਵਿੱਚ 30 ਮਿੰਟ ਲਈ ਕੈਸ਼ ਕਰਦਾ ਹੈ.
ਜੇ ਕੀਮਤ ਬਦਲਦੀ ਹੈ, CDN ਜਲਦੀ ਰੀਫ੍ਰੈਸ਼ ਹੋ ਸਕਦਾ ਹੈ ਪਰ Redis ਪੁਰਾਣਾ ਮੁੱਲ ਸਰਵ ਕਰਦੀ ਰਹਿ ਸਕਦੀ ਹੈ। ਹੁਣ “ਸਚਾਈ” ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਲੇਅਰ ਬਿਨੈ ਦਾ ਜਵਾਬ ਦਿੱਤੀ—ਇਹ ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ ਹੈ ਕਿ ਕਿਉਂ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਲੋਡ ਘਟਾਉਂਦੀਆਂ ਹਨ ਪਰ ਸਿਸਟਮ ਜਟਿਲਤਾ ਵਧਾਉਂਦੀਆਂ ਹਨ।
ਕੈਸ਼ਿੰਗ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ—ਇਹ ਉਹਨਾਂ ਥਾਵਾਂ ਦੀ ਇੱਕ ਸਟੈਕ ਹੈ ਜਿੱਥੇ ਡਾਟਾ ਸੰਭਾਲਿਆ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਰ ਲੇਅਰ ਲੋਡ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਹਰ ਇੱਕ ਦੀਆਂ ਤਾਜ਼ਗੀ, ਅਣਵੈਲੀਡੇਸ਼ਨ ਅਤੇ ਵਿਜ਼ੀਬਿਲਟੀ ਲਈ ਵੱਖ-ਵੱਖ ਨਿਯਮ ਹੁੰਦੇ ਹਨ।
ਬ੍ਰਾਊਜ਼ਰ ਚਿੱਤਰ, ਸਕ੍ਰਿਪਟ, CSS ਅਤੇ ਕਈ ਵਾਰੀ API ਰਿਸਪਾਂਸ ਨੂੰ HTTP ਹੈਡਰ (ਜਿਵੇਂ Cache-Control ਅਤੇ ETag) ਦੇ ਆਧਾਰ 'ਤੇ ਕੈਸ਼ ਕਰਦੇ ਹਨ। ਇਹ ਮੁੜ ਡਾਊਨਲੋਡਜ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ—ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ CDN/origin ਟ੍ਰੈਫਿਕ ਘਟਾਉਣ ਲਈ ਸ਼ਾਨਦਾਰ।
ਚੈਲੈਂਜ: ਜਦੋਂ ਇੱਕ ਰਿਸਪਾਂਸ ਕਲਾਇਂਟ-ਸਾਈਡ 'ਤੇ ਕੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੀਵੈਲੀਡੇਸ਼ਨ ਟਾਈਮਿੰਗ 'ਤੇ ਨਿਯੰਤਰਣ ਨਹੀਂ ਰੱਖਦੇ। ਕੁਝ ਯੂਜ਼ਰ ਲੰਬੇ ਸਮੇਂ ਪੁਰਾਣੇ ਐਸੈਟ ਰੱਖ ਸਕਦੇ ਹਨ (ਜਾਂ ਅਚਾਨਕ ਕੈਸ਼ ਸਾਫ ਕਰ ਦੇ ਸਕਦੇ ਹਨ), ਇਸ ਲਈ ਵਰਜ਼ਨ ਕੀਤੀ URL (ਜਿਵੇਂ app.3f2c.js) ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਜਾਲ ਹਨ।
CDN ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਸਮੱਗਰੀ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਸਟੈਟਿਕ ਫਾਈਲਾਂ, ਪਬਲਿਕ ਪੇਜ਼ਾਂ ਅਤੇ “ਜ਼ਿਆਦਾਤਰ ਸਥਿਰ” ਰਿਸਪਾਂਸ ਲਈ ਚਮਕਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ ਉਤਪਾਦ ਤਸਵੀਰਾਂ, ਡਾਕਯੂਮੈਂਟੇਸ਼ਨ ਜਾਂ rate-limited API endpoints.
CDN ਅਧਾਰਤ HTML ਨੂੰ ਵੀ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਤੁਸੀਂ cookie, ਹੈਡਰ, ਜਿਓ, ਡਿਵਾਈਸ ਨਾਲ ਵੱਧ-ਘਟ ਵੈਰੀਏਸ਼ਨ ਦਾ ਧਿਆਨ ਰੱਖੋ। ਗਲਤ variation ਨਿਯਮ ਅਕਸਰ ਗਲਤ ਉਪਭੋਗਤਾ ਨੂੰ ਗਲਤ ਸਮੱਗਰੀ ਸੇਵਾ ਕਰਨ ਦਾ ਕਾਰਣ ਬਣਦੇ ਹਨ।
ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (ਜਿਵੇਂ NGINX ਜਾਂ Varnish) ਤੁਹਾਡੇ ਐਪ ਦੇ ਸਾਹਮਣੇ ਬੈਠਦੇ ਹਨ ਅਤੇ ਪੂਰੀ ਰਿਸਪਾਂਸ ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਉਹ ਸਮੇਂ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੇਂਦਰਿਤ ਨਿਯੰਤਰਣ, ਭਵਿੱਖ-ਪੂਰਕ eviction ਅਤੇ origin ਸਰਵਰਾਂ ਲਈ ਤੇਜ਼ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹੋ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ CDN ਜਿੰਨੀ ਵਿਸ਼ਵ ਵਿਅਪੀ ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਤੁਹਾਡੇ ਐਪ ਦੇ ਰੁਟ ਅਤੇ ਹੈਡਰ ਲਈ ਟੇਲਰ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਇਹ ਕੈਸ਼ ਓਬਜੈਕਟ, ਗਣਨਾ ਨਤੀਜੇ, ਅਤੇ ਮਹਿੰਗੀਆਂ ਕਾਲਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ (ਜਿਵੇਂ “user profile by id” ਜਾਂ “pricing rules for region”). ਇਹ ਲਚੀਲਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਿਜ਼ਨੈਸ ਲੌਜਿਕ ਨੂੰ ਵਾਕਫ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਵੀ ਹੋਰ ਫੈਸਲੇ ਲਿਆਉਂਦਾ ਹੈ: ਕੀ-ਡਿਜ਼ਾਇਨ, TTL ਚੋਣ, ਅਣਵੈਲੀਡੇਸ਼ਨ ਲੌਜਿਕ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਲੋੜਾਂ ਜਿਵੇਂ ਸਾਈਜ਼ਿੰਗ ਅਤੇ failover।
ਜਿਆਦਾਤਰ ਡੇਟਾਬੇਸ ਪੇਜ਼, ਇੰਡੈਕਸ ਅਤੇ ਕ੍ਵੈਰੀ ਪਲਾਨ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕਰਦੇ ਹਨ; ਕੁਝ ਨਤੀਜਾ ਕੈਸ਼ਿੰਗ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਦੁਬਾਰਾ ਕ੍ਰਮਵਾਰ ਕ੍ਵੈਰੀਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਐਪ ਕੋਡ ਬਦਲੇ।
ਇਹ ਨੂੰ ਇੱਕ ਬੋਨਸ ਵਜੋਂ ਦੇਖੋ, ਨਾ ਕਿ ਗਾਰੰਟੀ ਵਜੋਂ: ਡੇਟਾਬੇਸ ਕੈਸ਼ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਕ੍ਵੈਰੀ ਪੈਟਰਨ ਹੇਠ ਅਨਿਯੰਤ੍ਰਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਲਿਖਾਈਆਂ, ਲਾਕਾਂ ਜਾਂ ਕੰਟੈਂਸ਼ਨ ਦੀ ਕੀਮਤ ਨਹੀਂ ਹਟਾਉਂਦੇ ਜਿਵੇਂ ਉਪਸਟਰੀਮ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ।
ਕੈਸ਼ਿੰਗ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਦੁਹਰਾਏ ਗਏ, ਮਹਿੰਗੇ ਬੈਕਐਂਡ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਸਸਤਾ ਲੁੱਕਅੱਪ ਵਿੱਚ ਬਦਲ ਦੇਵੇ। ਚਾਲ ਹੁੰਦੀ ਹੈ ਕਿ ਕੈਸ਼ ਨੂੰ ਐਸੇ ਵਰਕਲੋਡ ਨਾਲ ਮਿਲਾਇਆ ਜਾਵੇ ਜਿੱਥੇ ਬਿਨਤੀਆਂ ਕਾਫ਼ੀ ਮਿਲਦੀਆਂ ਹਨ—ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਮੁੜ ਵਰਤੋਂ ਉੱਚ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਪੜ੍ਹਾਈਆਂ ਤੋਂ ਬਹੁਤ ਜਿਆਦਾ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੈਸ਼ ਡੇਟਾਬੇਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਦਾ ਇਕ ਵੱਡਾ ਹਿੱਸਾ ਹਟਾ ਸਕਦਾ ਹੈ। ਉਤਪਾਦ ਪੇਜ਼, ਪਬਲਿਕ ਪ੍ਰੋਫਾਈਲ, ਸਹਾਇਤਾ ਕੇਂਦਰ ਦੇ ਲੇਖ ਅਤੇ ਖੋਜ/ਛਾਣ ਨਤੀਜੇ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ।
ਕੈਸ਼ਿੰਗ "ਮਹਿੰਗੇ" ਕੰਮਾਂ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ ਡੇਟਾਬੇਸ-ਬਾਊਂਡ ਨਹੀਂ: PDF ਬਣਾਉਣਾ, ਚਿੱਤਰਾਂ ਦਾ ਰੀਸਾਈਜ਼ ਕਰਨਾ, ਟੈਂਪਲੇਟ ਰੈਂਡਰ ਕਰਨਾ, ਜਾਂ ਐਗਰੀਗੇਟ ਗਣਨਾ। ਇੱਥੇ ਵੀ ਇੱਕ ਛੋਟਾ ਸਮੇਂ-ਸੀਮਾ ਵਾਲਾ ਕੈਸ਼ (ਸੈਕਿੰਡ ਤੋਂ ਮਿੰਟ) ਬੀੜ-ਸਮੇਂ ਵਿੱਚ ਦੁਹਰਾਏ ਗਣਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਟਰੈਫਿਕ ਅਸਮਾਨ ਹੁੰਦਾ ਹੈ, ਕੈਸ਼ਿੰਗ ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਕੋਈ ਮਾਰਕੀਟਿੰਗ ਈਮੇਲ, ਨਿਊਜ਼ ਜ਼ਿਕਰ ਜਾਂ ਸੋਸ਼ਲ ਪੋਸਟ ਇੱਕ ਚੰਦ URLਾਂ ਉੱਤੇ ਯੂਜ਼ਰ ਭੇਜਦੀ ਹੈ, ਤਾੰ CDN ਜਾਂ ਏਜ ਕੈਸ਼ ਜਿਆਦਾਤਰ ਉਸ surge ਨੂੰ ਅਬਸੋਰਬ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸ ਨਾਲ ਸਿਰਫ ਤੇਜ਼ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ: ਇਹ autoscaling ਝਟਕੇ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਖਤਮ ਹੋਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ rate limits/ਬੈਕਪ੍ਰੈਸ਼ਰ ਲਈ ਸਮਾਂ ਖਰੀਦਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਦੂਰ ਹੈ—ਚਾਹੇ ਅਸਲ ਵਿੱਚ (跨-ਰੀਜਨ) ਜਾਂ ਤਰਤੀਬ ਵਿੱਚ (धीਮ dependency)—ਤਾਂ ਕੈਸ਼ਿੰਗ ਦੋਹਾਂ ਲੋਡ ਅਤੇ ਮਹਿਸੂਸੀ ਧੀਰਜ ਘਟਾ ਸਕਦੀ ਹੈ। CDN ਤੋਂ ਨੇੜੇ ਸਰਵ ਕੀਤੀ ਸਮੱਗਰੀ ਉਪਭੋਗਤਾ ਲਈ ਲੰਬੇ-ਸਫ਼ਰ ਵਾਲੀ origin ਯਾਤਰਾ ਨੂੰ ਦੋਹਰਾਉਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਅੰਦਰੂਨੀ ਕੈਸ਼ ਵੀ ਮਦਦਗਾਰ ਹੈ ਜਦੋਂ ਬੋਤਲਨੈਕ ਇੱਕ ਉੱਚ-ਲੇਟੈਂਸੀ ਸਟੋਰ (ਦੂਰ ਦਾ ਡੇਟਾਬੇਸ, ਤੀਸਰਾ ਪੱਖੀ API, ਜਾਂ ਸਾਂਝੀ ਸਰਵਿਸ) ਹੈ। ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਣ ਨਾਲ concurrency ਦਬਾਅ ਅਤੇ tail latency ਵਿੱਚ ਸੁਧਾਰ ਆਉਂਦਾ ਹੈ।
ਜਦੋਂ ਰਿਸਪਾਂਸ ਬਹੁਤ ਪ੍ਰਸਨਲਾਈਜ਼ਡ ਹੁੰਦਾ ਹੈ (ਪ੍ਰਤੀ-ਯੂਜ਼ਰ ਡਾਟਾ, ਸੈਂਸੇਟਿਵ ਖਾਤਾ ਜਾਣਕਾਰੀਆਂ) ਜਾਂ ਜਦੋਂ ਮੂਲ ਡਾਟਾ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ (ਲਾਈਵ ਡੈਸ਼ਬੋਰਡ, ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਇਨਵੈਂਟਰੀ), ਤਾਂ ਕੈਸ਼ਿੰਗ ਘੱਟ ਲਾਭ ਦਿੰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਕੇਸਾਂ ਵਿੱਚ ਹਿੱਟ ਰੇਟ ਘੱਟ ਹੁੰਦੀ ਹੈ, ਅਣਵੈਲੀਡੇਸ਼ਨ ਲਾਗਤ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬਚਾਏ ਹੋਏ ਬੈਕਐਂਡ ਕੰਮ ਘੱਟ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਇੱਕੋ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਵਿਂਡੋ ਵਿੱਚ ਟੁੱਟ ਕੇ ਪੁੱਛਦੇ ਹਨ ਅਤੇ ਉਹ ਚੀਜ਼ ਇੱਕੋ-ਜਿਹੀ ਰਹਿੰਦੀ ਹੈ, ਤਦ ਕੈਸ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ overlap ਮੌਜੂਦ ਨਹੀਂ, ਤਾਂ ਹੋਰ ਇੱਕ ਲੇਅਰ complexity ਵਧਾ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਲੋਡ ਕੱਟੇ।
ਜਦੋਂ ਡਾਟਾ ਨਹੀਂ ਬਦਲਦਾ, ਕੈਸ਼ਿੰਗ ਆਸਾਨ ਹੈ। ਜਿਵੇਂ ਹੀ ਇਹ ਬਦਲਦਾ ਹੈ, ਤੁਸੀਂ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਭਾਗ ਦੇ ਹਕਦਾਰ ਬਣ ਜਾਂਦੇ ਹੋ: ਨਿਰਧਾਰਤ ਕਰਨਾ ਕਿ ਕਦੋਂ cached data ਭਰੋਸੇਯੋਗ ਰਹਿਣਾ ਛੱਡ ਦਿੰਦੈ, ਅਤੇ ਹਰ ਕੈਸ਼ ਲੇਅਰ ਨੂੰ ਇਹ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇ ਕਿ ਡਾਟਾ ਬਦਲਿਆ ਹੈ।
Time-to-live (TTL) ਮਨਮੋਹਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕ ਨੰਬਰ ਹੈ ਅਤੇ ਕੋਈ ਕੋਆਰਡੀਨੇਸ਼ਨ ਨਹੀਂ ਚਾਹੀਦੀ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ “ਸਹੀ” TTL ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਉਤਪਾਦ ਮੁੱਲ 'ਤੇ 5 ਮਿੰਟ TTL ਰੱਖਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਯੂਜ਼ਰ ਮੁੱਲ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਮੁੱਲ ਵੇਖ ਸਕਦੇ ਹਨ—ਸੰਭਵ ਹੈ ਕਿ ਇਹ ਕਾਨੂੰਨੀ ਜਾਂ ਸਪੋਰਟ ਸਮੱਸਿਆ ਬਣ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ TTL 5 ਸੈਕਿੰਡ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਘੱਟ ਲੋਡ ਦੀ ਬਚਤ ਮਿਲੇਗੀ। ਇਨ வாடੀ, ਇੱਕ ਹੀ ਰਿਸਪਾਂਸ ਦੇ ਵੱਖ-ਵੱਖ ਖੇਤਰ ਵੱਖ-ਵੱਖ ਦਰ ਨਾਲ ਬਦਲਦੇ ਹਨ (ਸਟਾਕ vs ਵੇਰਵਾ), ਇਸ ਲਈ ਇੱਕ TTL ਸੰਕਤ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਇਵੈਂਟ-ਚਲਿਤ ਅਣਵੈਲੀਡੇਸ਼ਨ ਕਹਿੰਦਾ ਹੈ: ਜਿਸ ਵੇਲੇ ਸਚਾਈ ਬਦਲਦੀ ਹੈ, ਪ੍ਰਭਾਵਤ ਕੀਜ਼ ਨੂੰ ਪੁਰਜ/ਅਪਡੇਟ ਕਰਨ ਲਈ ਇਕ ਇਵੈਂਟ ਜਾਰੀ ਕਰੋ। ਇਹ ਬਹੁਤ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਨਵੇਂ ਕੰਮ ਲਿਆਉਂਦਾ ਹੈ:
ਇਹ ਨਕਸ਼ਾ ਹੀ ਉਸ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ “ਦੋ ਮੁਸ਼ਕਲ ਚੀਜ਼ਾਂ: ਨਾਂਕਰਨ ਅਤੇ ਅਣਵੈਲੀਡੇਸ਼ਨ” ਬਹੁਤ ਹੀ ਪ੍ਰਾਇਮਕ ਸੁਲਝਣ-ਗਆਂਠੀ ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ /users/123 ਕੈਸ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਨਾਲ ਹੀ “ਟੌਪ ਕਾਂਟ੍ਰਿਬਿਊਟਰ” ਲਿਸਟ ਨੂੰ ਵੀ, ਤਾਂ ਉਪਯੋਕਤਾ ਨਾਮ ਬਦਲਣ ਨਾਲ ਇੱਕ ਤੋਂ ਵੱਧ ਕੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਰਿਸ਼ਤੇ ਟਰੈਕ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਸੀਂ ਮਿਲੀ-ਜੁਲੀ ਹਕੀਕਤ ਸੇਵਾ ਕਰੋਗੇ।
Cache-aside (ਐਪ DB ਨੂੰ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ, ਕੈਸ਼ ਨੂੰ ਭਰਦਾ) ਆਮ ਹੈ, ਪਰ ਅਣਵੈਲੀਡੇਸ਼ਨ ਤੁਹਾਡੇ ਉੱਤੇ ਹੈ।
Write-through (ਕੈਸ਼ ਅਤੇ DB ਨੂੰ ਇਕੱਠੇ ਲਿਖੋ) stale ਦਾ ਜੋਖਮ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਲੇਟੈਂਸੀ ਅਤੇ ਫੇਲਿਊਰ-ਹੈਂਡਲਿੰਗ ਜਟਿਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।
Write-back (ਪਹਿਲਾਂ ਕੈਸ਼ ਨੂੰ ਲਿਖੋ, ਬਾਅਦ ਵਿੱਚ ਫਲਸ਼ ਕਰੋ) ਗਤੀ ਵਧਾਉਂਦਾ ਹੈ, ਪਰ ਸਹੀਪਨ ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਬਹੁਤ ਜ਼ਰੂਰੀ ਅਤੇ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।
Stale-while-revalidate ਹਲਕਾ ਪੁਰਾਣਾ ਡਾਟਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪਿੱਛੋਂ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਰੀਫ੍ਰੈਸ਼ ਹੁੰਦਾ ਹੈ। ਇਹ ਛਪਟੀਆਂ ਸਮੇਤ origins ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਉਤਪਾਦ ਨਿਰਣਯ ਹੈ: ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ “ਤੇਜ਼ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਤਾਜ਼ਾ” ਨੂੰ “ਹਮੇਸ਼ਾ ਨਵੀਨਤਮ” ਨਾਲ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ।
ਕੈਸ਼ਿੰਗ ਇਹ ਬਦਲ ਦਿੰਦੀ ਹੈ ਕਿ “ਸਹੀ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਕੈਸ਼ ਨਾ ਹੋਣ 'ਤੇ, ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਨਵੀਂ ਕਮਿਟ ਕੀਤੀ ਡਾਟਾ ਵੇਖਦੇ ਹਨ (ਸਧਾਰਣ ਡੇਟਾਬੇਸ ਵਿਹੰਗੀ ਦੇ ਅਧੀਨ). ਕੈਸ਼ਾਂ ਨਾਲ, ਯੂਜ਼ਰ ਕੁਝ ਦੇਰ ਨਾਲ ਡਾਟਾ ਵੇਖ ਸਕਦੇ ਹਨ—ਜਾਂ ਸਕ੍ਰੀਨਾ-ਵਾਰ ਅਸੰਗਤਤਾ ਵੀ ਹੋ ਸਕਦੀ ਹੈ—ਕਈ ਵਾਰੀ ਬਿਨਾਂ ਕਿਸੇ ਸਪਸ਼ਟ ਗਲਤੀ ਦੇ।
Strong consistency ਦਾ ਲਕ਼ਸ਼ "read-after-write" ਹੁੰਦਾ ਹੈ: ਜੇ ਕੋਈ ਯੂਜ਼ਰ ਆਪਣਾ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ ਪੇਜ ਲੋਡ ਨਵੇਂ ਐਡਰੈੱਸ ਨੂੰ ਹਰ ਥਾਂ ਦਿਖਾਵੇ। ਇਹ ਸਹਿਜ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਹਰ ਲਿਖਾਈ ਨੂੰ ਫੌਰਨ ਕਈ ਕੈਸ਼ਾਂ ਨੂੰ ਪੁਰਜ/ਰੀਫ੍ਰੈਸ਼ ਕਰਨਾ ਪਵੇ।
Eventual consistency ਸੰਖੇਪ ਸਥਾਲੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ: ਅਪਡੇਟ ਜਲਦੀ ਹੀ ਨਜ਼ਰ ਆ ਜਾਵੇਗੀ, ਪਰ ਤੁਰੰਤ ਨਹੀਂ। ਯੂਜ਼ਰ ਇਸਨੂੰ ਘੱਟ ਮਹਤਵ ਵਾਲੀ ਸਮੱਗਰੀ ਲਈ ਸਹਿਣ ਕਰ ਲੈਂਦੇ ਹਨ (ਜਿਵੇਂ view counts), ਪਰ ਪੈਸਾ, ਪਰਮਿਸ਼ਨ ਜਾਂ ਕੁਝ ਐਸੇ ਕੰਮਾਂ ਲਈ ਜੋ ਤੁਰੰਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ, ਇਹ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।
ਆਮ ਪਿੱਛਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਲਿਖਾਈ ਉਸ ਸਮੇਂ ਹੋ ਰਹੀ ਹੈ ਜਦੋਂ ਕੈਸ਼ ਦੁਬਾਰਾ ਭਰਿਆ ਜਾ ਰਿਹਾ ਹੈ:
ਕਈ ਕੈਸ਼ ਲੇਅਰਾਂ ਨਾਲ, ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ disagre ਕਰ ਸਕਦੇ ਹਨ:
ਯੂਜ਼ਰ ਇਸਨੂੰ “ਸਿਸਟਮ ਟੁੱਟਿਆ” ਸਮਝਦੇ ਹਨ, ਨਾ ਕਿ “ਸਿਸਟਮ eventual consistent ਹੈ।”
ਵਰਜ਼ਨਿੰਗ ਭ੍ਰਮ ਘਟਾਉਂਦੀ ਹੈ:
user:123:v7) ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਵਧਣ ਦਿੰਦੇ ਹਨ: ਇੱਕ ਲਿਖਾਈ ਵਰਜ਼ਨ ਨੂੰ ਬੰਪ ਕਰਦੀ ਹੈ ਅਤੇ ਰੀਡਸ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਨਵੇਂ ਕੀ ਤੇ ਚਲੇ ਜਾਂਦੇ ਹਨ ਬਿਨਾਂperfectDeletes ਦੇ।ਚਾਬੀ ਫੈਸਲਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ “ਪੁਰਾਣਾ ਡਾਟਾ ਚੰਗਾ ਹੈ ਜਾਂ ਨਹੀਂ?” ਸਗੋਂ ਕਿੱਥੇ ਇਹ ਮਾੱਤੀ ਰੱਖਦਾ ਹੈ।
ਹਰ ਫੀਚਰ ਲਈ ਸਪਸ਼ਟ staleness budgets ਨਿਰਧਾਰਤ ਕਰੋ (ਸੈਕਿੰਡ/ਮਿੰਟ/ਘੰਟੇ) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਯੂਜ਼ਰ ਉਮੀਦਾਂ ਨਾਲ ਮਿਲਾਉ। ਖੋਜ ਨਤੀਜੇ ਇੱਕ ਮਿੰਟ ਦੇ ਲਈ ਲੇਟ ਹੋ ਸਕਦੇ ਹਨ; ਖਾਤਾ ਬੈਲੰਸ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਤੁਰੰਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਸ ਨਾਲ "ਕੈਸ਼ ਸਹੀਪਨ" ਇੱਕ ਉਤਪਾਦੀ ਮਿਆਦ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਟੈਸਟ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਕਰ ਸਕਦੇ ਹੋ।
ਕੈਸ਼ਿੰਗ ਅਕਸਰ ਐਸੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜੋ ਲੱਗਦਾ ਹੈ ਕਿ “ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਫਿਰ ਅਚਾਨਕ ਸਭ ਕੁਝ ਟੁੱਟ ਗਿਆ।” ਇਹ ਫੇਲਿਓਰ ਦੱਸਦੇ ਹਨ ਕਿ ਕੈਸ਼ ਟਰੈਫਿਕ ਪੈਟਰਨਾਂ ਨੂੰ ਸੰਕੇਂਦ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਛੋਟੀ-ਕਿਸਮ ਦੀ ਬਦਲਾਵ ਵੀ ਵੱਡੇ ਪ੍ਰਭਾਵ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
ਡਿਪਲੋਏ, autoscale ਇਵੈਂਟ, ਜਾਂ ਕੈਸ਼ ਫਲਸ਼ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਇੱਕ ਖ਼ਾਲੀ ਕੈਸ਼ ਪਾਓਗੇ। ਅਗਲਾ ਟਰੈਫਿਕ ਬਰ੍ਸਟ ਬਹੁਤ ਸਾਰੀਆਂ ਬਿਨਤੀਆਂ ਨੂੰ ਡੇਟਾਬੇਸ ਜਾਂ ਉਪਸਟਰੀਮ API ਵੱਲ ਮਾਰਦਾ ਹੈ।
ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਦਰਦਨਾਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟਰੈਫਿਕ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੋਲ ਲੋਕਪ੍ਰਿਯ ਆਈਟਮਾਂ ਨੂੰ ਗਰਮ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ।Deploys peak usage ਨਾਲ ਮਿਲਣ 'ਤੇ ਤੁਸੀਂ ਅਚਾਨਕ ਆਪਣਾ ਖੁਦ ਦਾ ਲੋਡ ਟੈਸਟ ਬਣ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸਟੈਂਪਿਡ ਤਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਇੱਕੋ ਹੀ ਆਈਟਮ ਮੰਗਦੇ ਹਨ ਜਿਵੇਂ ਹੀ ਉਹ expire ਹੁੰਦਾ ਹੈ (ਜਾਂ ਜਦੋਂ ਕੈਸ਼ ਘੱਟ ਹੈ). ਇਸ ਦੀ ਥਾਂ, ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਲੋਕ ਉਸੇ ਨਵੀਨ ਕਰਨ ਕੰਮ ਨੂੰ ਕਰ ਦਿੰਦੇ ਹਨ—ਓਰਿਜਿਨ ਨੂੰ ਓਵਰਹੈਮ ਕਰ ਦਿੰਦੇ ਹਨ।
ਆਮ ਰੋਕਥਾਮਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਜੇ ਸਹੀਪਨ ਦੀ ਲੋੜ ਸਹਾਇਕ ਹੋਵੇ, ਤਾਂ stale-while-revalidate ਵੀ peaks ਨੂੰ ਮਸਲ ਸਕਦਾ ਹੈ।
ਕੁਝ ਕੀਜ਼ ਅਸਾਧਾਰਣ ਰੂਪ ਵਿੱਚ ਲੋਕਪ੍ਰਿਭ ਬਣ ਜਾਂਦੀਆਂ ਹਨ (ਹੋਮਪੇਜ ਪੇਲੋਡ, trending product, ਗਲੋਬਲ configuration). ਹਾਟ-ਕੀਜ਼ ਅਸਮਾਨ ਲੋਡ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ ਕੈਸ਼ ਨੋਡ ਜਾਂ ਇੱਕ ਬੈਕਐਂਡ ਰਸਤਾ ਘੱਟ-ਰਿਹਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦਕਿ ਹੋਰ ਖਾਲੀ ਰਹਿੰਦੇ ਹਨ।
ਰੋਕਥਾਮ ਵਿੱਚ ਵੱਡੇ "ਗਲੋਬਲ" ਕੀਜ਼ ਨੂੰ ਛੋਟੇ ਖੰਡਾਂ ਵਿੱਚ ਵੰਡਣਾ, ਸ਼ਾਰਡਿੰਗ/ਪਾਰਟੀਸ਼ਨਿੰਗ, ਜਾਂ ਵੱਖ-ਵੱਖ ਲੇਅਰ 'ਤੇ ਕੈਸ਼ਿੰਗ (ਜਿਵੇਂ CDN ਰਾਹੀਂ) ਸ਼ਾਮਲ ਹੈ।
ਕੈਸ਼ ਆਊਟੇਜ ਅਕਸਰ ਨੋ-ਕੈਸ਼ ਨਾਲੋਂ ਬੁਰੀ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਪਹਿਲਾਂ ਤੋਂ ਫੈਸਲਾ ਕਰੋ:
ਜੋ ਵੀ ਚੋਣ ਕਰੋ, rate limits ਅਤੇ circuit breakers ਲਗਾਓ ਤਾਂ ਕਿ ਕੈਸ਼ ਫੇਲਿਓਰ origin ਆਊਟੇਜ ਵਿੱਚ ਨਾ ਬਦਲੇ।
ਕੈਸ਼ਿੰਗ ਤੁਹਾਡੇ origin ਸਿਸਟਮਾਂ 'ਤੇ ਲੋਡ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਦਿਨ-ਭਰ ਦੇ ਕੰਮਾਂ ਵਿੱਚ ਤਿਆਰ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਦਿੰਦੀ ਹੈ। ਭਾਵੇਂ "ਮੇਨੇਜਡ" caches ਵੀ ਇਹੋ ਜਿਹਾ ਜ਼ਰੂਰੀ ਯੋਜਨਾ, ਟਿਊਨਿੰਗ ਅਤੇ ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਮੰਗਦੇ ਹਨ।
ਨਵਾਂ ਕੈਸ਼ ਲੇਅਰ ਅਕਸਰ ਇੱਕ ਨਵੀਂ ਕਲੱਸਟਰ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਨਵਾਂ ਟੀਅਰ) ਹੁੰਦਾ ਹੈ ਜਿਸ ਦੀ ਆਪਣੀ କੈਜਿਟੀ ਸੀਮਾਵਾਂ ਹੁੰਦੀ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਮੇਮੋਰੀ ਸਾਈਜ਼ਿੰਗ, eviction ਨੀਤੀ, ਅਤੇ ਦਬਾਅ ਹੇਠ ਕੀ ਹੁੰਦਾ ਹੈ, ਦਾ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਕੈਸ਼ ਅਣਸਹੀਤ ਹੈ, ਤਾਂ ਇਹ churn ਕਰਦਾ ਹੈ: ਹਿੱਟ ਰੇਟ ਘਟਦਾ ਹੈ, ਲੇਟੈਂਸੀ ਵਧਦੀ ਹੈ, ਅਤੇ origin ਫਿਰ ਵੀ ਓਵਰਹੈਮ ਹੁੰਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਕਈ ਥਾਵਾਂ ਵਿੱਚ ਵਸਦੀ ਹੈ। ਤੁਸੀਂ CDN ਕੈਸ਼, ਐਪ ਕੈਸ਼, ਅਤੇ ਡੇਟਾਬੇਸ ਕੈਸ਼—ਸਭ ਨੂੰ ਵੱਖ-ਵੱਖ ਨਿਯਮਾਂ ਨਾਲ ਦੇਖ ਸਕਦੇ ਹੋ।
ਛੋਟੀਆਂ ਅਣਮੈਲਾਂ ਜੋੜੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:
ਸਮੇਂ-ਸਮੇਂ 'ਤੇ "ਇਹ ਰਿਕਵੇਸਟ ਕੈਸ਼ ਕਿਉਂ ਹੈ?" ਇੱਕ ਪੁਰਾਤਤਵੀ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੈਸ਼ ਤੁਹਾਨੂੰ ਨਵੇਂ ਦੁਹਰਾਏ ਕੰਮ ਦਿੰਦਾ ਹੈ: deploys ਤੋਂ ਬਾਅਦ ਮਹੱਤਵਪੂਰਨ ਕੀਜ਼ ਨੂੰ warm ਕਰਨਾ, ਡੇਟਾ ਬਦਲਣ 'ਤੇ purge/ਰੀਵੈਲੀਡੇਸ਼ਨ, ਨੋਡਜ਼ ਜੋੜਣ/ਹਟਾਉਣ 'ਤੇ resharding, ਅਤੇ ਪੂਰੇ ਫਲਸ਼ ਹੋਣ ਦੀ rehearsal।
ਜਦੋਂ ਯੂਜ਼ਰ stale ਡਾਟਾ ਜਾਂ ਅਚਾਨਕ ਸਲੋਨੈੱਸ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ, ਤਾਂ responders ਕੋਲ ਹੁਣ ਕਈ ਸੰਦੇਹ ਹਨ: CDN, ਕੈਸ਼ ਕਲੱਸਟਰ, ਐਪ ਦਾ ਕੈਸ਼ ਕਲਾਇੰਟ, ਅਤੇ ਓਰਿਜਿਨ। ਡੀਬਔਗ ਕਰਨ ਲਈ ਅਕਸਰ ਲੇਅਰਾਂ ਵਿੱਚ ਹਿੱਟ ਰੇਟ, eviction spikes, ਅਤੇ ਟਾਈਮਆਊਟ ਚੈੱਕ ਕਰਨੇ ਪੈਂਦੇ ਹਨ—ਫਿਰ ਤੈਅ ਕਰਨਾ ਕਿ bypass, purge, ਜਾਂ scale ਕਰਨਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਤਦ ਹੀ ਜਿੱਤ ਹੈ ਜਦੋਂ ਇਹ origin ਕੰਮ ਨੂੰ ਘਟਾਵੇ ਅਤੇ ਯੂਜ਼ਰ-ਮਹਿਸੂਸ ਕੀਤੀ ਤੇਜ਼ੀ ਸੁਧਾਰੇ। ਕਿਉਂਕਿ ਬਿਨਤੀਆਂ ਕਈ ਲੇਅਰਾਂ (edge/CDN, ਐਪ ਕੈਸ਼, ਡੇਟਾਬੇਸ ਕੈਸ਼) ਵਲੋਂ ਸਰਵ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਤੁਹਾਨੂੰ ਨਿਰੀਖਣਯੋਗਤਾ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਇਹ ਦੱਸੇ:
ਊਹੇ ਹਿੱਟ ਰੇਸ਼ੋ ਚੰਗੀ ਗੱਲ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਸਮੱਸਿਆਵਾਂ (ਜਿਵੇਂ ਸਲੋ ਕੈਸ਼ ਪੜ੍ਹਾਈ ਜਾਂ ਲਗਾਤਾਰ churn) ਛੁਪਾ ਸਕਦਾ ਹੈ। ਹਰ ਲੇਅਰ ਲਈ ਥੋੜ੍ਹੇ ਪਰ ਮਹੱਤਵਪੂਰਨ ਮੈਟ੍ਰਿਕਸ ਟਰੈਕ ਕਰੋ:
ਜੇ ਹਿੱਟ ਰੇਸ਼ੋ ਵਧਦਾ ਹੈ ਪਰ ਕੁੱਲ ਲੇਟੈਂਸੀ ਨਹੀਂ ਸੁਧਰਦੀ, ਤਾਂ ਕੈਸ਼ ਸ਼ਾਇਦ ধੀਮਾ ਹੈ, ਬਹੁਤ serialization ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਵੱਡੇ payload ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ।
ਡਿਸਟ੍ਰਿਬਿਊਟਡ ਟਰੇਸਿੰਗ ਦਿਖਾਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਇੱਕ ਬਿਨੈ edge 'ਤੇ, ਐਪ ਕੈਸ਼ ਦੁਆਰਾ, ਜਾਂ ਡੇਟਾਬੇਸ ਦੁਆਰਾ ਸਰਵ हुई। cache.layer=cdn|app|db ਅਤੇ cache.result=hit|miss|stale ਵਰਗੇ ਲਗਾਤਾਰ ਟੈਗਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟਰੇਸਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਸਕੋ ਅਤੇ ਹਿੱਟ-ਪਾਥ vs ਮਿਸ-ਪਾਥ ਟਾਈਮਿੰਗ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ।
ਕੈਸ਼ ਕੀਜ਼ ਨੂੰ ਲੌਗ ਕਰਦਿਆਂ ਸਾਵਧਾਨ ਰਹੋ: ਕੱਚੇ ਯੂਜ਼ਰ ਆਈਡੀ, ਈਮੇਲ, ਟੋਕਨ ਜਾਂ ਪੂਰੀ URL query ਸਟ੍ਰਿੰਗ ਤੋਂ ਬੱਚੋ। ਨਾਰਮਲਾਈਜ਼ਡ ਜਾਂ ਹੈਸ਼ ਕੀਤੇ ਕੀਜ਼ ਪਸੰਦ ਕਰੋ ਅਤੇ ਸਿਰਫ ਇਕ ਛੋਟਾ ਪ੍ਰੀਫਿਕਸ ਲੌਗ ਕਰੋ।
ਅਲਰਟ ਕਰੋ ਅਸਧਾਰਨ ਮਿਸ-ਰੇਟ ਸਪਾਈਕਸ, ਮਿਸ-ਉੱਤੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਅਚਾਨਕ ਛੱਲਾਂ, ਅਤੇ ਸਟੈਂਪਿਡੇ ਸਿਗਨਲਾਂ (ਉਹਨਾਂ ਹੀ ਕੀ ਪੈਟਰਨ ਲਈ ਬਹੁਤ concurrent misses). ਡੈਸ਼ਬੋਰਡਾਂ ਨੂੰ edge, app, ਅਤੇ database ਵਿਊਜ਼ ਵਿੱਚ ਵੰਡੋ, ਅਤੇ ਇੱਕ end-to-end ਪੈਨਲ ਜੋ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੁਹਰਾਉਂਦਾ ਹੈ—ਪਰ ਇਹ ਗਲਤ ਜਵਾਬ ਨੂੰ ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਵੀ ਦੁਹਰਾਉਂ ਸਕਦਾ ਹੈ। ਕੈਸ਼ ਸੰਬੰਧੀ ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਅਕਸਰ ਚੁੱਪਚਾਪ ਹੁੰਦੀਆਂ ਹਨ: ਸਭ ਕੁਝ ਤੇਜ਼ ਅਤੇ ਸਿਹਤਮੰਦ ਦਿੱਸ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਜਦਕਿ ਡਾਟਾ ਲੀਕ ਹੋ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਪ੍ਰਸਨਲਾਈਜ਼ਡ ਜਾਂ ਗੋਪਨੀਯ ਲਾਗੂ ਸਮੱਗਰੀ (ਖਾਤਾ ਵੇਰਵੇ, ਚਲਾਨ, ਸਹਾਇਤਾ ਟਿਕਟ, ਐਡਮਿਨ ਪੇਜ਼) ਕੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ—CDN, ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ, ਜਾਂ ਐਪ ਕੈਸ਼ ਵਿੱਚ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ "ਸਭ ਕੁਝ ਕੈਸ਼ ਕਰੋ" ਨਿਯਮ ਗਲਤ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਹੋਰ ਸੁਬਟਲ ਲੀਕ: ਐਸਾ ਰਿਸਪਾਂਸ ਜੋ session state (ਉਦਾਹਰਨ ਲਈ Set-Cookie ਹੈਡਰ) ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ cached ਰਿਸਪਾਂਸ ਨੂੰ ਦੂਜੇ ਯੂਜ਼ਰ ਨੂੰ ਸਰਵ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਰੋਟੀਨ ਬੱਗ ਹੈ: ਯੂਜ਼ਰ A ਲਈ ਰਿਟਰਨ ਕੀਤਾ HTML/JSON ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਗਲਤੀ ਨਾਲ ਯੂਜ਼ਰ B ਨੂੰ ਸਰਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀ ਵਿੱਚ ਯੂਜ਼ਰ ਸੰਦਰਭ ਨਹੀਂ ਹੈ। ਮਲਟੀ-ਟੇਨੈਂਟ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਟੇਨੈਂਟ ਪਛਾਣ ਵੀ ਕੀ ਦਾ ਹਿੱਸਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਨਿਯਮ ਵਜੋਂ: ਜੇ ਰਿਸਪਾਂਸ ਪ੍ਰਮਾਣੀਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਕੀ (ਜਾਂ ਬਾਈਪਾਸ ਲੌਜਿਕ) ਨੂੰ ਉਹ dependency ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ—roles, geography, pricing tier, feature flags ਵੀ ਸ਼ਾਮਿਲ।
HTTP ਕੈਸ਼ਿੰਗ ਦਾ ਵਿਵਹਾਰ ਬਹੁਤ ਹੱਦ ਤੱਕ ਹੈਡਰਾਂ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ:
Cache-Control: private / no-store ਨਾਲ ਅਕਸਮਾਤ ਸਟੋਰੇਜ ਰੋਕੋVary: ਯਕੀਨੀ ਬਣਾਓ ਕਿ caches ਅਨੁਰੋਧ ਹੈਡਰਾਂ ਦੁਆਰਾ ਵੱਖ-ਵੱਖ ਰਿਸਪਾਂਸ ਰੱਖਣ (ਜਿਵੇਂ Authorization, Accept-Language)Set-Cookie: ਅਕਸਰ ਇਹ ਸੂਚਿਤ ਕਰਦਾ ਹੈ ਕਿ ਰਿਸਪਾਂਸ ਨੂੰ ਪਬਲਿਕਲੀ ਕੈਸ਼ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾਜੇ ਕੰਪਲਾਇਐਂਸ ਜਾਂ ਜੋਖਮ ਉੱਚੇ ਹਨ—PII, ਸਿਹਤ/ਵਿੱਤੀ ਡੇਟਾ, ਕਾਨੂੰਨੀ ਦਸਤਾਵੇਜ਼—ਤਾਂ Cache-Control: no-store ਵਰਤੋ ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਲੱਭੋ। ਮਿਕਸ ਪੇਜਾਂ ਲਈ ਕੇਵਲ ਗੈਰ-ਸੰਵੇਦਨਸ਼ੀਲ ਫ੍ਰੈਗਮੈਂਟਾਂ ਨੂੰ ਕੈਸ਼ ਕਰੋ ਅਤੇ ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਸ਼ੇਅਰਡ ਕੈਸ਼ ਤੋਂ ਰੱਖੋ।
ਕੈਸ਼ਿੰਗ ਲੇਅਰਾਂ origin ਲੋਡ ਘਟਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਅਕਸਰ "ਮੁਫ਼ਤ ਪ੍ਰਦਰਸ਼ਨ" ਨਹੀਂ ਹੁੰਦਾ। ਹਰ ਨਵੇਂ ਕੈਸ਼ ਨੂੰ ਇੱਕ ਨਿਵੇਸ਼ ਵਜੋਂ ਦੇਖੋ: ਤੁਸੀਂ ਘੱਟ ਲੇਟੈਂਸੀ ਅਤੇ ਘੱਟ ਬੈਕਐਂਡ ਕੰਮ ਖਰੀਦ ਰਹੇ ਹੋ—ਬਦਲੇ ਵਿੱਚ ਪੈਸਾ, ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ, ਅਤੇ ਵੱਡੇ ਸਹੀਪਨ ਸਤਹ।
ਵਾਧੂ ਇੰਫਰਾਸਟਰਕਚਰ ਲਾਗਤ vs ਘਟਾਇਆ ਗਿਆ origin ਖਰਚ। CDN egress ਅਤੇ ਡੇਟਾ ਰੀਡ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ CDN ਬਿਨਤੀਆਂ, ਕੈਸ਼ ਸਟੋਰੇਜ, ਅਤੇ ਕਈ ਵਾਰ invalidation calls ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ। Redis/Memcached ਕਲੱਸਟਰ ਇੱਕ ਐਪਲਿਕੇਸ਼ਨ ਕੈਸ਼ ਲਈ ਖਰਚ ਵਧਾਉਂਦਾ ਹੈ। ਬਚਤਾਂ ਡੇਟਾਬੇਸ ਰਾੲੀਪਲਿਕਸ ਘਟਾ ਕੇ, ਛੋਟੇ instance types, ਜਾਂ ਸਕੇਲਿੰਗ ਦੇ ਰੁਕਾਵਟ ਦੇ ਰੂਪ ਵਿੱਚ ਆ ਸਕਦੀਆਂ ਹਨ।
ਲੇਟੈਂਸੀ ਫਾਇਦੇ vs ਤਾਜ਼ਗੀ ਦੀ ਲਾਗਤ। ਹਰ ਕੈਸ਼ ਇੱਕ "ਕਿੰਨੀ ਪੁਰਾਣੀ ਮਨਜ਼ੂਰ ਹੈ?" ਫੈਸਲਾ ਲਿਆਉਂਦਾ ਹੈ। ਕਠੋਰ ਤਾਜ਼ਗੀ ਵਧੇਰੇ invalidation ਪਲੰਬਿੰਗ (ਅਤੇ ਵੱਧ misses) ਮੰਗਦੀ ਹੈ। ਸਹਿਣ ਕੀਤੀ ਹੋਈ ਸਟੇਲਨੈਸ ਕਮਪਿਊਟਬਚਤ ਕਰਦੀ ਹੈ ਪਰ ਯੂਜ਼ਰ ਭਰੋਸੇ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਕੀਮਤਾਂ, ਉਪਲੱਬਧਤਾ ਜਾਂ ਪਹੁੰਚ ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ।
ਇੰਜੀਨੀਅਰਿੰਗ ਢੰਗ: ਫੀਚਰ ਗਤੀ vs ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ। ਨਵਾਂ ਲੇਅਰ ਆਮ ਤੌਰ 'ਤੇ ਵਾਧੂ ਕੋਡ ਰਾਹ, ਵਧੇਰੇ ਟੈਸਟਿੰਗ, ਅਤੇ ਵੱਧ ਇੰਸੀਡੈਂਟ ਕਿਸਮਾਂ (ਸਟੈਂਪਿਡੇ, ਹਾਟ ਕੀਜ਼, ਅੰਸ਼ਿਕ ਅਣਵੈਲੀਡੇਸ਼ਨ) ਲਈ ਲਿਆਉਂਦਾ ਹੈ। ਮੁਅੱਤਤਾ ਰੱਖੋ ਕਿ ਇਹ ਇੱਕ ਵਾਰੀ ਲਾਗਤ ਨਹੀਂ, ਪਰ ਓਵਰਹੈੱਡ ਜੋ ਜਾਰੀ ਰਹੇਗਾ।
ਫੈਲਾਓ ਤੋਂ ਪਹਿਲਾਂ ਸੀਮਿਤ ਟ੍ਰਾਇਲ ਚਲਾਓ:
ਨਵੀਂ ਕੈਸ਼ ਲੇਅਰ ਜੋੜੋ ਸਿਰਫ ਜੇ:
ਕੈਸ਼ਿੰਗ ਸਭ ਤੋਂ ਜਲਦੀ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਫੀਚਰ ਵਾਂਗ ਸਮਝਦੇ ਹੋ: ਇਸ ਨੂੰ ਇੱਕ ਮਾਲਕੀ, ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਬੰਦ ਕਰਨ ਦਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਸਮੇਂ 'ਤੇ ਇੱਕ ਕੈਸ਼ ਲੇਅਰ ਜੋੜੋ (ਉਦਾਹਰਨ: ਪਹਿਲਾਂ CDN ਜਾਂ ਐਪ ਕੈਸ਼), ਅਤੇ ਇੱਕ ਸਿੱਧਾ ਜਿੰਮੇਵਾਰ ਟੀਮ/ਵਿਆਕਤੀ ਨਿਯੁਕਤ ਕਰੋ।
ਮਾਲਕੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜ਼ਿਆਦਾਤਰ ਕੈਸ਼ ਬੱਗ ਅਸਲ ਵਿੱਚ “ਕੀ ਬੱਗ” ਹੁੰਦੀਆਂ ਹਨ। ਇਕ ਦਸਤਾਵੇਜ਼ੀ ਕਨਵੈਨਸ਼ਨ ਵਰਤੋਂ ਜੋ ਉਹ ਇਨਪੁਟ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ ਜੋ ਰਿਸਪਾਂਸ ਨੂੰ ਬਦਲਦੇ ਹਨ: tenant/user scope, locale, device class, ਅਤੇ ਸੰਬੰਧਿਤ feature flags.
ਵਰਜ਼ਨ ਕੀਜ਼ ਸ਼ਾਮਿਲ ਕਰੋ (ਜਿਵੇਂ product:v3:...) ਤਾਂ ਜੋ ਤੁਸੀਂ ਲੱਖਾਂ ਐਂਟਰੀਆਂ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਬਜਾਏ ਵਰਜ਼ਨ ਬੰਪ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਅਣਵੈਲੀਡ ਕਰ ਸਕੋ।
ਹਰ ਚੀਜ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਾਜ਼ਾ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਹਰ ਲਿਖਾਈ ਪਾਥ 'ਤੇ ਜਟਿਲਤਾ ਧਕੇਲਦੀ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ, ਫੀਚਰ-ਵਾਇਜ਼ "ਕਾਫ਼ੀ ਸਟੇਲ" ਦਾ ਨਿਰਧਾਰ ਕਰੋ (ਸੈਕਿੰਡ, ਮਿੰਟ, ਜਾਂ "ਅਗਲੇ ਰੀਫ੍ਰੈਸ਼ ਤੱਕ") ਅਤੇ ਇਸਨੂੰ encode ਕਰੋ:
ਕਮਿਊਨ ਧਾਰੋ ਕਿ ਕੈਸ਼ ਧੀਮਾ, ਗਲਤ ਜਾਂ ਡਾਊਨ ਹੋ ਸਕਦਾ ਹੈ।
ਟਾਈਮਆਊਟ ਅਤੇ circuit breakers ਵਰਤੋਂ ਤਾਂ ਜੋ ਕੈਸ਼ ਕਾਲਾਂ ਤੁਹਾਡੇ ਰਿਕਵੇਸਟ ਪਾਥ ਨੂੰ ਨਹੀਂ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ। ਗ੍ਰੇਸਫੁਲ ਡਿਗਰੇਡੇਸ਼ਨ ਨੂੰ explicit ਬਣਾਓ: ਜੇ ਕੈਸ਼ ਫੇਲ ਹੋਵੇ ਤਾਂ origin ਨੂੰ ਬਾਈਪਾਸ ਕਰੋ ਪਰ rate-limit ਕਰੋ, ਜਾਂ ਇੱਕ ਘੱਟ-ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਦਿਓ।
ਕੈਨਰੀ ਜਾਂ ਪ੍ਰਤੀਸ਼ਤ ਰੋਲਆਊਟ ਦੇ ਨਾਲ caching ship ਕਰੋ, ਅਤੇ ਇੱਕ bypass switch (ਪਰ ਰੂਟ ਜਾਂ ਹੈਡਰ ਦਰਜਾ) ਰੱਖੋ ਫਾਸਟ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਲਈ।
ਰਨਬੁਕਸ ਦਸਤਾਵੇਜ਼ ਕਰੋ: purge ਕਿਵੇਂ ਕਰਨਾ ਹੈ, ਕੀ ਵਰਜ਼ਨ ਬੰਪ ਕਰਨਾ ਹੈ, ਕੈਸ਼ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਨਾਕਾਰ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ metrics ਕਿੱਥੇ ਦੇਖਣੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਰਨਬੁਕ ਪੇਜ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ on-call ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਵਾਈ ਕਰ ਸਕੇ।
ਕੈਸ਼ਿੰਗ ਕੰਮ ਅਕਸਰ ਰੁਕਦਾ ਹੈ ਕਿਉਂਕਿ ਬਦਲਾਅ ਕਈ ਲੇਅਰਾਂ ਨੂੰ ਛੂੰਹਦੇ ਹਨ (ਹੈਡਰ, ਐਪ ਲੌਜਿਕ, ਡੇਟਾ ਮਾਡਲ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾਵਾਂ)। iteration ਦੀ ਲਾਗਤ ਘਟਾਉਣ ਲਈ, ਪੂਰੀ ਰਿਕਵੇਸਟ ਪਾਥ ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਵਾਤਾਵਰਨ ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ।
Koder.ai ਨਾਲ, ਟੀਮਾਂ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਦੁਆਰਾ ਇੱਕ ਰਿਆਲਿਸਟਿਕ ਐਪ ਸਟੈਕ (React, Go, PostgreSQL, ਆਦਿ) ਤੇਜ਼ੀ ਨਾਲ ਸਪਿਨ ਅਪ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ TTL, ਕੀ ਡਿਜ਼ਾਇਨ, stale-while-revalidate ਨੂੰ end-to-end ਟੈਸਟ ਕਰ ਸਕਦੀਆਂ ਹਨ। Planning mode ਵਰਗੀਆਂ ਖ਼ੂਬੀਆਂ ਨਿਰਧਾਰਤ caching ਵਿਹਾਰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ snapshots/rollback caching ਕਨਫਿਗਰੇਸ਼ਨ ਜਾਂ ਅਣਵੈਲੀਡ ਲੌਜਿਕ 'ਤੇ ਪ੍ਰਯੋਗ ਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੌਰਸ ਕੋਡ export ਜਾਂ deploy/host ਕਰ ਸਕਦੇ ਹੋ—ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੈਫਿਕ ਦਾ ਨਕਲ ਕਰਨ ਵਾਲੇ ਪਰਫਾਰਮੈਂਸ ਟੈਸਟਾਂ ਲਈ ਕਾਰਗਰ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅਜਿਹਾ ਪਲੇਟਫਾਰਮ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ production-grade observability ਦੇ ਪੂਰਕ ਵਜੋਂ ਲਓ: ਲਕ਼ਸ਼ ਤੇਜ਼ iteration ਹੈ ਪਰ ਸਹੀਪਨ ਦੀਆਂ ਲੋੜਾਂ ਅਤੇ ਰੋਲਬੈਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਪਸ਼ਟ ਬਣੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਕੈਸ਼ਿੰਗ ਦੁਹਰਾਏ ਗਏ ਬਿਨਤੀਆਂ ਨੂੰ ਬਿਨਾ origin (app ਸਰਵਰ, ਡੇਟਾਬੇਸ, ਤੀਸਰੇ ਪੱਖੀ API) ਨੂੰ ਹਿੱਟ ਕੀਤੇ ਜਵਾਬ ਦੇ ਕੇ ਲੋਡ ਘਟਾਉਂਦੀ ਹੈ। ਸਭ ਤੋਂ ਵੱਡੇ ਫਾਇਦੇ ਆਮ ਤੌਰ 'ਤੇ ਹਨ:
ਜਿਨ੍ਹਾਂ ਲੇਅਰਾਂ 'ਤੇ ਪਹਿਲਾਂ ਹਿੱਟ ਹੁੰਦੀ ਹੈ (ਬ੍ਰਾਊਜ਼ਰ/CDN vs ਐਪ), ਉਹਨਾ ਪਿੱਛੇ ਦੇ ਆਰਥਿਕ ਕੰਮ ਤੋਂ ਜ਼ਿਆਦਾ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।
ਇਕਲੌਤਾ ਕੈਸ਼ ਇੱਕ ਸਟੋਰ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ ਐਪ ਦੇ ਨਾਲ in-memory cache). ਇੱਕ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਮੰਗ ਪਾਥ ਵਿੱਚ ਇੱਕ ਚੈਕਪਾਇੰਟ ਹੁੰਦਾ ਹੈ (ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼, CDN, ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ, ਐਪ ਕੈਸ਼, ਡੇਟਾਬੇਸ ਕੈਸ਼).
ਕਈ ਲੇਅਰ ਲੋਡ ਨੂੰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਹੋਰ ਨਿਯਮ, ਫੇਲਿਓਰ ਮੋਡ ਅਤੇ ਅਸਮਨਵਝਤਾ ਦੇ ਤਰੀਕੇ ਵੀ ਲਿਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਲੇਅਰ ਇਕੱਠੇ ਹੋ ਕੇ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਸੇਵਾ ਕਰਦੇ ਹਨ।
ਮਿਸ ਹੋਣ 'ਤੇ ਅਸਲ ਕੰਮ ਹੋਂਦਾ ਹੈ ਅਤੇ ਉਸ ਨਾਲ ਕੈਸ਼ ਸੰਬੰਧੀ ਓਵਰਹੈੱਡ ਵੀ ਹੁੰਦਾ ਹੈ। ਮਿਸ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ:
ਇਸ ਲਈ ਮਿਸ "ਕੋਈ ਕੈਸ਼ ਨਹੀਂ" ਤੋਂ ਵੀ ਦੇਰ ਹੁੰਦੀ ਹੈ ਜੇ ਤੱਕ ਕੈਸ਼ ਅੱਛੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਨਾ ਹੋਵੇ ਅਤੇ ਹਿੱਟ ਰੇਟ ਉੱਚਾ ਨਾ ਹੋਵੇ।
TTL ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ; ਪਰ ‘ਸਹੀ’ TTL ਉਸ ਡੇਟਾ ਦੇ ਵਰਤੋਂ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਡਕਟ ਪ੍ਰਾਈਸ ਉੱਤੇ 5 ਮਿੰਟ TTL ਰੱਖਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਯੂਜ਼ਰ ਮੁੱਲ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਪ੍ਰਾਈਸ ਵੇਖ ਸਕਦੇ ਹਨ—ਜੋ ਕਾਨੂੰਨੀ ਜਾਂ ਸਹਾਇਤਾ ਸਮੱਸਿਆ ਖੜੀ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ TTL 5 ਸੈਕਿੰਡ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਘੱਟ ਲੋਡ ਬਚੇਗਾ। ਇਕੋ ਰਿਸਪਾਂਸ ਦੇ ਵੱਖ-ਵੱਖ ਖੇਤਰ ਵੱਖ-ਵੱਖ ਦਰਾਂ ਨਾਲ ਬਦਲਦੇ ਹਨ (ਜਿਵੇਂ ਇਨਵੈਂਟਰੀ vs ਵੇਰਵਾ), ਇਸ ਲਈ ਇਕ TTL ਸਾਰੇ ਲਈ ਸਮਝੌਤਾ ਕਰਦਾ ਹੈ।
ਇਵੈਂਟ-ਚਲਿਤ ਅਣਵੈਲੀਡੇਸ਼ਨ ਕਹਿੰਦਾ ਹੈ: ਜਦੋਂ ਸਚਾਈ ਬਦਲਦੀ ਹੈ, ਇੱਕ ਇਵੈਂਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਪ੍ਰਭਾਵਤ ਕੈਸ਼ ਕੀਜ਼ ਨੂੰ ਪੁਰਜ / ਅਪਡੇਟ ਕਰੋ। ਇਹ ਬਹੁਤ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਨਵੇਂ ਕੰਮ ਲਿਆਉਂਦਾ ਹੈ:
ਜੇ ਇਹ mapping ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਿਲੀ ਜੁਲੀ ਸਥਿਤੀਆਂ ਸੇਵਾ ਕਰ ਰਹੇ ਹੋਵੋਗੇ।
ਇਕ ਸਧਾਰਣ ਨਿਯਮ ਇਹ ਹੈ ਕਿ TTL ਪ੍ਰਤੀ ਫੀਚਰ ਵਿਸ਼ੇਸ਼ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਹਿੱਸਿਆਂ ਲਈ ਵੈਧਤਾ ਬਜਟ ਠਹਿਰਾਓ (ਮਿੰਟ/ਸੈਕਿੰਡ/ਘੰਟੇ)।
ਜਿਨ੍ਹਾਂ ক্ষেতਰਾਂ ਵਿੱਚ ਤੁਰੰਤ ਤਾਜ਼ਗੀ ਜ਼ਰੂਰੀ ਹੈ (ਜਿਵੇਂ ਖਾਤਾ ਬੈਲੰਸ, ਪ੍ਰਾਈਸਿੰਗ), ਉੱਥੇ TTL ਛੋਟਾ ਰੱਖੋ ਜਾਂ ਇਵੈਂਟ-ਚਲਿਤ ਅਣਵੈਲੀਡੇਸ਼ਨ ਵਰਤੋਂ—ਪਰ ਸਪਸ਼ਟ ਰਣਨੀਤੀ ਅਤੇ ਨਿਗਰਾਨੀ ਲਾਜ਼ਮੀ ਹੈ।
ਸੰਭਵ ਹੈ ਕਿ ਅਨੇਕ ਲੇਅਰ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਦਿਖਾਉਣ। ਉਦਾਹਰਨ: CDN ਪੁਰਾਣਾ HTML ਦੇਂਦਾ ਹੈ ਜਦਕਿ ਐਪ ਕੈਸ਼ ਨਵਾਂ JSON ਦੇ ਰਹੀ ਹੈ, ਜਿਸ ਨਾਲ UI ਮਿਲੀ-ਝੁਲੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਸ ਨੂੰ ਘਟਾਉਣ ਲਈ:
product:v3:...) ਤਾਂ ਜੋ ਪੜਚੋਲ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧੇVary/ਹੈਡਰ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਮੇਲ ਕਰੋ ਜੋ ਰਿਸਪਾਂਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈਇੱਕ ਸਟੈਂਪਿਡ (ਥੰਡਰਿੰਗ ਹਿਰਡ) ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਰਿਕਵੇਸਟ ਇੱਕੋ ਸਮੇਂ ਇਕੋ ਕੀ ਨੂੰ ਰੀਬਿਲਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ (ਆਮ ਤੌਰ 'ਤੇ ਐਕਸਪਾਇਰੀ ਦੇ ਤੁਰੰਤ ਬਾਅਦ). ਇਹ ਓਰਿਜਿਨ ਨੂੰ ਓਵਰਹੇਮ ਕਰ ਸਕਦਾ ਹੈ।
ਆਮ ਰੋਕਥਾਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਕੈਸ਼ ਖਰਾਬ ਹੋਣ 'ਤੇ ਫੈਲਬੈਕ ਦਾ ਫੈਸਲਾ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕਰੋ:
ਸਾਥ ਹੀ timeout, circuit breakers, ਤੇ rate limits ਲਾਓ ਤਾਂ ਜੋ ਕੈਸ਼ ਆਊਟੇਜ origin ਆਊਟੇਜ ਨਾ ਬਣੇ।
ਮਾਪ ਅਤੇ ਟ੍ਰੇਸਿੰਗ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਉਹ ਸਪਸ਼ਟ ਦੱਸ ਸਕਣ ਕਿ ਕੈਸ਼ ਅਸਲ ਵਿੱਚ ਮਦਦ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ:
ਟ੍ਰੇਸਿੰਗ ਵਿੱਚ cache.layer ਅਤੇ cache.result ਜਿਹੇ ਟੈਗ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਿੱਟ ਪਾਥ vs ਮਿਸ ਪਾਥ ਵੇਖ ਸਕੋ।
ਸਭ ਤੋਂ ਆਮ ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਨਿੱਜੀ ਜਾਂ ਪ੍ਰਸਨਲਾਈਜ਼ਡ ਰਿਸਪਾਂਸਾਂ ਨੂੰ ਸ਼ੇਅਰਡ ਲੇਅਰਾਂ (CDN/ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ) ਵਿੱਚ ਕੈਸ਼ ਕਰ ਦੇਣਾ ਕਿਉਂਕਿ ਕੀ ਵਿੱਚ ਯੂਜ਼ਰ-ਸੰਦਰਭ ਸ਼ਾਮਿਲ ਨਹੀਂ।
ਸੁਰੱਖਿਆ ਉਪਾਇ:
Cache-Control: no-store ਜਾਂ private ਵਰਤੋVary ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਸੈੱਟ ਕਰੋ (ਜਿਵੇਂ Authorization, Accept-Language)Set-Cookie ਵਾਲੇ ਰਿਸਪਾਂਸ ਨੂੰ ਆਮ ਰੂਪ ਵਿੱਚ ਪਬਲਿਕ ਕੈਸ਼ ਵਿੱਚ ਨਾ ਰੱਖੋ