分布式CAP定理指南

我们在今年2月跨越了YugaByte DB三年开发阶段，到目前为止，这是一段惊心动魄的旅程，但并非没有公平的技术挑战。有时我们不得不回到绘图板

分布式系统中时间是核心概念，依靠时间多个机器才能协同交互。分布式数据库 微服务交互都逃不过这个硬核。本文概括了物理时钟和逻辑时钟等概念。作为软件工程师，我们都依赖于时间概念：确保我们程序中的事件遵循时间顺序的关键概念。然而，调用“获取当前时间”的简单调用可能会产生意外结果，如果使用不

Zeebe是一种全新的工作流/编排引擎，适用于云原生和云规模应用。本文介绍如何使用Zebee进入云规模的工作流程自动化的新时代。Zeebe是一个真正的分布式系统，没有任何中心组件，根据一流的分布式计算概念设计，符合

CAP定理指出，在网络分区的情况下，不可能同时保证一致性和可用性。由于网络分区在可扩展的分布式系统中理论上是可行的，因此现代可扩展数据库系统的架构师分为两大阵营：优先考虑可用性的阵营（NoSQL阵营）和优先考虑一致性的阵营（NewSQL阵营）。 有一段时间

Spring Cloud 原本来自Netflix OSS，但是目前面临服务网格竞争，以及Netflix宣布放弃Hystrix，Spring Cloud与服务网格Istio竞争中

Hystrix是一个非常成熟的库，用于隔离分布式系统中的远程操作。通常只有在“纯”微服务架构中运行时才由开发人员考虑。但是即使我们的项目“只有”一个或两个连接到外部系统，是否也值得一试呢？我想是的，但是如果您的项目连接到某些外部系统，可以试试Hystrix。

当你你写了一个bash脚本，但是由于错误而运行一半退出了，当您修复了系统中的错误并再次运行这个脚本。但是脚本中的一半步骤会立即失败，因为它们已经作用于您的系统了。要构建弹性系统，您需要编写幂等的软件。（幂等在分布式环境同样重要，这样才能保证重试等正确实现）

你知道那种感觉吗？您有一个Web服务应用总是没有一个最佳的正常运行时间？我的工作团队肯定是有的，我们认为现在是改变的时候了。整篇文章都是作为教程编写的。您可以在

我最近一直在研究一个新项目，它需要在并发访问之间保持数据强一致性。为了更好地理解这个问题，可以考虑以下应用场景： 如何始终保持您的银行帐户余额正确 如何正确处理货架上的产品数量 如何正确处理视频或文章的喜欢或观看次数 你应该想知道管理这些问题的复杂性

开发人员在任何软件项目过程中都会做出数百个微观和宏观决策。有些似乎相对无害，但对下游会有一个很大的影响。几位Cantina工程师聚在一起，回顾了我们在学习了一些艰苦的经理后需要特别考虑的关键点。 1. 利益相关者要求

REST调用或同步是服务器之间通讯的经常方式，在没有分布式事务机制保障情况下，需要我们开发人员手工进行重试，重试几次失败后进行业务回退操作，重试非常重要，容易造成网络堵塞，引入断路器又过于重量，完善重试算法也许是一条出路： 在处理我们的应用程序时，我们不得

MongoDB和一般的文档数据库解决了传统关系数据库的一些问题：严格的模式 - 使用关系数据库，如果你有动态形态的数据，你不得不创建一堆随机的“杂项”数据列，将数据作为一个数据块推送，或使用

前文讨论了数据库的多领导者复制，现在看看无领导者复制： 无领导者复制亚马逊的Dyn

分布式事务的关键是实现强一致性，但是CAP定理认为获得强一致性必然放弃可用性，这是传统关系数据库和2PC的问题所在，最终一致性可以兼顾一致性和可用性，强最终一致性则更好，因此分布式事务的发展方向走向强最终一致性的一致性模型，强最终一致的模型实现有几种，比如Paxos和Raft，但是这些只适合

Noria:  https://pdos.csail.mit.edu/papers/noria:osdi18.pdf Ma

Dmitry Martyanov谈到PayPal如何开发处理一致性问题的分布式系统，并分享他在开发基于最终一致数据存储的系统中学到的经验教训。该解决方案利用无冲突，复制的数据类型CRDT和因果关系跟踪，实现多主数据中心数据库部署中关键数据的强大最终一致性。