Temu Duga Reka Bentuk Sistem: Mereka Bentuk Perkhidmatan Penyimpanan dan Penyegerakan Fail Awan

Prompt dan senario yang berkenaan

Reka bentuk perkhidmatan penyimpanan fail awan dan penyegerakan berbilang peranti yang serupa dengan Dropbox atau Google Drive. Ia mempunyai 50 juta pengguna berdaftar dan 5 juta pengguna aktif harian. Setiap pengguna menyimpan purata 10 GB data logikal. Sistem ini menerima 100 juta versi fail baharu setiap hari, dengan 4 MB kandungan baharu atau diubah bagi setiap versi. Trafik puncak adalah lima kali ganda daripada purata harian. Fail boleh bersaiz sehingga 50 GB, peranti dalam talian harus melihat penciptaan, kemas kini, pemindahan, dan pemadaman dalam masa 5 saat, dan perkhidmatan metadata menyasarkan ketersediaan 99.99%.

Skala, kependaman, ketersediaan, dan sasaran saiz ketulan 4 MiB adalah andaian temu duga, bukan komitmen prestasi awam daripada mana-mana produk penyimpanan. Skop ini merangkumi muat naik, muat turun, pemindahan boleh sambung semula, pemulihan versi, penyegerakan berbilang peranti, penyuntingan luar talian, salinan konflik, perkongsian mudah, dan pemadaman. Penyuntingan kolaboratif peringkat aksara, penggabungan dokumen Office secara semantik, sistem kebenaran perusahaan yang lengkap, dan penulisan rentas rantau aktif-aktif berada di luar skop.

Prompt reka bentuk sistem awam pada tahun 2026 masih menggunakan Dropbox, Google Drive, atau perkhidmatan penyegerakan fail generik untuk bertanya tentang pemetulan fail besar, penyegerakan delta, versi, operasi luar talian, dan konflik. Dokumentasi storan objek rasmi juga menetapkan nilai kejuruteraan bagi muat naik berbilang bahagian: bahagian boleh dimuat naik secara selari dan bahagian yang gagal boleh dicuba semula secara berasingan, manakala bahagian yang terbiar memerlukan pembatalan atau pembersihan kitaran hayat. Temu duga ini bertujuan menguji pemisahan pemindahan kandungan daripada keadaan ruang nama dan menutup gelung ketepatan di sekitar pemulihan dan pemadaman, bukannya menghafal seni bina dalaman satu syarikat.

Perkara yang dinilai oleh penemu duga

Pertama, bolehkah calon memisahkan kandungan fail daripada metadata? Jujukan bait yang besar tergolong dalam storan objek yang tahan lasak, murah, dan tidak boleh ubah. Nama, hubungan induk-anak, versi semasa, penanda pemadaman, dan kursor penyegerakan memerlukan penulisan bersyarat dan perubahan yang tersusun. Meletakkan fail 50 GB dalam pangkalan data hubungan, atau menggunakan kunci objek sebagai model direktori lengkap, menjadikan kemas kini, pemindahan, komit transaksi, dan pemulihan rapuh.

Kedua, adakah terdapat satu titik penerbitan yang jelas untuk sesuatu muat naik? Klien boleh memuat naik ketulan yang hilang secara selari, tetapi versi hanya kelihatan selepas pelayan mengesahkan setiap ketulan dan mengemas kini currentVersionId secara atomik bersama log perubahan. Jika tidak, metadata mungkin merujuk kepada kandungan yang hilang, atau bait yang dimuat naik mungkin tidak akan dapat dilihat oleh pengguna.

Ketiga, bolehkah protokol penyegerakan bertahan daripada pemberitahuan yang hilang, pendua, dan tidak teratur? Mesej tolak hanyalah petunjuk bahawa sesuatu telah berubah. Peranti mesti menggunakan kursor yang tahan lasak untuk menarik perubahan yang berwibawa. Peranti yang berada di luar talian selama berhari-hari, klien yang dipasang semula, dan kursor yang telah tamat tempoh semuanya memerlukan laluan pemulihan. Sambungan WebSocket bukanlah punca kebenaran mutlak (source of truth).

