最近在加速 server 處理某個大量且耗時的查詢。如同過去的經驗, 在嚴苛的需求下, 導出的解法往往都差不多, 因為沒有別的選擇

首先是要用 in-memory cache, 然後在背景定時 refresh cache, 這樣可解決 steady state 的效能問題。

再來要解決 in-memory cache 沒資料的問題。將需要的資料存在外部 cache server, 從 cache server 取需要的資料填入 in-memory cache。

清掉腦中放 redis 資訊的 cache, 要來放 elasticsearch 了

Redis latency 相關雜記. Latency 除錯指南 | by fcamel | fcame...

先將腦中的東西倒出來, 接下來可以安心地塞別的東西了 XD

Redis 實戰心得 - fcamel的程式開發心得 - Medium

覺得好像有很多心得, 但值得寫的好像沒多少

Redis 和 Redis Cluster 概念筆記 - fcamel - Medium

消化一下這陣子使用 DynamoDB 的心得, 有強烈的 scalability 需求時, 用起來滿不錯的

Amazon DynamoDB 初步使用心得 - fcamel - Medium

看 Redis 的設計, 總是能學到不錯的設計概念

Redis Cluster 用 full mesh (all nodes connect to all nodes), 但傳輸時採用 gossip protocol 減少傳輸量, 這點滿不錯的, 兼顧 reliability 和 scalability

我滿喜歡這句, 在許多 CS 設計裡重覆看見: All problems in computer science can be solved by another level of indirection

用中文幹話來說, 就是一個抽象層搞不定的事, 就用兩層!

前陣子看到科技島讀將這概念延伸到整個社會, 講得很清楚, 不愧是周欽華啊~

掌握複雜系統的利器 — 抽象化思考

Redis Cluster 讓 client 直接連往有 keys 的 node, 所以使用 Redis Cluster 的效能和使用單一節點一樣

主要的設計是 Redis Cluster nodes 不支援 proxy, 收到不屬於自己 keys 的操作時, 會用 MOVED 告知 client 處理該 key 的 hash slot 的節點位置。假設 client 有 cache 節點資訊的話, 之後不會找錯節點。

在 client/server 使用同樣 hashtag function 的前提下, client 多數情況第一次就能找對節點, 只有在節點 layout 有變時, 才會找錯節點, 然後被告知正確位置

剛在想要怎麼有效率地 index DynamoDB 部份資料到 Elasticsearch。接著在想要怎麼方便測試這個同步機制。差不多想出滿意的解法後, 發覺核心精神和之前作過同步資料功能有 87% 像

看起來只要是同步資料的需求, 都可以套這個模式處理, 達到最佳可測性。轉念想想, index 其實就是同步的一種, 只是同步部份資料而已, 所以有這樣的結果, 並不意外。

下面是之前思考同步和可測性的文章, 這篇算是我對可測性設計心得的里程碑, 沒想到這麼快又用上了

多想三分鐘，你可以少欠很多技術債 - fcamel的程式開發心得 - Medium

之前寫 Go 時就覺得 batch operation 的 error 很難定義, partial failure 時該回傳 error 嗎? 沒查到什麼通用規定

AWS DynamoDB 對 partial errors 的作法是:

* 不回傳 error
* 要求 client 檢查 response 裡特定欄位
* 有貼心的備好要 retry 的資料, client 可以直接拿來用

有回傳 error 時表示全部資料都沒寫進去。如果看沒有回傳 error, 就覺得 OK, 很有可能就掉資料了!