How do you guarantee FIFO order from eredis to a haproxy/twemproxy which connects to multiple redis server?
wminghao opened this issue · comments
Hi,
I am reading the code in https://github.com/wooga/eredis/blob/master/src/eredis_client.erl#L257
There is an assumption that redis server will return response based on FIFO order of requests.
My set up is eredis is connected to a haproxy/twemproxy which connects to multiple redis servers, so multiple redis server can return data in different order.
Does it break your assumption? Will it still work?
Cheers,
Howard
The Redis protocol specifies FIFO so it's really the only way to go. There's no other way of stitching a response back to a request.
Judging by the README of twemproxy (https://github.com/twitter/twemproxy#features) it sounds like it parses the request to understand which backend server to send it to. To a client, the proxy looks like the Redis server, so you should be good to use eredis or any other Redis client for that matter.
However, the assumption of FIFO may not be right here, since client sends request to haproxy/twemproxy, and response may come from 2 different redis servers behind haproxy/twemproxy.
---Req1----Haproxy/twemproxy--->redis1
---Req2----------------Haproxy/twemproxy--->redis2
---Resp2-------------------------Haproxy/twemproxy<---redis2
---Resp1---------------------------------------------Haproxy/twemproxy<---redis1
In the above diagram, Resp2 returns before Resp1, but it should be the other around.
That means if everything goes through twemproxy in a single connection, one redis server is slower than a faster redis server, the faster server will have to wait for the slower server to finish before it can receive the data?
Sounds a poor design to me.
I would use multiple connections instead in such case. eredis_pool will work.
You can use https://github.com/silviucpp/redis_pool . eredis_pool have some design issues:
-
It's using another gen_server proxy from where get's the pid of the redis connection inside the poolboy checkout. This is most probably because in the past eredis was crashing the gen_server when connection was lost and if too many crashes takes place in a short period of time the supervisor could stop. This is no longer the case as time newer versions of eredis can reconnect without crashing the gen_server.
-
poolboy seems overkill for managing a pool of redis connections. Instead erlpool overhead is resumed only to one ETS counter_update operation and one lookup
Silviu