Tìm kiếm
40 kết quả cho “job queue riêng”. Tìm không phân biệt dấu.
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
…g bình — [bài gốc](https://slack.engineering/scaling-slacks-job-queue/) Bối cảnh - Job queue chạy mọi việc không làm kịp trong request web: mỗi tin nhắn, push notification, unfurl…
- Dynein: Building a Distributed Delayed Job Queueing System Bài tóm tắt · Airbnb · 2019
…om/airbnb-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…
- 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ả…
- Building observability into Notion's dead-letter queue Bài tóm tắt · Notion · 2026
…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 trang cho search, sinh embedding, đồng bộ lịch, export workspace. Queue phâ…
- How a durable workflow engine works: you might not need a queue Bài tóm tắt · Inngest · 2023
…ng có workflow engine: viết từng task chạy trong queue, đẩy job, nối job này sang job khác, tự quản trạng thái giữa các bước. - Có workflow engine: viết một hàm gồm nhiều step ; mỗ…
- Timestone: Netflix's High-Throughput, Low-Latency Priority Queueing System Bài tóm tắt · Netflix · 2022
…lời, đồng thời trả cho client và phát event sang Kafka; hai job Flink cập nhật index "hiện tại" và "lịch sử" trên Elasticsearch (best-effort, thứ tự theo bộ đếm version của message…
- Maximum Warp: Building Migrations for Slack Enterprise Grid Bài tóm tắt · Slack · 2017
…Experience 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…
- Centrifuge: a reliable system for delivering billions of events per day Bài tóm tắt · Segment · 2018
…ứ tự trong Kafka do producer chốt). - Mô hình dữ liệu: bảng jobs (payload trung vị 5 KB, tối đa 750 KB; khoá chính KSUID, chỉ một index) và bảng job state transitions , cả hai bất…
- Executing Cron Scripts Reliably At Scale Bài tóm tắt · Slack · 2023
…g lại hệ có sẵn thay vì xây hết: ba thành phần: - Scheduled Job Conductor (Go, trên Bedrock, lớp bọc Kubernetes của Slack): thư viện cron của Go giữ nguyên định dạng chuỗi cron cũ…
- Utilizing Amazon DynamoDB and AWS Lambda for Asynchronous Event Publication Bài tóm tắt · Zalando · 2022
…ry thì event vào SQS dead letter queue ; một Kubernetes CronJob chạy lại cùng code Python theo chu kỳ để gửi lại và xoá khỏi hàng đợi khi thành công. - Đánh đổi nêu rõ: không đảm b…
- How we scaled async workload processing at GitLab.com using Sidekiq Bài tóm tắt · GitLab · 2020
…ất nhiều note trên một commit làm chậm queue gửi thông báo; job xử lý pipeline dồn, node pipeline hết CPU, pool pgbouncer của Sidekiq bão hoà. Thay đổi chính - Trạng thái cũ: quan…
- Scaling LinkedIn's Hadoop YARN cluster beyond 10,000 nodes Bài tóm tắt · LinkedIn · 2021
…partition riêng (khoảng 4.000 + 2.000 node). Hai tháng sau, job chờ hàng giờ mới được cấp dù cụm còn nhiều tài nguyên; tốc độ cấp container có lúc rơi từ khoảng 600 xuống 50/giây t…
- Infrastructure patterns for agentic applications Bài tóm tắt · Render · 2026
…g thái, subscribe hay nhận callback. Bẫy: queue biết có một job, không biết job thuộc tiến trình logic nào (hai mươi bước phụ thuộc, ba lần retry, hai nhánh, một lần chờ người duyệ…
- Our Migration to FoundationDB, Part 1 Bài tóm tắt · Inngest · 2026
…đọ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ó, và nó phải giữ công bằng giữ…
- How We Halved Go Monorepo CI Build Time Bài tóm tắt · Uber · 2022
…n phí); chia target đã đổi ra nhiều máy. Trên Jenkins (MultiJob cần cây tĩnh) họ khai báo sẵn 50 shard và bật theo metadata để giả lập sharding động: 10.000 target từ một giờ còn k…
- Scaling Email Infrastructure for Medium Digest Bài tóm tắt · Medium · 2020
…là một trong những tải nặng nhất. - Luồng: mỗi 10 phút một job Jenkins phát shard event , fan-out thành 256 shard event con; mỗi cái quét một shard của bảng email user cho múi giờ…
- 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…
- Running an automated test pipeline for the League client update Bài tóm tắt · Riot Games · 2016
…trên VM Windows và macOS (client chỉ chạy ở đó). Hàng loạt job tương tự được sinh từ cấu hình JSON bằng Jenkins Job DSL, tham số chung để đấu nối lại dễ. - Test về ở cạnh code: tá…
- 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…
- 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:
- 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…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một 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:
- 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.
- 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:
- 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…
- 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:
- 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.
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- 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…
- 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.
- 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.
- 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".
- 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…
- 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…
- 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:
- 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ì…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- 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: