基于內存日志的最終一致性方案的疑惑
老師你好,之前項目中一直用的本地事務保證數據一致性。
關于你介紹的基于內存日志的方案來解決最終一致性,我覺得這是存在一些問題的。
最大的問題是當處理業務數據之后,還未來得及將消息存儲到內存日志,這時候服務掛掉了,那么就會造成了數據的不一致:業務數據處理完了,但是消息沒有發送到消息隊列(因為沒有保存到內存日志中服務就掛掉了),導致其他服務無法收到消息。
感覺這種問題的補救方式就是在業務處理時做文章,比如在數據庫中記錄業務處理的狀態,當消息日志發送成功,再更改這個狀態(其實還是會遇到在此時宕機導致狀態未能及時更新狀態,這時候可能又要用別的補償措施了。。)。 那么進一步增加了復雜性。個人感覺還不如本地事務的方式更方便呢。
期待您的解答,謝謝!
2017-07-22
這是一個好問題,感謝你的提出
首先,我們要確定的一點的是系統沒有100%的可靠性,我們只能盡量去彌補發生問題的可能性,比如把穩定性提升到到3個9或者4個9等。
基于以上的條件我們再來選擇一個我們能接受的方案,使用內存日志的方式是信任了內存日志的處理效率和穩定性(內存還是我們能利用的效率最高的工具)。這樣來減少出現故障的可能性。如果使用內存日志還達不到系統要求的穩定性的話,就需要進一步優化,比如使用業務數據來進一步提供補償措施,
本地事務是一種比較方便的方式,但是對框架代碼有一定的侵入性,相比于內存日志的話效率會有一定損耗,算是怎樣去平衡的問題吧。