关于事务设计的思考技术
很多人应该不懂吧，本篇无私奉献一下。
很多人都一定思考过事务的设计问题。
我们一开始接触 关系型数据库 的时候就被教育，开启事务，A 转账给 B，A 账户减少钱，B 账户增加钱，要么成功，要么失败，不会只做一半。当时觉得好牛逼，这个怎么做到的，比如在任何一个环节断电了，那怎么办呢。后来才知道是数据库记录了事物日志，通过日志的方式实现了两件事情必须都成功或者都失败，但是对于这个日志还是不太明白怎么回事，觉得很牛逼。现在想想，MySQL 或者 Oracle 这种垃圾玩意儿，坑了多少人啊。性能超级低下，还搞出 SQL 注入这类大问题出来，并且迁移，导入，导出都超级麻烦。最最最垃圾的是，数据库对于空间的利用率特别低。
所以，所有的一切进步，来源于实践，一个工程师开发了很多项目，慢慢的迭代，慢慢的运营，他一定会发现，数据库这种东西，必须抛弃。
其实关于事务的支持其实很简单，这个问题，我以前想通过，现在做个记录。
事务支持的核心在于，记录开始的状态，我不管你多少个任务必须都成功，要么都失败，你都给我记住最开始的状态，也就是说如果做不成，我可以都回到最开始的状态。这么来看，事务就简单了。
其实，做事情，肯定是一件一件的做的，比如实际应用到转账，事务的支持能保证两个账户都必须更改，但是在某一瞬间，其实 A 账户是先减少，B 账户然后再增加的，只是你发现不了这个时间差，其实这个也不是问题，在实际环境中，也是合理的。
其实，事务就是游标，比如我们有很多任务，我都必须记录任务的位置，哪怕任何时候失败了，重启，都接着干。事务就是这样简单。
说到这里，又要骂一下关系型数据库了，这帮垃圾软件，耗时耗力，占用空间大，性能差，导入导出麻烦，数据迁移麻烦，维护成本大，就刚刚(2022/08/31)我一个 emoji 发不出去，懒得去搞什么原因了，本站早就是支持 emoji 的，不知道为什么不行，总是问题一堆接一堆的，坑了多少人啊。