Redis 改變授權,變成非開源軟體

Redis 宣佈拿掉開源授權:「Redis Adopts Dual Source-Available Licensing」,對應的 git commit 在「Change license from BSD-3 to dual RSALv2+SSPLv1 (#13157)」這邊可以看到。

Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1).

算是今天蠻熱的新聞之一,不過算是在預期之內的變化,因為 Redis 在 2018 年就把很多他們自己開發的 proprietary component 變成 SSPL,現在主體也變其實不算太意外,後續就是看社群的 fork 凝聚的力量會比較大,還是 Redis 公司方的力量比較大... 尤其在 Redis 已經實作了許多 data structure 後,Redis 公司想要套現這件事情是否還有機會?

不過比較特別的反倒是微軟... 微軟早了一兩天發佈了 Redis 相容的實作 Garnet

Garnet is a remote cache-store from Microsoft Research that offers strong performance (throughput and latency), scalability, storage, recovery, cluster sharding, key migration, and replication features. Garnet can work with existing Redis clients.

會是巧合嗎?這時間點其實真的很微妙...

當 Daemon 死掉時自動重新跑起...

以前確保 daemon 掛掉時會重新跑起來大概有幾個方式,像是用 Monit 顧,然後再用 /etc/inittab 確保 Monit 不會掛掉...

systemd 的年代,因為 systemd 已經被保護起來,而重跑這個功能在 systemd 裡就有支援,不需要用 Monit 這類程式了。

manual 裡搜尋 restart 可以看到幾個參數:

  • Restart=
  • RestartForceExitStatus=
  • RestartPreventExitStatus=
  • RestartSec=

這次是遇到 SmokePing 的 FastCGI daemon 每隔幾天會自己死掉,導致 nginx 丟出 503 然後被 UptimeRobot 偵測到而拋出警告。

但這個問題只有在一台伺服器會發生,而 log 裡也沒翻到可以繼續 debug 的錯誤訊息,試著猜測一些情境去搜尋引擎找也沒翻到... 就決定先 workaround 來處理,然後就發現現在已經不太需要用 Monit 來處理這個問題了。

AWS CodeDeploy 支援單機測試模式

AWS CodeDeploy 本來是個 client-server 服務架構,但現在讓你方便在本機測試,支援直接在本機下指令 deploy (不需要 server) 看看發生什麼狀況:「AWS CodeDeploy Supports Local Testing and Debugging」。

Previously, if you wanted to test and debug your deployment, you had to fully configure AWS CodeDeploy. This includes installing the agent on the target host, creating a CodeDeploy Application, and creating a CodeDeploy Deployment Group.

Now, you can execute a deployment directly on a local machine or instance where the CodeDeploy agent is installed. If your deployment has errors, you can easily find and view the error logs by accessing the agent with your terminal. This makes it faster and easier to find and fix bugs before configuring CodeDeploy for production.

是有很多人一直中獎然後跟 AWS 反應嗎... XD

Pinterest 對 ZooKeeper 的用法

在「ZooKeeper Resilience at Pinterest」這篇文章裡面,Pinterest 的人說明內部是怎麼使用 ZooKeeper,其中對我來說最重要的是這張圖:

程式不直接接觸 ZooKeeper 取得資料,而是透過 daemon 寫到 local disk 的資料取得。這樣當 ZooKeeper 失敗時仍然可以保持一定的服務 (因為 local disk cache),而避免服務中斷。

當然,這跟資料的性質有關,不是所有的資料型態都可以接受 cache。這種解法常常是在穩定性不是可以自己控制 (這個例子裡是 ZooKeeper),而且遇到問題時不希望整個服務就爆炸...

但這個思路每次看過每次都會忘記,寫下來不知道會不會比較容易想起來 :o