Theo SES API Reference cho SendRawEmail, các thông số duy nhất bạn cung cấp như một phần của yêu cầu là danh sách người nhận, nội dung email và địa chỉ nguồn của bạn. Thật không may, có vẻ như rất rõ ràng rằng nếu bạn nhận được một thời gian chờ hơn là một phản ứng từ SES, có không có cách nào để biết email cụ thể đó đã được gửi hay chưa. Tôi biết điều đó rất khó chịu. Tôi ghét nó khi tôi ở trong tình huống đó.
Bạn làm, tuy nhiên, có một số tùy chọn khi nói đến việc tìm ra giải pháp thiết thực nhất cho tình trạng khó xử này. Bạn có thể đưa ra quyết định về chăn để không bao giờ thử lại và giả sử rằng một tin nhắn chưa gửi tốt hơn một thông điệp trùng lặp. Bạn cũng có thể đưa ra quyết định về chăn mà các email trùng lặp hoàn toàn có thể chấp nhận được. Tuy nhiên, cách tiếp cận ưa thích và được đề nghị của tôi là nền tảng trung bình về mặt học vấn, ít thực tế hơn. Hãy để tôi giải thích.
Khi tích hợp với dịch vụ mới và bạn thấy trường hợp cạnh bạn không biết cách xử lý nhưng bạn không mong đợi sẽ xảy ra rất thường xuyên, điều tốt nhất cần làm là thu thập thêm thông tin và xử lý mọi thứ theo cách thủ công thời gian trung bình. Rome không được xây dựng trong một ngày, và dịch vụ đám mây của bạn sẽ không hoạt động hoàn hảo vào ngày đầu tiên bạn bật nó lên. Thay vào đó, khi bạn nhận được một thời gian chờ, đăng nhập nó và lưu đi bất cứ điều gì bạn có thể cần phải gửi lại email đó sau đó.
Bây giờ, hãy tưởng tượng bạn đã hoàn tất việc viết mã và thử nghiệm tích hợp và bạn đã bật dịch vụ trong sản xuất. Ngày đầu tiên, bạn cố gắng gửi 100.000 email. Nếu bạn nhận được 1000 thời gian chờ, điều gì đó thực sự kỳ lạ đang diễn ra và bạn biết bạn cần điều tra mạng của mình! Điều gì xảy ra nếu, thay vào đó, vào ngày đầu tiên, bạn nhận được 0 thời gian chờ, tương tự vào ngày thứ hai, và sau đó vào ngày thứ bảy, trong số 700.000 lần thử trong tuần, chỉ có 1 lần hết giờ. Nếu thích hợp, bạn có thể thử gọi 1 khách hàng đó và nói "Xin lỗi, xin lỗi vì đã làm phiền bạn, nhưng chúng tôi thực sự cam kết về độ tin cậy và chúng tôi gặp sự cố kỹ thuật. Tôi muốn đảm bảo bạn đã nhận được biên nhận qua email cho [XYZ]. " Nếu họ nói không, tốt, sau đó nó có thể có ý nghĩa để quay trở lại và thay đổi mã để khi có một thời gian chờ, bạn chỉ cần thử lại sau khi chờ đợi một vài giây kể từ khi bạn biết nó có thể sẽ làm việc. Cùng một ý tưởng cho bất cứ điều gì ở giữa.
Vấn đề ở đây là bạn sẽ áp dụng trí thông minh của con người vào bí ẩn. Tôi đã tìm thấy nó thường dễ dàng hơn để KHÔNG cố gắng để thông minh ra không rõ. Chỉ cần thiết lập cho mình để có thể xử lý bất cứ điều gì xảy ra, và tìm ra những gì thông minh để làm là khi bạn biết những gì vấn đề thực sự trông giống như.
(Bạn có thể thưởng thức này blog post - được viết bởi một người khác -. Về "không xử lý vụ việc cạnh")
Bạn đang sử dụng một AWS SDK để gửi email vào lúc này? Tôi đang sử dụng PHP SDK và sau khi SendEmail được kích hoạt, có một phản hồi cho biết email có được gửi hay không (kiểm tra https://github.com/aws/aws-sdk-php/blob/master/src/ Aws/Ses/Resources/ses-2010-12-01.php).Sau đó, tôi có thể đăng nhập kết quả đó và điều tiếp theo là khá thẳng về phía trước –
@Hieu Có tôi làm, và có Amazon không trả lại trạng thái gửi. Quan điểm của tôi là, nếu thư là * không * được gửi vì nói, yêu cầu HTTP không nhận được phản hồi, hoặc PHP thoát với lỗi nghiêm trọng, hoặc bất kỳ lỗi nào, thì không có cách nào để biết liệu tôi có cần gửi email một lần nữa hay không. Tôi có một cron xử lý hàng loạt các email đang chờ xử lý và tôi muốn có thể hỏi 'Có email với id 123 đã được gửi chưa?' – Benjamin
Hmm sau đó trong SDK, bạn có thể sử dụng phương thức GetSendStatistics() để lấy số liệu thống kê sử dụng. Đọc thêm tại đây: "Theo dõi thống kê sử dụng của bạn bằng API SES của Amazon" http://docs.aws.amazon.com/ses/latest/DeveloperGuide/monitor-usage-statistics.html. Hy vọng nó sẽ giúp;) –