☰

» »

MQ z bazo

MQ z bazo

kunigunda ::

Ojla, zanima me kateri MQ-ji so te cajte najbolj uporabljeni ?
Malo gledam po netu, pa bodisi nimajo baze zadi (ce se masina ugasne zgubis vse),
ali pa moras zraven prilimati se 100mb knjiznic.
Enkrat sem sicer probal Oracle ActiveMQ pa mi ni bil pretirano hiter, kakor imam v spominu.

krho ::

MQ as in message queue?

Imaš RabbitMQ ki je iz AMQP skupine, tu je precej brokerjev, pri njem vem da se da nastaviti da so queue "durable". Sam men je AMQP prekompleksen za neke simpl stvari. Za simpl je bil Disque od antirez fajn... Pa carski api v stilu... čakaj na sporočilo na queue1, queue2, queue3 ( in pol vrne sporočilo iz prvega queue, ki ga dobi, fino za t.i. prioriteto) Sam zdej je to plugin za redis, pa takoj rabiš vsaj dva redisa dat v cluster :(. Sam se trenutno nekaj spogledujem z NATS v JetStream načinu. Predvsem zato, ker podpira tudi MQTT.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

Zgodovina sprememb…

  • spremenil: krho ()

JeBelaCesta ::

IBM MQ? https://www.ibm.com/products/mq
Menda se uporablja v EU za carinske zadeve/storitve.
lep pozdrav iz višav ;-)

Spura ::

MQ ne rabi nujno baze za durability, ne vem od kod te ideje. Drugace imas vse sorte queuev, recimo https://github.com/OpenHFT/Chronicle-Qu...

kunigunda ::

Spura je izjavil:

MQ ne rabi nujno baze za durability, ne vem od kod te ideje. Drugace imas vse sorte queuev, recimo https://github.com/OpenHFT/Chronicle-Qu...

Pod bazo sm imel v mislih karkoli je syncan z diskom.

pegasus ::

SMTP? Najstarejši in najbolje razumljen store-and-forward ;)

c3p0 ::

RabbitMQ je kar popularen, tudi sam par clusterjev adminam, queue je lahko durable ali transient. Če rabiš top perf, pa bo kafka boljša.

krho ::

Kafka ne bo hitrejša od NATS. Še manj pa bo manj požrešna od njega. JVM pač dela svoje.
Isti service ko je bil prepisan iz Jave v Go je skuril le nekaj 10mb prostora na disku (Docker image) pa pri Ramu pa je bilo tudi tam nekje. Ravno tako je bil nižji CPU usage.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

Zimonem ::

Najbolj uporabljan je mqtt. Ni za vse je pa zihr najbolj uporabljan.

shm ::

Zimonem je izjavil:

Najbolj uporabljan je mqtt. Ni za vse je pa zihr najbolj uporabljan.

mqtt ni queue, ceprav ima mq v imenu.

kunigunda ::

c3p0 je izjavil:

RabbitMQ je kar popularen, tudi sam par clusterjev adminam, queue je lahko durable ali transient. Če rabiš top perf, pa bo kafka boljša.

O kaksnem top perfu je kle govora ? Jest rabm nekje 10k msg/sek, velikosti par kb.

krho ::

To ti bo dandanes sfolgal praktično vsak queue. Še pubsub na redisu, če maš že redis v infrastrukturi
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

kunigunda ::

c3p0 je izjavil:

RabbitMQ je kar popularen, tudi sam par clusterjev adminam, queue je lahko durable ali transient. Če rabiš top perf, pa bo kafka boljša.

A se da queueje managirat tud on the fly (iz clienta) al mors prej na serverju nastavt ce jih hocs uporablat ?

c3p0 ::

kunigunda je izjavil:

c3p0 je izjavil:

RabbitMQ je kar popularen, tudi sam par clusterjev adminam, queue je lahko durable ali transient. Če rabiš top perf, pa bo kafka boljša.

A se da queueje managirat tud on the fly (iz clienta) al mors prej na serverju nastavt ce jih hocs uporablat ?


Preko Web GUI lahko dodaš queue, ali preko kode preveriš ali že obstaja in ga kreiraš.

kunigunda je izjavil:

c3p0 je izjavil:

RabbitMQ je kar popularen, tudi sam par clusterjev adminam, queue je lahko durable ali transient. Če rabiš top perf, pa bo kafka boljša.

O kaksnem top perfu je kle govora ? Jest rabm nekje 10k msg/sek, velikosti par kb.


RabbitMQ komot prenese 10k/s, seveda odvisno od HW, pa niti ne slovi kot nek zelo hiter queue, ga kafka pelje scat. Za ostale ne vem.

