Khả năng mở rộng và hiệu năng hệ thống lưu trữ lên 1 triệu user

Khả năng mở rộng

Hệ thống hoạt động ổn định hôm nay không đồng nghĩa với việc nó sẽ hoạt động ổn định trong tương lai. Một lí do đơn giản cho nhận xét này vì theo thời gian tải của hệ thống cũng sẽ tăng lên. Trang web có 10000 user truy cập đồng thời hôm nay nhưng tương lai số lượng người truy cập có thể tăng lên 100.000, 1.000.000 user truy cập cùng lúc, kéo theo đó là lượng dữ liệu cần xử lý sẽ tăng. Lúc này, hệ thống hiện tại sẽ không còn đáp ứng được yêu cầu xử lý.

Khả năng mở rộng là khả năng hệ thống có khả năng ứng phó với lượng tải tăng. Việc này có thể xử lý bằng việc tăng tài nguyên trên một máy chủ hoặc mở rộng dịch vụ chạy trên nhiều máy chủ đồng thời.

Để đánh giá khả năng mở rộng của hệ thống có thể dựa vào một số yếu tố: số lượng request / giây đến server, tỉ lệ đọc bản ghi đến CSDL, số lượng user đồng thời có thể truy cập, tỉ lệ đọc trúng bản ghi trong cache,…

>> Lý thuyết thuật toán tìm kiếm theo chiều rộng BFS bằng C/C++ và Java

>> Lý thuyết về thuật toán quay lui Back Track

Lấy ví dụ với trường hợp của Twitter khi cần xử lý các dòng tweet của user. Có 2 hành động chính cần xử lý ở phía server:

• Post tweet: user có thể publish một message mới đến những user khác đang follow họ (4.6k requests/s, up to 12k requests/s)
• Home timeline: user có thể tweet lại các bài post từ những người mà họ đang follow (300k requests/s)

Giả sử ở trường hợp lượng tải lên cao nhất 12k requests/s. Hệ thống cần xử lý không chỉ lượng tweets này mà còn liên quan đến việc những user khác sẽ nhận được thông báo và có thể tweet lại làm cho số lượng requests sẽ tăng lên nhiều lần. Có 2 cách để xử lý trường hợp này:

• Insert một bản ghi vào database khi có một tweet mới được tạo. Khi user truy cập vào feed, tìm tất cả bài post của các user mà đang follow, sort lại theo time và trả ra cho feed của user:

SELECT tweets.*, users.* FROM tweets
JOIN users ON tweets.sender_id = users.id 
JOIN follows ON follows.followee_id = users.id 
WHERE follows.follower_id = current_user

• Thay vì insert và select từ database như cách một, hệ thống sẽ sử dụng một cache để lưu trữ timeline của mỗi user. Cache này sẽ lưu trữ những tweet phù hợp với từng user. Khi user gửi đăng một dòng tweet, tìm tất cả những user đang follow, insert tweet này vào cache timeline của từng user. Requests để đọc đến cache sẽ nhanh hơn nhiều so với việc đọc từ RDBMS do logic đã được tính toán sẵn từ trước và lưu vào cache.

Cách tiếp cận thứ hai có hiệu quả tốt hơn trong trường hợp tỉ lệ publish tweet mới thấp hơn so với tỉ lệ user mở timeline để đọc. Tuy nhiên, các tiếp cận thứ hai yêu cầu nhiều về mặt xử lý hơn. Tổng lượng tweet cần deliver từ user đến những người đang follow họ rất lớn, đặc biệt là nhóm người nổi tiếng.

Để xử lý vấn đề này cần phân tích được phân phối số lượng người follow trên từng user, đây là tham số chính để xác định phương án chịu tải và mở rộng của hệ thống. Twitter sử dụng kết hợp cả hai cách tiếp cận trên. Hầu hết những user có số lượng người follow thấp sẽ sử dụng cache để deliver. Đối với những user nhưng KOLs sẽ sử dụng cách insert trực tiếp vào database, do số lượng người follow lớn, thời gian để deliver bằng cách 2 sẽ chậm.

Hiệu năng

Để đánh giá lượng tải của hệ thống có thể dựa vào 2 cách:

• Tăng tham số tải, giữa nguyên cấu hình tài nguyên (CPU, memory, băng thông)
• Tăng tham số tải, kiểm tra hệ thống hiện tại cần thay đổi như thế nào để đáp ứng được nhu cầu

Trong hệ thống xử lý dữ liệu theo batch như hadoop, cần quan tâm đến thông lượng nghĩa là số bản ghi có thể xử lí/s hoặc tổng thời gian cần để xử lí hết một lượng dữ liệu. Trong các hệ thống online, cần quan tâm thêm một yếu tố nữa đó là thời gian phản hồi – response time – khoảng thời gian từ khi client gửi request đến server đến khi nhận được phản hồi.

Lưu ý phân biệt độ trễ và thời gian phản hồi. Độ trễ là khoảng thời gian một request phải đợi đến khi được server tiếp nhận để xử lý.

Ngoài thời gian phản hồi trung bình của một service, ta còn có thêm đại lượng percentiles để đánh giá hiệu năng. Thời gian trung bình không phải ánh được có bao nhiêu request đạt được thời gian phản hồi như yêu cầu. Một đại lượng khác được sử dụng phản ảnh chính xác hiệu năng của hệ thống hơn đó là số trung vị (median).

Percentiles sẽ chia thống kê thời gian phản hồi thành 2 phần, số trung vị là giá trị thời gian phản hồi ở giữa, một nữa số request sẽ có response time < trung vị, nửa còn lại lớn hơn. Giá trị percentiles tại x (s) = pn được hiểu là n phần trăm số lượng request có response time < x, kí hiệu pn. Ví dụ p95 tại 200ms tức là có 95% số lượng request có time response < 200ms.