Tech

product 價格、商品資訊 直播中會一直變 1:1 庫存表(熱資料,獨立一張) 庫存上限 —— 主播追加貨=只調這裡 購物車數量(預留) 訂單數量(成交) 付款:購物車 → 訂單,同一筆交易內轉移 不變量:購物車 + 訂單 ≤ 上限(可賣=導出值,不存「剩餘」) FSM batch 下單・LWW 改單 客人 自行調整數量 客服 清除・調整購物車 助理/營運 追加貨・結束檔期 寫入者有四方——但每小時會從 cart/order items 全量重算兩個計數(派生值的自我修復)

庫存:不能超賣,是這個系統唯一的鐵律

· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #5

留言解析完、身分掛好單,主線走到心臟:庫存。這個系統的功能清單可以慢慢長,但只有一條規則從第一天就是鐵律——不能超賣。賣掉不存在的貨,是要一個一個跟客人道歉退款的。這章講當年怎麼守這條不變量、它被什麼…

#war-story#live-commerce

identity:身分是事實 fb user(PSID) 留言當下就地建立 ig user 自建 user account:帳號是聚合 account 登入後才出現 認領 identity 的單,1:N 綁定(可多重) cart item(佔庫存) 掛在 fb user 上,不是 account 上 fbmsgtocartitem msg id・bidding key id 聚合視圖:認領即收編,訂單不用搬家

身分與帳號:留言的那個人,到底是誰

· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #4

上一章的 FSM 解出了「誰買了什麼」——但那個「誰」,其實只是 FB 給的一串數字。他可能從來沒註冊過我們的平台,可能明天才會登入,可能永遠不會。而庫存現在就要卡給他。這章講全景裡我說「全系列最容易…

#war-story#live-commerce#identity

✗ 直連:M × N 條耦合 app 1 app 2 app 3 Mimir Loki Tempo 每個 app 都要懂每個後端(位址/格式/重試) 換一個後端 → 改「所有」app ✓ 經過 collector:M + N 條 app 1 app 2 app 3 OTLP 一種協定 Collector(Alloy)批次・重試・脫敏・路由 Mimir Loki Tempo 換後端 → 只改 collector 設定,app 一行不動 M 個 app × N 個後端 → M + N:app 只認一種協定(OTLP),後端只面對 collector

採集層:資料怎麼進來——OpenTelemetry 與 Alloy

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #6

三支柱講完了,但有個前提一直被我跳過:訊號要先「進得來」,才有得看。第一篇資料流圖中間那格「採集層」,這篇把它拆開。兩個主角:OpenTelemetry(統一三種訊號的標準)與 Grafana All…

#observability

FB(100)・輪詢 IG(10)・webhook 自建(1)・直推 取回:各源各自的接法 FB 輪詢自適應:忙續抓、閒放慢 殊途同歸進同一張表 清洗 → 落地 統一 message 格式 append 去重鍵:source+message id batch 200・FSM 解析 → 查 bidding key 扣賣出數量+建立身分 raw 有落地・FB 可整場重抓——但從沒被動用 處理失敗 → 直接略過,沒有補救路徑 一切為了主播眼中最新鮮的庫存狀態;代價:尖峰 lag 可達幾分鐘、掉單無聲

留言即下單:把聊天室變成下單通道

· tech · 約 13 分鐘 · 📚 Re:從零開始做直播代購電商平台 #3

全景和起手式鋪完,進主線第一戰:一則留言,怎麼變成一筆單。這章講「接進來」和「解析」兩段,佔庫存的攻防留給下一章。主角是把聊天室變成收銀機的那台有限狀態機——我們會直接讀它的程式碼。 留言來自三個源:…

#war-story#live-commerce#fsm

同步・毫秒級 Django API 請求進、回應出 購物車・結帳・會員 即時・推送 WebSocket 客人留言 → 即時推給 主播 dashboard 非同步・秒~分 RabbitMQ(管道) Celery workers 抓留言・FSM 下單・開發票 寄 email・匯出訂單 PostgreSQL 唯一的事實:訂單・庫存・會員 Redis 速度:banned user 快速判斷 三種時間尺度各請一位專家,底下一份事實、一份速度

起手式:五個元件與一條 CI/CD

· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #2

全景鋪完,講留言、庫存那些戰役之前,先把當年的武器庫攤開——因為後面每一章的取捨,都是在這套技術棧的邊界裡做的。團隊很小:3 個後端、3 個前端,偶爾發包給外包 1–2 位工程師。武器庫也很樸素:Po…

#war-story#system-design#django

