没有关系数据库、事务如何做一个交易系统

之前一次心签到有提到如果没有关系数据库、没有事务我们要如何做一个在线交易的系统。这个对于以往重度依赖数据库、事务机制开发的同学会一头雾水，这要如何去做？我相信也有一部分人会觉得很疑惑。这和我以往开发的方式完全不一样？很多时候在一个分布式的系统里面我们是很难做到ACID的机制的，所以又演化出BASE理论，BASE 理论是允许或容忍系统出现暂时性的问题。那如何应用这个理论来解决我上面说的这个问题。那提出一个新的观念：补偿事务。我们可以通过现实生活中的例子来看看是怎么做的。比我我现在要出差，首先要请假、买机票这两部且都要成功。比如我现在请好假了，去买机票结果发现需要购买的日期机票已卖完了，但是明天有票。正常情况大家会怎么做，首先我们会作废之前的请假单、然后重新提交新的请假单、然在购买机票。这个是不是和我们分布式事务解决方案之一的：TCC事务模型特别像。其实很多时候我们并不需要追求强一致的情况，我们走最终一致也是ok的，如果失败我们就进行回滚，将原来在数据库层面实现的功能我们通过业务补偿冲正的方式来进行，这也是base理论的初衷。我们在做一个交易系统如果不考虑开发量的话，我们所有涉及到事务的地方都可以通过以上类似的方案进行解决。我们A账号要跨行转账给B账户100元。我们要如何保证A扣款成功B一定增加成功呢？举其中一个方案来说：A账号先预先扣除100元A，往B所在的银行系统上发起一个转账申请，对方回收到转账消息（如果申请失败，提示失败，让用户稍后），接着A账号所在银行标记当前已转账。接着B银行如果理想情况没有问题直接处理成功B收到转账的金额，如果对方账号异常无法进行收款操作，B银行从新进行退款操作，通知到A用户的银行。当然这里面还有一些细节需要在进一步细化。一个跨行转账的业务大体的思路就是这样（当然还有其他的方案这只是列出一种）。主要有哪些步骤出现异常，我们都是可以通过回滚、冲正的这类手段进行数据的一致性修复的。大家可能会说这样性能得多差呀，来来回回这么多次。不知道大家有没考虑过对于以上的业务来说我们大部分的情况应该都是成功的1000笔交易可能只有那么几笔有问题，我们需要进行冲正进行修复。当然这里面我只是举了一个转账的例子来进行说明。针对其他的业务流程我们细想其实都是可以用以上类似的方案来解决，不理解的话按照TCC的思路来理解就可以了。
我觉得设计不需要事务（业务补偿）的系统要遵循两个准则：
1.努力把业务执行完成。
2.如果执行不下去，需要进行业务补偿机制（回滚预留资源，冲正等手段）。