පණිවුඩ-ආශ්රිත පද්ධතියක් නිර්මාණය කරන විට මුල්ම ප්රශ්නය වන්නේ, සකස් නොකළ පණිවුඩයක් කුමන ලෙස හසුරවන්නද? සරලව කියනවානම්, දෝෂයක් සිදු වූ විට එය ලොග් කර ඉවත් කර දැමීමයි. එහෙමයි කියලා හිතුවොත්, නිෂ්පාදන පරිසරයේ පණිවුඩ අහිමි වීමක් බවට පත්වේ – නැවත පිරික්සුමක්, රිවෝක් එකක්, හෝ පරීක්ෂණ ලොග් එකක් නොමැතිව.
RabbitMQ හි Dead Letter Exchange (DLX) යනු මේ ගැටලුවට හොඳ විසඳුමක්. එය පණිවුඩයක් අසාර්ථක වුවහොත්, ඒ පණිවුඩය වෙනත් විනිවිද පසුබැසීමක (Dead Letter Queue) ගෙන යාමට ඉඩ සලසයි. නමුත් DLX එකක් පමණක් පූර්ණ දෝෂ-හසුරවීමේ ක්රමයක් නොවේ – එය retry, persistence, publisher confirms, monitoring සහ replay වැනි වෙනත් මොඩියුල සමඟ එකතු කර වැඩිදුරටත් භාවිතා කළ යුතුය.
අපගේ පද්ධතියේ පණිවුඩ ප්රවාහය තිදෙනෙකුගේ මූලික තීරණ මත පදනම් වේ:
- නැවත පෝෂණය කිරීම – BasicNack(requeue:true) භාවිතා කර පණිවුඩය නැවත කේතයට යැවීම. තාවකාලික දෝෂ සඳහා සුදුසු, නමුත් ස්ථිර දෝෂයකදී පණිවුඩය අඛණ්ඩව ලූප් වීමේ අවදානමක් ඇත.
- නොපිටවීම (DLX නොමැති) – BasicNack(requeue:false) හෝ BasicReject(requeue:false) භාවිතා කර පණිවුඩය අතුරුදන් වේ. මෙය දෙවැනි අවස්ථාවක් නොලැබීමේ හා නිරීක්ෂණය නොකිරීමේ ගැටලුවක් ඇති කරයි.
- DLX සමඟ ප්රතික්ෂේප කිරීම – පණිවුඩය DLX වෙත යැවීම, එවිට Dead Letter Queue එකකට රූට් කරගැනීම. මෙය ස්ථිර දෝෂ ඇති පණිවුඩ සඳහා එකම පිළිගත හැකි මාර්ගය.
Dead‑lettering සිදුවිය හැකි හේතු කිහිපයක් ඇත: consumer එකේ reject/nack (requeue:false), TTL නිසා පණිවුඩය කල් ඉකුත් වීම, queue දිග සීමාව ඉක්මවා යාම, හෝ quorum queue එකේ delivery සීමාව ඉක්මවා යාම. අපගේ කේස් එකේ ප්රධාන හේතුව consumer එකේ explicit reject වීමයි.
RabbitMQ පණිවුඩයට x-death, x-first-death-* වැනි header මඟින් මූලික queue, හේතුව, මරණ ඉතිහාසය වැනි තොරතුරු එකතු කරයි. ඒත් production පරිසරයේ, පණිවුඩ ID, correlation ID, queue නාමය, exception වර්ගය, හා failure හේතුව log කර ගැනීම අත්යවශ්යයි.
ශ්රී ලංකාවට ඇති වැදගත්කම
- ඉගෙනුම් ආකාරය – සිසුන්ට real‑world message queue architecture එකේ DLQ භාවිතය අත්හදා බැලීමට අවස්ථාව ලැබේ.
- ඩිවෙලපර්ලාට – .NET සහ RabbitMQ එකට DLX policies හරහා සකස් කිරීමෙන්, අලුත්ම DevOps ප්රතිපත්ති අනුගමනය කළ හැක.
- ව්යාපාරිකයින්ට – පණිවුඩ අහිමි වීම වැළැක්වීමෙන්, සේවා විශ්වාසතාවය වැඩිවීම සහ audit trail එකක් ලබා ගත හැක.
DLX සකස් කිරීමේදී policies (rabbitmqctl set_policy) භාවිතා කිරීම ඉතා සුදුසුය, ඒ මඟින් queue නැවත සකස් කිරීමකින් තොරව configuration වෙනස් කළ හැක. hard‑coded queue arguments වලට වඩා policies ලච්චි, නවීකරණය සහ අනුගමනය පහසුය.
අවසන් වශයෙන්, DLQ එකක් “දෝෂ සලකුණු කිරීමේ මධ්යස්ථානය” බව අමතක නොකරන්න – එය සලකුණු කළ පණිවුඩයන්ට තීරණයක් ගැනීමට ඉඩ සලසන ස්ථානයක් පමණයි. නිසි logging, retry strategy, සහ replay mechanism එකක් සමඟ ඒකතුවෙන් භාවිතා කළ විට, ඔබේ පණිවුඩ පද්ධතිය තවත් ස්ථිර, ආරක්ෂිත, හා පරීක්ෂණීය වේ.
