Temu duga reka bentuk sistem: Mereka bentuk perkhidmatan kuota dan pemeteran penggunaan berbilang penyewa (multi-tenant)

1. Soalan dan konteks

Sebuah platform SaaS mengendalikan permintaan API, tugas serentak (concurrent jobs), dan storan untuk banyak penyewa. Penyewa mungkin mempunyai kuota pada peringkat projek, organisasi, dan sumber; sesetengahnya ditetapkan semula setiap minit manakala yang lain terkumpul sepanjang tempoh pengebilan. Pihak perniagaan mahukan keputusan penerimaan (admission) yang pantas dan data penggunaan yang boleh dipercayai untuk amaran, audit, dan pengebilan. Reka bentuk perkhidmatan semakan kuota dan pemeteran, termasuk had ketat (hard limits), ambang lembut (soft thresholds), dasar overage, dan tingkah laku kegagalan pelbagai wilayah.

2. Perkara yang dinilai oleh penemu duga

• Sama ada anda membezakan had peruntukan, kadar, dan konkurensi serta mentakrifkan skop dan semantik penetapan semulanya.
• Sama ada anda mengasingkan penerimaan segerak (synchronous admission) daripada peristiwa penggunaan tak segerak, pengagregatan pengebilan, dan penyelarasan.
• Sama ada anda mengendalikan tempahan atomik, kunci keidempotenan, peristiwa pendua atau luar urutan, penyewa hangat (hot tenants), dan versi konfigurasi.
• Sama ada anda menerangkan ketekalan rentas wilayah, degradasi, jejak audit, amaran, dan perubahan manual yang selamat.

3. Penjelasan yang perlu ditanya sebelum menjawab

1. Adakah kita mengehadkan kadar permintaan, tugas serentak, kapasiti storan, atau penggunaan kumulatif dalam tempoh pengebilan?
2. Adakah skopnya organisasi, penyewa, projek, pengguna, atau tika sumber (resource instance), dan adakah had diwarisi ke bawah hierarki?
3. Apabila kuota habis, adakah sistem perlu menolak, memasukkan ke dalam giliran (queue), mendegradasi, atau membenarkan overage untuk pengebilan?
4. Adakah ketekalan kukuh pelbagai wilayah diperlukan, dan berapakah kelewatan peristiwa yang boleh diterima sebelum penyelarasan?

4. Rangka jawapan 30 saat

Saya akan membahagikan sistem kepada katalog kuota, enjin penerimaan segerak, lejar tempahan, saluran paip peristiwa penggunaan tak segerak, pertanyaan agregat, dan amaran audit. Setiap permintaan membawa penyewa, projek, jenis sumber, dan ID permintaan yang idempoten. Enjin penerimaan menyemak kuota kadar, konkurensi, dan kumulatif di bawah versi konfigurasi serta membuat tempahan secara atomik apabila diperlukan; penyiapan atau pembatalan akan melepaskan tempahan dan mengeluarkan peristiwa penggunaan. Peristiwa membawa ID unik, masa peristiwa, dan dimensi; pengguna (consumers) mengagregat secara idempoten, kemudian menyelaraskan tempoh tersebut dengan lejar dan input pengebilan. Bagi setiap sumber, pilih penulisan autoritatif atau penjualan lebih terikat (bounded oversell) merentasi wilayah; lindungi had ketat semasa kegagalan dan kembalikan isyarat yang boleh dicuba semula apabila wajar.

5. Jawapan terperinci langkah demi langkah

Langkah 1: Takrifkan model dan skop kuota

Katalog kuota menyimpan jenis sumber, skop, unit, tetingkap, had, kebolehlarasan, dan versi konfigurasi. Kuota kadar mengehadkan penggunaan dalam satu tetingkap masa, kuota konkurensi mengehadkan operasi yang berjalan serentak, dan kuota peruntukan mengehadkan sumber yang telah diperuntukkan. Had organisasi boleh menjadi siling tertinggi; tempahan penyewa dan projek mesti berada dalam baki kapasiti induk supaya semakan bebas tidak terlebih menjual (oversell) jumlah keseluruhan.

Langkah 2: Reka bentuk semakan segerak dan tempahan atomik

Laluan segerak memiliki fakta yang mempengaruhi penerimaan: pembilang tetingkap semasa, tempahan aktif, dan versi konfigurasi. Gunakan kunci hangat terpecah (sharded hot keys) atau storan berketekalan kukuh yang dipisahkan mengikut penyewa bagi penyewa yang aktif (hot tenant). Sesuatu tempahan mesti menyemak baki kapasiti dan meningkatkan jumlah yang ditempah secara atomik, mengelakkan dua permintaan serentak daripada menggunakan baki yang sama. Tugas berdurasi panjang menerima ID tempahan; penyiapan, pembatalan, dan tamat tempoh adalah idempoten.

checkAndReserve(tenant, dimensions, amount, requestId, configVersion)
  verify configVersion is active
  if requestId already committed: return previous decision
  atomically check remaining quota and add reservation
  persist reservation with expiry and requestId
  return reservationId and retryAfter

Langkah 3: Nyahtambat peristiwa penggunaan daripada pengagregatan pemeteran

Kejayaan, kegagalan, pembatalan, dan tamat tempoh harus mengeluarkan peristiwa. Setiap peristiwa membawa penyewa, projek, sumber, kuantiti, unit, masa peristiwa, dan ID peristiwa yang unik. Dengan penghantaran sekurang-kurangnya sekali (at-least-once delivery), pengguna (consumers) menyahduplikasi mengikut ID peristiwa; peristiwa luar urutan menggunakan tetingkap masa peristiwa atau lejar yang boleh dimainkan semula. Agregat memberi perkhidmatan kepada pertanyaan, amaran ambang, dan input pengebilan, tetapi tidak boleh menulis ganti lejar tempahan segerak.

