Moje skutečná otázka zní, může výše uvedený technologický zásobník škálovat 1 000 000 zpráv za sekundu (text, obrázky, videa)?
Jasně že může. Se správným designem a dostatkem hardwaru. Otázka, kterou by si váš klient měl klást, ve skutečnosti není, zda to může být tak velké, ale za jakou cenu a praktičnost to lze udělat a jsou to nejlepší volby.
Podívejme se na každý kousek, který jste zmínil:
node.js - Pro aplikaci zaměřenou na I/O je to vynikající volba pro velký rozsah a lze ji škálovat nasazením mnoha CPU v clusteru (jak víceprocesové na server, tak na více serverů). Jak praktický je tento typ měřítka, závisí hodně na tom, k jakému druhu sdílených dat potřebují všechny tyto serverové procesy přístup. Úložiště dat se obvykle nakonec stává těžším úzkým hrdlem při škálování, protože je snadné vrhnout na zpracování požadavku více serverů. Není tak snadné hodit více hardwaru do centralizovaného úložiště dat. Existují způsoby, jak to udělat, ale hodně záleží na požadavcích aplikace, jak to děláte a jak je to těžké.
socket.io - Pokud potřebujete efektivní server push malých zpráv, pak socket.io je pravděpodobně nejlepší způsob, jak jít, protože je nejúčinnější při odesílání klientovi. Není to však skvělé pro všechny druhy dopravy. Například bych nepřesouval velké obrázky nebo videa přes socket.io, protože existuje více účelových způsobů, jak toho dosáhnout. Použití socket.io tedy hodně závisí na tom, k čemu přesně jej chce aplikace používat. Pokud jste chtěli poslat video klientovi, můžete také poslat pouze URL a nechat klienta, aby se otočil a požádal o video prostřednictvím běžné http URL pomocí dobře známé špičkové technologie.
Redis - Opět skvělé pro některé věci, ne skvělé ve všem. Takže opravdu záleží na tom, co se snažíte dělat. To, co jsem vysvětlil dříve, je, že návrh vašeho úložiště dat a počet transakcí prostřednictvím něj pravděpodobně spočívá ve vašich skutečných problémech s rozsahem. Pokud bych začínal s touto prací, začal bych pochopením potřeb úložiště dat pro server, transakcemi za sekundu různých typů, strategií ukládání do mezipaměti, redundancí, selháním, perzistencí dat atd. nejprve škálovat přístup k datům. Nebyl bych si úplně jistý, že redis byla preferovaná volba. Pravděpodobně bych navrhoval, abyste na začátku projektu potřebovali jako konzultanta špičkového databázového člověka.
Nginx - Mnoho stránek ve velkém měřítku používá nginx, takže je to určitě dobrý nástroj. Zda je to přesně ten správný nástroj pro vás, závisí na vašem návrhu. Pravděpodobně bych pracoval na této části jako poslední, protože se zdá být méně ústřední pro návrh, a jakmile bude zbytek systému uspořádán, můžete zde zvážit, co potřebujete.
Amazon EC2 - Jedna z několika možností. Tyto volby je těžké srovnávat přímo v porovnání jablek s jablky. Rozsáhlé systémy byly postaveny z EC2, takže existuje důkaz o konceptu a obecná architektura se zdá být vhodná. Pokud byste chtěli vědět, kde jsou skuteční gremlinové, potřebovali byste konzultanta, který udělal velké věci na EC2.
Amazon S3 - Osobně znám několik webů s velmi vysokým úložištěm a šířkou pásma, které používají S3 pro video i obrázky. Na to to funguje.
Takže ... toto jsou obecně pravděpodobně dobré nástroje, které lze použít, pokud se používají správným způsobem. Redis by byl otazníkem v závislosti na potřebách úložiště aktuální aplikace (zadali jste nulové požadavky a databázi nelze vybrat s nulovými požadavky). Odůvodněnější odpověď by byla založena na sestavení souboru požadavků na vysoké úrovni, které analyzují, co systém potřebuje, aby byl schopen obsloužit 1 000 000 čehokoli. Tyto požadavky by se daly porovnat se známými schopnostmi některých z těchto částí, aby se začaly při škálování systému. Pak byste museli dát dohromady nějaké srovnávací testy, abyste mohli provést nějaké testy na určitých částech systému. Úspěch neúspěchu by závisel na tom, jak byla aplikace vytvořena a jak byly nástroje používány, stejně jako na tom, které nástroje byly vybrány. Pravděpodobně můžete vytvořit úspěšnou stupnici s mnoha různými typy nástrojů. Sakra, Facebook běží na PHP (dobře, vysoce upravené, přizpůsobené PHP, které ve skutečnosti není typické PHP za běhu).