25

您使用了哪些专门针对可伸缩性的设计模式或技术？

Flyweight模式等模式在我看来是Factory Pattern的特殊版本，用于提高可伸缩性或在内存或存储限制下工作。

你还用过什么其他的？（数据库的非规范化等）当高可用性或可伸缩性是您的主要目标时，您是否发现规则发生了变化？

可能的情况有：

  • 与台式机或笔记本电脑相比，内存、处理能力和连接性更有限的移动设备
  • 有限硬件上的高用户数（缓存策略等）
  • 优化数据库架构以代替标准化设计（例如用于存储的 SharePoint 列换行）以提高效率
4

5 回答 5

45

想到的几个模式：

  • 无状态应用
  • 松耦合
  • 异步
  • 延迟加载
  • 缓存
  • 并行性
  • 分区
  • 路由

一些资源：

于 2009-09-17T15:26:41.410 回答
10

使应用程序尽可能无状态。将更容易适应服务器场。

于 2009-09-17T15:19:54.890 回答
6

没有什么是免费的 - 归根结底，为了满足您的业务目标，可以接受哪些折衷方案。主要变量为：

  • 成本
  • 可用性
  • 一致性
  • 生存能力（例如，分区容限）

一篇关于该主题的优秀论文。

我相信一个好的指标是检查“成本/用户”曲线并尝试将其保持为线性进展（假设每个用户可接受的成本是一个已知参数:-)

设计模式确实发挥了作用，但最重要的是总体架构。一个人可能在模块级别非常彻底，但错过了网络级别的约束和可扩展性因此受到影响。

归根结底，我相信一个人必须问自己（她自己）：对于X型故障，可以影响多少“用户”，影响多长时间？

在某处总会有一个 SPOF（单点故障），但可以设计一个系统，使这个 SPOF 更靠近端点（例如用户）。但在许多情况下，SPOF 不受应用程序的控制，例如网络 POP 不可用。

无论如何，我可以花几个小时在这个主题上......

于 2009-09-17T15:24:59.033 回答
2

POSA（面向模式的软件架构）书籍是此类模式的重要来源。

POSA 4尤其关注分布式计算，但所有卷都充满了可扩展性模式。

于 2009-09-17T15:48:29.330 回答
1

What i have observed with Stateless application logic is that it introduces many other other requirements like locking on DB which eventually then work against scalability.

Lets say that the application logic deployed is stateless across a server farm then for a request which is hitting two nodes of a cluster at same time we have to introduce concepts like DB locking to make sure only one request will be processed.

I am dealing such situations now and was wondering how everyone else is dealing with such stateless behavior.

于 2012-12-05T02:45:45.327 回答