當前開發專案需求：需要上鏈一天10萬條資料，後台使用閘道器暴露服務
（只是一家isv10萬，後期可能資料量非常大，需要轉移資料）
（區塊鏈溯源baas平台，提供安全管理服務）
優化：使用批處理插入資料，資料設定unique key，時間大概1秒左右。成功則插入，失敗則校驗失敗。
優化：驗證發現傳送大量資料（1m）到訊息佇列的時間也和一條資料（1k）基本一致，直接傳送200條資料一次性傳送到mq，由於200條資料一次性處理對伺服器影響不是很大，並且總共有10萬條資料，所以大概率不會出現一台消費伺服器負載很大的情況。
優化：碰到問題druid執行緒池太小，等待時間太短導致出現問題，改為設定druid連線池大小為100，等待時間為60秒。（極 端情況下可能會出現訊息生產方占用druid執行緒，消費方無法及及時獲取執行緒導致異常）
優化：由於乙個批次都是乙個最終狀態，所以把迴圈修改部分資料放到一起，用in代替=，最終花費0.1s - 0.2s。
1、rds實現（線上第二版本需要快速迭代，所以先採用資料庫進行。申請redis流程複雜）
建立分布式鎖資料庫表，查詢時鎖定指定行記錄。上鏈後開放記錄，再次進行當前資料狀態查詢。
優化：直接在第一條記錄做中間狀態，用update + where只放開一條記錄的通行，不需建立分布式鎖表，且減少資料查詢時 間。
2、redis實現
暫時未使用
優化：新增重試機制，上鏈部分重試一定次數。
消費者執行緒過多，修改消費者執行緒為4個執行緒，採用2臺4核8g伺服器測試服務。修改配置服務後只執行消費者gc平均觸發 頻率在20秒一次。
1、批處理非同步訊息
利用rocketmq設定的消費超時時間，和設定冪等中間狀態的時間判斷訊息是rocketmq超時訊息重發還是初次傳送來進行批處 理子項的上鏈操作。
2、單條同步訊息
利用伺服器啟動查詢單條型別的訊息，若是為未處理則進行上鏈操作。
修改壓測執行緒為40左右，線上連線為2000故無影響
Django專案資料處理的流程是怎樣的
給學生講解用，看了很多部落格，感覺都不是自己想要的。使用者在瀏覽器裡輸入乙個位址 首先處理這個位址的應該是nginx伺服器或者apache伺服器，這裡以nginx伺服器為例 nginx立即把靜態資源返回給使用者 如果需要把動態資源給使用者，則將動態請求的 url交給django處理 通過 uwsgi...
資料處理相關的優化
等深層機制應用和研究，只是些膚淺應用和建議 關於資料處理相關的優化 一 sqldataread 和dataset 的選擇 sqldataread優點 讀取資料非常快。如果對返回的資料不需做大量處理的情況下，建議使用sqldatareader，其效能要比datset好很多。缺點 直到資料讀完才可clo...
python中scrapy處理專案資料的例項分析
在我們處理完資料後，習慣把它放在原有的位置，但是這樣也會出現一定的隱患。如果因為新資料的加入或者其他種種原因，當我們再次想要啟用這個檔案的時候，小夥伴們就會開始著急卻怎麼也翻不出來，似乎也沒有其他更好的蒐集辦法，而重新進行資料整理顯然是不現實的。下面我們就一起看看python爬蟲中sc處理專案資料的...