Thư Viện Câu Hỏi Phỏng Vấn

Mô hình lập trình WebSockets dựa hoàn toàn trên sự kiện (Event-driven). Phía Client phải tương tác với Server thông qua việc lắng nghe các sự kiện đến và gửi đi các hành động khi có sự kiện từ người dùng.

Khi kiểm thử ứng dụng WebSockets ở môi trường phát triển cục bộ (Localhost), độ trễ mạng gần như bằng không và kết nối luôn ổn định. Tuy nhiên, khi đưa lên môi trường thực tế, các vấn đề về mạng không ổn định sẽ bộc lộ.

Bảo mật là yếu tố tối quan trọng. Một WebSocket server không được bảo vệ sẽ cho phép bất kỳ ai kết nối và gửi nhận tin nhắn, dẫn đến các lỗ hổng nghiêm trọng như giả mạo tin nhắn hoặc tấn công tràn bộ nhớ.

Bản chất cơ chế

• Lazy Loading: Là cơ chế mặc định của Active Record. Dữ liệu chỉ được truy vấn từ cơ sở dữ liệu khi bạn thực sự gọi đến thuộc tính của đối tượng đó. Điều này giúp tiết kiệm bộ nhớ nhưng dễ dẫn đến vấn đề N+1 queries.
• Eager Loading: Là kỹ thuật tải trước các dữ liệu liên quan (associations) ngay từ đầu bằng cách sử dụng các phương thức như includes, preload, hoặc eager_load.

Khi nào nên sử dụng

• Sử dụng Lazy Loading: Khi bạn chỉ cần truy xuất dữ liệu của một đối tượng đơn lẻ hoặc các điều kiện logic phức tạp khiến việc tải trước dữ liệu trở nên lãng phí.
• Sử dụng Eager Loading: Khi bạn hiển thị danh sách (collection) và cần truy cập vào các bảng liên quan (ví dụ: User có nhiều Posts).

Ví dụ code

# Lazy Loading (Dễ gây N+1)
users = User.limit(10)
users.each { |user| puts user.posts.count }

# Eager Loading (Tối ưu)
users = User.includes(:posts).limit(10)
users.each { |user| puts user.posts.count }

Lưu ý thực chiến

Luôn sử dụng gem bullet trong môi trường phát triển để tự động phát hiện các truy vấn N+1 mà bạn vô tình tạo ra.

Tại sao là anti-pattern

• Khó kiểm soát luồng: Các callback như after_save hoặc before_create chạy ngầm, khiến việc debug trở nên khó khăn khi logic nghiệp vụ thay đổi.
• Vi phạm nguyên tắc Single Responsibility: Model trở nên quá cồng kềnh (Fat Model) khi chứa quá nhiều logic nghiệp vụ không liên quan trực tiếp đến dữ liệu.
• Khó khăn khi Testing: Các callback chạy tự động mỗi khi lưu dữ liệu, gây khó khăn cho việc cô lập unit test.

Cách khắc phục

• Service Objects: Chuyển logic nghiệp vụ vào các Service Objects để xử lý các tác vụ phức tạp.
• Form Objects: Sử dụng Form Objects để xử lý dữ liệu đầu vào và các logic validation trước khi lưu vào cơ sở dữ liệu.
• Pub/Sub hoặc Observers: Sử dụng các cơ chế sự kiện (Event-driven) để tách biệt các tác vụ phụ (như gửi email, thông báo) ra khỏi luồng lưu dữ liệu chính.

Lưu ý thực chiến

Chỉ nên sử dụng callback cho các logic liên quan trực tiếp đến tính toàn vẹn của dữ liệu trong chính model đó (ví dụ: format lại email trước khi lưu).

Vai trò của các file

• Gemfile: Định nghĩa danh sách các thư viện (gems) mà ứng dụng cần. Nó cho phép chỉ định phiên bản linh hoạt (ví dụ: gem 'rails', '~> 7.0').
• Gemfile.lock: Là bản ghi chính xác về phiên bản của tất cả các gem và các gem phụ thuộc (dependencies) đang được sử dụng trong môi trường hiện tại.

Tại sao phải commit cả hai

• Tính nhất quán: Đảm bảo rằng mọi thành viên trong đội ngũ phát triển và môi trường Production đều sử dụng chính xác cùng một phiên bản gem, tránh lỗi 'trên máy tôi chạy được nhưng trên server thì không'.
• Tính tái lập: Giúp việc triển khai (deployment) trở nên tin cậy, vì hệ thống sẽ cài đặt đúng các phiên bản đã được kiểm thử kỹ lưỡng.

Lưu ý thực chiến

Không bao giờ chỉnh sửa trực tiếp Gemfile.lock. Hãy luôn sử dụng lệnh bundle install hoặc bundle update để hệ thống tự động cập nhật file này.

Phân tích chi tiết

Các rủi ro

