Tìm kiếm
40 kết quả cho “Queue shard”. Tìm không phân biệt dấu.
- October 2024 queue retrospective Bài tóm tắt · Inngest · 2024
…Trung bình — [bài gốc](https://www.inngest.com/blog/2024-10-queue-retros) Một bài gom bảy sự cố trong một tháng nâng cấp hệ queue. Không sự cố nào mất dữ liệu (theo Inngest). Hai n…
- 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.
- Attack of the Shards: Our Migration to FoundationDB, Part 2 Bài tóm tắt · Inngest · 2026
…quả. Bối cảnh - Inngest (nền tảng durable execution) chuyển queue từ Valkey (bản fork của Redis, chạy trong RAM, thao tác queue đơn luồng) sang FoundationDB (KV có transaction, dữ…
- 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ả…
- Timestone: Netflix's High-Throughput, Low-Latency Priority Queueing System Bài tóm tắt · Netflix · 2022
…com/timestone-netflixs-high-throughput-low-latency-priority-queueing-system-with-built-in-support-1abf249ba95f) Bối cảnh - Năm 2018, khi thiết kế Cosmos thay hệ encode media Reload…
- Ratequeue: Core Queueing-And-Rate-Limiting System (chaos engineering cho failover) Bài tóm tắt · Twilio · 2017
…](https://www.twilio.com/blog/2017/11/chaos-engineering-ratequeue-ha.html) Bối cảnh - Tin nhắn gửi đi của Twilio có thể bị giới hạn tốc độ (quy định nhà mạng, hợp đồng, năng lực),…
- Dynein: Building a Distributed Delayed Job Queueing System Bài tóm tắt · Airbnb · 2019
…irbnb-engineering/dynein-building-a-distributed-delayed-job-queueing-system-93ab10f05f99) Bối cảnh - Job nền ở Airbnb gồm cả job hẹn giờ xa (nhắc check-in trước nhiều tháng, thậm c…
- Geosharded Recommendations Part 3: Consistency Bài tóm tắt · Tinder · 2019
…rtition mình đọc, tránh tranh chấp. - Theo Tinder, nhiều hệ queue khác chỉ có thứ tự "best-effort", hoặc FIFO nhưng throughput rất thấp. - Đọc nhất quán mạnh từ Elasticsearch: - El…
- Building observability into Notion's dead-letter queue Bài tóm tắt · Notion · 2026
…on.com/blog/building-observability-into-notions-dead-letter-queue) Bối cảnh - Gần như mọi thao tác ở Notion có một task nền chạy qua job queue: thông báo khi bị @-mention, index tr…
- Maximum Warp: Building Migrations for Slack Enterprise Grid Bài tóm tắt · Slack · 2017
…erience tự chỉnh tốc độ mà không cần kỹ sư. - Chạy trên job queue () với queue và pool worker riêng để không ảnh hưởng job khác. Thêm job queue inspector : gắn tag cho task của từn…
- How We Halved Go Monorepo CI Build Time Bài tóm tắt · Uber · 2022
…i: review trên Phabricator, CI chạy build + test, rồi SubmitQueue áp thay đổi lên HEAD mới nhất và chạy lại trước khi push. - Changed Targets Calculation (CTC): dựng cây kiểu Merkl…
- Our Migration to FoundationDB, Part 1 Bài tóm tắt · Inngest · 2026
…benchmark) chưa đăng khi wiki đọc (URL trả 404). Bối cảnh - Queue của Inngest quyết định job nào chạy tiếp, cho account nào, trên executor nào; mọi lần chạy function đều đi qua nó,…
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
…thêm thì gọi API tra ngược); consumer phải idempotent; mỗi queue tối đa 10.000 message tồn. - Bản thiết kế viết lại bằng Java bị architecture review bác (9/2015). Câu hỏi của đại…
- How we stopped xmin horizon blocking Postgres vacuuming Bài tóm tắt · Trigger.dev · 2024
…(nền tảng chạy background job) dùng Postgres làm DB chính. Queue chính cho run (v3) nằm trên Redis; còn tác vụ nội bộ (lịch, email cảnh báo...) chạy bằng Graphile Worker , một job…
- Scaling Email Infrastructure for Medium Digest Bài tóm tắt · Medium · 2020
Digest là email cá nhân hoá hằng ngày, phải tới 8–9 giờ sáng theo giờ địa phương. Gửi hàng triệu email/ngày; là một trong những tải nặng nhất.
- 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:
- Inside Minerva: building scalable observability for eBay's monetization platform Bài tóm tắt · eBay · 2026
Hệ tính phí (monetization) của eBay phụ thuộc khoảng 200 thuộc tính của item, seller, marketplace, campaign; eBay báo Q2/2026 có 136 triệu buyer, 2,6 tỉ listing. Một tổng toàn cục có thể trông bình thường trong khi một…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- How to Pitch Apache Kafka Bài tóm tắt · Zillow · 2020
Zillow chạy trên AWS và dùng SQS, SNS, Kinesis. Theo tác giả, lý lẽ "Kafka throughput tốt hơn" không thuyết phục được lãnh đạo; ở công ty trước, chính ông từ chối Kafka vì không thấy ROI của việc thêm người vận hành.
- Common Performance Pitfalls of Modern Storage I/O Bài tóm tắt · ScyllaDB · 2026
Hai phần trước của series tìm ra hai nguyên nhân làm instance lớn "không scale": hàng đợi công bằng trong IO Scheduler của Seastar tự bóp băng thông còn một phần nhỏ so với thông số, và block size/căn chỉnh của XFS gây…
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- 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.
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- 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…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- 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…
- 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.
- Inngest Công ty Thành viên
Năm 2026 Inngest chuyển queue từ Valkey (trong RAM, đơn luồng) sang FoundationDB: làm phẳng mô hình từ ba cấp xuống hai, shard logic khoảng 20.000 account, dời account giữa shard, công bằng giữa tenant bằng scan có…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- 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.
- Notion Công ty Thành viên
Một Postgres monolith chạy 5 năm tới khi vacuum kẹt và TXID wraparound đe doạ; năm 2021 Notion shard ở tầng ứng dụng theo workspace ID thành 480 shard logic trên 32 DB, migrate bằng audit log, chuyển trong 5 phút bảo…
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- Tinder Công ty Thành viên
Nhiều năm Tinder dùng một index Elasticsearch cho gợi ý; năm 2019 chia thành 40–100 geoshard cân theo load score trên S2 . Shard được hiện thực là nhiều index trong một cluster, chốt cỡ bằng performance test, và rải…