התייעצות טכנית אולי מישהו פה יודע

[user32]

אני מחפש queue עם יכולת שבעיניי נראית טרויוואלית אבל משום מה נראה שלא נתמכת בSQS של אמזון וגם לא בטוח בRabbitMQ.
אני רוצה שהתור ישחרר הודעות בקצב מסויים. למשל אם הגדרתי שהקצב הוא 1 לשניה, ויש בתור 30 הודעות, ההודעות ישתחררו כל שניה, גם אם יש 100 מאזינים פנויים, כל שניה תפלט הודעה.
כל התורים תומכים בdelay אבל זה רק אומר שההודעה נשארת בתור לX זמן. אני מעוניין לעשות delay בין הודעה להודעה. אז אם אני מכניס בבת אחת 30 הודעות, ייקח להם 30 שניות לצאת מהתור. אם אני משתמש בdelay רגיל, אז מה שיקרה הוא שכולם יהיו ביציאה מהתור אחרי 30 שניות ואם יש לי 30 מאזינים לתור, הרי שכולם יימשכו החוצה באותו זמן.

אשמח לפתרון שמעביר את האחריות לqueue עצמו ולא כאלה של מימוש עצמי, או שהconsumers צריכים לנהל ביניהם את זמני המשיכה.

תודה

 

[BismarkReborn]

אם אני מבין אותך נכון אז redis streams אמורים לתמוך במשהו כזה (אם כי אף פעם לא ניסיתי לעבוד ככה בעצמי)

 

[user32]

תודה. אנחנו משתמשים ברדיס אז אני אבדוק את הנושא של streams. מהלינק קשה להבין אם זה עונה על הצורך וגם אין הרבה תיעוד תזמונים בstreams. אני אבדוק.

שבת שלום

 

[user32]

עדכון למתעניינים. השתמשנו בסוף בDisributed Lock כך שכל קונסיומר תופס את המנעול למשך שניה וכך כל הצרכנים מסנכרנים את התזמון ביניהם.
השתמשנו בDLM של רדיס Redlock:

Distributed Locks with Redis

A distributed lock pattern with Redis

redis.io

 

[vinney]

עדכון למתעניינים. השתמשנו בסוף בDisributed Lock כך שכל קונסיומר תופס את המנעול למשך שניה וכך כל הצרכנים מסנכרנים את התזמון ביניהם.
השתמשנו בDLM של רדיס Redlock:

Distributed Locks with Redis

A distributed lock pattern with Redis

redis.io

סליחה שאני מאחר למסיבה, אבל למה לא זה?

 

[user32]

זה אכן היה איחור, וזה אכן סוג הפתרון שחיפשנו ומשום מה לא נתקלתי בפרוייקט הזה בחיפושים.
ראשית, לא נראה שיש להם ספרייה לnode וזה קצת overhead מבחינתי ההתעסקות עם זה, מה גם שהשימוש שלנו די שולי. לredlock לעומת זאת יש מימוש לnodejs.

שנית, הם בעצמם משווים בין הפתרון שלהם לזה של redlock ומשהו שלא הבנתי בטענה שלהם. אין צורך לנעול את הקיו לpush כשעושים נעילת redlock. אנחנו נועלים key מסויים (השם-ID של הקיו לצורך העניין) רק בשביל קריאות pop. כלומר התור ימשיך לגדול כרגיל אבל המשיכות ייעשו בסינכרון. לא הבנתי למה הם טוענים אחרת.
אחרון, זה ממומש מעל קפקא מה שיאלץ אותנו לתחזק קפקא שכרגע אין לנו שימוש בו ונצטרך להחליף את כל התורים שלנו שצריכים סינכרון (כרגע הם ב SQS) בקפקא.
אבל כן, זה בדיוק סוג הפתרון שחיפשתי בזמנו. תודה!

 

[vinney]

לnode יש את זה, לא יתאים לך?

בכל אופן, מה שחיפשתי זה throttled queue, כי זה מה שאתה מתאר. אני עובד עם זה כל יום כל היום (פתרון פנימי שלנו, לא יעזור לך), נראה לי מוזר שהיה לך קשה למצוא פתרון מוכן....

 

[user32]

rate limiters בדקתי הרבה. רובם עובדים כמו זה שהצגת. מאפשרים X בקשות ודוחים מה שלא עומד בקצב. יש לנו שימוש בזה לדברים אחרים קלאסיים (rate limit לבקשות נכנסות אלינו).
אני מחפש queue שיגדל גם אינסוף אבל שיתרוקן בקצב מסויים. ועם כל היתרונות האחרים של תור מודרני: FIFO, persistence, סקלביליות של התור עצמו, אמינות, ניטור וכו'. כגון: קפקא, SQS, רביט.
הפתרון הראשון שהצגת הוא כזה. לא מצאתי הרבה כאלה.