Арав гаруй жилийн турш хөгжиж буй бүтээгдэхүүн дээр ирэхэд хуучирсан технологиудыг олох нь гайхмаар зүйл биш юм. Харин зургаан сарын дотор 10 дахин их ачааллыг бариад уналтын зардал хэдэн зуу дахин нэмэгдвэл яах вэ? Энэ тохиолдолд танд өндөр ачаалалтай инженер хэрэгтэй. Гэвч үйлчлэгч байхгүй тул асуудлыг шийдэж өгөхийг надад даатгасан. Өгүүллийн эхний хэсэгт бид Redis-ээс Redis-cluster руу хэрхэн шилжсэнээ, хоёрдугаар хэсэгт кластерыг хэрхэн ашиглаж эхлэх, ашиглахдаа юуг анхаарах талаар зөвлөгөө өгөх болно.

Технологийн сонголт

Тийм муу гэж үү? тусдаа Redis (бие даасан redis) 1 мастер болон N боолын тохиргоонд? Би яагаад үүнийг хуучирсан технологи гэж нэрлээд байгаа юм бэ?

Үгүй ээ, Редис тийм ч муу биш... Гэсэн хэдий ч зарим нэг дутагдалтай талуудыг үл тоомсорлож болохгүй.

• Нэгдүгээрт, Редис нь мастер бүтэлгүйтлийн дараа гамшгийн нөхөн сэргээх механизмыг дэмждэггүй. Энэ асуудлыг шийдэхийн тулд бид VIP-г шинэ мастер руу автоматаар шилжүүлэх тохиргоог ашигласан бөгөөд нэг боолын үүргийг өөрчилж, үлдсэнийг нь сольсон. Энэ механизм ажилласан боловч найдвартай шийдэл гэж нэрлэгдэх боломжгүй байв. Нэгдүгээрт, хуурамч дохиолол гарсан, хоёрдугаарт, энэ нь нэг удаагийнх байсан бөгөөд ашиглалтын дараа гар аргаар пүршийг цэнэглэх шаардлагатай болсон.

• Хоёрдугаарт, ганцхан эзэнтэй байх нь хагарлын асуудалд хүргэсэн. Бид "1 мастер ба N боол" гэсэн хэд хэдэн бие даасан кластеруудыг үүсгэж, дараа нь эдгээр машинуудын хооронд мэдээллийн санг гараар тарааж, маргааш мэдээллийн сангуудын аль нэг нь тийм ч томроогүй тул тусдаа инстанц руу шилжих болно гэж найдаж байна.

Ямар сонголтууд байна вэ?

• Хамгийн үнэтэй, хамгийн баян шийдэл бол Redis-Enterprise юм. Энэ бол техникийн бүрэн дэмжлэг бүхий хайрцагласан шийдэл юм. Техникийн үүднээс харахад энэ нь хамгийн тохиромжтой мэт боловч үзэл суртлын шалтгаанаар бидэнд тохирохгүй байв.
• Redis-кластер. Шигтгээнээс гадна мастер шилжүүлэлт болон хуваах дэмжлэг байдаг. Интерфейс нь ердийн хувилбараас бараг ялгаатай биш юм. Энэ нь ирээдүйтэй харагдаж байна, бид алдаа дутагдлын талаар дараа ярих болно.
• Tarantool, Memcache, Aerospike болон бусад. Эдгээр бүх хэрэгслүүд бараг ижил зүйлийг хийдэг. Гэхдээ тус бүр өөрийн гэсэн дутагдалтай байдаг. Бид бүх өндөгөө нэг сагсанд хийхгүй байхаар шийдсэн. Бид Memcache болон Tarantool-ийг бусад ажлуудад ашигладаг бөгөөд урагшаа харахад бидний практикт тэдэнтэй холбоотой асуудал илүү их байсан гэж би хэлэх болно.

Ашиглалтын онцлог

Бид Редистэй ямар асуудлуудыг түүхэнд шийдэж, ямар функцийг ашигласан болохыг харцгаая.