Keempat, adakah semantik keserentakannya jujur? Apabila dua peranti luar talian mengubah suai fail binari biasa yang sama daripada versi lama yang sama, perkhidmatan generik tidak dapat menggabungkannya secara andal. Komit bersyarat yang gagal harus mengekalkan kedua-dua hasil dan mencipta salinan konflik dan bukannya secara senyap menggunakan pemenang-tulis-terakhir (last-writer-wins). Dokumentasi bantuan awam Dropbox juga menjelaskan bahawa penyuntingan serentak atau luar talian boleh menghasilkan salinan berkonflik yang mesti digabungkan oleh pengguna.

Akhir sekali, adakah jawapan tersebut menghubungkan kapasiti, kos, dan penambakan semula? Calon harus membezakan kapasiti logikal daripada kapasiti fizikal yang dinyahduplikasi, menganggarkan komit versi dan pemprosesan bait, serta menerangkan ketulan yatim, versi yang disimpan, batu nisan pemadaman, kuota, ruang nama hangat, dan mengapa pengutipan sampah tidak boleh bergantung pada satu kiraan rujukan seketika sahaja.

Soalan penjelasan sebelum menjawab

• Apakah kandungan yang disegerakkan? Fail dan direktori biasa; tiada kolaborasi langsung peringkat aksara.
• Apakah ketekalan yang diperlukan? Peranti yang memuat naik mendapat tingkah laku baca-tulisan-anda (read-your-write); peranti dalam talian yang lain menumpu dalam masa 5 saat.
• Berapa lamakah sejarah berperingkat disimpan? Andaikan 30 hari; kursor yang lebih lama memerlukan snapshot ruang nama sebelum menyambung semula delta.
• Bagaimanakah suntingan serentak dikendalikan? Hanya satu komit daripada baseVersionId yang diberikan menjadi semasa; hasil yang lebih lewat dikekalkan sebagai salinan konflik.
• Bolehkah pemadaman menambak bait dengan serta-merta? Tidak. Tulis batu nisan (tombstone) dan kekalkannya selama 30 hari untuk penyegerakan luar talian dan pemulihan.
• Adakah penyahduplikasian bersifat global merentas semua pengguna? Tetapkan kepada penyahduplikasian berskop akaun atau penyewa secara lalai untuk mengurangkan kebocoran kewujudan kandungan dan penggandingan penyulitan.
• Apakah perkongsian yang berada dalam skop? Pautan baca sahaja untuk fail atau direktori; kebenaran organisasi yang kompleks adalah susulan.
• Bagaimanakah penyulitan dan fail berniat jahat dikendalikan? Penyulitan semasa transit dan dalam rehat, URL bertandatangan jangka pendek, dan pengimbasan perisian hasad secara tak segerak; penyulitan hujung-ke-hujung berada di luar skop.
• Bagaimanakah rantau menerima penulisan? Setiap ruang nama mempunyai satu rantau penulisan utama (home write region); objek boleh direplikasi merentas rantau dan metadata mempunyai replikasi pemulihan bencana tak segerak.
• Adakah padanan muat naik segera dijamin? Tiada nisbah penyahduplikasian tetap diandaikan. Kenakan kuota logikal mengikut saiz yang dapat dilihat pengguna dan ukur penjimatan fizikal secara berasingan.

Kerangka jawapan 30 saat

"Saya akan menyimpan ketulan tak boleh ubah sekitar 4 MiB dalam storan objek dan mengekalkan direktori, versi semasa, manifes, batu nisan, dan perubahan tersusun dalam metadata yang tekal kukuh. Klien hanya memuat naik ketulan yang tiada, kemudian komit secara atomik dengan baseVersionId dan kunci kedekalpuncaan (idempotency key). Peranti menyimpan kursor dan menggunakan pemberitahuan hanya untuk mencetuskan /changes?cursor=, jadi pemberitahuan yang hilang tidak akan menghilangkan data. Komit luar talian yang serentak mengekalkan salinan konflik. Pada 100 juta versi setiap hari, puncak lima kali ganda adalah sekitar 6,000 komit/s, manakala kemasukan harian 400 TB memuncak hampir 25 GB/s. Pemadaman mengekalkan batu nisan, dan ketulan hanya ditambak semula selepas tempoh tangguh dan perdamaian manifes."

