Cái này là SAGA Pattern, việc implement SAGA bằng RabbitMQ hay Kafka cái nào cũng được , thậm chí dùng RabbitMQ còn tốt hơn vì nó có cơ chế ACK cũng như cơ chế broker rất clear. Nhưng SAGA lý thuyết thì hay chứ khi vào thực tế xử lý rollback distributed transaction chưa bao giờ là dễ dàng cả, nhất là ở bước Payment ấy
@@khangoduc8675 họ áp dụng cả cách của chủ kênh chia sẻ, nhưng về vấn đề order thì buộc phải đồng bộ. không thể run bất đồng bộ được. Như tiki họ dùng ring buffer
@@khangoduc8675 riêng khâu order vẫn phải dùng đồng bộ bạn nhé, còn làm sao để tối ưu khâu order đồng bộ mà nhanh thì có keyword là ring buffer. Các khâu khác thì có thể dùng như video bạn chủ hướng dẫn.
Mn cho e hỏi trong kiến trúc microservice thương mại điện tử thì khi đặt hàng sẽ kiểu tra số lượng hàng trc hay số tiền có trc ạ.Hay nó sẽ làm đồng thời kiểu bắn message đến 1 topic rồi cả 2 service sock và pay sẽ nhận và check cùng lúc ạ.nếu check đồng thời thì khi trả về nó đag ở 2 topic thì sao đồng bộ dc ạ
25 - Section 25: Order Service Api (part 1) | czcams.com/video/rpoQjTm9In4/video.html 26 - Section 26: Order service Part 2 | Tiếp đến là Redis chuyên sâu - czcams.com/video/mswayRA-870/video.html
A cho e hỏi với e có kinh nghiệm 4 năm Java , giờ đang muốn switch qua NodeJS. Học xong khoá NodeJS của a thì có vô dự án thực tế chiến được chưa ạ ? Thank a
Chú cho con hỏi nếu một node bị lỗi thì có thể ACID của db sẽ ko đảm bảo thì làm thế nào ạ. Vd update cart OK nhưng update inventory thì Fail. Thì cái này có cách nào khác phục ko ạ. Với lại độ trễ khi nữa. Nếu response order trả về OK cái con gọi api lấy lại list cart thì có lúc nó sẽ không trả về đúng dữ liệu mới thì cái cách nào giảm thiểu hoac khắc phục ko ạ ( này mà mástẻr - slave thì độ trễ tăng nữa ). Xin chú giải đáp ạ
Trước tiên hiểu sâu về ACID: Section 110: LÀM CHỦ MYSQL - Nguyên tắc ACID, sự cô lập vs cơ chế trong transaction HIỂU SÂU czcams.com/video/ylidVS4HvtE/video.html
Khi sử dụng kafka thì bạn phải đánh đổi ACID, thay vào đó phải handle tính nhất quán của dữ liệu thủ công, bạn có thể tìm hiểu các khái niệm eventually consistent, event sourcing, saga pattern. Những kỹ thuật này được thường được sử dụng để đảm bảo tính nhất quán dữ liệu
Anh ơi, cho e hỏi nếu dùng API gateway bắn mess tới Kafka xong Service tương ứng sẽ xử lý theo design Event Driven, thay vì Gateway forward trực tiếp tới service đó thì có ổn không a nhỉ? Các Gateway như Kong hay Traefik đều chỉ forward trực tiếp thôi. E cám ơn
@@huytranuc8610tại nếu bạn dùng service đẩy thì lại tốn 1 step từ Gateway connect tới service đó. Này mình code thêm plugin tích hợp vào Gateway cho nó đẩy thẳng vào Kafka, thằng service phụ trách chỉ cần subscribe mess thôi. Làm như này thì Loose coupling rất cao và cũng dễ scale nữa, Kafka nó tự handle cả rồi Đó là cái mới mà mình đọc của mo hinh Event Driven API (có thể mới với mình thôi 😂)
Theo mình thì việc sử dụng Kafka hay RabbitMQ phụ thuộc vào yêu cầu của b: - Nếu ứng dụng của bạn đơn giản, chỉ cần giao tiếp đơn giản giữa các service với nhau bằng việc gửi các tin nhắn cơ bản thì theo mình rabbit quá dư thừa để bạn sử dụng. - Còn bạn cần xử lý dữ liệu lớn, hệ thống bạn phức tạp hay đơn giản là bạn muốn làm quen với một công nghệ mới hơn thì Kafka là lựa chọn dành cho bạn ===> Chung quy lại thì để trả lời được câu hỏi này bạn phải phân tích được là mình muốn gì trước r bám sát vào ưu điểm từng thằng r mình quyết định thôi ạ
dạ mô hình này mình đang follow kiểu pub sub thì a cho em hỏi nếu như mình dùng cluster nhiều node nhiều pod, instance nó cùng sub thì mình xử lý duplicate như thế nào anh ạ?
Cái này là SAGA Pattern, việc implement SAGA bằng RabbitMQ hay Kafka cái nào cũng được , thậm chí dùng RabbitMQ còn tốt hơn vì nó có cơ chế ACK cũng như cơ chế broker rất clear. Nhưng SAGA lý thuyết thì hay chứ khi vào thực tế xử lý rollback distributed transaction chưa bao giờ là dễ dàng cả, nhất là ở bước Payment ấy
tôi thấy saga chả khác gì truyền thống:))
Trong video này còn không áp dụng transactions thì lgi có saga ở đây :D
hay quá anh ơi, anh apply kafka vào go project luôn nha anh
Tất nhiên rồi hen
Em đang tìm hiểu về Kafka mong anh ra sớm video ạ.
Mô hình này đảm bảo website nhỏ thôi bạn. Mô hình săn sale kiểu 7/7 shopee CCU lớn gần như lỗi hoàn toàn. Đền voucher sập cty.
vậy theo anh thì những hệ thống lớn họ sẽ dùng gì để handling event?
website nhỏ là nhỏ cở nào bạn ?
@@khangoduc8675 họ áp dụng cả cách của chủ kênh chia sẻ, nhưng về vấn đề order thì buộc phải đồng bộ. không thể run bất đồng bộ được. Như tiki họ dùng ring buffer
@@khangoduc8675 riêng khâu order vẫn phải dùng đồng bộ bạn nhé, còn làm sao để tối ưu khâu order đồng bộ mà nhanh thì có keyword là ring buffer. Các khâu khác thì có thể dùng như video bạn chủ hướng dẫn.
🤣
tính ra e làm Kafka đc hơn 3 năm Outsource cho Nokia mà e còn chưa biết hết mấy cái này nữa @@
Giờ biết mà. Cố lên nào
Anh có thể làm video so sánh NAST vs RMQ vs Kafka đc không anh❤
Anh chưa có cơ hội làm về NATS em à...
Nats = kafka + rabbitmq + grpc, cực xịn xò nha
hóng tiếp ạ
ok bạn nhe
Mn cho e hỏi trong kiến trúc microservice thương mại điện tử thì khi đặt hàng sẽ kiểu tra số lượng hàng trc hay số tiền có trc ạ.Hay nó sẽ làm đồng thời kiểu bắn message đến 1 topic rồi cả 2 service sock và pay sẽ nhận và check cùng lúc ạ.nếu check đồng thời thì khi trả về nó đag ở 2 topic thì sao đồng bộ dc ạ
25 - Section 25: Order Service Api (part 1) | czcams.com/video/rpoQjTm9In4/video.html
26 - Section 26: Order service Part 2 | Tiếp đến là Redis chuyên sâu - czcams.com/video/mswayRA-870/video.html
Anh làm về kiểm thử database được không ạ
A cho e hỏi với e có kinh nghiệm 4 năm Java , giờ đang muốn switch qua NodeJS. Học xong khoá NodeJS của a thì có vô dự án thực tế chiến được chưa ạ ? Thank a
Vãi ông middle java lại switch qua NodeJS làm gì làm Junior từ đầu down lương thì sao
e thấy hay nha
anh ơi, để học khóa backend nodejs của anh cần nắm những kiến thức gì trước ạ, và trong khóa đấy có phải code FE không ạ ?
hiểu đọc hiểu code js, ko có code FE trong khoá này
@@letuan5069 e cảm ơn ạ
Chú cho con hỏi nếu một node bị lỗi thì có thể ACID của db sẽ ko đảm bảo thì làm thế nào ạ. Vd update cart OK nhưng update inventory thì Fail. Thì cái này có cách nào khác phục ko ạ. Với lại độ trễ khi nữa. Nếu response order trả về OK cái con gọi api lấy lại list cart thì có lúc nó sẽ không trả về đúng dữ liệu mới thì cái cách nào giảm thiểu hoac khắc phục ko ạ ( này mà mástẻr - slave thì độ trễ tăng nữa ). Xin chú giải đáp ạ
Trước tiên hiểu sâu về ACID: Section 110: LÀM CHỦ MYSQL - Nguyên tắc ACID, sự cô lập vs cơ chế trong transaction HIỂU SÂU
czcams.com/video/ylidVS4HvtE/video.html
Sau đó lấy ví dụ thanh toán làm thực tế mức cô lập trong db
Khi sử dụng kafka thì bạn phải đánh đổi ACID, thay vào đó phải handle tính nhất quán của dữ liệu thủ công, bạn có thể tìm hiểu các khái niệm eventually consistent, event sourcing, saga pattern. Những kỹ thuật này được thường được sử dụng để đảm bảo tính nhất quán dữ liệu
@@anonystick đạ cảm ơn chú.
@@VuTuanIT dạ cảm ơn Anh ạ. Cho em hỏi thêm với. Mấy app liên quan tới tiền như bank thì bắt buộc phải đảm bảo ACID hả Anh.
Anh ơi, cho e hỏi nếu dùng API gateway bắn mess tới Kafka xong Service tương ứng sẽ xử lý theo design Event Driven, thay vì Gateway forward trực tiếp tới service đó thì có ổn không a nhỉ?
Các Gateway như Kong hay Traefik đều chỉ forward trực tiếp thôi. E cám ơn
gateway thì làm đúng việc của cái tên nó là điều hướng thôi b, để service bên trong đẩy vào kafka nếu cần
@@huytranuc8610tại nếu bạn dùng service đẩy thì lại tốn 1 step từ Gateway connect tới service đó. Này mình code thêm plugin tích hợp vào Gateway cho nó đẩy thẳng vào Kafka, thằng service phụ trách chỉ cần subscribe mess thôi. Làm như này thì Loose coupling rất cao và cũng dễ scale nữa, Kafka nó tự handle cả rồi
Đó là cái mới mà mình đọc của mo hinh Event Driven API (có thể mới với mình thôi 😂)
Nên sử dụng kafka hay rabbitMQ vậy a
Theo mình thì việc sử dụng Kafka hay RabbitMQ phụ thuộc vào yêu cầu của b:
- Nếu ứng dụng của bạn đơn giản, chỉ cần giao tiếp đơn giản giữa các service với nhau bằng việc gửi các tin nhắn cơ bản thì theo mình rabbit quá dư thừa để bạn sử dụng.
- Còn bạn cần xử lý dữ liệu lớn, hệ thống bạn phức tạp hay đơn giản là bạn muốn làm quen với một công nghệ mới hơn thì Kafka là lựa chọn dành cho bạn
===> Chung quy lại thì để trả lời được câu hỏi này bạn phải phân tích được là mình muốn gì trước r bám sát vào ưu điểm từng thằng r mình quyết định thôi ạ
1 bên là message phức tạp (rabbitMQ) 1 bên là lượng message lên hàng tỷ
dạ mô hình này mình đang follow kiểu pub sub thì a cho em hỏi nếu như mình dùng cluster nhiều node nhiều pod, instance nó cùng sub thì mình xử lý duplicate như thế nào anh ạ?
nhiều node nhiều pod là sao nhỉ. Ý của bạn là pod của bạn scale trong cùng 1 instance hay sao ?
Kafka nó tự lo vấn đề này rồi, tùy vào cách sử dụng, nó mạnh lắm, tìm hiểu consumer group, topic, và partition nhé
@@tamleminh755 đúng rùi ạ, nhiều pod của service A chẳng hạn
@@tamleminh755 nhiều pod của 1 service ấy ạ, mà service ấy là consumer, thí dụ default là 1 khi mà scale lên 3 4 pod thì mình xử lý ntn ấy ạ
@@n0osp0m123 cho các pod vào trong cùng consumer group, kafka nó sẽ tự distribute messages đến các pod, ko bị duplicate khi consume message đâu.
❤❤❤❤
Thế còn click house thì sao a nhỉ nó với cái Kafka này cái nào ngon hơn
clickhouse tính chất nó là database mà bác, nó không chuyên về queue như cái này
anh lam khoa hoc java anh oi
Xong go đã nha em
NATS thì sao bác
Anh chưa có cơ hội làm về NATS em à...