envoyproxy / envoyproxy/envoy

Redis Proxy improvements to Support commands PubSub , Streams , Scripts. Info... 50+ commands

Open
#38,492 26 comments 23 reactions 1 assignee Assigned to @dinesh-murugiah View on GitHub
area/redis enhancement no stalebot
Dominant language
C++
Stars
28.9k
Forks
5.6k
Avg merge
1d 20h
Merged PRs (30d)
437

Description

*Title*: Redis proxy - More classes and Design patterns to support additional commands

*Description*:
HI i am Working for https://www.freshworks.com/ . We have self hosted redis cluster in our organisation
we are using Envoy proxy for our clients interaction . The Envoy in its current form lacks support many commands
To make it useful for us we have made changes in envoy to support more than 50+ commands and its been running in production

We would like to contribute those changes to envoy community ,
starting this issue thread to initiate a conversation and understand is anyone else is working on such improvements

Short summary of Proposal
1. The current redis proxy code follows a chain of responsibility and observer design pattern , such that the commands received in proxy filter is linearly processed in chain and response is sent back
2. This design pattern will not allow for supporting commands like pubsub, blocking commands , which requires dedicated 1:1 connections between redis and client , rather than going via upstream connection pool
3. The proposal is to extend or transform the transaction class in to a bridge class , which will have abstractions to support implementations for pubsub , blocking , transaction commands , based on the input command appropriate implementation will be invoked with a dedicated upstream client
4. When the response is received for such commands , the regular chain of flow will not happen , we can have a mediator object in client impl which will define which flow the response should take , either directly to command filter in case of pubsub commands or regular chain for other commands

we are preparing a detailed document , before that just wanted to understand
1. is community willing to take such changes
2. is anyone already working on such changes
3. what documents are expected from us to take this as a proposal and then implementation

Below are the list of commands for which we have added support in envoy in our local repo

sunion | sdiff | sinter | sinterstore | zunionstore | zinterstore | pfmerge | georadius | georadiusbymember | xrevrange
subscribe | psubscribe | unsubscribe | punsubscribe | publish | pubsub | brpoplpush | bzpopmax | bzpopmin | blpop
brpop | script | flushall | keys | slowlog | config (set & get) | client (getname setname) | info | cluster (slots keyslot) | select
scan | hello* | XCLAIM | rename | xadd | xread | xdel | xtrim | xlen | xrange
getdel | GETEX | SORT | ZMSCORE | SDIFFSTORE | MSETNX | SUBSTR | ZRANGESTORE | ZUNION | ZDIFF
XAUTOCLAIM | XGROUP | XINFO | SUNIONSTORE | SMISMEMBER | HRANDFIELD | GEOSEARCHSTORE | XREADGROUP | ZDIFFSTORE | GEOSEARCH
RANDOMKEY | ZINTER | BLMOVE | ZRANDMEMBER | BITOP | LPOS | RENAMENX |  


[optional *Relevant Links*:]

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.