𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗥𝗘𝗦𝗣: 𝗧𝗵𝗲 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗕𝗲𝗵𝗶𝗻𝗱 𝗥𝗲𝗱𝗶𝘀
నా మునుపటి పోస్ట్లో, Node.jsతో నేను నిర్మించిన నా Redis క్లోన్ యొక్క అవలోకనాన్ని (overview) పంచుకున్నాను. ఇప్పుడు, ఈ ప్రాజెక్ట్లోని ఒక కీలకమైన భాగాన్ని వివరించాలనుకుంటున్నాను: RESP, లేదా Redis Serialization Protocol.
Redis చక్కని JavaScript arraysలను స్వీకరించదు. ఇది TCP socket ద్వారా raw bytesలను స్వీకరిస్తుంది. ఇవి పనిచేయడానికి, ఈ బైట్లకు ఒక నిర్మాణం (structure) అవసరం. ఒక కమాండ్ ఎక్కడ మొదలై ఎక్కడ ముగుస్తుందో సర్వర్కు తెలియాలి. ఎన్ని ఆర్గ్యుమెంట్స్ (arguments) ఉన్నాయి మరియు ప్రతి ఒక్కటి ఎంత పొడవు ఉందో కూడా సర్వర్కు తెలియాలి.
RESP ఈ నిర్మాణాన్ని అందిస్తుంది. క్లయింట్లు మరియు సర్వర్లు మాట్లాడుకోవడానికి ఉపయోగించే భాష ఇది.
ఉదాహరణకు, RESPలో GET name కమాండ్ ఇలా కనిపిస్తుంది:
*2\r\n$3\r\nGET\r\n$4\r\nname\r\n
దీని వివరణ ఇక్కడ ఉంది:
*2అంటే 2 ఎలిమెంట్స్ ఉన్న ఒక array అని అర్థం.$3అంటే తదుపరి భాగం 3 బైట్ల పొడవు కలిగి ఉందని అర్థం:GET.$4అంటే తదుపరి భాగం 4 బైట్ల పొడవు కలిగి ఉందని అర్థం:name.
Parser ఈ బైట్లను ["GET", "name"]గా మారుస్తుంది. ఇప్పుడు ఇంజిన్ కమాండ్ను రన్ చేయగలదు.
కేవలం స్పేస్ల ద్వారా స్ట్రింగ్లను ఎందుకు విడదీయకూడదు?
SET message "hello world" వంటి స్పేస్లు ఉన్న విలువలతో సాధారణ విభజన (splitting) విఫలమవుతుంది. ఇది బైనరీ డేటా విషయంలో కూడా విఫలమవుతుంది. ప్రతి విలువ యొక్క పొడవును (length) చేర్చడం ద్వారా RESP దీనిని పరిష్కరిస్తుంది. సర్వర్ పేర్కొన్న బైట్ల సంఖ్యను ఖచ్చితంగా చదువుతుంది. ఇది దీనిని binary-safe మరియు నమ్మదగినదిగా చేస్తుంది.
TCP అనేది మెసేజ్-ఆధారితం (message-based) కాదు, స్ట్రీమ్-ఆధారితం (stream-based) అని తెలుసుకోవడమే అత్యంత కష్టమైన పాఠం. సర్వర్ ఎల్లప్పుడూ ఒకేసారి ఒక పూర్తి కమాండ్ను స్వీకరించదు. ఒక కమాండ్ రెండు వేర్వేరు భాగాలుగా (chunks) రావచ్చు. లేదా, బహుళ కమాండ్లు ఒకే ఒకే భాగంలో రావచ్చు.
అంటే ఒక డేటా ఈవెంట్ అంటే ఒక కమాండ్ అని parser అనుకోలేరు. Parser తప్పనిసరిగా ఒక అంతర్గత బఫర్ను (internal buffer) ఉపయోగించాలి.
నా RESP parser ఈ విధంగా పనిచేస్తుంది:
- Socket నుండి బైట్లను స్వీకరించడం.
- బైట్లను బఫర్కు జోడించడం.
- పూర్తి కమాండ్ను parse చేయడానికి ప్రయత్నించడం.
- కమాండ్ అసంపూర్తిగా ఉంటే, మరికొంత డేటా కోసం వేచి ఉండటం.
- కమాండ్ పూర్తయితే, దానిని తిరిగి పంపడం (return).
- అదనపు డేటా మిగిలి ఉంటే, తదుపరి parse కోసం దానిని బఫర్లో ఉంచడం.
డేటాబేస్ ప్రోటోకాల్ లేయర్ (protocol layer) వద్ద ప్రారంభమవుతుంది. Redis డేటాను నిల్వ చేసే ముందు, అది కమాండ్ను అర్థం చేసుకోవాలి. అది ఒక విలువను తిరిగి ఇచ్చే ముందు, రెస్పాన్స్ను ఎన్కోడ్ (encode) చేయాలి.
RESPని అమలు చేయడం ఒక సాధారణ TCP సర్వర్ను నిజమైన Redis-అనుకూల వ్యవస్థగా మార్చింది. ఇది బ్యాకెండ్ సిస్టమ్లను నేను చూసే విధానాన్ని మార్చింది. ప్రోటోకాల్ అనేది కేవలం ఒక ఫార్మాట్ మాత్రమే కాదు. ఇది రెండు వ్యవస్థల మధ్య జరిగే ఒక ఒప్పందం (contract).
నా తదుపరి పోస్ట్లో, నేను in-memory storage లేయర్ను వివరిస్తాను.
రిపోజిటరీ: https://github.com/Abhinov007/redis_clone లైవ్ సాండ్బాక్స్: https://abhinov007.github.io/Redis_Clone/ మూలం: https://dev.to/abhinov007/understanding-resp-the-protocol-behind-redis-50p4