當優化擴展到多核時

"軟件開發沒有銀彈，我們能做的就是選擇和平衡;"

上一篇文章我們聊了在單線程下程序優化的5個方向（ref：《程序優化的5個方向》）；當單核優化到極值后，就到了多任務的情況；

想起來很清晰，單個任務分解成多個任務，讓多個cpu同時來工作，并行執行，效率自然就上去了；

但，未必就這么簡單；

任務分解的粒度

首先，我們需要確定，我們的單個任務是否可以分解；比如解析很多個文件，這樣的任務劃分成多個很簡單；但如果是一個耗時的串行邏輯計算，后期的計算依賴前期的結果，這樣就不好拆分；這種形式可能需要在更高層次上來拆分；

數據競爭

編程就是計算和數據；計算并行了，但數據還是訪問同一份，訪問共同的資源會產生資源競爭；

如果不進行控制，可能導致同一份數據重復計算（多個讀的場景）或是臟數據的產生（有回寫的場景）；

引入鎖

為了讓數據訪問有序進行，需要引入鎖來防止臟數據；

控制鎖的粒度，是個需要精心考慮的話題；

比如對于大量讀少量寫的場景，相比一視同仁的加鎖，使用讀寫鎖能顯著提升效率；

我們日常能接觸到的產品中，數據庫是個用鎖高手，在更新數據的時候，是鎖住行，還是列、或是表，不同的粒度性能相差明顯；

驚群現象

考慮這樣的場景：多個線程都在等在一個鎖，如果可以拿到鎖，線程就開始工作（線程池）

當鎖被釋放時，如果喚醒多個線程可能會產生 驚群現象；

解決方案：

使用單線程方案/處理accpet連接 處理等待鎖的操作，讓任何時刻只有一個線程在等待鎖；

更多細節參考：

《客戶-服務器程序設計方法》中 預先創建線程池，每個線程各自accept 一節

數據復制

讓每個線程使用自己的數據，讓數據不共有，這樣能去掉資源競爭，去掉鎖；

將數據復制為多份，減少競爭，各自訪問各自的數據；

但這又引入了一個新的問題：如果各個線程回寫了數據，如何保證這么數據的一致性？

畢竟它們代表的其實是一份數據；

涉及到數據的一致性，多份數據之間的同步又是個難題；

數據分片

那好，換個思路，不使用數據復制；我們使用數據分片；分片這個思想更容易想到，既然“計算”被劃分為多個小任務了，那么數據也可以同樣處理；

將數據分片，每份數據存的內容不相同，它們之間沒有共同點；

這樣，數據訪問沒有數據競爭，同時由于數據不同，也不涉及到數據一致性同步的問題；

但，分片遠遠沒有想的那么美好；

分片導致了每個線程看到數據不再是全集，而是片段；這就注定了這個線程只能處理這部分的特定數據；這樣，線程之間的計算失去了可替換性；某種工作只能在特定的線程上處理；

而如果有個任務需要訪問所有的數據，這樣就變得更加復雜；

原來，分片之后，我們將難題向上推了，推到線程層面，需要考慮到業務邏輯層面的處理；

這樣，可能更加復雜；

ok,想要速度更快，使用多核來處理，需要面對更多的問題；

將單機擴展多機集群，涉及到架構層面來看，其實我們的面對的問題是類似的；

參考：《大型網站技術架構》讀書筆記[2] - 架構的模式

軟件開發沒有銀彈，我們能做的就是選擇和平衡；