Kenny's Blog

今天要談談的是 golang test file 的 package 要在 internal 還是要放在 external 上？所謂的 internal 跟 external 指的是，你的 test file 是否要放在你要測試的程式碼的同一個 package 下，還是應該放在另外一個 package 上，例如 xxx_test package。

這兩者選擇時機點有點不太一樣，有什麼好處跟壞處呢？今天就來探討一下。

今天來講講 delayed task (延遲任務) 的 system design，有哪些方法以及每個方法的適用場景。延遲任務我想應該是常見的需求，舉例來說 CronJob 其實也是延遲任務的一種，只是可能 Cronjob 就是在固定的時間點做同一件事情這樣。那麼本文章的延遲任務指的是，今天有許多 task 是可以設定不同的時間點去執行的，就像是月曆上面可以設定你之後每天的行程是一樣的概念。再延伸想，當你排定好的行程快到了，像是 Google Calendar 就會在十分鐘前提醒你該行程快到了，這也是延遲任務的一種概念。

今天的主題來談談 Golang 的 project layout 的各種形式。所謂 project layout 指的就是基於 Golang 的專案架構，要知道官方是沒有宣布或是規定怎樣的專案架構。造成社群中大家對 Golang 的 project layout 可能看法都不同，因此我也記錄一下我自己選擇 project layout 的思路。

也會介紹社群中應該最為人所知的：https://github.com/golang-standards/project-layout

今天來講講在設計 API 常見的需求：分頁，為什麼要進行分頁？不外乎就是不希望向資料庫一次拿大量的資料出來，造成資料庫的負擔，且前端頁面也不應該一次顯示過多的大量資料，需要進行分頁來提升使用者體驗。

那麼在 Postgres 要實現分頁的需求其實有很多種方法，每個方法使用情境也都不一樣，其 performance 也會有差別的，這篇文章應該是我好久以前就寫好的草稿，但一直沒時間好好整理筆記發在 blog，所以就一直擱置了，因為分頁的需求很常見，所以是應該好好記下來才行。

今天分享這篇文章的筆記，主要內容是在講現在常見的程式語言的 memory model 的內容是什麼，因為我對 c/c++ 也很久沒碰了，所以可能我會理解錯誤，再歡迎指教。

今天分享這篇文章的相關筆記，該文章的作者也是主要 Go 的 contributor 其中之一。這篇文章主要是介紹硬體記憶體模型有什麼類型以及其差別。作者這系列的文章總共有三篇，前面兩篇都算是鋪陳第三篇的 Go 的記憶體模型設計，所以透過前兩篇文章先講講硬體記憶體模型是什麼及區別，第二篇是講講其他語言的記憶體模型設計為何。

如果有在用 GRPC 方式在做傳輸的話，就一定會知道 Google 推出的 Protocol Buffers (Protobuf)，其實它就是一種資料結構，現在 HTTP 傳輸大多使用 JSON 的格式來做資料傳輸，而 Protobuf 就是在做類似的事情。

今天來講講滿常會用的 errGroup 的用法及適用情境，為什麼好用呢？一般我們在用 goroutine 的時候都不能夠 return value，你要將 goroutine 執行後的結果傳出去，通常就要使用 channel 的方式才可以，而 errGroup 的套件則適用於如果你想要知道你開的 goroutine 執行的時候如果遇到 error 就停止工作，並且我需要知道 error value 的情況。

今天來談談 replication 最後的主題就是 Leaderless Replication。前面所說的都會有所謂的 Leader 去接收 Client 的 Write 的需求在同步給 Follower。 Leaderless Replication 盛行於 Amazon 的 Dynamo System，之後 Riak, Cassandra and Voldemort 這些 open source 也採用 leaderless replication，這些類型的資料庫被叫做 Dynamo-style。

Leaderless Replication 每個 Node 都是獨立的，也可以進行讀寫，這樣的架構在乎的倒也不是資料一致性，而是集群的可用性。

今天來講講 Ｍulti-Leader Replication 有哪些優缺點，以及如何處理 Write Conflicts。在前篇文章所提的 Leader-based replication，有個主要的缺點就是，如果這個 leader 掛了，所有的 writes 都無法進行了。因此這時候可以採用 multi-leader replication 的架構來解決這個問題，而每一個 leader 底下都會有各自的 follower。