NimoLife

markdown Today I make an decision that I will write something every day. cuz I want to imporve my English output skills. I want writting journal to be a habbit. I make some rule to let this things easy to execute. Here is my rules. ```markdown Try to use English to write something. - Consistantly to do this. - Don't correct any syntax or gramma or words until I used to write this journal. - Don't care how the essay length I should write, just consistant write. - Upload to the blog. Whatever. ``` This rule may change after I write every day and I wil not feel terrible to write. I don't know whether I can continue to do it, but at least this is a good start. Today I go jogging with my friends, tired but we achive our goal. Ibit is fall down to 44.40, Oh my god that is horrible.

markdown # 關於RCA * RCA : 根本原因分析 ## 結論 * RCA是一種通用報告的格式，提供了一些通用的方法與計巧，讓問題可以從根本上被解決，可以參考[Here](https://asq.org/quality-resources/root-cause-analysis#resources) ## 我們小組上使用的簡易格式 * I. Problem Statement -> 定義/描述問題 * II. Cause & Effect -> 分析原因/造成影響 * III. Solution & Evaluation -> 提出解決方案/評估可行性 * IV. Topics behind the scenario -> 延伸討論 (如果還有的話) ### 節錄部份壓測的RCA報告 ```markdown ## I. Problem Statement * 接入平台需要能承受較大量的用戶。 * 壓測試後發現承載人數低下。 * 測試行為，登入 + 打訊息 + 圖片上傳 & 只打訊息，以不同的人數成增長與訊息數量測試。 ## II. Cause & Effect ### 登入導至OOM * 登入API 密碼加密每次使用64MB空間加密 -> 過多記憶體導至系統崩潰。 ### 併發下物件過多導至GC壓力 * 部份API在高併發下產生大量的物件建立與釋放 -> 使CPU 70%以上的時間花費在GC回收上 ### 編解碼使用的方式不適合高併發場景 * 通訊server的編解碼使用`map[string]interface` -> CPU效能 + GC壓力 ... ... ## III. Solution & Evaluation ### 登入導至OOM * 將密碼加密使用的空間降低 * 需注意玩家的token失效問題 * 要編寫過渡的程式才能無感更換 ### 併發下物件過多導至GC壓力 * 對於重覆使用的物件，在高併發下應使用sync.Pool池來減少GC壓力 ### 編解碼使用的方式不適合高併發場景 * 通訊server的CPU壓力可以透過多台機器分擔壓力(目前的做法) * 或調整編解碼方式減少物件壓力 * 由於MQ訊息沒分離，解決...

markdown ## 結論 在使用make初始化slice的時候，要考慮初始的長度，若是只用兩個參數會使長度等於容量，也就是已經初始化過了，這時再用append的話就不會如想像那樣從頭開始新增資料了！ ## 環境 go v1.19.6 ```go type Card struct { Word string Explain string } ``` ## 預期的對照組 * 這是正常運行的 ```go stackB := []Card{ { Word: "test", Explain: "test", }, { Word: "test2", Explain: "test2", }, { Word: "test3", Explain: "test3", }, } fmt.Println(stackB) // worked stackB = stackB[:2] fmt.Println(stackB) // worked ``` ## 非預期的狀況 ```go stack, _ := GetCardMap() fmt.Println(stack) // worked stack = stack[:2] fmt.Println(stack) // only 2 empty element func GetCardMap() (m []Card, err error) { file, err := os.Open("frequecydic.txt") if err != nil { return nil, err } defer file.Close() totalCount, err := VerifyDic(file) if err != nil { return nil, err } // move file pointer to the beginning of file _, err = file.Seek(0, io.SeekStart) if err != nil { return nil, err...

markdown # 睡覺使你更有效率 ## 自我對話 我們都知道，所以我有個想法，因為我總是讓自己睡的很少，我想是因為我認為我的時間變少了，我要讓自己知道充足的睡眠->更有效率的做事->更多的時間。 我要讓自己認為睡覺是很重要的，其實我原本就知道睡覺是很重要的，但我還是睡的很少。 我要讓這個想法更具體一點，我覺的睡滿八小時是很重要的，所以我要在`起床前九小時入睡，睡到自然醒即可`，這件事情很重很重要！ ## 助眠的建議 * 低溫 * 規律的起床時間與睡眠時間 * 冥想 * 起床之後馬上接觸太陽光或任何足夠強的光線 5~10 分鐘 * 在睡覺前都做一樣的事情 (儀式)

markdown # 非同步資料落地對於IM的重要性 ## 結論 今天我在將建立訊息的API，從先在MySQL落地，改由直接送給Client並另外起一個Cron做異步落資料落地之後，效能從`每秒20人送訊息200人收訊息(4000封/s)`提升至`每秒60人發訊息600人收(36000封/s)`，實屬相當大的進步。 ## 原因 我想是MySQL對於多次連接+小資料的更新與新增很不拿手，因為MySQL每次都是要碰Disk的，而且資料不是連續的導致I/O的時間會很長。 在調整成異步落地之後資料不會經過Disk，而是從API->MQ->Websockt->Client，所以快很多。 並且在異步的資料落地時，採用的是批次插入資料，這可以讓MySQL只需要少量I/O就可以完成大筆資料插入。 ## 應注意的部分 ### 不適合的場景 * 100%訊息都無法遺失，只要預到停電，OOM等事故，Mem是會消失的。 * 資料有立即提取的需求，既然是異步，就無法保證在加入一筆資料之後馬上查詢可以查到資料。 ## 適合的部份 * 資料不是那麼重要的，可以接收遺失，策略可以是幾分鐘內的可能會遺失，

gojmapr 在README中放入blog連結 Hi 各位，我做了一個Golang開源項目！ → gojmapr 介紹 GO JSON MAPPER 簡稱 gojmapr 。 這是一個可以從一坨JSON中只取一些值並Map到的套件。 你有遇到第三方傳來的JSON很復雜，但是你只需要其中幾個屬性而不得不宣告一個超大還層層嵌套的結構嗎？ 你在讀取外部JSON的資料時必需要 account.user.cart.order... ? 這就是你要找的套件了！:) 套件的誕生 起初我是在寫後端API，我在接從前端來的呼叫時發現我花了很長的時間寫好對應的struct，每次使用時候還必需寫超級長，就產生了 為什麼不能用簡單的struct直接讀取我要的值就好了 ，這樣不僅不用寫一大堆struct嵌套，也不怕之後維護的人把整個struct傳來傳去很難維護。 用法 先來一個復雜的JSON結構 jsonString :=`{ "cart" : { "items" : [ { "product" : { "id" : "123" , "name" : "Product A" , "description" : "Product A description" , "price" : 10.99 }, "quantity" : 2 }, { "product" : { "id" : "456...