Android (分布式应用)主密钥策略

Question

我将实现一个具有多个移动客户端的分布式应用程序和一个基于web的服务器应用程序。因此，每个客户端和服务器都可以生成表条目。因此，我需要唯一的主键，而不是所有参与者，并且我希望能够生成键离线。

在分布式环境中生成主键的最佳方法是什么?关于类似的问题，请参见以SQLite和Azure数据库为中心存储的在线/离线多客户机移动应用程序的最佳主要关键策略是什么？。

我知道UUID密钥生成是一种很好的方案，但我想坚持使用名称为_id的键，并按安卓平台的建议键入。

我不希望组合id与设备(也是服务器是设备) id和本地id一起使用。无论如何，这种方法都不能很好地工作，因为服务器应该能够为某个客户端生成条目。在这种情况下，我还必须在服务器上使用设备id。

因此，我现在最喜欢的是用数据类型long构建我的密钥(我以前在另一个项目中这样做过)。我想我将使用高/低方法(例如，参见这里的Hi/Lo算法是什么？)，并有一个键，其中包括：

• 从服务器生成的客户机id (例如~28位)
• 在客户端上递增的低值(例如~4位)，从未持久化
• 高值(例如~ 32位)在客户端上递增，仅在客户端上持久化

必须在移动应用程序的第一次启动时从服务器获取客户端id。因此，第一个开始需要一个网络连接。这可能是这种方法的一个缺点。当设备上有客户端id时，我可以在没有网络连接的情况下生成密钥。

通常，高id是数据库上的唯一值。当用户卸载并再次安装应用程序时，我必须将他视为一个新客户端，并必须给他一个新的客户端id。否则，我必须在服务器上保存当前的高id，这样才能在丢失或重新安装时恢复它--这是不值得的。

--在Android上获得高id的最佳方法是什么？--一个自动递增键--不是解决方案。我需要像发电机这样的功能。而且它必须在自己的事务中执行(而不是“用户”事务)。有没有人在Android上体验过这种方法，有人能为我指明正确的方向吗？(我只找到了这个回答)。

您的多客户端应用程序(在线和脱机)使用什么关键策略？

Answer 1

这是更多的问题然后是答案..。

如果您可以自动生成所有id，那么这确实会使事情变得更简单，因此您不必从服务器上获取它们，并担心是否有连接。您提到不能采用通用方法(UUID或ANDROID_ID)，因为您将使用“Android平台建议的”长时间。

你指的是安卓假设你的SQLite表会有一个长的_id主键吗？

您是在服务器上使用数据存储还是SQL数据库？

如果您使用的是具有分级密钥的数据存储(例如，google数据存储)，那么如果您使用UUID/ANDROID_ID作为客户端id，然后使用一个长作为数据项id，则如何？然后在客户机上存储long，在服务器上使用UUID/long的关键路径存储实体。

为什么要写“高id必须是数据库上的唯一值”？由于它的前面有客户端id，所以您的意思是它在本地数据库中必须是唯一的？

要解决用户可以卸载和重新安装应用程序的问题，为什么不坚持“在服务器上保存当前的高id，以便能够在丢失或重新安装时恢复它”。由于您已经计划在第一次运行时检索客户端id (并且在获得id之前不能分配id)，所以您还可以向服务器询问下一个可用的高id。

您的实体是否有其他一些关键材料，这样您就可以为您的高id从该材料生成32位散列吗？假设高id只需要在特定的客户端上是唯一的(并且假设您在客户端上不会有大量的实体)，那么我认为如果您有合适的密钥材料并使用一个散列函数来最小化冲突，那么就永远不会发生冲突。

Answer 2

根据我的经验：在设备上使用本地ID，在服务器上使用单独的ID。每次您通过有线通信数据时，都要从一个转换到另一个。这实际上将澄清这个过程，并简化调试。转换例程保持较小，很好地隔离，并表示应用程序体系结构中的一个自然元素。无论如何，线路上传输的数据预计会相对较小，而且ID转换也不会造成很大的开销。而且，在移动设备上保存的数据量可能很小(大容量在服务器上)。

我建议使用一个简单的表local_ID<->server_ID.在设备上进行转换。服务器应该只提供一个过程:生成一批密钥，比如444个新密钥，据推测，移动设备随后将分配给其本地ID，并仅使用server_IDs向服务器发送数据。转换表可以偶尔清除未使用的ID，并且可以重用本地ID，32位整数就足够了。

动机

表保持较小，实现对本机设备体系结构保持最佳状态，与其他地方不可预测的体系结构更改隔离，并且有一个很好的调试和跟踪点，所有数据都可以通过该点进行调试和跟踪。

我让一个应用程序重新生成每个数据文件上的所有ID，保存和加载。它出乎意料地简单，快速，并打开了优雅的其他可能性，如ID-空间碎片整理和合并。

在您的示例中，您可以通过对客户端应用程序的最小更改来更改服务器技术。由于客户机无论如何都可以脱机操作，所以它只能在大多数函数中使用本地ID。只有同步模块才能获取和转换服务器ID。

Answer 3

我在这个问题上悬赏两次，但没有找到我想要的答案。但是我花了一些时间去思考最好的解决方案，也许这个问题还不够开放，并且把注意力集中在我想要的解决方案上。

然而，有很多不同的策略可用，现在(在第二个奖励之后)我认为第一个要回答的问题是，在您的分布式环境中，您有哪些数据模型？你可能会

1. 客户端和服务器上相同的(或子集)数据模型
2. 不同的客户端数据模型和服务器数据模型

如果你用1)回答，那么你可以选择你的关键策略

• 使用GUID
• 用我的方法高/低
• 将键映射为@ keys 3603546建议

如果你用2)回答，那么我只想到以下几点

• 复合id

我从来不喜欢复合id，但是当我想到它(无论如何也不要称之为复合id)，那么它可能是一个可能的解决方案。下面我想概述一下这个解决方案：

词汇表：

• ..。在客户端生成主键，因此客户端选择实现(用于Android的长_id )
• ..。在服务器端生成主键，因此服务器选择实现。
• ..。标识客户端的ID
• ..。标识设备的ID，客户端与设备之间存在1-n关系。

解决方案：

• 只有当您有客户端数据模型和服务器数据模型时，才使用它。
• 客户端数据模型具有字段
  • 主键
  • 可空数据字段

​

• 服务器数据模型具有字段。
  • 作为主键
  • 可空数据字段
  • 作为区分客户端的强制数据字段。

​

• 当从服务器同步到客户端时，在客户机上生成缺失，并将条目标记为脏(以便客户机id在一天结束时到达服务器)。
• 在从客户端同步到服务器时，在保存服务器之前在服务器上生成缺失。
• 客户端和服务器数据模型之间的映射可以由杜泽尔或奥里卡这样的专门框架处理，但是在执行映射时必须集成密钥生成。

我从来不喜欢这个解决方案，因为我总是用服务器数据模型的术语来思考。我有只存在于服务器上的实体，我总是希望在客户机上创建这些实体，这是不可能的。但是当我认为在客户数据模型中，我可能有一个实体，例如。在服务器上生成两个实体(Productand一个ClientProduct)的产品。