Tình huống: retry storm làm sập cả chuỗi Trung cấp

Một service chậm hiếm khi tự làm sập cả hệ thống. Thứ làm sập là retry ở mọi tầng cộng timeout dài: tải nhân lên đúng lúc dependency yếu nhất, và pool cạn dần từ dưới lên.

• Bốn bước: đọc dashboard, cầm máu, sửa policy, kiểm chứng.
• Để ý tỷ số request/s giữa các hop, không chỉ từng service riêng lẻ.
• Điểm chỉ tính lựa chọn đầu tiên ở mỗi bước.

Tình huống

Retry storm: pricing chậm 3 giây, cả chuỗi checkout sập

Bạn là on-call backend. Chuỗi gọi: gateway → order → inventory → pricing. Các chỉ số bên dưới đổi theo từng quyết định.

Tải vào pricing / tải vào gateway7 ×

5xx ở gateway38 %

p99 checkout ở gateway28.000 ms

Thread / connection pool của order100 %

Bước 1/4 · Dashboard đỏ từ ngoài vào trong

20:05, pricing deploy bản mới làm mất một index; p99 của pricing từ 200 ms lên 3 s. 20:12, gateway báo 38% lỗi 5xx. Cả ba service phía trên đều có cùng một config gọi downstream: 3 attempts, không backoff, timeout 10 s.

Bạn mở dashboard. Kết luận đầu tiên là gì?

order pool

200/200 bận

inventory pool

200/200 bận

pricing CPU

98%

traffic người dùng

không đổi

# request/s nhận vào, 20:12
gateway     2,000   (bình thường 2,000)
order       5,400
inventory   9,800
pricing    14,000   (capacity khi chậm ~1,200)

# trace một request lỗi
gateway → order ×3 → inventory ×3/lần → pricing ×3/lần  = 19 span pricing

Bạn làm gì?

Aorder-service hỏng: pool 100%, không nhận request mới. Restart toàn bộ pod orderBBị tấn công hoặc traffic tăng đột biến: bật rate limit chặt ở gatewayCRetry storm: request/s tăng dần qua từng hop dù traffic ngoài không đổi. Pricing chậm là mồi lửa, retry ở 3 tầng là thứ thổi nó thành sập cả chuỗiDPricing p99 3 s là nguyên nhân. Page team pricing, chờ họ rollback

Bảng khuếch đại theo số tầng và công thức jitter có trong Retry, backoff và jitter.