海量并发的无锁编程 (lock free programming)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/anzhsoft2008/article/details/40118695

最近在做在线架构的实现,在线架构和离线架构近线架构最大的区别是服务质量(SLA,Service Level Agreement,SLA 99.99代表10K的请求最多一次失败或者超时)和延时。而离线架构在意的是吞吐,SLA的不会那么严苛,比如99.9。离线架构一般要有流控,以控制用户发送请求的速度。以免多于服务端处理能力的请求造成大量的数据在buffer或者队列里堆积,造成大量的超时。在线架构不可能有流控了,你不能限制用户的请求。因此在线架构对于弹性扩容有很高的要求,在大量请求到来时自动扩展后台的服务能力。比如当前的请求已经占用了集群的70%的资源时,系统需要自动的扩容;相反,当前的请求仅仅占用了集群20%的资源时,有必要回收一部分资源了。要知道,公司机房的电费还是很贵的。

当然了在线和离线架构的相同和区别谈起来完全是一个大文章。本文主要关注在处理高并发请求的锁的使用上。几个原则吧:

  1. 不要使用全局锁。使用全局锁代表在需要请求锁时,其他为得到锁的线程都会等待,这将导致服务能力急剧下降。
  2. 一定要注意锁的作用范围,一定要保证锁作用于足够小的范围。一定不要在锁定区域有等待操作,比如IO调用。
  3. 尽量的考虑修改架构,避免加锁。

试想一个场景,为了服务质量,我们可能发送多个请求到后台,以达到:

  1. 高可用行,后台的某个节点挂了,有其他的backup request会被请求。如果节点的SLA是99%(很低了),那么发送2个请求到后台,SLA可以达到99.99%;如果单个节点的SLA是99.9%的话,SLA可以达到99.9999了,即百万次请求至多一次失败。
  2. 低延时,第一个回来的请求会响应,这样的话能够保证某些慢的节点不会影响系统整体的延时。

那么如何判断第一个请求是第一个达到的呢?

先想一个比较粗暴的办法:使用一个set记录未返回的request 的id,然后在接到响应时,查看这个set有没有这个id,如果有,删除它,并且响应client;第二个以后的响应达到时,由于在set已经没有这个id了,因此这些请求将被丢弃。

这个里边涉及到对set的读和写操作,这个需要加锁;如果这个set是进程内可见的,那么这个锁就是进程级别的(或者说该进程或者说是线程的子线程都是可见的),加锁时很多线程都会等待该锁。这样的话对性能会有很大损耗。

这个方法对于每秒几百次请求是没有问题的。但是如果达到千这个级别,那么锁的使用会达到数千次(比如1000个请求,发送3个请求到后台,那么每次写set加一次锁,3个请求回来都会加一次锁,因此相当于一个真实的请求会加锁4次,1000个请求就是4000次,想想都恐怖,1s要加锁4000次,锁的代价再小也很恐怖吧,别说set的插入和查询,删除也有不可忽略的性能损耗)。

那么可不可以加线程级别的锁?线程级别的锁会减少对其他线程的影响。但是,set如果也是线程级别的,那么得保证异步回调的借口也得是在同一个线程才可以。否则这个线程发出的请求,被其他的线程得到,那么上述的逻辑是不通的,因为set是线程级别的,对于其他线程来说是不可见的。这样的话如果架构能够保证一个异步请求的返回,也是在同一个线程处理就好了。那么,如果架构可以这么保证,那么你根本不需要锁,为什么呢?因为一个线程都是顺序执行的,不会有资源的竞争,因此读写set都是安全的,因此不需要加锁。

那么问题来了,架构如何支持这个异步回调也是走到相同的线程里?

一个实现就是实现一个线程池,对于特定的request id,基于一定的规则将他调度给一个工作线程;等到异步返回时,再通过这个request id调度给相同的线程处理。

那么如何实现一个线程池?boost 里有; 如果调度,boost 支持调度给哪个线程。问题解决。

睡觉。


当然了,你以为无锁编程会涉及CAS,那么可以移步 并发编程(三): 使用C++11实现无锁stack(lock-free stack)


展开阅读全文

没有更多推荐了,返回首页