Etsy 介紹的 Cache Smearing

Etsy 的 engineering blog 上提到了他們怎麼設計 cache 機制:「How Etsy caches: hashing, Ketama, and cache smearing」。

使用 consistent hash 已經是基本款了,文章裡花了一些篇幅介紹為什麼要用 consistent hash。

後半段則是有了 consistent hash 後會遇到的問題,也就是講 hot key 怎麼處理:有些資料非常熱 (常常被存取),就算用 consistent hash 也還是有可能搞爆單一機器。

他們做了幾件事情,第一件事情是設計 cache smearing 機制,把單一資料加上 random key,使得不同的 key 會打散到不同的機器上:

Let’s take an example of a hot key popular_user_data. This key is read often (since the user is popular) and is hashed to pool member 3. Cache smearing appends a random number in a small range (say, [0, 8)) to the key before each read or write. For instance, successive reads might look up popular_user_data3, popular_user_data1, and popular_user_data6. Because the keys are different, they will be hashed to different hosts. One or more may still be on pool member 3, but not all of them will be, sharing the load among the pool.

第二件事情則是監控哪些 key 比較熱門:

We’ve seen this problem many times over the years, using mctop, memkeys, and our distributed tracing tools to track down hot keys.

第三件事情是維護 hot key 的清單 (不是每個 key 都會上 cache smearing):

We manually add cache smearing to only our hottest keys, leaving keys that are less read-heavy efficiently stored on a single host.

是個當規模大到單一 hot key 會讓單台伺服器撐不住時的 workaround...

PHP 的 Memcached 的眉眉角角...

PHPMemcached 整理一下,未必適合其他人用。

設定上:

  • 平常應該要打開 libketama 相關設定,包含了 OPT_DISTRIBUTIONOPT_LIBKETAMA_COMPATIBLE
  • 多台 server 要注意使用 hostname 或是 IP address 連線 (尤其跨程式語言時),在 consistent hash 時會有差異。要避免因為 hostname 發生的問題,可以把這段設定放到 JSON 檔裡與其他程式語言共用。
  • 使用 SERIALIZER_JSON,一樣是為了與其他程式語言相容。

使用上:

  • add() 在 key 存在時會失敗,set() 則會覆蓋過去。
  • add()set() 裡的 expiration 參數是 UNIX timestamp,而非直覺的秒數...
  • get() 的 callback 不應該使用,因為無法設定 expire time。
  • memcached 的 manual 有寫預設值是使用冒號 (:) 當作 key 的分隔,這對於統計資料會有幫助。

先整理到這...

Percona Server 第一個 5.6 上 GA 版本...

UpdatePercona 自己也寫了一篇「A closer look at Percona Server 5.6」可以參考看看。

Percona 推出 Percona Server 5.6.13-61.0,是 5.6 的第一個 GA 版本:「Percona Server 5.6.13-61.0 first GA release is now available」。

這等好久了,MySQL 官方有給出「What's New in MySQL 5.6」,對我來說其中有幾個亮點需要測試:

效能

至少不能比現在的效能差。

對 memcache protocol 的支援

這是 5.6 的新功能,可以透過 memcache protocol 存取 InnoDB 的資料。如果可行,可以用在 HA memcache protocol 架構。

Time-Delayed Replication

看起來應該很有用,但一時間想不到可以用在哪裡... 應該是 vm 裡面多架幾台 slave 丟著?

Percona 版的修正

Twitter branch 的 Statement Timeout 看起來是個頗有趣的項目?可以想看看用在哪裡...

Overall...

總結來說,測試機測過後,先用在 DBRD + Heartbeat 的系統上 (只換一台,如果發現 5.6 版不好用,可以 downgrade),如果沒問題就再測試 memcache protocol,然後接下來就是等 Percona XtraDB Cluster 也出 5.6 版?

memkeys:用 C++ 寫的 mctop (memcache top)

在「mctop:memcache top」介紹過由 Etsy 所開發的 memcache top 工具 mctop

這套軟體用 Ruby 寫,其實就是個 sniffer + packet analyzer,但這套軟體有效能問題。在流量很高的時候無法處理所有封包,而變成 sampling 類型的監控。

Tumblr 用 C++ 新寫了一個版本,叫做 memkeys。依照軟體的說明,在 1Gbps 滿載時 mctop 約 50% 到 75% 的 packet drop (sampling rate 約 25% 到 50%),而 memkeys 只有 3% packet drop (sampling rate 約 97%):「Open Source - Memcache Top」。

This was originally inspired by mctop from etsy. I found that under load mctop would drop between 50 and 75 percent of packets. Under the same load memkeys will typically drop less than 3 percent of packets. This is on a machine saturating a 1Gb network link.

效能好不少 :p

Facebook 的 Memcache 架構...

NSDI '13Facebook 的工程師有講到 Facebook 內的 Memcache 的架構:「Scaling Memcache at Facebook」,有影片可以看,也有 PDF 投影片可以下載。

其實 2013 年這次的 conference 提到的架構以前就有提過了... 雖然一時間找不到之前提到架構的投影片,但還是可以配合著以前提到各種架構的文章與投影片看出 Facebook 怎麼利用 Memcache 架構 cache layer:

Facebook 會這樣設計 Memcache 架構,跟 Facebook 用 PHP 的方式有關,是在 PHP 的限制下想辦法爭取效率的作法。

不過這些投影片裡的資料畢竟是有年代了,現在的 memcached 改善了很多,跟當年的情況不太一樣,看之前的投影片最好知道當時 memcached 有哪些問題會比較能理解 Facebook 的工程師們想要解決什麼問題。

mctop:memcache top

mctop 其實是個看得懂 L7 packet 的 sniffer XDDD

軟體是由 Etsy 所開發,出自:「mctop - a tool for analyzing memcache get traffic」。跑起來像這樣 (官方的範例圖):

GitHub 頁面上官方有提到因為是透過 ruby-pcap,目前沒有辦法完全承載大流量 (會有 packet loss),不過看起來是 profiling 必備工具 :p