最近在寫一次砍掉所有系統正在運行的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。那接下來就進入我們今天的主題吧。
最近在看《軟體架構原理：工程方法》這本書，其中有一段講到身為架構師應該如何拿捏介入團隊實作的力道我覺得滿實用的。作者示範了兩種極端的架構師人格特質，以及列出幾項可以量化的點，透過這幾項量化後的分數加總決定應該施加多少介入的力道。
近期迴響