事務和數據庫有關系嗎？終于有一篇文章把“事務”講清楚了！
我不知道你是否遇到過這樣的情況。你去了一家小商店買東西并為此付出代價，但店主突然有一些事情要處理。處理后回來后，給你的貨物與你最初想要購買的東西不一致，或者很多可能丟失，它可能是錯誤的，甚至是間歇性的艾尼斯，忘記了你已經支付了，并要求你再次付款。或者在網上購物時，可以在支付成功后添加積分，但個人要點沒有變化，或者付款明顯成功，過了一會兒，蕭店會聯系你并說沒有股票和希望您可以申請退款。為了總結所有這些東西，對操作的期望與實際情況不一致，而且背后的原因是沒有交易。那么交易是什么？交易是一個工作機制。它將活動中涉及的所有其他操作放入不可分割的執行單元中。只有在成功執行所有操作時，才會考慮完成事務，否則整個事務不成功并返回原始狀態。一旦你有一個企業，當你去一家小商店買東西時，你付出的代價，給你相應的商品，而且所有者減少了庫存。完成三項操作后，整個購物操作已完成。如果您不支付金錢或店主沒有給您相應的商品，那么即使事務未能執行，它也將返回原始狀態。錢仍然是你的錢，貨物仍然是商人的貨物，不會增加或減少。事務主要用于數據庫情況，有兩種類型的業務：本地事務和分布式事務。對于數據庫本地事務，這是一個很好的理解，因為數據中涉及的內容將存儲在數據庫中，并且數據修改中最重要的是對金錢和財產的更改的內容，需要是通過交易保證，否則您將支付。但是不要向您提供貨物，您是否會向賣方提出上訴，并且平臺總是有問題，是否賣方呼吁平臺，連鎖最終會影響一大群人，所以事務是很重要。對于分布式事務，這主要是由于分布式架構和微服務的出現，并且分布式事務的一致性同樣重要。數據庫事務最重要的特點是酸，即原子，一致性，隔離，耐用性。所謂的原子是交易中涉及的所有經營。這是最小的不可分割。它已完成或未完成。如果在執行事務期間發生錯誤，則會在事務開始之前轉回狀態，就像您購買某些東西一樣，您必須支付它并將其付費并一起完成，或者您不會支付或送貨它。所謂的一致性意味著數據庫的內容必須在執行事務之前和之后一致。就像你買的東西一樣，商家的銷售額和產品庫存分別在購買前分別為100和1000。在購買之前，所有人都會在商家的銷量和庫存均為100和1000時購買。如果您成功購買了100件50元的物品，那么商家的銷量和庫存將成為150和900，而且當每個人來買東西時，商家的銷量。和庫存均為150和900，商家的個人數據庫始終是一致的。
所謂的隔離意味著在并發環境中，當不同的食物在同一數據上運行時，每次交易都是獨立執行的并且不影響彼此，就像你去一個小店買東西一樣，它不會影響其他人們也來到小店買東西。但是，購買商品的銷售額和庫存必須在結賬時具有一定的價值，并且您不會看到中間狀態。所謂的耐用性意味著只要交易成功結束，數據庫就會更新記錄。即使系統崩潰和數據庫系統重新啟動，數據庫也可以在交易結束時恢復到狀態，就像你去一家小商店買東西。老板的所有交易記錄都記錄在分類帳上，因此即使老板忘記，他仍然可以檢查分類帳。隨著Internet用戶和流量的快速增加，業務架構模型已開始分為微服務，并且業務部署模型已分發。所謂的微服務架構是將原始集成應用程序分成霧化模塊，可以獨立地完成功能。例如，電子商務系統服務可以分為用戶管理微服務，商品管理微服務，訂單管理微服務和庫存管理微服務。服務，事務管理微服務和其他模塊，付款，庫存減少和訂單的交易操作現在分散在交易管理，訂單管理和庫存管理的三個子模塊中，以及本地交易成為分布式風格事務。所謂的分布式部署是為了容災和高可用性。重要且最常用的服務在多個節點上部署，以確保服務可以隨時響應。例如，電子商務系統服務中的商品管理位于北京和上海。 ，杭州和深圳全部部署一套，訂單管理，庫存管理，交易管理等部署，當用戶在北京進行交易時，杭州和北京的服務通信的服務必須一起完成任務，本地事務成為分布式事務。分布式事務的出現是不可避免的，所以如何確保分布式交易的一致性？該行業的解決方案包括CAP理論和基礎理論。 CAP理論，即一致性，可用性和分區容忍，不能共存。保證系統AP的可用性或保證系統CP的一致性。這是因為在分布式部署和微服務體系結構的上下文中提出了帽，因此必須存在分區。如果為了確保數據一致性，當用戶在北京的服務節點進行事務時，杭州的服務節點不能使用它，您必須等到整個事務完成。此時，缺乏可用性。如果為了確保系統的可用性，用戶在北京服務節點和杭州服務節點的數據中的交易將不可避免地因數據傳輸延遲而不一致。所以一致性和可用性只能選擇其中一個。對于電子商務平臺，由于廣泛的用戶，有必要確保在任何時間可用，并且可以接受某些錯誤以獲得數據的準確性。對于事務系統，它是用戶屬性的一個點。沒有什么缺少，所以數據一致性非常重要?；旧匣旧峡捎?，軟狀態軟斯特泰特，最終是一致的基本理論，它是帽子結論中的AP的延伸。所謂的基本可用性意味著當分布式系統發生故障時，允許某些非核心業務功能無法使用，以確保核心功能可用。所謂的軟狀態意味著在分布式系統中允許中間狀態，并且允許一些錯誤。所謂的最終協議意味著在一段時間后，所有分布式節點的數據達到協議。分布式事務陷入互聯網的快速發展。是否采用本地交易或業務系統中的分布式交易應該取決于具體情況，并且不能為分發而分發。如果真的需要分發，那么您需要根據您的業務類型選擇適當的模型?？捎眯裕瑥姷囊恢滦院妥罱K一致性都是可行的解決方案。
?
