您使用的设计模式或技术专门针对可扩展性？
Flyweight模式等模式在我看来是Factory Pattern的专用版本，以提升高可伸缩性或在内存或存储限制内工作时。
你还有别人用过什么？ （Denormalization of Databases等）当高可用性或可扩展性是您的主要目标时，您是否发现规则会发生变化？
可能的情况是：
答案 0 :(得分：45)
记住一些模式：
一些资源：
答案 1 :(得分：10)
使应用程序尽可能无状态。将更容易适应服务器场。
答案 2 :(得分：6)
没有什么是免费的 - 它归结为为了实现您的业务目标而可接受的妥协。主要变量是：
关于这个主题的优秀paper。
我认为一个好的指标是检查“成本/用户”曲线并尝试将其保持为线性进展（假设每个用户可接受的成本是一个已知参数： - ）
设计模式确实发挥了作用，但它是最重要的总体架构。一个人可能在模块级别上非常彻底，但是由于错过了网络级别的限制和可扩展性，因此会受到影响。
在一天结束时，我相信一个人必须问自己（她自己）：因为X型失败，有多少“用户”会受到影响以及持续多长时间？
在某处总会有一个SPOF（单点故障），但是可以设计一个系统，使这个SPOF更靠近终点（例如用户）。但是，在许多情况下，SPOF不受应用程序的控制，例如网络POP不可用。
无论如何，我可以在这个问题上花上几个小时......
答案 3 :(得分：2)
POSA（面向模式的软件架构）书籍是这种模式的重要来源。
POSA 4尤其关注分布式计算，但所有的版本都充满了可伸缩性模式。
答案 4 :(得分：1)
我在无状态应用程序逻辑中观察到的是，它引入了许多其他要求，例如锁定数据库，这最终会影响可伸缩性。
让我们说部署的应用程序逻辑在服务器场中是无状态的，然后对于同时命中集群的两个节点的请求，我们必须引入像DB锁定这样的概念，以确保只处理一个请求。
我现在处理这种情况，并想知道其他人是如何处理这种无国籍行为的。