Kuelewa RESP: Itifaki Inayofanya Kazi Nyuma ya Redis

Katika chapisho langu lililopita, nilishiriki muhtasari wa Redis clone yangu niliyojenga kwa kutumia Node.js. Sasa, nataka kuelezea sehemu muhimu ya mradi huu: RESP, au Redis Serialization Protocol.

Redis haipokei array nzuri za JavaScript. Inapokea byte ghafi kupitia TCP socket. Ili zifanye kazi, byte hizi zinahitaji muundo. Seva lazima ijue amri (command) inapoanza na inapoishia. Lazima ijue ni argument ngapi zipo na kila moja ina urefu gani.

RESP hutoa muundo huu. Ni lugha ambayo wateja (clients) na seva hutumia kuzungumza.

Kwa mfano, amri ya GET name inaonekana hivi katika RESP: *2\r\n$3\r\nGET\r\n$4\r\nname\r\n

Hapa kuna mchanganuo:

  • *2 inamaanisha array yenye vipengele (elements) 2.
  • $3 inamaanisha sehemu inayofuata ina urefu wa byte 3: GET.
  • $4 inamaanisha sehemu inayofuata ina urefu wa byte 4: name.

Parser inageuza byte hizi kuwa ["GET", "name"]. Sasa injini inaweza kuendesha amri hiyo.

Kwa nini tusigawanye string kwa kutumia nafasi (spaces)? Kugawanya kwa urahisi hukwama pale thamani (values) zinapokuwa na nafasi, kama vile SET message "hello world". Pia hukwama na data za binary. RESP inatatua hili kwa kujumuisha urefu wa kila thamani. Seva inasoma idadi kamili ya byte iliyoelezwa. Hii inafanya iwe salama kwa binary (binary-safe) na ya kuaminika.

Somo gumu zaidi lilikuwa kujifunza kwamba TCP inategemea mtiririko (stream-based), si ujumbe (message-based). Seva haipokei kila wakati amri moja kamili kwa wakati mmoja. Amri inaweza kuwasili katika vipande (chunks) viwili tofauti. Au, amri nyingi zinaweza kuwasili katika kipande kimoja tu.

Hii inamaanisha kuwa parser haiwezi kudhania kuwa tukio moja la data ni sawa na amri moja. Parser lazima itumie buffer ya ndani.

Parser yangu ya RESP inafanya kazi hivi:

  1. Pokea byte kutoka kwenye socket.
  2. Ongeza byte kwenye buffer.
  3. Jaribu kutafsiri (parse) amri kamili.
  4. Ikiwa amri haijakamilika, subiri data zaidi.
  5. Ikiwa amri imekamilika, irudishe.
  6. Ikiwa kuna data ya ziada imebaki, iweke kwenye buffer kwa ajili ya tafsiri inayofuata.

Kanzi data (database) huanzia kwenye tabaka la itifaki (protocol layer). Kabla Redis haijatunza data, lazima ielewe amri. Kabla haijarudisha thamani, lazima iencode jibu (response).

Kutekeleza RESP kuligeuza seva rahisi ya TCP kuwa mfumo kamili unaoendana na Redis. Ilibadilisha jinsi ninavyoona mifumo ya backend. Itifaki ni zaidi ya muundo (format). Ni mkataba kati ya mifumo miwili.

Katika chapisho langu lijalo, nitazungumzia tabaka la uhifadhi wa ndani ya kumbukumbu (in-memory storage layer).

Repo: https://github.com/Abhinov007/redis_clone Sandbox ya moja kwa moja: https://abhinov007.github.io/Redis_Clone/ Chanzo: https://dev.to/abhinov007/understanding-resp-the-protocol-behind-redis-50p4