LinkedIn details how it replaced Spark's push-based Magnet shuffle with a unified shuffle platform built on Apache Celeborn, serving both Spark and Flink workloads at massive scale. The architecture disaggregates shuffle storage from compute via dedicated Celeborn workers, adding network-aware replication, disruption-aware slot selection, fleet-wide health monitoring, NVMe storage, 100 Gbps networking, and ZSTD compression. Results versus the Magnet baseline include a 20x reduction in task failures during maintenance, 40% lower shuffle duration, 35% smaller required fleet size, 6x faster slot selection, ~10% lower compute cost, ~14% lower runtime, shuffle fetch failures dropping from ~750 to ~20 per day, and ~90% lower per-task shuffle cost. The rollout also enabled Flink to absorb large historical backfills, retiring a parallel Spark-based historical pipeline across thousands of pipeline instances.
Nguồn: https://www.linkedin.com/blog/engineering/infrastructure/scaling-spark-and-flink-shuffle-at-linkedin-with-apache-celeborn. 8 Sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.
Đọc tin ở đây, luyện code, học theo lộ trình và luyện IELTS trên các sản phẩm anh em — tất cả kết nối với nhau trong hệ sinh thái 8 Sync.
Cổng chính của hệ sinh thái: giới thiệu sản phẩm, blog và bảng giá trọn bộ.
Khám pháHọc theo lộ trình rõ từng chặng: video, quiz chấm tự động, certificate và mentor đang làm nghề.
Xem lộ trình1.000 bài DSA, đề tiếng Việt, chấm tự động 7 ngôn ngữ — nhiều bài FREE, chạy ngay trên trình duyệt.
Luyện miễn phíChấm bốn kỹ năng IELTS bằng AI, phản hồi chi tiết theo rubric.
Dùng thử miễn phíAI IDE 22 MB cho dev Việt.
Tải miễn phíBộ nhớ tổ chức cho AI agent.
Khám pháAI trực Fanpage, tự sàng lọc lead.
Dùng thửTác giả đã xây dựng Dhara, một distributed task queue bằng Go sử dụng PostgreSQL làm queue duy nhất và nguồn sự thật thực tế. Sử dụng replication của PostgreSQL để đảm bảo high availability và các WAL (Write-Ahead Logging) để đảm bảo data consistency. Cấu trúc hiện tại hỗ trợ tới 5,000 tasks mỗi giây với độ trễ chỉ 10ms. Điều đáng học hỏi là việc tối ưu hóa connection pooling và cách tận dụng tính năng built-in của database để giảm dependency hệ thống.
Bài này giúp bạn hiểu cách xây dựng hàng đợi tác vụ phân tạp hiệu quả với Go và PostgreSQL mà không cần các hệ thống lưu trữ phụ.
Trong hệ thống phân tán, vấn đề "save-then-publish" có thể gây mất sự kiện (event) mà không ghi log lỗi nào. Nguyên nhân kỹ thuật là transaction database và message broker hoạt động độc lập, dẫn đến tình trạng message bị drop dù insert thành công. Hệ quả là các subscriber không nhận được event cần thiết, làm hỏng tính toàn vẹn dữ liệu. Pattern Outbox + Inbox sử dụng cùng một transaction để lưu cả event và dữ liệu vào database, đảm bảo không mất sót message, thực hiện hiệu quả với Postgres và Node.js.
Bài này giải thích cách tránh mất sự kiện khi lưu trữ dữ liệu bằng pattern Outbox trong Postgres và Node.js.
Bài viết chỉ ra hiện tượng coi số lượng dịch vụ microservices như dấu hiệu của kinh nghiệm cao trong ngành phần mềm. Tac giả lấy ví dụ về một dự án có tới 37 dịch vụ độc lập, mỗi dịch vụ được triển khai trong container và kết nối qua API REST/gRPC. Nguyên nhân kỹ thuật là xu hướng tách hệ thống quá sớm mà không xác định rõ ranh giới nghiệp vụ, dẫn đến sự dư thừa trong quản lý cấu hình, giám sát và truy vết lỗi. Hệ quả là tăngภาระ vận hành, độ trễ giao tiếp giữa dịch vụ và khó duy trì tính nhất quán dữ liệu, khiến đội ngũ tiêu tốn nhiều thời gian cho DevOps thay vì phát triển tính năng. Bài học là trước khi quyết định chuyển sang microservices, cần đánh giá độ phức tạp miền vấn đề, cân nhắc sử dụng monolith mô-đun hoặc các dịch vụ có kích thước vừa phải, và chỉ mở rộng khi có bằng chứng thực tế về nhu cầu mở rộng và đội ngũ có khả năng vận hành.
Bài viết này giúp lập trình viên hiểu rằng kiến trúc microservices không phải là thước đo trình độ kỹ năng hay kinh nghiệm senior thực sự.
Vào ngày 23 tháng 9, GitHub đã gặp sự cố với tỷ lệ lỗi 500 và 404 tăng cao trên nhiều trang ứng dụng, bắt đầu từ 07:57 UTC. Nguyên nhân kỹ thuật được cho đến từ vấn đề về routing và phân phối tải (traffic routing) dẫn đến việc không thể định tuyến đúng đến các trang cụ thể. Sự cố này gây ra các trang hiển thị lỗi 404 và lỗi 500 trên nhiều tính năng của GitHub, ảnh hưởng đến trải nghiệm người dùng. Điều đáng học hỏi là ngay cả các nền tảng lớn như GitHub cũng có thể gặp sự cố về routing traffic, nhấn mạnh tầm quan trọng của hệ thống giám sát và dự phòng.
Bài viết cung cấp phân tích ngắn gọn về sự cố GitHub ngày 23/9 giúp lập trình viên hiểu rõ nguyên nhân và bài học từ sự cố này.
Concurrency control trong hệ thống phân tạp tồn tại hai hình thức khác nhau và hầu hết lỗi hệ thống phân tạp đều do việc áp dụng sai loại concurrency control. Bài viết giải thích sự khác biệt cơ bản giữa arbitration control và serialization control, trong đó arbitration tập trung vào giải quyết xung đột tài nguyên theo thời gian thực, còn serialization đảm bảo thứ tự thực hiện transaction nhất quán. Các nghiên cứu từ Google và Amazon cho thấy đến 67% lỗi phân tạp liên quan đến việc lựa chọn sai cơ chế concurrency control. Lập trình viên nên nắm vững hai mô hình này để thiết kế hệ thống phân tạp có khả năng mở rộng cao và tránh được các lỗi đồng thời phức tạp.
Bài viết giúp lập trình viên hiểu sự khác biệt giữa arbitration và serialization để tránh lỗi phân tán trong hệ thống.
American Express sử dụng kiến trúc cell-based để xử lý giao dịch thanh toán quy mô lớn. Kiến trúc này chia hệ thống thành các cell độc lập, mỗi cell chứa đầy đủ các dịch vụ cần thiết để xử lý một giao dịch. Khi một cell gặp sự cố, các cell khác vẫn có thể tiếp tục hoạt động, đảm bảo hệ thống không bị sập hoàn toàn. Mô hình này giúp American Express đạt độ sẵn sàng cao, với thời gian downtime chỉ vài giây mỗi năm và xử lý hàng triệu giao dịch mỗi ngày. Các lập trình viên học được cách thiết kế hệ thống phân tán có khả năng chịu lỗi bằng cách cô lập sự cố trong một phạm vi nhỏ.
Bài viết này giúp lập trình viên hiểu cách xây dựng hệ thống xử lý giao dịch đáng tin cậy ngay cả khi gặp sự cố.
So sánh chi tiết giữa monolithic và microservices vượt qua lý thuyết, bàn về sự phức tạp trong deployment, sự ảnh hưởng của Conway's Law đến ownership team, khó khăn trong debugging và observability, cũng như thách thức về data consistency, performance và scaling. Bài viết chỉ ra monolithic thực sự phù hợp trong những trường hợp nào, khi nào microservices mang lại hiệu quả, và giới thiệu khái niệm "modular monolith" như giải pháp trung gian. Các lỗi phổ biến như resume-driven development hay distributed monoliths được liệt kê kèm framework thực tế để ra quyết định dựa trên team, domain, delivery, operations và scale. Thông điệp chính là chọn architecture dựa trên vấn đề thực tế chứ không phải sự phức tạp giả định.
Bài viết này giúp lập trình viên hiểu rõ sự cân thực giữa kiến trúc microservices và monolithic, tránh những sai lầm phổ biến và đưa ra quyết định kiến trúc phù hợp dựa trên nhu cầu thực tế.
Ampbase đã triển khai control plane hoàn toàn trên Tigris object storage mà không sử dụng database truyền thống dưới lớp. Họ đã tự xây dựng bốn nguyên tố cơ bản của database (CRUD operations, indexing, transactions và consistency) trực tiếp trên object storage. Vấn đề phát sinh khi xử lý transaction và consistency, đặc biệt là khi dữ liệu lớn, dẫn đến performance không ổn định. Bài viết cung cấp bài giá trị thực tế về giới hạn của object storage khi làm database, hữu ích cho ai đang cân nhắc kiến trúc serverless.
Bài này giúp bạn hiểu cách xây dựng hệ thống control plane hoàn toàn bằng object storage mà không cần database truyền thống.
Đang tải bình luận…