429 нь хүсэлтийн хязгаар хүрснийг илэрхийлнэ. Хүлээх мэдээллийг хадгалж, холбоотой давталтыг зогсоогоод ижил гарц ашигладаг бусад ажлыг зохицуул.
Дахин шинэчлэх товч бүү дар
Синк дуусахгүй байхад хэрэглэгч товчийг олон удаа дарах хандлагатай. 429 ирсэн нь мэдэгдсэн бол автомат давталт болон гараар дахин эхлүүлэхийг түр зогсоо. Болсон цаг, Retry-After байсан эсэхийг тэмдэглэ. Үүлэн хэрэгсэл зөвхөн эргэлдэх дүрс бус, хүлээж байгаа төлөвийг ойлгомжтой харуулах хэрэгтэй. Хүсэлт үнэхээр зогссон эсэх, ямар нөхцөлд дараагийн оролдлого хийхийг үйлчилгээ үзүүлэгчээс асуу. Одоогийн босгыг өөрөө таах шаардлагагүй.
Одоогийн хариу дахь хугацааг ашигла
Binance REST баримт 429 болон 418 хариу дахь Retry-After-ийг секундээр хүлээх хугацаа гэж тайлбарладаг. Өчигдрийн хариуны утга өнөөдрийн тогтмол тоолуур биш. Зааврын жишээ таны хүсэлтийн бодит хариуг орлохгүй. Интерфэйс энэ мэдээллийг харуулахгүй бол хөгжүүлэгчээс нууцгүй төлөвийг ав. Хүлээх утга харагдахгүй байна гэдэг нь шууд дахин оролдож болно гэсэн үг биш. Бүтэн дансны хүсэлт өгөх шаардлагагүй.
Гарцын бүх ачааллыг бодолц
Үүлэн үйлчилгээ олон хэрэглэгч болон арын ажлыг нэг гарах хаягт нэгтгэж болно. Та хэдэн минут тутамд нэг удаа шинэчилсэн ч бусад ажлын бөөгнөрөлтэй давхцаж болно. REST-ийн зарим хязгаар IP-аар тооцогддог тул шинэ түлхүүр үүсгэх нь хамтын ачааллыг өөрчлөхгүй. Ямар хязгаар хүрсэн, ямар бүлэг ажил нөөц хэрэглэж байгааг оператороос асуу. Бүх асуудлыг ганц хэрэглэгчийн товч даралттай холбож болохгүй.
Анхны импорт ба өдөр тутмын шинэчлэлийг салга
Энэ бол платформын тогтмол параметр бус, ажлын зохион байгуулалтын санал юм. Анхны түүх таталтыг хяналттай хэсгүүдэд хувааж дараалалд оруул. Өдөр тутмын шинэчлэлт зөвхөн шинэ хүрээг уншиж, хүчинтэй хэвээр үр дүнг дахин ашиглаж болно. Хоёр ажлыг ижил өндөр давтамжаар өрсөлдүүлэх хэрэггүй. Хөгжүүлэгч интерфэйс бүрийн өртөг болон сүүлийн амжилттай байрлалыг хадгалах шаардлагатай. Үгүй бол алдаа бүрийн дараа эхнээс татаж, ижил ажлыг дахин хийнэ.
Давталтыг хэн хариуцахыг сонго
Хөтөч, үйлчилгээ, ажлын дараалал, сүлжээний сан бүгд тусдаа дахин оролдох тохиргоотой байж болно. Давхарга бүр цөөн оролдлоо гэж бодсон ч нийлээд олон хүсэлт болно. Дараагийн оролдлогыг аль хэсэг удирдах, бусад хэсэг түр зогсолтыг яаж мэдэхийг тогтоо. Сэргээх үед бүх хүлээж буй ажлыг нэгэн зэрэг явуулахгүй. Эхлэх цагийг тарааж, оролдлогын хязгаар болон зогсох нөхцөл тогтоо. Энэ загварыг бодит хэрэгжилт дээр шалгах ёстой.
Бусад алдааг тусдаа ангил
Цаг буруу, гарын үсэг хүчингүй, унших эрх дутуу бол өөрийн гэсэн засвар шаардана. Зүгээр хүлээгээд дахин оролдох нь эдгээрийг зөв болгохгүй. Сүлжээ тасрах болон серверийн алдаа өөр ангилалд орно. Энэ заавар холболт ба унших ажлыг авч үзэж байгаа бөгөөд арилжааны хүсэлтийг автоматаар давтах арга өгөхгүй. HTTP төлөв болон API алдааны кодыг тусад нь хадгалснаар хүлээх үү, тохиргоо засах уу гэдгийг ялгаж чадна.
Сэргээхээс өмнө хуримтлагдсан ажлыг хар
Хүлээх нөхцөл хангагдсаны дараа нэг шаардлагатай унших үйлдлийг хяналттай ажиллуулж, дараа нь бусад ажлыг аажмаар сэргээ. Өгөгдлийн шинэ байдал, дарааллын хэмжээ, алдааны ангиллыг ажигла. Ижил хязгаар шууд дахин хүрвэл давталтыг зогсоож, хамтын төсвийг дахин тооц. Хязгаарыг үргэлжлүүлэн зөрчих нь IP хоригт хүргэж болно. Түлхүүр эсвэл хаягийг байнга солих нь ачааллын зохион байгуулалтыг засахыг орлохгүй.
Нотолгоо авахдаа ачаалал нэмэхгүй
Хэрэглэгч сүүлийн амжилт, анхны алдаа, гараар шинэчилсэн тоо, түүхийн импорт ажиллаж байсан эсэхийг тэмдэглэж болно. Ижил хэрэгслийн бусад хэсэг шинэчлэгдэхээ больсон эсэхийг мөн хар. Нотлохын тулд хүсэлтийн давтамжийг өсгөж болохгүй. Хөгжүүлэгч хүлээлтийн эхлэл төгсгөл, ажлын дугаар, интерфэйсийн ангилал, сэргээх шийдвэрийг нууцгүй логт үлдээнэ. Дараа нь төлөвийн тайлбар болон хуваарийг сайжруулбал ижил явдал бүрд хүнээс тусламж авах хэрэгцээ багасна.
Бүх эхлүүлэх цэг болон хүлээлтийн дэлгэцийг шалга
Хуудас нээх, гараар шинэчлэх, хуваарьт унших, импорт, эрүүл төлөв шалгах ажлыг жагсаа. Самбар сул мэт байхад далд шалгалт нөөц хэрэглэсээр байж болно. Арын үйлчилгээ хүлээж байх үед шинэ таб ижил ажлыг бие даан дахин эхлүүлэх ёсгүй. Програмын зан төлөвийг хяналттай дотоод орчинд зохиомол хариугаар шалгаж болно; бодит платформын хязгаарыг зориуд өдөөх шаардлагагүй. Энэ нотолгоог жинхэнэ алдааны логоос ялгаж хадгал. Симуляци таны програм нөхцөлийг хэрхэн боловсруулахыг батлахаас биржийн одоогийн нөөц эсвэл бодит хариуны хүлээлтийг батлахгүй.