Prompt dan konteks
Reka bentuk pengendalian konflik acara untuk produk seperti Google Calendar. Pengguna mencipta, mengemas kini dan memadam acara dengan peserta, masa mula dan tamat, zon masa, peraturan perulangan, peringatan, keterlihatan dan pautan mesyuarat. Tindakan cipta atau kemas kini mesti mengesan konflik dan menyokong dasar tolak (reject), amaran-dan-teruskan (warn-and-proceed), atau ganti (override). Andaikan bacaan kelapangan/kesibukan (free/busy) jauh melebihi penulisan, pemeriksaan biasa memerlukan puluhan milisaat, dan kalendar peribadi hanya mendedahkan status sibuk.
Perkara yang dinilai oleh penemu duga
Jawapan yang kukuh mentakrifkan semantik konflik sebelum menamakan pangkalan data. Isyarat yang dinilai ialah peraturan selang separuh terbuka yang mengelakkan konflik palsu pada sempadan masa; model acara kanonikal yang diasingkan daripada indeks pertindihan; had RRULE, pengecualian dan materialisasi yang jelas; penukaran daripada peraturan masa tempatan kepada waktu mutlak (instants); laluan outbox atau CDC untuk indeks terbitan; dan strategi konkurensi bagi dua penulis yang menempah sumber yang sama. Hanya menyatakan "Kueri pangkalan data untuk mencari pertindihan" membiarkan mod kegagalan ini tidak terjawab.
Soalan penjelasan
- Adakah selang yang bersebelahan berkonflik? Jika tidak, gunakan selang separuh terbuka
[start, end). - Sejauh manakah siri berulang perlu dikembangkan? Siri tanpa had memerlukan tetingkap bergolek (rolling window) atau pengembangan semasa waktu kueri.
- Adakah mana-mana peserta yang sibuk menyekat acara, atau hanya peserta wajib atau penganjur? Ini menetapkan fan-out kueri dan dasar.
- Adakah tempahan berganda (double booking) ditolak, diberi amaran atau dibenarkan? Bilik persidangan dan kalendar peribadi mungkin menggunakan dasar yang berbeza.
- Patutkah pengguna lain melihat butiran penuh, selang sibuk atau tiada apa-apa? Ini menentukan ACL dan bentuk respons.
Jawapan 30 saat
"Saya mengekalkan rekod acara dan peserta kanonikal, serta indeks free-busy yang dipartisi mengikut kalendar. Konflik hanya wujud apabila existing.start < new.end dan new.start < existing.end; acara lapang (free) tidak menggunakan masa. Saya menyimpan peraturan perulangan dalam zon masa acara, mematerialisasikan ufuk terhad dan merekodkan pengecualian. Pemeriksaan versi atau kunci sumber melindungi penulisan, dan outbox mengemas kini indeks terbitan selepas komit. Respons hanya mendedahkan maklumat sibuk yang dibenarkan oleh ACL, manakala pemantauan merangkumi hanyutan (drift) indeks, binaan semula dan kelewatan pemberitahuan."
Penyelesaian langkah demi langkah
1. Tentukan masa dan predikat konflik
Wakilkan setiap kemunculan sebagai [start_utc, end_utc), sambil mengekalkan zon masa asal dan peraturan tempatan untuk paparan serta pengembangan. Dua kemunculan berkonflik tepat apabila a.start < b.end dan b.start < a.end. Oleh itu, 10:00–11:00 dan 11:00–12:00 adalah bersebelahan, bukan bertindih; tolak selang sifar panjang atau selang yang terbalik. Tukar acara sepanjang hari kepada sempadan dalam zon masa kalendar sebelum menggunakan predikat yang sama.
2. Asingkan model kanonikal daripada indeks ketersediaan
Lapisan kanonikal menyimpan acara, peserta, RRULE, pengecualian, ACL dan versi untuk pengeditan dan audit. Indeks ketersediaan hanya menyimpan calendar_id, sempadan kemunculan, status penghunian, ID acara dan label keterlihatan, diisih mengikut kalendar dan masa mula. Kueri konflik mengimbas tetingkap yang diminta dan bukannya JSON acara yang besar. Buat partisi mengikut bulan atau penyewa (tenant); kalendar yang mempunyai trafik tinggi mungkin memerlukan shard atau cache khusus.
3. Kendalikan perulangan dan pengecualian
Simpan RRULE gaya iCalendar dan kembangkan kemunculan untuk ufuk yang diminta. Materialisasi bergolek boleh menjana 90 hari akan datang dan melanjutkannya apabila sempadan semakin hampir; kueri yang lebih jauh dikembangkan atas permintaan dan hasilnya dicache. this occurrence, this and future, dan pengeditan keseluruhan siri mencipta rekod pengecualian atau versi siri baharu dan bukannya menulis semula kemunculan masa lalu. Setiap kemunculan mengambil bahagian secara bebas dalam semakan konflik dan pemberitahuan.
4. Laluan penulisan dan kawalan konkurensi
Sahkan masa, ACL dan dasar peserta, kemudian semak versi indeks semasa dalam transaksi yang sama. Kalendar peribadi boleh menggunakan versi optimistik dan meminta klien mencuba semula; bilik yang eksklusif sepenuhnya atau slot janji temu boleh menggunakan kunci bagi setiap sumber atau kekangan pengecualian pangkalan data. Komit acara dan rekod outbox bersama-sama; pengguna (consumers) mengemas kini indeks dan menghantar pemberitahuan. Jika indeks ketinggalan, baca daripada storan kanonikal atau tandakan jawapan sebagai tidak pasti—jangan sekali-kali mendakwa tiada konflik secara senyap.
5. Privasi, kueri dan skala
Susun respons mengikut lapisan ACL: pelihat yang dibenarkan melihat tajuk dan peserta, manakala pengguna lain hanya melihat selang sibuk dan acara peribadi dipaparkan sebagai blok legap. Petakan status lapang, tentatif dan luar pejabat kepada penghunian atau amaran mengikut dasar. Cache tetingkap masa yang biasa untuk trafik bacaan tinggi; sertakan versi kalendar atau tera air (watermark) pembatalan dalam kunci. Panggilan free/busy rentas organisasi memerlukan had masa tamat (timeouts) dan semantik hasil separa supaya satu kalendar luaran tidak memperlahankan semua peserta.
6. Ketekalan, pembaikan dan laluan kegagalan
Acara kanonikal ialah punca kebenaran tunggal (source of truth) dan indeks boleh dibina semula. Outbox atau CDC menjamin bahawa komit yang berjaya akhirnya menghasilkan kemas kini indeks; pengguna memproses versi secara idempoten supaya mesej lama tidak boleh menulis ganti mesej yang lebih baharu. Bandingkan kemunculan kanonikal secara berkala dengan cincangan (hash) atau kiraan indeks, bina semula kalendar apabila berlaku hanyutan, dan rekodkan julat yang terjejas. Cuba semula pemberitahuan yang gagal tanpa membatalkan (rollback) acara yang telah dikomitkan.
Contoh jawapan berkualiti tinggi
Mula-mula, saya akan mentakrifkan konflik dengan [start, end): hanya persilangan ketat yang berkonflik, acara bersebelahan tidak berkonflik, dan acara lapang tidak menggunakan ketersediaan. Model acara kanonikal menyimpan zon masa asal, RRULE, pengecualian, peserta dan ACL. Indeks kemunculan berasingan yang dipartisi mengikut kalendar hanya menyimpan sempadan, penghunian dan ID acara untuk imbasan tetingkap yang pantas. RRULE kekal dalam zon masa acara; saya mematerialisasikan 90 hari akan datang, mengembangkan julat yang lebih jauh atas permintaan, dan mewakili pengeditan kemunculan tunggal, kemunculan masa hadapan dan keseluruhan siri sebagai pengecualian atau versi yang jelas.
Laluan penulisan mengesahkan kebenaran dan dasar, kemudian menggunakan versi optimistik atau kunci sumber untuk pengeditan serentak. Acara dan rekod outbox dikomit bersama-sama; pengguna yang peka versi mengemas kini indeks secara idempoten dan menghantar pemberitahuan. Indeks adalah bersifat terbitan dan boleh dibina semula daripada data kanonikal, dan respons konflik ditapis mengikut ACL. Saya akan memberi amaran dan bukannya menyekat tempahan berganda pada kalendar peribadi, tetapi menggunakan kekangan pengecualian atau kunci bagi bilik. Saya akan memantau hanyutan indeks, versi lapuk, kependaman kueri dan masa tamat free/busy luaran.
Kesilapan lazim
- Kesilapan: menggunakan
start <= other.enduntuk pertindihan → acara bersebelahan menjadi konflik palsu → nyatakan peraturan selang separuh terbuka dan tolak acara sifar panjang yang tidak sah. - Kesilapan: mengembangkan siri berulang tanpa had pada setiap permintaan → kependaman dan beban kerja tidak mempunyai had atas → gunakan ufuk materialisasi bergolek dan pengembangan atas permintaan melangkaui ufuk tersebut.
- Kesilapan: menggunakan JSON acara penuh sebagai indeks konflik → operasi baca mengimbas medan yang besar dan membocorkan butiran peribadi → kekalkan unjuran masa dan penghunian serta tapis mengikut ACL.
- Kesilapan: membatalkan acara apabila kemas kini indeks gagal → punca kebenaran menjadi terikat dengan carian dan pemberitahuan → komit outbox, cuba semula secara tak segerak (asynchronous), dan sediakan mekanisme binaan semula.
- Kesilapan: mengambil kunci global untuk setiap kalendar → kalendar yang sibuk memperlahankan keseluruhan perkhidmatan → kunci hanya sumber yang eksklusif sepenuhnya dan gunakan pemeriksaan versi untuk kalendar biasa.
Soalan susulan dan respons
Bagaimanakah anda mencari masa apabila setiap peserta lapang?
Kueri selang sibuk bagi setiap peserta wajib untuk tetingkap sasaran, gabungkan selang pada garis masa yang sama, dan ambil pelengkap bagi kesatuan (union) mereka. Fan-out meningkat dengan bilangan peserta, jadi jalankan kueri secara selari, hadkan tetingkap, dan kembalikan hasil separa atau tidak pasti untuk kalendar yang tidak dibenarkan atau tamat masa dan bukannya mendedahkan butiran peribadi.
Mesyuarat berulang hanya berkonflik pada tarikh tertentu selepas perubahan DST. Bagaimanakah anda menyahpepijatnya?
Periksa pengecam zon masa RRULE, masa tempatan asal, versi pustaka pengembangan dan rekod pengecualian. Jangan tukar masa tempatan kepada UTC dan membuang maklumat zon masa sebelum mengembangkannya. Mainkan semula lekapan ujian (fixture) yang merentasi sempadan DST dan bandingkan masa paparan tempatan setiap kemunculan, sempadan UTC dan predikat pertindihan untuk memisahkan pepijat pengembangan daripada pepijat materialisasi indeks.
Apakah yang berubah apabila bilik tidak boleh ditempah berganda sama sekali?
Dua permintaan boleh melihat bilik sebagai lapang pada masa yang sama. Lindungi julat masa sumber dengan kekangan pengecualian pangkalan data, transaksi boleh bersiri (serializable transaction), atau kunci sumber pendek, dan kembalikan kemunculan yang berkonflik jika gagal. Kunci hanya merangkumi tetingkap komit, bukan cache; buat shard untuk sumber yang sibuk dan hadkan percubaan semula supaya satu baris gilir kunci tidak menyekat sumber kalendar lain.