前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >实现近乎无限可扩展性的7种设计模式

实现近乎无限可扩展性的7种设计模式

作者头像
coderidea
发布2023-12-26 16:07:51
1390
发布2023-12-26 16:07:51
举报
文章被收录于专栏:coderideacoderidea

本篇主要总结了来自Pat Helland的令人印象深刻的论文《Life beyond Distributed Transactions: an Apostate's Opinion》中的设计模式。

实体唯一标识

在构建大规模分布式系统时,为了确保数据的唯一性和一致性,每个代表着独立数据集的实体都应该具有唯一的标识。这意味着我们需要为每个实体定义一个独一无二的键,以便能够有效地对其进行区分和操作。

多个不相交范围的事务可串行化

分布式系统中的事务管理是一个复杂而关键的问题。为了实现可伸缩性,我们需要确保事务的作用范围是有限的,不涉及多个不相交的数据实体。这样可以避免跨实体的原子事务,从而提高系统的并发性和性能。

至少一次消息传递

在分布式系统中,消息传递是组成不同组件之间通信的重要方式。应用程序必须具备至少一次消息传递的能力,即能够容忍消息的重复发送和消息到达的无序性。这是确保系统鲁棒性的关键因素之一。

消息寻址到实体

为了实现可扩展性,我们需要明确定义消息是如何寻址到特定实体的。这意味着我们不能将实体的唯一键的存在抽象化,而是需要在业务逻辑中考虑这些唯一键,以确保消息能够准确地定位到目标实体。

实体按参与方管理会话状态

为了保证系统的幂等性,每个实体需要能够管理与参与方的会话状态。这涉及到实体必须记住先前已经处理过的消息,以及在没有原子事务的情况下,使用某种工作流能力来“协商”处理结果。

替代索引不能存在于单一范围内

在分布式环境中,不能假设对实体的索引或引用可以原子地更新。由于存在并发操作,不同索引可能会出现不同步的情况。因此,在设计中需要考虑到这一点,以确保系统的一致性。

实体之间的消息传递是临时的

在分布式系统中,实体之间的消息传递必须能够容忍一定程度的不确定性。发送的消息应该被视为提交请求,但也可能会被取消。这种容错性是确保系统在面对各种异常情况时能够继续运行的关键。

与此同时,以上设计原则与构建Amazon S3时采用的设计原则相比较:

  1. 去中心化:采用完全去中心化的技术,消除系统的扩展瓶颈和单点故障,提高系统的可伸缩性。
  2. 异步性:确保系统在任何情况下都能取得进展,即使在异步的通信模式下也能够保持高效的运行。
  3. 自主性:每个组件都能够基于本地信息做出决策,实现系统的分布式自治,降低对全局状态的依赖。
  4. 本地责任:每个组件都负责自身一致性的维护,不依赖于其他同行的干预,从而提高系统的稳定性。
  5. 受控并发:通过设计操作,避免或最小化并发控制的需求,提高系统的并发性能。
  6. 容错性:将组件故障看作是正常操作模式的一部分,系统能够在组件失败时继续运行,保持高可用性。
  7. 受控并行性:使用精细的抽象粒度,使系统能够利用并行性以提高性能和系统的健壮性。
  8. 分解成小而易理解的构建块:避免设计一个单一服务尝试做所有事情,而是构建小组件,它们可以作为其他服务的构建块。
  9. 对称性:确保系统中的节点在功能上是相同的,减少节点特定的配置需求,提高系统的可维护性。
  10. 简单性:通过保持系统足够简单,但又不过于简单,降低系统的复杂性,提高可理解性。

这些设计原则共同构建了一个强大而高效的分布式系统,旨在应对大规模和高复杂性的挑战。通过理解和应用这些原则,开发者能够更好地构建可靠、可伸缩、高性能的分布式应用。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-12-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 coderidea 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档