"軟體開發沒有銀彈，我們能做的就是選擇和平衡;"首先，我們需要確定，我們的單個任務是否可以分解；比如解析很多個檔案，這樣的任務劃分成多個很簡單；但如果是乙個耗時的序列邏輯計算，後期的計算依賴前期的結果，這樣就不好拆分；這種形式可能需要在更高層次上來拆分；
程式設計就是計算和資料；計算並行了，但資料還是訪問同乙份，訪問共同的資源會產生資源競爭；
如果不進行控制，可能導致同乙份資料重複計算（多個讀的場景）或是髒資料的產生（有回寫的場景）；
為了讓資料訪問有序進行，需要引入鎖來防止髒資料；
控制鎖的粒度，是個需要精心考慮的話題；
比如對於大量讀少量寫的場景，相比一視同仁的加鎖，使用讀寫鎖能顯著提公升效率；
我們日常能接觸到的產品中，資料庫是個用鎖高手，在更新資料的時候，是鎖住行，還是列、或是表，不同的粒度效能相差明顯；
考慮這樣的場景：多個執行緒都在等在乙個鎖，如果可以拿到鎖，執行緒就開始工作（執行緒池）
當鎖被釋放時，如果喚醒多個執行緒可能會產生 驚群現象；
解決方案：
使用單執行緒方案/處理accpet連線 處理等待鎖的操作，讓任何時刻只有乙個執行緒在等待鎖；
更多細節參考：
《客戶-伺服器程式設計方法》中 預先建立執行緒池，每個執行緒各自accept 一節
讓每個執行緒使用自己的資料，讓資料不共有，這樣能去掉資源競爭，去掉鎖；
將資料複製為多份，減少競爭，各自訪問各自的資料；
但這又引入了乙個新的問題：如果各個執行緒回寫了資料，如何保證這麼資料的一致性？
畢竟它們代表的其實是乙份資料；
涉及到資料的一致性，多份資料之間的同步又是個難題；
那好，換個思路，不使用資料複製；我們使用資料分片；分片這個思想更容易想到，既然「計算」被劃分為多個小任務了，那麼資料也可以同樣處理；
將資料分片，每份資料存的內容不相同，它們之間沒有共同點；
這樣，資料訪問沒有資料競爭，同時由於資料不同，也不涉及到資料一致性同步的問題；
但，分片遠遠沒有想的那麼美好；
分片導致了每個執行緒看到資料不再是全集，而是片段；這就注定了這個執行緒只能處理這部分的特定資料；這樣，執行緒之間的計算失去了可替換性；某種工作只能在特定的執行緒上處理；
而如果有個任務需要訪問所有的資料，這樣就變得更加複雜；
原來，分片之後，我們將難題向上推了，推到執行緒層面，需要考慮到業務邏輯層面的處理；
這樣，可能更加複雜；
ok,想要速度更快，使用多核來處理，需要面對更多的問題；
將單機擴充套件多機集群，涉及到架構層面來看，其實我們的面對的問題是類似的；
參考：《大型**技術架構》讀書筆記[2] - 架構的模式
軟體開發沒有銀彈，我們能做的就是選擇和平衡；
posted by: 大cc | 13aug,2015
部落格：blog.me115.com [訂閱]
github：大cc
當優化擴充套件到多核時
軟體開發沒有銀彈，我們能做的就是選擇和平衡 首先，我們需要確定，我們的單個任務是否可以分解 比如解析很多個檔案，這樣的任務劃分成多個很簡單 但如果是乙個耗時的序列邏輯計算，後期的計算依賴前期的結果，這樣就不好拆分 這種形式可能需要在更高層次上來拆分 程式設計就是計算和資料 計算並行了，但資料還是訪問...
當優化擴充套件到多核時
軟體開發沒有銀彈，我們能做的就是選擇和平衡 首先，我們需要確定，我們的單個任務是否可以分解 比如解析很多個檔案，這樣的任務劃分成多個很簡單 但如果是乙個耗時的序列邏輯計算，後期的計算依賴前期的結果，這樣就不好拆分 這種形式可能需要在更高層次上來拆分 程式設計就是計算和資料 計算並行了，但資料還是訪問...
演算法作業 八皇后問題擴充套件到N皇后
問題背景 在 8 8 格的西洋棋上擺放八個皇后，使其不能互相攻擊，即任意兩個皇后都不能處於同一行 同一列或同一斜線上，輸出所有擺法。環境 vs2017 include pch.h include include include using namespace std const int max si...