此文發布在博客園上，當然說的都是IT的事。
去年，在一汽車金融公司做內部網站，其中就發現一個奇葩的現象：發布一輛車源，后端服務返回成功，但是從數據庫查詢卻查詢不到結果，等待幾分鍾后，再查詢就有結果了。這是多爛的程序，出現這種bugs。再加之服務器端是之前.net1.4時代，用vb寫的，鄙夷之意頓生。所以找想相關的人去解決，告知后端有個隊列，不是直接入庫，所以問題解決不了。那沒辦法，是內網的系統，而且使用頻率不高，那就用使用者忍忍吧。服務器端在優化下，盡量直接入庫，反正后來優化到5秒多鍾，算是解決了。
去年下半年，為了追趕行業潮流，換了另外一個汽車行業公司，但是改做手機服務器端。到這發現，發車也是用隊列做的？why？而且用隊列實現的地方還很多，比如用戶登錄的時候記錄用戶登錄信息，用戶出錯后，記錄的日志，都是異步發向隊列的，之后直接返回。后來發現消息隊列其實是挺主流的東西，當數據量過大的時候，這樣能提高程序相應性能，減少數據庫壓力等等好處。只是自己見識短而已。
之后再程序設計中，出現一個需求。客戶端（client or app）需要對新消息進行提示，可以對於不同的客戶端顯示不一樣。（也就是這數據不存在服務器上，而是存在客戶端就行了），原有示例中是服務器端每次調用借口都返回最后（最新）的一條的時間，然后看這次返回的最后時間和上次是否一致，以判定是不是存在最新。看到這個設計，又忍不住笑。這種設計多笨啊！！客戶端有時間，每次調用的時候，客戶端把時間給服務器端就行了，反正不同客戶端顯示不一致是可以的。而且這樣客戶端也不用存儲這個時間。but，問題出現了，客戶端時間和服務器時間可能不一致，有些條目原本人家已經看過，但是由於客戶端時間比服務器端時間晚太多，所以下次還是顯示成未讀（有新消息），好吧，這是我的失誤，那我用服務器端時間，我不用查數據庫，總比你查數據庫取最后一條好點吧。再But，測試的時候出現問題了，還是原本看過的，依舊顯示成未讀？這是why？？？經過多次排查，千辛萬苦，找到了答案——入庫的時候時間是數據庫服務器生成的，而查詢的時候是服務端服務產生的時間，而數據庫和服務不再一台機器上，時間不一致！！！生產環境會這樣嗎？也許不會但是保不准，而且生產環境有n台服務作的負載，他們之間會不會有時間差。怎么辦？驀然回首，那人卻在燈火闌珊處。我用原來我嘲笑的方案，不就perfect了嗎？
自古文人相輕，現在程序員亦是。.net、java、PHP、JS紛爭能幾時。他山之石，可以攻玉。今天你所嘲笑的人，明天或許你就會成為他。哎。前人為之，后人不解而笑之；后人復為之，后后人不解而復笑之。