Tìm kiếm
40 kết quả cho “Cache hit ratio”. Tìm không phân biệt dấu.
- 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:
- Re-architecting Slack's Workspace Preferences: Moving to an EAV Model Bài tóm tắt · Slack · 2018
…es , vốn đã bị truy cập rất nhiều cho thông tin sống còn; - cache lưu cả object workspace, nên đọc một tuỳ chọn là kéo cả khối về Memcached, và đổi một tuỳ chọn là invalidate cả ob…
- 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.
- Using the Gini Coefficient to Plan Edge Capacity Bài tóm tắt · Fastly · 2026
…ớn làm vài khách chiếm phần lớn traffic → độ phổ biến cao → cache hit cao → mỗi request rẻ CPU hơn. Hai POP cùng tổng traffic có thể có hành vi cache rất khác. - Chuỗi mô hình: tra…
- MemSQL Architecture - The Fast (MVCC, InMem, LockFree, CodeGen) And Familiar (SQL) Bài tóm tắt · MemSQL · 2012
…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 database: DB trong RAM nhưng giao diện là…
- Rearchitecting the Workflows control plane for the agentic era Bài tóm tắt · Cloudflare · 2026
…e: kiểm phiên bản control plane, dùng thông tin workflow đã cache ở location đó (thiếu mới hỏi Account), chỉ ghi metadata cần thiết vào chính Engine; việc báo cho control plane chạ…
- A Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay Bài tóm tắt · eBay · 2022
…pendency) có thể lớn hơn chính việc; worker sống lâu và giữ cache cục bộ thắng worker dùng một lần. - Theo eBay, mẫu "service trung tâm giữ hàng đợi + worker kéo việc" dùng lại đượ…
- Optimizing Elasticsearch for Low Latency, Real-Time Recommendations Bài tóm tắt · Zillow · 2022
…hất. Thay đổi chính - Service rt-recs (Java + Python): kiểm cache Redis → lấy hồ sơ người dùng (cập nhật gần realtime) → Elasticsearch sinh tối đa 100 ứng viên từ khoảng 1,3 triệu…
- Stack Overflow: How We Do App Caching - 2019 Edition Bài tóm tắt · Stack Overflow · 2019
…Craver (bài cuối đã viết). Bài trước: . Chi tiết hoá phần "cache 2 tầng" trong . Bối 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…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…B + 9 slave), 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…
- Himeji: A Scalable Centralized System for Authorization at Airbnb Bài tóm tắt · Airbnb · 2021
…ng: orchestration (đọc cấu hình, phát lệnh fetch, route tới cache bằng consistent hashing), cache (shard + replica, mỗi shard một instance trên mỗi AZ, nhắm hit rate khoảng 98%), d…
- Building Git infrastructure for agent-scale development Bài tóm tắt · GitHub · 2026
…n và replication có sẵn); năng lực đọc đến từ worker nhẹ có cache, nên đỡ được spike đọc (CI fan-out, đội agent, clone lớn) mà không thêm việc cho mỗi push. - Phục hồi nhanh hơn: m…
- What it takes to run Stack Overflow Bài tóm tắt · Stack Overflow · 2013
…0 (ghi nhiều hơn đọc), vì DB nằm gọn trong RAM và có 2 tầng cache phía trước nên gần như mọi lần đọc không chạm tới đĩa. - Hiệu năng trang: Question/Show (29,7 triệu hit/ngày) rend…
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
…c bước: 1. quy tắc sinh order ID mới ; 2. ghi kép vào DB và cache, đọc dữ liệu cũ, so sánh; 3. sửa SQL không tương thích (sắp xếp xuyên shard, thống kê, query không có khoá shard).…
- Journey to the cloud part I: Migrating Stack Overflow Teams to Azure Bài tóm tắt · Stack Overflow · 2023
…truy cập team đã dời qua URL cũ khiến code nạp lại toàn bộ cache site mỗi lần, một thao tác rất đắt, và "có lẽ đã làm sập site một hai lần". - Xong pha 1 vào 12/2022, sau gần một…
- 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…
- 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…
- 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:
- Độ 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.
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- 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…
- 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.
- 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".
- 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.
- 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ệ 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…
- 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:
- 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…
- 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ả…
- 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.
- 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ỡ:
- 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…
- 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…
- 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 .…
- SoundCloud Công ty Thành viên
Năm 2013 SoundCloud rời mô hình một Public API cho mọi client, tách monolith thành microservice và khai sinh pattern BFF; đến 2021 có vài chục BFF dùng chung thư viện edge, nhưng logic tích hợp và phân quyền bị nhân bản…
- 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…
- 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…
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…ers KV là kho KV toàn cầu: dữ liệu lưu ở storage theo vùng, cache khắp mạng Cloudflare; không chỉ khách hàng dùng mà còn là hạ tầng cho cấu hình, xác thực, phân phối asset của nhiề…
- HTTPS on Stack Overflow: The End of a Long Road Bài tóm tắt · Stack Overflow · 2017
…// sang wss:// . Hơn 600.000 kết nối đồng thời, TLS session cache chiếm phần lớn bộ nhớ, HAProxy dùng 19 GB trên máy 64 GB (2017). Sai lầm được kể lại - URL tương đối giao thức ( /…