Tìm kiếm
31 kết quả cho “Kafka invalidation”. 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:
- 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ả…
- How We Improved Website Performance by Evolving Our Infrastructure Bài tóm tắt · Wix · 2021
…ng cache. Dựng giải pháp nội bộ: Varnish để proxy và cache, Kafka để gửi invalidation, một service Scala/Netty sửa HTML và thêm cookie. Thành phần gọn nên triển khai được ở nhiều n…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
…Theo LinkedIn, cache nên đặt sát kho dữ liệu nhất có thể. - Kafka: nhiều pipeline riêng (vào data warehouse, vào Hadoop, log, tracking, queue cho InMail, cập nhật search khi đổi pr…
- FollowFeed: LinkedIn's Feed Made Faster and Smarter Bài tóm tắt · LinkedIn · 2016
…p99 mỗi bản ghi cho feed mobile). - Ingest bất đồng bộ qua Kafka: service Partitioner đọc stream mọi nội dung rồi ghi lại sang topic có partition khớp partition của index node; cù…
- How We Built a Cross-Region Caching Library Bài tóm tắt · Wix · 2022
…i cảnh - Wix (2022): hơn 500 tỷ HTTP request và 30 tỷ event Kafka mỗi ngày, hơn 2.500 microservice ở nhiều data center. - Nhiều team tự viết thư viện cache nửa vời, mỗi nhóm một ki…
- Keeping Counts In Sync Bài tóm tắt · SoundCloud · 2018
…trên Hadoop/Crunch, đọc dữ liệu từ pipeline event dựa trên Kafka). Dựa trên nhận xét lượt nghe hầu như không đến từ quá khứ (trừ spam và backfill do bug). - Cả tầng batch và tầng…
- Authorization at LinkedIn's Scale Bài tóm tắt · LinkedIn · 2019
…oklin báo để xoá cache. - Log mọi lần check bất đồng bộ qua Kafka để debug, phân tích traffic và phục vụ audit; số liệu đẩy lên inGraphs. - Thực thi phân tán, dữ liệu tập trung: AC…
- 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…
- Độ 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.
- 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:
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- 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ỡ:
- 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…
- 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…
- 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…
- Wix Công ty Thành viên
Năm 2015 Wix dùng MySQL như một kho key/value (blob, không join, không transaction, GUID do client sinh) cho bảng phân giải URL → site, active-active 3 DC, đọc khoảng 1 ms; theo Wix, "MySQL là NoSQL tốt hơn" . Năm 2021,…
- Monzo Công ty Thành viên
Ngân hàng số với hơn 2.100 microservice và hơn 100 deploy/ngày; rollback tự động bằng Argo Rollouts trở thành mặc định cho mọi service . Để chống "stampeding herd" khi hàng triệu người mở app cùng lúc, edge proxy cắt…
- Alibaba Công ty Thành viên
Database của Alibaba đi qua ba giai đoạn, đều do đỉnh tải Double 11 dẫn dắt: thương mại (IBM/Oracle/EMC, 2005–2009) → "De-IOE" sang mã nguồn mở với middleware TDDL và AliSQL (2010–2015) → tự phát triển X-DB (từ 2016).…
- Atlassian Công ty Thành viên
Atlassian lên AWS năm 2016. Tenant Context Service (ánh xạ tenant → vị trí, gọi nhiều lần trong mỗi request) được tối ưu qua bốn bài học "không có phép màu": DynamoDB, load balancer, cache, client . Cùng năm 2019, nền…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- eBay Công ty Thành viên
Hai bài về nhất quán và độ bền ở eBay: protocol GRIT (2019) cho giao dịch ACID xuyên microservice và nhiều DB bằng OCC + log + áp bất đồng bộ ; và các phương án chạy Kafka đa region khi event phải đúng thứ tự (2020),…
- 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…
- Grab Công ty Thành viên
Dùng AWS từ ngày đầu (MyTeksi 2012: Rails trên EC2 + RDS MySQL) và theo Grab chỉ cần dưới 10 kỹ sư vận hành nhờ managed service . Năm 2016 họ chuyển API hành khách từ Rails sang Go theo từng endpoint bằng shadow…
- Cloudflare Công ty Thành viên
Cloudflare bắt đầu bằng một cluster Postgres cfdb cho hầu hết control plane; từ 2017 các service dời dữ liệu ra dần. Đến 2022–2024 dữ liệu DNS (hàng tỷ record) được tách sang cluster riêng, sau khi mọi service đã đi qua…
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- Centrifuge: a reliable system for delivering billions of events per day Bài tóm tắt · Segment · 2018
…000 nguồn × trung bình 2,1 đích = 88.000 queue và còn tăng; Kafka, RabbitMQ, NSQ, Kinesis đều không scale tới số lượng đó một cách đơn giản. Thay đổi chính - Queue ảo trên database…
- 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à…
- The Events Rail: Inside Atlassian's Webhook Delivery Platform Bài tóm tắt · Atlassian · 2026
webhooks-processor ("events rail") đánh giá, ghép và giao event từ Jira, Confluence, Bitbucket tới app Forge, repository hook, endpoint audit log. Forge là consumer lớn nhất.
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…TTL hữu hạn để dọn bản ghi lệch (ví dụ lệnh xoá bị mất khi Kafka sự cố), cộng bootstrap định kỳ trong chu kỳ ngắn hơn TTL. - Chống lệch: ba bên cùng ghi cache (router, cache updat…
- 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ừ…