Zgodovina sprememb…

  • spremenil: c3p0 ()

kunigunda ::

Tegale ne stekam dobr od Rabbita:

There are two main message queue life-cycles:
- Durable message queues that are shared by many consumers and have an independent existence - i.e.
they will continue to exist and collect messages whether or not there are consumers to receive them.
- Temporary message queues that are private to one consumer and are tied to that consumer. When the
consumer disconnects, the message queue is deleted.

A to pomen ce producer fila, consumerja pa ni (ali pa se npr disconnecta), da grejo v nic ?
Prvo pa ne stekam, a mora consumer pol sam skrbet za dodatno brisanje v queueju.

steev ::

Ce se prav spomnim rabbita, mora consumer poskrbeti za to. Kar je lahko dobro ali pa ne, dovisno od namena.

https://www.rabbitmq.com/confirms.html
:|

kunigunda ::

steev je izjavil:

Ce se prav spomnim rabbita, mora consumer poskrbeti za to. Kar je lahko dobro ali pa ne, dovisno od namena.

https://www.rabbitmq.com/confirms.html

Aha, sej v bistvu ma pol confirm kot response. Edin ce bi glih vmes pr responsu net crknu, pol bi verjetno rabu 2-step confirmation.

kunigunda ::

Kljub morju MQ brokerjev se mi zdi da je se vedno vecina preglomaznih, verjetno zarad konkurence pol ponujajo en kup stvari, k jih niti ne rabis.
Tale rabbit mi je se najbolj blizu ceprov po reviewih ene par stvari manjka. Ga bom pa preizkusil da vidm.

kunigunda ::

Ne vem zakaj je sicer Rabbit MQ popularn ampak men se zdi shitty :)
Za instalacijo rabs se Visual C pa Erlang, za Clienta v javi pa se posebi Rabbit Node :S:S:S

HotBurek ::

Če si pravi moški, potem sprogramiraj to logiko premikanja informacij iz enega serverja na drugega, pač sam.

- komunikacijo med serverji narediš na HTTP GET/POST
- queue ti predstavlja folder
- fajl poimenuješ datum-čas-zfill(6) npr. 20211212-164315-000000, 20211212-164315-000001, 20211212-164315-000002
- 000000, 000001, 000002 itn. zato, če dobiš znotraj ene sekunde več sporočil
- zlistaš vse fajle v queue folderju, jih sortiraš naraščajoče, in imaš FIFO
- če rabiš prioriteto, jih poimenuj a-datum-čas-zfill(6), b-datum-čas-zfill(6), c-datum-čas-zfill(6)
- format v fajlu lepo enostavno protperty1=value1\nprotperty2=value2\nprotperty3=value3\n
- sparsaš fajl; split po \n, trim, split po =, shraniš v memori in potem iz tega nekaj narediš


Ali pa kompliciraj, pa nameščaj cloud, blogchain, machine learning, artifišal something, continuos integration, metawars, docker in ostale reči iz zakladnice marketinških nategunov.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Zgodovina sprememb…

  • spremenilo: HotBurek ()

win64 ::

zlistaš vse fajle v queue folderju, jih sortiraš naraščajoče, in imaš FIFO

To je neverjetno počasna operacije. File monitor je v takih primerih primernejši.
Je pa vprašanje kako se monitor obnaša pri velikem številu novih zapisov.

Tudi jaz ne vidim velikega smisla v nekem generičnem MQ.
- Implementacija z bazo: recimo frontend aplikacije ustvarjajo zahtevke v tabeli, servis za obdelave bere in jih obdeluje.
- Če aplikaciji nimata dostopa do baze se naredi nek HTTP REST API. Ali pa če hočeš komplicirati si izmisliš svoj TCP protokol.

Zgodovina sprememb…

  • spremenil: win64 ()

kunigunda ::

HotBurek je izjavil:

Če si pravi moški, potem sprogramiraj to logiko premikanja informacij iz enega serverja na drugega, pač sam.

- komunikacijo med serverji narediš na HTTP GET/POST
- queue ti predstavlja folder
- fajl poimenuješ datum-čas-zfill(6) npr. 20211212-164315-000000, 20211212-164315-000001, 20211212-164315-000002
- 000000, 000001, 000002 itn. zato, če dobiš znotraj ene sekunde več sporočil
- zlistaš vse fajle v queue folderju, jih sortiraš naraščajoče, in imaš FIFO
- če rabiš prioriteto, jih poimenuj a-datum-čas-zfill(6), b-datum-čas-zfill(6), c-datum-čas-zfill(6)
- format v fajlu lepo enostavno protperty1=value1\nprotperty2=value2\nprotperty3=value3\n
- sparsaš fajl; split po \n, trim, split po =, shraniš v memori in potem iz tega nekaj narediš