Penerokaan mendalam langkah demi langkah

Mulakan dengan lima invarian:

1. Versi yang diterbitkan hanya merujuk kepada ketulan yang wujud dan lulus semakan integriti.
2. Komit menggantikan currentVersionId hanya apabila baseVersionId masih bersamaan dengan versi semasa.
3. Nombor jujukan perubahan meningkat secara ketat dalam ruang nama, dan kursor peranti hanya bergerak ke hadapan.
4. Pemadaman menulis batu nisan; data yang mungkin masih dirujuk tidak dipadamkan secara fizikal semasa tetingkap penyegerakan dan pemulihan.
5. Pengutipan sampah memadamkan ketulan hanya selepas tempoh tangguh dan perdamaian manifes masih menunjukkan tiada rujukan.

Langkah satu: pisahkan klien, satah metadata, dan satah kandungan.

Klien mempunyai pemantau fail, indeks tempatan, jurnal operasi tahan lasak, pemetul (chunker), dan enjin penyegerakan. Selepas ranap sistem, ia memulihkan ketulan mana yang telah dimuat naik dan komit mana yang tidak pasti dan bukannya mengimbas dan memuat naik semula setiap fail. Pelayan mempunyai get laluan API, semakan pengesahan dan kuota, perkhidmatan metadata, penyelaras muat naik, storan objek, log perubahan ruang nama, perkhidmatan pemberitahuan, CDN muat turun, pengimbas perisian hasad, dan pengutip sampah.

Metadata dihalakan mengikut namespaceId. Pemacu peribadi ialah satu ruang nama, dan folder kongsi boleh menjadi satu lagi ruang nama, mengekalkan kebenaran, perubahan tersusun, dan pengasingan titik panas di dalam satu sempadan. Setiap ruang nama pada mulanya mempunyai satu rantau penulisan utama dengan replikasi metadata segerak merentas zon ketersediaan. Muat turun boleh menggunakan CDN berdekatan atau replika objek. Ini mengelakkan dua ketua wilayah daripada menerima kemas kini direktori yang bercanggah secara serentak.

Langkah dua: tentukan model data.

FileEntry(id, namespaceId, parentId, name, type, currentVersionId, deletedAt)
FileVersion(id, fileId, baseVersionId, size, manifestHash, createdBy, createdAt)
VersionChunk(versionId, ordinal, chunkHash, size)
UploadSession(id, fileId, baseVersionId, state, expiresAt, idempotencyKey)
Change(namespaceId, seq, entityId, operation, versionId, createdAt)

Pohon direktori menggunakan nilai fileId dan parentId yang stabil, jadi operasi alih atau namakan semula mengubah metadata tanpa menyalin kandungan. FileVersion adalah tidak boleh ubah, dan baris VersionChunk yang tersusun membentuk manifesnya. manifestHash mengesahkan manifes tetapi tidak menggantikan checksum setiap ketulan. UploadSession menyimpan keadaan sesi dan kunci kedekalpuncaannya. Change.seq adalah monotonik dalam ruang nama, dan pemadaman merupakan satu lagi operasi yang dilog.

Kuatkuasakan keunikan nama dengan kekangan bersyarat pada (namespaceId, parentId, normalizedName). Produk mesti mentakrifkan penormalan huruf besar/kecil secara jelas; jika tidak, klien Windows, macOS, dan Linux boleh berbeza pendapat sama ada dua nama bercanggah atau tidak.

Langkah tiga: reka bentuk muat naik berbilang bahagian boleh sambung semula.

POST /files/{fileId}/upload-sessions
  { baseVersionId, size, chunks[], idempotencyKey }
  -> { uploadSessionId, missingChunks[], signedUrls[] }

PUT {signedChunkUrl}
  Content-Checksum: ...

POST /upload-sessions/{uploadSessionId}/commit
  { manifestHash, idempotencyKey }
  -> { fileVersionId, changeSeq }

GET /files/{fileId}/download-manifest
  -> { fileVersionId, chunks[], signedUrls[] }

