关于分布式事务的实现梳理

关于分布式事务的实现梳理

场景描述

 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的数据库，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。

解决方案

 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式：

　　其一、分布式事务

　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。

　　其二、消息队列

　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。

　　其三、异步作业

　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。

　　　　在实际使用过程中，一般都是消息队列和异步作业配套实现，当消息队列出现问题，异步作业能正常的把流程走完。

　　分布式事务

 　　在介绍分布式事务时，分两部分来介绍：sql分布式事务、ado.net分布式事务。

　　sql分布式事务

　　分布式事务的实现，首先总结一下sql分布式事务的实现，主要适用于存储过程或者方法函数中。

　　 sql分布式事务的关键词为：distributed，分布式事务在使用前，需要做一下几点的环境准备：

　　分布式事务需要的前期环境准备：

　　在控制面板--->管理工具--->服务 中，开启distributed transaction coordinator 服务。

　　a、控制面板->管理工具->组件服务->计算机->我的电脑->右键->属性
　　b、选择msdtc页, 确认"使用本地协调器"
　　c、点击下方"安全配置"按钮
　　d、勾选: "允许网络dtc访问","允许远程客户端","允许入站","允许出站","不要求进行身份验证".

　　e、对于数据库服务器端, 可选择"要求对呼叫方验证"
　　f、勾选:"启用事务internet协议（tip)事务"。
　　g、在双方防火墙中增加msdtc.exe例外
　　可用命令行: netsh firewall set allowedprogram %windir%/system32/msdtc.exe msdtc enable

 

sql分布式事务的使用实例：

use ecshop;
go

set xact_abort on

--开启分布式事务
begin distributed tran traninsetname

begin

----需要执行的sql语句;
    insert into ecshop..test_name values(8,8)
    insert into ecshoptest..test_name values(9,null)
    insert into ecshoptest..test_name values(8,8)
commit tran traninsetname
end
go

 

　　ado.net中分布式事务

　　　　下面在总结一下ado.net中分布式事务的使用：

　　　　ado.net分布式事务关键词为：transactionscope

　　　　ado.net分布式事务需要引用命名空间：using system.transactions

　　　　首先需要了解ado.net分布式事务的级别

　　　　chaos：无法改写隔离级别更高的事务中的挂起的更改。

　　　　readcommitted：不可以在事务期间读取可变数据，但是可以修改它。

　　　　readuncommitted：可以在事务期间读取和修改可变数据。

　　　　repeatableread：可以在事务期间读取可变数据，但是不可以修改。可以在事务期间添加新数据。

　　　　serializable：可以在事务期间读取可变数据，但是不可以修改，也不可以添加任何新数据---默认级别。

　　　　snapshot：可以读取可变数据。在事务修改数据之前，它验证在它最初读取数据之后另一个事务是否更改过这些数据。如果数据已被更新，则会引发错误。这样使事务可获取先前提交的数据值。

　　　　unspecified：正在使用与指定隔离级别不同的隔离级别，但是无法确定该级别。如果设置了此值，则会引发异常。

　　　　实例代码：

　　　　

 　　　　　　//// 事务附件消息
            transactionoptions transactionoption = new transactionoptions();
            //设置事务隔离级别
            transactionoption.isolationlevel = system.transactions.isolationlevel.readcommitted;
            // 设置事务超时时间为60秒
            transactionoption.timeout = new timespan(0, 0, 60);

            //启动一个分布式事务
            using (transactionscope scope = new transactionscope(transactionscopeoption.required, transactionoption))
            {
                ///// 处理一个库操作
                using (sqlconnection conn = new sqlconnection(sqlconn))
                {
                    conn.open();
                    using (sqlcommand cmd = conn.createcommand())
                    {

                        cmd.commandtext = "insert into test_name values(25,25);insert into test_name values(26,null);";
                        cmd.executenonquery();
                        cmd.commandtext = "insert into test_name values(26,null);";
                        cmd.executenonquery();
                    }
                }

                ///// 创建一个新的连接，处理另外一个库操作
                using (sqlconnection conn = new sqlconnection(sqlconn))
                {
                    conn.open();
                    using (sqlcommand cmd = conn.createcommand())
                    {

                        cmd.commandtext = "insert into test_name values(25,25);insert into test_name values(26,null);";
                        cmd.executenonquery();
                        cmd.commandtext = "insert into test_name values(26,null);";
                        cmd.executenonquery();
                    }
                }
            }

 　　分布式事务在执行效率上低，在实际项目中不怎么使用，尤其是微服务项目。在微服务项目中，主要通过消息队列变相的实现事务，确保操作结果的一致性

　　消息队列

 　　消息队列在实际工作中使用场景还是很多的，主要目的是实现步骤解耦、消峰、高并发。在这只简单整理一下消息队列在分布式事务中的使用，

　　消息队列在分布式事务中使用逻辑大概是：主流程生成完成后，生成一个消息，直接返回结果给用户，通过消息中间件，告诉后续流程的消费者，进行各自的后续流程逻辑处理、

　　比如：以一个实际的电商中用户订单支付成功为例，假设订单支付成功后首先需要更新订单状态，其它后续流程包括：落地账单数据、落地分佣数据，假设账单数据和分佣数据没有数据关系，可并行执行

　　那么实现逻辑是：

　　　　消息生产者：支付成功，更新订单状态-->发送一个消息到消息队列中间件（广播）

　　　　消息消费者：此处有两个消息消费订阅对象，账单落地、分佣数据落地。两个消息消费者都会收到一条消息，并做各自的数据落地处理

　　消息队里，在系统架构上，或者用户体验上都有是一个很不错的选择，但是在实际工作中，仅仅使用消息队里也不是完成的解决方案，因为消息队列也有肯能出现宕机或者数据丢失，导致业务逻辑中断，所以在实际工作中，一般还会借助一个辅助程序（异步作业），实现对消息队里的补充的加固

　　异步作业

 　　异步作业的实现思路就是，程序定期的执行某一些数据流程操作，比如：账单数据落地异步作业小程序，查找到订单支付成功，但是账单为成功，则落地账单数据

　　在实现上，推荐使用：quartz开源的异步作业框架，使用起来很不错。

　　具体quartz的实现方式，推荐一个博客：

　　异步作业的宿主有：控制台程序、窗体程序、iis、windows服务

　　在实际开发过程中，推荐使用windows服务，方便控制管理

总结

 　　上面对分布式事务做了简单的介绍，如果有说的不对的地方勿喷，望多多指点学习。

　　通过上面的介绍，我们也知道在实际项目中的使用选择，我还是建议采用：消息队列+异步作业 来确保系统的高可用性