zzmark06

不太长看 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 来缓解，那么面临的必然是时间段内的数据不一致，

返回 10w ，零散对象就是多。
在任何有必要优化的专门点位，使用原生 JDBC API 来针对性优化，是完全正确且合乎情理的。
所以，遇到此类问题别和框架死磕，直接动用更底层的原始 API 就好。

请参考存储的 321 原则

你的第二句话，好像不太通畅。

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

不要问为啥不用 kafka ，甲方有安规，kafka 被卡供应了过不去。

Explorer 卡死，要么是什么软件加了钩子，要么是硬件初始化比如机械盘起转