@Madafaker đang dùng database gì? Dữ liệu này bị mất giữa chừng có ảnh hưởng gì không?
Có nhiều cách để giải quyết vấn đề đồng thời cùng đọc/ghi dữ liệu. Mình giới thiệu 2 cách đơn giản với giả định là bạn đang dùng RBDMS và dữ liệu bị mất giữa chừng là nguy hiểm.
Bây giờ mình gọi
-
nhóm server con có nhiệm vụ chuyên tạo 1 mã dữ liệu nào đó sau đó lưu mã này vào database là producer
-
nhóm server con khác có nhiệm vụ get các mã trên ra xử lý là consumer
Cách 1: consumer đọc dữ liệu được chỉ định
Với mỗi producer, mình cấp cho nó 1 id là số int, 1, 2, 3, 4
Với mỗi consumer, mình cũng cấp cho nó 1 id là số int, 1, 2, 3, 4
consumer chỉ đọc dữ liệu của producer có cùng id
Ưu điểm:
Nhược điểm
- Nếu consumer cụ thể chết, ví dụ 2 chết, thì dữ liệu được ghi ra bởi producer 2 sẽ không có ai đọc
Cách giải quyết:
- Cần có một monitor để kiểm tra mỗi x phút xem thử consumer hay producer nào chết và recover
Cách 2: Lock on read
producer cứ write dữ liệu vào db
consumer khi read một mã nào đấy, sẽ lock table lại, đọc dữ liệu xong đánh dấu mã này đã được đọc và đang được xử lý bởi consumer id nào đấy
dữ liệu trước khi đọc
foo | process_by | status
bar | -1 | pending
Dữ liệu sau khi đọc
foo | process_by | status
bar | 7 | processing
7 ở đây là id của consumer
Dữ liệu sau khi xử lý xong
foo | process_by | status
bar | 7 | Done hoặc Failed
Ưu điểm:
- dễ cài đặt
- nếu một hoặc vài consumer chết thì cũng không phải là vấn đề lớn
Nhược điểm
- Nếu có quá nhiều consumer thì sẽ làm cho việc đọc/ghi bị chậm lại do lock/unlock quá nhiều
Cách giải quyết:
- Cần có một monitor để kiểm tra mỗi x phút xem thử consumer hay producer nào chết và recover
Ví dụ như nếu consumer 2 đang process dữ liệu thì lăn ra chết, phải lên db sửa lại cái status của db thành process_by = -1 và status = pending để consumer khác vào process data đó
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?