Масштабирование WebSocket-серверов на Go

меня зовут александр и малин я из компании авито и сегодня буду рассказывать вам про масштабированию все нагло почему об этом рассказываю почему мне самому эта тема очень интересна ну я являюсь автором проекта центрифуга это достаточно популярный сервер real-time сообщение где основной протокол это websocket сервер используется в достаточно большом количестве российских компаний достаточно известных это sports.ru юла в других проектах mail.ru во внутренних проектах году и частичного vita она и за рубежом нам яркий пример это спутаем а сейчас сервер достиг 2 версии базируется на библиотеки смотрю фич собственно оно доступно всем город рабоче com посмотрите что это такое в конце доклада мы еще к этому вернемся задаем и стендом где будет миллион websocket соединений развернутый в q бернетт сервер будет оставаться как раз на библиотеки смотрите и ещё я работаю в мессенджера with a так же у нас там основной протокол общения с пользователями то websocket 12 миллионов уникальных посетителей версия для всех платформ современных достаточно нагружены приложения им принципе мы счастливы только там о чем сегодня доклад доклад будет о том с какими проблемами я и мои коллеги столкнулись при работе с окнами на голо в частности и вообще при работе с большим количеством постоянных соединений надеюсь какие-то техники диски технике вы сможете применить своих текущих или будущих проектах пару слов о том что такое в соке websocket это полна дуплексная клиент-серверное соединение что значит полнодуплексный значит а с двух сторон можно в него писать и не опасаться коллизий используется когда нужен быстрый обмен сообщениями между клиентом и сервером это чат и это коллаборативный приложение а сток акции стремится часто клиентам через websocket а ну почему применение массы думаю все знают все знаете это стартуют и псаки соединения с и степи запроса версии 11 важно что 11 потому что и степи 2 не имеет механизма апгрейт есть спецификации которая позволит стартовая тебе псаки то и работать через эти два но пока это еще один и один собственно клиент-сервер обменивается специализированными заголовками после чего у нас получается чистый tcp сессия по которой гуляют websocket фрейм и собственно высокие ты-то фреймы протокол и через фреймы мы можем передавать как текстовые так и бинарные данные почему вы вообще можете захотеть использовать и talked своих приложениях на первых это достаточно простой протокол на кости вы перейдете по ссылке там будет статья армина ван hero кто не знает пианист известный нет это не став здесь окей очень крутая статья где скрываются не которые не очевидны при усложнении websocket протокола советую почитать и топит работать на всех современных платформах и что немаловажно в браузере и собственно то что websocket работает в браузере и часто является решающим фактором почему его выбирают как основной транспорт и а у викс актив небольшой вверх от по сравнению с чистой теперь сессий то есть фрейминг websocket протокола добавляет от двух до восьми бать всего к вашим данным собственно что такое масштабировать сайтов для меня это не вопрос чистой производительности и большого количества соединений на сервер да и то лишь это задача о том что нагруженный websocket сервер должен решать определенный набор задач собственно попробовал сформулировать какие задачи может хотеть решать нагружены веб-сервер держать большое количество соединений кажется понятно отправлять большое количество сообщений не всегда но логично да что есть применение когда нужно отправить много обеспечивать fall back websocket нет даже сейчас 2019 году не все пользователи могут соединиться по протоколу websocket мы об этом сегодня поговорим аутентификации инвалида ция соединений соединение может быть установлена один раз и висеть неделями нужно его инвалидизировать и так же мы об этом будем говорить сегодня переживать массовый reconnect высокие приложения отличаются от стандартных оч типе серверов тем что у вас масса постоянных соединений у вас не стоит ли запрос у вас стоит в приложении и собственного также посмотрим на такую проблему как массово reconnected тысяч сотен тысяч миллионов пользователей что можем с этим сделать и иногда нужно не терять сообщение при reconnect опять же websocket приложения state of например если мы возьмем тот же чад также messenger да если потеряется websocket фрейм при реколлекции кажется что пользователь счастливы не будут ведь это было сообщение до которым летела часто можно восстановить состояние из базы основной так делают но мы посмотрим на некоторые нюансы которые здесь есть особенно при массовом reconnect прежде чем на ваш сервер придут тысячи соединений по websocket а вам нужно озаботиться тем что затемнить операционную систему придется какие здесь есть моменты первый это лимит файловых дескрипторов нам первое на что в сент кольца каждое соединение отъедает файловый дескриптор в операционной системе и по умолчанию лимит не такой уж большой 256000 24 файловых дескрипторов собственно по ссылке вы можете посмотреть как от лимит поднять хотите больше соединений поднимайте лимит тут первый совет если вы знаете что у вас операционная система не позволяет принимать соединение больше чем например 65535 да то есть такой лимит выставлен то не принимайте своем websocket server-side не не сверх этого лимита иначе когда у вас все пойдет плохо она пойдет вы не сможете даже в попросите да потому что заход в прав это еще один файлах дескриптор который у вас нет следующий момент это эфемерные порты обычно проблема появляется на связке load balancer ваш websocket сервер и заключается в том что вот балансер не может открыть еще одну websocket соединениях до вашего бэг-энда высоким бэг-энда потому что у него исчерпались порты портов с которых можно открыть и день по умолчанию не так много там порядка десяти пятнадцати тысяч плюс есть такое состояние so keep their weight когда его нельзя переиспользовать так что опять же по ссылке посмотрите как это затюнить есть контракт эйбл на каждый linux машине стоит ай-петри был состав которого входят в ренборг нет фильтр и там каждое соединение трека ица отдельной записью да то есть контролирует какие соединения у нас установлены с сервером также размер эта информация ограничен по умолчанию его надо затемнить и также возможно вы захотите затяните sistelle сетевой стек linux собственно есть масса статей в интернете как тюнить сервер под высокую нагрузку и опять же это возможно вам нужно сделать давайте перейдем к уровня приложения уже до что мы вообще знаем прописать это наверное первую очередь то что пакет x над websocket считается деп река этот стандартным де-факто является горилла websocket практически все приложения которые сейчас есть используют это именно этот пакет для работы в сокетами библиотечка габбасова с от сергея камардина решает некоторые дает возможность сделать некоторые оптимизации на которые гориллы websocket не способны но об этом немножко поговорим и также есть новый пакет на hair websocket активно развивающейся автор очень активен и даже сделал попытку maintain нить горилла websocket чтобы новых пользователей перенаправлять на свою библиотеку так что обратите внимание на этот пакет реального у него больших будущее но как я сказал горилла websocket везде да и в чувство моих примеров сегодня будет основываться именно на ней давайте посмотрим на простой websocket сервер мы говорить будем сегодня серверах с чего начинается но у нас есть свечи тебе обработчик как я сказал и псаки то это стартует с и степи функция апгрейт мы вызываем функцию апгрейт и внутри of great мы а точнее библиотека горилла websocket а делает хай джек соединения то есть берет его под свой контроль и отдает нам connection на самом деле эта структур ковра 15 вaм соединением далее обратите внимание что мы передаем настройки а грейдеры буфер says играет буфер says это размер буфера в которые будут использовать для ввода-вывода для записи для чтения для чего для того чтобы уменьшить количество сетевых вызовов обратите внимание на то что эти буферы будут прибиты к вашему соединению железно да то есть они увеличивают размер потребления памяти мы к этому вернемся обычном и оборачивать сведение в какую-то нашу структуру уровня приложения дат назовем ее клиент в конце хэндлера мы закрываем клиента и не забываем там же закрывать соединение стартуем отдельную грудь и ну на это запись при чем нужно помнить что горело websocket не поддерживать конкурентное чтение и запись да и блокируем и степи handler методом рид рид вычитывать данные с websocket а до тех пор пока не случится ошибка как только случается ошибка вы выходите из цикла рид и ищите pichunter завершается давайте посмотрим на такую проблему как высокий средний требовательный к ramdac оперативной памяти она поднималась не так давно в бокам unity и вообще кто-нибудь читал миллион websocket и попс of статьи сергея камардина отлично отлично на самом деле для тех кто не читал обязательно почитайте если вам интересна тема для в сокетов и даже если не интересно это просто шедевр инженерной мысли на самом деле и есть еще одно выступление вот израильтянина иная иран юная который по сути взял идеи сергея камардина и приложилась на иностранный лад дописал примеров также стоит посмотреть собственно чем говорится в статье о чем говорил сергей о том что минимальное потребление памяти наверх и соединения складывается из следующих факторов это 2 га рутины до 1 читают другая пишет это еще тебе буферы на чтение на запись от стандартной библиотеки г до которая лоцируется потому что без секса и дней начинается сочтите пи и это буфер и который мы в приложении используем для ввода-вывода и того получается если сапр активировать на миллион соединение минимум 20 гигабайт достаточно большая цифра не так ли на самом деле это самый плохой сценарий сгорел websocket мы можем перес пользовать буферы для этого мы переспорить буферы которая лоцируется и чтoб с сервером до стандартной библиотеки для этого мы рид буфер сальса в районе срастаясь передаем нулями собственно переиспользовать буфера горела websocket может потому что если мы посмотрим внутрь функция апгрейт то когда происходит хай джек возвращается объект буфере 3d raider который содержит как раз те буферы которые типы серверов на лоцировать для обработки запроса изначально при всем при этом да у нас все равно остаются 2 га рутины у нас буферы прибиты к соединениям библиотечка gap вас в с от сергея камардина позволяет отойти от этих проблем и позволяет сделать 2 оптимизации первое это зира копи апгрейт то есть мы убираем использовании стандартного чтить и сервера гоа и полностью сами парсим ешьте т.п. при этом не аллоцировать дополнительной памяти второе это возможность использовать и пол то есть и пол полностью организованный носи сколах до который использует api и linux пол и тем самым мы можем отойти даже от двух грудь in которые одна из которых пишет другая читает а также мы можем перес пользовать все буферы о которых шла речь на самом деле от буфера прибитого на чтение клип секс соединение может помочь избавиться от это еще на гитхабе в репозиторий ага как только она разрезал лица у нас будет возможность бустеры переиспользовать а от врать буфера уже сейчас сгорела websocket мы можем избавиться используя sing пул вам грейдеры тогда брать буфер будет буферы на запись будет перес пользоваться однако есть ещё одна а еще один трюк который со стандартной библиотекой год позволит очень сильно сократить потребление памяти мы даем джесси поработать что это значит это значит что последний момент да когда у нас происходит чтение мы стартуем чтение в отдельной грудь и не тем самым ешьте pichunter завершается как только из степи hander завершается хотя давайте еще один момент обратимой что здесь мы используем buffer и 1024 да потому что на самом деле стандарт те буферы которые используют стандартная библиотека это 4 килобайта на чтение за запись везли websocket приложений кажется что сообщение обычно меньше гораздо поэтому мы можем используется поменьше так вот когда завершается и степи handler мы даем возможность garbage collector у прибрать за нами убрать эти объекты на которые уже ссылки мне нужны и собственно вот этот профиль это профиль того когда мы не стартовали в рутину в последний момент и а вот это профиль и new space то есть памяти потребляемый процессом когда мы стартовали отдельную грудь и ну кажется что разница видна невооруженным глазом но если мы подсветим то вот столько объектов garbage collector получает возможность собрать вы можете посмотреть больше примеров и цифры вот в этом репозитории но грубо говоря вот такой техника вы можете сэкономить до сорока процентов оперативной памяти ok вы сделали так как я сказал да стартанули в отдельной грудь и не но при этом хендлер завершается в этот момент контекст который содержится в ищите при запросе отменится вообще контекст проникает во все уголки до нашей с вами разработки я не делюсь если вот сейчас посмотрю а там лежит контекст какой-нибудь ну кажется естественным что вы можете взять и прокинуть контекст далее по стыку вашего приложения ведь он может содержать какие-то полезные данные которые вы в него напихали в рамках middleware да и так же вы возможно скорее всего захотите отменять тяжелые действия которые вас есть websocket сервере основываясь на том когда отменяется контекст из и кажется что вы ожидаете что отменится он когда соединение закрывается в данном случае он в контекст закроется сразу как только у нас завершится еще хендлер на самом деле не проблем мы можем воспользоваться крутой фиче go оборачивать интерфейсы и менять реализация методов посмотрим на интерфейс контекст здесь нас в первую очередь интересует метод дан до который у него есть и что нам нужно сделать на самом деле нам нужно создать свой контекст который мы назовем кастом концов контекст обернуть изначальный контекст передать в него канал который будет закрываться тогда когда соединение реально закроется мы сами это знаем сами управляем и переопределим метод дан в этом методе дан мы возвращаем как раз тот канал которую закрытием которого мы управляем и все что нам нужно дальше сделать создать такой контекст прокинуть а дальше по стыку нашей программы и для других частей программы этот контекст будет все тем же интерфейсом однако отменяться он будет тогда когда нам нужно перейдем к тому что нужно рассылать много сообщений тут я америку не открою вам нужно использовать эффективный формат стерилизация выбор у вас на самом деле большой это джейсон про табов massage pack сами выбирайте что я хочу сказать здесь наверное что не стоит зацикливаться на стандартных реализациях сериализация посмотрите в сторону библиотек которые генерируют код яркий пример тут google про того который позволяет ускорить реализацию про табу в который сам по себе достаточно быстрой в пять раз да потому что не использует модуль reflect a использует код генерацию собственно подобные же библиотеке есть и для джейсон я думаю вы все знаете или джейсон fr джейсон собственно на этом можно много сэкономить еще одна проблема с которой мы вовек боролись мессенджеры и успешно побороли и это инвалидов соединения вообще да откуда проблема приходит и в соке соединения от пользователя она устанавливается и может висеть неделю что может произойти пользователь может открыть несколько табов браузера и в одном из них разлогиниться пользователи могут заблокировать в админке заблокировать его учетную запись за как за какое-то нарушение и всякие соединения продолжают жить опять же какая тут какой тут может быть выход вы можете подписаться на события если у вас есть какая-то шина данных например на свои то есть кафка как шина данных мы подписались на такие события и отключаем websocket а но если у вас такой шины данных нет то можете просто периодически проверять что и все соединения активно это дороже но тут вам нужно найти thread'ов до между производительностью и тем интервалом с которым вы проверяете каждое висящие соединение сейчас идет 2019 год а пользователи все еще не могут подключиться по websocket абсолютно все и проблема на самом деле не только в том что существует браузера до старая internet explorer 8 9 турне поддержки в socket а есть еще и корпоративные пользователи с ними во все беда то есть работодатель ставят своим сотрудникам доверенный рутовый сердце кат на компьютер далее имеет возможность перешив ро вать ls трафик даже тело из трафик на своих процессах причем proc прокси режут websocket соединения специально или потому что там старое программное обеспечение непонятно но такие примеры спрашиваю сплошь и рядом когда работал в мудру был еще один случай расширение браузерные это блок заблочен все соки соединения на домены и поддомены mail.ru почему потому что мои коллеги росла через высокие соединения рекламу и нас спас тогда только вы чтите fall back самый простой способ добавить ешьте fall back в приложении нагло как мне кажется эта библиотека 100 г с г а есть либо сок джесс клайн для java script которая проверено временем production рейде и собственно она требует сер для реализации вот как раз тот же с город усердно реализация до библиотеки сок джесс и если не отсоединение повив socket то будет установлена либо их сейчас тримминг соединения либо ансар соединения long polling еще несколько эзотерических транспортов переходим на нг центральной части моего доклада это то что производительность это не масштабируемость да как бы мы не оптимизировали приложение как выманить его ли операционную систему а сколько бы не экономили на оперативной памяти оно настанет момент когда вам нужно будет масштабировать вошли всех сервер на несколько и даже в плане того что отказывать в плане отказоустойчивости вам все равно нужно иметь несколько серверов да например один упал соединение перетекли на другой кажется это очень важно и мы будем об этом сейчас говорить какая здесь основная проблема вот мы добавили websocket серверов но пользователя ваши могут быть подключены к любому инстанцию веб сайт сервера а вы хотите отправить пользователю сообщению что вам делать наверное первые до что придумайте то публиковать на все но это не масштабируется это не просто не масштабируется лет еще не удобно потом что вам нужно знать о всех инстанциях вашего websocket сервера а которые к тому же могут динамически меняться тут дело в дело вступают брокер сообщений брокер попса брокер сообщений давайте посмотрим на картинку до что здесь изображена на самом деле gopher и это ваш websocket сервер несколько инстансов все они связаны через центральный брокер собственно центральный брокер работа по модели pops up когда соединение приходят наверх и сервера они инициализируют подписку на свой какой-то персональный топик в брокере собственный брокер знает о всех таких подписках и когда вы делаете публикацию сообщения вы делаете и через брокера и собственно в этот момент через механизм pops up сообщение долетают только до тех websocket серверов на которых оно должно где есть клиенты реальность заинтересованы в этом событии и она доставляется по писать эту клиенту вообще когда я готовился к этой статье к этому выступлению я прочитал много статей про масштабирование фактов и большинстве из них рассказывается про центральный попса брокер до для масштабирования однако конкретики нет часто говорят ну а для брокера используйте rabbit или редис на этом повествовании завершается я подумал и решил добавить больше конкретики в этот вопрос и давайте вообще посмотрим что нам нужно от брокера первое это конечно же производительность тут все логично сохранении порядка сообщений тоже важное свойство которое обычно нам нужно масштабируемость брокер мы хотим чтобы брокер сам по себе масштабировал ся и был отказа устойчивым мы хотим чтобы он поддерживал миллионы топиков одновременно ну потому что чистить частые space когда у каждого соединения есть свой персональный канал да мы хотим лишь рассылать сообщения конкретному пользователю в этот момент если вас миллион востоке соединения у вас появляется в шоке миллион топиков брокера мы хотим чтобы брокер мог поддерживал cacilie стрим сообщений об этом мы говорим поговорим чуть позже что это такое от чего это спасает и необходимость писать встроенной процедуры большой бонус опять же я расскажу как нам это помогло мне в центрифуге ином смысле джавитом какие есть опции первое это ribbit ribbit будет работать ребят будет работать пока у вас небольшая нагрузка собственно почему на каждое соединение вы будете создавать там очередь и на самом деле это не масштабируется когда у вас появляется множество и пользователей когда у вас большой connect disconnect the right да то есть вы создаете бенди тиан биндить и очереди и например в мессенджере авито когда я пришел на sender у нас там использовался rabbit i'm cool и было 100000 подключений вот на 100 тысячах подключения ребятенку потреблял 7770 то есть это огромная цифра забегая вперед мы заменили ребят на редис и получили 0,3 и драться по ул то есть это более чем x 200 персон из boost кафка кажется вполне натуральным попробовать кафку для этого но тут мне кажется что это может стать вертелом для многих приложений потому что кавказ охраняет стрим на диск консьюмер кафки работают по пулу модели что может быть неэффективным когда вас миллионы топиков и вам надо пулять из всех данные и кафка предпочитает более стабильную конфигурацию своих топиков потому что в динамике да когда вас появляется субскрайб ансаб скраб у вас топике создаются на лету и удаляются и кажется что во многих случаях лучше с кафкой так не делать на 13 тримминг вот тут что мне самому кажется а над вы вполне можете использовать если вам нужен андре-луи был попса падает а производительное решение написан иногда кажется что это взлетит над streaming я бы не использовал почему потому что я посмотрел код над streaming и в достаточно критичных для себя местах нашего нашел ту ду который не имплементировать определенную логику при восстановлении сообщений для меня это показалось критичным и я бы не использовал нас 3 мин для задачи если нужно восстанавливать сообщений тарантул кажется хорошей хорошую и альтернативы для в качестве брокера потому что у мега производительный у него есть logic на стороне сервера вы можете гибко писать логику и с недавней версии он поддерживает push со стороны брокеров соединения попробуйте на самом деле на чем я остановился и начнем с то есть мы в мессенджере это редис почему редис потому что он производительный в том числе у него мега производительный pops up он стабильный что самое главное предсказуемый у него есть сентинель для high availability он позволяет писать атомарного процедуры и структуры данных позволяют хранить кэш сообщений на самом деле опять возникает вот этот вот кэш сообщение для магические мы к нему скоро вернемся расскажу что такое тут есть один совет если вы делаете центральный брокер попса брокер то используйте одно или пул соединений между websocket серверами вашим брокером что я видел часто в примерах на гитхабе как пишет код это пришло новый websocket соединения открываем новый connect среди сам или с каким-то другим брокером так делать не надо это анти паттерны и масштабируется используйте одно или пул соединений с брокером и в этом месте вы можете использовать максимально эффективный формат стерилизации сообщений до для общения между websocket сервером и вашим брокером здесь вам не надо задумываться о том чтобы формат был человека читаемый да потому что его не увидят не ваши frontend разработчики не ваши тестировщики вы можете сугубо internal вещь можете максимально делать и эффективный брокерам мы еще вернемся а давайте поговорим о другой проблеме это проблема массового реконнекта массовый reconnect это когда у вас сотни тысяч пользователей онлайн подключены и psx соединением миллионы пользователей да и вы можете например раскладывать свой websocket сервер до выкатывать новую версию у вас могут ли ладится внешние балансиры что при этом происходит при этом соединение рвутся и лавину пользователи приходят вам на backend перри подключаться причем они не просто хотят перри установить соединение они еще скорее всего хотят восстановить свое состояние потому что websocket приложения не стоит fulda тоже messenger да я хочу получить все сообщения которые я пропустил пока отсутствовал это большая проблема давайте посмотрим как с ней можно бороться несколько техник первое наверное всем вам известно это обязательный экспоненту быков на клиенте клиенты должны перри подключаться с iq специально увеличивающимся интервалами 2 если вы знаете что у вас на бэг-энде какой-то ресурс деградируют при конкурентном доступе поставьте туда самый простейший bound семафоры ограничьте этот конкурентный доступ делается на гоа элементарно доконал с буфером и все его но зато в вас не деградирует систему то что пользователь предположим переключиться чуть позже ну окей 9 аутентификация как способ не нагружать бы концессии как часто что часто происходит приходит connect на сервер его нужно аутентифицировать вот инфицируется вы его через бы концессий причем бы концессии может быть как развёрнут как локально так и это может быть поход сторонний микро сервис джейсон gap talking позволяет избавиться от большой нагрузки на бы концессии потому что у jason wade токина есть expiration time да когда к вам приходят пользователи он пытается от инфицироваться с использовать же сон gap токен и он валиден вы можете не ходить ваш бэкон сессии и если вы разумного выберите время которое через который джейсон where токина истекают да то большая часть из них при реколлекции окажется валидный и вы в конце сине идете все хиндли ти внутри go добиваетесь максимальной производительности соединений вас сотни тысяч пользователей приходят и хотят перри подписаться в этот момент вы точно хотите перед подписать их как можно скорее это хорошо вам хорошо пользователям например случае с редисом мы можем это делать используя regional planning да то есть редис pipeline к это отправка нескольких сообщений нескольких запросов редиса за один запрос и мы это делаем центрифугу это делает нас инжира вид это делает и мы используем пайпа ник на полную в этот момент и нам с этим помогает такая техника кошмар бочанг такой паттерн который позволяет из нескольких независимых источников грудь и наших соединений собирать какие-то запросы да у нас есть канал из которых приходит какая-то работа и мы знаем что эту работу мы эффективнее выполняем в пачках да то есть по несколько штук мы читаем из канала записываем как объект который нам нужно обработать баччан ушла из какой-то далее мы продолжаем вычитывать из этого канала данные до тех пор пока у нас башни пред перерастет максимальный размер свой или пока в канале не останется данных да то есть это select это позволяет сделать должны в итоге копим батч и на выходе у нас получается пачка объектов с которой мы можем работать ну например послать pipeline запрос бредишь вот здесь вот есть ссылочка на мой репозитории накид хайга где можно посмотреть как smart починкой pipeline вместе живут там вот есть примеру бенчмарки можете посмотреть если заинтересовал эту тему ok then дальше кэш сообщение стал играть пиковую нагрузку собой я вот мы до него добрались что это такое как я уже сказал пользователи хотят восстановить свое состояние они хотят не пропускать сообщение которые были в момент реконнекта вы можете хранить стрим сообщений которые вы публиковали в каком-то кэше да что-то вроде ним каша что-то вроде киева или старриджа я собственном extreme сообщений храним время здесь в одессе в структуре данных лист а как вариант начинает среди 100 50 мы могли бы использовать стрелы но центрифугу массажа авито мы делаем следующим образом происходит публикация а идет запрос в редис там работает лап процедуры которая нам позволяет атомарный сделать те вещи о которых я сейчас буду говорить первые мы добавляем сообщения в структура данных лист да как вы видите здесь уже три сообщения у каждого сообщения при этом есть инкрементальный номер мы его увеличиваем также в десятом арно и далее мы публикуем сообщение в попса при одессы в этот момент она улетает в паб soft tabs об долетает до клиента если он подключен как только клиенты reconnective они передают номер сообщение которое они видели последним и собственно мы идем в рейде смотрим в лист если есть сообщение мы восстанавливаем их клиентов из этой структуры данных как будто он даже не был отключен да то есть по сути он получает весь стрим сообщений которые ему в интервале отсутствие были высланы помощи эта операция и если кто то знает до что это то что редис pops up это на самом деле это мост vans delivery мы в мессенджере в центрифуге сделали наряде сильно вот таких вот стримах это лист vans я подробнее про это расскажу на холодный через месяц вот но на самом деле это то есть можем это лист вам сделать нарядись и таком стриме и как бонус мы можем на таком стремясь сделать и fall back для websocket а собственно во vita в messenger мы именно так и делаем то есть мы у нас есть три таких сообщений для каждого топика и наш полинг 0 приходит и мы и z в пользователь приходит мы спазме степи полинг для fall back и забирая данные из этого стрима и отдает их клиенты собственно на этом же сам механизм можно и long polling пас построить это идет как бонус вот вот это вот каша и сообщений вот этот график это график которой случается при раскладке нашего сервиса случался точнее когда у нас был ребятенку и 100 тысяч пользователей а как мы видим ничего хорошего тут не изображено а вот так стало когда у нас стал редис и на самом деле уже 500 тысяч пользователей то есть раскладку происходит совершенно бесшовно для наших клиентов и времена ручек ну совсем не растут все что я здесь рассказывал на самом деле так или иначе используется внутри центрифуга сервера если вам не хочется заморачиваться самим писать все это да то можете использовать на 3 фуга это отдельно стоящей сервер который принимает connect и от пользователей имеет опять чтобы вы сообщение пользователям отправляли при этом он хорошо встраивается в любую микро сервисную архитектуру так что можете посмотреть как я говорил он основывается на библиотеки центре фич и вы можете использовать библиотеку смотри фичи ваших приложениях а единственное что да это уже не совсем библиотека потому что она задумывается о масштабируемости за вас имеет встроенный ряде сын джон и это на кэш сообщений это уже скорее framework то есть понятно что мы там gopher ада не очень любим фреймворке использовать ну смотрите сами а и чтобы как-то не быть голословным я сделал дима стенд кубер на это с который использует библиотеку сына 3 лично серверы и хотел добиться следующих целей 1 миллиона соединений от пользователей 30 миллионов сообщений в минуту которые да будут доставлены пользователям да то есть это 500 тысяч сообщений в секунду при этом я поддерживал конец disconnect а рейд по 200 тысяч в секунду до приблизил этот тем цифрам который у нас мысль джаве то есть и при этом я следил за ли танцы доставки сообщений чтобы она не перерастала 200 миллисекунд на самом деле тут будет небольшой таймлапс подробнее наверное вы сможете посмотреть уже после на какие конкретные цифры здесь используется нас усеченном буров connections до быстро дорастает до миллиона далее мы ждем какое-то время посмотрим что система ведет себя стабильно затем начинаем публиковать сообщения мы deliver a до график до 30 миллионов сообщений в минуту при этом смотрим на серве циpкa нам на память и так далее и что самое главное смотрим на брокер до наряде в данном случае используется 5 инстансов редиса то о чем я не рассказывал в докладе но мы сортируем редис да то есть это шарди ранее происходит по и мне топика и при этом мы видим что ле пин стене дорастает до роста и до 200 миллисекунд и там примерно останавливается до когда рейд сообщений достиг 30 миллионов чуть больше цифр есть на этом слайде потом если что посмотрите кому интересно также я планирую это потом опубликовать и и конфигурацию железа тоже предоставлю кажется что это достаточно весомые цифры то есть по большому счету железо тут ушло на один современный сервер который используется в пройден что вы можете вынести первое это дайте джесси поработать на благо потребления рам для то о чем я говорил мы можем сказать старичок приберись за нами мы тут немножко намусорили и на самом деле чем раньше мог сделать им лучше ведь нам вчера ему все равно garbage collector у работать поставки соединения завершится не откладывай на завтра то что можно сделать сегодня используйте эффективный компактный формат стерилизация используйте брокер сообщение для горизонтального масштабирования причем выбирайте тот что подходит для вашей задачи подумайте над необходимо стричь tefal bk головин угли коннектов можно и нужно переживать и посмотрите сторону центрифуга если вам нужно рабочее решение сейчас вторая версия очень даже хороша джейсон протокол про табу в протокол все что вы хотите и масштабируется среди сам все о чем я рассказывал что там есть так мышцам и связаться спасибо [аплодисменты] саша спасибо за доклад мне очень понравилось я слушал его прямо с удовольствием мне кажется рассказала всех граблях на которой наступил спасибо так держи нашу матрешку специально для докладчиков ты же мне и до дипломной пожалуйста доклады потому что и придется вывод с запоминая пожалуйста вопросы тебе придется выбрать самый лучший если у нас вопрос полно вопросов на последнем ряду добрая спасибо за интересный как так вот вопрос про пройдись мы когда делаем подписку в рай десна попса пну разыне открываем новые типы соединения нет ни от мультиплексе руется через одно соединение все да это ну это появилось до равно давно всегда так было наверное хорошо спасибо вопрос рядом на самом деле когда средства мы работаем самый эффективный способ это именно работа через одно соединение потому что реддит однопоточный и там чем больше средней на него приходит тем он больше деградирует вот так что это все-таки это давно да здравствуй пасибо за доклад очень интересно грузим из financing и такой вопрос вот обсуждали разные брокеры но я ничего не услышал про пульсар граждан пульса apache пульса и довольно просто хорошо подходит именно под этот кейс потому что он хорошо переживает там миллионы топиков и изучали ли вы его пробовали спасибо нет я к сожалению опыта не имел поэтому его никак не упомянул здесь возможно да он подходит и на самом деле выбора брокеров много да там и актив и мку есть и еще форки редиса многопоточные то есть я просто постарался упомянуть те что на слуху у меня наверное да вот пульсар возможно подойдет я посмотрю на него тоже не спасибо спасибо привет спасибо за доклад очень круто было вопрос про масштабирование я как пол услышал выстелить этапа топиком был ли такой кейс что какой-либо из топиков был супер нагружен и какая-то часть реплика отваливалась как кода в принципе так и редиса потому как я понимаю что не просто по топиком скиллинг идет неравномерные разные под из сервисов они еще подписаны на разные получаются куски редиса и все это как-то очень запутано на самом деле по закону больших чисел до обычно это выравнивается и тут есть один нюанс который связан со спецификой приложения это websocket сервер и чаще всего через 1 топик нет смысла гнать больше там чем 30 60 сообщений в секунду потому что по сути там 60 сообщений в секунду до этого достаточно чтобы сделать любую real-time websocket игру наверх на стороне клиента и там смысл гнать тысячу например сообщение через топик большого нет практического то есть это не тут спасает именно специфика системы заточены под клиентское использование когда из канала должно приходить не так много сообщений 3060 в секунду вот поэтому супер нагруженных топиков не бывает до неравномерное распределение да может быть да то есть но на практике пока не сталкивались пока закон больших чисел спасать нас какое количество плодов определяете для того чтобы увидеть и портов хватило а количество бора лакшми наших лекциях серверов и а вот количество кодов и апсо кассиров неважно да то есть на сервер может принять сколько угодно входящие соединения если выкручен правильное и лимит контракт и тут эфемерные порты не играют роли эфирные порты появляются проблемы эфемерных портов появляется со стороны клиента то есть именно клиент когда открывает много соединений с одним портом сервера вот там вот там нужно же виртуальный api или просто несколько реальных айтишников вогнать и тогда тем самым можно увеличить количество вот этих вот клиентских открытых соединений ну либо просто количество доступных портов увеличится там до 65000 это можно сделать вот то есть на сами на серверной стороне проблемы с портами не бывает это именно клиентская я понимаю что как бы порты они не используется на то есть на одном я просто вот девиз эфемерными портами не очень понял а ну да то есть на самом деле в тисе пи как ты теперь connect состоит из клиентского порта клиентского и печника серверного порта и серверного пик айпишник а да то есть вот такая связка из четырех значений и проблем возникает тогда когда клиент а в данном случае это вот load balancer да как я говорил начинает открывать много соединений у него клиентский порт вот это вот часть в этой связке по сути там 10000 по умолчанию он может таких создать и пока вы не выкрутить и вот этот вот финал port range да только 10 тысяч дней на от лат балансира может спроектировать она ваш websocket сервер ю-чат за на самом деле даты старики момент сапатеро ты там один порт используется на сервере один порт насаживать всегда один порт если еще вопрос у нас вот здесь на первые всегда на самом деле но большинстве случае спасибо за доклад у меня такой вопрос ты показывал в примерах когда там инициализироваться апгрейда до в гареме во плоти там можно было указать размер буфера на записи на чтение если какие-то рекомендации вот но как вообще какие значения можно подобрать то есть может быть нужно смотреть там на статистику размеры сообщений присылаемых и когда я думаю статистика размер сообщение вполне себе играет роль и как бы в зависимости от этого уже можно подбирать размер надо все понял спасибо еще вопросы здесь справа спасибо за доклад ты указывал что если закрывать хендлер сразу the garbage collector придет и почистить все но кажется что если у вас есть такая ротация клиентов то есть они ж не вечно вас висят то это особо не должно влиять потому что они меняются и но все равно он будет посещать хоть и хантер будет висеть но он просто будет позже откладывать на самом деле вообще garbage collector сразу не придет и не по чести да там есть га джесси нужно на практике это дает прирост до сорока процентов то есть коннектор количество растет garbage collector иногда приходит удаляет и по сути вот эти данные которые на лоцировать и стич тебе сервером да это они ведь нужны только на момент до апгрейда то есть у нас прошел апгрейт мы эти данные удаляем это в данном случае у нас уже получается как будто garbage collector работает связке с обычным хотя по серверам да то есть на обычном ктп сервере память не дорастает до гигабайт о чем я говорил а здесь мы просто как бы даем вот это вот почисть а дальше мы уже работаем с соединением сами да и там уже конечно же используем какой-то память но garbage collector нас спасает и как будто мы работаем с сервером данном случае это зависит от промежутка когда висит вот этот connection сколько в среднем средний пользователь сложно сказать ну пусть сутки то есть ну каждом приложении по-разному же это мобильные клиенты нет точной цифры не могу сказать зависит от специфики приложения сколько средняя сессия пользователя длится но обычную всякий connection это длительный collection то есть это не 200 миллисекунд там как вы чтите запросе это несколько минут час сутки и ну понятно просто сутки это очень странно у него браузер сутки открыт такие должно быть не так много на самом деле таких много то есть люди на кого как пользоваться вид приходит на работу включают браузер он у них висит целый день то есть на самом деле у нас ночью да вот если мы посмотрим на график connection of ночью у нас коннектов ночью всегда есть постоянно рейд 2 тысяч 200 до то есть люди оставляют открытыми вкладки и висит connection поэтому внизу планов оптимизировать висячие не нужно на самом деле можем да то есть если коннекта неактивен то почему бы его не отключить это имеется ввиду можно до отключать и мне кажется в принципе в каких-то кейсах это хорошая практика потому что мертвые коннектор зачем они сдались но мы так не сделали до этого мы не дошли спасибо коллеги и я думаю что нас кончилось время и вы лучше поймаете сашу в кулуарах саша пришло время выбрать самый лучший вопрос мне понравилось вопрос про распределение нагрузки по топиком где там про закон больших чисел отвечал так как то его задавал для туда приходите к нам отлично представься пожалуйста расскажи про свой вопрос denis меня зовут я повторить вопрос ответь просто ну у меня наверно почти похоже проблема что шарды не всегда просто логично распределять по ним нагрузку по ним данные раскидывать и зачастую таких простых вопросов типа давайте по дням в этом по алфавиту не работает и соломинка эта книжка для тебя и спасибо большое саше за доклад

