我的 Web 应用程序（销售点）处理多个分支机构的销售。每个销售都有一个唯一的整数 ID。分支 1 上的某个销售 ID 是n，那么分支 2 上的下一个销售是n +1。
当一家分店失去互联网连接时，我将销售信息保存在浏览器内部数据库中，其中销售 ID 是最后一个销售 ID 加一。恢复连接后，我将该信息发送到服务器，然后将其存储在真实数据库中。
当两个或更多分支机构失去互联网连接时，噩梦就会发生。因为当他们进行离线销售并且互联网恢复时，服务器将收到两个具有相同 ID 的销售，这太可怕了，因为客户票已经打印了！
我现在的计划是让每个销售 ID 混合分店 ID 和该分店的实际销售编号。因此，分支 1 的销售 ID 将是1-1，分支 2 的下一个销售将是2-1。听起来不错，直到一个分支有两个销售点，但事实并非如此，但它不是很有未来的证据。
你认为最好的方法是什么？有没有更好的方法来做到这一点？
避免单个 ID 上的 ID 冲突的唯一真正安全的方法是让服务器始终分配 ID。如果 POS 下线，那么您可能需要分配本地和临时 ID 来记录本地销售，然后当 POS 重新上线时，您从服务器获取真实 ID 并将本地 ID 修改为真实 ID，然后再发送交易. 我曾经有一个系统，它使用负数表示客户端创建的 ID，使用正数表示服务器创建的 ID。当服务器收到一个否定的 ID 时，它会将其更改为唯一创建的服务器 ID 并将该 ID 返回给客户端，以便客户端可以使用真实的事务 ID 更新其数据库。
如果您想要/需要全局唯一的客户端定义 ID，则每个 POS 客户端都需要一个服务器分配的唯一 ID，该 ID 可以是多部分复合 ID 的一部分。然后，每个客户端都可以维护自己的计数器，当与它的唯一客户端 ID 结合时，它始终是一个全局唯一 ID。它是您的 branchID 概念的扩展，除了它是唯一分配给每个客户的 clientID，因此您可以在每个分支机构拥有多个 POS 客户端。分配 clientID 可以在客户端设置时手动完成，也可以通过在某些设置或初始化过程中向服务器询问唯一的 clientID 来更动态地完成。
哪种技术对你来说最实用取决于你的系统比你在这里描述的要多得多，所以你要么必须根据你的知识来选择，要么描述更多关于你的系统是如何工作的，以便我们能够提供更多帮助。
理想情况下，每个销售点都有自己的 ID。例如，我曾经在一家国际零售连锁店工作（这里不点名），该连锁店在全球拥有数千家分店，每个分店多达 15 个销售点。每个 POS 都有自己的 ID 分配给它 - 它在向后端系统进行身份验证时使用此 ID。
如果您的设置是这种情况，那么您应该使用 POS ID 而不是分支 ID。这样，如果您在同一分支机构中有多个 POS，您可以将 POS ID 预先附加到事务 ID。
您描述的复合键是解决此问题的好方法。当我需要避免分布式情况下的键冲突时，我倾向于使用 GUID。