Phần này mình nói về chủ yếu là về việc query từ DB lên service để xử lý. còn việc trả về cho client thì có thể trả về theo dạng streaming qua SSE lúc này phía client cũng phải xử lý để đọc dữ liệu dạng streaming. vd như observable rxjs nhé
@trandatk Đó là với bài toán của em là như thế. Nhưng với các hệ thống như ngân hàng, thì họ cần chính xác tuyệt đối trong giao dịch và họ cũng cần ghi lại thông tin của những lần giao dịch cũng như thông báo để tiện rà soát. Đó là lý do kafka sẽ phát huy tốt trong lĩnh vực này. Nhưng nếu hệ thống của em chỉ cần Event bus, thì RabbitMQ sẽ hợp hơn.
Thực tế mỗi dự án sẽ có yêu cầu riêng nên việc chọn cái nào sẽ phụ thuộc vào nghiệp vụ và mong muốn của khách hàng. Ví dụ nếu khách hàng muốn dùng, dù em có thấy không hợp lý thì em vẫn phải làm đúng không?
Thê nên vấn đề của em là em thấy kafka đang không phù hợp với hệ thống của mình. Anh không biết hệ thống của em yêu cầu sao nhưng nếu đã chọn kafka thì em nên hỏi người chọn hoặc quản lý là tại sao cần chọn kafka cho hệ thống sẽ hợp lý hơn á
@giang.nt Theo em thì với ý thứ 3 của anh nói vấn đề replay dữ liệu khi server chết thì ngay từ ban đầu khi thiết kế microservices là Saga pattern và Outbox pattern thì đâu có lo chỗ khôi phục dữ liệu nhờ kafka anh nhỉ.
Ý em là về tính thực tiễn thôi, như em nói ngay từ ban đầu, khi triển khai microservices với Saga pattern, Outbox pattern thì việc lựa chọn Kafka để có tính bền vững là không hợp lý, ở đây ta chỉ cần một Event bus với nhiệm vụ truyền event đúng nghĩa thôi ấy
@trandatk Cái này còn tuỳ thuộc vào nghiệp vụ của dự án nữa.
Việc Replay là hệ quả của tính bền vững chứ không phải mục đích ban đầu.
Thực tế thì với lượng dữ liệu lớn như vậy nếu đã có 1 Kafka để thay e lưu thông tin rồi, thì có phải bớt một bước lưu lại ngay lúc đó, cũng tăng performance cho hệ thống.
Nếu tạo thêm nơi để lưu, nếu server chết (mất điện chẳng hạn) thì em nghĩ nên xử lý lưu lại như nào để khôi phục dữ liệu.
I encountered an issue when rotating the algorithm weekly because some users kept an outdated version of the front-end, so their HMAC algorithm was not up to date.
Therefore, the backend has to handle requests from both the new and the previous algorithm versions. This helps improve the overall user experience.
@giang.nt Tại chủ đề này em chưa thấy ai nói nên em hơi khó hiểu, về cơ bản người ta chỉ cần replay khi có lỗi thôi chứ đúng không anh? Vậy thì mấy cái như kiểu ELK vẫn làm tốt hơn mà, em vẫn chưa thấy ứng dụng của nó ấy
THẢO LUẬN
Bài viết hay quá bạn ơi
Đỉnh quá anh try ơi !!!!!!
bài viết hay quá
👍️
Cho mình hỏi nếu đăng ký gói thì hạn đến cuối tháng hay hết chi kỳ (ngày này tháng sau)
Bạn ơi, post code thì vui lòng post đủ source code lên cho mọi người tham khảo. Lỗi thiếu file tùm lum hết nè.
@giang.nt à em hiểu rồi, em cám ơn anh nhé
@huynq1808 ồ ra vậy, cám ơn chị nhiều nhé
Phần này mình nói về chủ yếu là về việc query từ DB lên service để xử lý. còn việc trả về cho client thì có thể trả về theo dạng streaming qua SSE lúc này phía client cũng phải xử lý để đọc dữ liệu dạng streaming. vd như observable rxjs nhé
@trandatk Đó là với bài toán của em là như thế. Nhưng với các hệ thống như ngân hàng, thì họ cần chính xác tuyệt đối trong giao dịch và họ cũng cần ghi lại thông tin của những lần giao dịch cũng như thông báo để tiện rà soát. Đó là lý do kafka sẽ phát huy tốt trong lĩnh vực này. Nhưng nếu hệ thống của em chỉ cần Event bus, thì RabbitMQ sẽ hợp hơn.
Thực tế mỗi dự án sẽ có yêu cầu riêng nên việc chọn cái nào sẽ phụ thuộc vào nghiệp vụ và mong muốn của khách hàng. Ví dụ nếu khách hàng muốn dùng, dù em có thấy không hợp lý thì em vẫn phải làm đúng không?
Thê nên vấn đề của em là em thấy kafka đang không phù hợp với hệ thống của mình. Anh không biết hệ thống của em yêu cầu sao nhưng nếu đã chọn kafka thì em nên hỏi người chọn hoặc quản lý là tại sao cần chọn kafka cho hệ thống sẽ hợp lý hơn á
Chà hay thật, nhưng mà cho em hỏi thêm một xíu đó là response cũng là dạng streaming và client cũng xử lý streaming tương ứng đúng không ạ?
@giang.nt Theo em thì với ý thứ 3 của anh nói vấn đề replay dữ liệu khi server chết thì ngay từ ban đầu khi thiết kế microservices là Saga pattern và Outbox pattern thì đâu có lo chỗ khôi phục dữ liệu nhờ kafka anh nhỉ.
Ý em là về tính thực tiễn thôi, như em nói ngay từ ban đầu, khi triển khai microservices với Saga pattern, Outbox pattern thì việc lựa chọn Kafka để có tính bền vững là không hợp lý, ở đây ta chỉ cần một Event bus với nhiệm vụ truyền event đúng nghĩa thôi ấy
@trandatk Cái này còn tuỳ thuộc vào nghiệp vụ của dự án nữa.
Việc Replay là hệ quả của tính bền vững chứ không phải mục đích ban đầu.
Thực tế thì với lượng dữ liệu lớn như vậy nếu đã có 1 Kafka để thay e lưu thông tin rồi, thì có phải bớt một bước lưu lại ngay lúc đó, cũng tăng performance cho hệ thống.
Nếu tạo thêm nơi để lưu, nếu server chết (mất điện chẳng hạn) thì em nghĩ nên xử lý lưu lại như nào để khôi phục dữ liệu.
This is exactly what I was searching for. Your content always adds great value. Keep up the amazing work https://login360.in/data-science-course-in-coimbatore/
bạn chưa hiểu ở đoạn nào á?
"Chụp 4 góc chỗ bàn/ghế ngồi thi" cái này chụp bằng Camera của laptop à ban?
đọc mãi vẫn chưa hiểu lắm , nh mong fen ra nhiều bài , bài nào cuả bạn cũng chất
Cảm ơn anh vì bài viết
I encountered an issue when rotating the algorithm weekly because some users kept an outdated version of the front-end, so their HMAC algorithm was not up to date. Therefore, the backend has to handle requests from both the new and the previous algorithm versions. This helps improve the overall user experience.
@giang.nt Tại chủ đề này em chưa thấy ai nói nên em hơi khó hiểu, về cơ bản người ta chỉ cần replay khi có lỗi thôi chứ đúng không anh? Vậy thì mấy cái như kiểu ELK vẫn làm tốt hơn mà, em vẫn chưa thấy ứng dụng của nó ấy