BraveRBT

@BraveRBT #40 勘误: HTAP 数据库(Hybrid Transaction / Analytical Processing), 打错了

@midsolo #38 我们内部经常讨论的经验法则: 万事万物都要幂等, 什么业务场景都要考虑重放带来的影响和风险.
问题核心在业务重放和抖动后不幂等, 优先从业务逻辑上解决这个问题, 如果实在无法解决, 再从技术手段上来降低风险.

不清楚贵司实际业务场景是什么, 但我们的想法是: 异地多可用区监察(尤其要单数节点,并且最好大于不等于 3) + 可靠重放机制
数据库如果能上云并能接受阿里系的话, PolarDB 或者 OceanBase 跨地域部署都还可以(把复杂基础设施可靠性问题抛给公有云解决,换句话将来得有个人接锅)
AWS 就是 Aurora Global Database, 实际验证过跨区域容灾能力和 RPO/RTO 都还不错

@midsolo #37 对的, 根据题目大概能猜测到贵司团队创始时间在 2015 年前后
有机会用 go 重构的话, 现在有蛮多先进中间件和框架可以选用
兵来将挡水来土掩, 只要架构设计合理, 性能问题和可靠性问题都能迎刃而解

另外最近几年半导体发展迅猛, 我们十年前担心的很多性能问题(尤其是算力和吞吐),现在已经不再是问题
有时候我们都感慨现在中间件/HATP 数据库的性能和起飞一样,在 15 年我们绝对不敢想会达到这个夸张的程度....

另外题目中,已经反复提到了网络抖动相关的问题, 这就更说明公司在这方面吃过亏
如果从架构上可以避免,就不应该使用有缺陷的架构去解决问题, 这也是面试八股文的典型特征
而且题目中也提到了 Drools, 这东西本身就很老.....
主流做法早就用 Flink/Spark Streaming 做流式处理实时计算

就和有些公司会问 clickhouse 现在是否是数仓第一选择一样, 反映的都是公司技术栈老旧的问题
答案都是否定的

针对题目 2

对于这么高的强一致性要求,而且还是双活(上下文题目中已经提到了同城双活架构)
Redis redlock 方案真的有待商榷.
换句话说 redis 加锁真的能满足强一致性要求吗(同城网络抖动导致脑裂, 内部 NTP 时钟漂移), 从一开始就是陷阱提问方式
很符合面试八股文的基本定义, 即从公司里的历史故障出发, 而不是从技术本质出发

正常做法都是数据库事务做悲观锁,或者 etcd(Raft)做强一致性处理,而不是缓存做分布式锁
而且同城双活的可靠性, 实际上也有待商榷, 不引入外部跨地域可用区进行 OB 仲裁很难避免脑裂问题
通常做法都是"两地三中心"或异地多活, 仅靠同城双活基本都是吹的比较好听,实际业务炸了就紧张的修理中了


感觉整套题目能回答上的人, 基本都感觉公司的实际技术栈是老旧和有问题的....
我第一想法是这公司的业务系统设计水平不高, 可能还停留在 10 年前的水平, 如果配上薪酬水平估计投都不投了

加入一个小型 node 用于网络转发,关闭调度,开启内核 ip_forward 参数
在交换机路由表配置 SVC 网段的请求转发到该节点作为网关即可

外部看起来类似于直通,无需其他任何配置和程序转发

可以在 k8s 里装个 APISIX,作为 ingress-controller.
这样做策略路由和标签路由就都没问题了,流量也不需要到 SVC 可以直接到 POD.

@nancheng911 #4 记得 export 导出的 tar 需要用 import 导入.

docker save 会保存所有差异叠加层,用 docker export 导出再导入即可合并这些叠加层.
空间就会得到释放了(会丢失所有的 layer 信息).

save 和 export 的差别如下:
export: Stream the contents of a container as a tar archive.
save: Save an image to a tar archive.