最近在工作上需要寫一隻圖片上傳的API，好讓使用者上傳證明用的圖片供後續人工審核用。身為一隻稱職的圖片上傳API，當收到使用者發過來的請求後第一步肯定要做參數檢查，驗證使用者上傳的檔案是不是真的是圖片檔，並將亂上傳的請求拒於門外。
但是今天使用者傳來的是檔案其實對API來說都是binary的形式，要怎麼檢驗它真的是圖片檔呢？如果用最直覺判斷副檔名的方式的話有可能會遇到使用者故意改副檔名，然後惡意上傳其它非影像的檔案，所以用副檔名擋肯定是不夠的。在survey了一下後，發現其實還有一招是可以從檔案內容中的magic number下手來判斷。
當服務在面對用戶量逐漸增加並且效能逼近單台的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併發時底層實現鎖的運作過程。
近期迴響