Redis වැනි cache එකක් යොදා ගත් පසු ප්රතිචාර වේගය අඩු වීම ඔබට අත්දැකීම් ඇති කර තිබේ. නමුත් cache හි දත්ත හිස් වීමත් සමඟ එකවර ලක්ෂ ගණනක් පරිශීලකයින් එකම දත්ත ලබාගැනීමට උත්සාහ කරන විට ‘Thundering Herd’ නමැති ගැටළුව මතුවේ.
සාමාන්යයෙන් අපි ලියන කේතය මෙසේය: let data = await cache.get(key); if (!data) { data = await db.query(query); await cache.set(key, data); } cache හි දත්ත නැතිවීමේ අවස්ථාවක, 100,000 පරිශීලකයින් එකම වේලාවේ මෙම කොඩ් එක ක්රියාත්මක කළහොත්, 100,000 සමාන්තර DB විමසුම් සිදුවේ. ඒ නිසා latency ඉහළ යාම, cascading failures, පද්ධතියේ පූර්ණ බර පැනීම වැනි ප්රතිඵල ලැබේ.
මෙම ගැටළුවට ප්රායෝගික විසඳුම් කිහිපයක් ඇත. Distributed Locks භාවිතා කරමින්, lock එක ගත් අය පමණක් DB වෙත යයි; අනෙක් අය lock නිකුත් වන තෙක් රැඳී සිටී. Jitter එකතු කිරීමෙන් සෑම රිට්රයි එකක්ම සුළු කාලයක් වෙනස් කර, ඒකකයෙන් පිරිස් එකට එකතුවීම වැළැක්විය හැක. Single In‑Flight (request coalescing) මඟින් එකම විමසුමට සමාන 1,000 ඉල්ලීම් එක DB call එකකට එක් කරයි. Early Re‑caching මඟින් TTL ඉවර වීමට පෙර පසුබැසීමේ ක්රියාවලියක් ක්රියාත්මක කර, cache එක නවීකරණය කර තබයි.
උදාහරණයක් ලෙස, flash sale එකක “Buy Now” බොත්තමට මිලියන ගණනක් ක්ලික් කරන විට, හෝ ගෝලීය banner එකක් අවසන් වීමත් සමඟ සියලු පරිශීලකයින් cache miss කරයි. එසේම DB පසුබැසීමෙන් පසු සියලු සේවා නැවත සම්බන්ධතා පූලයක් ගොඩනැගීමට උත්සාහ කරන විටද මේ ගැටළුව පෙන්වයි.
ශ්රී ලංකාවට ඇති වැදගත්කම
- සිසුන්: උපාධි පාඨමාලාවේ performance testing කරමින් මෙම ආකාරයේ bottleneck ගැටළුව පරීක්ෂා කිරීම, real‑world තත්ත්වයන් ගැන ගැඹුරු අවබෝධයක් ලබා දෙයි.
- ඩෙවලපර්වරු: distributed lock, jitter, request coalescing වැනි pattern ගොඩනැගීමේ හැකියාව, ලොකල් startup සහ IT සමාගම් වල scalability වැඩි කරන අත්දැකීමක් සපයයි.
- ව්යාපාර: අන්තර්ජාල වෙළඳපලේ flash sale, promotional banner වැනි උත්සවයන්දී සේවා බිඳ වැටීම වැළැක්වීම, පාරිභෝගික විශ්වාසය හා ආදායම රැක ගැනීමට මූලික වේ.
ඉතින්, cache එකක් පමණක් භාවිතා කිරීම ඔබේ පද්ධතියේ “Thundering Herd” ගැටළුව විසඳන්නේ නැත. නිවැරදි architecture, lock, jitter, early refresh වැනි තාක්ෂණික උපක්රම අනුගමනය කිරීමෙන් ඔබේ සේවාවන් තදබදයක් නැතිව, වේගවත් හා විශ්වාසදායකව පවත්වා ගත හැක.
