記一次EF+Mysql所遇到的事務不生效的的坑

業務場景：近期寫的一個項目，整個項目採用的DDD（領域驅動）設計，所以剛開始設計的時候就將各個業務以聚合根的方式進行劃分，以該業務場景為例，整體的業務簡述為，當客戶進行付款以後，創建一個付款單，然後由財務手動將付款單與發貨單進行賬務沖抵和關聯，同時還需要針對付款的客戶及企業的餘額進行相應的變動，所 ...

業務場景：

近期寫的一個項目，整個項目採用的DDD（領域驅動）設計，所以剛開始設計的時候就將各個業務以聚合根的方式進行劃分，以該業務場景為例，整體的業務簡述為，當客戶進行付款以後，創建一個付款單，然後由財務手動將付款單與發貨單進行賬務沖抵和關聯，同時還需要針對付款的客戶及企業的餘額進行相應的變動，所以，當付款單和發貨單進行沖抵業務的時候，客戶及其企業的待付款金額將會根據沖抵的金額，進行變動，所以該業務的主要操作是首先針對發貨單的待付款金額進行沖抵扣減，此時操作的聚合根為發貨單的聚合根，而因為還需要同時針對用戶的賬戶金額進行變動，所以在操作發貨單的聚合根的時候，觸發一個領域事件，而用戶的聚合根訂閱該事件，當該事件被觸發的時候，用戶的聚合根接收到事件，並隨之進行相應的操作。

實現方式：

一般情況下，領域事件可以看作一個一對多的多播事件即一方觸發多方進行響應，一個聚合根發生改變並且觸發領域事件的時候，其他與之關聯的聚合根都將訂閱該事件，在被觸發的時候進行響應並對自身進行對應的操作，而且事件一般不會存在返回值的情況，所以訂閱方的業務是否執行成功，失敗後需要進行什麼樣的操作，可以根據業務的不同進行不同的操作，如果是需要強一致性的業務，就需要考慮操作異常的處理。如果是一致性不強的業務，則可以考慮自身重試等機制。而目前該項目所遇到的就是強一致性的業務需求，那麼只能一榮俱榮，一損俱損。
在領域事件的是先方面，我採用的是NetCore項目中比較流行的MediatR組件（一種簡單的實現進程內的消息傳遞機制的類庫），採用MediatR的消息通知機制，在進行數據操作的時候，添加並觸發領域事件，從而實現領域事件的觸發以及訂閱處理，同時採用EF的事務來確保資料庫在操作數據時候的一致性。

    //業務代碼

    /// <summary>
    /// 業務開始
    /// </summary>
    /// <returns></returns>

    public async Task Task(CancellationToken token=default)
    {
        // 下麵所用的未聲明對象均有DI生成。
        // DbCotext 繼承 IUnitOfWork,並且通過IOC將其生命周期設為Scope（請求域） 
        //_repository 為聚合根的倉儲類，在實例化時註入IUnitOfWork進行相應的資料庫操作。
        //具體略
        var db = _repository.UnitOfWork as TestDbContext;
        using (var transaction=await db.Database.BeginTransactionAsync(IsolationLevel.ReadCommitted,token))
        {
            A a = new A();
            a.AddDomainEvent(new TestEvent());
            await _repository.AddAsync(a);
            await db.CommitTransactionAsync(transaction, token);
        }
    }


    //資料庫上下文部分方法

    /// <summary>
    /// 非同步提交事務
    /// </summary>
    /// <param name="transaction"></param>
    /// <param name="cancellationToken"></param>
    /// <returns></returns>
    public async Task CommitTransactionAsync(IDbContextTransaction transaction,CancellationToken cancellationToken=default)
    {
        try
        {
            await EventTrigger(cancellationToken);
            await SaveChangesAsync(cancellationToken);
            await transaction.CommitAsync(cancellationToken);
        }
        catch (Exception ex)
        {
            await RollbackTransactionAsync(cancellationToken);
            throw;
        }
        finally
        {
                transaction.Dispose();
                transaction = null;
        }
    }

    /// <summary>
    /// 事件觸發器
    /// </summary>
    /// <param name="cancellationToken"></param>
    /// <returns></returns>
    private async Task EventTrigger(CancellationToken cancellationToken = default(CancellationToken))
    {
        var mediator =_serviceProvider.GetService<IMediator>()!;
        await DispatchDomainEventAsync(mediator,cancellationToken);
    }

    /// <summary>
    /// 調度領域事件
    /// </summary>
    /// <param name="mediator"></param>
    /// <param name="cancellationToken"></param>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    private async Task DispatchDomainEventAsync(IMediator mediator,CancellationToken cancellationToken = default(CancellationToken))
    {
            //當前上下文的所有添加了領域事件的聚合根
            List<EntityEntry<IAggregateRoot>> domainEntries = this.ChangeTracker
            .Entries<IAggregateRoot>()
            .Where(x => x.Entity.DomainEvents.Any())
            .ToList();

        //獲取領域事件
        IEnumerable<INotification> domainEvents = domainEntries.SelectMany(x => x.Entity.DomainEvents).ToList();

        foreach (var domainEntry in domainEntries)
        {
            domainEntry.Entity.ClearDomainEvent();
        }

        //發送事件
        var tasks = domainEvents.Select(async domainEvent =>
        {
            await mediator.Publish(domainEvent, cancellationToken);
        });
        //同時執行
        await Task.WhenAll(tasks);
    }



 //訂閱方