• 2GIS | зэрэг алсын үйлчилгээнд хүсэлт гаргахаас өмнө кэш хийх Голанг
  

  SET MGET MSET "SELECT DB"

• MYSQL | өмнөх кэш PHP
  

  SET MGET MSET SCAN-г АВАХ "ХЭЭЖЭЭР ТҮЛХҮҮР" "МБ СОНГОХ"

• Сеанс болон драйверын координаттай ажиллах үйлчилгээний үндсэн хадгалалт | Голанг
  

  SET АВАХ MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Таны харж байгаагаар дээд математик байхгүй. Тэгвэл хүндрэл нь юу вэ? Арга тус бүрийг тусад нь авч үзье.

арга
Тайлбар
Redis-cluster-ийн онцлог
шийдвэр

ТОНИЛЦУУЛАХ
бичих/унших түлхүүр

MGET MSET
Олон товчлуур бичих/унших
Түлхүүрүүд нь өөр өөр зангилаанууд дээр байх болно. Бэлэн номын сангууд зөвхөн нэг зангилаа дотор олон үйлдэл хийх боломжтой
MGET-ийг N GET үйлдлийн шугамаар солих

DB СОНГОХ
Бидэнтэй ажиллах суурийг сонго
Олон мэдээллийн санг дэмждэггүй
Бүгдийг нэг мэдээллийн санд байрлуул. Түлхүүрүүдэд угтвар нэмэх

СКАН
Өгөгдлийн сангийн бүх түлхүүрүүдийг шалгана уу
Бид нэг мэдээллийн сантай тул кластерын бүх түлхүүрийг нэвтрүүлэх нь хэтэрхий үнэтэй юм
Нэг түлхүүрийн доторх инвариантыг хадгалж, энэ түлхүүр дээр HSCAN хийнэ. Эсвэл бүрмөсөн татгалзах

GEO
Геокэйктэй үйлдлүүд
Геокэйг хэлтэрхийгүй

ХЭЭ ЗААВАР ТҮЛХҮҮР
Загварын дагуу түлхүүр хайж байна
Бид нэг мэдээллийн сантай тул кластерын бүх түлхүүрүүдийг хайх болно. Хэтэрхий үнэтэй
SCAN-ийн нэгэн адил инвариантаас татгалзах буюу хадгалах

Redis-ийн эсрэг Redis-кластер

Кластерт шилжихэд бид юу алдаж, юу хожих вэ?

• Сул талууд: бид хэд хэдэн мэдээллийн сангийн үйл ажиллагааг алддаг.
  • Хэрэв бид логик хамааралгүй өгөгдлийг нэг кластерт хадгалахыг хүсвэл угтвар хэлбэрээр таяг хийх хэрэгтэй болно.
  • Бид SCAN, DBSIZE, CLEAR DB гэх мэт бүх "үндсэн" үйлдлүүдийг алддаг.
  • Олон үйлдэл хийх нь хэд хэдэн зангилаанд хандах шаардлагатай байж болох тул хэрэгжүүлэхэд илүү хэцүү болсон.
• Дээр нь:
  • Мастер бүтэлгүйтлийн хэлбэрийн алдааг тэсвэрлэх чадвар.
  • Редис талын хэсэгчилсэн хэсэг.
  • Өгөгдлийг зангилаа хооронд атомаар болон зогсолтгүйгээр дамжуулах.
  • Сул зогсолтгүйгээр хүчин чадал, ачааллыг нэмж, дахин хуваарилах.

Хэрэв та өндөр түвшний эвдрэлийг тэсвэрлэх шаардлагагүй бол кластер руу шилжих нь үнэ цэнэтэй зүйл биш, учир нь энэ нь өчүүхэн бус ажил байж болно гэж би дүгнэж байна. Гэхдээ хэрэв та эхлээд тусдаа хувилбар болон кластер хувилбарын аль нэгийг нь сонгосон бол кластер сонгох хэрэгтэй, учир нь энэ нь үүнээс муу зүйл биш бөгөөд үүнээс гадна толгойн зарим өвчинг намдаах болно.

Хөдлөхөд бэлдэж байна

Шилжихэд тавигдах шаардлагуудаас эхэлье:

