我正在Google AppEngine上实施许可证密钥系统 . 密钥是提前生成的，并通过电子邮件发送给用户 . 然后他们登录系统并输入密钥以激活产品 .
我可能有几百人同时提交他们的密钥进行验证 . 我需要事务强烈一致，以便不能多次使用相同的许可证密钥 .
选项1：使用数据存储区
要使用数据存储区，我需要它具有很强的一致性，因此我将使用EntityGroup作为许可证密钥 . 但是，实体组的写入/秒限制为1 . Appengine请求必须在60秒内完成，因此这意味着要么在激活密钥时通知用户离线，要么让他们循环轮询直到他们的密钥被接受为止 .
选项2：使用Google Cloud SQL
即使是最小的Google Cloud SQL层也可以处理250个并发连接 . 我不希望这些查询花费很长时间 . 这似乎会更快，并且可以处理数百或数千个同步许可证密钥请求而没有任何问题 .
Google Cloud SQL的缺点是每个实例的大小限制为500GB . 如果我的空间不足，我将不得不创建一个新的数据库实例，然后查询提交的许可证密钥 . 我认为在消耗500GB之前需要很长时间，看起来您甚至可以通过联系Google来增加尺寸 .
看起来像Option2是要走的路 - 但我想知道其他人的想法 . 您是否发现可接受的交易的实体组表现？
3 回答
在您的情况下，选项2看起来更可行，整洁干净，但是如果没有正确使用连接池，则必须自己处理数据库连接并且增加负载会带来麻烦 .
数据存储区还可以在许可证密钥系统中使用，通过基于密钥的几个前导或尾随数字来定义具有虚拟祖先的多个EntityGroup，以处理对实体组的1个写入/秒 . 通过这种方式，您还可以轻松确定生成或提供的许可证密钥的EntityGroup .
例如 4321 G42T 531P 8922 是许可证密钥，因此 4321 可以用作EntityGroup，所有以4321开头的密钥都将成为此EntityGroup的一部分 . 这是一种类似于机制的分片，以避免同时写入单个实体组的可能性 .
如果需要对许可证密钥以外的某些列执行查询，则可以在没有EntityGroup的情况下维护单独的映射表 .
你可以混合它们，谷歌 Cloud SQL只有键和电子邮件，500G我相信你可以存储地球上所有人的关键 . 另一方面，您可以请求谷歌增加数据大小限制 .
我将使用选项1数据存储，它更快，可扩展 .
而且我不知道你为什么需要创建EntityGroup，你可以将“许可证密钥”本身作为密钥，因此每个实体都在它自己的EntityGroup中...只有这样才能使事情具有可扩展性 .