public class TestEventHandler: INotificationHandler<TestEvent>
{
    #region fields

    private readonly IBRepository _repository;

    #endregion

    #region ctor

    /// <summary>
    /// 事件處理方
    /// </summary>
    /// <param name="repository"></param>
    public TestEventHandler(IBRepository repository)
    {
        _repository = repository;
    }

    #endregion

    #region 處理程式

    /// <summary>
    /// 處理程式
    /// </summary>
    /// <param name="notification"></param>
    /// <param name="cancellationToken"></param>
    public async Task Handle(TestEvent eventData, CancellationToken cancellationToken)
    {
        // 參數 eventData 是可以傳遞數據的，此示例省略
        B b = new B();
        b.Num = 1;
        await _repository.AddAsync(b);
    }

    #endregion
}

通過上面代碼可以推斷出，這次業務首先在操作之前開啟ef事務，確保數據，一致性，然後在聚合根A進行保存之前觸發領域事件，然後通過MediatR對事件進行調度，通知訂閱方，而訂閱方則根據自身的情況，實現自身的倉儲，對操作進行處理。最後通過統一保存，提交事務，確保數據的一致性。

遇到的坑

在業務代碼實現以後，就針對該項業務進行測試，為了保險起見，專門針對數據一致性進行了測試，而結果大失所望，在數據進行保存的時候，故意調整了表結構的表A在保存的時候報錯了沒有將數據添加成功，而未調整的表B，則正常添加進了數據，數據的一致性並沒有確保成功。這整個事情就變得很邪門了。而後就開始我的爬坑之旅。

爬坑

1、懷疑DI生命周期是否規範

起初，我以為是因為在進行調度的時候，採用了非同步+Task的方式對領域事件進行了調度操作，所以導致事件在進行處理的時候和主方法的資料庫上下不是一個導致的，所以針對資料庫上下文的註入方式進行了排查，最後結果是事件訂閱處理方的資料庫上下文和主方法的資料庫上下文為同一個實例，所以不存在生命周期或不是實例不同的問題。

2、懷疑項目架構問題

因為整個項目的架構都是我自己搭建的，出於對自身能力的懷疑，於是就有上面Demo的誕生，上面的Demo是我根據思路又重新調整後寫的,結果神奇的一幕出現了，上面的框架事務生效了！！！！（但是這又是另外一個坑，不過不知道是不是負負得正把，反正促使我找到了真正的問題。）

3、載入調試日誌

在這個階段，我進行了瘋狂的調試，在調試的時候，特意輸出了EF的Debug日誌。從事務開啟，到事務保存前創建事務保存點，再到保存，報錯，回滾，刪除事務保存點，這些日誌我全都看到EF輸出出來了並且排查了一遍，各種操作層出不窮，不再贅述，反正沒有解決。

4、懷疑EF

不得不說我飄了，我真真切切的開始懷疑過EFCore，甚至把這部分源碼以及文檔看了一遍，結果還是沒看出什麼所以然來。還是無果。

逃出生天

最後！！！！我要感恩的是馬桶，在我一次次一天天的失敗後，與昨晚（今天凌晨）12：30在我心灰意冷關了電腦以後，坐在馬桶上思考解決方案，隨手用手機搜了一下Mysql事務打開了一篇博客，具體博客內容我忘了，是一篇JAVA的，但是核心內容是在JAVA中開啟事務不管用的情況，一下我就來勁了，仔細一看，卧槽，我懷疑這個，懷疑那個，為毛就是沒有懷疑過是Mysql的問題呢？Mysql的存儲引擎，我所使用的版本是5.7.26，它預設的存儲引擎是MyISAM的，這玩意它不支持事務啊！！！！！它不支持！！！

結果

在我惡補了Mysql資料庫引擎區別以後，我將資料庫的存儲引擎改為InnoDB後，完美！！！解決了！！（具體區別可以去搜一下，網上到處都是，爛大街了都，我就不複製別人的了）兩周，整整兩周，只要有時間，就在電腦前摸索研究這個問題，最後卻發現是這麼一個不起眼的問題導致的。卻也說明瞭我個人對資料庫知識的薄弱，後期需要惡補資料庫。