• Энэ нь саадгүй байх ёстой. Үйлчилгээг 5 минутын турш бүрэн зогсоох нь бидэнд тохирохгүй.
• Энэ нь аль болох аюулгүй, аажмаар байх ёстой. Би нөхцөл байдалд хяналт тавихыг хүсч байна. Бид бүгдийг нэг дор хаяж, буцаах товчлуур дээр залбирахыг хүсэхгүй байна.
• Хөдлөх үед хамгийн бага өгөгдөл алдагдуулдаг. Атомоор шилжих нь маш хэцүү гэдгийг бид ойлгож байгаа тул ердийн болон бөөгнөрсөн Redis-д өгөгдөл хооронд синхрончлолгүй болгохыг зөвшөөрдөг.

Кластерийн засвар үйлчилгээ

Хөдлөхийн өмнөхөн бид кластерыг дэмжиж чадах эсэхээ бодох хэрэгтэй.

• График. Бид Prometheus болон Grafana программыг ашиглан CPU-ийн ачаалал, санах ойн ашиглалт, үйлчлүүлэгчдийн тоо, GET, SET, AUTH үйлдлийн тоо гэх мэт графикийг гаргадаг.
• Мэргэшсэн байдал. Маргааш таны хариуцлагын дор асар том кластер бий болно гэж төсөөлөөд үз дээ. Хагарвал чамаас өөр хэн ч засч чадахгүй. Хэрвээ тэр удааширч эхэлбэл бүгд чам руу гүйх болно. Хэрэв та нөөцийг нэмэх эсвэл ачааллыг дахин хуваарилах шаардлагатай бол буцаж ирээрэй. 25 настайдаа саарал өнгөтэй болохгүйн тулд эдгээр тохиолдлуудыг анхаарч, тодорхой үйлдлүүдийн дагуу технологи хэрхэн ажиллахыг урьдчилан шалгахыг зөвлөж байна. Энэ талаар "Мэргэжилтэн" хэсэгт илүү дэлгэрэнгүй ярилцъя.
• Хяналт, сэрэмжлүүлэг. Кластер задрахад та хамгийн түрүүнд энэ талаар мэдэхийг хүсдэг. Энд бид бүх зангилаа нь кластерын төлөв байдлын талаархи ижил мэдээллийг буцаадаг гэсэн мэдэгдлээр хязгаарлагдах болно (тиймээ, энэ нь өөрөөр тохиолддог). Мөн бусад асуудлуудыг Redis-ийн үйлчлүүлэгчийн үйлчилгээний дохиогоор илүү хурдан анзаарч болно.

Хөдлөх

Бид хэрхэн шилжих вэ:

