Should I read past page one?

2.1 Consumers and producers (not an economics lesson)
2.1 Iste'molchilar va ishlab chiqaruvchilar (iqtisod darsi emas)

If you’ve ever worked with software that uses a network, you’re probably used to thinking about clients and servers. Whether it’s a browser and a web server, or your app and a MySQL server, you have someone making requests and someone servicing them.

You could call it the food truck model. Your app places the order and the food truck fulfills it. The source of the data you want is the food truck server. This model is usually how we try to understand anything that involves our app and a service. So with this new messaging approach, you might ask, who’s the customer, who’s the food truck, and how do I order?

Agar siz hech qachon tarmoqdan foydalanadigan dasturiy ta'minot bilan ishlagan bo'lsangiz, ehtimol siz mijozlar va serverlar haqida o'ylashga odatlangansiz. Brauzer va veb-server yoki sizning ilovangiz va MySQL serveringiz bo'ladimi, sizda kimdir so'rovlar yuboradi va kimdir ularga xizmat qiladi.

Siz uni oziq-ovqat yuk mashinasi modeli deb atashingiz mumkin. Sizning ilovangiz buyurtma beradi va oziq-ovqat yuk mashinasi uni bajaradi. Siz xohlagan ma'lumotlarning manbai oziq-ovqat yuk mashinasi serveridir. Ushbu model odatda bizning ilovamiz va xizmatimiz bilan bog'liq har qanday narsani tushunishga harakat qiladi. Shunday qilib, ushbu yangi xabar almashish yondashuvi bilan siz mijoz kim, oziq-ovqat yuk mashinasi kim, deb so'rashingiz mumkin.
va qanday buyurtma beraman?

That’s the problem though. RabbitMQ isn’t a food truck; it’s a delivery service.

Muammo shundaki. RabbitMQ oziq-ovqat yuk mashinasi emas; bu yetkazib berish xizmati.

The data your app gets from RabbitMQ is no more served from Rabbit than the package you pick up was produced by FedEx. So let’s think about Rabbit as a delivery service.

Your app can send and receive packages. The server with the data you need can send and receive too. The role RabbitMQ plays is as the router between your app and the “server” it's talking to. So when your app connects to RabbitMQ, it has a decision to make: am I sending or receiving? Or in AMQP talk, am I a producer or a consumer?

Ilovangiz RabbitMQ-dan oladigan ma'lumotlar, siz FedEx tomonidan ishlab chiqarilgan paketdan ko'ra Rabbit-dan ko'proq taqdim etilmaydi. Shunday qilib, keling, Rabbitni etkazib berish xizmati sifatida o'ylab ko'raylik.

Ilovangiz paketlarni yuborishi va qabul qilishi mumkin. Sizga kerak bo'lgan ma'lumotlarga ega server ham yuborishi va qabul qilishi mumkin. RabbitMQ o'ynaydigan rol ilovangiz va u gaplashayotgan "server" o'rtasidagi yo'riqnomadir. Shunday qilib, ilovangiz RabbitMQ-ga ulanganda, u qaror qabul qiladi: men yuboryapmanmi yoki olamanmi? Yoki AMQP nutqida men ishlab chiqaruvchi yoki iste'molchimanmi?

Producers create messages and publish (send) them to a broker server (RabbitMQ).

What’s a message? A message has two parts: a payload and a label. The payload is the data you want to transmit. It can be anything from a JSON array to an MPEG-4 of your favorite iguana Ziggy. RabbitMQ doesn’t care. The label is more interesting. It describes the payload, and is how RabbitMQ will determine who should get a copy of your message. Unlike, for example, TCP, where you specify a specific sender and a specific receiver, AMQP only describes the message with a label (an exchange name and optionally a topic tag) and leaves it to Rabbit to send it to interested receivers based on that label. The communication is fire-and-forget and one-directional. We’ll get more details about how RabbitMQ interprets the label later when we talk about exchanges and bindings. For now, all you need to know is that producers create messages and label them for routing (see figure 2.1)

Ishlab chiqaruvchilar xabarlar yaratadilar va ularni broker serveriga (RabbitMQ) nashr etadilar (yuboradilar).

