由於專案並不會投入太多的時間，所以穩定性能是最終的。穩定性的可以從以下的維度進行考慮：
資料量不多的時候採用單執行緒。
異常處理。
重試。詳細的日誌。
個人覺得資料量少就是在40小時內遍歷全部並且可以爬完的就是小資料量。
異常處理主要就是放在請求**時、入庫。
而重試主要是用traceback這個庫，它的作用是捕捉到特定異常、設定重試間隔的時長、間隔時常的增長策略。如果真的想不到要在什麼地方寫重試就思考：
日誌的列印：
一開始可能會對什麼地方需要進行日誌列印感覺一點頭緒都沒。
我個人總結了幾點，
除重的策略主要是：
內容長的進行hash處理，通過對比hash來替代對比內容，例如，可以通過base64轉碼後hash縮小成64位，這樣的就不會有重複。
新增唯一索引，如果值有大量重複的列就不建議做唯一索引，例如性別，而幣種名稱就可以作為唯一索引，假如資料是一直在更新的那麼可以嘗試唯一聯合索引，例如幣種名稱和建立次條資訊的時間。
redis。
插入資料前先查一次，如果有物件就返回沒有就插入。
對於工作的一些思考
感覺自從領導讓我管專案以來,一直沒有讓領導很滿意的地方是自己在專案上花的心思太少.很簡單的一些例子就證明了,比如自己雖然是中途接手的專案,然後並沒有仔細檢視招標檔案,沒有針對招標檔案的要求 去核對乙方的一些功能是否完成.其次,對於乙方,我還在心裡上和行動上 做到完成把控住,我不僅要去分析我領導的想法...
對於Android MVP的一些思考（二）
上次對mvp的表面概念作出了一些思考 對於mvp 響應式程式設計以及事件匯流排的一些思考 而隨著對自己的mvp框架深入優化 擴充套件，也發現了一些疑惑的地方。相信接觸過mvp框架的都清楚，針對model view presenter這三者，都會為其單獨建立乙個inte ce，規範其各自的行為。舉個例...
對於Mysql更新的一些思考
1 緩衝池 buffer pool 快取資料頁和索引頁，加速查詢操作，避免每次查詢都需要進行磁碟隨機io 優化磁碟io隨機讀 2 寫緩衝區 change buffer 寫資料時，當資料不在緩衝池中，將資料直接寫入寫緩衝區中，資料不寫入磁碟資料頁 優化磁碟隨機寫 3 日誌緩衝區 log buffer ...