Temu Duga Reka Bentuk Sistem: Bagaimana Anda Mengasingkan Penyewa Bising dan Menjadualkan Secara Adil?

Gesaan dan konteks

Teras utamanya ialah pengasingan prestasi dan keadilan, bukan sekadar menambah tenantId. Perkhidmatan ini menerima kerja laporan tak segerak yang menggunakan baris gilir, CPU, imbasan pangkalan data, storan objek, dan lebar jalur muat turun. Lonjakan akhir bulan menjadikan beberapa penyewa bising (noisy). Mulakan dengan mentakrifkan objektif perkhidmatan, kemudian jelaskan apa yang dikongsi dan apa yang diasingkan.

Andaikan penyewa hanya boleh membaca datanya sendiri, laporan boleh disiapkan secara tak segerak, dan kelewatan sementara adalah lebih baik daripada kebocoran rentas penyewa. Penyewa perusahaan mungkin mempunyai pelan, rantau, dan dasar pengekalan yang berbeza; pematuhan, pemastautinan data, dan kapasiti khusus adalah kekangan ketat yang perlu dijelaskan. Keadilan tidak bermakna pemprosesan yang sama rata selama-lamanya: keutamaan kontrak dan keselamatan boleh mempunyai pemberat yang jelas dan boleh diaudit.

Senario ini sesuai untuk temu duga bahagian belakang (backend), platform, SRE, dan reka bentuk sistem. AWS membentangkan shuffle sharding sebagai corak pengasingan berbilang penyewa yang teras, manakala bahan reka bentuk sistem awam menganggap pengasingan penyewa, kuota, dan jiran bising sebagai kebimbangan reka bentuk yang lazim. Soalan ini memfokuskan pada penjadualan dan radius impak berbanding set ciri SaaS yang lengkap.

Perkara yang dinilai oleh penemu duga

Pertama, bolehkah anda mengenal pasti setiap permukaan pengasingan? Identiti penyewa, kerja, baris gilir, pekerja, sambungan pangkalan data, cache, storan objek, dan egress semuanya mungkin dikongsi; mengasingkan ingress sahaja membolehkan hingar menembusi bahagian hiliran.

Kedua, bolehkah anda membezakan kuota, penjadualan adil, dan pengasingan tegar? Baldi token penyewa mengehadkan volum, baris gilir adil memilih siapa yang berjalan seterusnya, dan shard atau kolam khusus mengehadkan kegagalan. Mereka menyelesaikan masalah yang berbeza.

Ketiga, bolehkah anda menaakul tentang kompromi kos antara penyewa besar dan kecil? Dedikasi penuh mewujudkan kapasiti terbiar dan beban operasi; perkongsian penuh mewujudkan pertikaian. Jawapan yang kukuh memberikan peringkat dan pencetus penghijrahan.

Keempat, bolehkah anda membuktikan pengasingan? Ukur kependaman, penolakan, usia baris gilir, penggunaan kuota, percubaan semula, dan pengguguran mengikut penyewa, baris gilir, dan lapisan sumber berbanding bergantung pada purata global.

Soalan penjelasan

• Apakah objektif perkhidmatan? Takrifkan p95, masa menunggu maksimum, kadar kejayaan, dan ketersediaan serantau untuk kerja interaktif dan tak segerak.
• Kerja manakah yang diutamakan? Peringkat kontrak, kerja manusia yang mendesak, laporan berjadual, dan penerokaan mungkin mempunyai pemberat yang berbeza.
• Apakah sempadan data dan sumber? Adakah sesetengah penyewa memerlukan pangkalan data, rantau, kunci, stor objek, atau kolam pekerja yang berasingan?
• Bagaimanakah lonjakan dan kuota jangka panjang diukur? Kadar penyerahan, kerja serentak, bait yang diimbas, masa CPU, storan, atau egress?
• Bagaimanakah pengguna melihat giliran dan penolakan? Anggaran penyiapan, panduan percubaan semula, penjelasan kuota, dan pelaporan pentadbir hendaklah dinyatakan secara eksplisit.

Jawapan 30 saat

“Saya terlebih dahulu mentakrifkan objektif kependaman, kejayaan, keserentakan, dan pengasingan data bagi setiap penyewa dan pelan, memisahkan kuota penyerahan, keserentakan berjalan, dan belanjawan hiliran. Get laluan mengesahkan penyewa, mengesahkan saiz kerja dan kunci kedegilan (idempotency key), serta menulis ke baris gilir tahan lasak. Penjadual menggunakan baldi token bagi setiap penyewa dan baris gilir adil berwajaran; penyewa yang bising atau dikawal selia boleh dipindahkan ke kolam pekerja khusus atau shuffle-sharded. Imbasan pangkalan data, cache, storan objek, dan egress turut dimeterkan. Semasa beban lampau, tolak atau tangguhkan kerja berkeutamaan rendah dengan status yang benar dan pembatalan. Sahkan dengan ujian kebenaran rentas penyewa, suntikan hingar, latihan kegagalan, serta penegasan p99, radius impak, dan pemulihan bagi setiap penyewa.”

Jawapan langkah demi langkah