• Юуны өмнө кластертай ажиллах номын сан бэлтгэх хэрэгтэй. Бид go-redis-ийг Go хувилбарын үндэс болгон авч өөрсөддөө тохируулан бага зэрэг өөрчилсөн. Бид дамжуулах хоолойгоор дамжуулан олон аргыг хэрэгжүүлж, хүсэлтийг давтах дүрмийг бага зэрэг зассан. PHP хувилбар нь илүү их асуудалтай байсан ч бид эцэст нь php-redis дээр тогтсон. Тэд саяхан кластерийн дэмжлэгийг нэвтрүүлсэн бөгөөд энэ нь бидний бодлоор сайн харагдаж байна.
• Дараа нь та кластерийг өөрөө байрлуулах хэрэгтэй. Энэ нь тохиргооны файл дээр суурилсан хоёр тушаалаар шууд утгаараа хийгддэг. Бид тохиргооны талаар доор дэлгэрэнгүй ярих болно.
• Аажмаар шилжихийн тулд бид хуурай горимыг ашигладаг. Бидэнд ижил интерфейстэй номын сангийн хоёр хувилбар (нэг нь ердийн хувилбар, нөгөө нь кластерт зориулагдсан) байгаа тул тусдаа хувилбартай ажиллах боодол үүсгэхэд ямар ч зардал гарахгүй бөгөөд кластерт бүх хүсэлтийг зэрэгцүүлэн хуулбарлах болно. хариултуудыг харьцуулж, бүртгэлийн зөрүүг бичих (бидний хувьд NewRelic). Тиймээс, кластер хувилбарыг нэвтрүүлэх явцад эвдэрсэн ч манай үйлдвэрлэлд нөлөөлөхгүй.
• Кластерийг хуурай горимд оруулсны дараа бид хариултын зөрүүний графикийг тайван харж болно. Хэрэв алдааны түвшин аажмаар боловч тодорхой бага тогтмол руу шилжвэл бүх зүйл хэвийн байна. Яагаад зөрүүтэй байсаар байна вэ? Тусдаа хувилбарт бичлэг хийх нь кластераас арай эрт явагддаг бөгөөд бичил хоцролтоос болж өгөгдөл нь ялгаатай байж болно. Үлдсэн зүйл бол зөрүүний бүртгэлийг үзэх бөгөөд хэрэв тэдгээр нь бүгд атомын бус бүртгэлээр тайлбарлагдвал бид цаашаа явж болно.
• Одоо та хуурай горимыг эсрэг чиглэлд сольж болно. Бид кластераас бичиж, уншиж, тусдаа хувилбар болгон хувилах болно. Юуны төлөө? Дараагийн долоо хоногт би кластерын ажлыг ажигламаар байна. Хэрэв гэнэт оргил ачааллын үед асуудал гарсан эсвэл бид ямар нэг зүйлийг анхаарч үзээгүй бол хуурай горимын ачаар бид хуучин код болон одоогийн өгөгдөл рүү яаралтай буцаах боломжтой байдаг.
• Үлдсэн зүйл бол хуурай горимыг идэвхгүй болгож, тусдаа хувилбарыг задлах явдал юм.

Мэргэжилтнүүд

Нэгдүгээрт, кластер дизайны талаар товчхон хэлье.

Юуны өмнө Redis бол үнэ цэнэтэй дэлгүүр юм. Дурын мөрүүдийг түлхүүр болгон ашигладаг. Тоонууд, мөрүүд болон бүхэл бүтцийг утга болгон ашиглаж болно. Сүүлийнх нь маш олон боловч ерөнхий бүтцийг ойлгоход энэ нь бидний хувьд чухал биш юм.
Түлхүүрүүдийн дараа хийсвэрлэх дараагийн түвшин нь үүр (SLOTS) юм. Түлхүүр бүр 16 слотын аль нэгэнд хамаарна. Слот бүрийн дотор хэдэн ч товчлуур байж болно. Тиймээс бүх түлхүүрүүд нь 383 салангид багцад хуваагддаг.

Дараа нь кластерт N мастер зангилаа байх ёстой. Зангилаа бүрийг кластер доторх бусад зангилааны талаар бүгдийг мэддэг Redis-ийн тусдаа жишээ гэж үзэж болно. Мастер зангилаа бүр хэд хэдэн үүртэй. Слот бүр нь зөвхөн нэг мастер зангилаанд хамаарна. Бүх үүрийг зангилааны хооронд хуваарилах шаардлагатай. Хэрэв зарим үүрийг хуваарилаагүй бол тэдгээрт хадгалагдсан түлхүүрүүд нэвтрэх боломжгүй болно. Мастер зангилаа бүрийг тусдаа логик эсвэл физик машин дээр ажиллуулах нь утга учиртай. Зангилаа бүр зөвхөн нэг цөм дээр ажилладаг гэдгийг санах нь зүйтэй бөгөөд хэрэв та нэг логик машин дээр хэд хэдэн Redis жишээг ажиллуулахыг хүсвэл тэдгээр нь өөр цөм дээр ажиллаж байгаа эсэхийг шалгаарай (бид үүнийг туршиж үзээгүй ч онолын хувьд ажиллах ёстой) . Үндсэндээ мастер зангилаа нь тогтмол хуваалтаар хангадаг ба илүү олон мастер зангилаа нь бичих, унших хүсэлтийг масштаблах боломжийг олгодог.

