PublicShow sourceredis_streams.pl -- Using Redis streams

A Redis stream is a set of messages consisting of key-value pairs that are identified by a time and sequence number. Streams are powerful objects that can roughly be used for three purposes:

This library abstracts the latter two scenarios. The main predicates are

See also
- https://redis.io/topics/streams-intro
Source xstream_set(+Redis, +Key, +Option)
Set an option on for Key on Redis. Currently supports:
maxlen(+Count)
Make xadd/4 add a MAXLEN ~ Count option to the XADD command, capping the length of the stream. See also Redis as a message brokering system
Source xadd(+Redis, +Key, ?Id, +Data:dict) is det
Add a message to a the stream Key on Redis. The length of the stream can be capped using the xstream_set/3 option maxlen(Count). If Id is unbound, generating the id is left to the server and Id is unified with the returned id. The returned id is a string consisting of the time stamp in milliseconds and a sequence number. See Redis docs for details.
Source xlisten(+Redis, +Streams, +Options)
Listen using XREAD on one or more Streams on the server Redis. For each message that arrives, call broadcast/1, where Data is a dict representing the message.
broadcast(redis(Redis, Stream, Id, Data))

Options:

count(+Count)
Process at most Count messages per stream for each request.
start(+Start)
Normally either 0 to start get all messages from the epoch or $ to get messages starting with the last. Default is $.
starts(+List)
May be used as an alternative to the start/1 option to specify the start for each stream. This may be used to restart listening if the application remembers the last processed id.

Note that this predicate does not terminate. It is normally executed in a thread. The following call listens to the streams key1 and key2 on the default Redis server. Using reconnect(true), the client will try to re-establish a connection if the collection got lost.

?- redis_connect(default, C, [reconnect(true)]),
   thread_create(xlisten(C, [key1, key2], [start($)]),
                 _, [detached(true)]).
Arguments:
Redis- is either a Redis server name (see redis_server/3) or an open connection. If it is a server name, a new connection is opened that is closed if xlisten/3 completes.
See also
- redis_subscribe/2 implements the classical pub/sub system of Redis that does not have any memory.
Source xlisten_group(+Redis, +Group, +Consumer, +Streams, +Options)
Listen as Consumer to Group. This is similar to xlisten/3, with the following differences:

Options processed:

block(+Seconds)
Causes XREADGROUP to return with timeout when no messages arrive within Seconds. On a timeout, xidle_group/5 is called which will try to handle messages to other consumers pending longer than Seconds. Choosing the time depends on the application. Notably:
  • Using a time shorter than the required processing time will make the job migrate from consumer to consumer until max_deliveries(Count) is exceeded. Note that the original receiver does not notice that the job is claimed and thus multiple consumers may ultimately answer the message.
  • Using a too long time causes an unnecessarily long delay if a node fails.
max_deliveries(+Count)
Re-deliver (using XCLAIM) a message max Count times. Exceeding this calls xhook/2. Default Count is 3.
max_claim(+Count)
Do not claim more than Count messages during a single idle action. Default is 10.
Source xconsumer_stop(+Leave)
May be called from a consumer listener to stop the consumer. This predicate throws the exception redis(stop(Leave)), which is caught by xlisten_group/5.
Source xhook(+Stream, +Event)[multifile]
This multifile predicate is called on certain stream events. Defined events are:
delivery_failed(Id, Group, Delivered)
A message was delivered more than specified by max_deliveries/1 of xlisten_group/5. Id is the message id, Group the group and Delivered the current delivery count. If the hooks fails, the message is acknowledged using XACK. From introduction to streams:
"So once the deliveries counter reaches a given large number that you chose, it is probably wiser to put such messages in another stream and send a notification to the system administrator. This is basically the way that Redis streams implement the concept of the dead letter."