层叠模式下的存储，假定是这些快照，10 点的快照->11 点的快照->12 点的快照，12 点快照要依赖 11 点快照，11 点的要依赖 10 点的。如果这时候你切回了 10 点的快照，那么 11 点、12 点的快照就作废不能用了。

当然有方法能弄成 a -> a1, a -> a2 ，a -> a3 ，在 a1 、a2 、a3 之间来回切换的快照存储方式。不过这种形式下你得手动保存和开启快照了，说句实话，手动保存快照，要比切换虚拟机慢，而且可能慢上好几倍的时间。

@123go Hyper-v 的快照是类似于 Docker 镜像的层叠模式，其他虚拟机的快照估计也类似。这种方式不适合做来回切换。

全程工作在唯一一个虚拟机环境下是可行的，hyper-v 虚拟机除了 ctrl+alt+* 组合键用不了、（因为只有远程桌面连接这一种方式造成的）锁 30 帧之外，跟宿主机就没区别了。多个虚拟机随时切换就太困难了。

scrum 天生就是 PDCA 循环，如果你们用 scrum 但是没走出来 PDCA 循环，那说明你们并没有真正的在用 Scrum 。这种情况下给什么方法论都没用。提示一下，PDCA 和 Scrum 的精髓是：每轮只解决最优先的部分问题（通常绝大部分问题都是留给后面）；根据以前的效率指定之后的计划（意味绝对不会有效率低下这种说法)；没全部成功就是失败（同时做失败了也算做了）。

@dqzcwxb 没先搞明白事务，就直接上分布式事务，就容易出现你这种理解偏差（说直白点就是没学会走就去学跑）。分布式事务的目的是什么，是要保证分布式场景下的数据一致性，那如果分布式流程中的单个环节都无法保证一致性的话，总体场景怎么可能有一致性。

不光 TCC ，除了两阶段提交之外的大部分分布式最终一致性方案，在分布式流程环节，都不依赖数据库。那实际上就不需要明说，都特么跨数据库了，还怎么依赖数据库。而那只是分布式流程环节不依赖数据库，单节点内部，还是需要强一致性的，而强一致性最好的方案就是关系数据库。单节点环节内部需要强一致性，这点也是不需要明说，因为通常能接触到最终一致性方案的，不会是像你这样事务一致性都不懂的人。

@dqzcwxb 你的文字理解能力实在是有限

@dqzcwxb 给你补充一下，TCC 模式是不依赖于本地关系数据库的 ACID 事务，但人家可没说不要求本地事务，你要不用关系数据库的事务，就得自己参照 ACID 原则做本地事务。

@dqzcwxb #1 跨库事务或者分布式事务从来都是伪命题，最后都要放弃事务一致性改成最终一致性。而最终一致性的前提是单节点上的事务一致性。至于你说的 TCC 模式，虽然我是第一次听说，但随便一搜就能确定它在单节点上还是事务一致性。

@dumbbell5kg 没有明确的说明，只是从经验上来说是这样，你可以看看 TransactionManager 的实现类。

你说的这个 request handler ，传输层用得还是 TCP ，它只是应用层用的 http 协议 。你自己的服务器，并不是直接运行在 TCP/UDP 协议上的，它也需要有专门的应用层协议。你照着 http 协议，搞一个带路由功能的协议即可。单纯的协议可能很难，但是要是把协议跟你开发用的工具结合起来定义，应该会很简单。

关系数据库的事务，跟非关系数据库的事务，不是一套体系，不能一起看待。比如说 Redis 的事务仅仅代表多个命令同时执行，都没回滚的。

Spring 的事务管理体系，是完全基于关系数据库的（它貌似压根没有 ORM 当中 O 层面的事务管理，完全用得是 R 层面的事务管理）。

@kongkongye 约定优先于配置，不是约定代替配置，你要不乐意，完全可以手动配置自己搞。你所看到的复杂，跟约定优先于配置没关系，是配置本来就这么复杂，约定是降低，而不是增加了复杂度。你现在的看法，举个例子来说就是：不怪路本来就难走，而怪修路的没把路修好。

你要有闲工夫可以用沙盒，windows 自带的沙盒和 sandboxie-plus 都可以。没闲工夫就直接上虚拟机。

哪有什么岁月静好，只不过有人在替你负重前行。你看到的只是一个树，但它背后是茫茫多的数据结构。别得不说，没有众多数据结构，数据库你都没有。

只要不是 Oracle 的，都能用。只不过各家都有专长点，OpenJDK 高度适配 Linux ，微软 JDK 高度适配 Windows 。

测试环境跟生产环境，除了前者修改更迅速外，环境上不能有差别，你生产环境用几个数据库，测试环境就得用一个。

你可能需要的是单元测试的独立数据库。好得单元测试环境，是不需要物理数据库的，临时性的内存数据库即可满足。如果没有那么好的单元测试环境，那就只能本机开个人数据库了，公司或者团队不会提供的，成本不是一般的高。