分布式CAP定理指南

     

CAP定理的缺点

33 2K

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

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

46

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

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

60 12K

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

缓存Caffeine与Sieve比较

60 3K

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

分布式 PostgreSQL 架构概述

82 8K

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

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

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

分布式系统中的 CAP 定理权衡

90 3K

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

十个数据库错误偏见

71

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

PACELC定理与CAP定理比较

183

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

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

110 6K

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

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

258 1 2K

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

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

109 4K

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

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

96 5K

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

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

62 3K

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

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

219 1 7K

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

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

120 2K

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

Epoxy分布式事务简介

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

Kafka 事务的一次性语义

308 4K

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

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

390 1 4K

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

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

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

纳秒时间戳不适合做唯一标识符

339

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

一致性模式

537 3K

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

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

575

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

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

440 2K

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

分布式系统8种认知偏见

473 2K

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

如何解决不同数据库和服务之间的事务问题?

443

在我这个项目中,有多个数据库和服务需要无缝通信和交换数据。然而,在这些不同的系统中保持交易的完整性已被证明是一个相当大的障碍。我想确保所有相关操作要么成功,要么失败,避免任何不一致或数据差异。我正在使.

微服务分布式事务指南大全

987 1 17K
本白皮书汇总了经典事务和分布式事务的概念。然后,我们解释了基于云的应用如何受到分布的影响。最后,我们介绍了基于补偿的事务,作为基于微服务的应用事务的可靠方法,即使是在云中。1、经典事务我们将简要概述事.

分布式缓存综合指南

543 1 7K
一个重要的网站需要一个网络服务器来接收请求和一个数据库来写入或读取数据。但是,如果每秒收到数百万个请求,这种简单的设置只有在优化数据库或更改整体数据库策略后才能扩展。那是对的吗?数据库最终达到了活动连.

Kafka的关键配置min.insync.replicas

561

Kafka的关键配置min.insync.replicas :用户消息生产的客户端配置,表示消息生产者认为写入成功之前确认收到记录的代理数量。 - acks==0 — 发送请求时认为写入成功 - 无需.