最近剛換到了新工作不久，新公司與前東家類似，有交易系統的業務存在：幫 user 建立訂單、加扣款、改狀態，核心邏輯圍繞著餘額在轉。
明明到了新的地方，加入了不同的團隊，但卻發現了一個幾乎一樣的 pattern：A、B、C 三個服務都在直接操作餘額表和訂單表，table 都沒有明確的歸屬，誰想操作就去操作。在前公司時每次看到這種架構都覺得哪裡不太對，在新公司看到一樣的 pattern 就更難忽視了。
本篇想從這個 pattern 出發，聊聊微服務架構下資料表的歸屬問題：同一個 table 到底該不該允許多個服務直接讀寫？以及如果只能透過 API 存取其他服務的資料表，如何解決跨服務一致性的問題。
公司原本只有使用 OLTP 的資料庫，直到這一年來資料量越來越多導致報表類的 query 越查越慢。於是開始研究起 OLAP 的資料庫，希望可以把報表類的 query 拆出去，讓 OLTP 的資料庫專注在 OLTP 的業務上。於是今天要來分享最近在研究的 OLAP 資料庫叫 clickhouse，它有一種能做到平行運算的 distributed table engine，並且測試他在撈上億筆的資料的性能如何。
最近參與了有關區塊鏈相關的專案，系統內部的服務會去調 web3 的 API 做 ERC 或 TRC 的鏈路的 USDT 轉帳。實際下去開發後才發現在這兩個鏈路上創建交易的流程雖然有一些不一樣，但是卻都又能解決了重複交易的問題。因此趁著記憶猶新時寫了這篇：比較 ERC 與 TRC 的創建交易流程以及它們是怎麼防止同一筆交易被上鏈多次導致重複交易的。
當服務在面對用戶量逐漸增加並且效能逼近單台的server極限時，身為技術團隊就必須想辦法為服務進行水平擴展，將服務拆分並且佈署至多台機器上形成分散式系統。
在畢業後在業界打滾幾年後，深深覺得學習分散式系統不能再用實務上看到一個坑才填一個坑的方式學習，因為坑實在太多了，而且職場上沒有那麼多機會及容忍度可以一個坑一個坑慢慢踩慢慢填。
於是就在某天跑完天瓏書局後就把《分散式系統主流框架實作指南》這本書也一起帶回家了，本篇將分享讀完這本書後的每章筆記，如果對於筆記內容覺得不錯的歡迎支持閱讀原作。
近期迴響