如何处理响应成功失败的消息，但成功提交到数据库 [英] How to handle message that failed to response success, but success commit to database
问题描述
我有一些关于处理无法成功响应的邮件的问题，但是成功提交到数据库。
I have some question about handling message that failed to response success, but success commit to database.
我认为这是为了保证处理邮件一次。
以下序列是处理的步骤。
问题包含在以下语句中：★
The design that I think is for guarantee processing message once.
Following sequences are step for handling.
Question is included on statements with ★
1）从消息队列获取消息
- >此后失败时，MQ将超时， retry
1) Fetch message from Message Queue
-> When failed after this, MQ will timeout & retry
2）Cache.SetIfNotExist（MessageId，MyId，Timeout）
ProcessingTime< Cache.Timeout< MQ.Timeoutpris
*这使得邮件的所有权
- >此后失败时，缓存将超时，MQ将超时， retry
2) Cache.SetIfNotExist(MessageId, MyId, Timeout)
ProcessingTime < Cache.Timeout < MQ.Timeout
* This make ownership for message
-> When failed after this, Cache will timeout and MQ will timeout & retry
3）处理资料包括读取储存空间
*所有数据应包括乐观锁定信息
- >当此后失败时，缓存将超时，MQ将超时， retry
3) Processing Data include read storage
* All of data should include optimistic locking information
-> When failed after this, Cache will timeout and MQ will timeout & retry
4）Cache.Get（MessageId）== MyId 0047
*确认此处理器拥有
- >当此后失败时，Cache将超时，MQ将超时， retry
4) Cache.Get(MessageId) == MyId
* This confirm this processor has ownership to message
-> When failed after this, Cache will timeout and MQ will timeout & retry
5）提交数据
*将所有数据提交到storage
¥b $ b *如果您更新多个文档，乐观锁定不保证一致性（如果所有或无功能存在，您可以获得一致性保证）_
*如果您使用某些文档以乐观锁定状态阅读，请阅读文档和提交文档应该检查乐观锁定
*您应该使用在RDBMS中的事务保证一致性
★失败后这是问题。如果MQ重试此事务，则无法检查。因此，转换会处理两次或更多次。
如果缓存在提交数据期间超时，会发生同样的问题。
5) Commit Data
* This will commit all data to storage
* If you update multiple document, optimistic locking do not guarantee consistency (if all or nothing feature is exist, you can get consistency guarantee)
* If you use some document for reading in optimistic locking state, read document and commit document should check by optimistic locking
* You should use transaction in RDBMS for guarantee consistency
★ Failed after this is problem. If MQ retry this transaction, there is no way to check. So transcation will be processed twice or more.
★ If cache is timeout during commit data, same problem is occurred.
6）Cache.Set（MessageId，MyId，Timeout）
*在删除邮件之前阻止MQ超时重试。
6) Cache.Set(MessageId, MyId, Timeout)
* Prevent retry by MQ timeout before deleting message.
7 ）Ack Message`
*发送完成并从邮件队列中删除邮件
7) Ack Message
* Send to finish and delete message from message queue
- 问题：以处理此问题？
1）提交数据出现问题后失败。如果MQ重试此事务，则无法检查。因此，系统会处理两次或更多次转换。
2）如果缓存在提交数据期间超时，则会出现同样的问题。
感谢您阅读。
Thanks you for reading.
推荐答案
我发现没有办法如果数据库不保存所讨论的消息所有者数据，则解决此问题。
在数据库中，恢复机制恢复删除崩溃数据，如停机时间，而不是结束transacriom。
解决这种情况的一种方法是在提交阶段失败时将所有阶段标志添加到所有权缓存检查数据库。
其他方式是更新数据库已知的已过期消息并用定期批处理将其删除。
只有一个线程写作业可以保证一致性，或者需要其他机制。所以服务到DB通信有两个线程，它不能保证。
I found there is no way to resolvs this problem if database doesn't hold message ownersnip data that was described at question.
In database, recovery mechanism restore removing crashed data like commited but not end transacriom after downtime.
One way to solve that situation is add phase flag to ownership cache check database when failed at commit stage.
Other way is updated database know published messageid with expiry and removing this with periodical batch.
Only one threaded write job can guarantee consistency, or required other mechanism. So service to DB communication has two thread, it cannot guarantee.
这篇关于如何处理响应成功失败的消息，但成功提交到数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
