Seorang bekas jurutera infrastruktur Reddit baru-baru ini berkongsi pendekatan mereka untuk menyelesaikan masalah baris gilir teragih yang melanda platform media sosial tersebut lebih sedekad yang lalu. Artikel tersebut menjanjikan pandangan tentang bagaimana mereka menangani isu di mana undian pengguna, komen, dan penyerahan boleh hilang apabila sistem gagal. Walau bagaimanapun, komuniti teknikal telah menimbulkan persoalan tentang kelengkapan penjelasan dan pembingkaian penyelesaian tersebut.
Masalah Asal di Reddit
Semasa tahun-tahun awal Reddit , platform tersebut sangat bergantung pada RabbitMQ sebagai broker mesej mereka untuk mengendalikan interaksi pengguna. Apabila pengguna memberikan undi positif pada kiriman, tindakan tersebut masuk ke dalam baris gilir teragih sebelum sampai ke pangkalan data. Seni bina ini menyediakan penskalaan mendatar dan kawalan aliran tetapi datang dengan isu kebolehpercayaan yang ketara. Kerosakan sistem boleh mengakibatkan kehilangan data, dan apabila baris gilir itu sendiri rosak, undian pengguna dan komen akan hilang begitu sahaja.
Jurutera tersebut menjelaskan bahawa apa yang benar-benar diperlukan oleh Reddit adalah baris gilir tahan lama yang mencatat status tugas ke storan berterusan seperti PostgreSQL . Sistem ini menggabungkan baris gilir tugas dengan aliran kerja tahan lama, membolehkan kerja yang gagal disambung semula dari langkah terakhir yang selesai dan bukannya bermula semula atau hilang sepenuhnya.
Seni Bina Asal Reddit (15+ tahun yang lalu):
- Message Broker: RabbitMQ
- Cache: Sistem seperti Redis
- Pangkalan Data: PostgreSQL
- Aliran: Tindakan pengguna → Queue + Cache → Respons kejayaan → Pemproses Queue → Pangkalan Data + Pengiraan Semula
Persoalan Komuniti Mengenai Jurang Teknikal
Komuniti teknikal telah menunjukkan beberapa isu dengan persembahan artikel tersebut. Pengkritik menyatakan bahawa artikel tersebut tidak pernah menjelaskan secara eksplisit bagaimana penulis menyelesaikan masalah asal, walaupun tajuknya menjanjikan. Artikel tersebut memberi tumpuan berat pada menggambarkan baris gilir tahan lama sebagai konsep tetapi kurang spesifik tentang pelaksanaan atau perbandingan dengan penyelesaian sedia ada.
Adakah saya terlepas sesuatu atau artikel tersebut tidak pernah menangani tajuknya? Kiriman tersebut adalah huraian yang baik tentang baris gilir tahan lama, tetapi ia tidak pernah menyatakan secara eksplisit bahawa ia adalah penyelesaian kepada masalah baris gilir teragih, mahupun ia tidak mentakrifkan masalah tersebut secara khusus.
Selain itu, pembangun berpengalaman telah mempersoalkan sama ada RabbitMQ itu sendiri adalah masalahnya, dengan menyatakan bahawa walaupun 15 tahun yang lalu, RabbitMQ menyokong ketahanan dan transaksi dengan keupayaan rollback. Sesetengahnya mencadangkan masalah yang diterangkan mungkin berpunca daripada menggunakan RabbitMQ secara tidak betul dan bukannya batasan teknologi itu sendiri.
 |
|---|
| Kesesakan lalu lintas melambangkan kekangan dan ketidakcekapan yang dilihat dalam pengurusan baris gilir teragih, menggamakan kebimbangan komuniti terhadap penyelesaian artikel asal |
Perbincangan Aliran Kerja Tahan Lama
Fokus artikel beralih dengan ketara ke arah aliran kerja tahan lama, yang berbeza daripada baris gilir tahan lama yang mudah. Aliran kerja tahan lama membolehkan pembangun menulis kod yang boleh berhenti sebentar dan menyambung semula pelaksanaan merentas kegagalan sistem, mengekalkan keadaan dalam storan berterusan. Teknologi ini telah mendapat tarikan dengan platform seperti Temporal , DBOS , Inngest , dan Restate menawarkan pelbagai pelaksanaan.
Walau bagaimanapun, ahli komuniti menyatakan bahawa aliran kerja tahan lama memerlukan pembangun untuk menyusun semula kod mereka di sekitar runtime async tersuai dan pengaturcaraan gaya callback. Ini mewakili perubahan seni bina yang ketara yang melampaui sekadar menjadikan baris gilir lebih boleh dipercayai.
Nota: Aliran kerja tahan lama adalah sistem yang boleh berhenti sebentar dan menyambung semula proses jangka panjang merentas kegagalan sistem dengan menyimpan keadaan mereka ke storan berterusan pada titik semak utama.
Platform Barisan Tahan Lama yang Disebut:
- Temporal (https://temporal.io/)
- DBOS (https://www.dbos.dev/)
- Inngest (https://www.inngest.com/)
- Restate (https://restate.dev/)
 |
|---|
| Potongan kod Python menunjukkan bagaimana beratur tahan lasak boleh dilaksanakan, mewakili bahagian penting dalam penstrukturan semula aliran kerja seperti yang dibincangkan dalam artikel |
Pertukaran Prestasi dan Alternatif Moden
Perbincangan mendedahkan pertimbangan penting tentang bila memilih baris gilir tahan lama berbanding penyelesaian tradisional. Baris gilir tahan lama biasanya menggunakan pangkalan data hubungan seperti PostgreSQL untuk kedua-dua pembrokeran mesej dan storan, yang menyediakan jaminan yang lebih kuat tetapi berpotensi daya pemprosesan yang lebih rendah berbanding penyelesaian dalam memori seperti Redis .
Komuniti juga menimbulkan persoalan tentang bagaimana pendekatan ini dibandingkan dengan platform streaming moden seperti Kafka , yang boleh menyediakan kedua-dua ketahanan dan prestasi tinggi. Sesetengahnya berpendapat bahawa pilihan antara teknologi baris gilir yang berbeza lebih bergantung pada kes penggunaan khusus dan butiran pelaksanaan daripada batasan seni bina asas.
Pertukaran Teknikal Utama:
- Barisan Gilir Tradisional: Daya pemprosesan lebih tinggi, penyimpanan dalam memori ( Redis ), potensi kehilangan data
- Barisan Gilir Tahan Lama: Daya pemprosesan lebih rendah, penyimpanan berterusan ( PostgreSQL ), jaminan ketahanan data
- Prestasi: Barisan gilir tahan lama lebih baik untuk tugasan berkritikaliti perniagaan bervolum rendah; barisan gilir tradisional lebih baik untuk tugasan kecil bervolum tinggi
Kesimpulan
Walaupun artikel asal bertujuan untuk berkongsi pengajaran yang dipelajari daripada menyelesaikan masalah baris gilir teragih di Reddit , ia sebaliknya telah mencetuskan perbincangan yang lebih luas tentang evolusi teknologi baris gilir mesej dan pertukaran yang terlibat dalam pendekatan yang berbeza. Respons komuniti menyerlahkan kepentingan menyediakan butiran teknikal yang konkrit dan mengakui landskap penuh penyelesaian yang tersedia apabila membincangkan cabaran infrastruktur. Perbualan terus berkembang di sekitar amalan terbaik untuk membina sistem teragih yang boleh dipercayai dalam aplikasi moden.
Rujukan: How I solved a distributed queue problem after 15 years