Tìm kiếm
30 kết quả cho “failover architecture”. Tìm không phân biệt dấu.
- 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:
- The LMAX Architecture Bài tóm tắt · LMAX · 2011
LMAX là sàn giao dịch phái sinh cho nhà đầu tư cá nhân (công ty mẹ là Betfair). Sàn cần latency thấp vì mỗi giao dịch làm thay đổi thị trường cho giao dịch sau; bán lẻ thì thêm nhiều người dùng. Phần lớn hoạt động đến…
- Adopting Arm at Scale: Transitioning to a Multi-Architecture Environment Bài tóm tắt · Uber · 2025
…mới sang tier sau), non-prod trước prod , từng zone (để còn failover hoặc rút traffic khỏi một AZ). Test tự chạy mỗi lần deploy; tự revert khi có alert hay SLA xấu đi, nên không cầ…
- Disaster Recovery for Databases: High-availability Architecture of PolarDB-X Bài tóm tắt · Alibaba · 2026
…, mất phân vùng là ngừng); bất đồng bộ (nhanh, mất dữ liệu, failover cần người kiểm); semi-sync (gần 0, khi trễ thì tụt về bất đồng bộ nên vẫn có thể mất); đồng thuận đa số Paxos/R…
- How we rebuilt the search architecture for high availability in GitHub Enterprise Server Bài tóm tắt · GitHub · 2026
…ch chỉ lo replication document; GitHub tự viết workflow cho failover, xoá index, nâng cấp . - Rollout: tuỳ chọn từ bản 3.19.1 (bật cờ cấu hình rồi config-apply /nâng cấp); khi khởi…
- The Evolution of Alibaba Cloud's Relational Database Services Architecture - PolarDB Bài tóm tắt · Alibaba · 2018
…metadata; trễ giữa master và read node xuống mức mili giây; failover sang read node dưới 30 giây . Replication theo page song song mịn hơn theo bảng; tắt được binlog nếu không cần…
- MemSQL Architecture - The Fast (MVCC, InMem, LockFree, CodeGen) And Familiar (SQL) Bài tóm tắt · MemSQL · 2012
Hai nhà sáng lập từng ở Facebook (nền tảng, hạ tầng; một người từng làm lõi SQL Server). Theo họ, Facebook scale được nhờ hai thứ: Memcached (KV trong RAM) và sinh code (HipHop dịch PHP sang C++). Ghép hai ý vào…
- Large-Scale Automated Dependency Analysis Across Uber's Service Mesh Bài tóm tắt · Uber · 2026
…n mesh đã được đánh chỉ mục, làm hàng rào chống hồi quy cho Failover Architecture 2.0; là nền cho cơ chế chống retry storm. Vì sao - Mẫu trace quá thưa để thấy lỗi hiếm trong thời…
- Active-Active Shared-Nothing Database Architecture Bài tóm tắt · CapitalOne · 2020
…N thường bị nhầm với HA. - Active/passive và brown-out: khi failover phải chờ standby bắt kịp; khoảng đó gọi là brown-out . Muốn hết brown-out thì phải nhân bản đồng bộ, vốn đắt (m…
- Chat Service Architecture: Persistence Bài tóm tắt · Riot Games · 2015
…single point of failure ; trục trặc nhỏ không đủ kích hoạt failover vẫn gây timeout, sự cố lớn thành downtime và nhiều việc tay; - schema migration ngày càng đắt, thường cần hàng…
- Flava DBaaS deep dive: From architecture to migration and beyond Bài tóm tắt · LINE (LY Corp) · 2026
…DBMS: dump & restore (cần downtime), replication native rồi failover (gần như không downtime, phải đổi endpoint), CDC qua Kafka (vượt được khác biệt topo, ví dụ Redis 6 shard sang…
- Độ 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.
- 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…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Hệ thống độ trễ thấp (low latency) Chủ đề Thành viên
Ở sàn giao dịch và công ty market making, mỗi giao dịch làm thay đổi thị trường cho giao dịch sau, và ai phản ứng chậm hơn thì thua. Yêu cầu không chỉ là latency trung bình thấp mà latency ổn định ở đuôi, ở thang micro…
- 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.
- 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".
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- 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ả…
- 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…
- 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.
- 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…
- 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.
- 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ẻ…
- 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 .…
- 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…
- Building Git infrastructure for agent-scale development Bài tóm tắt · GitHub · 2026
Tải tăng vọt vì agent (theo GitHub): tổng sự kiện Git từ 218,2 tỉ lên 473,3 tỉ mỗi tháng (9/2025 → 8/2026); push tăng 4,9 lần trong một năm (0,69 → 3,35 tỉ/tháng); 7,38 tỉ commit trong tháng 9/2026, gấp hơn năm lần năm…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- LMAX Công ty Thành viên
Sàn giao dịch phái sinh cho nhà đầu tư cá nhân, thuộc Betfair. Nguồn duy nhất trong wiki là bài năm 2011 của Martin Fowler, viết theo lời kể của đội LMAX: sau khi prototype actor model cho thấy CPU bận quản lý hàng đợi…
- HTTPS on Stack Overflow: The End of a Long Road Bài tóm tắt · Stack Overflow · 2017
…card (DigiCert), cài giống hệt ở cả load balancer và CDN để failover được. Domain dạng meta.gaming.stackexchange.com không được wildcard phủ (RFC 6125), nên phải đổi sang gaming.me…