留言進來 FB / IG / 自建 統一留言事件 每源一個 adapter 解析 key+n 同人重複取最後一筆 身分 identity 沒帳號也要能掛單 佔庫存購物車 庫存 −n・不能超賣 結帳 兩種購物車合併 第三方金流 webhook・冪等 出貨前處理 合併出貨・交物流 逾期未付 → 釋放庫存 每一站都是系列的一章:留言接入、身分、庫存、購物車、金流、出貨前處理

全景:留言下單的一筆訂單,會經過哪些系統

· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #1

這是一個新系列,也是這個部落格第一個戰爭故事。我在前公司實際做過一個直播代購電商平台——使用者看直播、在留言區打字下單,後面接著庫存、金流、物流一整條鏈。這系列不是回憶錄:我想帶著現在的功力(DDIA…

#war-story#live-commerce#system-design

傳統:一個盒子,全部捆在一起 儲存引擎 索引 快取 mat. view log ↓ 拆開(unbundle),每個功能交給一個特化系統 ↓ log 當中樞(Kafka)— 定順序的膠水 OLTP DB儲存 + 交易 Elasticsearch= 索引 Redis= 快取 數倉 / Gold 層= materialized view 每個系統都是 log 的 follower,照同一順序消費 → 各自一致 你的資料平台 = 一台「由內翻外」的資料庫;讓它不散架的,是那條 log

資料系統的未來:拆開的資料庫、Kappa,與端到端的正確性(完結)

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #12

終章。前面十一章把儲存、複製、分區、交易、共識、批次、串流一塊塊講完,Kleppmann 在這章把它們收攏成一個大膽的視角:別再把「資料庫」當成一個盒子——把它拆開。 而讀到這裡你會發現,這個「未來」…

#distributed-systems#book-notes#data-engineering

✗ 雙寫:應用自己寫三份 應用程式 DB 快取 搜尋索引 病一:寫到一半當掉 → 有的寫了有的沒寫 沒有交易能跨三個系統回滾 病二:並行寫抵達順序不同 DB 收到先A後B、快取先B後A → 收斂到不同值 → 三個系統永久分歧,無聲無息 ✓ log 先行:只寫一個地方 應用程式 只寫這裡 一條有順序的 log(source of truth) DB 快取 搜尋索引 全部照「同一順序」消費 → 順序一致、掉了可重放 下游全是 follower,最終收斂到同一狀態 一份資料要進 N 個系統?選一個當 source of truth,其他全部當 follower

串流:雙寫的陷阱、CDC,與流表二象性

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #11

批次處理「已經齊了」的資料;串流處理「一直來」的資料。這章很多地基我在別處鋪過了:log 與 offset 在 Kafka 系列、投遞保證在 delivery 那篇、視窗與 event time 在 …

#distributed-systems#book-notes#streaming

輸入(不可變) log 分片 1 log 分片 2 log 分片 3 ① map(就地、平行) (/a,1)(/b,1)… (/a,1)(/c,1)… (/b,1)(/a,1)… 逐筆抽 (key, value),不搬資料 ② shuffle(按 key 重分發) 同 key 跨網路聚到同一台+排序 唯一大搬家的一步=最貴 ③ reduce(整組聚合) /a:(1,1,1)→ /a=3 /b:(1,1)→ /b=2 … 輸出:寫成「新」檔案 map 就地跑(把運算搬到資料旁)· shuffle 是唯一的大搬家,也是一切成本所在 groupBy、join、去重……凡是「同 key 要相聚」的操作,背後都是一次 shuffle

批次處理:MapReduce 的精神、join 的兩條路,與不可變輸入的美德

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #10

Part II 在單一系統內把一致性守住了;Part III 的主題換成資料在系統之間流動——而最古老、也最可靠的流動方式,是批次(batch)。DDIA 講 MapReduce 的切入點很別緻:先講…

#distributed-systems#book-notes#data-engineering

終場哨響:結果寫入,但兩個 replica 進度不同 leader:2 : 1 終場 replica 1(已同步):2:1 終場 replica 2(落後):1:1 進行中 ① Alice 查到「終場 2:1」→ 告訴 Bob ② Bob 重新整理 → 「還在踢」?! 發生在「後」的讀,讀到「更舊」的狀態 → 「單一資料」的幻覺破滅 = 不 linearizable

一致性與共識:linearizability、CAP 的誠實版,與全序廣播

· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #9

上一篇的結論是:任何單一節點的判斷都不可信,真相只能由多數決定。這章講的就是「多數怎麼安全地決定」——DDIA 全書的理論高潮。演算法細節(Raft、Paxos、Zab 怎麼投票換屆)我在 SRE 共…

#distributed-systems#book-notes

你的節點 送出請求,等待… ① 請求在網路上丟了對方根本沒收到 ② 對方當掉了真的死了 ③ 對方只是很慢(過載、GC 暫停中)等一下它會處理——甚至正在處理 ④ 對方做完了,但「回應」在路上丟了動作已經發生,你卻以為沒有 在你這端: 四種一模一樣 = 沒有回應 timeout 到了,只代表「你決定不等了」,不代表「你知道發生了什麼」

分散式系統的麻煩:不可靠的網路、不可信的時鐘,與半死不活的節點

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #8

上一篇結尾埋了個鉤子:當系統跨到多台機器,連「鎖」和「驗證」本身都變得不可靠。這章就是那個「不可靠」的總清算——也是我認為全書最該精讀的一章。核心一句話:單機世界是確定性的,要嘛全好、要嘛全壞;分散式…

#distributed-systems#book-notes#reliability

不變量:值班醫生 ≥ 2(目前:Alice、Bob 都在) Alice 的交易 ① 查值班人數 → 讀到 2 ≥ 2 ✓ ② 把「自己」改成請假 Bob 的交易 ① 查值班人數 → 也讀到 2 ✓ ② 把「自己」改成請假 (快照隔離:兩人看到的都是「舊快照」的 2) (改的是「不同列」→ 沒有寫入衝突,都放行) 結果:值班人數 = 0,不變量被打破 💥 每筆交易「單獨看」都對;錯在:你檢查所依據的條件,被對方的寫入悄悄改掉了 同款劇本:會議室重複預訂、帳號搶同一個 username、餘額分兩筆同時扣

交易:快照隔離擋不住的 write skew,與可串行化的三條路

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #7

交易的地基我在 SQL 系列鋪過了:ACID 的重點是 I、髒讀/不可重複讀/幻讀三種怪事、四個隔離層級的光譜、MVCC 怎麼讀不擋寫——那些這篇不重複。DDIA Ch7 真正的加值在後半:兩個連「快…

#distributed-systems#book-notes

按 key 範圍切(range) A–F G–R S–Z 像百科全書分冊,key 有序 ✓ 範圍掃描高效(讀連續一段) ✗ key 是時間戳 → 今天的寫入 全砸最後一區(熱點) HBase / 早期 Bigtable 按 key 的 hash 切 分區 0 分區 1 分區 2 hash 把相鄰 key 均勻噴散 ✓ 負載攤平,熱點被打散 ✗ 順序沒了 → 範圍掃描 得問「所有」分區 Cassandra / Redis Cluster(CRC16)/ Kafka 折衷:複合主鍵(第一欄 hash 選分區,其餘欄位在「分區內」照樣排序)—— Cassandra 的招牌 而 hash 救不了「單一超熱 key」(名人問題)—— 那得在應用層加鹽,把一把 key 拆成多把

分區:range 還是 hash、二級索引擺哪、以及怎麼重新平衡

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #6

複製是同一份資料放多台;分區(partitioning,也叫 sharding)是把資料切開,每台只放一部分——當資料量一台裝不下、或寫入 throughput 一台吃不消,這是唯一的出路。兩者幾乎總…

#distributed-systems#book-notes

單主 single-leader Leader follower follower 所有寫入 衝突:源頭消滅(單一寫入點) 代價:failover 難(誰接任?) MySQL / Postgres / Redis / Kafka 多主 multi-leader Leader A Leader B 資料中心 1資料中心 2 兩邊同時改同一筆 → 衝突! 得利:各地就近寫、斷網照收 代價:寫入衝突要事後解 跨資料中心 / 離線編輯 / 協作文件 無主 leaderless 副本 副本 副本 client 同時寫 n 份 quorum:w + r > n 得利:沒有 leader,無 failover 代價:讀寫路徑複雜、read repair Dynamo / Cassandra 同一道題的三種答案:寫入衝突,你想在「源頭擋、事後解、還是讀時調和」?

複製:單主、多主、無主,與延遲的三個怪象

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #5

進入 Part II,資料開始跨機器。第一招是複製(replication):同一份資料放多台,為的是三件事——一台掛了還能服務(高可用)、資料放得離使用者近(低延遲)、讀流量攤出去(擴讀)。如果資料…

#distributed-systems#book-notes

一個請求的 trace:spans 排在時間軸上(waterfall) gateway auth checkout payment← 600ms 瓶頸 inventory db write 05001000 ms metric 只說「checkout 慢」;trace 指出是 payment 那 600ms —— 這是 metric/log 給不了的「在哪一段」

追蹤與 Tempo:一個請求走過的路

· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #5

三支柱最後一個:traces。它補的是 metric 和 log 之間那個最關鍵的洞——「在哪一段?」 Metric 告訴你「checkout 慢」,但一個請求橫跨了八個服務,到底卡在哪一 hop?L…

#observability

滾動更新中:新舊版同時在跑,資料雙向流動 新版程式 v2已升級的那幾台 舊版程式 v1還沒輪到的那幾台 同一個資料庫 / topic 兩邊都在寫、也都在讀 向後相容 backward 新程式,讀得懂「舊資料」 大家都記得(migration 思維) 向前相容 forward 舊程式,讀得懂「新資料」 最常被忘,但滾動與回滾窗口天天發生 schema 每一次變更,兩種相容都要顧——少一邊,滾動到一半就開始噴錯

編碼與演化:讓新舊程式碼,讀得懂彼此的資料

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #4

上一篇講資料怎麼放上磁碟,這篇講一個更容易被輕視的問題:資料寫出去時,是用什麼格式編碼的? 你可能覺得「JSON 就好了啊」——直到 schema 要改的那一天。這章的重量,來自兩個躲不掉的事實:資料…

#distributed-systems#book-notes#data-engineering

Loki 的兩步查詢 {service=checkout}|= "timeout" ① label 索引小而快 → 縮到幾個 chunk(只索引這個) ② grep 那小堆原始 chunk存 object storage・不索引全文暴力掃,但範圍已很小 ELK:索引全文每行都建全文索引 → 任意全文秒搜但索引巨大、RAM 貴 Loki:只索引 label先用 label 縮小、再 grep便宜到能存海量 log 賭注:你多半已知道要看哪個 service、哪段時間 → 先縮再 grep,夠用又便宜

日誌與 Loki:只索引 label,不索引全文

· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #4

三支柱第二個:logs。而 Loki 最該懂的一件事,是它一個很聰明、很省的設計選擇——它不像傳統 log 系統(ELK)那樣索引全文,而是「像 Prometheus 一樣只索引 label」。這個選…

#observability

LSM-tree:append-only,事後整理 memtable記憶體,先接住寫入 寫滿→整批順序刷盤 SSTable(新,不可變) SSTable(較舊) SSTable(更舊) compaction背景合併去重 寫:永遠順序 append → 快 讀:可能翻好幾層 SSTable(bloom filter 救) B-tree:page 樹,就地更新 root page page page ✎ 就地覆寫 leaf page WAL:改 page 前先順序記一筆(防當機) 讀:沿樹走 3~4 層就到 → 穩 寫:隨機 I/O 就地改 + 先寫 WAL LSM 寫優(RocksDB / Cassandra / HBase)· B-tree 讀穩(幾乎所有關聯式 DB)

儲存引擎:LSM-tree、B-tree,與欄式儲存

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #3

上一篇選好了資料模型,這篇往最底層鑽:資料庫到底怎麼把資料放上磁碟、又怎麼找回來? DDIA 這章從一個兩行 bash 的「全世界最簡單資料庫」開場——dbset 就是往檔案尾巴 append 一行,…

#distributed-systems#book-notes#storage

cardinality:series 數 = 每個 label 基數的乘積 http_requests_total{...} ✓ 低基數 labels service(3) × method(4) × status(5) = 60 條 series Prometheus 輕鬆扛 ✗ 多加一個高基數 label … × user_id(100 萬) = 6000 萬條 series 💥 記憶體被吃光,Prometheus 暴斃 label 只放低基數維度;高基數(user_id / request_id / email / URL)丟去 logs / traces

指標與 Prometheus:時序、pull、PromQL 與 cardinality 的坑

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #3

三大支柱進第一個,也是骨幹:metrics。它是你「有沒有問題」的第一道防線,也是後面告警和 SLO 的底層數字。而 metrics 世界的事實標準,是 Prometheus。這篇講它的資料模型、為什…

#observability

Grafana 只查不存:資料在 data source Grafana(一塊玻璃)只存 dashboard / 設定,不存資料 panel:錯誤率 panel:延遲 p99 panel:錯誤 log 資料真正住這裡 ↓ Prometheus / Mimir Tempo Loki PromQL trace query LogQL 關掉 Grafana,資料一點不少(它在 data source);Grafana 只是「問」,不是「存」

Grafana:一塊玻璃,只查不存

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #2

第一篇那張資料流圖,最右邊那格是 Grafana。這篇把它拆開——而理解 Grafana,其實只要抓住一句反直覺的話:它不存任何觀測資料,它只是一塊拿來「問」的玻璃。 想通這句,它的所有特性就都通了。…

#observability#grafana