Tag Archives: distributed

分散式系統的介紹

Hacker News Daily 上看到講分散式系統的整理:「An introduction to distributed systems」,作者 (我記得他應該是在 Stripe?) 之前因為需要研究資料庫的正確性而搞了不少事情,還開發了對應的測試框架。

這篇文章把相關的理論都列出來,變成一篇滿滿都是關鍵字的文章。這邊提到的 12 到 16 小時應該是對於已經有基礎的人上課的時間,如果平常沒有在碰的人,以及需要自己學習的人應該會長很多:

This outline accompanies a 12-16 hour overview class on distributed systems fundamentals.

短時間應該看不完,但可以每個週末看一個主題研究一下... 然後也不用想太多,很多時候用單機硬幹 (scale up) 可以爭取到時間回來讀這些東西 & 設計系統轉換。

TiDB 單機效能

TiDB 是一個支援分散式運算的資料庫,希望能夠完整地模擬 MySQL Protocol,而 Percona 試著測試 TiDB 在單機的效能,雖然測試的項目很簡單,但結果頗有趣的:「A Quick Look into TiDB Performance on a Single Server」。

Percona 觀察到的現象是 TiDB 對於單一 SQL query 支援多 CPU 運算 (MySQL 只會使用單 CPU),所以在高階的機器上,某些 SQL query 會快很多。而 OLAP 類型的 SQL query 也不錯,但常見的 OLTP 應用則慢不少:

Short version: TiDB supports parallel query execution for selects and can utilize many more CPU cores – MySQL is limited to a single CPU core for a single select query. For the higher-end hardware – ec2 instances in my case – TiDB can be 3-4 times faster for complex select queries (OLAP workload) which do not use, or benefit from, indexes. At the same time point selects and writes, especially inserts, can be 5x-10x slower. Again, please note that this test was on a single server, with a single TiKV process.

是個有趣的 drop-in...

Cloudflare 推出 IPFS Gateway

Cloudflare 推出了自己的 IPFS Gateway:「Cloudflare goes InterPlanetary - Introducing Cloudflare’s IPFS Gateway」。

IPFS 偏靜態性應用 (雖然官方一直很堅持說動態的資訊也可以在上面跑),這就很適合 CDN 架構拿出來用... Cloudflare 出手應該可以讓 IPFS 的門檻再降低一些。

相較於官方提供的 ipfs.io,Cloudflare 的應該會快不少... (畢竟是直接連到最近的機房)

MySQL 的 XA Transaction

Percona 的「How to Deal with XA Transactions Recovery」這篇提到 MySQLXA Transaction 的復原問題。

XA Transaction 主要拿來做分散式上的事物交易,在官方文件上就有提到對應的標準:

The MySQL XA implementation is based on the X/Open CAE document Distributed Transaction Processing: The XA Specification. This document is published by The Open Group and available at http://www.opengroup.org/public/pubs/catalog/c193.htm.

不過我覺得比較有趣的是這點,Percona 直接建議不要用 5.6 的 XA:

But there is a limitation in 5.6: you can only XA commit/rollback transactions that belong to your session. That means after a crash you are out of luck. To get rid of these you need to promote a slave or perform a logical dump and restore. The best plan is to avoid the use of XA transactions with 5.6.

不過翻了 bug report,Oracle 官方的 5.7 還是沒解決,看起來是 Percona 自己 patch 掉 XDDD

Percona XtraDB Cluster 解釋最近的版本為什麼可以再度提昇效能

Percona XtraDB Cluster 最近的一個版本宣稱效能大幅提昇,這篇試著解釋原因:「How We Made Percona XtraDB Cluster Scale」。

裡面提了三個情境,解釋了這些效能問題以及解法,進而帶出這次的效能提昇:

With these three main optimizations, and some small tweaks, we have tuned Percona XtraDB Cluster to scale better and made it fast enough for the growing demands of your applications. All of this is available with the recently released Percona XtraDB Cluster 5.7.17-29.20. Give it a try and watch your application scale in a multi-master environment, making Percona XtraDB Cluster the best fit for your HA workloads.

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue,難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue:「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做:

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題,就如同 Netflix 提到的:

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上:

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 RedisMemcached 的系統,可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」,也就是有可能會有多次的情況,用 Dyno Queues 系統的人必需要考慮進去:

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆,但實際看起來還是很厚重... 暫時還是不會用吧 :o

奇怪的 RFC:Naming Things with Hashes

看到「RFC 6920: Naming Things with Hashes」這個,看日期是 April 2013,就在想是不是四月一號發的... 但內容看起來還頗有用的,有種 distributed web 的味道?文件裡給的範例長這樣:

<html>
 <head>
   <title>ni: relative URI test</title>
   <base href="ni://example.com">
 </head>
 <body>
   <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
     and <a href="sha-256;UyaQV...">this other document</a>.
     and <a href="sha-256-128;...">this third document</a>.
   </p>
 </body>
</html>

目前是 Propsed Standard,所以是怎樣呢...

IPFS 分散式 Web 服務,以及 ipfspics 圖片儲存

IPFS (InterPlanetary File System),或是被稱作 The Permanent Web。

起因在於目前 HTTP (Web) 在設計時是 1990 年代的想法,許多威脅在當時並不明顯。而到了現在,來自攻擊者的威脅與政府監控的威脅使得必須在 HTTP (Web) 上架構許多 workaround。

最知名的 workaround 就是 HTTPS 以及對應的 CA 架構了,前者因為 HTTPS 協定本身高度複雜,實作的單位經常出錯而產生安全漏洞。而後者靠著大量的稽核檢查來避免出問題,不過畢竟還是 workaround,常常會有一堆「誤發」的狀況發生。

另外 HTTP 發展到現在其實是去中心化「Decenteralized」的架構,政府單位可以抓著其中幾個結點就可以大量監控,而 IPFS 想要做到真正的分散式「Distributed」:

前陣子 IPFS 在 GitHub 上放出了 prototype 讓大家玩:「ipfs implementation in go.」,而最近有人把這個點子實作成 image hosting:「ipfs.pics」(一樣是放在 GitHub 上),並且提供對應的網頁上傳介面:「Decentralized picture hosting in ipfs」。

我試著丟一張圖片上 ipfs.pics 後,得到的 hash 值是 QmRpNqK33gDDKdu8y6Wx5DQsuiJbsnwojNzH5nUwCpwoS9,也可以在 IPFS 看到這張圖:

來玩看看好了 :o

分散式的論壇系統

在「Kudos - A Peer-to-Peer Discussion System Based on Social Voting」這邊看到分散式的論壇系統,帶有投票分數機制以及相關議題機制:

Decentralized Reddit using a DHT to store content and a blockchain to rank such content. Whitepaper with more details here: http://lucaa.org/docs/kudos.pdf

論文裡面可以看出來設計的觀念受到 Bitcoin 的啟發,演算法也是... 換句話說,Bitcoin 帶來的影響遠遠超過金融市場,Bitcoin 所使用的理論也給其他領域很多想法。

如果這樣的系統可行的話 (還沒仔細研究 @_@),真正分散式的論壇系統就會出現了...