Klien bermula dengan ketulan sekitar 4 MiB dan mengira cincangan (hash) yang kuat. Pelayan mencari ketulan sedia ada hanya dalam akaun atau penyewa dan mengeluarkan URL bertandatangan jangka pendek yang diskopkan mengikut objek dan operasi untuk ketulan yang hilang. Klien memuat naik dengan keselarian terhad dan mencuba semula bahagian yang gagal sahaja. Dokumentasi berbilang bahagian rasmi AWS dan Alibaba Cloud kedua-duanya menggunakan model sesi permulaan, muat naik bahagian, dan penyelesaian. Mereka juga menyatakan bahawa bahagian yang belum selesai terus menggunakan storan, jadi sesi memerlukan tamat tempoh dan muat naik yang lama terbiar memerlukan pembatalan yang jelas.

Ketulan bersaiz tetap adalah mudah dan menyelaraskan dengan baik untuk kebanyakan fail. Jika beban kerja kerap memasukkan beberapa bait berhampiran permulaan, setiap sempadan tetap yang seterusnya akan berganjak dan cincangan berubah. Pemetulan tertakrif kandungan (content-defined chunking) boleh memulihkan lebih banyak data yang tidak berubah dengan kos CPU dan kerumitan pelaksanaan. Mulakan dengan ketulan tetap dan naik taraf hanya apabila corak suntingan yang diperhatikan mewajarkannya.

Langkah empat: jadikan komit versi sebagai satu-satunya sempadan penerbitan.

Titik akhir komit mula-mula mencari hasil sedia ada mengikut idempotencyKey, kemudian mengesahkan saiz ketulan, cincangan, kebenaran, dan kuota. Dalam satu transaksi metadata, ia:

1. Mengunci atau membaca secara bersyarat FileEntry.currentVersionId.
2. Mengesahkan bahawa ia masih bersamaan dengan baseVersionId bagi permintaan tersebut.
3. Menulis manifes FileVersion dan VersionChunk yang tidak boleh ubah.
4. Mengemas kini currentVersionId.
5. Menambah Change.seq seterusnya dan rekod peti keluar (outbox) transaksi.

Bait objek selesai sebelum transaksi metadata, jadi transaksi tersebut tidak boleh menerbitkan rujukan kepada ketulan yang hilang. Kegagalan pemberitahuan selepas komit tidak menjejaskan ketepatan: peti keluar mencuba semula, dan peranti masih boleh menarik mengikut kursor. Jika respons komit hilang, percubaan semula kunci kedekalpuncaan yang sama mengembalikan fileVersionId asal dan bukannya mencipta satu lagi versi logikal atau mengenakan kuota dua kali.

Langkah lima: segerakkan peranti dengan kursor.

GET /changes?namespaceId={id}&cursor={lastSeq}&limit=1000
  -> { changes[], nextCursor, hasMore }

Peranti menyimpan lastSeq dan indeks fail tempatannya dalam transaksi tahan lasak yang sama. Selepas pemberitahuan "ruang nama mungkin telah berubah", ia menarik sehingga hasMore=false, menggunakan penciptaan, kemas kini, perpindahan, dan batu nisan mengikut urutan, dan hanya selepas itu ia mengkomit kursor baharu. seq menjadikan main semula idempoten. Pemberitahuan yang tidak teratur tidak menjejaskan hasil tarikan. Jika setiap pemberitahuan hilang, kebangkitan latar hadapan dan pemeriksaan berkala tetap akan menemui jujukan yang lebih baharu.

Jika kursor lebih lama daripada tetingkap pengekalan 30 hari, perkhidmatan mengembalikan cursor_expired dengan lokasi untuk snapshot ruang nama yang tekal. Klien memuatkan snapshot, mendamaikan operasi tidak terkomit tempatan, dan menyambung semula daripada penanda air snapshot. Ia tidak boleh sekadar memadam semua fail tempatan. Pemberitahuan ialah pengoptimuman kependaman; log kursor ialah protokol penyegerakan sebenar.

Langkah enam: kendalikan konflik, pemadaman, dan pemulihan versi.

