Өргөтгөх боломжтой захиалгын системийг бий болгох: Өгөгдлийн сангийн үндсэн загварууд болон уян хатан API загварууд

Захиалгын системийг бий болгох үүрэгтэй хөгжүүлэгч бүр энэ нь хуурамч сорилт гэдгийг хурдан ойлгодог. Өнгөц харахад энэ нь зүгээр л хэрэглэгч, нөөц (цаг хугацааны интервал эсвэл суудал гэх мэт) болон цагийг холбодог. Бодит байдал дээр энэ нь өгөгдлийн бүрэн бүтэн байдал, бодит цаг хугацааны уялдаа холбоо, бизнесийн логикийн өндөр эрсдэлтэй зохион байгуулалт бөгөөд ачааллын үед өө сэвгүй ажиллах ёстой. Буруу зохион бүтээсэн систем нь давхар захиалга, үйлчлүүлэгчдийг бухимдуулж, үйл ажиллагааны хар дарсан зүүдэнд хүргэдэг. Mewayz зэрэг платформ дээрх 138 мянга гаруй бизнес эрхлэгчдийн хувьд найдвартай захиалгын систем нь тансаг зүйл биш юм; Энэ нь үйлчилгээ, томилгоо, хөрөнгийн удирдлагын үйл ажиллагааны тулгуур юм. Энэхүү гарын авлага нь таны эхний 100 захиалгаас эхний сая хүртэлх системийг бий болгоход шаардлагатай мэдээллийн сангийн үндсэн загвар болон API загваруудыг задалсан болно.

Өгөгдлийн сангийн үндсэн схем: Хүснэгтээс илүү

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

Үндсэн объектуудыг тодорхой загварчилж эхэл. Санаа зовоосон асуудлуудыг ингэж салгах нь уян хатан байдалд чухал ач холбогдолтой. Таны Нөөц хүснэгт нь хурлын өрөө, стилистийн цаг, түрээсийн машин зэрэг юуг захиалж болохыг тодорхойлдог. Нөөц бүр энгийн (9-ээс 5 хүртэл, Даваа-Баасан) эсвэл төвөгтэй (захиалгат цаг, тасарсан огноо, захиалгын хоорондох завсрын хугацаа) байж болох Хүртээмжтэй байдлын дүрэмтэй холбоотой байх ёстой. Боломжтой байдлыг нөөцөөс тусад нь хадгалах нь динамик хуваарь гаргах, илүү хялбар шинэчлэлт хийх боломжийг олгодог.

Үндсэн аж ахуйн нэгжийн харилцаа

Системийн зүрх нь Хэрэглэгчид, Нөөц, Цагийн зай-ын хоорондох уулзвар юм. Бат бөх Захиалга хүснэгт нь зөвхөн эхлэх болон дуусах огноог хадгалах ёсгүй. Үүнд 'баталгаад'-аас давсан утгатай статусын талбар байх ёстой— pending_payment, tantative, cancelled, no_show гэж бод. Энэ нь хэрэглэгч төлбөр тооцоогоо хийж байх хооронд слотыг түр барих гэх мэт баялаг ажлын урсгалыг бий болгодог. Нэмж хэлэхэд, source (вэб, мобайл, API), залилан илрүүлэхэд зориулсан ip_address гэх мэт мета өгөгдлийг, мөн өөдрөг зэрэгцэн удирдахад зориулсан хувилбар дугаар эсвэл updated_at цагийн тэмдэг зэргийг багтаасан бөгөөд бид үүнийг дараа хэлэлцэх болно.

Зэрэгцээ байдлыг зохицуулах: Тэмцээний нөхцөл байдлын асуудал

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

• Гутрангуй түгжигдэхүүн: Энэ нь захиалгын гүйлгээний хугацаанд нөөц эсвэл цагийн интервал дээр эгнээний түвшний түгжээг байрлуулахад оршино. Энэ нь энгийн бөгөөд бүрэн бүтэн байдлыг баталгаажуулдаг боловч дамжуулах чадварыг эрс багасгаж, өндөр зэрэглэлийн үед мухардмал байдалд хүргэж болзошгүй юм. Энэ нь мэдээллийн сангийн мөрөнд "Бүү саад бол" гэсэн тэмдэг тавихтай адил юм.
• Өөдрөг Зэрэгцээ Хяналт (OCC): Вэб хэмжээний програмуудад илүү тохиромжтой. Энд та эгнээ түгжихгүй. Үүний оронд та шинэчлэлт хийхдээ хувилбарын дугаар эсвэл цагийн тэмдгийг шалгана уу. Хэрэглэгч үүнийг үзсэнээс хойш нөөцийн төлөв өөрчлөгдөөгүй тохиолдолд л захиалга үргэлжилнэ. Хэрэв зөрчил илэрсэн бол хэрэглэгчдэд мэдэгдэх бөгөөд дахин оролдох шаардлагатай. Энэ загвар нь маш өргөн цар хүрээтэй боловч зөрчилдөөнийг шийдвэрлэх логикийг сайтар бодож үзэх шаардлагатай.
• Мэдээллийн сангийн түвшний хязгаарлалт: Хамгийн найдвартай арга бол схемээ зохиох бөгөөд ингэснээр давхар захиалга хийх боломжгүй юм. resource_id, start_time, end_time (статус != 'цуцлагдсан' байх нөхцөлтэй) хослол дээр UNNIQUE хязгаарлалтыг ашиглах нь өгөгдлийн сан өөрөө давхцал үүсгэсэн бүх оруулгыг үгүйсгэнэ гэсэн үг юм. Энэ нь хэрэгжилтийг өгөгдлийн сангийн систем рүү шилжүүлдэг бөгөөд энэ нь маш сайн.

Idempotent болон Resilient API-г зохион бүтээх

Таны API бол гарц юм. Сүлжээний доголдол, мобайл програмын доголдол, эсвэл тэвчээргүй хэрэглэгчид "Илгээх" гэсэн товчлуурыг хоёр удаа дарах нь таны захиалгын эцсийн цэг хүчингүй байх ёстой гэсэн үг бөгөөд нэг хүсэлтийг олон удаа хийх нь нэг удаа хийхтэй адил нөлөө үзүүлдэг. Энэ нь төлбөртэй холбоотой үйл явцын хувьд тохиролцох боломжгүй.

Үйлчлүүлэгчээс захиалга үүсгэх хүсэлт бүрийн хамт өвөрмөц idempotency_key (жишээ нь, UUID-ээр үүсгэгдсэн үйлчлүүлэгч тал) илгээхийг шаардах замаар idempotency-ийг хэрэгжүүлээрэй. Таны API энэ түлхүүрийг захиалгын ID-тай холбож хадгалдаг. Ижил түлхүүр бүхий давхардсан хүсэлт нь урьд нь үүсгэсэн захиалгын дэлгэрэнгүй мэдээллийг буцаан өгч, давхар төлбөр болон захиалга хийхээс сэргийлнэ. Энэ загвар нь төлбөр тооцоо, хуваарь боловсруулдаг Mewayz API модулиуд зэрэг санхүүгийн болон гүйлгээний системийн найдвартай байдалд гол үүрэг гүйцэтгэдэг.

Тусгайлах боломжтой захиалгын API-ийн түлхүүр нь зөвхөн хурд биш юм; энэ нь урьдчилан таамаглах чадвар юм. Тодорхой, тууштай алдааны код бүхий idempotent төгсгөлийн цэг нь бүтэлгүйтлийн үед давхардсан гүйлгээг үүсгэдэг ахиу хурдтай цэгээс илүү үнэ цэнэтэй юм.

Төрийн менежмент ба амьдралын мөчлөгийн дэгээ

Захиалга бол төрийн машин юм. Энэ нь хүлээгдэж буй-аас батлагдсан руу дууссан эсвэл цуцлагдсан руу шилжинэ. Шилжилт бүр нь баталгаажуулах имэйл илгээх, нөөцийн хуанли шинэчлэх, буцаан олголтыг боловсруулах эсвэл аудитын мөрийг бүртгэх зэрэг тодорхой үйлдлүүдийг өдөөх ёстой. Үүнийг сайн тодорхойлсон үйлчилгээний давхарга эсвэл үйл явдалд тулгуурласан архитектур ашиглан хэрэгжүүлээрэй.

Жишээ нь, захиалга цуцлагдах үед таны үйлчилгээ:

1. Цуцлах бодлогыг баталгаажуулах (жишээ нь, "24 цагийн мэдэгдэл шаардлагатай").
2. bookings.status-г цуцлагдсан болгож шинэчил.
3. booking.cancelled үйл явдал гарга.
4. Төлбөрийн гарцаар дамжуулан хэсэгчлэн буцаан олголт хийх, цуцлах имэйл илгээх, сонголтоор хүлээлгийн жагсаалтад мэдэгдэл илгээх боломжтой сонсогчдод олгоорой.

Mewayz-ийн модульчлагдсан үйлдлийн системтэй төстэй энэхүү салангид загвар нь системийг өргөтгөх боломжтой болгодог. Шинэ SMS мэдэгдэл нэмэх эсвэл CRM-тэй нэгтгэх нь захиалгын үндсэн логикийг хөндөхгүйгээр шинэ үйл явдал сонсогч нэмэх явдал юм.

Гүйцэтгэлийн хувьд асуулгын загварууд

Таны захиалгын хэмжээ нэмэгдэхийн хэрээр үр ашиггүй асуулга нь таны хяналтын самбар болон тайланг мөлхөх болно. Нийтлэг үйлдлүүдэд "5-р сард X нөөцийн бүх захиалгыг олох" болон "хэрэглэгчийн удахгүй болох уулзалтуудыг харуулах" багтдаг.

Индексжүүлэх стратеги хамгийн чухал. (resource_id, start_time) болон (user_id, start_time) дээрх нийлмэл индексүүд зайлшгүй шаардлагатай. Том хүрээг хамарсан огнооны хүрээний асуулгын хувьд захиалга хүснэгтээ огноогоор (жишээ нь, сараар) хуваахыг бодоорой. Энэ нь мэдээллийн санд сканнердсан бүх хуваалтыг хурдан гаргах боломжийг олгоно. Цаашилбал SELECT *-аас зайлсхий. Санах ой болон сүлжээний ачааллыг багасгахын тулд зөвхөн тухайн харагдац эсвэл үйлдэлд шаардлагатай баганыг татаж авч асуулгадаа тодорхой бичээрэй.

Алхам алхмаар: Захиалгын найдвартай урсгалыг хэрэгжүүлэх нь

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

1-р алхам: Баталгаажуулалт, эрх мэдлийг шалгах хүсэлт гаргах

Ирж буй ачааллыг баталгаажуулна уу (хэрэглэгчийн_id, нөөцийн_id, хүссэн цаг хугацаа). idempotency_key-г зориулалтын хүснэгт эсвэл Redis кэштэй харьцуулан нэн даруй шалгана уу. Хэрэв тохирол байгаа бол хадгалсан хариултыг даруй буцаана уу (Одоо байгаа захиалгын өгөгдөлтэй HTTP 200 OK).

Алхам 2: Боломжтой байдлын баталгаажуулалт

Слот сул байгаа эсэхийг шалгах асуулга. Энэ нь одоо байгаа батлагдсан болон хүлээгдэж буй захиалга, мөн нөөцийн бэлэн байдлын дүрмийг харгалзан үзэх ёстой. Боломжтой бол өгөгдлийн сангийн хязгаарлалтыг ашиглан ганц атомын асуулга ашиглана уу. Жишээ нь: <код>ХААНА resource_id = захиалгаас COUNT(*) СОНГОХ? БА tsrange(эхлэх_цаг, дуусах_цаг) && tsrange(?, ?) БА төлөв БАЙГҮЙ БАЙНА ('цуцлагдсан', 'үзүүлээгүй').

Алхам 3: Атомын гүйлгээ

Бүтээлийг мэдээллийн сангийн гүйлгээнд боож өгнө үү. Үүнд:
1. Боломжтой эсэхийг дахин шалгах (эцсийн шалгалт).
2. Шинэ захиалгын бүртгэлийг pending_payment эсвэл баталгаажсан статустай оруулна уу.
3. Амжилттай захиалгын ID-г idempotency_key-тэй холбосон бичлэг оруулна уу.
4. Гүйлгээ хийх. Хэрэв ямар нэг алхам амжилтгүй болвол гүйлгээ бүхэлдээ буцаагдах ба хагас төлөв үлдэхгүй.

