英文:
Basic Client/Server Architecture & Interactions
问题
我正在尝试实现一个客户端和服务器，并定义它们之间的交互。客户端使用Golang设计，服务器使用Node.js设计，并使用gRPC进行交互。
基本思路如下：
- 客户端联系服务器以更新后端数据库。
- 客户端从服务器接收成功响应。
- 客户端自身改变整个系统的状态，使数据库反映这种变化。
但是，假设在第2步和第3步之间发生了某种情况，导致进程中断（客户端进程以某种方式终止）。如何确保我的后端数据库不反映与实际情况不一致的系统状态？我相信这不是一个新颖的问题，只是想了解人们通常如何处理这种类型的设计的一些建议。
所以我已经考虑过重新设计这种交互方式，使服务器成为处理系统变化的实体，这样一切都在同一个请求和后端上处理。但是，我正在使用一个设计为Go的开源技术（因此我可以轻松地在我的Go客户端中使用它）。换句话说，客户端必须执行系统变更操作。
提前感谢您的帮助！
英文:
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:
- Client contacts server to update backend DB
- Client receives success response from server
- 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.
<Enter>
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 <b>must</b> be the entity that performs that system-change operation.
Thanks in advance!
答案1
得分: 0
- 客户端确认（回应服务器）它也已经更新本地状态与服务器同步。
如果第4步没有发生，那么服务器会回滚在第1步中执行的事务，整个1-4的操作是原子性的。
英文:
- 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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论