今天又開了1個多小時的會議去討論一個不是那么明確的問題。在會議上經(jīng)過多次的提問，我發(fā)現(xiàn)了我們項目組存在的一個很嚴(yán)重的問題--言之無物！

開始的時候我們討論為什么郵件延時的解決方案。發(fā)送一個郵件大約的耗時如下：

1、讀取郵件數(shù)據(jù)（2～3ms 每1000條）

2、生成郵件（20-50ms每次調(diào)用，每一次發(fā)郵件都需要讀取一次）

3、IO操作（包括網(wǎng)絡(luò)）（網(wǎng)絡(luò)不出錯，20ms，網(wǎng)絡(luò)出錯1000ms）

4、更改數(shù)據(jù)狀態(tài)（50ms每條）

5、寫日志（60ms每條）

開始的時候，項目經(jīng)理說，把4和5優(yōu)化一下，優(yōu)化成批量更新，這個沒有問題，接著就把2也優(yōu)化一下，改成每個模板只讀一次。不是每次都讀一次，好吧也沒有問題。然后討論著討論著，就到了典型的研發(fā)開會，越來越復(fù)雜，有人說4和5直接先寫到文件中去，等空閑再去寫回數(shù)據(jù)庫，有人說先生成所有的郵件，再去發(fā)送（因為郵件其實是有重復(fù)的）。后來我幽幽的問了一句，3失敗率是多少？不知道。大哥，你怎么可以不知道，如果失敗率是2%那么發(fā)送時間就會增加一倍，那如果更高了。后來有人說優(yōu)化4（4分兩步，一步是更新狀態(tài)，另外一步是移到歷史表），在第一步的時候?qū)?shù)據(jù)狀態(tài)改為發(fā)送狀態(tài)，然后再用另外一個線程移入歷史表，或者在第一步的時候?qū)?shù)據(jù)移入一個過渡表，然后再移入歷史表。這時候我又問了一句，是更新快還是移走快？有人說更新快，有人說移走快。我又說，可以叫DBA分析一下，oralce有這個功能，沒人說話。。。再或來的討論，發(fā)現(xiàn)，瓶頸根本不在我們的系統(tǒng)，而是另外一個系統(tǒng)，那個系統(tǒng)的郵件量是我們的10幾倍。。。于是我們決定把那個系統(tǒng)隔離開來，留待以后做優(yōu)化。

看完上面的經(jīng)過，我不知道你們有什么感受，有什么想說的。我當(dāng)時想到的就是為什么我們開會就是沒有人會拿數(shù)據(jù)出來說話？為什么都是想當(dāng)然的去優(yōu)化，要知道數(shù)據(jù)才是最重要的呀。有人說，上面不是給數(shù)據(jù)了嗎，但是請想一下，對于一個一天發(fā)幾十萬郵件甚至上百萬郵件的系統(tǒng)來說上面5點的數(shù)據(jù)是沒用的。因為這個時候我們需要的是一個可接受的，大范圍的抽樣。比如我問得，失敗率是多少？

有時候分析問題，把數(shù)據(jù)拿出來了，你會發(fā)現(xiàn)這個世界廓然開朗。問題已經(jīng)不是問題了。

?

ps：博客園的memcache緩存好像有問題，用wl寫了之后打開后臺看不到文章。。。

轉(zhuǎn)載于:https://www.cnblogs.com/hrmai/archive/2010/08/12/1798521.html

總結(jié)

以上是生活随笔為你收集整理的言之有物的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。