Peranti A dan B kedua-duanya menyunting versi 10 di luar talian. A mengkomit versi 11 dengan baseVersionId=10. Komit bersyarat B yang terkemudian gagal. Perkhidmatan mengekalkan kandungan yang dimuat naik oleh B, mencipta entri baharu seperti "nama (salinan berkonflik B)" atau versi konflik, dan menambah perubahan ruang nama. Fail binari biasa tidak digabungkan secara automatik secara senyap. Penggabungan khusus teks atau dokumen ialah keupayaan produk yang berasingan.

Pemadaman mengemas kini deletedAt dan menambah batu nisan. Peranti dalam talian memindahkan entri ke tong sampah, dan peranti luar talian boleh mengetahui tentang pemadaman tersebut apabila ia menyambung semula. Versi sejarah dan rujukan ketulan kekal sah semasa tetingkap pemulihan 30 hari. Selepas itu, pengutip mengira set ketulan yang dirujuk oleh manifes yang disimpan, menandakan calon yang tidak dirujuk, menunggu tempoh tangguh, dan mendamaikan semula sebelum memadam. Percubaan semula, peristiwa yang tertangguh, dan tugas pembaikan boleh menjadikan kiraan rujukan seketika salah, jadi ia tidak boleh menjadi satu-satunya pihak berkuasa untuk pemadaman yang tidak boleh diubah balik.

Langkah tujuh: anggarkan kapasiti dan asingkan titik panas.

50 million × 10 GB = 500 PB storan logikal. Replikasi, sejarah, dan penyahduplikasian mengubah kapasiti fizikal, tetapi prompt tidak memberikan nisbah, jadi angka fizikal yang tepat hanyalah rekaan semata-mata. Kemasukan logikal harian ialah 100 million × 4 MB = 400 TB, dengan purata kira-kira 4.6 GB/s dan memuncak sekitar 25 GB/s. Komit versi purata 100,000,000 / 86,400 ≈ 1,157/s dan dibundarkan kepada kira-kira 6,000/s pada puncak lima kali ganda.

Jika setiap perubahan memberi petunjuk kepada purata tiga peranti dalam talian, pemberitahuan boleh memuncak hampir 18,000/s. Pemberitahuan boleh digabungkan menjadi "ruang nama ini berubah" dan bukannya menjadi mesej setiap fail yang boleh diharap (reliable). Bahagikan (shard) metadata secara cincangan mengikut namespaceId, mengekalkan penulisan tersusun untuk satu ruang nama pada satu shard utama. Ruang kongsi yang sangat besar mungkin menjadi hangat. Hadkan kadar operasi direktori pukal, gabungkan pemberitahuan, dan sub-shard rekod fail mengikut fileId hanya dengan bukti, sambil mengekalkan penjana jujukan ruang nama yang berasingan.

Langkah lapan: tutup gelung kegagalan, keselamatan, dan pengesahan.

• Muat naik terganggu: buat pertanyaan sesi dan muat naik bahagian yang hilang sahaja; pemprosesan kitaran hayat menamatkan tempoh sesi yang terbiar.
• Bahagian dimuat naik tetapi komit gagal: bahagian tersebut adalah anak yatim sementara dan perdamaian manifes menambaknya semula selepas tempoh tangguh.
• Komit berjaya tetapi pemberitahuan gagal: peti keluar transaksi mencuba semula, dan tarikan kursor masih pulih.
• Komit berjaya tetapi respons hilang: kunci kedekalpuncaan yang sama mengembalikan hasil asal.
• Penulisan luar talian serentak: syarat baseVersionId gagal dan perkhidmatan mengekalkan salinan konflik.
• Ketulan rosak: muat naik dan muat turun mengesahkan cincangan yang kuat, dan kandungan tidak sah tidak boleh memasuki manifes yang diterbitkan.
• Kursor tamat tempoh: muatkan snapshot, kemudian sambung semula daripada penanda airnya.
• Rantau utama tidak boleh menulis: hentikan penulisan atau lakukan failover di bawah prosedur RPO/RTO yang jelas; jangan sekali-kali membenarkan dua penulis utama.

