分布式CAP定理指南

     
  • 分布式缓存基础教程

    38 6K

    缓存是增强分布式应用程序性能和可扩展性的关键技术。这篇文章“掌握分布式应用程序中的缓存”全面概述了高级缓存技术和策略。在大规模分布式应用程序中缓存很难,团队经常会经历一个迭代和实验的过程来调整他们的缓.

  • 分布式系统:常见陷阱和复杂性

    63 6K

    分布式系统的复杂性对于工程师和开发人员来说是一个重要的挑战。随着系统的发展,复杂性往往会增加,因此积极主动很重要。让我们谈谈您在工作中可能会遇到哪些类型的复杂性以及处理这些复杂性的有效策略。分布式系统.

  • 分布式系统CAP定理教程

    53 4K

    本文探讨了 CAP 定理。理解 CAP 对于设计分布式系统至关重要,我们将深入研究每个属性的含义。什么是分布式系统?分布式系统将计算和数据分布在网络内的多个互连节点上。这可能涉及卸载处理能力或在地理上.

  • 分布式缓存架构综述

    106 5K

    本文研究了分布式缓存,强调了它通过改进数据访问和可扩展性对应用程序性能的影响,并提供了实用指导。什么是分布式缓存?分布式缓存是指将信息存储在多个服务器上的方法,这些服务器通常分布在不同的地理位置。与集.

  • CAP定理的缺点

    73 2K

    2000 年,埃里克-布鲁尔(Eric Brewer)在 "分布式计算原理会议"(Principles of Distributed Computing conference)上发表题为 "迈向稳健的.

  • Uber是如何花费巨大精力实现缓存精确失效?

    117

    这篇文章介绍了Uber内部分布式数据库Docstore的架构、挑战以及他们构建的集成缓存解决方案CacheFront。文章详细介绍了CacheFront的设计、特性和实现,以及对最终结果的评估。通过C.

  • 分布式数据库系统中主从、主主和无主三种复制算法

    124 12K

    分布式系统中的复制对于确保数据一致性、可用性和系统弹性至关重要。这是一种将数据存储在多个节点或服务器上的策略,即使在服务器故障或维护期间也可以防止数据丢失并实现不间断访问。1、单领导者主从复制:涉及一.

  • 缓存Caffeine与Sieve比较

    151 3K

    Caffeine缓存作者:背景信息Caffeine 使用自适应窗口技术,因此不会完全影响您的观察结果。论文建议将 1%的窗口作为起点,因为这在数据库、搜索和分析等许多关键工作负载中都很有效。论文最后指.

  • 分布式 PostgreSQL 架构概述

    130 8K

    许多分布式数据库讨论的重点都是分布式查询规划、事务等方面的算法。这些都是非常有趣的话题,但事实上,作为一名分布式数据库工程师,我只有一小部分时间花在算法上,而过多的时间花在了在各个层面进行非常谨慎的权.

  • rockscache:保证与DB最终或强一致性的Redis缓存库

    284 11K
    随着缓存的引入,分布式系统中的一致性问题出现了,因为数据同时存储在两个地方:数据库和Redis。到目前为止,我们看到的所有缓存解决方案,如果没有在应用程序级别引入版本控制,都无法解决数据不一致场景。目.
  • 分布式系统中的 CAP 定理权衡

    174 3K

    在本文中,我们将踏上揭开 CAP 定理复杂性的旅程,通过简单但相关的数据库类比的视角探索其意义和含义。1.什么是CAP定理?CAP 定理,也称为 Brewer 定理,是分布式系统中的一个基本原则,它阐.

  • 十个数据库错误偏见

    105

    关于数据库,你会听到的十个“错误”的事情: 1)SQL数据库不能扩展。 2)ACID中的一致性= CAP中的一致性 3)CAP中的可用性是指“高可用性”  4)NoSQL数据库不使用B树 5)所有数据.

  • PACELC定理与CAP定理比较

    224

    根据CAP定理,数据库即使在15天后才返回查询响应,也是可用的,但对于任何真实世界的应用程序来说,这种延迟是不可接受的。什么是CAP定理CAP定理是分布式计算领域的一个基本理论,它由计算机科学家Eri.

  • PolarDB-SCC:阿里低延迟强一致性读取的云数据库分析

    152 6K

    阿里巴巴组的这篇论文讨论了如何在PolarDB数据库部署中从从节点执行低延迟强一致性读取。发表在VLDB'23 上。PolarDB采用关系型数据库规范的主从架构。主节点是读写 (RW) 节点,辅助节点.

  • 分布式系统中的乐观和错误假设

    296 1 2K

    避免协调是让我们构建的分布式系统超越单机性能的一个基本要素。当我们构建避免协调的系统时,我们最终构建的组件会假设其他组件在做什么。这一点也很重要。如果两个组件不能在每一步操作后都互相检查,那么它们就需.

  • Epoxy:跨不同数据存储的 ACID 事务

    145 4K

    Epoxy 利用 Postgres 事务数据库作为主数据库/协调数据库,并扩展多版本并发控制 (MVCC) 以实现跨数据存储隔离。它通过乐观并发控制 (OCC) 和两阶段提交 (2PC) 协议提供隔离.

  • 缓存如何满足每日 12 亿个API请求?

    132 5K

    在 RevenueCat,我们每天处理超过 12 亿个请求。只有在以下情况下您才能有效地做到这一点: 您可以在许多 Web 服务器之间分配负载。 您可以使用缓存来加速对热数据的访问并保护后端系统和数据.

  • 帮助理解分布式系统复制算法的开源项目

    102 3K

    在分布式系统中,快速编码和测试对于理解Paxos等复杂概念至关重要。这个小框架来快速编写和测试各种复制机制。可以快速实现复制算法并编写 JUnit 测试。它还提供了引入进程崩溃、网络断开、网络延迟和时.

  • Go中悲观锁、乐观锁+2PC实现分布式事务

    293 1 7K

    在本文中,我将在基本的酒店预订系统中使用 Go 实现2PC(两阶段提交),并使用悲观锁定和乐观锁定。在此系统中,我们将重点创建预订流程并将使用 PostgreSQL 数据库。您可以在这里找到源代码!为.

  • 又是每个程序员都应该知道的:幂等性

    167 2K

    在编程世界中,每个开发人员都应该理解许多概念,以便构建高效可靠的系统。其中一个重要的概念是幂等性,它指的是操作或函数的属性,多次应用时产生的结果与仅应用一次时产生的结果相同。这似乎是一个简单的概念,但.

  • Epoxy分布式事务简介

    388 3K
    传统的解决方案是通过像X/Open XA这样的协议使用两阶段提交。 然而,虽然XA被大多数大型关系数据库(如Postgres和MySQL)支持,但它不受流行的更新数据存储(如MongoDB,Cassa.
  • Kafka 事务的一次性语义

    356 4K

    事务为发布到 Kafka 的一组消息提供原子性、一致性、隔离性和持久性 (ACID) 的保证。这意味着要么事务中的所有消息都将成功写入 Kafka,要么不会写入任何消息。在确保数据一致性和避免任何数据.

  • cloudflare在多租户数据库环境中遭遇的问题与挑战

    451 1 4K

    以 Cloudflare 规模运营意味着我们在整个技术堆栈中花费大量时间来处理不同的负载条件。在这篇博文中,我们讨论如何使用 Postgres 集群解决性能难题。这些集群支持大量租户和高度可变的负载条.

  • 用生活案例形容说明什么是CAP定理

    420 1 3K
    您经常会听到 CAP 定理,它规定了设计分布式系统时的某种上限。第 1 章:成立"纪念公司" :昨晚,当你的妻子感谢你记得她的生日并给她带了礼物时,你突然产生了一个奇怪的想法。人们总是记不住事情。而你.
  • 纳秒时间戳不适合做唯一标识符

    386

    在现代系统中,纳秒时间戳碰撞的频率有多高?答案是:非常频繁,比如在同时读取所有 4 个物理内核的时钟时,有 5%的样本会发生碰撞。因此,采用原始纳秒时间戳作为唯一标识符是不安全的。 test prog.

  • 一致性模式

    603 3K

    分布式系统中的一致性模型:在分布式数据系统的三个属性(一致性、可用性和分区容错性)中选择两个。- Eric Brewer,CAP 定理分布式系统具有可扩展性和容错性等优点。然而,维持分布式系统的一致性.

  • typeid:受 Stripe ID 启发的类型安全、K-sortable、全局唯一标识符

    631

    TypeIDs是UUIDv7的一个现代的、类型安全的扩展。TypeIDs被规范地编码为小写的字符串,由三部分组成: 一个类型前缀 一个下划线'_'分隔符 一个128位UUIDv7编码为base32的2.

  • 基于Http的ETags和If-Modified-Since实现乐观并发性

    486 2K

    HTTP的特点是ETags和条件性请求,并启用乐观的并发性。ETagETag(又称实体标记entity-tag)解决了 "丢失更新 "的问题,即一个API的两个客户端已经收到了一个实体的版本的数据。但.

  • 分布式系统8种认知偏见

    515 2K

    分布式系统的谬误是由L Peter Deutsch和Sun Microsystems公司的其他人提出的一套论断,描述了刚开始接触分布式应用的程序员总是做出的错误假设。微服务的大规模采用,迫使更多的工程.