Correlating redis requests and responses
Methos
I have multiple processes that issues GET & SET requests to redis server. These processes are short lived. Rather than establishing TCP connection before every redis command, I decided to write a 2 threaded server that will keep connection with the redis server alive. One thread will accept redis commands from the processes and send it to redis server. The other thread will read the responses and dispatch responses back to each process. However, in the redis protocol, there is no notion of request and response id. Thus I don't know how to correlate requests and responses.
One solution is to issue a request and not to issue another request until the first request's response is received. However, this adds RTT * (number of pending requests ahead of you) delay for each request. Another solution is to use part of value to store the key. For e.g. if I want to set key "FOO" to value "BAR" then actually set it to "FOO_BAR". When the response comes back, separate the key and value part and then dispatch the value to the waiting process.
What is the suggested way of doing this? Is there any other better way?
-m
Josiah Carlson
you server local and Redis remote? You using unix domain sockets?
To answer your question, because Redis responds to requests in the
order in which they were received (especially from a single given
connection), you can simply issue the commands sequentially with your
sending thread, adding a process identifier to a queue. Your receiving
thread would then just read responses from Redis, popping process
identifiers from the queue as necessary, and sending the response to
the process identifier related to the received response.
That said... I suspect that Redis would do at least as well at
handling this as any solution you would come up with. Not because I
don't think you are good, but because Redis has been optimized for
what it does, and you'd not only have to implement a high-speed socket
server and client in the same process, but you'd also have to
implement the Redis protocol or some other protocol on top of just the
socket client and server.
That said, have you tested Redis and determined that it isn't fast enough?
Regards,
- Josiah
> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.
>
Methos
think redis is pretty good at what it does. All I was suggesting is
some work around on top of redis so that I can run redis server on a
remote machine and still be able to issue multiple requests and
correlate the responses. I knew that since the transport protocol is
TCP, network will not reorder the datagrams. They will be delivered in
the order as they were sent. However, I was not sure if the redis
server obeys the processing order. From your response it looks like
so. Thus I will just do what you have suggested. Issue a request and
push the process id in a queue. Then receive a response and pop the
request id.
Thank you.
-m
