2017-07-03 15:19
浏览 83


I'm trying to implement a client and server and define their interactions. The client is designed using Golang, the server is designed in Node.js, and they interact using gRPC.

So the basic gist is:

  1. Client contacts server to update backend DB
  2. Client receives success response from server
  3. Client then itself changes the state of the overall system that the DB now reflects

But say something were to happen such that the process dies between steps 2 and 3 (Client process is terminated somehow). What is the best way to ensure that my backend DB doesn't reflect a system state that is inconsistent with reality? I'm sure this isn't a novel problem and would just like a couple pointers to how people typically cope with this type of design.

So I've already thought of redesigning this interaction such that the server is the entity that will handle the system changes— that way everything is handled in the same request and on the backend— but I'm using an open source technology that is designed in Go (so I can easily wrap it in my Go client). In other words, the client must be the entity that performs that system-change operation.

Thanks in advance!

图片转代码服务由CSDN问答提供 功能建议

我正在尝试实现客户端和服务器并定义其交互。 客户端是使用Golang设计的,服务器是使用Node.js设计的,并且它们使用gRPC进行交互。


  1. 客户端与服务器联系以更新后端数据库
  2. 客户端从服务器收到成功响应
  3. 客户端然后自行更改数据库现在的整体系统状态 反映

    ,但要说会发生一些事情,使流程在步骤2和3之间消失(客户端流程以某种方式终止)。 确保我的后端数据库不反映与实际情况不一致的系统状态的最佳方法是什么? 我确定这不是一个新问题,只是想指出一些人们通常如何处理这种类型的设计。

    所以我已经考虑过重新设计这种设计 交互,使得服务器是处理系统更改的实体(这样,所有事情都在同一请求中和后端处理),但是我使用的是Go中设计的开源技术(因此,我可以轻松包装它 在我的Go客户端中)。 换句话说,客户端必须是执行该系统更改操作的实体。


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • douqian9729
    douqian9729 2017-07-03 17:02
    1. The client ACKs (responds to server) that it has also updated local state to be synchronous with the server.

    If 4. doesn't happen, then the server rolls back the transaction done in 1. and the entire operation of 1 - 4 is atomic.

    点赞 评论