SOFA Weekly | 每周精选【9/23 - 9/27】

最新推荐文章于 2024-02-04 20:17:42 发布

SOFAStack

最新推荐文章于 2024-02-04 20:17:42 发布

阅读量189

点赞数

SOFA WEEKLY | 每周精选，筛选每周精华问答

同步开源进展，欢迎留言互动

SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。

SOFAStack 官网: https://www.sofastack.tech

SOFAStack: https://github.com/sofastack

每周读者问答提炼

欢迎大家向公众号留言提问或在群里与我们互动

我们会筛选重点问题通过

" SOFA WEEKLY " 的形式回复

1、关于 SOFAJRaft 的提问：

@LoFi 提问：

关于 SOFAJRaft，请教几个问题：不管 raft log 是并行，batch 还是 pipeline 复制，都是为了提高 throughput，但对 latency 没有好处，因为最终日志必须要顺序 commit 和顺序 Apply ，这是 Raft 论文的要求。但是在某些简单的 KV 场景，上层业务可以根据需求去乱序 commit 和 Apply 么？这样可以降低 latency 。

A：pipeline 对 latency 会有一些好处，总体上讲 batch 对吞吐有好处，SOFAJRaft 里的 batch 设计也不会对 latency 有坏处，所以它还是好的，乱序 apply 理论上影响一致性。

如果 raft log commit 成功，但是 apply 失败，系统目前的处理方式是什么？直接 crash?

A：apply 异常失败会阻塞住状态机，只有重启才可能恢复，为了保证一致性。

如果 leader 本地磁盘 error 或者本地 log flush 失败, 但收到了多数派的响应，日志会 commit 么？怎么处理这种情况？

A：你说的这种异常状态机就挂掉了，原因同上一条。

关于扩容：

扩容时，新节点的角色不能为 follow 吧？会影响 ballot，不应该先增加一个 Follow 角色，等 snapshot 加载成功后再变为 follow 么？

A：新加节点首先要求日志追上才行，你说的这个不存在。

扩容时，如果是 follow 的话，根据论文就会影响 leader 的投票吧

A：那首先得你说的这个 follower 在这个组里呀。首先要追上数据，才能变更配置，这个节点才会进入 group，另外再退一步，没有最新日志的 follower 也无法影响投票。SOFAJRaft 比 Raft 论文里面多了一个 preVote。

明白，就是先追上数据，然后才能再走一遍 addpeer raftlog ?

A：不是额，是 addPeer 的流程里第一步就是要先追数据。

你的意思是：当新的节点加入集群时，会先追日志 , 然后再把这个节点加入到 raft goup 中，成为投票中的一员是么？也就是说在追日志的过程中，这个新的节点是不会参与 raft log 的投票么？那如果说我只是为一个 raft goup 增加副本数，比如从 3 副本变成 4 副本时，这个时候是怎么处理的呢？反正就是不管哪种情况，都是先追数据，然后再加入到 Goup 里？

A：新加的 follower 一启动，就会 electiontimeout 发起选举，但是不会成功，然后 leader 会为这个节点新起一个 replicator 开始复制数据日志（通常包含 snapshot），等到数据追上后，leader 会再提交一条配置变更日志，此时这个节点就正式加入到 group 了。

2、关于 Seata 的提问：

@姜伟锋 提问：

最近在看 Seata 的源码，发现 rpc 相关的 Request、Response 网络传输对象太多了，在保证扩展性的基础上是不是可以优化下，因为主要参数也就是事务组 id、事务组 status、分支事务 id、分支事务 status，再加上附加信息字段，感觉这块设计还有相关序列化设计有点复杂了，这样设计的目的是什么呢，求大佬解。

A：是指字段冗余还是指外层的包装协议复杂了？

rpc 传输对象感觉有点冗余，一些 request response 对象是不是可以合并，主要字段应该是固定的，这样设计的目的扩展性是很好，复用性是不是还有优化空间呢？

A：这里是按照非事务消息（注册鉴权之类）和事务消息，事务消息又按照 RM，TM 角色以及传输的方向做了分类，你说的冗余能举个栗子嘛？

看到是按角色定义的 rpc req，res 传输对象，这些词传输对象中主要的字段是全库事务 id，全库事务状态，分支事务 id，分支事务状态，资源 id，还有一些附加字段，TM、TC、RM 交互时为什么不设计成一个 req res 对象公用或者是否可以在现有框架上提高下复用性，个人是觉得这块设计了好多传输对象，每个对象有对应的序列化和反序列化，有点复杂，这样设计扩展性这个点我明白，复用性不是太好，还有其他考虑吗？

A：每个消息都有一个名称（code），消息名对于整个事务的链路流程上理解比较清晰，结合着我们的事务流程图来看，每个阶段的 rpc 都有一个确切的含义，即使从字段上来说是相同的比如GlobalRollbackRequest，GlobalCommitRequest 从名称上来看不一样，但从传输层面来看除了code 不一样其他的是一样的。但是大部分消息的字段还是不一样的，对于这种通用字段比如 xid begin 消息就是空的，设计成通用这里只能是 null，非通用比如 lockkey 那这里如果使用通用消息就可能直接塞到一个 applicationData 的扩展字段里，这种写法我觉得不确切，同时有增加了我私有协议序列化时不必要的长度标识字段，每条消息都是由确切的所需的字段，宁愿复杂一些，也要从设计上更清晰些。

Seata：

https://github.com/seata/seata

SOFAJRaft 解析文章全系列

《剖析 | SOFAJRaft 实现原理》系列文章完结啦，感谢 SOFAStack 社区的核心贡献者们的编写，也欢迎更多感兴趣的技术同学加入。

SOFAJRaft：

https://github.com/sofastack/sofa-jraft