16 февраля Golang-сообщество устроило глобальный сбор в честь релиза версии 1.8. На московскую release party в офисе Avito собрались более 150 «гоферов» и сегодня мы публикуем видео-записи докладов.
«Go 1.8»
Вячеслав Бахмутов (Dropbox / GolangShow)
Слайды доклада
«Golang в Avito»
Сергей Орлов, Вячеслав Крюков, Андрей Скоморохов (Avito)
«Как 200 строк на Go помогли нам освободить 15 серверов»
Паша Мурзаков (Badoo)
«Миллион открытых каналов с данными по сети»
Илья Биин (Zenhotels)
Фото со встречи выложены на нашей странице в FB. За анонсами митапов московского Golang-комьюнити следите на meetup.com. Видео-записи докладов с предыдущих митапов, прошедших в Avito, можно найти на нашем YouTube-канале. До новых встреч!
Поделиться с друзьями
Комментарии (7)
mohtep
22.02.2017 14:26+3Увы. Ваше предложение корректно, но только в случае, если память бесконечна. То есть мы должны вычитать объем данных предназначавшихся для неактивного воркера. Если этот объем велик, то мы достаточно агрессивно начнем тратить хип.
sshipkov
22.02.2017 21:58-1Если речь про «неактивных воркеров», тем более не стоит изобретать велосипед. Вариантов реализации механизма отложенных вычислений великое множество.
Про память, этот вопрос тоже легко решается, даже с велосипедом. Из пула читающих воркеров, данные складываются в буфер нужного бизнес воркера. Буфер может быть локальный (например кольцевой), внешний (например очередь).
sshipkov
В докладе «Миллион открытых каналов с данными по сети», автор упоминает о проблеме Head-of-Line Blocking в разрезе блокировок при последовательном чтении TCP пакетов, JRPC и д.р.
К счастью избежать данную проблему легко:
Blooderst
Совершенно согласен. Если проблема в неполучении данных из-за сети, то предложенное решение ее все равно не решит. Если же сетевых проблем между серверами нет, то проблема HoLB решается до безобразия просто — сначала прочитай пришедшие к тебе данные и только потом их обрабатывай. И я уверен что многие тысячи подобных кейсов решены именно таким способом без велокрафтинга. Единственный случай, при котором такой подход не будет работать — это когда объем передаваемого сообщения превышает объем оперативной памяти ноды, но что-то мне подсказывает, что у автора доклада, который одной нодой по его словам обрабатывает миллионы одновременных подключений, не этот случай.
ndka
Как-раз именно тот случай. Там дикие объёмы данных перегоняются. :)
Blooderst
Если так, тогда да, это смотрится как весьма хитрое инженерное решение =)
ndka
К сожалению, доклад из-за временных рамок не мог вместить всякого хитрого, поэтому автор вынужден был скакать по верхам. За подробностями лучше его терроризировать, вона, он ниже отписал, mohtep звать. :)