4-р алхам: Бүтээлийн дараах үйлдлүүд

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

Илүү өргөн бизнесийн үйлдлийн системтэй нэгтгэх

Захиалгын систем нь вакуум орчинд ховор байдаг. Түүний жинхэнэ үнэ цэнэ нь бусад бизнесийн функцуудтай нэгтгэгдсэн үед нээгддэг. Захиалга үүсгэх үед CRM-д харилцагч үүсгэх, нэхэмжлэх үүсгэх, хүний ​​нөөцийн модульд багийн гишүүний календарийг хаах эсвэл флот менежерээс тээврийн хэрэгслийн хуваарь гаргах боломжтой. Энэ бол Захиалгын модуль нь бусад 207 платформтой автоматаар синк хийдэг Mewayz зэрэг платформуудын арын модульчлагдсан философи юм.

Хөгжүүлэгчдийн хувьд энэ нь таны захиалгын системийн өгөгдлийн загвар, үйл явдлыг нэгтгэх цэгүүдийг харгалзан төлөвлөх гэсэн үг юм. Гол үйл явдлуудын (booking.created, booking.updated) вэб дэгээг нээснээр бусад системд хариу үйлдэл үзүүлэх боломжтой. Mewayz-д $4.99/модуль/сард санал болгодог шиг тодорхой, сайн баримтжуулсан API-г хангах нь түншүүд болон дотоод багуудад автоматжуулсан дагах SMS кампанит ажлаас гадна нягтлан бодох бүртгэлийн программ хангамжтай синк хийх хүртэл захиалгат ажлын урсгалыг бий болгох боломжийг олгодог.

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

Байнга асуудаг асуултууд

Давхар захиалгаас урьдчилан сэргийлэх хамгийн чухал мэдээллийн баазын хязгаарлалт юу вэ?

Нөөцийн_id, эхлэх_цаг, дуусах_цаг (идэвхтэй статусын хувьд шүүсэн) хосолсон ӨГӨГДӨЛ хязгаарлалт нь хамгийн бат бөх бөгөөд өгөгдлийн сангийн хөдөлгүүрийн түвшинд давхцаж буй захиалга хийхээс сэргийлдэг бөгөөд энэ нь атом шинж чанартай бөгөөд найдвартай.

Яагаад захиалгын API-д таних чадваргүй байдлын түлхүүр шаардлагатай вэ?

Үйлчлүүлэгч амжилтгүй болсон хүсэлтийг дахин оролдвол (жишээ нь сүлжээний завсарлагааны улмаас) зөвхөн нэг захиалга үүсгэж, хэрэглэгчээс нэг удаа төлбөр ногдуулахыг баталгаажуулж, давхардлаас сэргийлж, төлбөрийн үйл явцад хэрэглэгчийн итгэлийг бий болгодог.

Зэрэгцээ байдлыг хянахын тулд би өөдрөг эсвэл гутранги түгжээг ашиглах ёстой юу?

Вэбд суурилсан захиалгын ихэнх системүүдийн хувьд өргөтгөх боломжтой байх үүднээс өөдрөг зэрэгцэн ажиллах хяналтыг (OCC) илүүд үздэг. Гутранги түгжээ нь маш бага зэрэгцэлтэй хувилбаруудын хувьд илүү хялбар байж болох ч хэрэглэгчийн эзлэхүүн нэмэгдэхийн хэрээр саад тотгор болдог.

Захиалгын систем дэх цагийн бүсийг хэрхэн зохицуулах ёстой вэ?

Өөрийн мэдээллийн санд бүх цагийн тэмдэглэгээг зохицуулсан бүх нийтийн цагаар (UTC) үргэлж хадгал. Найдвартай цагийн бүсийн сангуудыг ашиглан зөвхөн програмын үзүүлэнгийн давхарга дээр хэрэглэгчийн эсвэл нөөцийн орон нутгийн цагийн бүс рүү хөрвүүлэх боломжтой.

Захиалгын амьдралын мөчлөгийн менежментийн үйл явдалд тулгуурласан архитектурын давуу тал нь юу вэ?

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