分布式共识一致性教程

本文主要解释了区块链中的重要功能：工作证明(Proof-of-Work)。主要说明工作证明对于区块链是一个重要特征，而且是必须的；区块链中其他经常被提及特征（如安全性）反而是次要的，虽有用但非必须。 本文的解释主要是基于区块链工作证明的一些有趣特性，这些特

MongoDB版本3.6.4和4.0.0-rc1实现因果一致性（CC）支持，只要用户一直连接到majority 读写会话上，就能实现因果一致性，如果这种CC会话失败出错，也能提供不变性约束（数据完整性）。 背景

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

你知道吗？二手交易网转转的数据库用的是什么？本文由TiDB / TiKV的首席架构师Ed Huang发表，虽然有软文嫌疑，但是从其研发的最先进分布式数据库经验角度看，这五个问题还是很干货的。TiDB/TiKV分布式数据库是一种高一致性的分布式事务数据库，存储使用Rust编写，SQL计算使用Go语言，

Distributed Systems Consensus timeline:- 1989: consensus is Paxos.- 2013: consensus is Raft.- 2018: consensus is that computers are terrib

CKEditor 5推出分布式修改同一份文档的功能，好像以后大家可以一起愉快地修改代码了，再也不用手工解决Git的冲突，在选择你的源码还是我的源码之间冲突，大师Kent beck还为此提出对人行为的约束规则：test && commit || revert。闲话少说，看看它的分布式一致性方案

我将直接告诉你：事件溯源Event Sourcing实际上有缺点的，如果您在互联网上阅读了有关该主题的任何内容，这句话肯定会让您感到震惊。毕竟，它通常是给人一种阳光和彩虹的美好感觉，当你遇到了什么问题时，都可以通过事件溯源来解决的。你生活中的大部分烦恼可能都是由于缺乏事件溯源造

我开始认为CQRS分离方向是错误的，我们不应该在命令和查询之间分离责任，而是在业务需要强烈一致的操作和可能弱一致的操作之间。这意味着如果业务需要读取您自己的写入，那么您不必向后弯曲以实现它，您只需在强一致性方面执行该读取操作。它还允许更灵活的写入，因为您可以在业务允许的弱一致

Hyperledger Fabric是一个分布式区块链网络，其中多个组件自己保留的共享分类帐复制副本，即所有交易的历史记录。当新交易发生时，它们必须通过网络发布，使分类帐的所有复制副本同步到一致的数据。 在较高的层次上，该流程如下所示： <

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

苹果终于开源其威力巨大的强一致性分布式数据库，根据CAP定理，在分布式分区的情况下，如果想保持强一致性是很难的，Google的Spanner进行了这方面创新，可惜没有开源，如今另外一个世界顶级数据库苹果的FoundationDB开源了，其官方声明如下： F

事务很难，分布式事务更难，WAN上的分布式事务是最终的老板硬度。- 安迪帕夫洛 FaunaDB是一个分布式数据库平台，支持可序列化，外部一致（也称为严格可序列化）事务。与Google Spanner或类似系统不同，FaunaDB不依赖物理时钟同步来

这是数据库数据复制技术续集，前文讨论了单领导者复制。现在让我们讨论一个替代方案，并探讨自己的挑战，并尝试确定使用它的方案。考虑多领导方法的主要原因是解决了当我们只

随着时间的推移变得越来越复杂和越来越苛刻。Google的Spann

在基辅召开的JEEConf会议上，Amitay Horwitz描述了他和他的团队如何实施事件溯源的发票系统，他们在生产2年半后遇到的挑战以及他们如何使用Kafka Streams实施新设计。 Wix的软件工程师Horwitz 于2015年开始与他的团队一起

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