Бүх түлхүүрүүдийг үүрнүүдийн хооронд хуваарилж, үүрүүд нь мастер зангилаанууд дунд тархсаны дараа мастер зангилаа бүрт дурын тооны боол зангилаа нэмж болно. Ийм мастер-боол холбоос бүрийн дотор ердийн хуулбар ажиллах болно. Унших хүсэлтийг масштаблах, мастер бүтэлгүйтсэн тохиолдолд шилжүүлэн суулгахад туслах хэрэгслүүд хэрэгтэй.

Одоо хийх боломжтой байсан нь дээр байсан үйл ажиллагааны талаар ярья.

Бид Redis-CLI-ээр дамжуулан системд хандах болно. Redis-д нэг нэвтрэх цэг байхгүй тул та аль нэг зангилаа дээр дараах үйлдлүүдийг хийж болно. Цэг бүр дээр би ачааллын дор үйл ажиллагааг гүйцэтгэх боломжид тус тусад нь анхаарлаа хандуулдаг.

• Бидэнд хэрэгтэй хамгийн эхний бөгөөд хамгийн чухал зүйл бол кластер зангилааны ажиллагаа юм. Энэ нь кластерын төлөвийг буцаана, зангилааны жагсаалт, тэдгээрийн үүрэг, үүрний хуваарилалт гэх мэтийг харуулна. Дэлгэрэнгүй мэдээллийг кластерын мэдээлэл болон кластерын слот ашиглан авах боломжтой.
• Зангилаа нэмэх, хасах боломжтой бол сайхан байх болно. Энэ зорилгоор кластер уулзах, кластер мартах үйлдлүүд байдаг. Кластер мартах нь мастер болон хуулбарын аль алинд нь БҮР зангилаанд хэрэглэгдэх ёстойг анхаарна уу. Мөн кластер уулзалтыг зөвхөн нэг зангилаа дээр дуудах шаардлагатай. Энэ ялгаа нь сэтгэл түгшээж болзошгүй тул кластертайгаа шууд холбогдохоосоо өмнө энэ талаар мэдэж авсан нь дээр. Зангилаа нэмэх нь тулалдаанд аюулгүйгээр хийгддэг бөгөөд кластерын үйл ажиллагаанд ямар ч байдлаар нөлөөлөхгүй (энэ нь логик юм). Хэрэв та кластераас зангилаа устгах гэж байгаа бол түүн дээр ямар ч үүр байхгүй эсэхийг шалгах хэрэгтэй (эсвэл та энэ зангилааны бүх түлхүүрүүдэд хандах эрхээ алдах эрсдэлтэй). Мөн боолтой эзнийг бүү устга, эс тэгвээс шинэ эзний төлөө шаардлагагүй санал өгөх болно. Хэрэв зангилаанууд үүргүй болсон бол энэ нь жижиг асуудал юм, гэхдээ бид эхлээд боолуудыг устгаж чадвал яагаад нэмэлт сонголт хэрэгтэй байна вэ.
• Хэрэв та мастер болон боолын байрлалыг хүчээр солих шаардлагатай бол кластерийн шилжүүлэлт командыг гүйцэтгэнэ. Үүнийг тулалдаанд дуудахдаа үйл ажиллагааны явцад мастер байхгүй болно гэдгийг ойлгох хэрэгтэй. Ихэвчлэн шилжүүлэгч нь секунд хүрэхгүй хугацаанд тохиолддог боловч атом биш юм. Энэ хугацаанд мастерт өгөх зарим хүсэлт амжилтгүй болно гэж найдаж болно.
• Кластераас зангилаа арилгахын өмнө үүн дээр ямар ч үүр үлдэх ёсгүй. Claster reshard командыг ашиглан тэдгээрийг дахин хуваарилах нь дээр. Слотуудыг нэг мастераас нөгөөд шилжүүлэх болно. Бүхэл бүтэн үйл ажиллагаа хэдэн минут үргэлжилж болох бөгөөд энэ нь дамжуулж буй өгөгдлийн хэмжээнээс хамаарна, гэхдээ дамжуулах процесс нь аюулгүй бөгөөд кластерын үйл ажиллагаанд ямар ч байдлаар нөлөөлөхгүй. Тиймээс бүх өгөгдлийг ачааллын дор шууд нэг зангилаанаас нөгөөд шилжүүлэх боломжтой бөгөөд бэлэн эсэх талаар санаа зовохгүйгээр шууд дамжуулж болно. Гэсэн хэдий ч нарийн мэдрэмжүүд бас байдаг. Нэгдүгээрт, өгөгдөл дамжуулах нь хүлээн авагч болон илгээгчийн зангилааны тодорхой ачаалалтай холбоотой байдаг. Хэрэв хүлээн авагчийн зангилаа процессор дээр аль хэдийн ачаалал ихтэй байгаа бол та шинэ өгөгдөл хүлээн авахдаа үүнийг ачаалах ёсгүй. Хоёрдугаарт, илгээгч мастер дээр ганц ч үүр үлдэхгүй бол түүний бүх боолууд эдгээр үүрийг шилжүүлсэн мастер руу шууд очно. Асуудал нь эдгээр бүх боолууд өгөгдлийг нэг дор синхрончлохыг хүсэх болно. Хэрэв энэ нь бүрэн синхрончлол биш харин хэсэгчилсэн байвал та азтай байх болно. Үүнийг анхаарч, үүр шилжүүлэх, боолуудыг идэвхгүй болгох/шилжүүлэх үйлдлүүдийг нэгтгэнэ үү. Эсвэл танд аюулгүй байдлын хангалттай хэмжээ байгаа гэж найдаж байна.
• Шилжүүлгийн явцад та хаа нэгтээ слотоо алдсаныг олж мэдвэл яах ёстой вэ? Энэ асуудал танд нөлөөлөхгүй гэж найдаж байна, гэхдээ хэрэв ийм зүйл тохиолдвол кластер засах үйлдэл байна. Хамгийн багаар бодоход тэр зангилаанууд дээр үүрүүдийг санамсаргүй дарааллаар тараана. Би эхлээд кластераас тархсан үүртэй зангилааг арилгах замаар түүний ажиллагааг шалгахыг зөвлөж байна. Хуваарилагдаагүй слотуудын өгөгдөл аль хэдийн боломжгүй байгаа тул эдгээр слотуудын бэлэн байдлын талаар санаа зовоход хэтэрхий оройтсон байна. Хариуд нь үйл ажиллагаа нь тархсан слотуудад нөлөөлөхгүй.
• Өөр нэг ашигтай үйлдэл бол хяналт юм. Энэ нь зангилаа руу орж буй хүсэлтийн бүх жагсаалтыг бодит цаг хугацаанд харах боломжийг танд олгоно. Түүнээс гадна, та үүнийг grep болон шаардлагатай хөдөлгөөн байгаа эсэхийг олж мэдэх боломжтой.

