-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
设计实现 Redis API #608
Comments
Wait ! |
@gdutChenxj Hi 不好意思,我去问了下这个任务被占用了(作为今年开源之夏的参赛课题) |
@seeflood 现在还有什么任务可以领取?很多都处于领完的状态 |
好问题,我整理下 |
@gdutChenxj hi, 我更新了一下 |
@seeflood 领取【设计实现 Redis API】任务 |
这个是 #530 的子任务 @gdutChenxj hi, 因为这个功能比较重要,需要先做设计(写个设计 proposal),大家讨论后达成一致了再开始编码~ 如果方便的话可以来参加我们每周社区会议,这样沟通效率更高些 |
@gdutChenxj 棒! 每次的议题记录在 https://github.com/mosn/layotto/discussions |
FYI |
Hi,我之前在capa项目中调研过一些Redis的API,可以作为参考 如 #530 ,在capa中我使用java接口进行api定义,主要参考了 http://redisdoc.com/index.html 文档和jedis的java api。 在做的过程中我发现完全的Redis原生命令可能有120+个,其中有的比较复杂,并且可能应用场景较少。 如 #530 中提到的,我遇到的常见的数据结构主要有:
按照"starting simple"的思路,或许可以从这些数据结构的api开始设计。 最后,附上capa中的java redis api地址:https://github.com/capa-cloud/cloud-runtimes-jvm/tree/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/nativeproto/redis Best Wishes. |
@kevinten10 3Q,有留意到 #530 这个帖子,感觉很有帮助 |
@wenxuwan 说的是生产用户已经在用的方案,只需要设计一个 redis command 接口。 rpc RedisCommand(RedisRequest) returns (RedisResponse) {}
message RedisRequest {
string store_name = 1;
string cmd = 2;
repeated bytes args = 3;
map<string,string> metadata = 4;
}
message RedisResponse {
repeated bytes values = 1;
} 思路类似于 dapr binding API (不过 dapr 的 redis binding 目前啥功能都不支持 pros:
|
@seeflood 个人理解,感觉直接暴露 redis 协议接口 low level api 对初级用户使用过程不太友好,可能会产生一些不太好的使用实践,另外哦如果设施底层可能是集群代理或者类redis协议的缓存组件,low level api无法限制用户使用不支持的命令 |
@gdutChenxj 你说的确实是个问题,上面的方案有缺点:
方案b: cmd 改成用枚举值呢 rpc RedisCommand(RedisRequest) returns (RedisResponse) {}
message RedisRequest {
string store_name = 1;
command cmd = 2;
repeated bytes args = 3;
enum command{
set = 0;
get = 1;
// ...
}
}
message RedisResponse {
repeated bytes values = 1;
} 解释:
pros:
cons:
|
Hi, 1. 用户应该不希望面向 多行文本 编程,而是面向语义清晰的api进行编程。这样,还是需要定义很多in-process的api吧(比如我上面提到的capa的那一堆接口定义),最终需要映射到 一百多个grpc接口 或者 RedisCommand 上的。
工作量感觉差不多 2. 考虑和Redis Mesh的混合形式呢比如一种 RedisMesh ,未来可能有这种架构:layotto和x-mesh混用的架构,用户希望redis的功能在redis mesh/layotto之间做选择,或许:
这样的话,我感觉 RedisCommand 会好一点,因为layotto只需要把接收到的grpc参数,转成redis命令发出去就可以了。 |
@kevinten10 使用 RedisCommand 的实际开发量会少一些,对开发者比较友好,但是考虑到命令的参数在接口上的限制会变弱,使用体验上会稍微差些,我考虑的话虽然定义独立的 grpc 接口编写的代码会稍多,但总归是有限的一次性工作,长期来看更加合理,个人更倾向于 grpc 接口 |
@kevinten10 另外我在想,是不是能写个简单一个脚本,通过您之前在 capa 定义的 java 接口,初始化一波 grpc 接口定义,应该能减少一些工作量 |
看起来是的,一次性的工作
哈哈,也可以试试idea的列编辑模式 |
@kevinten10 恩恩 后续的演进方向是准备“既支持原生 redis协议,又支持 redis gRPC API”的,见#530 |
所以现在的争议焦点是: 问题1. RedisCommand 没啥类型信息,会不会用户体验太差
Q: 会不会因为 api没啥类型信息,导致用户不知道怎么用这个api? 这个问题,个人觉得还好,因为用户是对照着 redis 命令行工具的文档、社区资料来使用的,举个例子:
文档上有写这条命令,那么调 gRPC API 就一一对应(伪代码):
再比如 redis-cli 的文档上有写:
那对应的gRPC API传参就是(伪代码):
我们只需要告诉用户“嘿,这个 API 传参和 redis-cli 一模一样,举两个例子blabla,剩下的你们自己去看 redis-cli 文档吧”,不用维护注释、大量文档,“白嫖” redis 社区所有现成的资料 问题2. 既然总归要在sdk 层面定义100 个 interface、总归有那么多工作量,不如定100个 gRPC API,反正没有让工作量增加?我觉得分两个阶段: 阶段1. 我们可以先不管 sdk interface(比如 java interface),专注于做 gRPC API,用户可以直接用 gRPC;如果用户更喜欢用 jedis sdk 或者 capa sdk,可以修改sdk的内部实现、改成调用 layotto gRPC API ,但是对用户暴露的java interface不变(比如还是 capa interface) 阶段2. 有编译工具,把 proto 编译成 java interface。这正好是 sig-api 准备做的事情 100个 gRPC API 的后续维护成本这个是我最担心的:定 100个 gRPC API 可能不是一次性工作,可能给后续带来很高的维护成本。 因为要:
这个是比较可怕的,因为现在 Layotto 追求兼容 dapr API,而 dapr API 更新时(比如新增 workflow API, 比如 state API 新增查询接口),我们及时跟进、更新都觉得比较花时间,如果再来一百个,维护成本会更高…… |
@wenxuwan 给点意见? |
像 redis API、aws S3 API 这类 "可信协议的 gRPC API"的设计目标、取舍逻辑是:
|
action:
|
@gdutChenxj Hi, 你还在搞这个issue么? |
Hi, 有没有 |
@seeflood 最近没时间搞了,麻烦转给其他人吧 |
@kevinten10 我们没专门压过state API,@wenxuwan 压过 grpc 的 invokeService 和 sayHello 接口。当时1000qps下,引入layotto后,(相比于用mosn)rpc耗时增加0.24ms 当然具体精确数字最好专门压测一下 |
@gdutChenxj ok 欢迎有空了再来参与社区 |
What would you like to be added:
设计实现 Redis API
The text was updated successfully, but these errors were encountered: