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.
THẢO LUẬN
Cảm ơn đã chia sẻ thông tin
Hay quá, mong tác giả hoàn thành được dự án đầy triển vọng này.
Dùng cái này sẽ tận dụng được phần cứng GPU của NVIDIA nên giúp tốc độ xử lý nhanh hơn rất nhiều lần so với OpenCV đó bạn.
Dùng queue, supervisor, scheduler (Laravel) trên ServBay như nào thế bác?
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 á?