Vấn đề đồng độ dữ liệu giữa các server?

Người ta gọi đó là service broker nhé bạn.

@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:

• dễ cài đặt

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 đó

cảm ơn anh đạt cách 2 của anh giống với cách em đang tính làm … em sẽ tạo 1 thằng moniter để liên tục quan sát và kiểm tra hoạt động của mấy server kia … vì em tính làm server nhỏ tầm 20 node con trở lại nên chắc làm cách này là ổn rồi …

Có một hướng giải quyết khác cho bài toán của bạn, cách lock table là cách không hiệu quả và dễ xảy ra deadlock, không đáp ứng được cho các môi trường throughput cao. Bạn có thể dùng RabbitMQ để phân phối tác vụ các producer sẽ pub tác vụ, RabbitMQ sẽ phân phối tác vụ cho các consumer luôn đảm bảo 1 consumer sẽ xử lý 1 tác vụ (tham khảo idea Work Queues của RabbitMQ).

vâng em sẽ thử cả 2 phương án …