A Kết quả phân loại câu hỏi môn KTLT và CTDL&GT
4.2 Các thành phần trong luồng chấm bài mới
4.1.3 Sử dụng phương thức giao tiếp bất đồng bộ mới - Kafka
Nhóm đánh giá cao giải pháp sử dụng mơ hình giao tiếp bất đồng bộ giữa thành phần Back- end và Grader trong hệ thống cũ (bước 1-3 trong hình 4.1). Do chấm bài là quá trình phải chịu tải từ số lượng lớn người dùng một cách liên tục nên không thể thiết kế theo hướng gửi lời gọi và trả kết quả về ngay (mơ hình giao tiếp đồng bộ), mà nên là gửi lời gọi và trả kết quả về sau (mơ hình giao tiếp bất đồng bộ) để khơng gây áp lực lên con chấm. Vì lẽ đó, thành phần Grader
mới sẽ tiếp tục được thiết kế theo hướng giao tiếp bất đồng bộ với thành phần Back-end nhằm mang lại hiệu năng chấm bài tốt nhất.
Nhóm cũng thực hiện phần thay đổi cho giao thức kết nối giữa Back-end và Grader để tối ưu hiệu năng hơn. Thông qua việc sử dụng Kafka làm giao thức kết nối, thay cho REST API như trước. Lý do là Kafka có thể đóng vai trị như một hàng đợi thơng điệp (message queue) hiệu năng cao (được giới thiệu tại mục 2.3.5), đáp ứng được nhu cầu tiếp nhận rất nhiều bài nộp của sinh viên cùng lúc mà vẫn giữ được thứ tự của chúng. Nhờ vậy, bài nộp nào được nộp trước sẽ được chấm trước, đảm bảo tính cơng bằng khi chấm bài cho sinh viên.
Nhóm nhận thấy trong q trình chấm bài cũ, nội dung bài nộp không được gửi kèm cùng với lời gọi chấm bài mà Grader phải gọi API sang Back-end một lần nữa để lấy được nội dung (bước 9 trong hình 4.1). Do vậy nhóm muốn tối ưu thêm bằng cách gửi kèm nội dung bài nộp trong lời gọi chấm bài để hạn chế số lượng lời gọi API ra ngoài Internet.
Với cách tối ưu trên, cấu trúc của một thơng điệp được gửi từ phía Back-end sang Grader để chấm bài như sau:
• question_id: Định danh cho câu hỏi, dùng cho bước lấy nội dung về câu hỏi khi cần.
• submission_id: Định danh cho bài nộp, dùng cho bước cập nhật điểm của bài nộp.
• submission_name: Tên của bài nộp, dùng trong lời gọi sang Jobe để chấm bài.
• submission: Nội dung của bài nộp.
Nội dung của câu hỏi khơng nằm trong cấu trúc trên vì đây là dữ liệu có thể tái sử dụng qua nhiều lần chấm bài. Do vậy, chỉ ở lần đầu tiên chấm bài cho một câu hỏi, Grader sẽ gọi API sang Back-end để lấy nội dung của câu hỏi và lưu vào bộ nhớ đệm để sử dụng cho lần sau mà không cần phải truyền lại trong mỗi thông điệp chấm bài.
4.1.4 Thay đổi nền tảng bộ nhớ đệm sang Redis
Xuyên suốt q trình chấm bài, hai thơng tin ít khi bị thay đổi là nội dung của câu hỏi và kết quả mong đợi của câu hỏi đó theo từng testcase. Do vậy, hai thơng tin này nên được lưu trong bộ nhớ đệm để tiết kiệm thời gian chấm bài. Với nội dung của câu hỏi, việc caching giúp hạn chế số lần lấy nội dung câu hỏi từ phần Back-end. Cịn về kết quả mong đợi thì việc caching sẽ giúp quá trình so sánh kết quả chấm bài với kết quả mong đợi được nhanh hơn.
Nhóm sẽ sử dụng Redis như là nền tảng caching của hệ thống, vì đây là một trong những giải pháp caching có hiệu năng tốt và được sử dụng phổ biến trong thực tế (đã được giới thiệu ở 2.3.4).
4.1.5 Kết quả sau khi cải thiện
Luồng thực hiện quá trình chấm bài sử dụng con chấm mới là Jobe, và ứng dụng thêm các giải pháp mới như Kafka và Redis được mô tả lại như 4.3.
Chi tiết như sau luồng chấm bài mới như sau:
• Bước 1 - 2:Grader nhận lời gọi chấm bài từ Back-end thơng qua Kafka.
• Bước 3 - 7: Grader kiểm tra nội dung của câu hỏi đã có trong Redis hay khơng. Nếu khơng thì gọi sang Back-end để lấy nội dung rồi cache lại trong Redis để sử dụng ở lần chấm bài sau.
• Bước 8 - 12:Grader kiểm tra trên Redis về kết quả kỳ vọng của testcase. Nếu không xuất hiện, Grader sẽ tiến hành chấm bài dựa theo lời giải của người dạy. Sau đó, Grader lưu lại kết quả này để so sánh với lần chấm bài kế tiếp mà không phải chấm lại lời giải.
• Bước 13 - 17:Grader tiến hành chấm bài theo bài nộp của sinh viên. Sau khi có kết quả chấm bài từ Jobe, Grader sẽ so sánh với kết quả mong đợi ở bước 8 - 12 để cho ra kết quả của bài nộp theo testcase.
• Các bước 8 - 12 và 13 - 17 sẽ được lặp lại theo số lượng testcase của câu hỏi.
• Bước 18:Grader sẽ tổng hợp điểm theo các testcase nhằm cho ra kết quả cuối cùng của bài nộp.