浅谈C++高并发场景下读多写少的优化方案

 更新时间:2022年01月17日 12:44:41   作者:longbozhan  
本文主要介绍了浅谈C++高并发场景下读多写少的优化方案,文中通过示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下

来源:https://www.cnblogs.com/longbozhan/p/15780194.html

作者:longbozhan

概述

一谈到高并发的优化方案,往往能想到模块水平拆分、数据库读写分离、分库分表,加缓存、加mq等,这些都是从系统架构上解决。单模块作为系统的组成单元,其性能好坏也能很大的影响整体性能,本文从单模块下读多写少的场景出发,探讨其解决方案,以其更好的实现高并发。
不同的业务场景,读和写的频率各有侧重,有两种常见的业务场景:

  • 读多写少:典型场景如广告检索端、白名单更新维护、loadbalancer
  • 读少写多:典型场景如qps统计

本文针对读多写少(也称一写多读)场景下遇到的问题进行分析,并探讨一种合适的解决方案。

分析

读多写少的场景,服务大部分情况下都是处于读,而且要求读的耗时不能太长,一般是毫秒或者更低的级别;更新的频率就不是那么频繁,如几秒钟更新一次。通过简单的加互斥锁,腾出一片临界区,往往能到达预期的效果,保证数据更新正确。

但是,只要加了锁,就会带来竞争,即使加的是读写锁,虽然读之间不互斥,但写一样会影响读,而且读写同时争夺锁的时候,锁优先分配给写(读写锁的特性)。例如,写的时候,要求所有的读请求阻塞住,等到写线程或协程释放锁之后才能读。如果写的临界区耗时比较大,则所有的读请求都会受影响,从监控图上看,这时候会有一根很尖的耗时毛刺,所有的读请求都在队列中等待处理,如果在下个更新周期来之前,服务能处理完这些读请求,可能情况没那么糟糕。但极端情况下,如果下个更新周期来了,读请求还没处理完,就会形成一个恶性循环,不断的有读请求在队列中等待,最终导致队列被挤满,服务出现假死,情况再恶劣一点的话,上游服务发现某个节点假死后,由于负载均衡策略,一般会重试请求其他节点,这时候其他节点的压力跟着增加了,最终导致整个系统出现雪崩。

因此,加锁在高并发场景下要尽量避免,如果避免不了,需要让锁的粒度尽量小,接近无锁(lock-free)更好,简单的对一大片临界区加锁,在高并发场景下不是一种合适的解决方案

双缓冲

有一种数据结构叫双缓冲,其这种数据结构很常见,例如显示屏的显示原理,显示屏显示的当前帧,下一帧已经在后台的buffer准备好,等时间周期一到,就直接替换前台帧,这样能做到无卡顿的刷新,其实现的指导思想是空间换时间,这种数据结构的工作原理如下:

  • 数据分为前台和后台
  • 所有读线程读前台数据,不用加锁,通过一个指针来指向当前读的前台数据
  • 只有一个线程负责更新,更新的时候,先准备好后台数据,接着直接切指针,这之后所有新进来的读请求都看到了新的前台数据
  • 有部分读还落在老的前台那里处理,因为更新还不算完成,也就不能退出写线程,写线程需要等待所有落在老前台的线程读完成后,才能退出,在退出之前,顺便再更新一遍老前台数据(也就当前的新后台),可以保证前后台数据一致,这点在做增量更新的时候有用

工程实现上需要攻克的难点

写线程要怎么知道所有的读线程在老前台中的读完成了呢?

一种做法是让各个读线程都维护一把锁,读的时候锁住,这时候不会影响其他线程的读,但会影响写,读完后释放锁(某些时候可能会有通知写线程的开销,但写本身很少),写线程只需要确认锁有没有释放了,确认完了后马上释放,确认这个动作非常快(小于25ns,1s=103ms=106us=10^9ns),读线程几乎不会感觉到锁的存在。

每个线程都有一把自己的锁,需要用全局的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

简单说说golang中双缓冲的实现

普通的双缓冲加载实现

基于计数器,用atomic,保证原子性,读进入临界区,计数器+1,退出-1,写判断计数器为0则切换,但计数器是全局锁。这种方案C++也可以采取,只是计数器毕竟也是全局锁,性能会差那么一丢丢。即使用智能指针shared_ptr,也会面临智能指针引用计数互斥的问题。之所以用计数器,而不用TLS,是因为go不支持TLS,对比TLS版本和计数器版本,TLS性能更优,因为没有抢计数器的互斥问题,但抢计数器本身很快,性能没测试过,可以试试。

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
基于计数器的实现:https://www.cnblogs.com/gaoxingnjiagoutansuo/p/15773361.html#4998436

到此这篇关于浅谈C++高并发场景下读多写少的优化方案的文章就介绍到这了,更多相关浅谈C++高并发场景下读多写少的优化方案内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • C++中vector的用法实例解析

    C++中vector的用法实例解析

    这篇文章主要介绍了C++中vector的用法,详细描述了vector的各种常见的用法及注意事项,需要的朋友可以参考下
    2014-08-08
  • STL各个容器性能详细比较

    STL各个容器性能详细比较

    从下面表中的数据来看写入用时vector和deque很快,因为他们内存分配次数少,关联容器和list都是一个一个分配的,一个一个分配也会造成内存碎片,内存利用率低
    2013-09-09
  • 纯C语言:贪心Prim算法生成树问题源码分享

    纯C语言:贪心Prim算法生成树问题源码分享

    这篇文章主要介绍了贪心Prim算法生成树问题源码,有需要的朋友可以参考一下
    2014-01-01
  • 关于STL的erase()陷阱-迭代器失效问题的总结

    关于STL的erase()陷阱-迭代器失效问题的总结

    下面小编就为大家带来一篇关于STL的erase()陷阱-迭代器失效问题的总结。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2016-12-12
  • C++11中delete和default的用法详解

    C++11中delete和default的用法详解

    这篇文章主要为大家详细介绍了C++11中delete和default的具体用法,文中的示例代码简洁易懂,具有一定的学习价值,感兴趣的小伙伴可以了解下
    2023-08-08
  • C++实现LeetCode(187.求重复的DNA序列)

    C++实现LeetCode(187.求重复的DNA序列)

    这篇文章主要介绍了C++实现LeetCode(187.求重复的DNA序列),本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下
    2021-07-07
  • QT6中QTextcodec头文件找不到的解决方法

    QT6中QTextcodec头文件找不到的解决方法

    本文主要介绍了QT6中QTextcodec头文件找不到的解决方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2023-02-02
  • C++中std::count函数介绍和使用场景

    C++中std::count函数介绍和使用场景

    std::count函数是一个非常实用的算法,它可以帮助我们快速统计给定值在指定范围内的出现次数,本文主要介绍了C++中std::count函数介绍和使用场景,感兴趣的可以了解一下
    2024-02-02
  • C语言实现学生管理系统的源码分享

    C语言实现学生管理系统的源码分享

    这篇文章主要为大家详细介绍了如何利用C语言实现学生管理系统,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2022-07-07
  • C++文件输入输出fstream使用方法

    C++文件输入输出fstream使用方法

    C++标准库提供了<fstream>头文件,其中包含了用于文件输入输出的相关类和函数,本文将详细介绍<fstream>头文件的使用方法,包括函数原型、打开文件、读取和写入文件、以及错误处理等注意事项,感兴趣的朋友跟随小编一起看看吧
    2023-10-10

最新评论