Xabar nima? Xabar ikki qismdan iborat: foydali yuk va yorliq. Foydali yuk - bu siz uzatmoqchi bo'lgan ma'lumotlar. Bu JSON massividan tortib, sevimli Ziggy iguanangizning MPEG-4-ga qadar hamma narsa bo'lishi mumkin. RabbitMQ parvo qilmaydi. Yorliq yanada qiziqarli. U foydali yukni tavsiflaydi va RabbitMQ sizning xabaringiz nusxasini kim olishi kerakligini qanday aniqlaydi. Masalan, siz ma'lum bir jo'natuvchi va ma'lum qabul qiluvchini ko'rsatadigan TCP dan farqli o'laroq, AMQP xabarni faqat yorliqli (birja nomi va ixtiyoriy ravishda mavzu yorlig'i) tasvirlaydi va shu asosda uni qiziqqan qabul qiluvchilarga yuborish uchun uni Rabbitga qoldiradi. teg. Muloqot olov va unut va bir yo'nalishli. Biz RabbitMQ yorlig'ini qanday izohlashi haqida ko'proq ma'lumotni keyinchalik almashish va bog'lash haqida gapirganda bilib olamiz. Hozircha siz bilishingiz kerak bo'lgan narsa ishlab chiqaruvchilar xabarlarni yaratishi va ularni marshrutlash uchun belgilashi (2.1-rasmga qarang).

Consumers are just as simple. They attach to a broker server and subscribe to a queue. Think of a queue as a named mailbox. Whenever a message arrives in a particular mailbox, RabbitMQ sends it to one of the subscribed/listening consumers. By the time a consumer receives a message, it now only has one part: a payload. The labels attached to the message don’t get passed along with the payload when the message is routed. RabbitMQ doesn’t even tell you who the producer/sender was. It would be like picking up your mail but all of the envelopes are blank. The only way to know a message is from your Aunt Millie is if she signed the letter inside. Similarly, if you need to know specifically who produced an AMQP message, it’s up to the producer to include that information as a part of the message payload..

Iste'molchilar ham xuddi shunday oddiy. Ular broker serveriga biriktiriladi va navbatga obuna bo'ladi. Navbatni nomlangan pochta qutisi sifatida tasavvur qiling. Xabar ma'lum bir pochta qutisiga kelganda, RabbitMQ uni obuna bo'lgan/tinglovchi iste'molchilardan biriga yuboradi. Iste'molchi xabarni olgan vaqtga kelib, u endi faqat bitta qismga ega: foydali yuk. Xabarga biriktirilgan teglar xabar yo'naltirilganda foydali yuk bilan birga o'tkazilmaydi. RabbitMQ sizga prodyuser/yuboruvchi kimligini ham aytmaydi. Bu sizning pochtangizni olishga o'xshaydi, lekin barcha konvertlar bo'sh. Milliy xolangizdan xabarni bilishning yagona yo'li, agar u xatga imzo qo'ygan bo'lsa. Xuddi shunday, agar siz AMQP xabarini kim ishlab chiqarganini aniq bilishingiz kerak bo'lsa, ushbu ma'lumotni xabar yukining bir qismi sifatida kiritish ishlab chiqaruvchiga bog'liq.

From the outside it’s simple: producers create messages and consumers receive them. Your app can be a producer when it needs to send a message to another app, or it can be a consumer when it needs to receive. It can also switch between the two. But before it can do either it has to set up a channel. Wait a minute … what’s a channel?

Tashqi tomondan hamma narsa oddiy: ishlab chiqaruvchilar xabarlar yaratadilar va iste'molchilar ularni qabul qiladilar. Ilovangiz boshqa ilovaga xabar yuborishi kerak boʻlganda ishlab chiqaruvchi yoki qabul qilishi kerak boʻlganda isteʼmolchi boʻlishi mumkin. Shuningdek, u ikkalasi o'rtasida almashishi mumkin. Lekin buni amalga oshirishdan oldin u kanalni o'rnatishi kerak. Bir daqiqa kutib turing… kanal nima?

Before you consume from or publish to Rabbit, you first have to connect to it. By
connecting, you’re creating a TCP connection between your app and the Rabbit broker.
Once the TCP connection is open (and you’re authenticated), your app then creates
an AMQP channel. This channel is a virtual connection inside the “real” TCP
connection, and it’s over the channel that you issue AMQP commands. Every channel
has a unique ID assigned to it (your AMQP library of choice will handle remembering
the ID for you). Whether you’re publishing a message, subscribing to a queue, or
receiving a message, it’s all done over a channel. Why do we need channels, you might
ask? Why not just issue AMQP commands directly over the TCP connection? The main
reason is because setting up and tearing down TCP sessions is expensive for an
operating system. Let’s say your app consumes messages from a queue and spins
threads up or down based on service demand.

Rabbit-dan iste'mol qilish yoki nashr qilishdan oldin, avval unga ulanishingiz kerak. Ulanish orqali siz ilovangiz va Rabbit brokeri o‘rtasida TCP ulanishini yaratasiz.

TCP ulanishi ochilgandan so'ng (va siz autentifikatsiya qilingansiz), ilovangiz AMQP kanalini yaratadi. Bu kanal "haqiqiy" TCP ulanishi ichidagi virtual ulanish bo'lib, u kanal orqali AMQP buyruqlarini chiqaradi. Har bir kanalga o'ziga xos identifikator tayinlangan (sizning tanlagan AMQP kutubxonangiz siz uchun IDni eslab qolish bilan shug'ullanadi). Xabarni nashr etasizmi, navbatga obuna bo'lasizmi yoki xabar qabul qilasizmi, barchasi kanal orqali amalga oshiriladi. Nima uchun bizga kanallar kerak, deb so'rashingiz mumkin? Nega TCP ulanishi orqali AMQP buyruqlarini bermaslik kerak? Buning asosiy sababi shundaki, TCP seanslarini sozlash va o'chirish operatsion tizim uchun qimmat. Aytaylik, sizning ilovangiz navbatdagi xabarlarni iste'mol qiladi va xizmat talabiga qarab mavzularni yuqoriga yoki pastga aylantiradi.

