博客 / 列表

apocelipes - docker-compose 部署單節點 kafka 4.0 測試環境

高版本kafka已經不再需要ZooKeeper當保姆才能啓動了,現在部署一個單機單節點測試環境比原來方便不少。 不過最常用的bitnami/kafka不再提供免費鏡像,導致我們只能用apache/kafka,新鏡像的配置會稍微麻煩一些,所以記錄一下。 部署內容: 單節點kafka服務,版本4.0+ kafka UI,方便管理,版本用最新的 開啓簡單的用户名密碼驗證 docker-comp

雲計算

apocelipes - 從源碼角度解析C++20新特性如何簡化線程超時取消

C++20中增加了很多重量級新特性,它不僅帶來了ranges、concept和協程,也為多線程編程帶來了jthread和stop_source這些強力輔助。利用這些新特性,我們可以更高效地編寫併發程序。 今天要説的就是利用jthread和stop_source來簡化線程超時控制的實現,最終我們可以實現一個簡單高效、可維護性不輸給號稱“天生支持併發”的Go語言的版本。 為什麼需要超時控制 超時控制是

後端

apocelipes - Linux的binfmt_misc機制

在類UNIX系統上,可執行文件和shell腳本一般都是不帶後綴名的,操作系統內置的程序加載器會自動檢測文件的權限和內容是否是一個可執行的程序。這麼做的好處是可以在輸入命令的時候少打很多字。壞處自然是不對文件做徹底的檢查就無法確定其是否是可執行文件,這會帶來一些安全問題。 Linux則更進一步,提供了一套叫binfmt_misc的機制讓用户自定義哪些格式的文件是可執行文件,進一步提升了系統靈活性。

操作系統

apocelipes - 利用泛型編寫更安全的Golang代碼

從Go 1.18正式引入泛型,再到Go 1.21大量泛型函數/類型進入標準庫開始已經過去了三年。儘管有着不支持類型特化、不支持泛型方法、實現方式有少量運行時開銷、使用指針類型時不夠直觀等限制,泛型編程還是在golang社區和各種項目中遍地開花甚至碩果累累了。 不過也因為泛型功能上的種種限制,大多數代碼中對其的應用仍然只停留在最基本的層面——僅僅減少重複代碼上。但golang泛型的威力遠不止如此,即

後端

apocelipes - C++ Two Phase Lookup導致的模板代碼編譯錯誤

猜猜下面這段代碼的輸出是什麼: template typename T struct Base { void DoThings() { std::cout "A\n"; } }; template typename T struct Derived: BaseT { void Do() { DoThings(); } }; in

後端

apocelipes - POSIX兼容系統上read和write系統調用的行為總結

關於UNIX和Linux的宣傳語中,一切皆文件應該是最廣為人知的一句。 不管是普通文件,還是硬件設備、管道、網絡套接字,在Linux甚至還有信號和定時器都共享一套相似的api,大家可以用類似的代碼完成各種不同的任務,大大簡化了代碼複雜度和學習成本。 當然這只是理想中的情況,現實是普通文件和硬件設備是兩種完全不同的東西,普通文件和網絡套接字尤其是UDP協議的那種更是風馬牛不相及,強行把這些行為屬性完

後端

apocelipes - atomic不是免費午餐

很多初級甚至中級開發會濫用atomic,因為在他們的世界觀裏atomic比mutex輕量,性能總是優於鎖的。 這話不能算錯,但有個很重要的前提,那就是原子操作競爭不激烈的時候。 “競爭激烈”是指什麼呢,指的是有很多線程在同一個資源上大量執行原子操作的情況。 落在這種情況下原子操作反而會成為性能拖油瓶。我們來看一個經典的原子計數器: func AddAtomic() uint64 { var co

go , 後端

apocelipes - 下劃線字段在golang結構體中的應用

最近公司裏的新人問了我一個問題:這段代碼是啥意思。這個問題很普通也很常見,我還是個新人的時候也經常問,當然,現在我不是新人了但我也經常發出類似的提問。 代碼是長這樣的: type BussinessObject struct { _ [0]func() ID uint64 FieldA string FieldB *int64 ... }

go , 後端

apocelipes - Go 1.26 內置函數 new 新特性

目前golang 1.26的各種新特性還在開發中,不過其中一個在開發完成之前就已經被官方拿到枱面上進行宣傳了——內置函數new功能擴展。 每個新特性其實都有它的背景故事,沒有需求的驅動也就不會有新特性的誕生。所以在介紹這個新特性之前我們先來了解下是什麼樣的場景催生了這個功能。 如果你經常瀏覽一些大型的go項目,尤其是那些需要頻繁和JSON、GRPC或者yaml打交道的項目,比如k8s,你會發現這些

go , 後端

apocelipes - golang unique包和字符串內部化

最近在做老系統優化,正好遇到了需要使用字符串內部化的場景,所以今天就來説説字符串內部化這種優化技巧。 什麼是字符串內部化 熟悉Java或者python的開發者應該對“內部化”這種技術不陌生。內部化指的是對於內容完全相同的字符串變量,內存中只保留一份數據,所有的變量都引用同一份數據,從而節約內存。 舉個Java的例子: public class StringInternDemo { publ

go , 後端

apocelipes - C++23的out_ptr和inout_ptr

c++23新增了一些智能指針適配器,用來擴展和簡化智能指針的使用。 這次主要介紹的是std::out_ptr和std::inout_ptr。這兩個適配器用法和實現都很簡單,但網上的文檔都比較抱歉,還缺少一些比較重要的部分,因此單開一篇文章記錄一下。 out_ptr 首先從功能最簡單的out_ptr講起。 std::out_ptr其實是一個函數,返回一個類型為std::out_ptr_t的智能指針適

後端