меня зовут александр и малин я из компании авито и сегодня буду рассказывать вам про масштабированию все нагло почему об этом рассказываю почему мне самому эта тема очень интересна ну я являюсь автором проекта центрифуга это достаточно популярный сервер real-time сообщение где основной протокол это websocket сервер используется в достаточно большом количестве российских компаний достаточно известных это sports.ru юла в других проектах mail.ru во внутренних проектах году и частичного vita она и за рубежом нам яркий пример это спутаем а сейчас сервер достиг 2 версии базируется на библиотеки смотрю фич собственно оно доступно всем город рабоче com посмотрите что это такое в конце доклада мы еще к этому вернемся задаем и стендом где будет миллион websocket соединений развернутый в q бернетт сервер будет оставаться как раз на библиотеки смотрите и ещё я работаю в мессенджера with a так же у нас там основной протокол общения с пользователями то websocket 12 миллионов уникальных посетителей версия для всех платформ современных достаточно нагружены приложения им принципе мы счастливы только там о чем сегодня доклад доклад будет о том с какими проблемами я и мои коллеги столкнулись при работе с окнами на голо в частности и вообще при работе с большим количеством постоянных соединений надеюсь какие-то техники диски технике вы сможете применить своих текущих или будущих проектах пару слов о том что такое в соке websocket это полна дуплексная клиент-серверное соединение что значит полнодуплексный значит а с двух сторон можно в него писать и не опасаться коллизий используется когда нужен быстрый обмен сообщениями между клиентом и сервером это чат и это коллаборативный приложение а сток акции стремится часто клиентам через websocket а ну почему применение массы думаю все знают все знаете это стартуют и псаки соединения с и степи запроса версии 11 важно что 11 потому что и степи 2 не имеет механизма апгрейт есть спецификации которая позволит стартовая тебе псаки то и работать через эти два но пока это еще один и один собственно клиент-сервер обменивается специализированными заголовками после чего у нас получается чистый tcp сессия по которой гуляют websocket фрейм и собственно высокие ты-то фреймы протокол и через фреймы мы можем передавать как текстовые так и бинарные данные почему вы вообще можете захотеть использовать и talked своих приложениях на первых это достаточно простой протокол на кости вы перейдете по ссылке там будет статья армина ван hero кто не знает пианист известный нет это не став здесь окей очень крутая статья где скрываются не которые не очевидны при усложнении websocket протокола советую почитать и топит работать на всех современных платформах и что немаловажно в браузере и собственно то что websocket работает в браузере и часто является решающим фактором почему его выбирают как основной транспорт и а у викс актив небольшой вверх от по сравнению с чистой теперь сессий то есть фрейминг websocket протокола добавляет от двух до восьми бать всего к вашим данным собственно что такое масштабировать сайтов для меня это не вопрос чистой производительности и большого количества соединений на сервер да и то лишь это задача о том что нагруженный websocket сервер должен решать определенный набор задач собственно попробовал сформулировать какие задачи может хотеть решать нагружены веб-сервер держать большое количество соединений кажется понятно отправлять большое количество сообщений не всегда но логично да что есть применение когда нужно отправить много обеспечивать fall back websocket нет даже сейчас 2019 году не все пользователи могут соединиться по протоколу websocket мы об этом сегодня поговорим аутентификации инвалида ция соединений соединение может быть установлена один раз и висеть неделями нужно его инвалидизировать и так же мы об этом будем говорить сегодня переживать массовый reconnect высокие приложения отличаются от стандартных оч типе серверов тем что у вас масса постоянных соединений у вас не стоит ли запрос у вас стоит в приложении и собственного также посмотрим на такую проблему как массово reconnected тысяч сотен тысяч миллионов пользователей что можем с этим сделать и иногда нужно не терять сообщение при reconnect опять же websocket приложения state of например если мы возьмем тот же чад также messenger да если потеряется websocket фрейм при реколлекции кажется что пользователь счастливы не будут ведь это было сообщение до которым летела часто можно восстановить состояние из базы основной так делают но мы посмотрим на некоторые нюансы которые здесь есть особенно при массовом reconnect прежде чем на ваш сервер придут тысячи соединений по websocket а вам нужно озаботиться тем что затемнить операционную систему придется какие здесь есть моменты первый это лимит файловых дескрипторов нам первое на что в сент кольца каждое соединение отъедает файловый дескриптор в операционной системе и по умолчанию лимит не такой уж большой 256000 24 файловых дескрипторов собственно по ссылке вы можете посмотреть как от лимит поднять хотите больше соединений поднимайте лимит тут первый совет если вы знаете что у вас операционная система не позволяет принимать соединение больше чем например 65535 да то есть такой лимит выставлен то не принимайте своем websocket server-side не не сверх этого лимита иначе когда у вас все пойдет плохо она пойдет вы не сможете даже в попросите да потому что заход в прав это еще один файлах дескриптор который у вас нет следующий момент это эфемерные порты обычно проблема появляется на связке load balancer ваш websocket сервер и заключается в том что вот балансер не может открыть еще одну websocket соединениях до вашего бэг-энда высоким бэг-энда потому что у него исчерпались порты портов с которых можно открыть и день по умолчанию не так много там порядка десяти пятнадцати тысяч плюс есть такое состояние so keep their weight когда его нельзя переиспользовать так что опять же по ссылке посмотрите как это затюнить есть контракт эйбл на каждый linux машине стоит ай-петри был состав которого входят в ренборг нет фильтр и там каждое соединение трека ица отдельной записью да то есть контролирует какие соединения у нас установлены с сервером также размер эта информация ограничен по умолчанию его надо затемнить и также возможно вы захотите затяните sistelle сетевой стек linux собственно есть масса статей в интернете как тюнить сервер под высокую нагрузку и опять же это возможно вам нужно сделать давайте перейдем к уровня приложения уже до что мы вообще знаем прописать это наверное первую очередь то что пакет x над websocket считается деп река этот стандартным де-факто является горилла websocket практически все приложения которые сейчас есть используют это именно этот пакет для работы в сокетами библиотечка габбасова с от сергея камардина решает некоторые дает возможность сделать некоторые оптимизации на которые гориллы websocket не способны но об этом немножко поговорим и также есть новый пакет на hair websocket активно развивающейся автор очень активен и даже сделал попытку maintain нить горилла websocket чтобы новых пользователей перенаправлять на свою библиотеку так что обратите внимание на этот пакет реального у него больших будущее но как я сказал горилла websocket везде да и в чувство моих примеров сегодня будет основываться именно на ней давайте посмотрим на простой websocket сервер мы говорить будем сегодня серверах с чего начинается но у нас есть свечи тебе обработчик как я сказал и псаки то это стартует с и степи функция апгрейт мы вызываем функцию апгрейт и внутри of great мы а точнее библиотека горилла websocket а делает хай джек соединения то есть берет его под свой контроль и отдает нам connection на самом деле эта структур ковра 15 вaм соединением далее обратите внимание что мы передаем настройки а грейдеры буфер says играет буфер says это размер буфера в которые будут использовать для ввода-вывода для записи для чтения для чего для того чтобы уменьшить количество сетевых вызовов обратите внимание на то что эти буферы будут прибиты к вашему соединению железно да то есть они увеличивают размер потребления памяти мы к этому вернемся обычном и оборачивать сведение в какую-то нашу структуру уровня приложения дат назовем ее клиент в конце хэндлера мы закрываем клиента и не забываем там же закрывать соединение стартуем отдельную грудь и ну на это запись при чем нужно помнить что горело websocket не поддерживать конкурентное чтение и запись да и блокируем и степи handler методом рид рид вычитывать данные с websocket а до тех пор пока не случится ошибка как только случается ошибка вы выходите из цикла рид и ищите pichunter завершается давайте посмотрим на такую проблему как высокий средний требовательный к ramdac оперативной памяти она поднималась не так давно в бокам unity и вообще кто-нибудь читал миллион websocket и попс of статьи сергея камардина отлично отлично на самом деле для тех кто не читал обязательно почитайте если вам интересна тема для в сокетов и даже если не интересно это просто шедевр инженерной мысли на самом деле и есть еще одно выступление вот израильтянина иная иран юная который по сути взял идеи сергея камардина и приложилась на иностранный лад дописал примеров также стоит посмотреть собственно чем говорится в статье о чем говорил сергей о том что минимальное потребление памяти наверх и соединения складывается из следующих факторов это 2 га рутины до 1 читают другая пишет это еще тебе буферы на чтение на запись от стандартной библиотеки г до которая лоцируется потому что без секса и дней начинается сочтите пи и это буфер и который мы в приложении используем для ввода-вывода и того получается если сапр активировать на миллион соединение минимум 20 гигабайт достаточно большая цифра не так ли на самом деле это самый плохой сценарий сгорел websocket мы можем перес пользовать буферы для этого мы переспорить буферы которая лоцируется и чтoб с сервером до стандартной библиотеки для этого мы рид буфер сальса в районе срастаясь передаем нулями собственно переиспользовать буфера горела websocket может потому что если мы посмотрим внутрь функция апгрейт то когда происходит хай джек возвращается объект буфере 3d raider который содержит как раз те буферы которые типы серверов на лоцировать для обработки запроса изначально при всем при этом да у нас все равно остаются 2 га рутины у нас буферы прибиты к соединениям библиотечка gap вас в с от сергея камардина позволяет отойти от этих проблем и позволяет сделать 2 оптимизации первое это зира копи апгрейт то есть мы убираем использовании стандартного чтить и сервера гоа и полностью сами парсим ешьте т.п. при этом не аллоцировать дополнительной памяти второе это возможность использовать и пол то есть и пол полностью организованный носи сколах до который использует api и linux пол и тем самым мы можем отойти даже от двух грудь in которые одна из которых пишет другая читает а также мы можем перес пользовать все буферы о которых шла речь на самом деле от буфера прибитого на чтение клип секс соединение может помочь избавиться от это еще на гитхабе в репозиторий ага как только она разрезал лица у нас будет возможность бустеры переиспользовать а от врать буфера уже сейчас сгорела websocket мы можем избавиться используя sing пул вам грейдеры тогда брать буфер будет буферы на запись будет перес пользоваться однако есть ещё одна а еще один трюк который со стандартной библиотекой год позволит очень сильно сократить потребление памяти мы даем джесси поработать что это значит это значит что последний момент да когда у нас происходит чтение мы стартуем чтение в отдельной грудь и не тем самым ешьте pichunter завершается как только из степи hander завершается хотя давайте еще один момент обратимой что здесь мы используем buffer и 1024 да потому что на самом деле стандарт те буферы которые используют стандартная библиотека это 4 килобайта на чтение за запись везли websocket приложений кажется что сообщение обычно меньше гораздо поэтому мы можем используется поменьше так вот когда завершается и степи handler мы даем возможность garbage collector у прибрать за нами убрать эти объекты на которые уже ссылки мне нужны и собственно вот этот профиль это профиль того когда мы не стартовали в рутину в последний момент и а вот это профиль и new space то есть памяти потребляемый процессом когда мы стартовали отдельную грудь и ну кажется что разница видна невооруженным глазом но если мы подсветим то вот столько объектов garbage collector получает возможность собрать вы можете посмотреть больше примеров и цифры вот в этом репозитории но грубо говоря вот такой техника вы можете сэкономить до сорока процентов оперативной памяти ok вы сделали так как я сказал да стартанули в отдельной грудь и не но при этом хендлер завершается в этот момент контекст который содержится в ищите при запросе отменится вообще контекст проникает во все уголки до нашей с вами разработки я не делюсь если вот сейчас посмотрю а там лежит контекст какой-нибудь ну кажется естественным что вы можете взять и прокинуть контекст далее по стыку вашего приложения ведь он может содержать какие-то полезные данные которые вы в него напихали в рамках middleware да и так же вы возможно скорее всего захотите отменять тяжелые действия которые вас есть websocket сервере основываясь на том когда отменяется контекст из и кажется что вы ожидаете что отменится он когда соединение закрывается в данном случае он в контекст закроется сразу как только у нас завершится еще хендлер на самом деле не проблем мы можем воспользоваться крутой фиче go оборачивать интерфейсы и менять реализация методов посмотрим на интерфейс контекст здесь нас в первую очередь интересует метод дан до который у него есть и что нам нужно сделать на самом деле нам нужно создать свой контекст который мы назовем кастом концов контекст обернуть изначальный контекст передать в него канал который будет закрываться тогда когда соединение реально закроется мы сами это знаем сами управляем и переопределим метод дан в этом методе дан мы возвращаем как раз тот канал которую закрытием которого мы управляем и все что нам нужно дальше сделать создать такой контекст прокинуть а дальше по стыку нашей программы и для других частей программы этот контекст будет все тем же интерфейсом однако отменяться он будет тогда когда нам нужно перейдем к тому что нужно рассылать много сообщений тут я америку не открою вам нужно использовать эффективный формат стерилизация выбор у вас на самом деле большой это джейсон про табов massage pack сами выбирайте что я хочу сказать здесь наверное что не стоит зацикливаться на стандартных реализациях сериализация посмотрите в сторону библиотек которые генерируют код яркий пример тут google про того который позволяет ускорить реализацию про табу в который сам по себе достаточно быстрой в пять раз да потому что не использует модуль reflect a использует код генерацию собственно подобные же библиотеке есть и для джейсон я думаю вы все знаете или джейсон fr джейсон собственно на этом можно много сэкономить еще одна проблема с которой мы вовек боролись мессенджеры и успешно побороли и это инвалидов соединения вообще да откуда проблема приходит и в соке соединения от пользователя она устанавливается и может висеть неделю что может произойти пользователь может открыть несколько табов браузера и в одном из них разлогиниться пользователи могут заблокировать в админке заблокировать его учетную запись за как за какое-то нарушение и всякие соединения продолжают жить опять же какая тут какой тут может быть выход вы можете подписаться на события если у вас есть какая-то шина данных например на свои то есть кафка как шина данных мы подписались на такие события и отключаем websocket а но если у вас такой шины данных нет то можете просто периодически проверять что и все соединения активно это дороже но тут вам нужно найти thread&#39;ов до между производительностью и тем интервалом с которым вы проверяете каждое висящие соединение сейчас идет 2019 год а пользователи все еще не могут подключиться по websocket абсолютно все и проблема на самом деле не только в том что существует браузера до старая internet explorer 8 9 турне поддержки в socket а есть еще и корпоративные пользователи с ними во все беда то есть работодатель ставят своим сотрудникам доверенный рутовый сердце кат на компьютер далее имеет возможность перешив ро вать ls трафик даже тело из трафик на своих процессах причем proc прокси режут websocket соединения специально или потому что там старое программное обеспечение непонятно но такие примеры спрашиваю сплошь и рядом когда работал в мудру был еще один случай расширение браузерные это блок заблочен все соки соединения на домены и поддомены mail.ru почему потому что мои коллеги росла через высокие соединения рекламу и нас спас тогда только вы чтите fall back самый простой способ добавить ешьте fall back в приложении нагло как мне кажется эта библиотека 100 г с г а есть либо сок джесс клайн для java script которая проверено временем production рейде и собственно она требует сер для реализации вот как раз тот же с город усердно реализация до библиотеки сок джесс и если не отсоединение повив socket то будет установлена либо их сейчас тримминг соединения либо ансар соединения long polling еще несколько эзотерических транспортов переходим на нг центральной части моего доклада это то что производительность это не масштабируемость да как бы мы не оптимизировали приложение как выманить его ли операционную систему а сколько бы не экономили на оперативной памяти оно настанет момент когда вам нужно будет масштабировать вошли всех сервер на несколько и даже в плане того что отказывать в плане отказоустойчивости вам все равно нужно иметь несколько серверов да например один упал соединение перетекли на другой кажется это очень важно и мы будем об этом сейчас говорить какая здесь основная проблема вот мы добавили websocket серверов но пользователя ваши могут быть подключены к любому инстанцию веб сайт сервера а вы хотите отправить пользователю сообщению что вам делать наверное первые до что придумайте то публиковать на все но это не масштабируется это не просто не масштабируется лет еще не удобно потом что вам нужно знать о всех инстанциях вашего websocket сервера а которые к тому же могут динамически меняться тут дело в дело вступают брокер сообщений брокер попса брокер сообщений давайте посмотрим на картинку до что здесь изображена на самом деле gopher и это ваш websocket сервер несколько инстансов все они связаны через центральный брокер собственно центральный брокер работа по модели pops up когда соединение приходят наверх и сервера они инициализируют подписку на свой какой-то персональный топик в брокере собственный брокер знает о всех таких подписках и когда вы делаете публикацию сообщения вы делаете и через брокера и собственно в этот момент через механизм pops up сообщение долетают только до тех websocket серверов на которых оно должно где есть клиенты реальность заинтересованы в этом событии и она доставляется по писать эту клиенту вообще когда я готовился к этой статье к этому выступлению я прочитал много статей про масштабирование фактов и большинстве из них рассказывается про центральный попса брокер до для масштабирования однако конкретики нет часто говорят ну а для брокера используйте rabbit или редис на этом повествовании завершается я подумал и решил добавить больше конкретики в этот вопрос и давайте вообще посмотрим что нам нужно от брокера первое это конечно же производительность тут все логично сохранении порядка сообщений тоже важное свойство которое обычно нам нужно масштабируемость брокер мы хотим чтобы брокер сам по себе масштабировал ся и был отказа устойчивым мы хотим чтобы он поддерживал миллионы топиков одновременно ну потому что чистить частые space когда у каждого соединения есть свой персональный канал да мы хотим лишь рассылать сообщения конкретному пользователю в этот момент если вас миллион востоке соединения у вас появляется в шоке миллион топиков брокера мы хотим чтобы брокер мог поддерживал cacilie стрим сообщений об этом мы говорим поговорим чуть позже что это такое от чего это спасает и необходимость писать встроенной процедуры большой бонус опять же я расскажу как нам это помогло мне в центрифуге ином смысле джавитом какие есть опции первое это ribbit ribbit будет работать ребят будет работать пока у вас небольшая нагрузка собственно почему на каждое соединение вы будете создавать там очередь и на самом деле это не масштабируется когда у вас появляется множество и пользователей когда у вас большой connect disconnect the right да то есть вы создаете бенди тиан биндить и очереди и например в мессенджере авито когда я пришел на sender у нас там использовался rabbit i&#39;m cool и было 100000 подключений вот на 100 тысячах подключения ребятенку потреблял 7770 то есть это огромная цифра забегая вперед мы заменили ребят на редис и получили 0,3 и драться по ул то есть это более чем x 200 персон из boost кафка кажется вполне натуральным попробовать кафку для этого но тут мне кажется что это может стать вертелом для многих приложений потому что кавказ охраняет стрим на диск консьюмер кафки работают по пулу модели что может быть неэффективным когда вас миллионы топиков и вам надо пулять из всех данные и кафка предпочитает более стабильную конфигурацию своих топиков потому что в динамике да когда вас появляется субскрайб ансаб скраб у вас топике создаются на лету и удаляются и кажется что во многих случаях лучше с кафкой так не делать на 13 тримминг вот тут что мне самому кажется а над вы вполне можете использовать если вам нужен андре-луи был попса падает а производительное решение написан иногда кажется что это взлетит над streaming я бы не использовал почему потому что я посмотрел код над streaming и в достаточно критичных для себя местах нашего нашел ту ду который не имплементировать определенную логику при восстановлении сообщений для меня это показалось критичным и я бы не использовал нас 3 мин для задачи если нужно восстанавливать сообщений тарантул кажется хорошей хорошую и альтернативы для в качестве брокера потому что у мега производительный у него есть logic на стороне сервера вы можете гибко писать логику и с недавней версии он поддерживает push со стороны брокеров соединения попробуйте на самом деле на чем я остановился и начнем с то есть мы в мессенджере это редис почему редис потому что он производительный в том числе у него мега производительный pops up он стабильный что самое главное предсказуемый у него есть сентинель для high availability он позволяет писать атомарного процедуры и структуры данных позволяют хранить кэш сообщений на самом деле опять возникает вот этот вот кэш сообщение для магические мы к нему скоро вернемся расскажу что такое тут есть один совет если вы делаете центральный брокер попса брокер то используйте одно или пул соединений между websocket серверами вашим брокером что я видел часто в примерах на гитхабе как пишет код это пришло новый websocket соединения открываем новый connect среди сам или с каким-то другим брокером так делать не надо это анти паттерны и масштабируется используйте одно или пул соединений с брокером и в этом месте вы можете использовать максимально эффективный формат стерилизации сообщений до для общения между websocket сервером и вашим брокером здесь вам не надо задумываться о том чтобы формат был человека читаемый да потому что его не увидят не ваши frontend разработчики не ваши тестировщики вы можете сугубо internal вещь можете максимально делать и эффективный брокерам мы еще вернемся а давайте поговорим о другой проблеме это проблема массового реконнекта массовый reconnect это когда у вас сотни тысяч пользователей онлайн подключены и psx соединением миллионы пользователей да и вы можете например раскладывать свой websocket сервер до выкатывать новую версию у вас могут ли ладится внешние балансиры что при этом происходит при этом соединение рвутся и лавину пользователи приходят вам на backend перри подключаться причем они не просто хотят перри установить соединение они еще скорее всего хотят восстановить свое состояние потому что websocket приложения не стоит fulda тоже messenger да я хочу получить все сообщения которые я пропустил пока отсутствовал это большая проблема давайте посмотрим как с ней можно бороться несколько техник первое наверное всем вам известно это обязательный экспоненту быков на клиенте клиенты должны перри подключаться с iq специально увеличивающимся интервалами 2 если вы знаете что у вас на бэг-энде какой-то ресурс деградируют при конкурентном доступе поставьте туда самый простейший bound семафоры ограничьте этот конкурентный доступ делается на гоа элементарно доконал с буфером и все его но зато в вас не деградирует систему то что пользователь предположим переключиться чуть позже ну окей 9 аутентификация как способ не нагружать бы концессии как часто что часто происходит приходит connect на сервер его нужно аутентифицировать вот инфицируется вы его через бы концессий причем бы концессии может быть как развёрнут как локально так и это может быть поход сторонний микро сервис джейсон gap talking позволяет избавиться от большой нагрузки на бы концессии потому что у jason wade токина есть expiration time да когда к вам приходят пользователи он пытается от инфицироваться с использовать же сон gap токен и он валиден вы можете не ходить ваш бэкон сессии и если вы разумного выберите время которое через который джейсон where токина истекают да то большая часть из них при реколлекции окажется валидный и вы в конце сине идете все хиндли ти внутри go добиваетесь максимальной производительности соединений вас сотни тысяч пользователей приходят и хотят перри подписаться в этот момент вы точно хотите перед подписать их как можно скорее это хорошо вам хорошо пользователям например случае с редисом мы можем это делать используя regional planning да то есть редис pipeline к это отправка нескольких сообщений нескольких запросов редиса за один запрос и мы это делаем центрифугу это делает нас инжира вид это делает и мы используем пайпа ник на полную в этот момент и нам с этим помогает такая техника кошмар бочанг такой паттерн который позволяет из нескольких независимых источников грудь и наших соединений собирать какие-то запросы да у нас есть канал из которых приходит какая-то работа и мы знаем что эту работу мы эффективнее выполняем в пачках да то есть по несколько штук мы читаем из канала записываем как объект который нам нужно обработать баччан ушла из какой-то далее мы продолжаем вычитывать из этого канала данные до тех пор пока у нас башни пред перерастет максимальный размер свой или пока в канале не останется данных да то есть это select это позволяет сделать должны в итоге копим батч и на выходе у нас получается пачка объектов с которой мы можем работать ну например послать pipeline запрос бредишь вот здесь вот есть ссылочка на мой репозитории накид хайга где можно посмотреть как smart починкой pipeline вместе живут там вот есть примеру бенчмарки можете посмотреть если заинтересовал эту тему ok then дальше кэш сообщение стал играть пиковую нагрузку собой я вот мы до него добрались что это такое как я уже сказал пользователи хотят восстановить свое состояние они хотят не пропускать сообщение которые были в момент реконнекта вы можете хранить стрим сообщений которые вы публиковали в каком-то кэше да что-то вроде ним каша что-то вроде киева или старриджа я собственном extreme сообщений храним время здесь в одессе в структуре данных лист а как вариант начинает среди 100 50 мы могли бы использовать стрелы но центрифугу массажа авито мы делаем следующим образом происходит публикация а идет запрос в редис там работает лап процедуры которая нам позволяет атомарный сделать те вещи о которых я сейчас буду говорить первые мы добавляем сообщения в структура данных лист да как вы видите здесь уже три сообщения у каждого сообщения при этом есть инкрементальный номер мы его увеличиваем также в десятом арно и далее мы публикуем сообщение в попса при одессы в этот момент она улетает в паб soft tabs об долетает до клиента если он подключен как только клиенты reconnective они передают номер сообщение которое они видели последним и собственно мы идем в рейде смотрим в лист если есть сообщение мы восстанавливаем их клиентов из этой структуры данных как будто он даже не был отключен да то есть по сути он получает весь стрим сообщений которые ему в интервале отсутствие были высланы помощи эта операция и если кто то знает до что это то что редис pops up это на самом деле это мост vans delivery мы в мессенджере в центрифуге сделали наряде сильно вот таких вот стримах это лист vans я подробнее про это расскажу на холодный через месяц вот но на самом деле это то есть можем это лист вам сделать нарядись и таком стриме и как бонус мы можем на таком стремясь сделать и fall back для websocket а собственно во vita в messenger мы именно так и делаем то есть мы у нас есть три таких сообщений для каждого топика и наш полинг 0 приходит и мы и z в пользователь приходит мы спазме степи полинг для fall back и забирая данные из этого стрима и отдает их клиенты собственно на этом же сам механизм можно и long polling пас построить это идет как бонус вот вот это вот каша и сообщений вот этот график это график которой случается при раскладке нашего сервиса случался точнее когда у нас был ребятенку и 100 тысяч пользователей а как мы видим ничего хорошего тут не изображено а вот так стало когда у нас стал редис и на самом деле уже 500 тысяч пользователей то есть раскладку происходит совершенно бесшовно для наших клиентов и времена ручек ну совсем не растут все что я здесь рассказывал на самом деле так или иначе используется внутри центрифуга сервера если вам не хочется заморачиваться самим писать все это да то можете использовать на 3 фуга это отдельно стоящей сервер который принимает connect и от пользователей имеет опять чтобы вы сообщение пользователям отправляли при этом он хорошо встраивается в любую микро сервисную архитектуру так что можете посмотреть как я говорил он основывается на библиотеки центре фич и вы можете использовать библиотеку смотри фичи ваших приложениях а единственное что да это уже не совсем библиотека потому что она задумывается о масштабируемости за вас имеет встроенный ряде сын джон и это на кэш сообщений это уже скорее framework то есть понятно что мы там gopher ада не очень любим фреймворке использовать ну смотрите сами а и чтобы как-то не быть голословным я сделал дима стенд кубер на это с который использует библиотеку сына 3 лично серверы и хотел добиться следующих целей 1 миллиона соединений от пользователей 30 миллионов сообщений в минуту которые да будут доставлены пользователям да то есть это 500 тысяч сообщений в секунду при этом я поддерживал конец disconnect а рейд по 200 тысяч в секунду до приблизил этот тем цифрам который у нас мысль джаве то есть и при этом я следил за ли танцы доставки сообщений чтобы она не перерастала 200 миллисекунд на самом деле тут будет небольшой таймлапс подробнее наверное вы сможете посмотреть уже после на какие конкретные цифры здесь используется нас усеченном буров connections до быстро дорастает до миллиона далее мы ждем какое-то время посмотрим что система ведет себя стабильно затем начинаем публиковать сообщения мы deliver a до график до 30 миллионов сообщений в минуту при этом смотрим на серве циpкa нам на память и так далее и что самое главное смотрим на брокер до наряде в данном случае используется 5 инстансов редиса то о чем я не рассказывал в докладе но мы сортируем редис да то есть это шарди ранее происходит по и мне топика и при этом мы видим что ле пин стене дорастает до роста и до 200 миллисекунд и там примерно останавливается до когда рейд сообщений достиг 30 миллионов чуть больше цифр есть на этом слайде потом если что посмотрите кому интересно также я планирую это потом опубликовать и и конфигурацию железа тоже предоставлю кажется что это достаточно весомые цифры то есть по большому счету железо тут ушло на один современный сервер который используется в пройден что вы можете вынести первое это дайте джесси поработать на благо потребления рам для то о чем я говорил мы можем сказать старичок приберись за нами мы тут немножко намусорили и на самом деле чем раньше мог сделать им лучше ведь нам вчера ему все равно garbage collector у работать поставки соединения завершится не откладывай на завтра то что можно сделать сегодня используйте эффективный компактный формат стерилизация используйте брокер сообщение для горизонтального масштабирования причем выбирайте тот что подходит для вашей задачи подумайте над необходимо стричь tefal bk головин угли коннектов можно и нужно переживать и посмотрите сторону центрифуга если вам нужно рабочее решение сейчас вторая версия очень даже хороша джейсон протокол про табу в протокол все что вы хотите и масштабируется среди сам все о чем я рассказывал что там есть так мышцам и связаться спасибо [аплодисменты] саша спасибо за доклад мне очень понравилось я слушал его прямо с удовольствием мне кажется рассказала всех граблях на которой наступил спасибо так держи нашу матрешку специально для докладчиков ты же мне и до дипломной пожалуйста доклады потому что и придется вывод с запоминая пожалуйста вопросы тебе придется выбрать самый лучший если у нас вопрос полно вопросов на последнем ряду добрая спасибо за интересный как так вот вопрос про пройдись мы когда делаем подписку в рай десна попса пну разыне открываем новые типы соединения нет ни от мультиплексе руется через одно соединение все да это ну это появилось до равно давно всегда так было наверное хорошо спасибо вопрос рядом на самом деле когда средства мы работаем самый эффективный способ это именно работа через одно соединение потому что реддит однопоточный и там чем больше средней на него приходит тем он больше деградирует вот так что это все-таки это давно да здравствуй пасибо за доклад очень интересно грузим из financing и такой вопрос вот обсуждали разные брокеры но я ничего не услышал про пульсар граждан пульса apache пульса и довольно просто хорошо подходит именно под этот кейс потому что он хорошо переживает там миллионы топиков и изучали ли вы его пробовали спасибо нет я к сожалению опыта не имел поэтому его никак не упомянул здесь возможно да он подходит и на самом деле выбора брокеров много да там и актив и мку есть и еще форки редиса многопоточные то есть я просто постарался упомянуть те что на слуху у меня наверное да вот пульсар возможно подойдет я посмотрю на него тоже не спасибо спасибо привет спасибо за доклад очень круто было вопрос про масштабирование я как пол услышал выстелить этапа топиком был ли такой кейс что какой-либо из топиков был супер нагружен и какая-то часть реплика отваливалась как кода в принципе так и редиса потому как я понимаю что не просто по топиком скиллинг идет неравномерные разные под из сервисов они еще подписаны на разные получаются куски редиса и все это как-то очень запутано на самом деле по закону больших чисел до обычно это выравнивается и тут есть один нюанс который связан со спецификой приложения это websocket сервер и чаще всего через 1 топик нет смысла гнать больше там чем 30 60 сообщений в секунду потому что по сути там 60 сообщений в секунду до этого достаточно чтобы сделать любую real-time websocket игру наверх на стороне клиента и там смысл гнать тысячу например сообщение через топик большого нет практического то есть это не тут спасает именно специфика системы заточены под клиентское использование когда из канала должно приходить не так много сообщений 3060 в секунду вот поэтому супер нагруженных топиков не бывает до неравномерное распределение да может быть да то есть но на практике пока не сталкивались пока закон больших чисел спасать нас какое количество плодов определяете для того чтобы увидеть и портов хватило а количество бора лакшми наших лекциях серверов и а вот количество кодов и апсо кассиров неважно да то есть на сервер может принять сколько угодно входящие соединения если выкручен правильное и лимит контракт и тут эфемерные порты не играют роли эфирные порты появляются проблемы эфемерных портов появляется со стороны клиента то есть именно клиент когда открывает много соединений с одним портом сервера вот там вот там нужно же виртуальный api или просто несколько реальных айтишников вогнать и тогда тем самым можно увеличить количество вот этих вот клиентских открытых соединений ну либо просто количество доступных портов увеличится там до 65000 это можно сделать вот то есть на сами на серверной стороне проблемы с портами не бывает это именно клиентская я понимаю что как бы порты они не используется на то есть на одном я просто вот девиз эфемерными портами не очень понял а ну да то есть на самом деле в тисе пи как ты теперь connect состоит из клиентского порта клиентского и печника серверного порта и серверного пик айпишник а да то есть вот такая связка из четырех значений и проблем возникает тогда когда клиент а в данном случае это вот load balancer да как я говорил начинает открывать много соединений у него клиентский порт вот это вот часть в этой связке по сути там 10000 по умолчанию он может таких создать и пока вы не выкрутить и вот этот вот финал port range да только 10 тысяч дней на от лат балансира может спроектировать она ваш websocket сервер ю-чат за на самом деле даты старики момент сапатеро ты там один порт используется на сервере один порт насаживать всегда один порт если еще вопрос у нас вот здесь на первые всегда на самом деле но большинстве случае спасибо за доклад у меня такой вопрос ты показывал в примерах когда там инициализироваться апгрейда до в гареме во плоти там можно было указать размер буфера на записи на чтение если какие-то рекомендации вот но как вообще какие значения можно подобрать то есть может быть нужно смотреть там на статистику размеры сообщений присылаемых и когда я думаю статистика размер сообщение вполне себе играет роль и как бы в зависимости от этого уже можно подбирать размер надо все понял спасибо еще вопросы здесь справа спасибо за доклад ты указывал что если закрывать хендлер сразу the garbage collector придет и почистить все но кажется что если у вас есть такая ротация клиентов то есть они ж не вечно вас висят то это особо не должно влиять потому что они меняются и но все равно он будет посещать хоть и хантер будет висеть но он просто будет позже откладывать на самом деле вообще garbage collector сразу не придет и не по чести да там есть га джесси нужно на практике это дает прирост до сорока процентов то есть коннектор количество растет garbage collector иногда приходит удаляет и по сути вот эти данные которые на лоцировать и стич тебе сервером да это они ведь нужны только на момент до апгрейда то есть у нас прошел апгрейт мы эти данные удаляем это в данном случае у нас уже получается как будто garbage collector работает связке с обычным хотя по серверам да то есть на обычном ктп сервере память не дорастает до гигабайт о чем я говорил а здесь мы просто как бы даем вот это вот почисть а дальше мы уже работаем с соединением сами да и там уже конечно же используем какой-то память но garbage collector нас спасает и как будто мы работаем с сервером данном случае это зависит от промежутка когда висит вот этот connection сколько в среднем средний пользователь сложно сказать ну пусть сутки то есть ну каждом приложении по-разному же это мобильные клиенты нет точной цифры не могу сказать зависит от специфики приложения сколько средняя сессия пользователя длится но обычную всякий connection это длительный collection то есть это не 200 миллисекунд там как вы чтите запросе это несколько минут час сутки и ну понятно просто сутки это очень странно у него браузер сутки открыт такие должно быть не так много на самом деле таких много то есть люди на кого как пользоваться вид приходит на работу включают браузер он у них висит целый день то есть на самом деле у нас ночью да вот если мы посмотрим на график connection of ночью у нас коннектов ночью всегда есть постоянно рейд 2 тысяч 200 до то есть люди оставляют открытыми вкладки и висит connection поэтому внизу планов оптимизировать висячие не нужно на самом деле можем да то есть если коннекта неактивен то почему бы его не отключить это имеется ввиду можно до отключать и мне кажется в принципе в каких-то кейсах это хорошая практика потому что мертвые коннектор зачем они сдались но мы так не сделали до этого мы не дошли спасибо коллеги и я думаю что нас кончилось время и вы лучше поймаете сашу в кулуарах саша пришло время выбрать самый лучший вопрос мне понравилось вопрос про распределение нагрузки по топиком где там про закон больших чисел отвечал так как то его задавал для туда приходите к нам отлично представься пожалуйста расскажи про свой вопрос denis меня зовут я повторить вопрос ответь просто ну у меня наверно почти похоже проблема что шарды не всегда просто логично распределять по ним нагрузку по ним данные раскидывать и зачастую таких простых вопросов типа давайте по дням в этом по алфавиту не работает и соломинка эта книжка для тебя и спасибо большое саше за доклад

Transcript for:Масштабирование WebSocket-серверов на Go

Transcript for:
Масштабирование WebSocket-серверов на Go