當服務在面對用戶量逐漸增加並且效能逼近單台的server極限時，身為技術團隊就必須想辦法為服務進行水平擴展，將服務拆分並且佈署至多台機器上形成分散式系統。
在畢業後在業界打滾幾年後，深深覺得學習分散式系統不能再用實務上看到一個坑才填一個坑的方式學習，因為坑實在太多了，而且職場上沒有那麼多機會及容忍度可以一個坑一個坑慢慢踩慢慢填。
於是就在某天跑完天瓏書局後就把《分散式系統主流框架實作指南》這本書也一起帶回家了，本篇將分享讀完這本書後的每章筆記，如果對於筆記內容覺得不錯的歡迎支持閱讀原作。
最近在寫一次砍掉所有系統正在運行的java程式腳本。
ps -aux | grep "java" | grep -v "grep" | awk '{print $2}' | while read -r pid ; do
echo "Shutting down PID: $pid"
kill $pid
done
說明：
ps -aux：列出所有的process。grep "java"：抓出含有java字樣的process。grep -v "grep"：過濾掉含有grep字樣的process，也就是目前自身script執行的指令。awk '{print $2}'：在每行的第二個column抓出PID。pid，再把它kill掉。最近接到一個需求，需要將game record服務保存遊戲數據至資料庫的行為換成由game server直接推到message queue(我們用Kafka)，再由consumer(worker)去寫入資料庫以實現與game record服務解耦。這樣的話同時就可以再創其他consumer group共用同份message去做其他運算。但是我們又不想再自己寫新的consumer，於是就把腦筋動到Kafka自帶的Kafka Connect上。
Kafka Connect是Kafka自帶的consumer框架，對於一些簡單的搬資料操作例如Kafka的message搬至MySQL、MongoDB、Elastic Search等等的可以委託Kafka Connect達成，就不用再自己寫consumer邏輯多啟一個服務。
在研究與嘗試了幾天後，本篇會記錄如何快速架起Kafka及Kafka Connect的過程。為了demo上的方便，本篇所啟的服務都是單台並且replication factor=1模式，實際在production時請依照所需適時增加replica set。
最近在公司支援另一個採用PostgreSQL當資料庫的專案，雖然從語句面或使用ORM來看的話差異與熟悉的MySQL不大，但是當從併發的角度來看待效能時，才發現其實底層實現鎖的機制大不相同。本篇，我們會拿一個在實際專案中發生的簡化版情境，來介紹MySQL與PostgreSQL併發時底層實現鎖的運作過程。
開發時大家都會使用git為程式碼做版控，好讓不同開發環境以及佈署環境的程式得以統一。今天我們來體驗一下一個叫Sequelize的DB migration工具來為我們的DB schema做版控。
把DB schema版控起來最大的好處是DB schema就可以像程式碼一樣在各個環境都是統一的，不會發生在stg環境驗完測完沒問題的程式因為上到prod環境時忘記加欄位導致prod環境的錯誤狂噴。再來是對於新加入專案的開發人員非常友好，因為開發人員只要使用migration工具下完up指令就可以將本機的資料庫建好很快就可以進入開發，甚至也可以指定版本建出幾天前的舊版DB schema。那接下來就進入我們今天的主題吧。
近期迴響