cái này triển khai còn thiếu cái bước quản lý trạng thái giao dịch và theo dõi các transaction để bù trừ nếu cần rollback nữa. Chứ múc cơ bản khóc meo meo luôn nhá.
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
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.
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
@@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.
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 ạ
@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 triển khai còn thiếu cái bước quản lý trạng thái giao dịch và theo dõi các transaction để bù trừ nếu cần rollback nữa. Chứ múc cơ bản khóc meo meo luôn nhá.
Em đang tìm hiểu về Kafka mong anh ra sớm video ạ.
hay quá anh ơi, anh apply kafka vào go project luôn nha anh
Tất nhiên rồi hen
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
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
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
Anh làm về kiểm thử database được không ạ
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
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
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.
🤣
e thấy hay nha
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 ạ
@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
có video thực hành cơ chế này cho bài toán thực tế ko anh?
JAVA
@@anonystickJavascript có ko ạ?
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 ạ
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 lam khoa hoc java anh oi
Xong go đã nha em
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.
❤❤❤❤
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 à...