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
Cái này chẳng liên quan đến Kafka hay kiến trúc truyền thống gì cả, cái này liên quan đến tư duy. Có những process có thể xử lý trong thời gian dài mà không cần trả kết quả ngay lập tức. Xử lý đơn hàng là một trong những process đó: khách hàng xác nhận đơn hàng, hệ thống trả về "đơn hàng đang được xử lý, chúng tôi sẽ thông báo cho bạn trong thời gian sớm nhất". Và việc thêm tính năng mới cũng chẳng liên quan đến sức mạnh của Kafka. Trong ví dụ của trên video chỉ là một trường hợp thêm tính năng bằng cách replay các event, một việc mà hầu hết các event store đều làm được, không riêng gì Kafka, và có thể áp dụng cho kiến trúc truyền thống. Khác biệt là ở tư duy, không phải ở công nghệ.
@@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.
Em có 1 thắc mắc, là nếu mình đẩy vào quee như vậy nếu 1 step trong order nó failed thì các service trước đó cũng phải update lại phải không anh. Ví dụ một trước lúc "do payment" thì mình có 1 bước là "update inventory" vậy nếu mình bị failed ở "payment service" thì làm sao để back về update lại cái "inventery service" kia v ah, có phải mình sẽ public 1 event từ con "payment server" thanh toán failed thì con "inventory server" lắng nghe event failed của con "payment service" và update lại phải không anh.
Nếu bạn thiết kế boundary của các service đủ tốt thì bạn chẳng cần phải nghĩ đến thực hiện "transaction" trên nhiều service, tuy nhiêu trong thực tế thì rất khó làm việc này. Thực hiện "transaction" trên nhiều service khác nhau có nhiều cách, hai cách thông dụng nhất là SAGA và Routing Slip. Ý tưởng chung là thực hiện liên tiếp các local transaction trên từng service, nếu như một bước trong quá trình bị lỗi thì trạng thái của các service trước đó cần được khôi phục lại, thường sẽ thông qua compensation message. Tuy nhiên luôn sẽ có các vấn đề: 1. Ở mỗi local transaction, bạn cần phải đảm bảo việc gửi các message trong transaction đó, do đó bạn cần phải có cơ chế Outbox, Idempotent Consumer. 2. "Lỗi" nói ở trên là lỗi về mặt business, ví dụ trong quá trình xử lý đơn hàng thì thanh toán không thành công do không đủ tiền. Còn lỗi như không thể kết nối database, là những lỗi ký thuật, thì không phải là lỗi để bạn hủy bỏ quá trình xử lý, do đó bạn cần có cơ chế retry trong trường hợp gặp lỗi kỹ thuật. 3. Làm theo cách này, tính Isolation trong ACID bị vứt vào sọt rác, và không có một cách tổng quát nào để bạn có thể khắc phục được việc này, phụ thuộc vào hệ thống mà bạn chọn ra giải pháp. Tốt hơn hết, bạn cần phải xác định tốt boundary của các service để giảm thiểu việc sử dụng "transaction" trên nhiều service.
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) | th-cam.com/video/rpoQjTm9In4/w-d-xo.html 26 - Section 26: Order service Part 2 | Tiếp đến là Redis chuyên sâu - th-cam.com/video/mswayRA-870/w-d-xo.html
cho em hỏi nếu hệ thống nào cũng như này thì sao ta không áp dụng hết Go đi ạ theo em thấy anh demo thì Go quá mạnh có khi nó realtime luôn vậy cần gì tốn chi phí cho những thằng khác trong khi Go handle được tận hàng triệu request mà còn có khả năng chia sẻ thông tin giữa các luồng quá mạnh rồi ạ. Mong anh làm video làm về vấn đề này ạ
Có hiệu năng cao không phải là một tiêu chuẩn tốt để chọn một ngôn ngữ. Vì sao: - Tiến độ dự án. Nếu một ngôn ngữ có hiệu năng cao nhưng lại cho năng suất thấp thì sẽ làm dự án dài hơn rất nhiều, làm chậm tiến độ release sản phẩm. - Đa số các backend đều là IO bounds. Nghĩa là ngôn ngữ có nhanh và hiệu quả đến cỡ nào thì vẫn phải chờ IO như mấy ngôn ngữ chậm như rùa bò có hỗ trợ multitasking.
@@placeholder612 Ngoài mấy vấn đề khách quan này có gì khác không ạ. Em vẫn thấy nếu IO bounds thì thằng Gin (framework của GO) cũng có ấy ạ, với lại em thấy dev nó cũng nhanh. Em là dân chuyên JS từ BE đến FE và làm C#. Do em thấy mọi người nói Go mạnh thì có tìm hiểu và học 1 thời gian thì có code lại dự án đang chạy của công ty sang Go thì đúng nó nhanh thật mà thời gian dev cũng ko lâu đâu ạ nếu so với 1 dự án Nhật chạy như vậy. Vậy có điều gì làm mọi người không nên bỏ hết mấy ngôn ngữ kia và chọn Go nhỉ. Em không tân bốc nó hay gì chỉ là thắc mắc 1 ngôn ngữ cái gì cũng mạnh vậy sao không bỏ hết mấy ngôn ngữ khác theo nó thôi kiểu giống như C top 1 tại sao không làm C thôi mà lại qua Python trong khi Python chạy rất chậm có khi gặp lỗi throttling liên tục không fix được nữa
@@placeholder612 nhưng theo em thấy những nguyên nhân khách quan đó nó không phải là nan giải và có thể handle được - Và những dự án mới bây giờ người ta cũng không chọn Golang là bước phát triển đầu tiên - Giống như việc em đưa 1 con game với lúc đầu là server Nodejs khi lượng user request quá cao em bị chết và dường như nó phải làm em phải đi handle case đó trong khi em đổi qua Golang chỉ mất tầm 1 tháng 3 tuần xong và nó có tốc độ nhanh và em không còn phải đau đầu giải quyết mấy cái vụ request đó nữa và dường như nó không gặp lại trong 2 tháng hơn hiện nay - Website thì em không biết nhưng có thể handle trong thời gian ngắn được thôi ạ nhưng tại sao người ta vẫn muốn chọn ngôn ngữ khác thay vì Go ta => Em chỉ thắc mắc thôi ạ vì em là dân Chuyển C#, Python em thấy Go nó mạnh mà sao mọi người lại cứ phải chọn Nodejs và java làm gì trong khi hiệu năng và tốc độ thì Golang ăn dứt truy bảo mật thì Golang nó cũng ngang ngang java không vượt trội thôi. Nhưng về chung quy nó vẫn mạnh hơn nhiều
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
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 😂)
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 th-cam.com/video/ylidVS4HvtE/w-d-xo.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
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 ạ.
Cái này chẳng liên quan đến Kafka hay kiến trúc truyền thống gì cả, cái này liên quan đến tư duy.
Có những process có thể xử lý trong thời gian dài mà không cần trả kết quả ngay lập tức.
Xử lý đơn hàng là một trong những process đó: khách hàng xác nhận đơn hàng, hệ thống trả về "đơn hàng đang được xử lý, chúng tôi sẽ thông báo cho bạn trong thời gian sớm nhất".
Và việc thêm tính năng mới cũng chẳng liên quan đến sức mạnh của Kafka. Trong ví dụ của trên video chỉ là một trường hợp thêm tính năng bằng cách replay các event, một việc mà hầu hết các event store đều làm được, không riêng gì Kafka, và có thể áp dụng cho kiến trúc truyền thống.
Khác biệt là ở tư duy, không phải ở công nghệ.
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.
🤣
hóng tiếp ạ
ok bạn nhe
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
Em có 1 thắc mắc, là nếu mình đẩy vào quee như vậy nếu 1 step trong order nó failed thì các service trước đó cũng phải update lại phải không anh. Ví dụ một trước lúc "do payment" thì mình có 1 bước là "update inventory" vậy nếu mình bị failed ở "payment service" thì làm sao để back về update lại cái "inventery service" kia v ah, có phải mình sẽ public 1 event từ con "payment server" thanh toán failed thì con "inventory server" lắng nghe event failed của con "payment service" và update lại phải không anh.
Có em tất cả phải transaction. SAGA pattern
Nếu bạn thiết kế boundary của các service đủ tốt thì bạn chẳng cần phải nghĩ đến thực hiện "transaction" trên nhiều service, tuy nhiêu trong thực tế thì rất khó làm việc này.
Thực hiện "transaction" trên nhiều service khác nhau có nhiều cách, hai cách thông dụng nhất là SAGA và Routing Slip. Ý tưởng chung là thực hiện liên tiếp các local transaction trên từng service, nếu như một bước trong quá trình bị lỗi thì trạng thái của các service trước đó cần được khôi phục lại, thường sẽ thông qua compensation message.
Tuy nhiên luôn sẽ có các vấn đề:
1. Ở mỗi local transaction, bạn cần phải đảm bảo việc gửi các message trong transaction đó, do đó bạn cần phải có cơ chế Outbox, Idempotent Consumer.
2. "Lỗi" nói ở trên là lỗi về mặt business, ví dụ trong quá trình xử lý đơn hàng thì thanh toán không thành công do không đủ tiền. Còn lỗi như không thể kết nối database, là những lỗi ký thuật, thì không phải là lỗi để bạn hủy bỏ quá trình xử lý, do đó bạn cần có cơ chế retry trong trường hợp gặp lỗi kỹ thuật.
3. Làm theo cách này, tính Isolation trong ACID bị vứt vào sọt rác, và không có một cách tổng quát nào để bạn có thể khắc phục được việc này, phụ thuộc vào hệ thống mà bạn chọn ra giải pháp.
Tốt hơn hết, bạn cần phải xác định tốt boundary của các service để giảm thiểu việc sử dụng "transaction" trên nhiều service.
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) | th-cam.com/video/rpoQjTm9In4/w-d-xo.html
26 - Section 26: Order service Part 2 | Tiếp đến là Redis chuyên sâu - th-cam.com/video/mswayRA-870/w-d-xo.html
cho em hỏi nếu hệ thống nào cũng như này thì sao ta không áp dụng hết Go đi ạ theo em thấy anh demo thì Go quá mạnh có khi nó realtime luôn vậy cần gì tốn chi phí cho những thằng khác trong khi Go handle được tận hàng triệu request mà còn có khả năng chia sẻ thông tin giữa các luồng quá mạnh rồi ạ. Mong anh làm video làm về vấn đề này ạ
Có hiệu năng cao không phải là một tiêu chuẩn tốt để chọn một ngôn ngữ. Vì sao:
- Tiến độ dự án. Nếu một ngôn ngữ có hiệu năng cao nhưng lại cho năng suất thấp thì sẽ làm dự án dài hơn rất nhiều, làm chậm tiến độ release sản phẩm.
- Đa số các backend đều là IO bounds. Nghĩa là ngôn ngữ có nhanh và hiệu quả đến cỡ nào thì vẫn phải chờ IO như mấy ngôn ngữ chậm như rùa bò có hỗ trợ multitasking.
@@placeholder612 Ngoài mấy vấn đề khách quan này có gì khác không ạ. Em vẫn thấy nếu IO bounds thì thằng Gin (framework của GO) cũng có ấy ạ, với lại em thấy dev nó cũng nhanh. Em là dân chuyên JS từ BE đến FE và làm C#.
Do em thấy mọi người nói Go mạnh thì có tìm hiểu và học 1 thời gian thì có code lại dự án đang chạy của công ty sang Go thì đúng nó nhanh thật mà thời gian dev cũng ko lâu đâu ạ nếu so với 1 dự án Nhật chạy như vậy.
Vậy có điều gì làm mọi người không nên bỏ hết mấy ngôn ngữ kia và chọn Go nhỉ. Em không tân bốc nó hay gì chỉ là thắc mắc 1 ngôn ngữ cái gì cũng mạnh vậy sao không bỏ hết mấy ngôn ngữ khác theo nó thôi kiểu giống như C top 1 tại sao không làm C thôi mà lại qua Python trong khi Python chạy rất chậm có khi gặp lỗi throttling liên tục không fix được nữa
@@placeholder612 nhưng theo em thấy những nguyên nhân khách quan đó nó không phải là nan giải và có thể handle được
- Và những dự án mới bây giờ người ta cũng không chọn Golang là bước phát triển đầu tiên
- Giống như việc em đưa 1 con game với lúc đầu là server Nodejs khi lượng user request quá cao em bị chết và dường như nó phải làm em phải đi handle case đó trong khi em đổi qua Golang chỉ mất tầm 1 tháng 3 tuần xong và nó có tốc độ nhanh và em không còn phải đau đầu giải quyết mấy cái vụ request đó nữa và dường như nó không gặp lại trong 2 tháng hơn hiện nay
- Website thì em không biết nhưng có thể handle trong thời gian ngắn được thôi ạ nhưng tại sao người ta vẫn muốn chọn ngôn ngữ khác thay vì Go ta
=> Em chỉ thắc mắc thôi ạ vì em là dân Chuyển C#, Python em thấy Go nó mạnh mà sao mọi người lại cứ phải chọn Nodejs và java làm gì trong khi hiệu năng và tốc độ thì Golang ăn dứt truy bảo mật thì Golang nó cũng ngang ngang java không vượt trội thôi. Nhưng về chung quy nó vẫn mạnh hơn nhiều
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 ơ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 ạ
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
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 😂)
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
th-cam.com/video/ylidVS4HvtE/w-d-xo.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.
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.
có video thực hành cơ chế này cho bài toán thực tế ko anh?
JAVA
@@anonystickJavascript có ko ạ?
e thấy hay nha
anh lam khoa hoc java anh oi
Xong go đã nha em
❤❤❤❤
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
NATS thì sao bác
Anh chưa có cơ hội làm về NATS em à...