Langkah 4: Kendalikan overage, perubahan kuota, dan keadilan

Tolak atau masukkan ke dalam giliran apabila kuota ketat habis; ambang lembut harus mencetuskan amaran. Sama ada overage dibenarkan mestilah tetapan produk yang jelas dengan pelaku yang dibenarkan dan peraturan harga. Sebelum menurunkan kuota, periksa tempahan sedia ada supaya kerja yang telah diterima tidak kehilangan kapasiti secara tiba-tiba. Penyewa hangat tidak boleh menggunakan perkongsian shard secara berlebihan; had konkurensi penyewa, baldi token (token buckets), dan giliran adil (fair queues) boleh melindungi penyewa lain. Permintaan peningkatan kuota harus mengikut peraturan kelulusan atau automasi serta mengekalkan versi lama untuk audit.

Langkah 5: Tingkah laku pelbagai wilayah, pemulihan, dan penyelarasan

Jika had ketat mesti tepat secara global, halakan sumber kepada satu pihak berkuasa (authority) atau gunakan storan yang disokong konsensus. Jika ketersediaan lebih penting, peruntukkan belanjawan serantau dan nyatakan maksimum oversell. Semasa pemecahan wilayah (regional partition), tolak keputusan had ketat yang tidak boleh dibuat dengan selamat; had lembut boleh didegradasi buat sementara waktu kepada penghantaran amaran sahaja. Selepas pemulihan, mainkan semula peristiwa tak boleh ubah (immutable) dan rekod tempahan, bandingkan keputusan penerimaan, agregat, dan hasil pengebilan, serta baiki perbezaan dengan peristiwa pampasan dan bukannya mengedit sejarah.

6. Contoh jawapan berkualiti tinggi

Saya akan mengasingkan katalog kuota, enjin penerimaan segerak, lejar tempahan, saluran paip pemeteran tak segerak, dan pertanyaan audit. Katalog mentakrifkan skop organisasi, penyewa, dan projek serta had kadar, konkurensi, dan peruntukan. Penerimaan menggunakan dimensi penyewa dan ID keidempotenan untuk semak-dan-tempah secara atomik; tugas yang panjang mendapat ID tempahan dan menjadikan penyiapan, pembatalan, dan tamat tempoh sebagai idempoten. Peristiwa kejayaan dan kegagalan memasuki saluran paip at-least-once; pengguna menduplikasi mengikut ID peristiwa dan mengagregat mengikut masa peristiwa untuk amaran dan pengebilan, tanpa menulis ganti lejar penerimaan. Bagi setiap sumber, tingkah laku pelbagai wilayah adalah sama ada autoritatif atau penjualan lebih terikat. Semasa kegagalan, lindungi kuota ketat; selepas pemulihan, mainkan semula dan selaras, dengan setiap perubahan dan pampasan boleh diaudit.

7. Kesilapan biasa

• Menggunakan satu pembilang yang dikongsi → penyewa hangat memperlahankan semua orang → pecahkan (shard) mengikut penyewa dan kuat kuasakan had yang adil.
• Membiarkan agregat tak segerak menentukan penerimaan → kelewatan peristiwa menyebabkan oversell → kekalkan lejar tempahan atomik sebagai punca kebenaran penerimaan.
• Hanya membincangkan had kadar → tugas panjang dan storan menggunakan kapasiti tanpa had → modelkan had kadar, konkurensi, dan peruntukan.
• Hanya menyahduplikasi ID permintaan → peristiwa yang dicuba semula dikira dua kali → gunakan kunci keidempotenan berasingan untuk tempahan dan peristiwa penggunaan.
• Menulis ganti baki semasa menurunkan kuota → kerja yang telah diterima ditolak secara tiba-tiba → buat versi konfigurasi dan periksa tempahan sedia ada.

8. Soalan susulan dan jawapan

Soalan susulan 1: Mengapa tidak bergantung hanya pada pembilang Redis?

Pembilang berguna untuk statistik tetingkap kependaman rendah, tetapi tempahan atomik rentas sumber, tamat tempoh tugas, versi konfigurasi, dan audit memerlukan lejar yang lebih lengkap. Pembilang hanya boleh menjadi laluan pantas apabila rekod autoritatif dan proses pembinaan semula wujud.

Soalan susulan 2: Bagaimanakah anda mengelakkan peristiwa penggunaan pendua daripada dibilkan dua kali?

Berikan setiap peristiwa satu ID unik yang stabil. Pengguna menulis rekod penyahduplikasian dan agregat dalam satu transaksi, atau menggunakan operasi atomik yang setara. Agregat kekal boleh dikira semula; pengebilan menggunakan versi agregat yang disahkan dan mengekalkan peristiwa pampasan.

Soalan susulan 3: Adakah anda terus menerima tugas semasa pemecahan (partition) pelbagai wilayah?

Jeda atau halakan sumber kepada pihak berkuasa bagi kuota ketat yang tidak boleh dijual lebih. Bagi kuota lembut dengan belanjawan oversell terikat, terima daripada peruntukan serantau dan rekod risiko maksimum. Pilihan ini bergantung pada kerugian perniagaan dan objektif ketekalan.

Soalan susulan 4: Bagaimanakah anda menguji perkhidmatan kuota?

Lakukan ujian beban terhadap penyewa hangat, tempahan serentak, peristiwa pendua dan luar urutan, penurunan taraf konfigurasi, pemecahan wilayah, main semula pengguna, dan pertukaran tempoh. Sahkan bahawa had ketat tidak pernah dilanggar, operasi idempoten adalah stabil, dan lejar, agregat, serta pengebilan menumpu (converge) selepas pemulihan.