Tìm kiếm
40 kết quả cho “Redis lock”. Tìm không phân biệt dấu.
- Rediscovering Transaction Processing From History and First Principles Bài tóm tắt · TigerBeetle · 2024
…ng bình — [bài gốc](https://tigerbeetle.com/blog/2024-07-23-rediscovering-transaction-processing-from-history-and-first-principles) Bài của nhà sáng lập TigerBeetle (Joran Dirk Gre…
- We replaced Redis with MySQL for inventory reservations, and it scaled Bài tóm tắt · Shopify · 2026
…y họ chiếm hơn 14% thương mại điện tử Mỹ. - Mô hình cũ trên Redis: DECR / INCR trên khoá số lượng. Concurrency ổn, nhưng reservation (Redis) và sổ tồn kho (MySQL) nằm ở hai hệ thốn…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
…- Kiến trúc từ những ngày đầu: web app băm ID job chọn host Redis, khử trùng có giới hạn, worker poll Redis, chuyển job sang danh sách đang chạy, lỗi thì sang hàng thử lại. - Sự cố…
- Building High Throughput Payment Account Processing Bài tóm tắt · Uber · 2026
…hoản vào lô có hạn thời gian bằng script Lua nguyên tử trên Redis , đẩy task vào hàng đợi Redis, trả kết quả cho client từ cache kết quả trên Redis. Batch Process: các processor ở…
- Dynein: Building a Distributed Delayed Job Queueing System Bài tóm tắt · Airbnb · 2019
…Resque trung tâm của monolith Rails, chạy trên một instance Redis : at-most-once (có thể mất job), giới hạn bởi RAM và mạng một máy, một job xấu làm đứng phần lớn worker; Resque Sc…
- How we stopped xmin horizon blocking Postgres vacuuming Bài tóm tắt · Trigger.dev · 2024
…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 queue trên chính Postgres , tìm j…
- Finding Order in Chaos: How We Automated Performance Testing with Torque Bài tóm tắt · Dream11 · 2021
…dựng EC2 sinh tải và deploy code → các generator giành khoá Redis (Redisson) → generator thắng lấy dữ liệu, đẩy lên S3, gọi Lambda (hoặc Spark nếu 100–200 triệu dòng, vượt giới hạn…
- ML Feature Serving Infrastructure at Lyft Bài tóm tắt · Lyft · 2021
…, từ đó nhân bản sang Hive (cho training) và Elasticsearch. Redis làm write-through cache cho cả giá trị lẫn metadata. Người ghi có thể phân tán nên dùng conditional check của Dyna…
- The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds Bài tóm tắt · Twitter · 2013
…low) rồi chèn ID tweet vào list của từng follower trong cụm Redis (vài TB RAM, mỗi timeline nhân 3 bản trên 3 máy, pipeline 4.000 đích mỗi lần). Mỗi phần tử chỉ là ID tweet, ID ngư…
- How we scaled async workload processing at GitLab.com using Sidekiq Bài tóm tắt · GitLab · 2020
…Bối cảnh - GitLab (Rails) xử lý việc nền bằng Sidekiq trên Redis. Lịch sử: 2013 mỗi worker class một queue, không ai quản; 2016 gom theo tính năng; 2017 lại mỗi worker class một q…
- 5-year Evolution of Ele.me's Transaction System - Part 4 Bài tóm tắt · Ele.me · 2020
…i cảnh Sau khi shard (đầu 2016), nút cổ chai dời từ DB sang Redis (khoảng 6/2016). Twemproxy và Codis gặp nhiều vấn đề, nên Ele.me tự viết proxy Redis corvus có đủ metric (bộ nhớ,…
- Load Testing Kubernetes: Resolving bottlenecks and improving performance (Part 2) Bài tóm tắt · Achievers · 2023
…ưu query xuống mức mili giây. - Cache: chuyển ảnh sang CDN; Redis ở vài namespace quan trọng vượt limit bộ nhớ của Kubernetes và bị OOM, sửa bằng tăng request. Theo Achievers, Redi…
- An alternative approach to rate limiting Bài tóm tắt · Figma · 2017
…chậm request, tự dọn dữ liệu cũ, chính xác, ít bộ nhớ. Chọn Redis (thay vì Postgres) vì nhanh và có sẵn cơ chế hết hạn. Thay đổi chính So sánh ba thuật toán quen thuộc: Thuật toán…
- How We Made QStash And Upstash Workflow Reliable At Scale Bài tóm tắt · Upstash · 2026
…thuộc một máy lớn mãi: storage là một pool database Upstash Redis , tài nguyên và task của khách rải qua các DB, thêm DB khi cần thay vì migrate sang node to hơn; compute là cụm pr…
- Executing Cron Scripts Reliably At Scale Bài tóm tắt · Slack · 2023
…- Job Queue của Slack (khoảng 9 tỉ job/ngày; Kafka để bền, Redis để giữ metadata ngắn hạn, rồi worker): mỗi script là một job, đặt trên queue riêng nên chạy nhanh; gánh hết CPU và…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- 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".
- 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ả…
- 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:
- 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.
- 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…
- 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ố…
- 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.
- 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ì…
- 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…
- 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:
- 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…
- 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.
- 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…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- 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:
- 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:
- Upstash Công ty Thành viên
Nhà cung cấp Redis serverless. Sau vụ mất một AZ của AWS tháng 5/2026, họ mô tả failover multi-AZ: bầu replica có số thứ tự ghi cao nhất, từ chối promote bản thiếu, trộn sau split-brain, backpressure lên ghi khi replica…
- How Upstash Monitors Uptime: Every Replica, Every Minute, From Everywhere Bài tóm tắt · Upstash · 2026
…của mình, nhận định ghi "theo Upstash". Bối cảnh - Upstash Redis đa tenant, nhiều zone: mỗi database có ít nhất hai replica; mất một replica thì bầu replica khác (). Theo Upstash,…
- Shopify Công ty Thành viên
Năm 2015 không còn mua được DB to hơn nên Shopify shard, rồi phát hiện thao tác lặp mọi shard làm mất cô lập lỗi. Kiến trúc pod (mỗi request chỉ chạm một tập datastore cô lập, Pod Mover dời pod sang DR) ra đời .…
- Counter Service: How we rewrote it in Rust Bài tóm tắt · Grab · 2025
….rs…), nhưng vài thư viện ít sao/không chính thức. Thư viện Redis "chính thức" không đáp ứng được nên đổi sang fred.rs. - Thư viện nội bộ chỉ có cho Go (config dựa trên Go template…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…
- Airbnb Công ty Thành viên
Airbnb chuyển từ một ứng dụng Rails khổng lồ sang SOA, và lộ ra chi phí test: deep integration test cho mọi service không scale, nên họ chuyển sang tháp test + CD có canary analysis . Năm 2025 với ba trụ sản phẩm, data…