技術 Day 24. 打造可重覆使用的設計－Figma 的 Component 元件解析

在一個網站中，常常會在不同的頁面之間看到許多相同共用的元素，比如說按鈕、導覽列。而在同一個網頁中，也經常會看到有些一再重覆出現的元素，比如說卡片、列表等。 我們...

技術 Day 19 - Google Distributed Lock Service - Chubby(中)

Chubby 架構 下圖是一個Chubby的架構 分成Client與Chubby Cells 五個replica servers組成一個高可用的Chubby...

技術 Day 18 - Google Distributed Lock Service - Chubby(上)

前言 我們前面剛講完Zookeeper的共識演算法，還沒介紹它的功能，怎麼就跳到什麼鎖服務了呢？ 這是因為Apache系列底下的分散式系統例如: Hadoop、...

技術 Day 15 - 共識演算法 - 先喘口氣做一個複習

前言 今天鐵人30天已經走了一半了！沒想到我們還在討論Consistency與Availability的問題。就知道其實分散式系統最大的問題，便是在保持系統可用...

技術 Day 14 - 共識演算法 - Paxos太難了所以我發明了Raft(下)

前言 昨天提到了基本的選Leader的方式，與log被commit的方法，感覺已經非常完整了，到底哪裡還有問題呢？ 我們今天繼續往後探討當選出一個新的Leade...

技術 Day 13 - 共識演算法 - Paxos太難了所以我發明了Raft(上)

前言 今天要來說一個覺得人家論文太難，所以就寫一個博士論文重新發明共識演算法的故事。 其實，Paxos太難這件事不只一個人說過，也許前面幾篇講解Paxos流程不...

技術 Day 12 - 共識演算法 - 3 Phase Commitment (3PC)

前言 昨天提到在資料庫領域有2PC來解決Distributed Transaction ACID的問題。但是最大的缺點便是單一Coordinator，如果失效那...

技術 Day 11 - 共識演算法 - 2 Phase Commitment (2PC)

前言 前面提到的Paxos: Leaderless，每一個replica server都可以當Proposer去說服系統達成共識，決定最終的v值 保證「只要過...

技術 Day 10 - 共識演算法之虛構的希臘城邦 - Paxos(下)

設計出一套演算法，當然必須能夠證明他的正確性，且要滿足Consensus Problem的三個要求Termination、Agreement與Validity...

技術 Day 9 - 共識演算法之虛構的希臘城邦 - Paxos(上)

前言 前面我們提到了共識演算法是達成Strong Consistency的一種做法。而共識演算法必須滿足以下三個條件: Termination: 保證所有參...

技術 Day 7 - 分散式系統裡的時間並不可靠(下) - Vector Clock

前言 昨天我們介紹了Lamport Logical Clock可以幫助我們找出分散式系統裡的Causality關係，但是有其缺點，那就是雖然兩個event是平行...

技術 Day 5 - DynamoDB設計裡Consistency與Availability的爭奪 - Quorum System(下)

前言 昨天(傳送門提到如果今天有5個replicas，搭配 W+W > N 與 W+R > N 我們再搭配timestamp可以讀到最新的結果。...

技術 Day 4 - DynamoDB設計裡Consistency與Availability的爭奪 - Quorum System(上)

先看一個例子 昨天的分散式儲存系統，要求寫入只能寫入primary server，讀取則可以從replica servers讀取。因此問題: 在於要多久的時間...