當優(yōu)化擴展到多核時

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

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

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

但，未必就這么簡單；

任務分解的粒度

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

數(shù)據(jù)競爭

編程就是計算和數(shù)據(jù)；計算并行了，但數(shù)據(jù)還是訪問同一份，訪問共同的資源會產(chǎn)生資源競爭；

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

引入鎖

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

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

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

我們?nèi)粘Ｄ芙佑|到的產(chǎn)品中，數(shù)據(jù)庫是個用鎖高手，在更新數(shù)據(jù)的時候，是鎖住行，還是列、或是表，不同的粒度性能相差明顯；

驚群現(xiàn)象

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

當鎖被釋放時，如果喚醒多個線程可能會產(chǎn)生 驚群現(xiàn)象；

解決方案：

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

更多細節(jié)參考：

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

數(shù)據(jù)復制

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

將數(shù)據(jù)復制為多份，減少競爭，各自訪問各自的數(shù)據(jù)；

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

畢竟它們代表的其實是一份數(shù)據(jù)；

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

數(shù)據(jù)分片

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

將數(shù)據(jù)分片，每份數(shù)據(jù)存的內(nèi)容不相同，它們之間沒有共同點；

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

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

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

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

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

這樣，可能更加復雜；

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

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

參考：《大型網(wǎng)站技術(shù)架構(gòu)》讀書筆記[2] - 架構(gòu)的模式

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