增:支持将数据写入到 Redis ,隔一段时间自动将数据同步到 MySQL/sqlserver ,同步完成后,Redis 中已同步的数据会自动清除;
删:支持根据指定业务字段(或者 KEY )将数据从 Redis 删除,删除后的数据不会同步到 Redis ;
改:删+增的逻辑;
查:支持 Redis 数据查询,最好能像查询数据库一样,使用类似 SQL 语言查询 Redis ,如果未查到会主动去数据库查询并写入 Redis 等,有 Java 版本的客户端;
请问没有这样的中间件,全部符合或者符合若干个条件都可以推荐下,
谢谢大佬们!
看了大佬们的回复,觉得这个想法确实太奇怪了,在此贴一下我的原始需求和产生这个需求的问题
数据库版本: 阿里云RDS SQLSERVER 产生这个问题的需求是因为老项目的长SQL实在是过于多了,几百行的SQL一找一个准,去优化SQL工作量非常大。
导致生产环境数据库很不稳定,经常因为SQL引起数据库不可用导致被客户投诉罚钱,但是阿里云高可用对于小企业来说实在是太贵了。迁移下云又需要一个比较专业的DBA来运维数据库,小企业老板估计也不会同意。
于是便有了以下这几个步骤:
使用了DTS,同步主库的数据到从库,基本上实现了读写分离;
拆分了核心业务,但是核心业务仍然有访问数据库的需求,因此万一数据库不可用时,如何保证核心业务的正常运行,成为了一个大问题;
领导于是提了一个点:
![]() |
1
shangfabao 64 天前
应该是没有,自己手撸一个吧
|
2
THESDZ 64 天前
|
![]() |
3
pisay 64 天前
使用 nifi 拉流程实现吧
|
4
mindddd 64 天前
感觉自己可以根据需求撸一个
|
7
sampeng 64 天前 via iPhone
@BuggerL 你的查就想多了,实际情况没人这么用,是属于自己给自己找不痛快。正常业务我算你 100 个接口,1000 条不同类型的 sql.。这是一个比较有规模和复杂度的项目了吧。你需要 1000 个 sql 都过 redis 做一层缓存?顶天十分之一最重要的访问量最大的。100 个了不起了。然后就为这点鸡毛蒜皮的事整个 sql 解析出来?不过也不是没有,找 sql 查 redis 的开源项目挺多的…没啥意义
|
![]() |
8
zt5b79527 64 天前
奇奇怪怪,倒不如把你的原始需求贴出来,让大佬们给你改改方案
|
9
ala2008 64 天前
没有,你这个太不通用,偏向业务。自己搞吧
|
10
securityCoding 64 天前
没有,这是纯业务跟中间件没啥关系
|
12
zzmark06 64 天前
你的第二句话,好像不太通畅。
以前我们有做过利用 redis 批量写 db 。 拿 redis 当 buffer 用。 逻辑基本是手搓的。redis 只管 SET ,定时会用 SCAN 扫,都是时序数据没有 update 。 不要问为啥不用 kafka ,甲方有安规,kafka 被卡供应了过不去。 |
13
sampeng 64 天前
@BuggerL 为啥是异想天开。。。https://zeesql.com/随便搜了一个。我的意思是没有任何价值。所以开源社区几乎没有几个实现。像 redis 这类只要你搞开发就要上的中间件,如果价值大,开源实现一抓一大把。无非就是语法解析罢了。缓存要设计逻辑的。。绝对不是抽象的和数据库一样。。。。鬼知道是不是 redis 里值错的或者瞬时变化或是逻辑 bug ,还有缓存穿透,冷热数据启动,全局锁,分布式异步状态的切换等等。。这些问题都碰到过,都得单拿出来设计数据结构和读/存的逻辑。。可能 1000 个接口你全用这种方式缓存了。。所有数据都是要走一个中间件。想想查 bug 的恐怖程度就难受
|
14
BuggerL 64 天前
@sampeng 这东西搜了搜,压根没人在生产环境用。他绝对不能完整兼容 sql 语法,应该就是简单的 sql 可以支持。所以这东西应该就是个玩具。没必要争了,反正用 redis 跑 sql 不现实
|
16
zzmark06 22 天前
不太长看 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 来缓解,那么面临的必然是时间段内的数据不一致, |