Сервер бүрт биш, нэг удаа ажилладаг сануулга

Манай үйл ажиллагааны сануулгуудын нэг — нийтлэгдсэн аппын хэрэглэгчийн "кредит бага" гэх сануулга — өдөрт хамгийн ихдээ нэг удаа хүрэх ёстой. Нэг үдээс хойш таван удаа ирсэн. Шалтгаан нь: API-ийн хуулбар бүр аль сануулгыг аль хэдий нь явуулснаа өөрийн ой санамжинд хадгалдаг байсан тул хоёр сервер хоёр удаа явуулж, deploy бүр тэр санамжийг устгаж сануулгыг дахин явуулах боломж олгодог байв. Ижил хэв маяг нэг фоно ажлыг хоёр удаа хийдэг болгож байсан. Одоо хоёулаа хуваалцсан сангаар зохицуулдаг, мөн тэр сан бэлэн биш байхад аюулгүй талд унадаг.

Шинж тэмдэг

Mythex баг нэг зүйлд анхаарах шаардлагатай үед сануулга илгээдэг: үйлчилгээ унасан, ажил зогссон, нийтлэгдсэн аппын хэрэглэгчийн кредит дуусах дөхсөн. Сануулга бүр dedupe цонхтой — ижил сануулгыг зөвхөн нэг удаа илгээх хугацаа. Кредит бага байх сануулгын хувьд тэр цонх 24 цаг.

Нэг үдээс хойш ижил сануулгын таван хуулбар ирсэн нь цонх барихгүй байсныг харуулсан. Илүү муу нь тэд хос хосоороо ирсэн, ойролцоогоор 11 минутын зөрүүтэй.

Яагаад болсон бэ

Манай alerts багц dedupe-гээ ой санамжид хадгалдаг байсан: "сануулгын түлхүүр → сүүлд хэзээ илгээсэн" гэсэн хүснэгт, ажиллаж буй процесс дотор. Энэ нь нэг процесс л байж, хэзээ ч дахин эхлэхгүй бол ажилладаг. Продакшн дээр ийм биш:

• Хоёр API replica. Продакшн хоёр API хуулбартай. Тус бүр өөрийн хүснэгттэй, тиймээс тус бүр сануулгыг нэг удаа илгээсэн. Энэ бол хос нь.
• Deploy. Deploy бүр хоёр replica-г шинэ процессоор солиж, хоосон хүснэгттэй болгодог. Deploy-ийн дараа сануулга дахин явсан, огт илгээгээгүй мэт.

Хос сануулгын хоорондох ~11 минутын зай нь энэ сануулгыг өсгөдөг ажлаас гарсан. Тэр ажил хоёр replica дээр ажилладаг бөгөөд цоож авдаг тул replica-ууд ээлжилж хожиж, тус бүр өөрийн ээлж ирэхэд сануулгыг өсгөдөг байв.

Мөн ижил кодонд хоёр дахь, бүр чимээгүй алдаа байсан. Хүснэгт үүрд өсөхөөс сэргийлэхийн тулд 500 түлхүүрт хүрэхэд өөрийгөө цэвэрлэдэг байсан — цонхныхоо хугацаанаас үл хамааран 15 минутаас хуучин бүх оруулгыг устгана. Ачаалал өндөр үед 24 цагийн dedupe дөрөвний нэг цаг хүртэл хүчинтэй байж магадгүй байв.

Засвар

Сануулга бүрт нэг хуваалцсан бичлэг

API сануулга илгээхээс өмнө dedupe түлхүүрээ Redis-д нэхдэг болсон — хоёр replica-ийн хамтдаа холбогддог, API дахин эхлэхэд үлддэг хуваалцсан ой санамжийн сан. Нэхэлт нь "энэ түлхүүрийг зөвхөн байхгүй бол тавь, цонхны дараа дуусгавар болго" гэсэн нэг үйлдэл. Хамгийн түрүүн нэхсэн replica сануулгыг илгээнэ; нөгөө нь түлхүүрийг эзэлсэн олдоод чимээгүй байна. Deploy-ийн дараа шинэ процесс тэр түлхүүр байсаар байгааг олно.

Түлхүүр болон цонх нь alerts багцын нэг дүрмээс гардаг, одоо хоёр давхарга хоорондоо "ижил сануулга" гэж юуг хэлэхээ зөрчихгүй байхаар хуваалцдаг.

Бүтэлгүйтэхэд нээлттэй талд унана, хаалттай биш

Хамгийн чухал шийдвэр нь Redis холбогдохгүй байхад юу хийх вэ гэдэг байв. Бид сануулгыг ямар ч тохиолдолд илгээхээр шийдсэн. Redis унасан эсвэл 1.5 секундын дотор хариулахгүй бол сануулга явна. Давхардсан сануулга бол чимээ шуу; хасагдсан сануулга бол хэн нэгэнд хэлэгдээгүй зүйл.

Хамгийн ноцтой сануулга P0-ийг dedupe огт барихгүй.

Оруулга бүр өөрийн цонхтойгоо

Alerts багцын өөрийн ой санамжийн dedupe-д оруулга бүр одоо цонх дуусах хугацаагаа хадгалдаг, мөн цэвэрлэх нь цонх нь дууссан оруулгыг л устгана. 24 цагийн түлхүүр өөр хэдэн ч сануулга ирсэн ч 24 цаг хадгалагдана.

Ижил алдаа, өөр газар

Ижил хэв маяг фоно ажлын нэг хэсгийг хоёр дахин болгосон: манай workspace бүрийн статусын бүртгэлийг sandbox үйлчилгээ нийлүүлэгчийнхтэйгээ нийцүүлдэг эвлэрүүлэх ажил. Давтагдах бүр бүртгэлд байгаа бүх sandbox-ыг жагсаадаг — продакшн дээр мянга гаруй, ойролцоогоор таван секунд — мөн ажиллаж буй болон түр зогссон төслүүд. Хоёр replica үүнийг хоёр минут тутамд ажиллуулдаг байв.

Түүний бичилт idempotent — хоёр удаа ажиллуулахад нэг удаагийнхтай ижил үр дүн гардаг — тул юу ч эвдрээгүй. Зөвхөн хоёр дахин ажил байсан. Одоо хоёр минутын цонх бүр Redis-д нэхэгддэг, манай usage хэмжигч яг л өөрийнхөө цонхыг нэхдэгтэй адилхан, мөн зөвхөн нэхсэн replica л ажлыг ажиллуулна. Redis холбогдохгүй бол ажил ямар ч тохиолдолд ажиллана: ажлыг хоёр дахин хийх нь хор хөнөөлгүй, харин хийхгүй орхих нь хор хөнөөлтэй.

Яаж туршсан бэ

Тестүүд бодит тохиргоог загварчилдаг. Тэд сануулгын модулийг хоёр удаа ачаалж, хоёр тусдаа "replica" гэж үзэж, хоёуланг нь нэг хуваалцсан сан руу чиглүүлж, хоёулаас ижил сануулга өсгөөд, "deploy-ийн дараа" дүрслэх гурав дахь шинэ хуулбарыг ачаалж дахин өсгөнө. Яг нэг сануулга илгээгдэнэ. Бусад тест нь өөр builder-ийн сануулга явсаар байгааг, P0 хоёр replica-аас илгээгдэж байгааг, мөн сан унасан эсвэл хугацаанаас хэтэрч удаашрахад ч сануулга явсаар байгааг шалгана. Цэвэрлэх засварт өөрийн тест бий: 24 цагийн түлхүүр 20 минутын дараа ирэх 600 өөр сануулгыг давж амьдардаг.

Эвлэрүүлэх ажлын хувьд, нэг цонхонд хоёр replica зэрэг tick хийж, мөн гурав дахь tick хийхэд нэг жагсаалт үүснэ.

Бидний сурсан зүйл

• Ой санамжийн төлөв процесс бүрт хамаарна. Сервер хооронд үнэн байх ёстой зүйл — "нэг удаа илгээсэн", "нэг удаа ажилласан" — хуваалцсан газар байх ёстой.
• Deploy бол дахин эхлэлт. Дараагийн дахин эхлэх хүртэл л үлддэг төлөв нь энгийн ажлын өдөр ч үлддэггүй.
• Аль талаараа унахаа шийд. Сануулгын хувьд хуваалцсан сан унах нь илүү сануулга гэсэн үг байх ёстой, цөөн биш.
• Тохиолдлыг биш хэв маягийг хар. Сануулга бол чанга тохиолдол байсан; давхардсан эвлэрүүлэх ажил бол ижил алдаа, чимээгүйхэн ажлыг үрсэн.

Энэ нь Mythex-ийн дотроос харагдахгүй. Платформыг хэрхэн тогтвортой байлгадгийн талаар deploy-ийг 502 алдаагүй болгосон нь ба дутуу swap файл гэсэн нийтлэлүүдийг үзнэ үү. Хэд хэдэн хуулбар дээр үйлчилгээ ажиллуулах санаанд шинэ бол, сервер гэж юу вэ гарын авлага үндсийг тайлбарлана.