Tìm kiếm
40 kết quả cho “Lua”. Tìm không phân biệt dấu.
- Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production Bài tóm tắt · Booking.com · 2015
…[bài gốc](https://medium.com/booking-com-infrastructure/evaluating-mysql-parallel-replication-part-3-benchmarks-in-production-db5811058d74) Phần 3 của series "Evaluating MySQL Par…
- Evaluating MySQL Parallel Replication Part 2: Slave Group Commit Bài tóm tắt · Booking.com · 2015
…[bài gốc](https://medium.com/booking-com-infrastructure/evaluating-mysql-parallel-replication-part-2-slave-group-commit-459026a141d2) Phần 2 của series "Evaluating MySQL Parallel…
- Evaluating MySQL Parallel Replication Part 4: More Benchmarks in Production Bài tóm tắt · Booking.com · 2016
…[bài gốc](https://medium.com/booking-com-infrastructure/evaluating-mysql-parallel-replication-part-4-more-benchmarks-in-production-49ee255043ab) Phần 4 của series; phần trước: . A…
- A lesson in creating and using niche business DSLs at scale Bài tóm tắt · Zerodha · 2020
…ng trước tên là Veto : một reverse proxy kiểm tra lệnh theo luật động do đội quản trị rủi ro (RMS) đặt, từ chối ngay tại chỗ hoặc chuyển tiếp lên OMS. Lệnh bị từ chối không bao giờ…
- How we migrated Dropbox from Nginx to Envoy Bài tóm tắt · Dropbox · 2020
…loy lại; phần động (quản lý upstream, xuất stats) viết bằng Lua; logic phức tạp đẩy xuống tầng proxy Go phía sau ( Bandaid ). - Không còn hợp cách làm hiện tại: API chuyển từ REST…
- How we're building Scam Alert on WhatsApp Bài tóm tắt · WhatsApp · 2026
…security/how-were-building-scam-alert-whatsapp/) Bối cảnh - Lừa đảo chuyển từ mạo danh sang social engineering và mồi nhử do AI tạo. Server không đọc được tin (E2EE), nên không thể…
- Making the LinkedIn experimentation engine 20x faster Bài tóm tắt · LinkedIn · 2020
…g 35.000 thí nghiệm chạy cùng lúc , tới 23 nghìn tỷ lượt evaluate/ngày , latency trung bình 700 ns (p99 3 µs), dùng trong khoảng 500 service production. - Lix Engine là thư viện ch…
- Timestone: Netflix's High-Throughput, Low-Latency Priority Queueing System Bài tóm tắt · Netflix · 2022
…r) nằm cùng một shard nhờ hash tag. Gần như mọi thao tác là Lua script (Redis chạy nguyên tử). Mọi API đổi trạng thái là idempotent. - Index phụ cho quan sát: sau khi Redis trả lời…
- How we built a real-time service that handles 20,000 updates per second Bài tóm tắt · Trigger.dev · 2025
…ết nối đồng thời) bằng sliding window trong Redis viết bằng Lua (sorted set, xoá mục hết hạn, thêm, đếm, vượt thì gỡ), chạy nguyên tử nên không race; mỗi mục hết hạn sau 5 phút. -…
- Building High Throughput Payment Account Processing Bài tóm tắt · Uber · 2026
…RPC, gom theo tài khoản vào lô có hạn thời gian bằng script Lua nguyên tử trên Redis , đẩy task vào hàng đợi Redis, trả kết quả cho client từ cache kết quả trên Redis. Batch Proces…
- A postmortem of three recent issues Bài tóm tắt · Anthropic · 2025
Anthropic phục vụ Claude qua API của mình, Amazon Bedrock và Google Vertex AI, trên ba loại phần cứng (AWS Trainium, GPU NVIDIA, TPU Google). Mỗi nền tảng cần tối ưu riêng nhưng phải cho kết quả tương đương, nên mọi…
- Maintaining Machine Learning Model Accuracy Through Monitoring Bài tóm tắt · DoorDash · 2021
Model của DoorDash ước thời gian nấu, thời gian giao, quyết định giao đơn nào cho Dasher. Theo DoorDash, model bắt đầu xuống cấp ngay khi lên production (model drift) vì dữ liệu đổi: thêm khách, thêm sản phẩm, hay sự…
- KernelEvolve: How Meta's Ranking Engineer Agent Optimizes AI Infrastructure Bài tóm tắt · Meta · 2026
Fleet phần cứng của Meta không đồng nhất: GPU NVIDIA, GPU AMD, chip MTIA tự làm (4 thế hệ trong 2 năm), CPU. Mỗi phép toán của model phải có kernel tối ưu cho từng chip; số kernel = {loại và thế hệ phần cứng} × {kiến…
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọ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…
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- 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".
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- 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…
- 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.
- 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ả…
- 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.
- 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…
- 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ỡ:
- 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…
- 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:
- 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:
- 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…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí 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:
- 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:
- 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…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Mô hình tổ chức SRE Chủ đề
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn…