求一款符合需求的 Redis 开源中间件

89 天前
 seedhk

需求:

增:支持将数据写入到 Redis ,隔一段时间自动将数据同步到 MySQL/sqlserver ,同步完成后,Redis 中已同步的数据会自动清除;

删:支持根据指定业务字段(或者 KEY )将数据从 Redis 删除,删除后的数据不会同步到 Redis ;

改:删+增的逻辑;

查:支持 Redis 数据查询,最好能像查询数据库一样,使用类似 SQL 语言查询 Redis ,如果未查到会主动去数据库查询并写入 Redis 等,有 Java 版本的客户端;

请问没有这样的中间件,全部符合或者符合若干个条件都可以推荐下,

谢谢大佬们!

2565 次点击
所在节点    程序员
16 条回复
shangfabao
89 天前
应该是没有,自己手撸一个吧
THESDZ
89 天前
pisay
89 天前
使用 nifi 拉流程实现吧
mindddd
89 天前
感觉自己可以根据需求撸一个
spritecn
89 天前
@mindddd 实话,感觉撸一个就俩工作日的事
BuggerL
89 天前
@spritecn 认真的吗,sql 查 redis 就不是一两天能做完的。。可以说是做不了了
sampeng
89 天前
@BuggerL 你的查就想多了,实际情况没人这么用,是属于自己给自己找不痛快。正常业务我算你 100 个接口,1000 条不同类型的 sql.。这是一个比较有规模和复杂度的项目了吧。你需要 1000 个 sql 都过 redis 做一层缓存?顶天十分之一最重要的访问量最大的。100 个了不起了。然后就为这点鸡毛蒜皮的事整个 sql 解析出来?不过也不是没有,找 sql 查 redis 的开源项目挺多的…没啥意义
zt5b79527
89 天前
奇奇怪怪,倒不如把你的原始需求贴出来,让大佬们给你改改方案
ala2008
89 天前
没有,你这个太不通用,偏向业务。自己搞吧
securityCoding
89 天前
没有,这是纯业务跟中间件没啥关系
BuggerL
89 天前
@sampeng 回错人了吧。。redis 实现 sql 解析本来就是异想天开。。。
zzmark06
89 天前
你的第二句话,好像不太通畅。

以前我们有做过利用 redis 批量写 db 。
拿 redis 当 buffer 用。
逻辑基本是手搓的。redis 只管 SET ,定时会用 SCAN 扫,都是时序数据没有 update 。

不要问为啥不用 kafka ,甲方有安规,kafka 被卡供应了过不去。
sampeng
88 天前
@BuggerL 为啥是异想天开。。。https://zeesql.com/随便搜了一个。我的意思是没有任何价值。所以开源社区几乎没有几个实现。像 redis 这类只要你搞开发就要上的中间件,如果价值大,开源实现一抓一大把。无非就是语法解析罢了。缓存要设计逻辑的。。绝对不是抽象的和数据库一样。。。。鬼知道是不是 redis 里值错的或者瞬时变化或是逻辑 bug ,还有缓存穿透,冷热数据启动,全局锁,分布式异步状态的切换等等。。这些问题都碰到过,都得单拿出来设计数据结构和读/存的逻辑。。可能 1000 个接口你全用这种方式缓存了。。所有数据都是要走一个中间件。想想查 bug 的恐怖程度就难受
BuggerL
88 天前
@sampeng 这东西搜了搜,压根没人在生产环境用。他绝对不能完整兼容 sql 语法,应该就是简单的 sql 可以支持。所以这东西应该就是个玩具。没必要争了,反正用 redis 跑 sql 不现实
seedhk
88 天前
@THESDZ 看了下不满足,谢谢老哥
@zzmark06 请问您当时是怎么实现的,可以说下具体的方案吗?
zzmark06
47 天前
不太长看 v2 ,许久后回复。

redis 和 db 异构,必然得面临数据不一致的问题。
redis 是 KV 型存储,没有足够的描述结构。

我们当时的方案,是有个针对的,就是只用 redis 存储 IOT 报文,业务上没有 update/delete ,纯 insert ,所以只是针对 key 设计就够了。

没有用 kafka 主要还有个问题,业务侧有明细数据查询的时效性需求,给的指标是端到端不超过 2s(从 iot 网关开始计算,实际上是不合理需求,但甲方爸爸……)。kafka 其实是守不住 2s 的,所以用了大把的 redis 写。
数据 set ,数据对应的一级索引 hset 。
设计两个 key 就行,然后有 batch 任务每隔多久来扫走并删除相应数据( redis 最多存 2 个时间窗口,batch 扫走第二个,删掉第一个)

至于你们领导的想法,那是扯淡,完全置数据复杂度于不顾。数据库不可用,两个思想方向:
1. 保证数据库高可用,既然 sql server ,那成熟的 always on 体系砸就是了。
2. 若是真的没法保证(成本因素 or 技术难题),数据库不可用就该让他不可用,保证 RPO=0(数据恢复点,就是不能丢数据不能错数据),然后才是尽量缩短 RTO(业务恢复时间)
不然,照着主库能挂然后靠 redis 来缓解,那么面临的必然是时间段内的数据不一致,

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/1097758

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX