事情的經過是這樣的：
一個夏日的午后，我在啪啪啪的敲代碼，正爽着呢，老大在背后拍了拍我的肩膀，說讓我寫個功能。
我說啥功能，他說：“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