4

I'm using Redis for storing simple key, value pairs; where, value is also of string type. In my Redis cluster, I've a master and two slaves. I want to propagate any of the changes to the data from one of the slaves to any other store (actually, oracle database). How can I do that reliably? The sink database only needs to be eventually consistent. Some delay is allowed.

Strategies I can think of:

a) Read the AOF file written by the slave machine and propagate the changes. (Requires parsing the AOF file and getting notified of every change to the file.)

b) Use rpoplpush. The reliable queue pattern provided. But, how to make the slave insert to that queue whenever it gets some set event from the master?

Any other possibility?

ptntialunrlsd
  • 794
  • 8
  • 23

1 Answers1

2

This is a very common problem faced by Redis developers. In a nutshell, it is the fact that:

  • Want to know all changes sinse last
  • Keep this change data atomic

I believe that any decision one way or another will be around these issues. So, yes AOF is one of best choises in this case, but here is not any production ready instruments for that. Yes, it is not very complex solution in case of one server but then using master/slave or cluster it can be very complex.

Using Keyspace notifications

Look's like Keyspace Notifications feature may be alternative. Keyspace notifications is a feature available since 2.8.0 and available in Redis cluster too. From original documentation:

Keyspace notifications allows clients to subscribe to Pub/Sub channels in order to receive events affecting the Redis data set in some way.Examples of the events that is possible to receive are the following:

  1. All the commands affecting a given key.
  2. All the keys receiving an LPUSH operation.
  3. All the keys expiring in the database 0.

Events are delivered using the normal Pub/Sub layer of Redis, so clients implementing Pub/Sub are able to use this feature without modifications.

Because Redis Pub/Sub is fire and forget currently there is no way to use this feature if you application demands reliable notification of events, that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost. This can be improved by duplicating the employees who serve this Pub/Sub channel:

  1. The group of N workers subscribe to notification and put data to SET based "sync" list. This allow us control overhead and do not write same data to our sync list.
  2. The other group of workers pop record with SPOP and write it other store.

Using manual update list

The other way is using special "sync" SET based list with every write operation (as i understand SET/HSET in your case). Something like:

MULTI
SET myKey value
SADD myKey
EXEC

Each time you modify your key you add key name to SET. So in other process or worker you can SPOP that key, read value and update source.

Also you can use RPOPLPUSH/LPOPRPUSH besides of SPOP in some kind of in progress list to protect your key would missed if worker failed. In this case each worker first RPOPLPUSH/LPOPRPUSH from sync set to in progress set, push data to storage and remove key from in progress set.

Nick Bondarenko
  • 6,211
  • 4
  • 35
  • 56
  • 1
    > So in other process or worker you can SPOP that key, read value and update source. You do need to make sure that that worker actually completes successfully or you'll loose the `SPOP`ed key... The other way to do it is to `LPOPRPUSH` it to another list, e.g. `inprocess`, and poll it for dead workers. – Itamar Haber Dec 17 '15 at 11:22