可扩展性的设计模式（或技术）
您使用过哪些专门针对可扩展性的设计模式或技术？
在我看来，Flyweight 等模式是一种工厂模式的专用版本，促进高可扩展性或在内存或存储限制内工作时。
你还用过哪些？ （数据库非规范化等.) 当高可用性或可扩展性成为您的主要目标时，您是否发现规则发生了变化？
可能的情况有：
- 与台式机或笔记本电脑相比，移动设备的内存、处理能力和连接性更有限
- 硬件有限的用户数量较多（缓存策略等）
- 优化数据库模式以提高效率，而不是标准化设计（例如 SharePoint 列）包装储存）
What design patterns or techniques have you used that are specifically geared toward scalability?
Patterns such as the Flyweight pattern seem to me to be a specialized version of the Factory Pattern, to promote high scalability or when working within memory or storage constraints.
What others have you used? (Denormalization of Databases, etc.) Do you find that the rules change when high availability or scalability is your primary goal?
Possible situations are:
- Mobile devices with more limited memory, processing power, and connectivity than a Desktop or Laptop
- High # of users on limited hardware (caching strategies, etc)
- Optimization of database schema for efficiency in lieu of a normalized design (e.g. SharePoint column wrapping for storage)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
想到的一些模式：
一些资源：
A few patterns that come in mind:
Some resources:
使应用程序尽可能无状态。将更容易适应服务器场。
Make the application as stateless as possible. Will be easier to adapt to a server farm.
没有什么是免费的 - 这取决于为了实现您的业务目标可以接受哪些妥协。主要变量有：
一篇出色的论文< /a> 阅读该主题。
我相信一个好的衡量标准是检查“成本/用户”曲线并尝试将其保持为线性进展（假设每个用户可接受的成本是一个已知参数:-)
设计模式确实发挥了作用，但它是总体架构这才是最重要的。人们可能在模块级别上非常彻底，但错过了网络级别的限制，因此可扩展性受到影响。
归根结底，我相信人们必须问自己：对于X类型的故障，有多少“用户”会受到影响，影响多久？
某处总会存在 SPOF（单点故障），但人们可以设计一种系统，使该 SPOF 更靠近端点（例如用户）。但在许多情况下，SPOF 不受应用程序的控制，例如网络 POP 不可用。
无论如何，我可以花几个小时在这个主题上......
Nothing is free - it comes down to what are the acceptable compromises in order to meet your business objectives. The main variables being:
An excellent paper to read on the subject.
I believe a good metric would be to examine the "cost/user" curve and try maintaining it to linear progression (assuming the acceptable cost per user is a known parameter :-)
The Design Patterns do play a role but it is the overarching architecture that matters most. One might have been very thorough at the module level but missed network level constraints and scalability suffers as a consequence.
At the end of the day, I believe one must ask himself (herself): for failure type X, how many "users" can be affected and for how long?
There will always be a SPOF (Single Point Of Failure) somewhere but one can engineer a system such that this SPOF is moved closer to the end-points (e.g. users). In many cases though, the SPOF is out of the control of the application e.g. network POP unavailable.
Anyway, I could spend hours on the subject...
POSA（面向模式的软件架构）书籍是此类模式的重要来源。
POSA 4 特别关注分布式计算，但所有卷都是充满可扩展性模式。
The POSA (Patterns-Oriented Software Architecture) books are a great source for such patterns.
POSA 4, especially, is concerned with distributed computing, but all the volumns are full of scalability patterns.
我对无状态应用程序逻辑的观察是，它引入了许多其他要求，例如锁定数据库，最终会影响可扩展性。
假设部署的应用程序逻辑在服务器场中是无状态的，那么对于同时访问集群的两个节点的请求，我们必须引入数据库锁定等概念，以确保只处理一个请求。
我现在正在处理这种情况，想知道其他人是如何处理这种无国籍行为的。
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.