MySQL是一個很常見的關聯式資料庫，在任何牽扯到交易和金錢的場景都很容易看到MySQL的身影。原因在於MySQL等關聯式資料在執行操作時具有ACID的保證。 關於ACID的內容，在鐵人賽剛開始時的分散式交易就已經介紹過了，因此這邊就不贅述。 但在這篇文章中有一個必須要強調的重點，也就是ACID中的Isolation在MySQL等關聯式資料庫上有分為四個等級。 讀未提交(Read Uncommitted) 讀已提交(Read Committed) 可重複讀(Repeatable Read) 可序列化(Serializable)

我們在之前聊過如何準備設計審閱也介紹了分散式交易，那麼讓我們把這兩者結合在一起。讓我來示範一下，如何做一個分散式交易的設計審閱。 為了避免大家忘記，我簡單列一下要點： C4模型 使用者故事和使用案例 設計決策 因此我會按照一個真正的設計審閱流程設計一個分散式交易功能，但太細節的內容會省略。

在開始介紹微服務之前，有一個很重要的概念必須要先闡明，那就是分散式交易。 因此這篇文章會分為幾個部分： 解釋什麼是分散式交易 介紹如何解決分散式系統的問題 提供一個實際的例子 但在解釋什麼是分散式交易前，讓我們來回顧一下什麼是交易。

This article will take backend development as an example, but the same concepts can be applied to various fields. Before explaining how to prepare a good design review, let's first introduce what a design review should have. As an architect, I'm going to tell you what I want to see. C4 model User stories and use cases Design decisions As an architect, what I want to see the most is the above three items, not code flow nor database schema even nor RESTful API spec.

Background graph LR guest(Guest) proxy(HTTP proxy) host(Host) internet(Internet) subgraph Lab host --> proxy end proxy --> internet

EKS Fargate Demonstrate the setup of EKS Fargate including Create cluster Deploy an app Installation auto install: eksctl manual install: AWS mgmt console

from Javascript to Python 一般來說，要從前端上傳一個檔案到後端，最簡單的做法是： <input type="file">拿到一個檔案的Blob 用application/octet-stream直接往後端送，後端收到就會是一個二元字串，可以直接使用。 但這樣有個前提是，你一次只上傳一個檔案。 在現實情況很常有需要送很多資料的情況，這時候不是放在query string就是放在HTTP header； 若是資料很多的情況，這兩種做法都不現實，勢必變成需要夾在request body和檔案一起送。