-
OpenTelemetry 分布式追踪工程化完全指南:从一次"P99 8 秒但 Zipkin 只显示 800ms"看懂为什么加 Sleuth 远远不够
2023 年我们公司有一套微服务系统跑在 Kubernetes 上大概 80 个 service 分布在 6 个 namespace 一开始我们用 spring-cloud 的 Sleuth 接 Zipkin 做调用链追踪看起来该有的都有 trace_id span_id 服务调用关系图谱也能画出来看上去很完整但真正发生故障的时候我们才发现一系列问题第一种最让我傻眼某天业务报告下单接口慢 P99 …- 0
- 0
-
PostgreSQL 索引与执行计划工程化完全指南:从一次"5 亿行订单表查询走全表扫 8 秒不出"看懂为什么加 B-tree 远远不够
2022 年我们公司有一套核心的订单库跑在 PostgreSQL 上数据量大概 5 亿行单库 30 多张表上线两年一直挺稳定直到某天产品突然要做一个卖家后台的查询页面要支持按订单状态时间范围金额范围客户名称等多个条件组合查询我心想 PostgreSQL 嘛加几个索引就完事顺手在 status time amount 上各加了个 B-tree 索引部署上线第二天卖家中心的接口接连超时业务那边把电话打…- 0
- 0
-
Kafka 消费者组与 rebalance 工程实战:从一次"凌晨 3 点整组消费停顿 20 分钟"看懂为什么慢消息能拖垮你的消费链路
2023 年我接手了一套基于 Kafka 的订单事件处理链路上游一天大概几亿条事件下游有十几个消费者组各自处理不同业务接手的第一个月一切都很顺没出什么大事让我心里很笃定 Kafka 这东西嘛只要 topic 分区数够多消费者数量配得上就完事了直到有一天凌晨 3 点告警群里炸了订单状态回写延迟从平时的 200 毫秒涨到了 40 秒我爬起来排查发现下游某个消费者组在不停 rebalance 平均每 3…- 0
- 0
后端工程
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×