被大佬问到自闭！MongoDB数据分布不均的解决方案，HR的话扎心了

前言

在大数据、高并发的系统中，为了突破瓶颈，会将系统进行水平扩展和垂直拆分，形成独立的服务。每个独立的服务背后，可能是一个集群在对外提供服务。这就会碰到一个问题，整个系统是由多个服务(子系统)组成的，数据需要在各个服务中不停流转。如果数据在各个子系统中传输时，速度过慢，就会形成瓶颈，降低整个系统的性能。从而就形成了以Kafka为中心的解决方案！

因为阅读Kafka源码重要性就不言而喻，今天小编就分享一份拼多多Kafka的源码笔记，现已面向大众全面开源！（为了不影响大家的阅读体验，免费获取方式放在了文末！）

这份笔记从Kafka的应用场景、源码环境搭建开始逐步深人，不仅介绍Kafka的核心概念，而且对Kafka生产者、消费者、服务端的源码进行深人的剖析，最后介绍Kafka常用的管理脚本实现，让读者不仅从宏观设计上了解Kafka,而且能够深人到Kafka的细节设计之中。在源码分析的过程中，还穿插了笔者工作积累的经验和对Kafka设计的理解，希望读者可以举一反三， 不仅知其然，而且知其所以然。

常见的分布式事务场景

分布式事务其实就在我们身边，你一直在用，但是你却一直不注意它。

转账

扣你账户的余额，增加别人账户余额，如果只扣了你的，别人没增加这是失败；如果没扣你的钱别人也增加了那银行的赔钱。

下订单/扣库存

电商系统中这是很常见的一个场景，用户下单成功了，店家没收到单，不发货；用户取消了订单，但是店家却看到了订单，发了货。

分库分表场景

当我们的数据量大了之后，我们可能会部署很多独立的数据库，但是你的一个逻辑可能会同时操作很多个数据库的表，这时候该如何保证所有的操作要么成功，要么失败。

分布式系统调用问题

微服务的拆分让各个系统各司其职，但是带来的也有很多痛苦，一个操作可能会伴随很多的外部请求，如果某一个外部系统挂掉了，之前操作已完成的这些是否需要回滚。

针对上面这些问题，我们前面学过的数据库4大特性：ACID 似乎在这里想要达到就变得很困难，单机情况下你还可以通过锁和日志机制来控制数据，在分布式场景又该如何实现呢？在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。尽管有这么多工程细节需要考虑，但分布式事务最核心的还是其 ACID 特性，只是这种 ACID 变换了场景。

分布式理论

CAP 定理

传统的 ACID 模型肯定无法解决分布式环境下的挑战，基于此加州大学伯克利分校 Eric Brewer教授提出 CAP 定理，他指出 现代 WEB 服务无法同时满足以下 3 个属性：

• 一致性(Consistency) ： 所有的客户端都能返回最新的操作。
• 可用性(Availability) ： 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用，操作依然可以完成。

关于一致性的理解后面分出来三个方向：

• 强一致：任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。
• 弱一致：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
• 最终一致：不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

关于一致性的理解不同，后面对于 CAP 理论的实现就有所不同。

另外 Eric Brewer教授指出现代 WEB 服务无法同时满足这 3 个属性，说的是无法同时满足，那这是为什么呢？

如果在某个分布式系统中无副本，那么必然满足强一致性，同时也满足可用性，但是如果这个数据宕机了，那么可用性就得不到保证。

如果一个系统满足 AP，那么一致性又得不到保证。所以 CAP 原则的精髓就是要么 AP，要么 CP，要么 AC，但是不存在 CAP。

BASE 定理

基于前面提到的 CAP，反正我们都无法同时满足CAP，设计系统的最高目的就是让他跑下去不出错，那么是不是可以不要求强一致性，最终让他一致即可。所以后面又提出来了 BASE 定理：

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

基于现在大型分布式系统的复杂性，我们无法保证服务永远达到999，那么是否可以取舍，核心服务达到999，非核心服务允许挂为了保全核心服务。另外在非核心服务 down 机过程中允许系统暂时出现不一致但是这个不一致并不影响系统的核心功能使用。

最终系统恢复，所有服务一起修复数据，最终达到一致的状态。

业内通常把严格遵循 ACID 的事务称为刚性事务