Langkah 1: Takrifkan sumber dan objektif perkhidmatan

Bahagikan laporan kepada penyerahan, giliran, pertanyaan, penjanaan, penulisan objek, dan muat turun. Takrifkan objektif yang boleh diukur untuk setiap satu, seperti p95 penyerahan, usia baris gilir, masa penyiapan, kejayaan muat turun, dan pengasingan. Peruntukkan belanjawan CPU, memori, imbasan, sambungan, slot baris gilir, permintaan objek, dan egress dan bukannya hanya menamakan kiraan pekerja.

Langkah 2: Wujudkan konteks penyewa yang dipercayai

Identiti penyewa datang daripada kelayakan yang disahkan dan kebenaran pelayan, bukan tenantId yang dibekalkan oleh pemanggil. Kerja, mesej baris gilir, pertanyaan, laluan objek, kunci cache, dan token muat turun membawa konteks yang disahkan. Hadkan medan, tetingkap masa, dan imbasan maksimum supaya penyewa yang sah tidak dapat menghabiskan sumber kongsi dengan pertanyaan yang luas.

authenticated principal
  -> authorize tenant and report definition
  -> assign quota class and priority
  -> enqueue {tenantId, taskId, costEstimate, deadline}
  -> every worker and storage call re-checks tenant scope

Langkah 3: Pilih peringkat pengasingan

Penyewa kecil boleh berkongsi baris gilir dan pekerja dengan kuota penyewa, had keserentakan, dan penjadualan adil. Penyewa bervolum tinggi atau dikawal selia boleh menerima baris gilir khusus, partition, skema pangkalan data, kunci penyulitan, atau kolam pekerja. AWS shuffle sharding memetakan setiap penyewa kepada gabungan pekerja supaya kegagalan satu pekerja menjejaskan penyewa yang lebih sedikit; ia mengehadkan radius impak sambil mengekalkan beberapa kecekapan perkongsian.

Langkah 4: Reka bentuk kuota dan penjadualan adil

Gunakan baldi token penyerahan untuk lonjakan ingress, had keserentakan untuk kerja dalam proses, dan belanjawan kos untuk bait yang diimbas atau CPU. Baris gilir adil berwajaran atau baris gilir maya bagi setiap penyewa menghalang seorang penyewa daripada menduduki setiap pekerja; dalam penyewa, susun mengikut keutamaan, tarikh akhir, dan usia. Penolakan hendaklah dalam keadaan beban lampau sementara atau kuota yang boleh diterangkan, bukan jemputan untuk mencuba semula selama-lamanya.

Langkah 5: Lindungi sumber hiliran

Mulakan kerja hanya selepas penjadual mempunyai belanjawan pangkalan data, cache, dan storan objek. Gunakan replika bacaan, tetingkap masa, dan had imbasan untuk laporan; bahagikan hasil mengikut penyewa dan rantau serta keluarkan kebenaran muat turun jangka pendek. Jika sambungan, cache, benang (threads), dan egress kekal dikongsi secara global, ingress yang adil tidak dapat menghalang kebuluran sumber di hiliran. Berikan kebergantungan kritikal had keserentakan dan baris gilir terhad mereka sendiri.

Langkah 6: Kendalikan lonjakan, kegagalan, dan pemulihan

Kekalkan keadaan kerja, syot kilat kuota, kunci kedegilan, dan pembatalan. Pekerja yang ranap boleh mencuba semula, tetapi penulisan hasil mestilah idempoten melalui versi atau kunci hasil. Apabila kebergantungan tidak tersedia, jedakan hanya kelas yang terjejas, kekalkan usia baris gilir dan anggaran, serta elakkan ribut percubaan semula yang menyeluruh. Semasa pemulihan, tingkatkan kemasukan secara berperingkat mengikut penyewa dan keutamaan sambil memerhatikan p99, ralat, dan kuota berbanding melepaskan semua tunggakan sekali gus.

Langkah 7: Skalakan, hijrahkan, dan sahkan

Skalakan daripada pemprosesan berguna, usia baris gilir, penggunaan sumber, dan pemberat penyewa, bukan purata CPU sahaja. Apabila memindahkan penyewa daripada kolam kongsi ke shard khusus, kekalkan keadaan kerja idempoten dan laluan hasil, beralih secara beransur-ansur, dan kekalkan keupayaan gulung balik (rollback). Uji kebenaran rentas penyewa, suntikan hingar, kegagalan satu pekerja, pangkalan data yang perlahan, pemulihan baris gilir, pembatalan, dan penghijrahan penyewa besar; setiap ujian menyemak sama ada penyewa lain masih memenuhi objektif mereka.

Contoh jawapan berkualiti tinggi

“Saya akan membahagikan laporan kepada penyerahan, giliran, pertanyaan, penjanaan, storan, dan muat turun serta mentakrifkan objektif kependaman, kejayaan, dan pengasingan untuk setiap satu. Identiti penyewa datang daripada konteks yang disahkan dan pelayan mengesahkan semula takrifan laporan; medan penyewa dalam permintaan adalah input, bukan sempadan. Kerja memasuki baris gilir tahan lasak dengan penyewa, anggaran kos, kunci kedegilan, dan tarikh akhir.

