文件目录发生了增删改操作？

相比2PC的改进

对于2PC的同步阻塞的问题，我们可以看到因为3PC加入了参与者的超时机制，所以原来2PC的如果某个参与者故障导致的同步阻塞的问题时间缩短了，这是一个优化，但是并没有完全避免。

第二个单点故障的问题，同样因为超时机制的引入，一定程度上也算是优化了。

但是数据不一致的问题，这个始终没有得到解决。

举个栗子：

在PreCommit阶段，某个参与者发生脑裂，无法收到TM的请求，这时候其他参与者执行abort事务回滚，而脑裂的参与者超时之后继续提交事务，还是有可能发生数据不一致的问题。

那么，为什么要加入DoCommit这个阶段呢?就是为了引入超时机制，事先我们先确认数据库是否都可以执行事务，如果都OK，那么才会进入后面的步骤，所以既然都可以执行，那么超时之后说明发生了问题，就自动提交事务。

TCC

TCC的模式叫做Try、Confirm、Cancel，实际上也就是2PC的一个变种而已。

实现这个模式，一个事务的接口需要拆分成3个，也就是Try预占、Confirm确认提交、最后Cancel回滚。

对于TCC来说，实际生产我基本上就没看见过有人用，考虑到原因，首先是程序员的本身素质参差不齐，多个团队协作你很难去约束别人按照你的规则来实现，另外一点就是太过于复杂。

如果说有简单的应用的话，库存的应用或许可以算做是一个。

一般库存的操作，很多实现方案里面都会会在下单的时候先预占库存，下单成功之后再实际去扣减库存，最终如果发生了异常再回退。
 

分支命名规范

团队内部可以约定每个分支的命名样式，这里举个例子，大家可以参考：

1. feature分支：以feature_开头，如 feature_order
2. release分支：以release_开头，如 release_v1.0
3. hotfix分支：以hotfix_开头，如hotfix_20210117
4. tag标记：如果是release分支合并，则以release_开头，如果是hotfix分支合并，则以hotfix_开头。

Forking 工作流

Forking 工作流是以 Github 为代表的一种代码协作方式，开发者通过克隆(fork)源仓库进行编写代码，一旦完成会发起 pull request，源仓库作者可以选择是否接受该 PR。

下面通过 Github 详细讲解 Forking 工作流模式。

随便找一个Github 开源项目，

https://github.com/smileArchitect/JavaMap

右上角有三个按钮：Watch，Star，Fork

Watch 是关注的意思，一旦你点击了之后该项目有任何改动都会第一时间通知到你;

Star 类似于点赞的意思，多给开源项目点个赞，鼓励一下作者;

Fork 本意是分叉，实际上是克隆的意思，点了之后会将该项目拷贝一份到自己的 github 远程仓库中。

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!