If all you had were TCP connections, each thread would need its own connection to Rabbit, which could mean hundreds of connections per second during high load periods. Not only would this be a massive waste of TCP connections, but an operating system can only build so many per second. So you could quickly hit a performance wall. Wouldn’t it be cool if you could use one TCP connection for all of your threads for performance, but get the same privacy as giving each thread its own connection? This is where a channel comes in. As each thread spins up, it creates a channel on the existing connection and gets its own private communication path to Rabbit without any additional load on your operating system’s TCP stack, as in figure 2.2. As a result, you can create a channel hundreds or thousands of times a second without your operating system seeing so much as a blip.

There’s no limit to how many AMQP channels you can have on one TCP connection. Think of it like a bundle of fiber optic cable.

Agar sizda faqat TCP ulanishlari bo'lsa, har bir ipning Rabbit-ga o'z ulanishi kerak bo'lar edi, bu yuqori yuklanish davrida soniyasiga yuzlab ulanishlarni anglatishi mumkin. Bu nafaqat TCP ulanishlarining katta isrof bo'lishi, balki operatsion tizim sekundiga shuncha ko'p yaratishi mumkin. Shunday qilib, siz tezda ishlash devoriga urishingiz mumkin. Ishlash uchun barcha oqimlaringiz uchun bitta TCP ulanishidan foydalansangiz yaxshi bo'lmaydimi, lekin har bir ipga o'z ulanishini berish bilan bir xil maxfiylikka ega bo'lsangiz? Bu erda kanal kiradi. Har bir ip aylanayotganda, u mavjud ulanishda kanal yaratadi va 2.2-rasmda bo'lgani kabi, operatsion tizimingizning TCP stekiga qo'shimcha yuklamasdan Rabbitga o'zining shaxsiy aloqa yo'lini oladi. Natijada, siz operatsion tizimingiz bunchalik ko'p narsani ko'rmasdan, soniyada yuzlab yoki minglab marta kanal yaratishingiz mumkin.

Bitta TCP ulanishida qancha AMQP kanaliga ega bo'lishingiz mumkinligiga hech qanday cheklov yo'q. Buni optik tolali kabel to'plami kabi tasavvur qiling.