URL bertandatangan mestilah jangka pendek dan terikat pada akaun, objek, saiz, dan operasi. Pelayan menyemak semula kebenaran dan kuota semasa komit. Muat naik segera rentas pengguna global mewujudkan saluran sisi untuk kewujudan kandungan dan menggabungkan hak penyulitan dan pemadaman setiap pengguna, jadi penyahduplikasian diskopkan mengikut penyewa secara lalai. Metrik teras termasuk p99 muat naik dan komit, kelengahan penyegerakan, kursor tamat tempoh, salinan konflik, bait ketulan yatim, padanan nyahduplikasi, perbezaan calon-lawan-pemadaman GC, ruang nama hangat, kegagalan checksum, dan kejayaan pemulihan.

Pengesahan merangkumi pemindahan boleh sambung semula fail 50 GB, ranap selepas setiap peringkat muat naik, komit pendua, pemberitahuan yang hilang dan tidak teratur, suntingan luar talian serentak, peranti lama kembali selepas pemadaman, kerosakan checksum, failover shard utama, kursor tamat tempoh, sempadan kuota, dan perlindungan GC daripada pemadaman palsu. Penegasan hujung-ke-hujung yang paling penting ialah setiap fileVersionId yang kelihatan dimuat turun ke kandungan yang lengkap dan disahkan, serta versi di dalam tetingkap pemulihan tidak pernah ditambak semula.

Contoh jawapan berkualiti tinggi

"Saya mula-mula akan memisahkan satah kandungan daripada satah metadata. Fail dibahagikan kepada ketulan tak boleh ubah sekitar 4 MiB dalam storan objek. Direktori, nilai fileId yang stabil, versi semasa, manifes versi, batu nisan, dan nombor jujukan ruang nama diletakkan dalam lapisan metadata yang menyokong penulisan bersyarat. Pemindahan dan penamaan semula mengemas kini metadata tanpa menulis ganti sejarah.

Semasa muat naik, klien mencincang ketulan dan mencipta sesi dengan baseVersionId dan kunci kedekalpuncaan. Pelayan mengembalikan URL bertandatangan jangka pendek hanya untuk ketulan yang hilang diskopkan mengikut penyewa. Selepas semua ketulan dimuat naik dan disahkan, transaksi metadata mengesahkan bahawa versi semasa tidak berubah, menulis versi dan manifes baharu, mengemas kini currentVersionId, dan menambah Change.seq berserta rekod peti keluar. Kandungan selesai sebelum penerbitan metadata, jadi versi yang kelihatan tidak akan pernah menunjuk ke bait yang hilang. Respons yang hilang dipulihkan dengan kunci kedekalpuncaan yang sama.

Penyegerakan menggunakan kursor yang tahan lasak. Pemberitahuan hanya memberitahu bahawa ruang nama mungkin telah berubah. Peranti memanggil /changes?cursor=, menggunakan perubahan mengikut urutan, dan kemudian memajukan kursor. Oleh itu, pemberitahuan yang hilang, pendua, dan tidak teratur tidak akan menghilangkan data. Kursor yang lebih lama daripada tetingkap pengekalan 30 hari membina semula daripada snapshot yang tekal dan menyambung semula daripada penanda airnya. Apabila dua peranti menyunting versi yang sama di luar talian, komit yang terkemudian mengekalkan salinan konflik dan bukannya menulis ganti versi yang lebih baharu.

Kapasiti adalah 500 PB storan logikal. Kandungan baharu atau diubah ialah 400 TB setiap hari, dengan purata sekitar 4.6 GB/s dan memuncak sekitar 25 GB/s. Seratus juta versi menghasilkan purata kira-kira 1,157 komit sesaat dan memuncak hampir 6,000/s. Metadata dibahagikan (shard) mengikut ruang nama dengan satu rantau penulisan utama, manakala muat turun diskalakan melalui CDN dan replika objek serantau.

Pemadaman menulis batu nisan yang disimpan selama 30 hari. Apabila sejarah tamat tempoh, pengutipan sampah menandakan calon daripada semua manifes yang disimpan, menunggu tempoh tangguh, dan mendamaikan semula. Ia tidak pernah memadam semata-mata kerana satu kiraan rujukan mencapai sifar. Saya akan menyuntik kegagalan pada setiap sempadan muat naik dan komit, kemudian mengesahkan pemberitahuan yang hilang, konflik luar talian, kursor tamat tempoh, kerosakan checksum, failover utama, dan keselamatan GC sambil terus menegaskan bahawa setiap versi yang kelihatan dimuat turun sepenuhnya."

Kesilapan lazim

• Menyimpan bait fail dalam pangkalan data metadata → objek besar membebankan replikasi, sandaran, dan transaksi → simpan rujukan dalam metadata dan kandungan tak boleh ubah dalam storan objek.
• Menerbitkan fail selepas bahagian pertama dimuat naik → peranti lain boleh membaca versi yang tidak lengkap → komit metadata secara atomik hanya selepas setiap bahagian disahkan.
• Menganggap pemberitahuan WebSocket sebagai kebenaran penyegerakan → mesej yang hilang atau tempoh luar talian menyebabkan perubahan terlepas secara kekal → gunakan pemberitahuan hanya untuk mencetuskan tarikan kursor yang berwibawa.
• Komit tanpa baseVersionId → peranti luar talian secara senyap menulis ganti versi yang lebih baharu → gunakan komit bersyarat dan kekalkan salinan konflik sekiranya berlaku kegagalan.
• Menjana sesi dan kunci kedekalpuncaan baharu pada setiap percubaan semula → versi pendua, caj kuota, dan ketulan yatim bertambah → gunakan kunci yang stabil untuk memulihkan hasil asal.
• Menetapkan muat naik segera rentas pengguna global secara lalai → kewujudan kandungan bocor dan penyulitan/pemadaman menjadi terikat → skopkan penyahduplikasian kepada akaun atau penyewa.
• Memadam ketulan serta-merta selepas pemadaman oleh pengguna → penyegerakan luar talian, pemulihan, atau transaksi tertangguh merujuk kepada bait yang hilang → gunakan batu nisan, pengekalan, tempoh tangguh, dan perdamaian.
• Mengandaikan nisbah penyahduplikasian tetap untuk kapasiti fizikal → beban kerja yang tidak diketahui menghasilkan ketepatan palsu → laporkan 500 PB logikal dan tentukur penjimatan fizikal daripada pengukuran.
• Menolak setiap perubahan fail secara andal ke setiap peranti → kos pemberitahuan dan keadaan percubaan semula meletup → gabungkan petunjuk ruang nama dan biarkan klien menarik delta.
• Bermula dengan penulisan metadata rentas rantau aktif-aktif → konflik nama, alih, dan versi semasa menjadi sukar untuk ditumpukan → kekalkan satu penulis utama bagi setiap ruang nama terlebih dahulu.

Soalan susulan dan respons

Susulan satu: Bagaimanakah anda memilih antara ketulan bersaiz tetap berbanding tertakrif kandungan?

Ketulan sekitar 4 MiB adalah mudah dan boleh diramal serta berfungsi dengan baik untuk penambahan di hujung (appends), penulisan ganti setempat, dan kebanyakan fail media. Jika pengguna kerap memasukkan kandungan berhampiran permulaan, sempadan tetap akan berganjak dan setiap cincangan yang berikutnya berubah. Pemetulan tertakrif kandungan boleh menemui semula kandungan yang tidak berubah tetapi menggunakan lebih banyak CPU dan memerlukan algoritma sempadan yang stabil dan berversi. Lancarkan dengan ketulan tetap, ukur peratusan bait yang boleh diguna semula selepas suntingan, dan dayakan pemetulan tertakrif kandungan untuk fail besar terpilih hanya apabila penjimatan yang diperhatikan mewajarkan kerumitan tersebut.

Susulan dua: Bagaimanakah pemindahan direktori mengekalkan susunan penyegerakan?

Pemindahan mengemas kini parentId dan menambah satu jujukan ruang nama dalam transaksi metadata. Klien menggunakannya mengikut seq. Operasi alih tidak menulis semula laluan bagi setiap keturunan kerana laluan diperoleh daripada rantai induk. Pemindahan rentas ruang nama tidak boleh dianggap sebagai satu kemas kini metadata tempatan; modelkannya sebagai aliran kerja salin-dan-padam yang boleh dicuba semula dan dedahkan keadaan sedang berjalan kepada pengguna.

