Pull to refresh

Comments 7

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

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