旅遊分帳:把 Google Sheet 當後端,寫一個不會把帳弄丟的分帳工具
· tech · 約 6 分鐘
每次跟朋友出國,分帳都是同一個劇本:有人先墊機票、有人刷了租車、晚餐又是另一個人付——回國後對著一堆收據算「誰欠誰多少」,算到懷疑人生。市面上的分帳 App 不是要每個人都註冊帳號,就是要大家都裝同一…
#distributed-systems
資料系統的未來:拆開的資料庫、Kappa,與端到端的正確性(完結)
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #12
終章。前面十一章把儲存、複製、分區、交易、共識、批次、串流一塊塊講完,Kleppmann 在這章把它們收攏成一個大膽的視角:別再把「資料庫」當成一個盒子——把它拆開。 而讀到這裡你會發現,這個「未來」…
串流:雙寫的陷阱、CDC,與流表二象性
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #11
批次處理「已經齊了」的資料;串流處理「一直來」的資料。這章很多地基我在別處鋪過了:log 與 offset 在 Kafka 系列、投遞保證在 delivery 那篇、視窗與 event time 在 …
批次處理:MapReduce 的精神、join 的兩條路,與不可變輸入的美德
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #10
Part II 在單一系統內把一致性守住了;Part III 的主題換成資料在系統之間流動——而最古老、也最可靠的流動方式,是批次(batch)。DDIA 講 MapReduce 的切入點很別緻:先講…
一致性與共識:linearizability、CAP 的誠實版,與全序廣播
· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #9
上一篇的結論是:任何單一節點的判斷都不可信,真相只能由多數決定。這章講的就是「多數怎麼安全地決定」——DDIA 全書的理論高潮。演算法細節(Raft、Paxos、Zab 怎麼投票換屆)我在 SRE 共…
分散式系統的麻煩:不可靠的網路、不可信的時鐘,與半死不活的節點
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #8
上一篇結尾埋了個鉤子:當系統跨到多台機器,連「鎖」和「驗證」本身都變得不可靠。這章就是那個「不可靠」的總清算——也是我認為全書最該精讀的一章。核心一句話:單機世界是確定性的,要嘛全好、要嘛全壞;分散式…
交易:快照隔離擋不住的 write skew,與可串行化的三條路
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #7
交易的地基我在 SQL 系列鋪過了:ACID 的重點是 I、髒讀/不可重複讀/幻讀三種怪事、四個隔離層級的光譜、MVCC 怎麼讀不擋寫——那些這篇不重複。DDIA Ch7 真正的加值在後半:兩個連「快…
分區:range 還是 hash、二級索引擺哪、以及怎麼重新平衡
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #6
複製是同一份資料放多台;分區(partitioning,也叫 sharding)是把資料切開,每台只放一部分——當資料量一台裝不下、或寫入 throughput 一台吃不消,這是唯一的出路。兩者幾乎總…
複製:單主、多主、無主,與延遲的三個怪象
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #5
進入 Part II,資料開始跨機器。第一招是複製(replication):同一份資料放多台,為的是三件事——一台掛了還能服務(高可用)、資料放得離使用者近(低延遲)、讀流量攤出去(擴讀)。如果資料…
編碼與演化:讓新舊程式碼,讀得懂彼此的資料
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #4
上一篇講資料怎麼放上磁碟,這篇講一個更容易被輕視的問題:資料寫出去時,是用什麼格式編碼的? 你可能覺得「JSON 就好了啊」——直到 schema 要改的那一天。這章的重量,來自兩個躲不掉的事實:資料…
儲存引擎:LSM-tree、B-tree,與欄式儲存
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #3
上一篇選好了資料模型,這篇往最底層鑽:資料庫到底怎麼把資料放上磁碟、又怎麼找回來? DDIA 這章從一個兩行 bash 的「全世界最簡單資料庫」開場——dbset 就是往檔案尾巴 append 一行,…
Pub/Sub vs Stream:Redis 版的訊息系統
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #12
Redis 也能當訊息系統,但它有兩套截然不同的東西,用錯就會莫名其妙掉訊息、或殺雞用牛刀:Pub/Sub(廣播,丟了就丟)和 Stream(留著的 log,像一台縮小版 Kafka)。這是整個 Re…
管線、交易與 Lua:省 RTT 與原子性
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #11
有三個東西常被混在一起,其實各解完全不同的問題:pipeline 解「網路來回太多」、MULTI/EXEC(交易)解「一組命令要一起執行不被插隊」、Lua 解「要原子、又要帶邏輯」。搞混它們,你會拿 …
Redis Cluster:16384 個 slot 怎麼分片與擴縮
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #10
單執行緒那篇說過,一台 Redis 的瓶頸是記憶體與網路。當一台裝不下、或流量頂到單機上限,就要把資料分片(sharding)到多台——這就是 Redis Cluster。但它的分片方式很有個性:不用…
主從複製:讀寫分離與複製延遲的怪現象
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #8
一台 Redis 再快也有記憶體與流量的上限,而且它一掛,資料就懸在半空。走向高可用的第一塊地基,就是主從複製(replication):一個 master 負責寫、若干 replica 各複製一份、…
分散式鎖:從 SETNX 到 Redlock,與那場著名的爭議
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #7
多個行程、多台機器要搶同一個資源(同一時間只准一個人扣庫存、跑一個排程),就需要一把分散式鎖。Redis 因為快又原子,常被拿來當這把鎖。但這是個「看起來三行就能寫完、其實坑深到見底」的題目——一路踩…
Apache ZooKeeper:分散式系統的協調核心
· tech · 約 6 分鐘
上一篇共識帶到 Zab 是 ZooKeeper 的引擎,但 ZooKeeper 本身值得單獨講一篇。它是分散式系統的協調核心(coordination service):你很少直接用它,卻天天間接依賴…
分散式共識:一群會掛的機器,如何對同一件事達成一致
· tech · 約 7 分鐘 · 📚 Google SRE 讀書筆記 #14
一群機器要對「同一件事」達成一致——誰是 leader?這把鎖在誰手上?最新的值是多少?——聽起來很簡單,卻是分散式系統最難的問題之一。難在哪?因為機器會掛、網路會斷、時鐘不可信,而你要在這些前提下,…
資料模型:關聯式、文件、圖,你在選什麼
· tech · 約 3 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #2
第一篇講了資料系統要追求什麼(可靠、可擴展、可維護)。這篇往下一層:你要用什麼「資料模型」來裝資料? 關聯式、文件、還是圖——這個選擇不是小事,它是你把現實映射成資料的底層抽象,決定了你怎麼建模、怎麼…
可靠、可擴展、可維護:資料系統的三個目標
· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #1
開一個新系列:讀 Martin Kleppmann 的 Designing Data-Intensive Applications(簡稱 DDIA)。它跟 FoDE 互補——FoDE 是資料工程的實務…