后端架构中业务层容错设计的数据完整性问题

　　互联网应用业务需求迭代更新速度快，业务层代码常常性变更，致使代码质量变差，另外应用版本发布周期也短，所以除了完整的测试体系以外，在后端架构业务逻辑层中，容错设计对鲁棒性和问题的快速修复都相当重要。B/S应用也好，C/S应用也好，处理好这个问题高可用及快速发布都有保证。
　　业务逻辑层实现较多使用的高级语言例如Java，Python，PHP，ECMAScript系列，都会在发生错误的时候抛出各类异常，而后程序就会在出错点终止，一般能够经过这些语言提供的异常捕获机制处理出错，确保进程继续运行，接受新的业务调用请求，C/C++在这个问题上有点悲剧。
　　在一个业务调用执行过程当中，一段顺序执行的逻辑代码，通常来讲各行均可能存在着对全局数据的操做，例如数据库写操做，或者进程内全局变量更新操做，若是这段代码执行到一半出错而抛出异常终止（常常可能发生的事），但因为业务进程容错，进程会继续运行不会受到影响，只是这段代码原来设计改变的数据可能只修改了部分，另外出错点后面的数据没有修改到，因而产生了业务数据完整性的问题，这不是关系型数据库的数据引用完整性问题，你无法彻底经过设计良好的完整引用来排除，所以这种问题是常常存在的。
　　一般来讲，对于这种问题，咱们能够这样解决，经过对逻辑代码修复，同时分析对生产数据的影响，而后同步进行修复；另一种方法是在该段代码开始执行时就启用数据库事务，出错时直接rollback，若是你使用的是关系型数据库的话，比较大杀器。
　　分析这两种方法，第一种方法来讲加剧了修复的工做量和时间，要求也比较高，另外取决于应用的设计，对一个线上应用来讲该问题也可能已经照成了难以预料的连带错误；第二种办法解决得比较完全，可是启用事务会大大影响数据库服务器的并发效率，另外目前流行的NoSQL数据库对事务的支持比较糟糕。
　　那么如何更好的解决容错设计下的数据完整性这种问题呢？
　　个人想法是能够参照关系型数据库的事务机制在业务逻辑层实现本身的写调用延迟，分离逻辑代码和数据写调用（数据读调用无需关心）。
这样的架构下，业务代码出错不会影响到全局数据，执行成功则最后将写调用提交执行，若是执行失败则能够删除写调用记录，至关于事务rollback，该业务的调用对外部来讲跟没发生过同样；经过适当的封装，在编写业务代码时也无太大的区别，不会带来代码上的习惯转变问题。
该实现带来的好处是调用抛出异常终止时无需再关心数据完整性的修复问题，只须要修复相应的业务代码便可，固然这只是针对本地的调用，对于存在于本地业务逻辑中的RPC则显式两阶段提交是不可避免的，不在考虑范围。
　　我已经在本身的服务端架构中实现了该想法。将继续测试。