@midsolo #37 对的, 根据题目大概能猜测到贵司团队创始时间在 2015 年前后 有机会用 go 重构的话, 现在有蛮多先进中间件和框架可以选用 兵来将挡水来土掩, 只要架构设计合理, 性能问题和可靠性问题都能迎刃而解 另外最近几年半导体发展迅猛, 我们十年前担心的很多性能问题(尤其是算力和吞吐),现在已经不再是问题 有时候我们都感慨现在中间件/HATP 数据库的性能和起飞一样,在 15 年我们绝对不敢想会达到这个夸张的程度....

@midsolo #38 我们内部经常讨论的经验法则: 万事万物都要幂等, 什么业务场景都要考虑重放带来的影响和风险. 问题核心在业务重放和抖动后不幂等, 优先从业务逻辑上解决这个问题, 如果实在无法解决, 再从技术手段上来降低风险. 不清楚贵司实际业务场景是什么, 但我们的想法是: 异地多可用区监察(尤其要单数节点,并且最好大于不等于 3) + 可靠重放机制 数据库如果能上云并能接受阿里系的话, PolarDB 或者 OceanBase 跨地域部署都还可以(把复杂基础设施可靠性问题抛给公有云解决,换句话将来得有个人接锅) AWS 就是 Aurora Global Database, 实际验证过跨区域容灾能力和 RPO/RTO 都还不错

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

非要 redis 来做 cp 的场景吗，最近也在看八股文，感觉都是在为难我 https://i.imgur.com/Iy0taMy.png

这是面试架构师吧

这个岗位多少薪资啊

我作为部门的技术总监 我羞愧 。也就懂寥寥几题

我很惭愧 :)