Tách dữ liệu nóng và lạnh là gì?

Tách dữ liệu nóng và lạnh là chiến lược kiến trúc phân loại dữ liệu thành dữ liệu lạnh và dữ liệu nóng dựa trên tần suất truy cập và mức độ quan trọng với nghiệp vụ, sau đó lưu trữ chúng trên các storage medium có performance và chi phí khác nhau.

Deep pagination là gì? Vì sao xảy ra?

Tình huống offset truy vấn quá lớn được gọi là deep pagination. Điều này khiến hiệu năng truy vấn thấp, ví dụ:

# MySQL bỏ qua 1000000 bản ghi rồi lấy 10 bản ghi tiếp theo khi không thể sử dụng index
SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10

Load balancing là gì?

Load balancing là việc phân phối request của người dùng đến các server khác nhau để xử lý, nhằm nâng cao năng lực xử lý đồng thời và độ tin cậy tổng thể của hệ thống. Dịch vụ load balancing có thể do phần mềm hoặc phần cứng chuyên dụng đảm nhiệm. Thông thường, phần cứng có performance tốt hơn, còn phần mềm có giá rẻ hơn (sẽ giới thiệu chi tiết ở phần sau).

Tách đọc ghi

Tách đọc ghi là gì?

Tách đọc ghi chủ yếu nhằm phân tán thao tác đọc và thao tác ghi của database đến các node database khác nhau. Write request vẫn đi vào primary database, read request được phân bổ cho một hoặc nhiều read-only replica, vì vậy lợi ích chính là nâng cao khả năng mở rộng đọc của database. Chỉ khi primary database vốn bị nhiều read request làm chậm thì việc chuyển read traffic ra ngoài mới có thể gián tiếp giúp write path.

SQL chậm thì đừng vội áp dụng các quy tắc như “thêm index”, “không dùng SELECT *”. Trước hết hãy tìm slow SQL, xem nó chậm do số dòng scan, sorting, đọc lại bảng, lock wait hay tần suất gọi quá cao. Sau khi đối chiếu execution plan với cách truy cập của nghiệp vụ, mới quyết định sửa index, SQL, cấu trúc bảng hay chuyển query sang cache, search engine hoặc báo cáo offline.

Message queue là middleware rất phổ biến trong các hệ thống high-performance và high-availability, chủ yếu dùng để xử lý asynchronous, decoupling ứng dụng, giảm đỉnh tải và buffer traffic. Khi học message queue, không thể chỉ ghi nhớ các tính năng của Kafka, RocketMQ, RabbitMQ mà còn phải hiểu độ tin cậy, tính thứ tự, idempotent, cách xử lý backlog và lựa chọn công nghệ.

Disruptor là một chủ đề tương đối ít phổ biến. Tuy nhiên, nếu dự án của bạn có sử dụng Disruptor thì bạn rất có thể sẽ được hỏi về nó trong phỏng vấn.

Một bài chia sẻ kinh nghiệm phỏng vấn trước đây của một độc giả cũng có đề cập đến một số câu hỏi về Disruptor: Mơ ước thành hiện thực! Thuận lợi nhận offer từ ByteDance, Taobao, Pinduoduo và các công ty lớn khác! .

“RabbitMQ?” “Kafka?” “RocketMQ?”... Trong quá trình học tập và phát triển hằng ngày, chúng ta thường nghe đến keyword message queue. Tôi cũng đã đề cập đến khái niệm này trong nhiều bài viết. Có thể bạn là người đã thành thạo message queue, hoặc là người mới chưa hiểu message queue. Dù bạn đã biết hay chưa, bài viết này sẽ giúp bạn nắm được một số lý thuyết cơ bản về message queue.

Hiện nay không thể chỉ chuẩn bị RabbitMQ theo đáp án cũ kiểu “Exchange + Queue”. RabbitMQ 4.0 đã loại bỏ mirror queue; khi cần replication và high availability, trọng tâm là Quorum Queue; khi cần kiểu lưu trữ log, replay lịch sử hoặc xử lý lượng message tồn đọng lớn, hãy đánh giá Streams.

Bài viết này giới thiệu RabbitMQ 4.x mới nhất làm trọng tâm, đồng thời giữ lại vấn đề mirror queue vẫn có thể gặp trong các cluster 3.x cũ. Hãy tập trung vào bốn điểm: mô hình AMQP hoạt động thế nào, Exchange định tuyến ra sao, bảo đảm độ tin cậy của message thế nào, và nên chọn Classic Queue, Quorum Queue hay Streams ra sao.