1

在这种情况下，最好的重试策略是什么：

Database成功创建数据条目，但响应时间过长Application。所以要执行这项工作，Application重试创建，当然会Database返回一个“已经存在”的错误。所以最后从Application他的角度来看，好像是创作失败了，其实是成功了。更糟糕的是，如果这是在一系列步骤的中间，那么就无法Application决定是否触发前面步骤的回滚。

增加超时时间Application不是一个可接受的解决方案，因为 IP 网络永远不可能 100% 可靠，而且响应在网络中丢失的可能性总是很小。

在创建之前添加对存在的检查<data>可能会起作用。但这只是在考虑并发性的情况下。在我的情况下，可以有多个客户Database，我不确定竞争条件的可能性。

+-------------+                                             +-----------+    
| Application |                                             | Database  |    
+-------------+                                             +-----------+    
       |                                                          |          
       | CREATE <data>                                            |          
       |--------------------------------------------------------->|          
       |                                                          |          
       |                                                          | creating 
       |                                                          |--------- 
       |                                                          |        | 
       |                                                          |<-------- 
       | -------------------------------\                         |          
       |-| timeout waiting for response |                         |          
       | |------------------------------|                         |          
       |                                                          |          
       |                                                  SUCCESS |          
       |<---------------------------------------------------------|          
       | -----------------------------------------------\         |          
       |-| response from a timed out session is ignored |         |          
       | |----------------------------------------------|         |          
       |                                                          |          
       | retry CREATE <data>                                      |          
       |--------------------------------------------------------->|          
       |                                                          |          
       |                             ERROR: <data> ALREADY EXISTS |          
       |<---------------------------------------------------------|          
       | ---------------------------------------------------\     |          
       |-| no idea whether the creation actually took place |     |          
       | |--------------------------------------------------|     |          
       |                                                          |
4

2 回答 2

0

大多数现代数据库都提供了一些编写“upsert”语句的方法，如果数据不存在，它将自动插入数据，如果数据已经存在，则更新（或什么都不做）。这样，如果数据已经创建，您的应用程序可以安全地重试并且不会出错，从而使您的数据创建具有幂等性。

一些流行数据库的示例：

  • MySQL：

     -- Do nothing if data exists
 INSERT IGNORE ...
 -- Update if data exists
 INSERT ...  ON DUPLICATE KEY UPDATE ...

  • PostgreSQL :

    -- Do nothing if data exists
INSERT ... ON CONFLICT DO NOTHING
-- Update if data exists
INSERT ... ON CONFLICT ... DO NOTHING

  • 甲骨文：

    -- Do nothing if data exists
MERGE INTO ... USING ...
WHEN NOT MATCHED THEN INSERT ...
-- Update if data exists
MERGE INTO ... USING ...
WHEN NOT MATCHED THEN INSERT ...
WHEN MATCHED THEN UPDATE ...

如果原子操作或事务不是一个选项，您可以编写数据库操作以便重试不会有害，并在循环中执行每个操作，首先检查数据库是否已经处于所需状态，然后尝试操作如果它不是，并重试失败。换句话说，类似（伪代码）：

max_retries = n
retries = 0
WHILE NOT database_in_desired_state
    IF retries < max_retries THEN
        perform_database_operation
        retries = retries + 1
    ELSE
        fail

您可以通过使操作有条件（例如UPDATE some_table SET field = value, version = version + 1 WHERE version = expected_version，或添加唯一约束等以禁止重复操作）来使重试无害。如果您提供有关您正在使用的数据库的更多详细信息，我可能能够提供更具体的建议。

如果您在多个远程系统上执行一系列操作，如果发生故障，整个操作应该回滚，并且无法将所有交互包装在单个（分布式）事务中，您将需要编写补偿事务这将手动回滚迄今为止对错误所做的工作。当然，补偿事务也可能失败，您需要考虑如何处理。一种方法是定期进行清理任务，以查找失败的事务或不一致的状态。

于 2017-08-02T10:05:45.383 回答
0

这一切都取决于上下文。

是的，网络连接可能会失败 - 但您必须确定这是多大的风险。如果您使用专业的托管设置和企业级设备，这将会发生 - 嗯，几乎永远不会。在这种情况下，我不会在应用程序中构建很多额外的逻辑来处理网络问题；您应该依靠数据库的事务管理功能来确保数据处于一致状态。一旦您的应用程序捕获到网络异常，您就可以向用户显示错误，并要求他们重新开始。

如果你的环境本质上是不可靠的——例如，你通过公共互联网连接——常见的架构模式是使用消息总线，而不是同步操作。

编写同步代码来处理不可靠的网络状况并非易事；您将从发布的伪代码@markusk 开始，但我会添加关闭并重新打开数据库连接。

于 2017-08-07T08:13:57.420 回答