Систем дотор нэг хэсэг нь ажил үүсгэж, өөр нэг хэсэг нь тэр ажлыг боловсруулдаг гэж бодъё. Ажил үүсгэж байгаа хэсгийг producer, ажил боловсруулж байгаа хэсгийг consumer гэж нэрлэдэг.
Хоёр хэсэг яг ижил хурдтай ажиллах албагүй. Producer зарим үед consumer-ээс хурдан ажиллаж болно. Энэ үед боловсруулагдаагүй ажил түр хугацаанд хүлээгдэж болно. Гэхдээ producer байнга илүү хурдан ажиллаад байвал хүлээгдэж байгаа ажил улам нэмэгдэнэ.
Эндээс гол асуудал гарч ирнэ. Систем нэг дор өөрийн боловсруулж чадахаас илүү их ажил хүлээж аваад байвал тэр илүүдэл ажил хаа нэг газар хуримтлагдах хэрэгтэй болно.
Боловсруулагдаагүй ажлыг ихэвчлэн queue эсвэл buffer дотор түр хадгалж болно. Энэ нь богино хугацаанд маш хэрэгтэй. Жишээ нь ачаалал хэсэг хугацаанд огцом нэмэгдээд дараа нь буувал consumer өмнө нь хуримтлагдсан ажлыг дараа нь боловсруулж чадна.
Гэхдээ асуудал удаан үргэлжилбэл queue байнга өснө.
Queue өсөх тусам ажил боловсруулах хүртэлх хүлээлт нэмэгдэнэ. Memory илүү их ашиглагдана. Зарим тохиолдолд connection, thread зэрэг бусад нөөцүүд ч дуусаж болно. Эцэст нь систем шинэ ажил хүлээж авах боломжгүй болох эсвэл бүр зогсож болно.
Тиймээс зөвхөн "илүү их ажил хадгалъя" гэдэг нь жинхэнэ шийдэл биш.
Backpressure гэдэг нь ийм үед ажлын урсгалыг хянах арга юм.
Гол санаа нь маш энгийн: ажил боловсруулж байгаа тал удаан байвал ажил үүсгэж байгаа тал мөн үүнийг мэдэрч, хурдаа тохируулах хэрэгтэй.
Өөрөөр хэлбэл consumer-ийн чадвар хүрэхгүй байхад producer өмнөх шигээ хязгааргүй ажил үүсгэсээр байх ёсгүй.
Ингэснээр систем "хэдий хэмжээний ажил орж ирж байна вэ?" гэдгээс гадна "би тэр ажлыг хэр хурдан боловсруулж чадаж байна вэ?" гэдгийг харгалзан үздэг.
Ажил ерөнхийдөө нэг чиглэлд явна:
Producer → Consumer
Producer ажил үүсгэнэ, consumer ажил боловсруулна.
Гэхдээ consumer хэт их ачаалалтай болох үед түүний хязгаарлалт producer талд нөлөөлнө:
Producer → Consumer
← хязгаарлалт
Энэ нөлөө downstream талаас upstream руу буцаж байгаа учраас backpressure гэж нэрлэдэг.
Тиймээс backpressure гэдэг нь зүгээр нэг "удаашруулах" гэсэн үг биш. Consumer-ийн боловсруулах чадвар producer-ийн ажил үүсгэх хурдыг хянахад нөлөөлж байгаа гэсэн санаа юм.
Систем илүүдэл ажилтай болсон үед заавал нэг л арга хэрэглэх шаардлагагүй.
Producer түр хүлээж болно. Ингэснээр шинэ ажил шууд нэмэгдэхгүй.
Мөн producer-ийн хурдыг багасгаж болно. Ингэснээр consumer өөрийн хурдаар ажлаа нөхөх боломжтой болно.
Зарим систем шинэ ажлыг түр хүлээж авахгүй байж болно. Энэ нь системийг улам их ачааллаас хамгаална.
Зарим тохиолдолд зарим ажлыг хаяж болно. Энэ нь бүх өгөгдөл заавал хадгалагдах шаардлагагүй системд ашигтай байж болно.
Ямар арга сонгох нь тухайн системийн шаардлагаас хамаарна. Хамгийн чухал нь систем өөрийн чадахаас илүү ажлыг хяналтгүйгээр авч байх ёсгүй.
Buffer болон backpressure хоёрыг андуурах нь амархан.
Buffer нь илүүдэл ажлыг түр хадгалдаг. Харин backpressure нь илүүдэл ажил хэт их болж эхлэхэд урсгалыг хянадаг.
Тиймээс buffer нь "түр хадгалах" асуудлыг шийддэг бол backpressure нь "хэт их ажил орж ирж байна" гэсэн асуудлыг шийддэг.
Хэрэв ажил байнга боловсруулах чадвараас их орж ирдэг бол buffer-ийг улам томруулах нь асуудлыг шийдэхгүй. Зөвхөн buffer дүүрэх хугацааг уртасгана.
Rate limiting нь урьдчилан тогтоосон хязгаараар хүсэлт эсвэл ажлын хурдыг барьдаг.
Жишээ нь систем тодорхой хугацаанд тодорхой хэмжээний хүсэлтээс илүүг авахгүй гэсэн дүрэмтэй байж болно.
Backpressure-ийн хувьд гол анхаарал нь одоогийн боловсруулах чадвар дээр байна. Consumer удааширвал upstream талд нөлөөлж, ажлын урсгал мөн өөрчлөгдөнө.
Товчхондоо rate limiting нь "хэдийг зөвшөөрөх вэ?" гэсэн асуудалд, backpressure нь "одоо байгаа хүчин чадлаараа хэр их ажлыг даах вэ?" гэсэн асуудалд илүү хамаатай.
Олон service-тэй системд нэг service нөгөөгөөсөө хурдан эсвэл удаан байх нь хэвийн.
Нэг service хэвийн ажиллаж байсан ч түүний ашигладаг database эсвэл өөр service удааширч болно. Тэгэхэд тухайн service өмнөх шигээ хурдан ажиллах боломжгүй болно.
Хэрэв upstream service үүнийг тооцохгүйгээр ажилласаар байвал боловсруулагдаагүй ажил хуримтлагдана.
Тиймээс distributed system-д нэг хэсгийн удаашрал бусад хэсгүүдэд хэрхэн нөлөөлөхийг хянах шаардлагатай. Backpressure нь энэ нөлөөг хянах нэг арга юм.
Backpressure-ийн зорилго нь системийг заавал хурдан болгох биш.
Зорилго нь систем өөрийн чадахаас илүү ажлыг хүлээж аваад нөөцөө дуусгах, queue-гээ хязгааргүй өсгөх, улмаар бүхэлдээ доголдохоос хамгаалах явдал юм.
Зарим үед backpressure хэрэглэснээр системийн хурд багасаж, зарим ажил илүү удаан хүлээгдэж болно. Гэхдээ энэ нь системийг бүхэлд нь хяналтгүйгээр ачаалуулахтай харьцуулахад илүү хяналттай байдал юм.
Backpressure-ийг хамгийн энгийнээр "ажил боловсруулах тал удаан байвал ажил үүсгэх талд буцаад нөлөөлж, ажлын урсгалыг тохируулах" гэж ойлгож болно.
Үндсэн асуудал нь producer ба consumer-ийн хурд өөр байгаагаас эхэлдэг. Хэрэв producer байнга хурдан байвал боловсруулагдаагүй ажил хуримтлагдана. Queue эсвэл buffer энэ ажлыг түр хадгалж чадна, гэхдээ асуудал удаан үргэлжилбэл өөрсдөө асуудал болж эхэлнэ.
Backpressure нь энэ үед урсгалыг хянаж, системийн боловсруулах чадвартай илүү ойр байлгахыг зорьдог.
Тиймээс backpressure-ийн хамгийн чухал санаа нь "илүү их ажлыг яаж хадгалах вэ?" биш, "системийн одоогийн хүчин чадлаас илүү ажил орж ирэхэд яаж зөв хариу өгөх вэ?" гэдэгт оршдог.
