Tìm kiếm
40 kết quả cho “Redis Cluster”. Tìm không phân biệt dấu.
- Atomic slot migration with Redis 8.4 Bài tóm tắt · Redis · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://redis.io/blog/atomic-slot-migration/) Bài kỹ thuật của nhà cung cấp về tính năng của Redis Open Source; benchmark do Redis…
- How Twitter Uses Redis to Scale - 105TB RAM, 39MM QPS, 10,000+ Instances Bài tóm tắt · Twitter · 2014
…](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) Nguồn thứ cấp: HighScalability tóm tắt talk của Yao Yue (đội Cache của…
- Redis Công ty Thành viên
Nguồn duy nhất của Redis (công ty) trong wiki là bài về atomic slot migration ở Redis 8.4: Redis Cluster dời hash slot giữa shard bằng cách chép snapshot của cả slot kèm luồng delta rồi chuyển quyền một lần, thay cho…
- 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…
- Controlled Chaos with Fault Injection Testing Bài tóm tắt · Riot Games · 2019
…kỳ, tổng số call mỗi khách phải đếm ở một chỗ trung tâm là Redis . - Khi chuyển Riot API từ VM AWS vào rCluster (cloud nội bộ chạy container), đội chọn chạy Redis trong rCluster b…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…lave), 4 node Cassandra, 15 node Membase (3 cụm), Memcache, Redis, Elasticsearch, 3 cụm Mongo, chỉ với 3 kỹ sư. Năm công nghệ DB khác nhau, mỗi cái hỏng theo cách riêng khi bị đẩy…
- Scaling Our Geo-Search Service For 10x Load Bài tóm tắt · Gojek · 2022
…nhật lại phải re-index, không chịu nổi tải ghi. Chuyển sang Redis , nhưng trần chỉ khoảng 10.000 request/phút. GoRide dùng một hệ khác; khi GoFood và Logistics lớn lên thì ngày nào…
- Stack Overflow: How We Do App Caching - 2019 Edition Bài tóm tắt · Stack Overflow · 2019
…cảnh - Thang độ trễ (2019): RAM khoảng 100 ns; một lần gọi Redis qua LAN của họ 0,2–0,5 ms (chậm hơn RAM 2.000–5.000 lần); trang câu hỏi render trung bình 18–20 ms , nên vài lần g…
- 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…
- March 20 ChatGPT outage: Here's what happened Bài tóm tắt · OpenAI · 2023
…thấp". Nguyên nhân - Kiến trúc: cache thông tin user trong Redis Cluster để không phải hỏi DB mỗi request; server Python chạy asyncio dùng thư viện redis-py với một pool kết nối d…
- Stack Overflow: The Hardware - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…nhân, 64 GB RAM. - Service (tag engine, indexing): 3 máy. - Redis: 2 máy, 256 GB RAM. - Elasticsearch: 3 máy, 192 GB RAM. - HAProxy: 2 máy cho traffic qua CloudFlare, 2 máy cho tra…
- Scaling Kubernetes to 2,500 nodes Bài tóm tắt · OpenAI · 2018
…cache: mỗi pod một IP làm đầy bảng ARP của kernel (kết nối Redis mất hơn 30 giây). Tăng ngưỡng gc thresh như các cụm HPC vẫn làm. - Kết quả: khoảng 3 tháng không sự cố. Bài học ch…
- Airflow at Zillow Bài tóm tắt · Zillow · 2017
…, metadata DB Postgres trên RDS, broker RabbitMQ (chọn thay Redis/SQS vì ổn định, chống mất dữ liệu), DAG/plugin/log trên S3, email qua SES, log về Splunk. - Airflow chỉ chạy job 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.
- 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:
- 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:
- 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".
- 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.
- 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:
- 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.
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- 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:
- 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:
- 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.
- 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…
- 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.
- 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:
- 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…
- 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:
- 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…
- Twitter Công ty Thành viên
Khi rời một MySQL duy nhất sang Cassandra và MySQL shard (Gizzard), thứ vỡ đầu tiên là sinh ID, dẫn tới Snowflake (64 bit, k-sorted, không phối hợp) . Sau World Cup 2010, họ nhận ra monolith Rails (~200 kỹ sư) và…
- Stack Overflow: The Architecture - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…trong đó 66 triệu page load; - 504 triệu SQL query, 5,8 tỷ Redis hit; - trang câu hỏi render trung bình 22,7ms , trang chủ 11,8ms. So với 11/2013: thêm 61 triệu request/ngày mà th…
- Gojek Công ty Thành viên
Dịch vụ tìm tài xế của Gojek đi từ Postgres (không chịu được vị trí cập nhật liên tục) sang Redis, rồi khi GoFood và Logistics tăng trưởng thì phải scale ngang: đẩy đọc sang replica nhờ lệnh EVALRO họ đề xuất cho Redis,…
- Balancing cost and reliability for Spark on Kubernetes Bài tóm tắt · Notion · 2026
…ụ 70% spot, 30% on-demand), lưu số executor theo loại trong Redis. Một lần thu hồi chỉ mất một phần nhỏ, đã biết trước, số executor; Spark tự retry phần còn lại. Job dài hay quan t…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- 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…
- Attack of the Shards: Our Migration to FoundationDB, Part 2 Bài tóm tắt · Inngest · 2026
…ả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ữ liệu trên đĩa). - Lý do nêu tr…
- Riot Games Công ty Thành viên
Chat League of Legends (2015): cụm Erlang theo region, mỗi node tự trị, bảng định tuyến nhân bản trong Mnesia và tự lành sau netsplit; viết lại 10% phần nóng bằng C . Kho dữ liệu chuyển từ MySQL (chỉ scale dọc, SPOF,…