Мастер бүтэлгүйтлийн процедурыг бас дурдах нь зүйтэй. Товчхондоо, энэ нь байгаа бөгөөд миний бодлоор энэ нь маш сайн ажилладаг. Гэсэн хэдий ч, хэрэв та мастер зангилаатай машин дээрх цахилгааны утсыг салгавал Редис шууд шилжиж, үйлчлүүлэгчид алдагдлыг анзаарахгүй байх болно гэж битгий бодоорой. Миний практикт шилжих нь хэдхэн секундын дотор тохиолддог. Энэ хугацаанд зарим өгөгдөл боломжгүй болно: мастерын боломжгүй байдал илэрсэн, зангилаанууд шинийг сонгоход санал өгдөг, боолууд солигдсон, өгөгдөл синхрончлогдсон. Энэ схем ажиллаж байгаа эсэхийг шалгах хамгийн сайн арга бол орон нутгийн дасгал хийх явдал юм. Зөөврийн компьютер дээрээ кластерыг өсгөж, хамгийн бага ачааллыг өгч, эвдрэлийг дуурайж (жишээлбэл, портуудыг хаах), шилжих хурдыг үнэл. Миний бодлоор энэ маягаар ганц хоёр өдөр тоглосны дараа л технологийн үйл ажиллагаанд итгэлтэй байж болно. За, эсвэл интернетийн тэн хагас нь ашигладаг программ хангамж ажилладаг байх гэж найдаж байна.

