22 февраля в 12:58

Видео докладов с Go 1.8 release party Moscow

image

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-канале. До новых встреч!
Автор: @Oldtuna
Avito
рейтинг 257,26
Avito – сайт объявлений №1 в России

Вакансии компании Avito

Комментарии (7)

  • +2
    В докладе «Миллион открытых каналов с данными по сети», автор упоминает о проблеме Head-of-Line Blocking в разрезе блокировок при последовательном чтении TCP пакетов, JRPC и д.р.
    К счастью избежать данную проблему легко:
    • сначала читаем данные, потом параллельно обрабатываем
    • читаем доступные данные и асинхронно обрабатываем

    • 0
      Совершенно согласен. Если проблема в неполучении данных из-за сети, то предложенное решение ее все равно не решит. Если же сетевых проблем между серверами нет, то проблема HoLB решается до безобразия просто — сначала прочитай пришедшие к тебе данные и только потом их обрабатывай. И я уверен что многие тысячи подобных кейсов решены именно таким способом без велокрафтинга. Единственный случай, при котором такой подход не будет работать — это когда объем передаваемого сообщения превышает объем оперативной памяти ноды, но что-то мне подсказывает, что у автора доклада, который одной нодой по его словам обрабатывает миллионы одновременных подключений, не этот случай.
      • 0
        Как-раз именно тот случай. Там дикие объёмы данных перегоняются. :)
        • 0
          Если так, тогда да, это смотрится как весьма хитрое инженерное решение =)
          • 0
            К сожалению, доклад из-за временных рамок не мог вместить всякого хитрого, поэтому автор вынужден был скакать по верхам. За подробностями лучше его терроризировать, вона, он ниже отписал, mohtep звать. :)
  • +3
    Увы. Ваше предложение корректно, но только в случае, если память бесконечна. То есть мы должны вычитать объем данных предназначавшихся для неактивного воркера. Если этот объем велик, то мы достаточно агрессивно начнем тратить хип.
    • –1
      Если речь про «неактивных воркеров», тем более не стоит изобретать велосипед. Вариантов реализации механизма отложенных вычислений великое множество.
      Про память, этот вопрос тоже легко решается, даже с велосипедом. Из пула читающих воркеров, данные складываются в буфер нужного бизнес воркера. Буфер может быть локальный (например кольцевой), внешний (например очередь).

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка