Tag: lock

RDBMS 裡的各種 Lock 與 Isolation Level

來推薦其他人寫的文章 (雖然是在 Medium 上...)：「複習資料庫的 Isolation Level 與圖解五個常見的 Race Conditions」、「對於 MySQL Repeatable Read Isolation 常見的三個誤解」，另外再推薦英文維基百科上的「Snapshot isolation」條目。

兩篇文章都是中文 (另外一個是英文維基百科條目)，就不重複講了，這邊主要是拉條目的內容記錄起來，然後寫一些感想...

SQL-92 定義 Isolation 的時候，技術還沒有這麼成熟，所以當時在訂的時候其實是以當時的技術背景設計 Isolation，所以當技術發展起來後，發生了一些 SQL-92 的定義沒那麼好用的情況：

Unfortunately, the ANSI SQL-92 standard was written with a lock-based database in mind, and hence is rather vague when applied to MVCC systems. Berenson et al. wrote a paper in 1995 critiquing the SQL standard, and cited snapshot isolation as an example of an isolation level that did not exhibit the standard anomalies described in the ANSI SQL-92 standard, yet still had anomalous behaviour when compared with serializable transactions.

其中一個就是 Snapshot Isolation，近代的資料庫系統都用這個概念實做，但實際上又有不少差別...

另外「Jepsen: MariaDB Galera Cluster」這篇裡出現的這張也很有用，裡面描述了不同層級之間會發生的問題：

這算是當系統有一點規模時 (i.e. 不太可能使用 SERIALIZABLE 避免這類問題)，開發者需要了解的資料庫限制...

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時，CDN 這端會先取得 exclusive lock，然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案，就會先卡住，避免同時間對 origin server 產生大量連線：

這個架構在一般的情況下其實還 ok，就算是 Windows Update 這種等級的量，畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說，因為檔案一直產生，這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲，所以在使用者端就需要多抓一些緩衝時間才能確保品質，這增加了直播的互動延遲，所以 Cloudflare 改善了這個部分，讓所有人都可以同時下載，而非等到發起的使用者下載完才能下載：

沒有太多意外的，從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降，對於使用者來說也大幅降低了 TTFB (time to first byte)：

不確定其他家的情況...

AWS 推出了 S3 Object Lock，保護資料被刪除的可能性

AWS 推出了 S3 Object Lock，可以設定條件鎖住 S3 上的 object，以保護資料不被刪除：「AWS Announces Amazon S3 Object Lock in all AWS Regions」。

這個功能跟會計做帳的概念很像，也就是寫進去後就不能改，也不能刪除，保留一定時間後才移除掉：

You can migrate workloads from existing write-once-read-many (WORM) systems into Amazon S3, and configure S3 Object Lock at the object- and bucket-levels to prevent object version deletions prior to pre-defined Retain Until Dates or Legal Hold Dates.

AWS 提供有兩種模式，一個是 Governance mode，這個模式下可以設定某些 IAM 權限可以移除 S3 Object Lock。另外一個是 Compliance mode，這個模式下連 root account 都不能刪除：

S3 Object Lock can be configured in one of two modes. When deployed in Governance mode, AWS accounts with specific IAM permissions are able to remove object locks from objects. If you require stronger immutability to comply with regulations, you can use Compliance Mode. In Compliance Mode, the protection cannot be removed by any user, including the root account.

Percona XtraDB Cluster 裡各種與 LOCK 相關的指令會產生的效果

在「FLUSH and LOCK Handling in Percona XtraDB Cluster」這邊看到在 Percona XtraDB Cluster 內各種不同形式的 LOCK 指令會有不同的效果。有些跟一開始用的印象已經不太一樣了...

FLUSH TABLE WITH READ LOCK 與 FLUSH TABLE <tablename> (WITH READ LOCK|FOR EXPORT) 都會直接讓整個 node 卡住，但 LOCK TABLE <tablename> READ/WRITE 就只會卡對應的表格，另外 GET_LOCK 本來應該是完全不支援，現在似乎變成 experimental 的功能了 (參考「PXC Strict Mode」這邊)，這樣一來 MogileFS 的資料庫部分就可以在上面跑了嗎？(當初就是因為這個問題而另外弄一組 DRBD + Heartbeat 的 MySQL 起來跑 XD)

之後看一下什麼時候加進去的...

加州的手機防竊提案讓失竊率下降不少...

2013 的時候提過「加州的手機防竊提案...」，後來在 2015 年生效：

In a press release sent to reporters on Thursday, George Gascón said that since the law went into effect on July 1, 2015[,]

在兩大陣營都有類似的功能：

Such a kill switch has become standard in all iPhones ("Activation Lock") and Android phones ("Device Protection") since 2015.

而執行到現在已經兩年了，手機的失竊率下降不少：「San Francisco DA: Anti-theft law results in huge drop in stolen phones」。

[S]martphone-related robberies have fallen 22 percent from 2015 to 2016. When measured from the peak in 2013, "overall robberies involving smartphones have declined an astonishing 50 percent."

變成要找人殺肉才能處理，增加被竊後的處理難度與成本...

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫：「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明：

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale，很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法，將 cache 放到 client 的效能比較好：

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了：「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話，透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

Google 弄出來的 Grumpy：把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy，可以把 Python 2.7 的程式碼轉成 Go：「Grumpy: Go running Python!」。

下面看到一個留言頗有趣的：

This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文，這次的需求主要是出自 YouTube 的需求：

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍：

除了 C extension 不支援外，還是有些「過於動態」的語法不支援：

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少，這個專案可以當作 YouTube 這種規模的網站所做的改善，而不是什麼可以拿來用的工具 :o

關閉 MySQL 的 Query Cache

MySQL 的 Query Cache 是目前已知效能不好的主要因素之一 (global mutex lock 的緣故)，在正式環境裡的 best practice 一般都是關閉，之前測過也是一開下去效能就會狂掉...

而 Percona 的人在討論要怎麼樣才能完全關閉 MySQL 的 Query Cache：「Is Your Query Cache Really Disabled?」，而他們發現只有在 query_cache_type 與 query_cache_size 都設為 0，而且重開 MySQL 才能完全避免 global mutex lock：

[W]e can see it is not possible to fully disable the query cache on the fly by changing query_cache_type or/and query_cache_size to 0. Based on the code and the tests, if you want to make sure the query cache is fully disabled, change query_cache_size and query_cache_type to 0 and restart MySQL.

應該是要再修正 my.cnf 的 template 了...

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.

後端是 Redis 與 Memcached 的系統，可以對抗整個機房從 internet 上消失的狀態。

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

4. At-least-once delivery semantics

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

Composer 出現 lock file out of date 的解法

之前也有遇到，結果 Lorna Jane Mitchell 寫了一篇「Handling Composer "lock file out of date" Warning」給了不少解法。

第一種是 composer upgrade，直接全部升級。

第二種是先用 composer update --dry-run 看看是不是有人加到 composer.json 後忘記更新，如果是的話再用 composer update [package] 處理。

第三種是用 composer update nothing 閉上眼睛更新 hash 值，當作什麼都沒看到 XDDD

Sometimes this is the right answer so it's a handy trick to know!. I seem to see these kinds of issues in people's projects quite often (I'm a consultant, I see a lot of projects) so I thought I'd share my usual tactics for getting things sorted - if you have any tricks of your own to share, I'd love to hear them :)

該說很「實用」嗎 XDDD