Тохиргоо

Ихэнхдээ тохиргоо нь багажтай ажиллаж эхлэхэд хамгийн түрүүнд шаардлагатай байдаг бөгөөд бүх зүйл ажиллахад та тохиргоонд хүрэхийг ч хүсдэггүй. Тохиргоонууд руу буцаж очоод анхааралтай үзэхийн тулд өөрийгөө хүчлэхийн тулд бага зэрэг хүчин чармайлт шаардагдана. Миний санах ойд бид тохиргоонд анхаарал хандуулаагүйн улмаас дор хаяж хоёр ноцтой алдаа гарсан. Дараахь зүйлүүдэд онцгой анхаарал хандуулаарай.

• завсарлага 0
  Идэвхгүй холболтууд хаагдах хугацаа (секундээр). 0 - хааж болохгүй
  Манай номын сан бүр холбоогоо зөв хааж чаддаггүй байсан. Энэ тохиргоог идэвхгүй болгосноор бид үйлчлүүлэгчдийн тооны хязгаарт хүрэх эрсдэлтэй. Нөгөөтэйгүүр, хэрэв ийм асуудал гарвал алдагдсан холболтыг автоматаар зогсоох нь үүнийг далдлах бөгөөд бид үүнийг анзаарахгүй байж магадгүй юм. Үүнээс гадна, та байнгын холболтыг ашиглах үед энэ тохиргоог идэвхжүүлэх ёсгүй.
• xy-г хадгалаарай, тийм ээ
  RDB агшин агшныг хадгалж байна.
  Бид RDB/AOF асуудлыг доор дэлгэрэнгүй авч үзэх болно.
• bgsave-ондоо бичихийг зогсоох-алдаа үгүй ​​& slave-serve-хуучирсан-өгөгдлүүд тийм
  Хэрэв идэвхжүүлсэн бол RDB хормын хувилбар эвдэрвэл мастер өөрчлөлтийн хүсэлтийг хүлээн авахаа болино. Хэрэв эзэнтэй холболт тасарсан бол боол хүсэлтэд үргэлжлүүлэн хариулах боломжтой (тийм). Эсвэл хариу өгөхөө болино (үгүй)
  Редис хулуу болж хувирсан байдалд бид сэтгэл хангалуун бус байна.
• repl-ping-sleve-period 5
  Энэ хугацааны дараа бид мастер эвдэрч, бүтэлгүйтлийн процедурыг хийх цаг болсон гэж санаа зовж эхэлнэ.
  Та худал эерэг болон бүтэлгүйтлийг өдөөх хооронд тэнцвэрийг гараар олох хэрэгтэй болно. Манай практикт энэ нь 5 секунд юм.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Бид бүтэлгүйтсэн хуулбарын хувьд яг ийм хэмжээний өгөгдлийг буферт хадгалах боломжтой. Хэрэв буфер дуусвал та бүрэн синхрончлох хэрэгтэй болно.
  Дадлагаас харахад илүү өндөр утгыг тогтоох нь дээр. Хуулбар яагаад хоцорч эхлэх олон шалтгаан бий. Хэрэв энэ нь хоцрох юм бол таны эзэн аль хэдийн үүнийг даван туулахад хэцүү байх магадлалтай бөгөөд бүрэн синхрончлол нь сүүлчийн сүрэл байх болно.
• maxclients 10000
  Нэг удаагийн үйлчлүүлэгчдийн хамгийн их тоо.
  Бидний туршлагаас харахад илүү өндөр үнэ цэнийг тогтоох нь дээр. Redis 10k холболтыг сайн зохицуулдаг. Зүгээр л систем дээр хангалттай залгуур байгаа эсэхийг шалгаарай.
• maxmemory-policy volatile-ttl
  Боломжтой санах ойн хязгаарт хүрсэн үед түлхүүрүүдийг устгах дүрэм.
  Энд гол зүйл бол дүрэм өөрөө биш, харин энэ нь хэрхэн тохиолдохыг ойлгох явдал юм. Редис нь санах ойн хязгаарт хүрсэн үед хэвийн ажиллах чадвартай гэж магтаж болно.

RDB болон AOF асуудлууд

Хэдийгээр Redis өөрөө бүх мэдээллийг RAM-д хадгалдаг ч өгөгдлийг дискэнд хадгалах механизм бас байдаг. Илүү нарийн, гурван механизм:

• RDB-snapshot - бүх өгөгдлийн бүрэн агшин агшин. SAVE XY тохиргоог ашиглан тохируулаад "Хэрэв ядаж Y товчлуурууд өөрчлөгдсөн бол X секунд тутамд бүх өгөгдлийн бүрэн агшин зургийг хадгал" гэж уншина.
• Зөвхөн хавсаргах файл - гүйцэтгэсэн дарааллаар нь үйлдлүүдийн жагсаалт. X секунд тутамд эсвэл Y үйлдэл бүрт шинэ ирж буй үйлдлийг файлд нэмнэ.
• RDB болон AOF нь өмнөх хоёрын хослол юм.

Бүх аргууд нь давуу болон сул талуудтай тул би бүгдийг нь жагсаахгүй, би зүгээр л миний бодлоор тодорхойгүй байгаа цэгүүдэд анхаарлаа хандуулах болно.

Нэгдүгээрт, RDB хормын хувилбарыг хадгалахын тулд FORK руу залгах шаардлагатай. Хэрэв маш их өгөгдөл байгаа бол энэ нь бүх Redis-ийг хэдхэн миллисекундээс секундын хугацаанд өлгөх боломжтой. Нэмж дурдахад систем нь ийм агшин зуурын санах ойг хуваарилах шаардлагатай бөгөөд энэ нь логик машин дээр RAM-ийн давхар нөөцийг хадгалах шаардлагатай болдог: хэрэв Redis-д 8 ГБ хуваарилагдсан бол виртуал машин дээр 16 ГБ байх ёстой. тэр.

Хоёрдугаарт, хэсэгчилсэн синхрончлолд асуудал гардаг. AOF горимд боол дахин холбогдсон үед хэсэгчилсэн синхрончлолын оронд бүрэн синхрончлолыг хийж болно. Яагаад ийм зүйл болсныг би ойлгохгүй байна. Гэхдээ үүнийг санах нь зүйтэй.

Эдгээр хоёр цэг нь хэрэв бүх зүйл аль хэдийн боолууд давхардсан бол дискэнд энэ өгөгдөл үнэхээр хэрэгтэй эсэх талаар бодоход хүргэж байна. Бүх боолууд бүтэлгүйтсэн тохиолдолд л өгөгдөл алдагдах ба энэ нь "ДС-д гал түймэр"-ийн түвшний асуудал юм. Буултын хувьд та зөвхөн боолууд дээр өгөгдөл хадгалахыг санал болгож болно, гэхдээ энэ тохиолдолд эдгээр боолууд гамшгийн нөхөн сэргээх явцад хэзээ ч эзэн болохгүй гэдгийг баталгаажуулах хэрэгтэй (түүний тулд тэдгээрийн тохиргоонд боолын тэргүүлэх тохиргоо байдаг). Бид өөрсдийнхөө хувьд тодорхой тохиолдол бүрт өгөгдлийг дискэнд хадгалах шаардлагатай эсэх талаар боддог бөгөөд ихэнхдээ "үгүй" гэж хариулдаг.

дүгнэлт

Эцэст нь хэлэхэд, би үүнийг огт сонсоогүй хүмүүст redis-cluster хэрхэн ажилладаг талаар ерөнхий ойлголт өгч чадсан гэж найдаж байна, мөн үүнийг ашиглаж байсан хүмүүст тодорхой бус зарим зүйлд анхаарлаа хандуулсан. урт хугацаанд.
Цаг зав гаргасанд баярлалаа, сэдэвтэй холбоотой санал хүсэлтийг үргэлж хүлээн авах боломжтой.

Эх сурвалж: www.habr.com