Penyewa kecil berkongsi pekerja, tetapi masing-masing mempunyai kuota kadar penyerahan, dalam proses, bait yang diimbas, dan storan. Penjadualan adil berwajaran dengan keutamaan usia menghalang lonjakan akhir bulan daripada menduduki setiap pekerja. Penyewa bervolum tinggi atau dikawal selia boleh dipindahkan ke baris gilir khusus, partition, atau kolam pekerja shuffle-sharded untuk mengurangkan radius impak kegagalan pekerja atau penyewa hangat. Sambungan pangkalan data, cache, storan objek, dan egress turut menerima belanjawan penyewa atau kelas.

Sekiranya berlaku lebihan, saya mengembalikan keadaan baris gilir atau beban lampau sementara yang jujur dan menyokong pembatalan; klien tidak boleh mencuba semula selama-lamanya. Pekerja menggunakan kunci hasil yang idempoten, manakala kegagalan kebergantungan menjedakan kerja yang terjejas sahaja dan pemulihan ditingkatkan secara berperingkat mengikut penyewa dan keutamaan.

Saya akan mengesahkan dengan ujian akses rentas penyewa, lonjakan penyewa tunggal, kerosakan pekerja dan pangkalan data, main semula baris gilir, pembatalan, dan latihan penghijrahan. Saya akan memeriksa p99, usia baris gilir, kadar penolakan, penggunaan sumber, dan penegasan kebocoran bagi setiap penyewa. Saya akan memperluaskan kolam pengasingan atau melaraskan pemberat hanya selepas kedua-dua penyewa kecil dan peringkat tinggi memenuhi objektif mereka.”

Kesilapan lazim

• Mempercayai tenantId daripada permintaan → Pemanggil boleh memalsukan skop → Perolehnya daripada pengesahan dan semak semula di hiliran.
• Memberikan setiap penyewa satu pekerja tetap → Kapasiti terbiar bertambah dan kegagalan masih merebak → Gunakan peringkat risiko dan shard gabungan apabila diperlukan.
• Mengehadkan kadar penyerahan sahaja → Kerja dalam proses masih menggunakan sumber hiliran → Hadkan keserentakan, kos, dan kebergantungan juga.
• Menggunakan purata global untuk keadilan → Kependaman ekor (tail latency) penyewa kecil hilang → Rekod p95, p99, baris gilir, dan penolakan mengikut penyewa.
• Mencuba semula selama-lamanya di bawah beban lampau → Penguatan percubaan semula melumpuhkan perkhidmatan → Kembalikan status eksplisit, percubaan semula idempoten, dan belanjawan kongsi.
• Menambah pekerja tanpa belanjawan pangkalan data → Kebergantungan menjadi hambatan (bottleneck) → Peruntukkan belanjawan setiap lapisan sumber dari hujung ke hujung.
• Melepaskan semua tunggakan semasa pemulihan → Puncak baharu terbentuk → Gunakan histerisis dan kemasukan beransur-ansur.
• Bermigrasi tanpa keadaan idempoten → Kerja mendua atau hasil hilang → Gunakan versi, kunci hasil, dan gulung balik.

Soalan susulan dan respons

Soalan susulan 1: Bagaimanakah perbezaan shuffle sharding berbanding sharding biasa?

Sharding biasa biasanya meletakkan penyewa pada satu shard tetap, jadi kegagalan shard menjejaskan semua penyewa di situ. Shuffle sharding memetakan setiap penyewa kepada gabungan pekerja dengan pertindihan terhad, mengurangkan set yang terjejas oleh kegagalan satu pekerja. Ia menambah kebimbangan mengenai kapasiti, pengimbangan semula, dan penghijrahan penyewa hangat.

Soalan susulan 2: Bolehkah penyewa premium memintas penjadualan adil?

Berikannya kontrak yang jelas atau pemberat berbayar, tetapi kekalkan jumlah kapasiti, pengasingan, dan sempadan keselamatan. Simpan belanjawan untuk kerja premium sambil merekodkan objektif perkhidmatan minimum untuk penyewa biasa; “keutamaan” tidak boleh bermakna preemption tanpa had.

Soalan susulan 3: Bagaimana jika satu laporan mengimbas keseluruhan pangkalan data?

Anggarkan kos semasa penghuraian dan perancangan, perlukan julat masa, hadkan bait dan keserentakan, serta pisahkan, tangguhkan, atau tolak kerja yang melebihi belanjawan. Kolam pangkalan data yang lebih besar sekadar memindahkan tekanan ke dalam storan dan bukanlah penyelesaian yang lengkap.

Soalan susulan 4: Bagaimanakah anda membuktikan tiada kebocoran rentas penyewa?

Bina matriks akses daripada prinsipal yang disahkan merentasi API, main semula baris gilir, pekerja, cache, laluan objek, eksport, dan alat pentadbir. Tambah ujian negatif supaya konteks yang hilang atau dipalsukan dinafikan secara lalai, dan tegaskan label dan kandungan penyewa pada hasil sebenar.