一 mqtt連線數報警
有天下午快下班的時候，突然mqtt不斷報警，手機上5秒一次收到報警簡訊，提示mqtt連線數已經超標(用阿里雲的產品感覺這塊的預警功提示的還是蠻及時)，因為當初也有一些搖搖車在做測試，頻繁的使用到mqtt，所以當時也沒太在意，叫測試人員先停一下在做測試(這個裡面很尷尬，搖搖車掃碼啟動用到的測試環境和線上環境是同乙個mqtt，這個後面再詳情描述原因)以為過一會連線數會釋放下去，但是手機收到報警簡訊越來越猛，當時第一時間想到的整體事故點應該在mqtt業務應用層這一端(手機掃碼是通過http請求到mqtt應用層，mqtt應用層再扔訊息到阿里雲mqtt伺服器)，當初是2臺mqtt應用層在做負載均衡集群，我登入2臺伺服器，分別用top命令檢視兩台伺服器一台cpu在80%左右，另外一台cpu在60%左右，頓時覺得很詫異，這麼點搖搖車資料請求不至於導致應用伺服器承受不了，當時第一時間想到的是看看tcp的目前的連線數，結果一查嚇了跳(使用命令:netstat -natp|awk '' |sort|uniq -c|sort -rn)，兩台伺服器的當前連線數都接近快1w多，還在持續上公升(因為當時投放出去的搖搖車還在不斷有人在使用消費)，這個時候基本定位問題：手機掃碼傳送http請求到mqtt應用層，mqtt應用層每次仍訊息到阿里雲mqtt伺服器，都需要建立連線。所以問題很有可能是沒有釋放連線，由於當初的**邏輯比較簡單，所以直接找到寫這個**的開發人員，一起喵了眼**，果然如此，修改**後，重新發包一切正常，手機報警簡訊立馬停了。
public
void
sendmsgmqtt
(string productid, string deviceid, string scontent, string topic)
catch (mqttexception e)
try catch (interruptedexception e) }}
public
void
messagearrived
(string topic, mqttmessage mqttmessage)
throws exception
public
void
deliverycomplete
(imqttdeliverytoken imqttdeliverytoken)
});sampleclient.connect(connopts);
trycatch(exception ex)finally
}catch(exception ex)
}
必須要先說下，創業專案初期，當初的業務都是很不清晰的，基本屬於那種摸著石頭過河，走一步算一步，再回頭想想甚至看看市場的反應，然後再修改，所以這個階段更多的是檢驗模式，優化業務，當然資金也有限，而且要求開發迭代要求迅速，所以資料庫當初沒有做集群，就是一台，玩單機，也正是因為玩單機，所以一些在集群環境下沒有這麼快爆發出來的問題很容易在單機裡面爆發出來。
晚上大概7點左右(晚點7點到9點是搖搖車的使用高峰，白天一般訂單資料較少，到了晚上資料成倍的增漲)，收到反饋，說平台系統開啟很慢很慢，而且手機也不斷收到mqtt簡訊預警，說堆積了大量未消費的訂單，第一時間的反應迅速登入雲資料庫管理平台看到資料庫cpu這項指標嚴重標紅，並顯示使用率達到100%。當初資料庫用的是通用型4核8g的，訂單表資料將近40w，開啟資料庫效能管理介面檢視(如果沒有這種管理介面，也可以通過命令show processlist來檢視正在執行的sql和explain來分析執行計畫檢視慢sql)，發現積累了大量的慢sql，有些sql的平均執行時間超過將近1分鐘，很明顯做了資料庫的全域性掃瞄，再加上這段時間的高峰時期，慢sql堆積，導致cpu資源順序消耗完。
當時也正是業務的使用的高峰期，再加上客戶投訴和上面很多人在盯著這個事情，所以我這邊要在短時間內恢復資料庫的正常，當初有幾種選擇可以迅速恢復，將資料庫切換到備資料庫（資料庫是高可用的）或者kill掉一些慢sql（通過show processlist檢視state為sending data的列，然後kill id），這些都有可能會影響到現在正在使用的業務，萬不得已的情況的不會第一時間去做。我看了下排在前面的幾條慢sql，其中有些是第一時間可以迅速處理的，比如優化索引，我抱著試試的方法，將之前有些索引重新優化了下(後面會詳細描述)，過了幾分鐘，cpu的使用率慢慢的降了下來（沒有優化索引之前大概3秒執行乙個記錄，優化索引後1秒可以執行上千個記錄），業務正常了，給我後面做資料庫的優化有了大把時間思考，所以這次事件給我最大的感觸就是切勿頭腦發熱，需要冷靜最小化處理問題。
1.新增索引和優化索引，特別小心索引隱式轉換
乙個表裡面如果只是設定了主鍵，然後其它索引一律不建不管，簡單業務如只涉及到按照主鍵查詢的業務是沒問題，但是設計到其它欄位的查詢，在資料量稍大又加上業務高峰期，這種導致表全域性查詢的sql肯定會積累大量慢sql，最終導致cpu持續上公升，如果有條件的話，測試最好做一些大資料量的壓力測試是可以測試出來的，另外，建立了索引，也要注意到索引失效這種情況。如：select *from order where phone=13772556391; 平時寫**粗心大意，不仔細檢查再加上壓力測試沒測試到位，在高併發資料量稍微大點的業務場景裡面搞不好就出問題。資料庫表phone欄位用的字串型別，但是這個sql裡面沒有加上引號，所以像這種情況下，索引是無效的。
2.分頁查詢優化
select * from orderwhere oid=100 limit 100000，5000，這種普通limit m，n的翻頁寫法，在越往後翻頁的過程中速度越慢，原因mysql會讀取表中的前m+n條資料，m越大，效能就越差。像這種sql如果只是平時查詢看看記錄，感覺不到異常，就算稍微慢點，也忍了，但是在我剛才說的業務場景裡面，也會導致慢sql查詢積累。優化寫法：select t1.* from order t1,(select id from order oid=100 limit 100000，5000) t2 where t1.id=t2.id，這種效率會高很好。
3.分表
雖然做了上面的優化，執行效率比之前高了很多台階，但是單表達的壓力依然存在。訂單表當時沒有做分表，儘管目前的條件沒有用分片集群，但是為解決燃眉之需也需要做物理分表(隨著投放出去的搖搖車越來越多，當時每天訂單大約1萬到2萬)。
sql優化是乙個長期的過程，最好是結合具體業務場景來做優化效率會更好一些，後面我會繼續羅列在這個專案實戰中出現的一些關於sql的坑和做的相關優化。
我的物聯網專案之推廣策略
這個裡面從最開始推廣入口來說，現在想來其實有點意淫，也正是我前面所說，路要走過才知道，我們現在就走趟雷。推廣人員全部由外面兼職或者全職做為主力軍，當初給他們的政策就是成功推廣一輛搖搖車提成50元 聽說有時候具體情況也有提成100元的 很多推廣人員看到這麼高的利潤，著實掄起衣袖實幹了一把。注意，這個裡...
我的物聯網專案之線下之戰
搖搖車這個行業在中國至少已經存在了7，8年以上，這期間也越來越多的投放商加入到這個隊伍裡面，說明這個行業本身是剛性需求，不要小看這一塊錢現金流，如果投放的數量達到一定程度，每天的現金收入是非常可觀的。這麼來算 粗略的算 投放100輛車出去，每輛車每天消費15次也就是說每天賺15塊錢，每天總收入有15...
我的物聯網專案 十 線下之戰
搖搖車這個行業在中國至少已經存在了7，8年以上，這期間也越來越多的投放商加入到這個隊伍裡面，說明這個行業本身是剛性需求，不要小看這一塊錢現金流，如果投放的數量達到一定程度，每天的現金收入是非常可觀的。這麼來算 粗略的算 投放100輛車出去，每輛車每天消費15次也就是說每天賺15塊錢，每天總收入有15...