Истинският ми въпрос е, може ли горната технология да мащабира 1 000 000 съобщения в секунди (текст, изображения, видеоклипове)?
Разбира се, че може. С правилния дизайн и достатъчно хардуер. Въпросът, който клиентът ви трябва да зададе, всъщност не е дали може да се направи толкова голям, а на каква цена и практичност може да се направи и това ли е най-добрият избор.
Нека разгледаме всяко парче, което споменахте:
node.js - За приложение, ориентирано към I/O, това е отличен избор за голям мащаб и може да се мащабира чрез внедряване на много процесори в клъстер (както мултипроцес на сървър, така и мулти-сървър). Доколко практичен е този тип мащаб зависи много от това до какъв вид споделени данни имат нужда всички тези сървърни процеси. Обикновено съхраняването на данни в крайна сметка се оказва по-трудното препятствие в мащабирането, защото е лесно да се хвърлят повече сървъри при обработката на заявката. Не е толкова лесно да хвърлите повече хардуер в централизирано хранилище за данни. Има начини да направите това, но зависи много от изискванията на приложението за това как го правите и колко е трудно.
socket.io - Ако имате нужда от ефективно изпращане на малки съобщения от сървъра, тогава socket.io е може би най-добрият начин да отидете, защото е най-ефективният при натискане към клиента. Все пак не е страхотно при всички видове транспорт. Например, не бих преместил големи изображения или видео наоколо чрез socket.io, тъй като има повече предназначени начини за това. Така че използването на socket.io зависи много от това за какво точно приложението иска да го използва. Ако искате да изпратите видеоклип на клиент, можете също да натиснете само URL и да накарате клиента да се обърне и да поиска видеоклипа чрез обикновен http URL, използвайки добре позната високомащабна технология.
Redis - Отново, страхотно за някои неща, не страхотно във всичко. Така че наистина зависи от това, което се опитвате да направите. Това, което обясних по-рано, е, че дизайнът на вашето хранилище за данни и броят на транзакциите през него вероятно е мястото, където се крият истинските ви проблеми с мащаба. Ако започвах тази работа, щях да започна с разбирането на нуждите за съхранение на данни за сървър, транзакции в секунда от различни типове, стратегия за кеширане, излишък, отказ, постоянство на данните и т.н... и да проектирам високо ниво първо мащабирайте достъпа до данни. Не бих бил напълно сигурен, че redis е предпочитаният избор. Вероятно бих предложил, че имате нужда от високомащабна база данни като консултант в началото на проекта.
Nginx - Много високомащабни сайтове, използващи nginx, така че със сигурност е добър инструмент. Дали това е точно правилният инструмент за вас зависи от вашия дизайн. Вероятно ще работя върху тази част последна, защото изглежда по-малко централна за дизайна и след като останалата част от системата бъде изложена, можете да помислите какво ви трябва тук.
Amazon EC2 - Един от няколкото възможни избора. Тези избори са трудни за сравнение директно в сравнение ябълки с ябълки. От EC2 са изградени широкомащабни системи, така че има доказателство за концепцията и общата архитектура изглежда подходяща. Ако искате да знаете къде са истинските гремлини, ще ви трябва консултант, който е правил мащабни неща на EC2.
Amazon S3 - Аз лично познавам някои сайтове с много висока памет и честотна лента, използващи S3 както за видео, така и за изображения. Работи за това.
Така че... това обикновено са добри инструменти за използване, ако се използват по правилния начин. Redis би бил въпросителен знак в зависимост от нуждите за съхранение на действителното приложение (предоставили сте нулеви изисквания и база данни не може да бъде избрана с нулеви изисквания). По-обоснован отговор би се основавал на съставянето на набор от изисквания на високо ниво, които анализират какво трябва да прави системата, за да обслужва 1 000 000 каквото и да е. Тези изисквания могат да бъдат сравнени с известните възможности за някои от тези части, за да започнат основния етап на мащабиране на система. След това ще трябва да съберете някои тестове за сравнителен анализ, за да изпълните някои тестове на определени части от системата. Успехът на неуспеха в голяма степен ще зависи от това как е създадено приложението и как са използвани инструментите, както и кои инструменти са избрани. Вероятно можете да направите успешна скала с много различни видове инструменти. По дяволите, Facebook работи на PHP (е, силно модифициран, персонализиран PHP, който изобщо не е типичен PHP по време на изпълнение).
