Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We want to connect the people who have knowledge to the people who need it, to bring together people with different perspectives so they can understand each other better, and to empower everyone to share their knowledge.
Ưu /khuyết điểm của Message Queue
1. Ưu điểm: - Nó giải phóng được thread đang phục vụ API, từ đó mà có thể phục vụ nhiều request đồng thời hơn. - Nó tách biệt các nghiệp vụ, từ đó mà có thể chia nhỏ được các nghiệp vụ, nhiều team sẽ làm việc cùng 1 lúc, và nếu 1 nghiệp vụ bị tèo thì cũng không ảnh hưởng gì đến toàn bộ hệ thống - TrRead more
1. Ưu điểm:
– Nó giải phóng được thread đang phục vụ API, từ đó mà có thể phục vụ nhiều request đồng thời hơn.
– Nó tách biệt các nghiệp vụ, từ đó mà có thể chia nhỏ được các nghiệp vụ, nhiều team sẽ làm việc cùng 1 lúc, và nếu 1 nghiệp vụ bị tèo thì cũng không ảnh hưởng gì đến toàn bộ hệ thống
– Trên thực tế có những nghiệp vụ ví dụ xử lý transaction gửi nhận tiền giữa nhiều users chẳng hạn, thì việc gom yêu cầu thông qua MQ rồi đến con consumer xử lý tập trung sẽ làm cho những việc kiểu như lock nó rất dễ dàng, ví dụ:
lock.lock() try { cộng tiền của user 1, trừ tiền của user 2 } finally { lock.unlock(); }Thay vì phải xử lý cực kỳ phức tạp nếu xử lý transaction trên nhiều server, thậm chí đôi khi còn không thể nào xử lý chính xác 100% được.
2. Nhược điểm:
See less– Nó sẽ yêu cầu phải sinh ra nhiều server để cài cắm và xử lý, tối thiều đã cần 1 con producer, 1 con broker và 1 con consumer rồi, từ đó cũng tăng thêm chi phí DevOps, chi phí vận hành.
– Do dữ liệu phải đi qua nhiều server trung gian nên tốc độ sẽ bị chậm hơn so với xử lý trực tiếp từ server nhận request.
Hỏi về việc gửi tin nhắn qua Message Queue (RabbitMQ,Kafka)
Trả lời câu 1: - Xử lý đơn hàng trong thương mại điện tử - Xử lý giao dịch (gửi nhận tiền hay bất kỳ loại giao dịch nào khác) - Những nghiệp vụ mà yêu cầu chỉ được thực hiện bởi 1 server duy nhất để tránh bị concurrent Trả lời câu 2: 1. Không rõ em đọc các giải thích ở đâu nhỉ? có thể cho anh xem ngRead more
Trả lời câu 1:
– Xử lý đơn hàng trong thương mại điện tử
– Xử lý giao dịch (gửi nhận tiền hay bất kỳ loại giao dịch nào khác)
– Những nghiệp vụ mà yêu cầu chỉ được thực hiện bởi 1 server duy nhất để tránh bị concurrent
Trả lời câu 2:
1. Không rõ em đọc các giải thích ở đâu nhỉ? có thể cho anh xem nguồn được không?
2. Gửi Mail, SMS là một trong những nghiệp vụ khá chậm, ví dụ em submit 1 cái request gửi Mail, SMS marketing đến 1000 người, thì khả năng cao sẽ mất đến vài phút, như vậy thì em sẽ không thể đợi request đó được thực hiện xong được, trên giao diện của em nó sẽ quay mãi luôn. Thêm 1 điểm nữa là server sẽ chỉ có hữu hạn số lượng thread (thường là vài trăm) như vậy nếu request nào cũng chờ quá lâu dẫn đến tình trạng server bị hết thread và không thể phục vụ thêm request, nó cũng tương đương với DDoS.
Chính vì vậy mà người ta phải lưu tạm Mail, SMS vào trong database, MQ hay Kafka, mục đích chính là nhanh chóng giải phóng thread để còn phục vụ các yêu cầu khác nữa.
Ngoài ra thì nếu việc gửi mail, sms còn rất dễ lỗi nữa, nên còn liên quan đến việc xử lý các mail sms lỗi này, nên nếu mình có nhiều HTTP server để phục vụ APIs mà mình cũng dùng luôn các server này để xử lý mail, sms thì có thể dẫn đến trường hợp gửi trùng lặp mail, sms, vậy nên thông qua database, MQ hay kafka gửi đến 1 con server xử lý tập trung thì sẽ chính xác hơn.
Tuy nhiên nếu lấy lý do là để xử lý sms và mail nhanh hơn thì có vẻ không đúng, vì rõ ràng là việc gửi nhận qua MQ hay Kafka sẽ tốn thêm thời gian request phải đi qua các con Broker nữa đúng không nhỉ, vậy nó phải chậm hơn mới đúng. Mà việc gửi mail, sms thuần tuý là I/O không có xử lý logic gì cả.
3. Em cần tách câu hỏi này ra em ạ, đến đây khá dài rồi.
See lessvì sao càng gần Native, Mã máy thì càng nhanh
Nó cũng giống việc em nói chuyện trực tiếp với bạn em và nói chuyện với bạn em thông quan 1 thông dịch viên đúng không nhỉ? Rõ ràng là nói chuyện trực tiếp sẽ nhanh hơn nhiều so với việc phải chờ đợi 1 người dịch qua dịch lại rồi em ạ.
Nó cũng giống việc em nói chuyện trực tiếp với bạn em và nói chuyện với bạn em thông quan 1 thông dịch viên đúng không nhỉ? Rõ ràng là nói chuyện trực tiếp sẽ nhanh hơn nhiều so với việc phải chờ đợi 1 người dịch qua dịch lại rồi em ạ.
See lessBackground activity bị auto scale khi bàn phím số hiện lên
Bạn có thể cung cấp thêm hình ảnh và code hiện tại để mình có thể dữ liệu hỗ trợ không nhỉ?
Bạn có thể cung cấp thêm hình ảnh và code hiện tại để mình có thể dữ liệu hỗ trợ không nhỉ?
See lessXử lý kiểu dữ liệu Blob trong database h2 spring boot
1. Theo anh thấy là có thể lưu tất cả các dạng file em ạ. 2. Spring thì chưa hỗ trợ, em sẽ cần phải đọc file thành InputStream hoặc byte[] hoặc blob rồi lưu xuống db. 3. Tuy nhiên anh nghĩ là em nên lưu file ở trên server hoặc s3 hoặc 1 dịch vụ datastore nào đó thì sẽ tốt hơn là lưu vào db em ạ. VìRead more
1. Theo anh thấy là có thể lưu tất cả các dạng file em ạ.
See less2. Spring thì chưa hỗ trợ, em sẽ cần phải đọc file thành InputStream hoặc byte[] hoặc blob rồi lưu xuống db.
3. Tuy nhiên anh nghĩ là em nên lưu file ở trên server hoặc s3 hoặc 1 dịch vụ datastore nào đó thì sẽ tốt hơn là lưu vào db em ạ. Vì nếu lưu 1 file có dung lượng lớn hàng chục MB trở lên thì việc đọc ghi sẽ gặp nhiều khó khăn và chậm chạp, dễ bị tràn bộ nhớ. Thêm vào nữa khi dung lượng DB lớn lên thì việc backup cũng sẽ bị ảnh hưởng rất nhiều đó em ạ.
tránh deadlock với Transaction trong Database
Anh ơi, khi 1 ứng dụng có 2 thread Update 2 bảng A đến B và B đến A với cùng 1 record sẽ xảy ra deadlock, điều này không tránh khỏi Anh chưa hiểu cái này lắm, em có thể ví dụ cụ thể bằng code được không? Trong mọi trường hợp thì việc deadlock đều dẫn đến service bị hoạt động không bình thường. Khi eRead more
Anh chưa hiểu cái này lắm, em có thể ví dụ cụ thể bằng code được không?
Trong mọi trường hợp thì việc deadlock đều dẫn đến service bị hoạt động không bình thường. Khi em sử dụng database thì tuỳ theo cơ chế của database đó nó sẽ đối xử với transaction thế nào. Có thể là nó sẽ có timeout cho transaction, có thể là nó sẽ đóng lại transaction khi session bị ngắt kết nối, vậy nên sẽ không nhất thiết em phải restart database đâu.
Để tránh deadlock thì em có thể tham khảo wiki này. Và cách đơn giản nhất là đừng có sử dụng synchronized hoặc lock bừa bãi, và trong code thực tế thì em cũng hiếm khi sử dụng đến lock, ngay cả khi có sử dụng lock thì thường em cũng dùng trong phạm vi nhỏ hoặc không lồng nhau, nên cũng không cần lo lắng quá về deadlock đâu em ạ.
See lesscông cụ nào để check Network
Không rõ là em cần check network đến mức nào nhưng hiện nay thì anh cũng đang dùng Prometheus Blackbox để call health check của service thôi, nếu không có phản hồi từ service thì nó sẽ bắn lỗi về slack và anh sẽ cần kiểm tra và khởi động lại service nếu cần. Ngoài ra em cũng có thể nghiên cứu sử dụnRead more
Không rõ là em cần check network đến mức nào nhưng hiện nay thì anh cũng đang dùng Prometheus Blackbox để call health check của service thôi, nếu không có phản hồi từ service thì nó sẽ bắn lỗi về slack và anh sẽ cần kiểm tra và khởi động lại service nếu cần.
Ngoài ra em cũng có thể nghiên cứu sử dụng datadog xem sao, anh thấy nó cũng hỗ trợ khá mạnh.
See less