Presentación
PDF (pincha para descargar)
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
first I want to give a quick shout out to the organizers the story goes that they were about to mortgage their house in order to make this happen so thank you also to the sponsors so that they didn't have to mortgage their house to make this happen I'm
sure you're all so incredibly excited about me talking about the third messaging system of the day hopefully there will be something new and interesting that I will present that you'll find a value so my name is Matt and I'm currently building
patterns but I'm not here to talk to you about that today I'm here to talk to you about nsq which we built at bitly that's Chauncey Macduff person the bitly mascot so there's two there's two questions that I get asked most often when giving
variations of this talk one of them is why didn't use RabbitMQ and the other one is what on earth does nsq even mean some people have suggested not stable Q do not believe them it's a lie my favorite is naming socks Q because we all know it does the
truth is it's actually much more boring it's called new simple Q and that's actually pretty important at bitly when we were building an SQ we had a large existing infrastructure that we were converting over to it and that's actually the title
of this talk it's called spray some nsq on it we have our nsq spray can whenever we converted a service on our old simple Q over a 10 sq we would joke that we're just you know taking out our old nsq spray can and spraying some nsq on it but don't
worry nsq is environmentally friendly the kids absolutely love it and it is illegal in 49 states okay so I'm gonna walk through a series of steps where we start small and we scale and we'll build a little you know service on top of NS q obviously sprang
some NS q on it so Chauncey is missing from this slide sorry about that he should be off to the left there let's assume this is early bitly and we have a simple API service and we're shortening links and we're returning synchronously to our external
clients and the boss comes to uni says I want to add metrics and you're on a single host and you're doing these synchronous writes so the easiest thing to do now there's Chauncey it's synchronously write to a metro system right you take you
15 minutes you punch in a couple lines of code what's the problem with this the problem is if you keep going down this path of tightly coupling things you sort of end up in a state where you have these groups of services that also want access to the same
data and if every time you want to add a new producer a consumer you you know tightly couple them and just change code and do a deploy in order for that to happen you end up in a state where you have this nightmare of interconnected components and in particular
it becomes really hard to understand how they're going to fail if one of them individually has issues but there's hope and the answer is just use node and this is actually the end of my talk I'm serious okay so this is what we have another I converted
these from widescreen to non-widescreen and I lost some some information here but it's supposed to say distribute a message bus in the middle here this is this is our goal right we want to build a system where we have these really clean api's for producers
to be introduced you're writing to this central but not a single point of failure system and consumers can freely come and go you're decoupling things you're providing an opportunity to introduce a real real-time introspection and a hook for you
to be able to actually look at what your data layer is doing in production as well as the opportunity to provide a system that is really easy to configure and does not have a large upfront cost but before we do that let's talk about some basic messaging
patterns so how would we build a system like this and I see another mistake in the slides that's supposed to say producer and not produce let's see what happens when we push a message through a broadcast delivery mechanism right it's being copied
across to and delivered to two distinct groups of consumers and all we've really accomplished here is is decoupling producers from consumers so the producer no longer needs to know about who's consuming this data the consumers don't really care
where the data is coming from and everybody's happy and then there's the distribution approach this is sort of the inverse you have a producer pushing data across the pipe and this is where your load balancing the stream of messages across your connected
consumers note that off to the right here they're the same color they're probably performing the same work running the same code and this also gives you horizontal scalability so now as you're the volume of your stream changes you can introduce
new consumers and be able to you know handle that throughput and it's also great for failure cases so let's see what happens when one of them reaches a fiery death always at 3:00 in the morning probably right so we have our consumer that burns up push
[ ... ]
Nota: se han omitido las otras 2.533 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.