Aplikasi online skala besar telah berkembang pesat dalam dua dekade sebelumnya. Inovasi ini telah mengubah persepsi kami tentang pengembangan perangkat lunak. Facebook, Instagram, dan Twitter, misalnya, semuanya adalah platform yang dapat diskalakan.
Sistem ini harus dibangun untuk mengelola volume lalu lintas dan data yang sangat besar karena miliaran orang menggunakannya secara bersamaan di seluruh dunia. Ini adalah ketika desain sistem memasuki gambar.
Proses membangun arsitektur, antarmuka, dan data untuk sistem yang memenuhi kriteria tertentu dikenal sebagai desain sistem. Melalui sistem yang kohesif dan efisien, desain sistem memenuhi tuntutan bisnis atau organisasi Anda.
Setelah perusahaan atau organisasi Anda menentukan kriterianya, Anda dapat mulai memasukkannya ke dalam desain sistem fisik yang memenuhi permintaan konsumen Anda.
Apakah Anda memilih untuk menggunakan pengembangan yang dipesan lebih dahulu, solusi komersial, atau kombinasi keduanya, bagaimana Anda mendesain sistem Anda akan menentukan bagaimana Anda membangunnya.
Kami akan melihat secara rinci desain sistem timeline Twitter di posting ini, lengkap dengan tutorialnya. Mari kita mulai.
Langkah 1: Buat garis besar kasus penggunaan & batasan
Gunakan kasing
- Seorang pengguna mengunggah tweet.
- Layanan ini mengirimkan pemberitahuan push dan email ke pengikut tweet.
- Garis waktu pengguna dilihat (aktivitas dari pengguna)
- Pengguna melihat timeline beranda (aktivitas dari orang yang diikuti pengguna)
- Kata kunci dicari oleh pengguna.
- Layanan ini benar-benar dapat diakses.
Keluar dari ruang lingkup
- Tweet dikirim ke Twitter Firehose dan aliran lainnya menggunakan layanan ini.
- Layanan menghapus tweet berdasarkan pengaturan visibilitas pengguna.
- Jika pengguna tidak juga mengikuti orang yang dibalas, sembunyikan balasannya.
- Perhatikan opsi 'sembunyikan retweet'.
- Analitik
Kendala & asumsi
Asumsi Negara
- Lalu lintas tidak tersebar merata.
- Seharusnya sederhana untuk mengirim tweet.
- Kecuali Anda memiliki jutaan pengikut, mengirim tweet ke semua pengikut Anda harus cepat.
- Ada 100 juta pengguna aktif.
- 15 miliar tweet setiap bulan atau 500 juta tweet setiap hari
- Setiap tweet memiliki rata-rata pengiriman 10 fanout.
- Setiap hari, fanout mengirimkan 5 miliar tweet.
- Fanout mengirimkan 150 miliar tweet setiap bulan.
- 250 miliar permintaan baca bulanan
- 10 miliar pencarian bulanan
Perusahaan
- Garis waktu harus mudah dinavigasi.
- Twitter lebih tentang membaca daripada menulis.
- Optimalkan untuk membaca tweet cepat
- Konsumsi Tweet memakan waktu.
Pencarian
- Proses pencarian harus cepat.
- Ini memakan waktu untuk mencari.
Hitung penggunaan
Ukuran setiap tweet:
- ID tweet 8 byte
- ID pengguna 32 byte
- 140 byte teks
- media – rata-rata 10 KB
- Jumlah: ~10 KB
Setiap bulan, 150 TB konten tweet baru dihasilkan.
- * 500 juta tweet setiap hari * 30 hari per bulan * 10 KB per tweet
- Dalam tiga tahun, ada 5.4 PB konten tweet baru.
Ada 100,000 permintaan baca setiap detik.
- * (400 permintaan per detik / 1 miliar permintaan per bulan) 250 miliar permintaan baca setiap bulan
Ada 6,000 tweet setiap detik.
- * (400 permintaan per detik / 1 miliar permintaan per bulan) 15 miliar tweet setiap bulan
Pada fanout, 60 ribu tweet dikirim setiap detik.
- Fanout mengirimkan 150 miliar tweet setiap bulan* (400 permintaan per detik / 1 miliar permintaan per bulan).
4,000 permintaan informasi setiap detik
- * (400 permintaan per detik / 1 miliar permintaan per bulan) 10 miliar pencarian setiap bulan
Beberapa konversi yang berguna
- Setiap bulan, 2.5 juta detik berlalu.
- 2.5 juta permintaan per bulan dengan 1 permintaan per detik
- 100 juta permintaan per bulan x 40 permintaan per detik
- 1 miliar permintaan per bulan = 400 permintaan per detik
Langkah 2: Diagram tingkat tinggi
Langkah 3: Menjelaskan komponen inti
Kami dapat menyimpan tweet pengguna sendiri untuk mengisi timeline pengguna (aktivitas dari pengguna) dalam database relasional jika mereka mengirimkan tweet. Lebih sulit untuk mengirim tweet dan mengembangkan timeline beranda (aktivitas dari individu yang diikuti pengguna).
Basis data relasional yang khas akan kewalahan dengan menyebarkan tweet ke semua pengikut (60 ribu tweet dikirim setiap detik). Kami mungkin ingin menggunakan penyimpanan data tulis cepat seperti database NoSQL atau Memory Cache.
Membaca 1 MB secara berurutan dari memori membutuhkan waktu kira-kira 250 mikrodetik, tetapi membaca dari SSD membutuhkan waktu 4 kali lebih lama, dan membaca dari disk membutuhkan waktu 80 kali lebih lama.
Object Store dapat digunakan untuk menyimpan data seperti gambar dan video.
- Server Web, yang bertindak sebagai proxy terbalik, menerima tweet dari Klien.
- Permintaan dikirim ke server Write API oleh Web Server.
- Write API menyimpan tweet ke database SQL di timeline pengguna.
Layanan Fan-Out dihubungi oleh Write API, dan melakukan tugas berikut.
- Menemukan pengikut pengguna di Cache Memori dengan menanyakan Layanan Grafik Pengguna.
- Pada Memory Cache, tweet disimpan di timeline beranda pengikut pengguna.
- 1,000 pengikut = 1,000 pencarian dan sisipan = O(n) operasi.
- Tweet disimpan di Search Index Service untuk pencarian cepat.
- Object Store digunakan untuk menyimpan media.
- Mengirim peringatan push ke pengikut melalui Layanan Pemberitahuan.
- Untuk mengirimkan peringatan secara asinkron, ia menggunakan Antrian.
Kami dapat menggunakan daftar Redis asli dengan struktur berikut jika Cache Memori kami adalah Redis:
Timeline beranda pengguna akan diperbarui dengan tweet baru, yang akan disimpan di Memory Cache. Kami akan menggunakan REST API publik berikut:
Garis waktu pengguna dilihat oleh pengguna.
- Server Web menerima permintaan timeline pengguna dari Klien.
- Permintaan dikirim ke server Read API oleh Web Server.
- Read API mengkueri Database SQL untuk jangka waktu pengguna.
REST API akan bekerja mirip dengan timeline beranda, dengan pengecualian bahwa semua tweet berasal dari pengguna dan bukan dari orang yang mereka ikuti.
Seorang pengguna mencari kata kunci:
- Server Web menerima permintaan pencarian dari Klien.
- Permintaan dikirim ke server API Pencarian oleh Server Web.
Langkah 4: Garis waktu Twitter
Pembuatan garis waktu adalah tugas yang sulit. Diperlukan server penghasil garis waktu yang menautkan ke server web atau aplikasi.
Setiap kali pengguna masuk, layanan garis waktu melacak tweet terbaru dari pengguna di tabel pengikut dan memperbarui atau menyegarkan garis waktu pengguna.
Kami tidak menerapkan sistem peringkat apa pun di sini; sebagai gantinya, kami menganggap bahwa 5 tweet teratas dari pengikut pengguna ditampilkan di timeline dalam urutan waktu pembuatan. Kami dapat mempertahankan batas penyegaran 50 tweet. Kami masih berhenti menyegarkan atau membuat garis waktu setelah ambang batas tersebut tercapai hingga pengguna menyegarkan halaman.
Masalah latensi dan kinerja tinggi akan datang dari pembuatan umpan pengguna langsung. Sebaliknya, membuat streaming offline yang dapat disajikan secara instan adalah cara terbaik untuk meningkatkan kinerja. Jalankan server timeline khusus yang melakukan ping ke server aplikasi secara teratur untuk menyegarkan umpan berdasarkan waktu pembuatannya.
Algoritme peringkat harus mempertimbangkan sinyal penting dan memberikan bobot untuk menjamin bahwa garis waktu pengguna tidak didominasi oleh materi dari satu atau lebih akun yang mereka ikuti.
Lebih tepatnya, kita dapat memilih fitur yang terkait dengan relevansi item feed apa pun, seperti jumlah suka, komentar, bagikan, dan waktu pembaruan. Masing-masing kriteria ini harus digunakan untuk menilai tweet, dan kemudian peringkat itu harus digunakan untuk menampilkan tweet di timeline.
Haruskah kita terus-menerus memperingatkan pengguna ketika konten baru untuk umpan berita mereka tersedia? Pengguna dapat merasakan manfaat untuk diperingatkan ketika data baru tersedia. Namun, pada perangkat seluler, ketika penggunaan data cukup mahal, dapat membuang bandwidth.
Akibatnya, kami dapat memilih untuk tidak mendorong data ke perangkat seluler dan sebagai gantinya mengizinkan pengguna untuk "Tarik untuk Menyegarkan" untuk posting baru.
Langkah 5: Desain penskalaan
Hambatan potensial adalah Layanan Fanout. Pengguna Twitter dengan jutaan pengikut harus menunggu beberapa menit hingga tweet mereka diluncurkan. Hal ini dapat menyebabkan perlombaan dengan balasan tweet, yang dapat kami hindari dengan mengurutkan ulang tweet pada waktu penayangan.
Kami juga dapat mencegah penyebaran tweet dari orang-orang dengan jumlah pengikut yang banyak. Sebagai gantinya, kami dapat melakukan pencarian tweet dari individu yang sangat diikuti, mengintegrasikan hasil pencarian dengan hasil timeline beranda pengguna, dan kemudian menyusun ulang tweet pada waktu penayangan.
Penyempurnaan tambahan meliputi:
- Simpan hanya beberapa ratus tweet di Memory Cache untuk setiap timeline beranda.
- Di Cache Memori, hanya informasi timeline beranda pengguna aktif yang disimpan.
- Kami dapat merekonstruksi kronologi dari Database SQL jika pengguna tidak aktif dalam 30 hari sebelumnya.
- Untuk mengetahui siapa pengguna tersebut, gunakan Layanan Grafik Pengguna.
- Tambahkan tweet ke Memory Cache dengan mengambilnya dari Database SQL.
- Layanan Info Tweet hanya dapat menyimpan tweet selama sebulan.
- Di Layanan Info Pengguna, hanya pengguna aktif yang disimpan.
- Untuk menjaga latensi tetap rendah, Search Cluster kemungkinan besar perlu mempertahankan tweet di memori.
Kesimpulan
Meskipun Twitter adalah organisasi besar, ia memiliki organisasi yang lebih baik pengertian desain sistem. Saya melakukan yang terbaik untuk memberi Anda gambaran umum tingkat tinggi tentang garis waktu Twitter.
Saya harap Anda mendapatkan informasi yang berguna darinya dan dapat menggunakannya dengan baik.
Tinggalkan Balasan