𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗥𝗘𝗦𝗣: 𝗧𝗵𝗲 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗕𝗲𝗵𝗶𝗻𝗱 𝗥𝗲𝗱𝗶𝘀

अपनी पिछली पोस्ट में, मैंने Node.js के साथ बनाए गए अपने Redis क्लोन का एक अवलोकन (overview) साझा किया था। अब, मैं इस प्रोजेक्ट के एक महत्वपूर्ण हिस्से को समझाना चाहता हूँ: RESP, या Redis Serialization Protocol।

Redis को सुंदर JavaScript arrays नहीं मिलते। इसे TCP socket के माध्यम से raw bytes मिलते हैं। काम करने के लिए, इन bytes को एक संरचना (structure) की आवश्यकता होती है। सर्वर को पता होना चाहिए कि कमांड कहाँ शुरू और कहाँ समाप्त होती है। उसे यह भी पता होना चाहिए कि कितने arguments मौजूद हैं और प्रत्येक की लंबाई कितनी है।

RESP यही संरचना प्रदान करता है। यह वह भाषा है जिसका उपयोग क्लाइंट और सर्वर बातचीत करने के लिए करते हैं।

उदाहरण के लिए, RESP में GET name कमांड इस तरह दिखती है: *2\r\n$3\r\nGET\r\n$4\r\nname\r\n

यहाँ इसका विवरण दिया गया है:

  • *2 का अर्थ है 2 elements वाला एक array।
  • $3 का अर्थ है कि अगला हिस्सा 3 bytes लंबा है: GET।
  • $4 का अर्थ है कि अगला हिस्सा 4 bytes लंबा है: name।

पार्सर (parser) इन bytes को ["GET", "name"] में बदल देता है। अब इंजन कमांड चला सकता है।

स्ट्रिंग्स को सिर्फ स्पेस (spaces) के आधार पर क्यों नहीं बाँटा जाता? साधारण स्प्लिटिंग (splitting) उन values के साथ विफल हो जाती है जिनमें स्पेस होते हैं, जैसे SET message "hello world"। यह binary data के साथ भी विफल हो जाती है। RESP हर value की लंबाई शामिल करके इस समस्या को हल करता है। सर्वर ठीक उतने ही bytes पढ़ता है जितने निर्दिष्ट (specified) किए गए हैं। यह इसे binary-safe और विश्वसनीय बनाता है।

सबसे कठिन सबक यह सीखना था कि TCP stream-based होता है, message-based नहीं। सर्वर को हमेशा एक बार में एक पूरी कमांड नहीं मिलती है। एक कमांड दो अलग-अलग chunks में आ सकती है। या, एक ही chunk में कई कमांड आ सकती हैं।

इसका मतलब है कि पार्सर यह मानकर नहीं चल सकता कि एक data event का मतलब एक कमांड है। पार्सर को एक internal buffer का उपयोग करना चाहिए।

मेरा RESP पार्सर इस तरह काम करता है:

  1. Socket से bytes प्राप्त करें।
  2. Bytes को एक buffer में जोड़ें।
  3. एक पूरी कमांड को parse करने का प्रयास करें।
  4. यदि कमांड अधूरी है, तो और डेटा का इंतज़ार करें।
  5. यदि कमांड पूरी है, तो उसे return करें।
  6. यदि अतिरिक्त डेटा बचता है, तो उसे अगले parse के लिए buffer में रखें।

एक डेटाबेस की शुरुआत प्रोटोकॉल लेयर से होती है। Redis द्वारा डेटा स्टोर करने से पहले, उसे कमांड को समझना होगा। वैल्यू return करने से पहले, उसे रिस्पॉन्स को encode करना होगा।

RESP को लागू करने से एक साधारण TCP सर्वर एक वास्तविक Redis-compatible सिस्टम में बदल गया। इसने बैकएंड सिस्टम को देखने के मेरे नज़रिए को बदल दिया। एक प्रोटोकॉल केवल एक फॉर्मेट से कहीं अधिक है। यह दो सिस्टमों के बीच एक अनुबंध (contract) है।

अपनी अगली पोस्ट में, मैं in-memory storage layer के बारे में बताऊँगा।

रिपॉजिटरी: https://github.com/Abhinov007/redis_clone लाइव सैंडबॉक्स: https://abhinov007.github.io/Redis_Clone/ स्रोत: https://dev.to/abhinov007/understanding-resp-the-protocol-behind-redis-50p4