近日工作中有乙個動作是去updatedb中的資料，更新了幾十萬條資料。更新完了，業務測試沒有通過。但是在test環境是ok的。
首先說說公司的上線流程是 dev->test->uat->regression->live.
對應的是 開發-> 測試 -> 業務測試（需求方）-> 回歸測試(測試對所有ticket進行整體回歸) -> 上線這樣乙個過程。
因為之前是無腦更新，所以現在只能夠看看是什麼原因導致了這種情況。通過**可以看到使用了redis作為快取。追根溯源，在得到key之後通過ttl命令檢視存活時間------
redis時間單位是秒，這個時間顯然太長了，業務想要的結果肯定是立馬生效的。也就是說在updatedb的同時應該去update redis。以免造成這種困擾。看了一把如何構造key。寫個指令碼把updatedb的動作改為update redis跑了一遍達到了目的。
那麼這樣的問題就變成了如何去更新db的同時去更新快取。向上面的情況就變成了分步，update db，redis是單獨了。最好額做法肯定是把兩者繫結起來，提供乙個介面或者格式把兩者更新，刪除繫結，這才是最佳的。這樣把整體的邏輯打包，自然減少了風險。
之前還有另一點思考，關於sql的選擇。
sql的選擇大體分為了兩種型別。
首先分析一下這兩種sql的優劣：
簡單sql
複雜sql
基於以上的比較，在小系統初期，更加傾向於使用sql來替我們做並表查詢，排序。當系統達到一定規模，db會分庫分表，這個時候做這種操作一方面實現難度增大，另一方面效能急劇下降。那麼微服務化，構建統一的介面獲取相關資訊就變得更加重要了。
最近一些想法
1.it系統的建設中，當前的方 似乎仍舊沒有足夠重視對目標的認識 這造成的結果，以盲人摸象來形容，實際上是太輕了。今天上街看給小孩玩的電動小象形狀會唱歌但不會動的那種汽車，小孩的媽媽說，咱們去騎小象吧，這給了我乙個認識 我們建模的時候甚至在更早的步驟中進行分析和抽象的時候，往往就是這麼做的。即便不是...
談一些想法
睡不著，做夢驚醒。不知不覺，又是乙個6月8號過去了，如果一切正常的話，應該又有一大批的學弟學妹們走下了考場，滿懷憧憬地準備迎接人生的下乙個十字路口。一年前的我，現在應該坐在家裡，想著我報考什麼學校和專業吧。最開始可能想去北京，報考計算機或者機械，或者別的什麼專業。去年填報志願的時候，人工智慧炒的非常...
關於自己目前的境遇以及一些想法
搬家，簡歷，找工作，又是這一套流程，依稀想起來12年的時候在北京，在五道口宇宙中心，在農大旁邊的靜淑東里的隔斷間裡，在那個只要跟著劉靜就會有肉吃的一段美好時光。真的是非常懷念在之前艾薇的一段生活，雖然不長，最後還是因為自己的能力問題被推掉了，但是確實學到了很多東西，認識了到目前為止在技術上影響我最大...