𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗥𝗘𝗦𝗣: 𝗧𝗵𝗲 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗕𝗲𝗵𝗶𝗻𝗱 𝗥𝗲𝗱𝗶𝘀
મારી અગાઉની પોસ્ટમાં, મેં Node.js સાથે બનાવેલા મારા Redis ક્લોનનો એક ઓવરવ્યુ શેર કર્યો હતો. હવે, હું આ પ્રોજેક્ટના એક મહત્વપૂર્ણ ભાગ વિશે સમજાવવા માંગુ છું: RESP, અથવા Redis Serialization Protocol.
Redis ને સુંદર JavaScript એરે (arrays) મળતા નથી. તેને TCP સોકેટ દ્વારા કાચા બાઇટ્સ (raw bytes) મળે છે. કામ કરવા માટે, આ બાઇટ્સને એક માળખાની (structure) જરૂર હોય છે. સર્વરે ખબર હોવી જોઈએ કે કમાન્ડ ક્યાંથી શરૂ થાય છે અને ક્યાં સમાપ્ત થાય છે. તેને ખબર હોવી જોઈએ કે કેટલા આર્ગ્યુમેન્ટ્સ (arguments) છે અને દરેક કેટલા લાંબા છે.
RESP આ માળખું પૂરું પાડે છે. તે ક્લાયન્ટ્સ અને સર્વર્સ વચ્ચે વાતચીત કરવા માટે વપરાતી ભાષા છે.
ઉદાહરણ તરીકે, RESP માં GET name કમાન્ડ આવો દેખાય છે:
*2\r\n$3\r\nGET\r\n$4\r\nname\r\n
અહીં તેનું વિભાજન છે:
*2એટલે 2 એલિમેન્ટ્સ વાળો એરે.$3એટલે કે પછીનો ભાગ 3 બાઇટ્સ લાંબો છે: GET.$4એટલે કે પછીનો ભાગ 4 બાઇટ્સ લાંબો છે: name.
પાર્સર આ બાઇટ્સને ["GET", "name"] માં ફેરવે છે. હવે એન્જિન કમાન્ડ ચલાવી શકે છે.
માત્ર સ્પેસ દ્વારા સ્ટ્રિંગ્સને કેમ સ્પ્લિટ (split) નથી કરતા?
સાદું સ્પ્લિટિંગ એવા મૂલ્યો (values) સાથે નિષ્ફળ જાય છે જેમાં સ્પેસ હોય છે, જેમ કે SET message "hello world". તે બાઈનરી ડેટા સાથે પણ નિષ્ફળ જાય છે. RESP દરેક મૂલ્યની લંબાઈનો સમાવેશ કરીને આ સમસ્યાનું સમાધાન કરે છે. સર્વર બરાબર નિર્દિષ્ટ કરેલા બાઇટ્સની સંખ્યા વાંચે છે. આ તેને binary-safe અને વિશ્વસનીય બનાવે છે.
સૌથી અઘરો પાઠ એ શીખવાનો હતો કે TCP એ સ્ટ્રીમ-આધારિત (stream-based) છે, મેસેજ-આધારિત (message-based) નથી. સર્વરને હંમેશા એક સમયે એક સંપૂર્ણ કમાન્ડ મળતો નથી. એક કમાન્ડ બે અલગ-અલગ ટુકડાઓમાં (chunks) આવી શકે છે. અથવા, એક જ ટુકડામાં અનેક કમાન્ડ્સ આવી શકે છે.
આનો અર્થ એ છે કે પાર્સર એમ માની શકતું નથી કે એક ડેટા ઇવેન્ટ એટલે એક કમાન્ડ. પાર્સરે આંતરિક બફર (internal buffer) નો ઉપયોગ કરવો આવશ્યક છે.
મારો RESP પાર્સર આ રીતે કામ કરે છે:
- સોકેટમાંથી બાઇટ્સ મેળવો.
- બાઇટ્સને બફરમાં ઉમેરો.
- સંપૂર્ણ કમાન્ડ પાર્સ કરવાનો પ્રયાસ કરો.
- જો કમાન્ડ અધૂરો હોય, તો વધુ ડેટા માટે રાહ જુઓ.
- જો કમાન્ડ પૂર્ણ હોય, તો તેને રિટર્ન કરો.
- જો વધારાનો ડેટા બાકી રહે, તો તેને આગામી પાર્સિંગ માટે બફરમાં રાખો.
ડેટાબેઝ પ્રોટોકોલ લેયરથી શરૂ થાય છે. Redis ડેટા સ્ટોર કરી શકે તે પહેલાં, તેણે કમાન્ડ સમજવો આવશ્યક છે. તે મૂલ્ય રિટર્ન કરે તે પહેલાં, તેણે રિસ્પોન્સને એન્કોડ (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