Tìm kiếm
30 kết quả cho “một session một shard”. Tìm không phân biệt dấu.
- 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.
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
…Từ 2015 Asana shard theo domain (mỗi domain nằm trọn trong một database, mỗi DB chứa nhiều domain), cộng một master shard lưu user và quan hệ thành viên domain. Mọi DB và service…
- 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 we built the Tinder API Gateway Bài tóm tắt · Tinder · 2022
…lẫn traffic của kẻ xấu. - Trước TAG: mỗi team ứng dụng dùng một API gateway bên thứ ba khác nhau, trên các stack khác nhau. Hậu quả: khó bảo trì, không chia sẻ được thành phần, chậ…
- 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".
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không cò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:
- 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.
- 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…
- 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:
- 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.
- 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…
- 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.
- 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…
- 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…
- Tracing phân tán và log theo request Chủ đề
Khi một request đi qua hàng chục service, metric của từng service cho biết có chậm, log của từng service cho biết từng mảnh; không cái nào trả lời "request này chậm vì đâu" hay "trang này tốn bao nhiêu". Tracing phân…
- 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…
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…
- Discord Công ty Thành viên
Hiếm có công ty nào kể cùng một bài toán qua 6 năm như Discord. Năm 2015 họ cố ý dùng một replica set MongoDB để ra sản phẩm trong 2 tháng, kèm đường thoát. Họ phân tích workload rồi chuyển sang Cassandra 12 node với…
- How Discord Scaled Elixir to 5,000,000 Concurrent Users Bài tóm tắt · Discord · 2017
…7). - Kiến trúc lõi là pub/sub: mỗi user mở WebSocket và có một process session ; mỗi guild (server Discord) là một process guild trên node khác. Sự kiện trong guild được fan-out t…
- Chat Service Architecture: Servers Bài tóm tắt · Riot Games · 2015
…tỷ event (presence, message, IQ) và hàng triệu REST query; một ngày tháng 7 có 1,7 triệu lượt kết bạn mới. - Triển khai theo region ("shard"): mỗi region một cụm chat riêng, không…
- A Self-Baked Async FFI Framework for Rust <-> C# Interop Bài tóm tắt · ScyllaDB · 2026
…nh, bỏ chi tiết cú pháp interop. Bối cảnh - ScyllaDB chỉ có một database nhưng phải bảo trì một đàn driver , mỗi ngôn ngữ một cái. Ý tưởng "One Driver To Rule Them All" (từ hackath…
- The growing pains of database architecture Bài tóm tắt · Figma · 2023
…Phần lớn metadata (quyền, thông tin file, comment) nằm trên một Amazon RDS Postgres . Giờ cao điểm CPU vượt 65%, latency ngày càng khó đoán. Theo Figma: nếu DB bão hoà hoàn toàn th…
- Zillow Công ty Thành viên
Zillow cho thấy một công ty dữ liệu đi từ ứng dụng web có cache tự làm sang nền tảng dữ liệu, ML và thí nghiệm dùng chung. Năm 2012 các sản phẩm mới đã chạy trên AWS: nền tảng website cho môi giới trên WordPress dùng…
- Asana Công ty Thành viên
Phần mềm quản lý công việc; hai nguồn trong wiki đều về lớp dữ liệu. Asana shard theo domain (tenant) từ 2015, nhưng một phần dữ liệu dùng chung cho mọi workspace vẫn nằm trong một MySQL trên RDS. Mùa hè 2019, ba lần…
- Upgrading a 56TB database that's growing at 250GB per day with (nearly) no downtime Bài tóm tắt · Trigger.dev · 2026
…ps://trigger.dev/blog/upgrading-a-56tb-database) Bối cảnh - Một cụm Aurora Postgres khoảng 56 TB : bảng run 29,4 TB, các bảng liên quan tới run 25,4 TB, dữ liệu control plane (tổ c…
- Technical Secrets of PolarDB: High Availability - Smooth Switchover Bài tóm tắt · Alibaba · 2025
…L primary/secondary truyền thống (replicate binlog, mỗi bên một bản dữ liệu), PolarDB for MySQL dùng storage chia sẻ : primary (RW) và read-only (RO) trong cùng zone đọc chung một…
- What Powers Instagram: Hundreds of Instances, Dozens of Technologies Bài tóm tắt · Instagram · 2011
…dùng ElastiCache vì không rẻ hơn tự chạy. Bài học cho SWE - Một monolith Django + Postgres + Redis + Memcached đủ cho hàng chục triệu user nếu giữ app stateless và working set tron…