<style>
.markdown-body {
max-width: 1280px;
}
</style>

# 幣託集團BitoGroup 考題

劉智明 2023/11/12

# Question 1 : Check out this golang program. What happens when this program runs?
[考題範例](https://hackmd.io/wp_lbzWrSc-vJFEpUb4OrQ?view)

all goroutines are asleep - deadlock
所有的 goroutine 都 死鎖了
原因出在 transfer 函式內的 from.Lock.Lock() 重複上鎖 造成的

時間軸:

第一個goroutine 1 ---> call from.Lock.Lock() ----> do something ---- 但還沒結束, 可能延遲 n Millisecond

     第二個 goroutine 2 ---> call from.Lock.Lock() ----> do something  就會因為同一把鎖上鎖兩次, 死鎖了

解決辦法:
1. transfer 都只使用單一把鎖就可, 不用分 來源鎖和目的鎖 (但頻繁的 上鎖/解鎖 效能就慢一些)
2. 都把鎖拿掉不使用, 一樣開 兩個 goroutine, 都把 錢包地址 和 轉帳金額傳進函式去, 使用channel 的 jobqueue 來依照順序來處理交易

channel job queue 解決法

# Question 2 : You are required to implement an API that queries a user's recent 100
**purchased products. The API's RTT time should be lower than 50ms, so you need to use
Redis as the data store. How would you store the data in Redis? How would you minimize
memory usage?**

使用指令

key = userlog:userId  field = datalist   value = 要壓縮的字串 100筆  (下面範例我先打json字串,所以把json字串壓縮儲存進去即可)
hset userlog:1234 datalist '{ "money": 100, "type":1 }'


主要是要使用哪種壓縮格式就要找前後端都支援的壓縮格式

[Golang支援 zlib 或 gzlib](https://www.cnblogs.com/tomtellyou/p/15127472.html)
[前端APP使用此壓縮技術看看,得實際測試才知道](https://www.an.rustfisher.com/android/zip/zip-string/)

可以使用 info 和 monitor 觀察記憶體相關使用量, 或使用工具來看 或 內存分析

# Question 3 : Please explain the difference between rolling upgrade and re-create
**Kubernetes deployment strategies, and the relationship between rolling upgrade and
readiness probe.**

# Question 4 : Check out the following SQL. Of index A or B, which has better performance and why?

SELECT * FROM orders WHERE user_id = ? AND status = ? AND created_at >= ?
index A : idx_user_id_status_created_at(user_id, status, created_at)
index B : idx_user_id_created_at_status(user_id, created_at, status)

index A 效能比較好, 應該說是當兩個聯合索引都存在時, 在上面的優先


聯合索引的規則是
先將聯合索引最左邊的開始排序
在第一個欄位的排序基礎下, 在使用第二個欄位進行排序
而且索引不能夠跳著 例如 1 3

可以用 explain 來 交叉比對誰的效能較高

key_len決定了索引項目在儲存空間佔用的大小，越小意味著一個磁碟區能夠放置的索引項越多，
從而可以降低B+樹的高度，高度低就意味著查找時所搜尋的路徑越少，
例如一個三層B+樹，從根到葉節點只需2步，而四層就需要3步了，
而搜尋的路徑少就意味著磁碟IO讀取次數少（如果沒有全放內存的話），自然就提高查詢的效率了

**type類型從快到慢：system > const > eq_ref >ref >range > index > ALL**

| type | 說明 |
| ------ |:------------------------------------------------------------ |
| system | 系統表，少量數據，往往不需要進行磁碟IO |
| const | 常數連接 |
| eq_ref | 主鍵索引(primary key)或非空唯一索引(unique not null)等值掃描 |
| ref | 非主鍵非唯一索引等值掃描 |
| range | 範圍掃描 |
| index | 索引樹掃描 |
| ALL | 全表掃描(full table scan) |

[explain](https://www.cnblogs.com/bubu99/p/11410194.html)

# Question 5 : In the Kafka architecture design, how does kafka scale consumer-side performance? Does its solution have any drawbacks? Is there any counterpart to this drawback?

consumer: 消費者
producer: 生產者
topic: 訊息對列
訂閱 發布
就是一個結合 pub sub 和 MQ 的一個即時處理事件串流、分析和整合工作的開源分散式事件流平台

# Question 6 : Please follow the following requirements to implement an HTTP server and post your GitHub repo link.

Design an HTTP server for the Tinder matching system. The HTTP server must support the
following three APIs:
1. AddSinglePersonAndMatch : Add a new user to the matching system and find any
possible matches for the new user.
2. RemoveSinglePerson : Remove a user from the matching system so that the user
cannot be matched anymore.
3. QuerySinglePeople : Find the most N possible matched single people, where N is a
request parameter.
Here is the matching rule:
- A single person has four input parameters: name, height, gender, and number of
wanted dates.
- Boys can only match girls who have lower height. Conversely, girls match boys who
are taller.
- Once the girl and boy match, they both use up one date. When their number of dates
becomes zero, they should be removed from the matching system.
Note : Please use in-memory data structure to store your data.

[github example](https://github.com/lion770818/bito_group.git)

Other requirements :
- Unit test
- Docker image
- Structured project layout
- API documentation
- System design documentation that also explains the time complexity of your API