一次關於知識儲備的思考

 

事情的通過是這樣的：

一個夏日的午後，我在啪啪啪的敲代碼，正爽着呢，老大在背後拍了拍個人肩膀，說讓我寫個功能。

我說啥功能，他說：「operate 模塊那邊每次收到文件都會給你發一條消息。而後對消息進行計數，每隔一段時間，你把這個計數寫入一次數據庫。」

 

我說爲何。
老大說對文件數量進行計數。

 

我說爲何不讓他們直接去更新數據庫。
他說 operate 那邊是多線程，數據量比較大的時候，同時更新數據庫會出問題。因此須要經過消息隊列，把數據都彙總到你這兒，你來統一更新這個數據。

 

大概意思我聽明白了，我說行，我作。

意思應該是這樣：operate 那邊是多線程處理數據，而且是多個線程共同維護同一個數據庫的某個統計字段。在數據更新比較頻繁的時候，數據會出現錯誤。

我猜應該是同步沒作好。可是爲何沒作好，我不知道，部門多了，產品複雜了，什麼狀況均可能出現。老大讓這麼作，那就有他的道理，既然是和其它部門商議後的結果，這個方案確定就肯定了。

 

和老大商量後，個人工做是這樣的：建立一個線程出來，獲取數據庫中統計字段的當前值，監聽發送給個人消息，而後累加這個值，每隔一段時間（暫定5秒）更新一次這個值。

開始寫代碼的時候在想，爲何要把這個數據取出來，而後再加上一個數字，而後再放回去呢？爲何把更新一個數字的過程分紅三個部分呢？這多麻煩啊。我印象中好像在《深刻淺出MySQL》這本書裏看到過，mysql 中能夠寫表達式。不過平時沒怎麼用過，就去一個MySQL的QQ羣裏諮詢了下，網友們都很熱情，在逗圖和吹牛逼的時候還順便回答了我這個問題。

若是咱們要更新的字段是 sum ，那麼就能夠直接寫「update table_name set sum = sum + 5 where id = 1;」就能夠了。而後我 就把這個狀況告訴老大了，老大說你測試下這個方式是否是線程安全的，還有測試下多線程下的效率。

我寫了個程序，測試了下效率，也查閱了咱們使用的MySQL引擎的文檔，在咱們的開發環境下是線程安全的，效率也讓老大看了，他以爲還能夠接受。而後，而後他就找 operate 部扯皮去了。

由於這樣更新數據，是線程安全的，因此當 operate 模塊是多線程的時候，使用這個方式更新數據，就不存在線程同步問題了。也就不必讓我再拉個統計線程出來了。

 

老大說更新數據庫的部分讓 operate 來作，operate 的人確定是不情願啦。他們說，既然已經這麼定了，就得這麼作，咱們的都快收尾了，你又讓咱們改這個。
老大說這麼作太複雜了，大家直接更新會更簡單。他們反問我老大，說：「既然這麼作簡單，你幹嗎一開始要那麼搞呢？」。老大愣了兩秒鐘，很憤怒的說：「當時沒人告訴我能夠這麼作啊！」。

後來兩個部門又開了個會，通過一天的扯皮，更新統計數據的部分，成功推給 operate 部去作了。後來我發現， operate 的東西其實並無收尾。

 

嗯，故事講完了，說說個人感覺。

首先，在聽到老大的憤怒後，我第一個想到的詞是，知識儲備。

至少從我剛剛經歷的這個事情來看，知識儲備是很是重要的事。雖然就是一個SQL語句的事兒，但是不知道這個用法的話，就真的會把東西弄複雜了。因此平時沒事的時候還真應該多讀書，多學習，增長本身的知識儲備，指不定在哪天就用到了呢。

第二點就是對事物審慎的態度。
在我告訴老大，我發現了一條真理的時候，他沒有讓我直接去用，而是讓我檢驗這個真理的安全性和性能如何。

這個也是很重要的。估計要是個人話，直接就用上了，萬一真的是性能達不到或者不支持線程安全的話，前面的工做估計也白作了。因此在接觸一個新東西的時候，應該先全方位的考察下這個東西是否是真的能解決眼下的問題，而且不會帶來新的問題。要是不能的話，那就寧願不要用。

 

---

 

同步發表於：http://www.fengbohello.top/blog/p/knowledge-reserve