在横向扩展架构中如何处理单例代码+数据？答案

【问题标题】：How is singleton code+data handled in scale-out architectures?在横向扩展架构中如何处理单例代码+数据？
【发布时间】：2013-07-24 09:12:02
【问题描述】：

这更像是一个概念性问题，但也欢迎针对（JBoss 等）等开源产品的特定答案。

如果我的企业应用程序需要扩展并且我想选择横向扩展模型（而不是纵向扩展）模型，多个应用服务器实例将如何保留一段代码/数据的单例语义？

示例：假设我有一个 ID 生成类，其逻辑要求将其实例化为单例。此类可能会或可能不会与底层数据库对话。现在，我如何确保在横向扩展时保持此类的单例语义？

其次，是否有一本书或在线资源既列出了这些概念性问题又提出了解决方案？

编辑： 一般来说，如何处理应用服务器层中的通用应用程序状态以允许应用程序横向扩展？我应该进一步探索哪些设计模式、软件组件/产品等？

【问题讨论】：

“我有一个 ID 生成类” - 使用 GUID 然后就不需要该类了....
谢谢，但那是“假设”的情况。这个问题一般是如何解决的？如果答案恰好是“首先避免问题”，那么我会很好，但我仍然希望得到网络应用程序和扩展专家的确认。
我并不是说你不是扩展专家，如果我传达了这个印象，我很抱歉。但我确实想要一个确认，显然你似乎给了一个。但是我的问题是，一般来说，应用服务器层中的状态是如何维护的，以允许应用程序向外扩展？
避免 ID 往返的标准技术是使用中间层生成的 GUID。一般状态扩展的问题是一个不同的问题。
我在原始问题中添加了 EDIT。

【解决方案1】：

您越往外扩展，您就越无法以原子方式管理全局静态。换句话说，如果您有 100 台服务器需要共享状态（知道在 ID 生成单例类中下一个 ID 是哪个 ID），那么我所知道的没有一种技术可以快速、原子地为您获取该 ID。

在 ID 生成方面，数据必须在机器之间传输。

对于您提到的场景，我可以想到几个选项：

在接受新 ID 之前等待所有计算机赶上/同步。您可以在本地生成 ID，然后检查它是否适用于其他机器 - 或者 - 运行作业以在所有机器上获取下一个 ID（想想 map/reduce）。
考虑分片。通过分片，您可以“本地”生成 ID，并保证具有唯一性。因此，如果您有 100 台机器，那么 1-10 台机器供加利福尼亚的用户使用，11-20 台机器供纽约的用户使用，等等。选择分片键可能很困难。
开始寻找消息传递系统。您可以在一台机器上本地创建/修改您的对象，然后将结果发送到服务总线/消息系统，其他机器订阅主题/队列并可以获取该对象并对其进行处理。
选择一个可水平扩展的数据库来管理对象。他们已经解决了同步和复制的问题。

【讨论】：

谢谢。即将将您的答案标记为最终答案，但是...您想就应用程序服务器实例中其他通用状态的处理说一两句话...因为 ID 只是一个示例？这显然是一个新手问题——我不知道世界上的开发人员将如何处理这个问题！如果您愿意，我也可以单独提出这个问题，但请务必尽快回复。
一般的状态和对象......如今 NoSQL 的趋势是拥抱最终一致的数据。这个想法是您的写入最终将传播到水平可扩展集群中的所有机器，但是有一段时间......您的数据将不一致。如果你从一开始就是这样想的，那么你编写的代码就会有点不同。来自 YouTube 的一个简单示例：当您喜欢一个视频时，他们会使用 Javascript 将喜欢计数增加 1 并开始写入。他们会立即给出看起来像写的反馈，但实际的写还没有完成。
感谢 YT 的示例。