分布式一致性协议与事务

1. 写在最前面

从隔壁大佬那边借来了 zookeeper 的协议 zap 的论文介绍，原本想对比一下 zap 和 raft 协议的异同。但是脑海里突然想到一句话「授人以鱼，不如授之以渔」。很多时候知识本身并不能产生多大价值，真正产生价值是要理解该知识使用的场景。

注：本文并不会过多介绍分布式事务和一致性性协议的细节，仅从使用场景的角度进行分析。

2. 解决的问题

2.1 从流量说起

🤔 思考一个业务场景，假设服务 300 qps 请求，是不是压根就不需要考虑分布式事务、一致性协议之类的问题，请求完全可以靠单机就能够抗住。

那么随着业务的扩展流量增加到 3kqs 或者 300k qps 应该玩耍呢？

总结：

• 单机：业务量很小，代码均放在一个项目中，项目部署的时候使用一台服务器

• 集群：单机处理达到瓶颈的时候，单机复制几份，构成一个「集群」

  注：集群附加引入了负载均衡（LB）的概念

• 分布式：将一个完整的系统，按照业务功能，拆分成一个个独立子系统，子系统之间通过 RPC 调用进行通信。例子🌰：将一个电商服务，拆分成用户服务、产品服务、订单服务、后台管理服务、数据分析服务等。

  拆分子系统的优点：

  • 解耦，各个子系统可以独立开发、测试、部署（ps 多人开发一份系统，解冲突想不想要原地爆炸💥
  • 细粒度优化系统的瓶颈，比如订单服务到瓶颈的时候仅仅扩容订单服务的集群即可
  • 复用性，比如将用户系统作为单独的服务，为该公司的所有产品提供服务，减少重复代码的开发

2.2 从一主多从到分布式一致性协议

古人教育我们「鸡蛋不要放在一个篮子里」，同理为了服务的稳定性，在真实的生产环境下，对企业而言重中之重的用户和服务数据常常是备份在多个服务节点上。

注：事情不可能只有一面，多备份为容灾带来了好处，但同时也会服务的可用性和性能带来了影响。

2.2.1 一主多从

假设在一主多从数据备份的场景下，对于服务而言：

• 性能：整体性能的瓶颈会受到处理最慢的节点影响。比如：server1/server3/server4 已经完成了同步，但是因为处理速度较慢的 server2 并未完成，所以对于 server 整个操作也就没有完成
• 可用性：一旦 server2 处于不可用的情况下，整个 server 即不可用，增加了不可用的风险

2.2.2 分布式一致性协议

提问：分布式一致性协议真的有传闻中的那么优秀嘛？

注：分布式一致性协议是为了维护各个节点数据的一致性，换句话说，就是使集群中节点存储的数据一模一样。

根据大部分分布式一致性协议设计的思路，假设集群中有 n 个节点，Leader 节点，只要收到 n/2+1 Follow 节点回复操作提交，该操作即可视为提交，且已提交的操作不会丢失，即使发生新一轮的选举。（ps：不了解该协议的小朋友阔以自己狠戳参考资料学习，笔者只能帮你到这里了

分布式一致性协议的复制如下图所示，由分析可知，即使 server2 处理速度慢或者 server2 不可用，整个 server 集群还是可用的。可见分布式一致性协议从性能和使用性的角度上分析，完胜。

注：分布式一致性协议不是银弹，它也有缺点，比如持续的 leader 选举，这依然会导致服务不可用，不过概率和时间上来说会更小🤔

2.2.3 总结

• 一主多从和分布式一致性协议均可以用于维护各个节点数据的一致性
• 分布式一致性协议较一主多从的模式有高的稳定性且处理速度不受最慢的节点影响

2.3 分布式事务

假设一个电商平台的下单服务操作，需要调用以下的子系统完成整个下单的流程。因为依赖较多的子系统，引入了更多的不稳定因素。所以为了保证用户下单行为的正确，此处需要引入分布式事务。解决用户在下单流程中失败的问题。

2.3.1 概念

分布式事务的概念很简单，要么所有操作都执行，要么所有操作都不执行，不允许出现执行一半的场景。比如：

• 订单服务和库存服务调用成功
• 积分服务调用失败
• 仓储服务并未执行

2.3.2 思考

几乎所有新技术的出现一定是为了解决某一类特定的问题，但是大多数时候，我们都只顾着去学习新技术，而忘记了去深入探究，它到底解决了什么问题。

• 你知道 VM 和 continer 是啥，怎么用，但是思考过它们解决了什么问题吗？资源利用率嘛？
• 你知道 serverless 的概念，但是它真正能产生的价值是什么？提效产研嘛？
• 你知道 service mesh 的概念，甚至去看过了它的源码？但是你们公司真的需要它嘛？它能够解决贵公司面临的问题嘛？

「not what but why」。有位大佬吐槽过我「不要手里拿一个锤子就看啥都像钉子，就算真的是个钉子，你用木头不能锤嘛？你用石头不能锤嘛？」🤔

3. 具体实现协议

以下内容仅做归纳，完全木有细节，可以自行跳跃式阅读。

3.1 分布式一致性协议

3.1.1 多主协议

• Gossip 算法：由初始的几个节点向周围互相传播，到后期的大规模互相传播，最终达到一致。
  • 实际使用： redis 集群消息同步
• Pow 算法：大量的节点参与竞争，通过自身的工作量大小来证明自身的能力，最终能力最大的节点优胜。
  • 实际使用：比特币引入了 Pow 算法

3.1.2 单主协议：

• Zap 算法： zookeeper 实现了该算法

• Paxos 算法

• Raft 算法

此处还欠缺一些开源实现好的算法，但是本着自己动手丰衣足食的策略，我就不罗列了。

3.2 分布式事务

以下是实现分布式事务的几种方式：

• 2PC 两阶段提交
• 3PC 三阶段提交
• TCC 补偿事务协议 (try/confirm/cancel)

注：🤔我觉得 2PC 和 3PC 是由协调者控制是否要提交，而 TCC 补偿事务协议则由业务方控制是否要提交

4. 碎碎念

不是拖延症晚期的感觉还是挺好的，居然周一就写完了，撒花

• 人生中没有哪件事情是无用的，即使不能得到夸奖，不能被人认可，至少我希望能竭尽全力，做好能做的每一件事。所以，我现在又要去做所谓无用功了。《校对女孩》

有用也好，无用也罢，总之自己觉得开心就好啦。

5. 参考资料

• raft协议和zab协议有啥区别？

• Raft对比ZAB协议

• Zookeeper——一致性协议:Zab协议

• 分布式事务：两阶段提交与三阶段提交

• 终于有人把“TCC分布式事务”实现原理讲明白了！

• 分布式一致性协议概述

• 分布式和集群的区别是什么