• Locking: Các lệnh như ALTER TABLE có thể khóa bảng, khiến ứng dụng không thể đọc/ghi dữ liệu, gây downtime.
• Thời gian thực thi: Migration quá lâu có thể gây lỗi timeout trên hệ thống triển khai.

Chiến lược an toàn

• Sử dụng strong_migrations: Gem này giúp ngăn chặn các lệnh migration nguy hiểm (như thêm cột với giá trị mặc định trên bảng lớn).
• Chia nhỏ migration: Thay vì thực hiện một thay đổi lớn, hãy chia thành nhiều bước (ví dụ: thêm cột, cập nhật dữ liệu theo từng batch, sau đó mới đặt ràng buộc NOT NULL).
• Online Schema Change: Sử dụng các công cụ như gh-ost hoặc pt-online-schema-change để thay đổi cấu trúc bảng mà không làm khóa bảng.

Lưu ý thực chiến

Luôn kiểm tra thời gian thực thi migration trên môi trường staging có dữ liệu tương đương với production trước khi áp dụng thực tế.

Bản chất của Redis

Redis viết tắt của Remote Dictionary Server, là một hệ thống mã nguồn mở hoạt động theo mô hình lưu trữ cấu trúc dữ liệu trong bộ nhớ (in-memory data structure store). Nó có thể được sử dụng như một cơ sở dữ liệu, bộ đệm (cache), và trình quản lý hàng đợi thông điệp (message broker).

Phân biệt String và Hash trong Redis

1. Redis String

• Định nghĩa: Là cấu trúc dữ liệu cơ bản nhất trong Redis, lưu trữ một chuỗi dữ liệu nhị phân an toàn (binary-safe), có thể chứa văn bản, số nguyên, số thực hoặc hình ảnh (tối đa 512MB).
• Trường hợp sử dụng: Thường dùng để lưu trữ các giá trị đơn lẻ như token xác thực, bộ đếm lượt truy cập, hoặc cấu hình dạng thô.

2. Redis Hash

• Định nghĩa: Là tập hợp các cặp trường và giá trị (field-value pairs) nằm trong một key duy nhất. Ví dụ, một Hash đại diện cho một người dùng có thể chứa các trường như name, age, email.
• Trường hợp sử dụng: Rất phù hợp để đại diện cho các đối tượng (objects) có nhiều thuộc tính.

Khi nào nên chọn Hash thay vì String?

• Tiết kiệm bộ nhớ: Khi lưu trữ một đối tượng có nhiều thuộc tính (ví dụ thông tin người dùng: id, username, status), nếu dùng String, bạn có thể phải tạo nhiều key (user:1:name, user:1:email) hoặc serialize toàn bộ đối tượng thành một chuỗi JSON. Việc tạo nhiều key sẽ tốn kém chi phí bộ nhớ phụ cho cấu trúc quản lý key của Redis. Sử dụng Hash giúp gom nhóm các thuộc tính vào một key duy nhất, tối ưu hóa đáng kể dung lượng RAM.
• Cập nhật một phần tử dễ dàng: Hash cho phép bạn đọc hoặc ghi một field cụ thể (ví dụ dùng lệnh HGET hoặc HSET) mà không cần phải đọc và giải mã (deserialize) toàn bộ đối tượng như khi lưu dưới dạng chuỗi JSON.

Ví dụ thực tế

Thay vì lưu JSON string: SET user:1000 '{"name":"Nguyen Van A","age":25}' Bạn nên dùng Hash: HSET user:1000 name "Nguyen Van A" age 25

Cơ chế hoạt động của lệnh EXPIRE

Lệnh EXPIRE được sử dụng để thiết lập thời gian sống (Time To Live - TTL) cho một key cụ thể tính bằng giây. Khi thời gian này kết thúc, key đó sẽ tự động bị xóa khỏi Redis.

Bản chất mô hình Single-threaded của Redis

Mặc dù các phiên bản Redis gần đây có sử dụng các luồng phụ (background threads) cho một số tác vụ nặng như giải phóng bộ nhớ (lazy freeing) hay I/O phụ trợ, nhưng cốt lõi xử lý các câu lệnh (command execution engine) của Redis vẫn chạy hoàn toàn trên một luồng chính duy nhất (single-threaded event loop).

Sử dụng Redis List làm Message Queue

Redis cung cấp cấu trúc dữ liệu List với các lệnh hỗ trợ thao tác đẩy và lấy dữ liệu ở hai đầu danh sách (Left và Right), rất phù hợp để xây dựng mô hình hàng đợi Producer-Consumer đơn giản.

Việc sử dụng hàm ẩn danh (ví dụ: renderItem={() => }) trong FlatList khiến hàm này được tạo mới sau mỗi lần render của component cha. Điều này dẫn đến việc FlatList luôn coi item đó là thay đổi, kích hoạt quá trình re-render không cần thiết cho toàn bộ danh sách, gây giật lag (jank).

Để tối ưu hóa kích thước bundle, bạn cần thực hiện các bước sau: