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

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

上一篇文章我們聊了在單線程下程序優(yōu)化的5個方向（ref：《程序優(yōu)化的5個方向》）；當單核優(yōu)化到極值后，就到了多任務(wù)的情況；
想起來很清晰，單個任務(wù)分解成多個任務(wù)，讓多個cpu同時來工作，并行執(zhí)行，效率自然就上去了；
但，未必就這么簡單；

任務(wù)分解的粒度

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

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

編程就是計算和數(shù)據(jù)；計算并行了，但數(shù)據(jù)還是訪問同一份，訪問共同的資源會產(chǎn)生資源競爭；
如果不進行控制，可能導(dǎo)致同一份數(shù)據(jù)重復(fù)計算（多個讀的場景）或是臟數(shù)據(jù)的產(chǎn)生（有回寫的場景）；

引入鎖

為了讓數(shù)據(jù)訪問有序進行，需要引入鎖來防止臟數(shù)據(jù)；
控制鎖的粒度，是個需要精心考慮的話題；
比如對于大量讀少量寫的場景，相比一視同仁的加鎖，使用讀寫鎖能顯著提升效率；
我們?nèi)粘Ｄ芙佑|到的產(chǎn)品中，數(shù)據(jù)庫是個用鎖高手，在更新數(shù)據(jù)的時候，是鎖住行，還是列、或是表，不同的粒度性能相差明顯；

驚群現(xiàn)象

考慮這樣的場景：多個線程都在等在一個鎖，如果可以拿到鎖，線程就開始工作（線程池）
當鎖被釋放時，如果喚醒多個線程可能會產(chǎn)生 驚群現(xiàn)象；
解決方案：
使用單線程方案/處理accpet連接 處理等待鎖的操作，讓任何時刻只有一個線程在等待鎖；
更多細節(jié)參考：
《客戶-服務(wù)器程序設(shè)計方法》中 預(yù)先創(chuàng)建線程池，每個線程各自accept 一節(jié)

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

讓每個線程使用自己的數(shù)據(jù)，讓數(shù)據(jù)不共有，這樣能去掉資源競爭，去掉鎖；
將數(shù)據(jù)復(fù)制為多份，減少競爭，各自訪問各自的數(shù)據(jù)；
但這又引入了一個新的問題：如果各個線程回寫了數(shù)據(jù)，如何保證這么數(shù)據(jù)的一致性？
畢竟它們代表的其實是一份數(shù)據(jù)；

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

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

那好，換個思路，不使用數(shù)據(jù)復(fù)制；我們使用數(shù)據(jù)分片；分片這個思想更容易想到，既然“計算”被劃分為多個小任務(wù)了，那么數(shù)據(jù)也可以同樣處理；
將數(shù)據(jù)分片，每份數(shù)據(jù)存的內(nèi)容不相同，它們之間沒有共同點；
這樣，數(shù)據(jù)訪問沒有數(shù)據(jù)競爭，同時由于數(shù)據(jù)不同，也不涉及到數(shù)據(jù)一致性同步的問題；
但，分片遠遠沒有想的那么美好；
分片導(dǎo)致了每個線程看到數(shù)據(jù)不再是全集，而是片段；這就注定了這個線程只能處理這部分的特定數(shù)據(jù)；這樣，線程之間的計算失去了可替換性；某種工作只能在特定的線程上處理；
而如果有個任務(wù)需要訪問所有的數(shù)據(jù)，這樣就變得更加復(fù)雜；
原來，分片之后，我們將難題向上推了，推到線程層面，需要考慮到業(yè)務(wù)邏輯層面的處理；
這樣，可能更加復(fù)雜；

ok,想要速度更快，使用多核來處理，需要面對更多的問題；
將單機擴展多機集群，涉及到架構(gòu)層面來看，其實我們的面對的問題是類似的；
參考：《大型網(wǎng)站技術(shù)架構(gòu)》讀書筆記[2] - 架構(gòu)的模式

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

Posted by: 大CC | 13AUG,2015
博客：blog.me115.com [訂閱]
Github：大CC

總結(jié)

以上是生活随笔為你收集整理的当优化扩展到多核时的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。