Susulan tiga: Bagaimanakah penyulitan hujung-ke-hujung dan muat naik segera wujud bersama?

Dengan penyulitan hujung-ke-hujung bahagian klien, pelayan secara umumnya hanya melihat teks sifer. Kunci setiap pengguna yang berbeza menjadikan teks biasa yang sama menghasilkan teks sifer yang berbeza, menghapuskan kebanyakan penyahduplikasian rentas pengguna. Penyulitan konvergen memperkenalkan serangan pengesahan kandungan dan risiko kunci. Produk mesti memilih: mod privasi tinggi menerima penyahduplikasian yang lebih rendah, manakala mod kunci yang diuruskan oleh penyewa boleh menyahduplikasi di dalam penyewa. Ia tidak boleh menjanjikan muat naik segera global tanpa syarat dan kerahsiaan hujung-ke-hujung yang kukuh pada masa yang sama.

Susulan empat: Bagaimana jika satu direktori kongsi yang amat besar menjadi hangat?

Mula-mula gabungkan pemberitahuan, hadkan kadar operasi pukal, simpan cache halaman direktori baca sahaja, dan ukur sama ada kesesakan berlaku pada peruntukan jujukan, keunikan nama, atau penyenaraian. Metadata fail mungkin boleh di-sub-shard mengikut fileId, tetapi ruang nama masih memerlukan penanda air yang tersusun. Secara dalaman, peruntukkan julat jujukan secara kelompok atau gunakan log berpartition sambil mendedahkan kursor luaran yang stabil. Jangan buang semantik susunan yang boleh dipulihkan semata-mata untuk menuntut penskalaan mendatar.

Susulan lima: Bagaimanakah pengutipan sampah mengelakkan pemadaman palsu?

GC tidak mempercayai kiraan rujukan langsung semata-mata. Ia membina set langsung daripada setiap manifes yang masih dalam pengekalan, menandakan ketulan di luar set sebagai calon, menunggu lebih lama daripada kelewatan maksimum transaksi, replikasi, dan pemulihan, serta mendamaikan semula terhadap manifes semasa sebelum memadam. Pemadaman adalah idempoten dan diaudit; manifes yang hilang atau ketidakpadanan melambatkan penambakan semula. Bahagian berbilang bahagian yang belum selesai juga memerlukan tamat tempoh sesi yang bebas dan pemprosesan pembatalan.

Susulan enam: Bagaimanakah anda menyediakan pemulihan bencana rentas wilayah?

Setiap ruang nama biasanya mempunyai satu rantau utama yang menerima penulisan metadata. Rantau lain secara tak segerak mereplikasi log dan objeknya. Failover terlebih dahulu memagar (fence) penulis lama, mempromosikan replika pemulihan di bawah epok baharu, dan mengubah penghalaan. RPO bergantung pada kelengahan replikasi dan RTO pada pengesanan dan promosi. RPO sifar memerlukan kuorum rentas rantau segerak dan kependaman penulisan yang lebih tinggi. Utama lama yang telah pulih mesti mengesahkan epok kepimpinan ruang nama sebelum menerima penulisan.

Susulan tujuh: Bagaimanakah anda membuktikan bahawa penyegerakan tidak pernah terlepas data?

Bina model keadaan yang menjana jujukan muat naik, komit, alih, padam, konflik, dan cuba semula. Tegaskan bahawa klien selepas menggunakan jujukan N adalah sama dengan snapshot pelayan pada N. Ujian hujung-ke-hujung menggugurkan, menduplikasi, dan menyusun semula pemberitahuan secara rawak tanpa merosakkan log perubahan; peranti mesti tetap menumpu melalui tarikan kursor. Suntik ranap selepas menggunakan perubahan tetapi sebelum menyimpan kursor, dan selepas menyimpan kandungan tempatan tetapi sebelum penyiapan proses. Main semula mesti kekal idempoten, dan setiap peranti akhirnya mesti mencapai graf versi yang sama.