IT討論區(113) 就到4月啦!!又到轉工好時機!!

你咪replicate, then config insert埋入新db, then行一次select insert去補step1/2既gap

如果你無得config insert埋入新db 咁咪upgrade左呢part backend先
如果你個 backend非常stateful 一定要有downtime咁轉process instance 但又真係重要到唔可以有五秒downtime
咁叫個CTO自裁 同埋唔好入呢間公司

咩data先，如果係external database就無concern啦

如果係係個server既storage而本身個design無預到呢個case咁係無得搞，例如新server mount唔到隻碟

結論係本身design要預，用k8s啦

舊tech crud 有0.7 hbu，印印腳養老都唔錯啦

你thesis做咩topic?

咁你篇野做咩field

那麼問題來了
1. cNN?
2. Temporal?
3. Produce high-d or low-d data?
4. Scales easily, or need retrain for new data set?

active active / active passive clustering?

如果stateful係咪可以定期take snapshot加write ahead logging 等新instance可以recover返個state？

都得既 理論上有journal就得
不過實際上有support先再算

其實可唔可以新舊backend一齊run一個禮拜
假設data已經較早前catch up左

呢個睇法幾創新

呢個就係個方案
具體點安排要睇具體系統同資源

不過如果你stateful 同時行應該有啲痛苦

我開個簡單use case 睇下大家點set
有個rset api
一call佢就會insert一條db record
當係2個column：IP,TIME

一秒有500個request啦

而家0 downtime deploy
新behavior
一call api就會insert一條db record
3個column：IP,TIME,LOCATION

點set？

kafka

直接開新column with default value

照道理兩邊啲state一樣 除非有啲session耐過一個禮拜

可以逐個逐個module啪過去新backend同時再喺新backend reroute啲external calls去舊backend做多次

有咩搞唔掂啪返過去就得

如果係大改
可以行REST api versioning