C++高並發場景下讀多寫少的優化方案
概述
一談到高並發的優化方案，往往能想到模塊水平拆分、數據庫讀寫分離、分庫分表，加緩存、加mq等，這些都是從系統架構上解決。單模塊作為系統的組成單元，其性能好壞也能很大的影響整體性能，本文從單模塊下讀多寫少的場景出發，探討其解決方案，以其更好的實現高並發。
不同的業務場景，讀和寫的頻率各有側重，有兩種常見的業務場景：
- 讀多寫少：典型場景如廣告檢索端、白名單更新維護、loadbalancer
- 讀少寫多：典型場景如qps統計
本文針對讀多寫少（也稱一寫多讀）場景下遇到的問題進行分析，並探討一種合適的解決方案。
分析
讀多寫少的場景，服務大部分情況下都是處於讀，而且要求讀的耗時不能太長，一般是毫秒或者更低的級別；更新的頻率就不是那么頻繁，如幾秒鍾更新一次。通過簡單的加互斥鎖，騰出一片臨界區，往往能到達預期的效果，保證數據更新正確。
但是，只要加了鎖，就會帶來競爭，即使加的是讀寫鎖，雖然讀之間不互斥，但寫一樣會影響讀，而且讀寫同時爭奪鎖的時候，鎖優先分配給寫（讀寫鎖的特性）。例如，寫的時候，要求所有的讀請求阻塞住，等到寫線程或協程釋放鎖之后才能讀。如果寫的臨界區耗時比較大，則所有的讀請求都會受影響，從監控圖上看，這時候會有一根很尖的耗時毛刺，所有的讀請求都在隊列中等待處理，如果在下個更新周期來之前，服務能處理完這些讀請求，可能情況沒那么糟糕。但極端情況下，如果下個更新周期來了，讀請求還沒處理完，就會形成一個惡性循環，不斷的有讀請求在隊列中等待，最終導致隊列被擠滿，服務出現假死，情況再惡劣一點的話，上游服務發現某個節點假死后，由於負載均衡策略，一般會重試請求其他節點，這時候其他節點的壓力跟着增加了，最終導致整個系統出現雪崩。
因此，加鎖在高並發場景下要盡量避免，如果避免不了，需要讓鎖的粒度盡量小，接近無鎖（lock-free）更好，簡單的對一大片臨界區加鎖，在高並發場景下不是一種合適的解決方案
雙緩沖
有一種數據結構叫雙緩沖，其這種數據結構很常見，例如顯示屏的顯示原理，顯示屏顯示的當前幀，下一幀已經在后台的buffer准備好，等時間周期一到，就直接替換前台幀，這樣能做到無卡頓的刷新，其實現的指導思想是空間換時間，這種數據結構的工作原理如下：
- 數據分為前台和后台
- 所有讀線程讀前台數據，不用加鎖，通過一個指針來指向當前讀的前台數據
- 只有一個線程負責更新，更新的時候，先准備好后台數據，接着直接切指針，這之后所有新進來的讀請求都看到了新的前台數據
- 有部分讀還落在老的前台那里處理，因為更新還不算完成，也就不能退出寫線程，寫線程需要等待所有落在老前台的線程讀完成后，才能退出，在退出之前，順便再更新一遍老前台數據（也就當前的新后台），可以保證前后台數據一致，這點在做增量更新的時候有用
工程實現上需要攻克的難點
- 寫線程要怎么知道所有的讀線程在老前台中的讀完成了呢？
一種做法是讓各個讀線程都維護一把鎖，讀的時候鎖住，這時候不會影響其他線程的讀，但會影響寫，讀完后釋放鎖(某些時候可能會有通知寫線程的開銷，但由於寫的頻率很低，所以這點開銷還能接受)，寫線程只需要確認鎖有沒有釋放了，確認完了后馬上釋放，確認這個動作非常快（小於25ns，1s=1000ms=1000000us=1000000000ns），讀線程幾乎不會感覺到鎖的存在。 - 每個線程都有一把自己的鎖，需要用全局的map來做線程id和鎖的映射嗎？
不需要，而且這樣做全局map就要加全局鎖了，又回到了剛開始分析中遇到的問題了。其實，每個線程可以有私有存儲（thread local storage，簡稱TLS），如果是協程，就對應這協程的TLS（但對於go語言，官方是不支持TLS的，想實現類似功能，要么就想辦法獲取到TLS，要么就不要基於協程鎖，而是用全局鎖，但盡量讓鎖粒度小，本文主要針對C++語言，暫時不深入討論其他語言的實現）。這樣每個讀線程鎖的是自己的鎖，不會影響到其他的讀線程，鎖的目的僅僅是為了保證讀優先。
對於線程私有存儲，可以使用pthread_key_create, pthread_setspecific，pthread_getspecific系列函數
核心代碼實現
讀
template <typename T, typename TLS>
int DoublyBufferedData<T, TLS>::Read(
typename DoublyBufferedData<T, TLS>::ScopedPtr* ptr) { // ScopedPtr析構的時候，會釋放鎖
Wrapper* w = static_cast<Wrapper*>(pthread_getspecific(_wrapper_key)); //非首次讀，獲取pthread local lock
if (BAIDU_LIKELY(w != NULL)) {
w->BeginRead(); // 鎖住
ptr->_data = UnsafeRead();
ptr->_w = w;
return 0;
}
w = AddWrapper();
if (BAIDU_LIKELY(w != NULL)) {
const int rc = pthread_setspecific(_wrapper_key, w); // 首次讀，設置pthread local lock
if (rc == 0) {
w->BeginRead();
ptr->_data = UnsafeRead();
ptr->_w = w;
return 0;
}
}
return -1;
}
寫
template <typename T, typename TLS>
template <typename Fn>
size_t DoublyBufferedData<T, TLS>::Modify(Fn& fn) {
BAIDU_SCOPED_LOCK(_modify_mutex); // 加鎖，保證只有一個寫
int bg_index = !_index.load(butil::memory_order_relaxed); // 指向后台buffer
const size_t ret = fn(_data[bg_index]); // 修改后台buffer
if (!ret) {
return 0;
}
// 切指針
_index.store(bg_index, butil::memory_order_release);
bg_index = !bg_index;
// 等所有讀老前台的線程讀結束
{
BAIDU_SCOPED_LOCK(_wrappers_mutex);
for (size_t i = 0; i < _wrappers.size(); ++i) {
_wrappers[i]->WaitReadDone();
}
}
// 確認沒有讀了，直接修改新后台數據，對其新前台
const size_t ret2 = fn(_data[bg_index]);
return ret2;
}
完整實現請參考brpc的DoublyBufferData
擴展實現
基於計數器的實現
基於計數器，用atomic，保證原子性，讀進入臨界區，計數器+1，退出-1，寫判斷計數器為0則切換（但在計數器為0和切換中間，不能保證沒有新的讀進來，這時候也要鎖），而且計數器是全局鎖。這種方案C++也可以采取，只是計數器畢竟也是全局鎖，性能會差那么一丟丟。即使用智能指針shared_ptr，也會面臨切換之前計數器有變成非0的問題。之所以用計數器，而不用TLS，是因為有些語言，如golang，不支持TLS，對比TLS版本和計數器版本，TLS性能更優，因為沒有搶計數器的互斥問題，大概耗費700ns，很多嗎？搶計數器本身很快，性能沒測試過，可以試試。
golang中sync.Map的實現
也是基於計數器，只是計數器是為了讓讀前台緩存失效的概率不要太高，有抑制和收斂的作用，實現了讀的無鎖，少部分情況下，前台緩存讀不到數據的時候，會去讀后台緩存，這時候也要加鎖，同時計數器+1。計數器數值達到一定程度（超過后台緩存的元素個數），就執行切換
是否適用於讀少寫多的場景
不合適，雙緩沖優先保證讀的性能，寫多讀少的場景需要優先保證寫的性能。
相關文獻
brpc對於雙buffer的描述：https://www.bookstack.cn/read/incubator-brpc/3c7745da34a1418b.md#DoublyBufferedData
go實現的雙buffer（但讀是互斥的，性能先對較差）：http://blog.codeg.cn/2016/01/27/double-buffering/
雙buffer的三種實現方案：https://juejin.cn/post/6844904130989801479
一寫多讀：https://blog.csdn.net/lqt641/article/details/55058137
高並發下的系統設計：https://www.cnblogs.com/flame540/p/12817529.html
基於shared_ptr的實現，原理也是計數器，但感覺還是有缺陷：https://www.cnblogs.com/gaoxingnjiagoutansuo/p/15773361.html#4998436