Tìm kiếm
23 kết quả cho “proxy routing”. Tìm không phân biệt dấu.
- Introducing uForwarder: The Consumer Proxy for Kafka Async Queuing Bài tóm tắt · Uber · 2026
…ều PB mỗi ngày. Khoảng ba năm trước bài, Uber dựng Consumer Proxy : một cụm proxy lấy message từ Kafka bằng giao thức nhị phân, đẩy từng message tới consumer service qua gRPC, nhận…
- Building a data plane from scratch: Stripe's own high-performance distributed proxy Bài tóm tắt · Stripe · 2026
…plane-from-scratch-stripes-own-high-performance-distributed-proxy) Bối cảnh - Mục tiêu độ tin cậy 99,9995% cho request thanh toán; service mesh nội bộ xử lý hàng triệu request/giây…
- Unlocking Horizontal Scalability in Our Web Serving Tier Bài tóm tắt · Airbnb · 2016
…ead pool chỉ có ở MySQL enterprise, không có trên RDS → cần proxy ngoài. Chọn MariaDB MaxScale nhưng nó giữ một kết nối backend cho mỗi kết nối client, nên fork để thêm connection…
- Migrating Millions of Concurrent Websockets to Envoy Bài tóm tắt · Slack · 2021
…vào hệ "wss" (tin nhắn, presence, app). Từ đầu Slack dùng HAProxy ở nhiều region AWS để kết thúc websocket gần user. - Vấn đề reload: danh sách backend đổi thường xuyên. Cách Runti…
- How Twitter Uses Redis to Scale - 105TB RAM, 39MM QPS, 10,000+ Instances Bài tóm tắt · Twitter · 2014
…khoá phụ (lấy từ BSD); tốn bộ nhớ metadata. - Cluster bằng proxy : không để server tự đồng thuận (giữ server "đơn giản, ngốc, nhanh"), không làm ở client (gần 100 project, đẩy tha…
- Alerting on Service-Level Objectives (SLOs) Bài tóm tắt · SoundCloud · 2019
…LO nội bộ hay không. Chỗ đáng làm nhất là tầng terminator HAProxy ở biên: tỉ lệ 5xx theo từng backend. - Multiwindow, multi-burn-rate: recording rule tính tỉ lệ lỗi theo 5m, 30m, 1…
- Troubleshooting: A journey into the unknown Bài tóm tắt · Booking.com · 2017
…không tăng TCP/ICMP/HTTP, UDP bị chặn), loại trừ cấu hình haproxy và phiên bản. - Dấu vết: cùng lúc có CPU 100% ở mức system trên cả 10 process haproxy, và hệ điều hành bỗng giải p…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Scaling Cache Infrastructure at Pinterest Bài tóm tắt · Pinterest · 2020
…g thư viện client (dễ vỡ, gắn với việc deploy binary) → một proxy tự xây (thiếu khối dựng sẵn cho high availability) → mcrouter . Thay đổi chính - Memcached + mcrouter: - memcached…
- The growing pains of database architecture Bài tóm tắt · Figma · 2023
…bảng (AAS) để biết tách gì có tác động nhất. - Chèn một lớp proxy rồi tách nó trước dữ liệu , nhờ vậy lỗi routing lộ ra khi vẫn còn an toàn. - Thiết kế rollback từ đầu (replication…
- Partitioning GitHub's relational databases to handle scale Bài tóm tắt · GitHub · 2021
…ăng (ví dụ statuses) sang DB riêng; thêm read replica; dùng ProxySQL giảm số kết nối tới primary. - Nhưng lõi vẫn là một cluster mysql1 chứa user, repo, issue, PR. Họ liên tục phải…
- Building Pubsub for 50M concurrent socket connections Bài tóm tắt · Disney Hotstar · 2019
…triệu kết nối, nên dùng nhiều ELB. Đã thử NLB (gặp bug), HAProxy/Nginx, cân tải phía client; theo bài, cân tải kết nối TCP bền không đơn giản. - Vượt 2 triệu: - Nhiều cụm nối bằng…
- Scaling Datastores at Slack with Vitess Bài tóm tắt · Slack · 2020
…h năng xuyên khách hàng. - Đặt sharding vào một tầng riêng (proxy), không để trong app. Như vậy mọi service mới đều được hưởng. - Đổi càng ít càng tốt: giữ MySQL, đổi tầng phía trê…