Ali pa kompliciraj, pa nameščaj cloud, blogchain, machine learning, artifišal something, continuos integration, metawars, docker in ostale reči iz zakladnice marketinških nategunov.


Sej v bistvu zgodba je taka da sm pravi moski lol. Mam ze 20 let svojo resitev ki je v bistvu tko kot vidim podobna rabbitu. Quejij publish consume subscribe prioritete ipd. ter svoj mq binarni protokol ceprov pdopiram tud soap/rest in v vsem tm cajtu ni bilo nikoli problemov. Pac pa nova politika podjetja zahteva za vse obstojece stvari da popirajo ssl in cluster in sm reku bom prej pobrsku za novimi stvarmi ki to majo predno grem tok staro kodo popravljat kar je nehvalezno. Ampak ocitno se mi to bolj casovno splaca kukr da mi cajt pa zivce jemjejo novodbne stvari :)
Sm pa to server client varianto takrat naredu v bistvu zato ker mi CORBA ni bla vsec in je blo tud neka "vmesna" resitev. Edin podporo sincanja z diskom bom verjetno tud dodal high speed bazo mam ze za druge namene sprogramirano.

Hvala vseeno za vse odgovore.

HotBurek ::

Ja no, to imaš potem že vse rešeno, razen TLS in klusterja.


Za TLS pač naprogramiri nek wrapper. Pa glede certifikatov; kdo jih bo izdajal, veljavnos, renew postopek, kje bodo shranjeni lokalno, kje so CRL liste, itn. To enkrat narediš in potem to dela. Če nimate internega sistema izdajanja certifikatov, lahko uporabiš certbot / sslforfree combo. Mislim, da bi zadevo lahko poganjal tudi, če so strežniki dosegljivi samo na private IPjih, ker lahko requeste confirmaš preko DNS, ftp, pa še česa.


Glede cluster zadeve pa mogoče, da pogledaš dokumentacijo od rabbit/active/whatever MQ; kako imajo rešen cluster, kako je implementirana. Potem pa izbereš eno opcijo in sprogramiraš ta cluster. Na koncu imaš Pravi Moški tm cluster, ki pa funkcionira isto, kot tisti od brand-ed MQ, tako da te težje kdo matra, da bo treba migrirat al pa kej.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Zgodovina sprememb…

  • spremenilo: HotBurek ()

Lonsarg ::

Ce je politika da je vse SSL ter cluster bi nekako pricakoval da je tudi kak kubernetes cluster kje postavlen. Tak z genericno SSL podporo itd.

V tem primeru developer samo poskrbi za docker file. In hopla poljubna interna aplikacija postane highly available in z SSL podporo.

Spura ::

Torej na vrh nekega home-baked sistema, ki je zelo kompliciran, bi zdej se neke adhoc kmecke resitve z nekimi folderji. Niste normalni. In to zato da se prispara na disk placu ki bi ga zavzeli dependencyi.

HotBurek ::

Torej na vrh nekega home-baked sistema, ki je zelo kompliciran, bi zdej se neke adhoc kmecke resitve z nekimi folderji.

To, da je custom rešitev že 20 let postavljena (in da ne postavlja iz nule), je bilo podano šele na koncu. Tega do sedaj nismo vedeli.

In to zato da se prispara na disk placu ki bi ga zavzeli dependencyi.

Gre se za to, da imajo te rešitve vlkjučen nebodi ga treba bloatware.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

win64 ::

A mi kdo pove, kje uporabljate te sisteme v praksi?

kunigunda ::

HotBurek je izjavil:

Ja no, to imaš potem že vse rešeno, razen TLS in klusterja.


Za TLS pač naprogramiri nek wrapper. Pa glede certifikatov; kdo jih bo izdajal, veljavnos, renew postopek, kje bodo shranjeni lokalno, kje so CRL liste, itn. To enkrat narediš in potem to dela. Če nimate internega sistema izdajanja certifikatov, lahko uporabiš certbot / sslforfree combo. Mislim, da bi zadevo lahko poganjal tudi, če so strežniki dosegljivi samo na private IPjih, ker lahko requeste confirmaš preko DNS, ftp, pa še česa.


Glede cluster zadeve pa mogoče, da pogledaš dokumentacijo od rabbit/active/whatever MQ; kako imajo rešen cluster, kako je implementirana. Potem pa izbereš eno opcijo in sprogramiraš ta cluster. Na koncu imaš Pravi Moški tm cluster, ki pa funkcionira isto, kot tisti od brand-ed MQ, tako da te težje kdo matra, da bo treba migrirat al pa kej.

Za SSL mam ze lib narjen k ga drgje uporabljam tko da kodiranje ni problem. Hotu sm se sam izognt upgrejdu kode pa mogoce se kako dodatno funkcionalnost najdt pri novodobnih produktih.
Problem je pa bolj samo cajt :) Se pa k sreci ne mudi glede politike, tko da mam se dost cajta.

kunigunda ::

win64 je izjavil:

zlistaš vse fajle v queue folderju, jih sortiraš naraščajoče, in imaš FIFO

To je neverjetno počasna operacije. File monitor je v takih primerih primernejši.
Je pa vprašanje kako se monitor obnaša pri velikem številu novih zapisov.

Tudi jaz ne vidim velikega smisla v nekem generičnem MQ.
- Implementacija z bazo: recimo frontend aplikacije ustvarjajo zahtevke v tabeli, servis za obdelave bere in jih obdeluje.
- Če aplikaciji nimata dostopa do baze se naredi nek HTTP REST API. Ali pa če hočeš komplicirati si izmisliš svoj TCP protokol.


Direkt baza je tud prepocasna, fajli kot si rekel pa sploh. Potem je tukaj se zaklepanje, da dva klienta vzporedno ne interferirata podatkov ipd.
Tud strukture queuejev so lohk razlicne, server v bistvu ne ve kaksni messagi so, to vejo sam klienti. V bistvu je pa dost simpl sistem, sam pri opensourcih
je verjetn tko da scasoma ko ljudje z vseh koncov sveta majo svoje zelje, ratajo z leti napihnjeni.

c3p0 ::

kunigunda je izjavil:

Ne vem zakaj je sicer Rabbit MQ popularn ampak men se zdi shitty :)
Za instalacijo rabs se Visual C pa Erlang, za Clienta v javi pa se posebi Rabbit Node :S:S:S


Hja pisan je v Erlang, ergo.. Visual C? Tu nekaj ne štima. Rabbit Node, to je mišljeno kot server? Gotovo rabiš node, da se sploh konektaš gor. :)

mr_chai ::

kunigunda je izjavil:

Tegale ne stekam dobr od Rabbita:

There are two main message queue life-cycles:
- Durable message queues that are shared by many consumers and have an independent existence - i.e.
they will continue to exist and collect messages whether or not there are consumers to receive them.
- Temporary message queues that are private to one consumer and are tied to that consumer. When the
consumer disconnects, the message queue is deleted.

A to pomen ce producer fila, consumerja pa ni (ali pa se npr disconnecta), da grejo v nic ?
Prvo pa ne stekam, a mora consumer pol sam skrbet za dodatno brisanje v queueju.


Hmm, dobro v prašanje. Načeloma lahko tudi nastaviš TTL kdaj se messigi pobrišejo. Pomojem se temp queji vzpostavljajo preko requesta consumerja in pol ko se consumer disconnecta, se avtomatično pobrišejo.

Zgodovina sprememb…

  • spremenilo: mr_chai ()

darkolord ::

win64 je izjavil:

A mi kdo pove, kje uporabljate te sisteme v praksi?
Na primer:
- Eventi se generirajo v nekem tretjem sistemu, ki bi jih rad v mojem sistemu uporabil. Jaz se samo priklopim na ustrezen topic in berem ven dogodke, tretji sistem o mojem ne ve prav ničesar.
- En servis želi o neki spremembi obvestiti vse ostale servise. Koliko je ostalih, nima pojma. Lahko ni nobenega, lahko jih je več.
- Reagirati je treba na nek dogodek, ampak samo in točno enkrat. MQ bo poskrbel za to, da se eno sporočilo sprocesira samo enkrat, tudi če je več consumerjev.

Že tam, kjer je več odjemalcev na eni ali drugi strani, propade velik del zgoraj omenjenih DIY rešitev.

Zgodovina sprememb…

  • spremenilo: darkolord ()

elrado ::

Do sedaj sem MQje uprabljal v dveh sistemih:
Intralogistični sistem, kjer so "odjemalci" iz vse države svoje tickete pošiljali na MQ (Tibco). Mi smo jih pobirali, obdelovali in na podlagi le teh izvajali logiko na mašinah. Iz MQ se je zadeva lahko zbrisala šele ko je bila varno pri nas v bazi. Odjemalci so bili 1 stran, vzdrževalci precej velikega MQja druga in potem mi.

Real time sistem, ki je od n klientov v "real time" shranjeval podatke. Moral je biti čim hitrejši, da je dobil čim več in da stranke niso čakale. Te podatke smo potem obdelovali in shranjevali. Ravno tako smo po določenem času na njihovi podlagi sproižili nove akcije in rezultate pošiljali ma MQ. Se pravi vmesniki med n strankami in nami so bili vsi na MQjih.
Zadeva je bila preverjena, asinhrona in je delovala (oz še deluje BP). Lahko da bi nek na roko narejen sistem delal podobno a za precej večji vložek (developerski).

Pri obeh sistemih nam je MQ pomagal (poleg standarnega vmesnika in zrelih rešitev) predvsem pri obvladovanju podatkovnih peakov (Bursts).

kunigunda ::

Ja sej to je pomoje edina uporabnost MQjev da neki posljes pa ne cakas drug pa obdeluje. Edin ce je queue tip directa da publisher caka na izvedbo. Asinhroni ipc bi lohk tud reku.

mr_chai ::

kunigunda je izjavil:

Ja sej to je pomoje edina uporabnost MQjev da neki posljes pa ne cakas drug pa obdeluje. Edin ce je queue tip directa da publisher caka na izvedbo. Asinhroni ipc bi lohk tud reku.


https://engineering.linkedin.com/distri...

win64 ::

Hvala za vse primere. Očitno nisem še naletel na tako količino zahtevkov, da bi to pohitrilo ali naredilo zadevo bolj zanesljivo.

Bom imel v mislih za naslednje projekte.

win64 ::

Še eno vprašanje. Recimo, da imaš spletno aplikacijo za oddajo različnih naročil. Vsako vrsto naročila bi obdeloval drugi servis. Se da te zapise v vrsti kako označit/kategorizirat tako da določen servis prevzame samo "svoja" naročila.

Kaj pa če imaš več manjših internih aplikaciji. Je potrebno za vsako aplikacijo postavit novo instanco MQ? Kako je sploh z instancami pri MQ - je podobno kot pri bazah?

shm ::

Vse to se da nardit. Verjetno najboljs da si pogledas RabbitMQ tutoriale, da vidis osnovne koncepte. Tudi ce potem izberes kaksen drug MQ delajo v osnovi vsi precej podobno.

Ne rabis za vsako aplikacijo svoje instance. Lahko imas vec queue-jev v eni instanci kar bi verjetno lahko primerjal s tabelami v bazah.

kunigunda ::

mr_chai je izjavil:

kunigunda je izjavil:

Ja sej to je pomoje edina uporabnost MQjev da neki posljes pa ne cakas drug pa obdeluje. Edin ce je queue tip directa da publisher caka na izvedbo. Asinhroni ipc bi lohk tud reku.


https://engineering.linkedin.com/distri...

Ce je transport tcp to upocasni aplikacijo,ce je ssl gor se toliko bolj, edino ce udp omogoca server.

win64 ::

shm je izjavil:

Vse to se da nardit. Verjetno najboljs da si pogledas RabbitMQ tutoriale, da vidis osnovne koncepte. Tudi ce potem izberes kaksen drug MQ delajo v osnovi vsi precej podobno.

Ne rabis za vsako aplikacijo svoje instance. Lahko imas vec queue-jev v eni instanci kar bi verjetno lahko primerjal s tabelami v bazah.


Bom preveril, hvala za vse informacije. Še je upanje za slo-tech :)

c3p0 ::

win64 je izjavil:

Še eno vprašanje. Recimo, da imaš spletno aplikacijo za oddajo različnih naročil. Vsako vrsto naročila bi obdeloval drugi servis. Se da te zapise v vrsti kako označit/kategorizirat tako da določen servis prevzame samo "svoja" naročila.

Kaj pa če imaš več manjših internih aplikaciji. Je potrebno za vsako aplikacijo postavit novo instanco MQ? Kako je sploh z instancami pri MQ - je podobno kot pri bazah?


Vrste ločiš v ločene queues, imaš pa tudi "vhost" konstrukt, ki je še en nivo višje in vsak lahko vsebuje svoje queues. Vsak queue pa seveda svoje nastavitve (transient, ttl, priority...). Vse to je lahko v eni instanci Rabbita ali Rabbit clusterja.

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Worker arhitektura

Oddelek: Programiranje		102140 (1752) pegasus
»

SMTP promet (strani: 1 2 3 4 )

Oddelek: Omrežja in internet		18118909 (16960) NeMeTko
»

Real-time database

Oddelek: Programska oprema		351578 (1095) kunigunda

Več podobnih tem