DISCUSSIONS

hiện tại có 3 cách để làm em nhé:

  1. polliing publíher: chính là relay publisher ở trên, nó hiệu quả với bài toán k cần real-time, và lượng event ít.
  2. transaction log tailing: e có thể tham khảo debezium nhé, idea là nó read file transaction log để build event
  3. publish id: e publish trước event id sang 1 service khác, service khác đó sẽ read data từ db với id đó để publish. phải impl thêm retry hoặc cancel eventid...
0
Avatar
commented to answer in the question
Thursday, 12:55 a.m.

theo mình khởi đầu thì có thể tham khảo Factory Method hoặc Builder Method, 2 cái này đều dùng cho khởi tạo khá dễ áp dụng trong các dự án, ko rõ cụ thể bạn đang làm với công nghệ nào nhỉ

0

Hay quá a. Nhưng mà e thấy quả SAGA pattern này hâu như phải implement bằng cơm 😄 và cũng vất vả để apply nó một cách ngon nghẻ . Như chỗ e hiện tại nó đang nở ra tận mấy chục con microservice mà tất cả service đấy muốn apply saga thì đúng vỡ mồm thật. 😄

0

À e có thêm 1 thắc mắc nữa ạ. Ví dụ e sử dụng Orchestration -> sau khi e thanh toán xong, cộng trừ tiền các kiểu cho khách rồi, lưu vào DB luôn rồi, khách hàng đã thấy trên máy mình đã bị trừ tiền rồi.(tức là transaction ở paymentService đã được commit, và đóng rồi) -> sau đến nhà bếp service thì hết nguyên liệu thì nhà bếp bắn ra lỗi cho orchestration -> sau đấy orchestration trigger cho paymentService là không có nguyên liệu làm , mày trả lại tiền cho người ta đi -> thì chỗ này thằng paymentService phải lấy thông tin đâu ra để rollback lại ạ. (vì e nghĩ là paymenService và nhà bếp service sẽ là 2 localTransaction khác nhau). Liệu lúc save hay update dữ liệu có nên tạo ra 1 bản backup hay không -> nếu tạo thì sẽ có phải là bảng nào nằm trong vùng quản lý orchestration cũng phải tạo 1 bảng backup hay không. E cảm ơn.

0

e có câu hỏi như này ạ. Ở chỗ paymentService , sau khi thực hiện bussiness thanh toán tiền xong -> thì lưu thông tin thanh toán vào DB và đồng thời lưu vào out_box table (cả 2 thằng save này đều ngon nghe). Thì ở chỗ này tiếp theo a sẽ publish message lên kafka (xem như là mình đã chọn kafka làm message broker) để thằng relay publisher sẽ consumes. hay là a sẽ tạo schedule tại relay publisher để quét những message đã được lưu ạ. Thanks a vì những bài viết hay như thế này ạ.

0

Cảm ơn bác đã chia sẻ nhá. Thoạt nhìn bài toán có vẻ đơn giản nhưng làm thì thấy cũng rối rắm lắm. Bữa mình code mà k note rõ các trường hợp ra, sai tè le luôn

0
Wednesday, 2:36 p.m.

đỉnh quá

0

Series rất hay, cảm ơn bác nhiều.

0

"Bàn giao muộn và các phần chưa được hoàn thành là những dấu hiệu cho thấy tốc độ quá nhanh hoặc có quá nhiều việc phải thực hiện. Kết thúc sớm có nghĩa là tốc độ đang quá chậm hoặc team có khả năng hơn và không gặp thách thức nào."

Đoạn này nghe mâu thuẫn quá. 😃

0
Wednesday, 9:44 a.m.

Anh cho e xin source chall friends được k ạ?

0
Avatar
commented to answer in the question
Wednesday, 9:04 a.m.

mình cũng có xem qua 1 số Design Pattern nhưng vẫn chưa hiểu nó apply vào code như nào

0
Wednesday, 8:39 a.m.

Copy nguyên translate của dev.mysql

0
Wednesday, 7:12 a.m.

tks

0
Wednesday, 7:01 a.m.

tks

0
Wednesday, 4:11 a.m.

thanks

0
Wednesday, 3:36 a.m.

thanks

0

em xin phép share bài nhé ạ, cảm ưn anh :3

+1

Tóm lại biên dịch là interpreter hay compiler? Thông dịch là interpreter hay compiler?

0
Viblo
Let's register a Viblo Account to get more interesting posts.