Ssdb: Implementieren von veröffentlichen, abonnieren, blpop, brpop

Es ist besser, diese Funktionen zu erhalten, indem Sie Nachrichtenwarteschlangendienste wie ZeroMQ, Gearman usw. verwenden.

Grundsätzlich stimme ich Ihnen zu, habe aber ein paar Einwände:

• Nicht alle Projekte sind Web-Scale (oder sind als solche geplant), ein Startup könnte sich entscheiden, den technologischen Stack einfach zu halten und Redis für Daten, Queue-Broker und Pub-Sub zu verwenden. Aus Versehen sind dies auch dieselben Startups, die von der Kostensenkungseffektivität profitieren würden, wenn nicht alle Daten im Speicher gehalten werden.
  Denken Sie auch daran, dass Startups dazu neigen, einen großen Teil zu OSS beizutragen und leichter zu innovieren.
• Vermutlich auch im großen Maßstab ist ein interner Redis-Publish-Subscribe-Kanal mit geringem Traffic eine gute Idee, um Dienste zu koordinieren, ohne dass ZMQ für einen einfachen Heartbeat-Dienst eingerichtet werden muss.
• Sie werden staunen, aber Redis ist ein verdammt guter Warteschlangen-Broker (nicht alle Projekte erfordern oder profitieren insbesondere von maklerlosen Warteschlangen). Und es gibt viele Projekte, die Warteschlangen in Redis implementieren.
• PubSub in Redis ist auch wirklich schnell (obwohl es natürlich mit einer sehr hohen Anzahl von Abonnenten oder einem sehr hohen Abonnentenverkehr leidet).

Ich habe erst vor kurzem von SSDB erfahren. Gute Arbeit!
Da SSDB als Alternative zu Redis gemacht wird, würde ich erwarten, dass es Pub-Sub enthält. Da Microsoft die Redis-Unterstützung eingestellt hat, habe ich SSDB als Alternative angesehen, kann sie jedoch nicht verwenden, da sie Pub-Sub nicht unterstützt.
Eine Sache, die ich bei Redis Pub-Sub-Messaging wirklich vermisst habe, sind die Schlüsselwerte (alt-neu). Ich würde mich sehr freuen, wenn das zu SSDB hinzugefügt würde!