message queue redis-szel

Csinalt mar valaki ilyet? Tapasztalatok?

( zsolt.k | 2014. 12. 13., szo – 14:13 )

Igen. Tökéletesen működik. Mire vagy kíváncsi?

mondjuk arra, hogy mekkora 'uzeneteket' toltok bele, mekkora a read/write performancia, ill. mekkora memoria igenye van az n db uzenetnek, ill. hogy sima lpush, lpop parancsokat hasznaltok, vagy valami komplikaltabb modon oldottatok meg?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

"hogy sima lpush, lpop parancsokat hasznaltok"

Igen.

"mekkora 'uzeneteket' toltok bele"

Jellemzően nagyon kicsiket, job queue-nak használjuk, az üzenet a worker-ek által végrehajtandó utasítást, és annak paramétereit tartalmazza. Egy-egy üzenet maximum mérete 1 Kbyte körüli.

"mekkora a read/write performancia, ill. mekkora memoria igenye van az n db uzenetnek"

Erre nem tudok neked választ adni, egyrészt mert hétvége van :), másrészt mert nem végeztünk méréseket ezzel kapcsolatban. De normál (nem extrém nagy terhelésű) használatra tökéletesen megfelel mind performancia, mind erőforráshasználat tekintetében, ha pedig nem normál felhasználásra tervezed, akkor ne használj Redis-t, hanem valami masszívabb queue megoldást.

Mert az állt rendelkezésre az adott környezetben, azzal volt a fejlesztőcsapatnak tapasztalata, és miután kipróbáltuk, tökéletesen megfelelt a feladatra. :) De ha a performancia a lényeg, akkor mindenképpen egy erre a célra kihegyezett queue vagy message broker rendszer az ideális választás (pl. Apache Kafka).

a github a resque nevu cuccot hasznalta, ez egy ruby library (van php valtozat is), redisben taroltak az adatokat: egy listaban vannak a job azonositok, azt kezeli ha kiad valakinek egy feladatot, es kulon kulcsokban volt a job data.

amit en viszont nem tudok, hogy a turoba lehet ezt a redis HA-ra epiteni?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

En sem tudok HA megoldasrol, a legegyszerubb gondolom a workereket tobb redis szerverre felkapcsolni, a fo app pedig oda oszt feladatot, amit epp eler. Mivel effektiv adat nincsen a message-ben (az az adatbazisbol jon, csak a jobbal kapcsolatos adatok kellenek redisbe), igy nem kell az inkonzisztencia miatt aggodni, a redisben levo adatokkal szemben nem szempont, hogy perzisztensek legyenek.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( bra | 2014. 12. 13., szo – 22:54 )

Nem tudom mit akarsz csinálni, de érdemes lehet megnézni a "rendes" MQ-kat is. (bár nem a leggyorsabb, a saját tapasztalataim alapján a rabbitmq áll a legközelebb ahhoz, hogy azt, amit vállal, teljesítse is, a többieknél (activemq, hornetq) random helyeken fura meglepetések értek...
--
zsebHUP-ot használok!