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 卡死，要么是什么软件加了钩子，要么是硬件初始化比如机械盘起转

1. 设备兼容性。你不能要求用户不使用老设备，也不能要求老业务组去升级基础设施（真的会死）
2. 证书轮换，项目各种奇葩部署方式导致证书根本收不上来，难不成每 2 个月就要到七八个项目组二三十个证书轮换点挨个去轮换？
3. OCSP ，Lets encrypt 的 OCSP 经常被墙，导致 ios 用户首次请求直接寄（超时 10s ）。
4. 业务多了，Lets encrypt 的免费单域名不够用，通配解析又存在分发问题（参照第二点）。
5. 安规，你以为买 OV 和 EV 只是个证书？其实买的是审查和设计。

问出这个问题，难道没赶上 Lets Encrypt 更换根证书的时候吗，证书只是运维的一个小部分，没有人天天能盯着这么多东西的。
至于说做好监控，或者自动 acme.sh ，现实情况远比梦里的复杂，你觉得是雇个人天天盯着成本低，还是直接花几千块钱买个证省下一年十几个 (人/日) 成本低。

想的话，必然是 golang ，python ，scala 。
但实际写起来，还是 java 和 nodejs 最熟悉，最终还是会选传统派

啥顺手选啥，选熟悉的，不选(政治)正确的