The Myth of the Magical Messaging Fabric by Jakub Korab https://www.youtube.com/watch?v=Ie3--CSpCGs
a warm-up exercise ‎· (❍ᴥ❍ʋ)
"independently for about three years" ‎· (❍ᴥ❍ʋ)
@jakekorab ‎· (❍ᴥ❍ʋ)
myths, two definitions, usefulness of myths, more etymology ‎· (❍ᴥ❍ʋ)
ActiveMQ vs Kafka ‎· (❍ᴥ❍ʋ)
broker as an interface, as a post office ‎· (❍ᴥ❍ʋ)
wire formats: OpenWire, AMQP, STOMP, MQTT, XMPP,.. ‎· (❍ᴥ❍ʋ)
queues/topics ‎· (❍ᴥ❍ʋ)
reliability vs performance ‎· (❍ᴥ❍ʋ)
send-write-"confirm"-ack cycle, the meaning of "wrote" http://j.mp/postgres-journal-reliability ‎· (❍ᴥ❍ʋ)
in ActiveMQ, disk is the main speed limiter ‎· (❍ᴥ❍ʋ)
IOPS, capacity, latency,.. ‎· (❍ᴥ❍ʋ)
two+ consumers, node failure, redispatch ‎· (❍ᴥ❍ʋ)
at-least-once-delivery is the best you can possibly do (indeed) ‎· (❍ᴥ❍ʋ)
slave is supposed to stop listening. (it doesn't afaik) ‎· (❍ᴥ❍ʋ)
broker is not a great fit for a container (or VM) ‎· (❍ᴥ❍ʋ)
transactions are a nice way to increase throughtput ‎· (❍ᴥ❍ʋ)
do not use one shared broker. so long for the centralized queues ‎· (❍ᴥ❍ʋ)
(how do we trace it? wire tapping?) ‎· (❍ᴥ❍ʋ)
kafka as a way to _not_ set up separate brokers ‎· (❍ᴥ❍ʋ)
100K 1/sec; many shiny promises ‎· (❍ᴥ❍ʋ)
consumer group as a logical consumer ‎· (❍ᴥ❍ʋ)
no round-robin, the newest consumer steals all the messages, you can multiplex by hand ‎· (❍ᴥ❍ʋ)
partitioning; separate journals for separate consumers, screwed-up ordering. ‎· (❍ᴥ❍ʋ)
the standard pain of producer being responsible for sharding: it is the producer who decides on partitioning. ‎· (❍ᴥ❍ʋ)
send returns a Future, so... it's up to you to deal with the client lib failures ‎· (❍ᴥ❍ʋ)
consumption is non-transactional,.. but you can rewind, manually. ‎· (❍ᴥ❍ʋ)
a plane designed for survival ‎· (❍ᴥ❍ʋ)
needs a lot of disk; huge cleanup windows, very expensive disk-wise. ‎· (❍ᴥ❍ʋ)
"kafka doesn't actually _lose_ messages; you just may happen not to consume them" ‎· (❍ᴥ❍ʋ)
[ ] grab that slide desk ‎· (❍ᴥ❍ʋ)
"I've just saved you a whole bunch of conference sessions" (on SEDA) ‎· (❍ᴥ❍ʋ)
^ лол :) ‎· אני אדם משום מקום
cool! a link to the slide deck would be appreciated :) ‎· 9000
Only got the blog so far, http://www.jakubkorab.net — but I'll ask him ‎· (❍ᴥ❍ʋ)
ух. прям не знаю, как комментировать — осмысленно не получится, но почему то мне эта лекция не нравится. единроги, бля, опять же. вроде вся информация доступна и в текстовом виде... я вообще предпочитаю пользоваться brokerless MPS, больше контроля над синхронизацией и кэшированием. там конечно свои проблемы, но 500k я получаю между микросервисами на питоне. короче, я не фанат persistant messages. нет стэйта (особенно такого над которым у тебя нет нормального контроля), нет проблемы. UPD: вот, сформулировал: все эти persistant брокеры во время дизайна абстрагируют domain knowledge, выбрасывая информацию которая позволяет все сделать элегантнее, точнее они персистентны не на том уровне абстракции. мы в итоге используем ibverbs/RDMA, несколько миллионов 4k сообщений в секунду, персистентность обеспечивается в отдельном слое, асинхронно, redundancy за счет дублирования сообщений и пересылки. причем, несколько уровней redundancy с разными гарантиями и производительностью, что возможно только по той причине, что мы не потеряли информацию сериализуя в сообщения MPS, точнее коммуникация происходит в том слое, в котором вся информация есть. nanomsg, кстати отличный, я с ним игрался но для своего проекта zeromq был удобнее, к нему больше оберток есть. ‎· 50% ash
Вообще, мне нравится эта игра с brokerless MPS, преимущество которое я получаю это возможность двигать боттлнеки програмно. я могу контролировать скорость producers, просто их блокируя, увеличивать и уменьшать количество consumers, давать временную персистентность, потом в авральном порядке разгребая очередь, на лету перестраивать топологию, и кучу всего еще, не закладываясь на ограничения брокера. В итоге, все эти операции достаточно просты на уровне кода, все описывается набором эвристик похожим на правила. А от brokered MQ меня интуитивно корежит, по настоящему сложность никуда не исчезает, просто контроль над ней переходит в руки операционной / файловой системы, а я им вообще не доверяю, у них 0 domain knowledge. ‎· 50% ash