Pertanyaan saya yang sebenarnya adalah, dapatkah tumpukan teknologi di atas menskalakan 1.000.000 pesan per detik (teks, gambar, video)?
Tentu bisa. Dengan desain yang tepat dan perangkat keras yang memadai. Pertanyaan yang harus diajukan klien Anda sebenarnya bukanlah apakah hal itu dapat dibuat menjadi sebesar itu, tetapi dengan biaya dan kepraktisan berapa hal itu dapat dilakukan dan apakah itu pilihan terbaik.
Mari kita lihat setiap bagian yang Anda sebutkan:
node.js - Untuk aplikasi I/O sentris, ini adalah pilihan yang sangat baik untuk skala tinggi dan dapat diskalakan dengan menerapkan banyak CPU dalam sebuah cluster (baik multi-proses per server dan multi-server). Seberapa praktis skala jenis ini sangat bergantung pada jenis data bersama yang perlu diakses oleh semua proses server ini. Biasanya, penyimpanan data akhirnya menjadi hambatan yang lebih sulit dalam penskalaan karena mudah untuk membuang lebih banyak server pada pemrosesan permintaan. Tidak mudah untuk membuang lebih banyak perangkat keras di penyimpanan data terpusat. Ada beberapa cara untuk melakukannya, tetapi ini sangat bergantung pada permintaan aplikasi tentang cara Anda melakukannya dan seberapa sulitnya.
socket.io - Jika Anda memerlukan server push yang efisien untuk pesan bertubuh kecil, maka socket.io mungkin adalah cara terbaik untuk melakukannya karena ini adalah yang paling efisien dalam push ke klien. Ini tidak bagus di semua jenis transportasi. Misalnya, saya tidak akan memindahkan gambar atau video besar melalui socket.io karena ada lebih banyak cara yang dibuat khusus untuk melakukannya. Jadi, penggunaan socket.io sangat bergantung pada aplikasi yang ingin digunakan. Jika Anda ingin mendorong video ke klien, Anda juga dapat mendorong hanya URL dan meminta klien berbalik dan meminta video melalui URL http biasa menggunakan teknologi skala tinggi yang terkenal.
Merah - Sekali lagi, bagus untuk beberapa hal, tidak bagus dalam segala hal. Jadi, itu benar-benar tergantung pada apa yang Anda coba lakukan. Apa yang saya jelaskan sebelumnya adalah bahwa desain penyimpanan data Anda dan jumlah transaksi yang melaluinya mungkin adalah letak masalah skala Anda yang sebenarnya. Jika saya memulai pekerjaan ini, saya akan mulai dengan pemahaman tentang kebutuhan penyimpanan data untuk server, transaksi per detik dari berbagai jenis, strategi caching, redundansi, fail-over, persistensi data, dll... skala akses ke data terlebih dahulu. Saya tidak akan sepenuhnya yakin redis adalah pilihan yang lebih disukai. Saya mungkin menyarankan Anda membutuhkan orang database skala tinggi sebagai konsultan di awal proyek.
Nginx - Banyak situs skala tinggi yang menggunakan nginx jadi ini pasti alat yang bagus. Apakah itu alat yang tepat untuk Anda tergantung pada desain Anda. Saya mungkin akan mengerjakan bagian ini terakhir karena tampaknya kurang penting untuk desain dan setelah sistem lainnya ditata, Anda dapat mempertimbangkan apa yang Anda butuhkan di sini.
Amazon EC2 - Salah satu dari beberapa pilihan yang mungkin. Pilihan-pilihan ini sulit untuk dibandingkan secara langsung dalam perbandingan apel ke apel. Sistem skala besar telah dibangun dari EC2 sehingga ada bukti konsep di sana dan arsitektur umum tampaknya cocok. Jika Anda ingin tahu di mana gremlins sebenarnya, Anda memerlukan konsultan yang telah melakukan hal-hal berskala tinggi di EC2.
Amazon S3 - Saya pribadi tahu beberapa situs penyimpanan dan bandwidth yang sangat tinggi menggunakan S3 untuk video dan gambar. Ini berhasil untuk itu.
Jadi ... ini biasanya merupakan alat yang bagus untuk digunakan jika digunakan dengan cara yang benar. Redis akan menjadi tanda tanya tergantung pada kebutuhan penyimpanan aplikasi yang sebenarnya (Anda telah memberikan persyaratan nol dan database tidak dapat dipilih dengan persyaratan nol). Jawaban yang lebih masuk akal akan didasarkan pada penyusunan serangkaian persyaratan tingkat tinggi yang menganalisis apa yang perlu dilakukan sistem untuk melayani 1.000.000 apa pun. Persyaratan tersebut dapat dibandingkan dengan kemampuan yang diketahui untuk beberapa bagian ini untuk memulai rata-rata dalam penskalaan sistem. Kemudian, Anda harus mengumpulkan beberapa tes benchmark untuk menjalankan beberapa tes pada bagian tertentu dari sistem. Keberhasilan kegagalan akan tergantung pada bagaimana aplikasi dibangun dan bagaimana alat digunakan sebagaimana alat mana yang dipilih. Anda mungkin dapat membuat skala yang sukses dengan berbagai jenis alat. Heck, Facebook berjalan di PHP (well, PHP yang sangat dimodifikasi dan disesuaikan yang sama sekali bukan PHP biasa saat runtime).
