海量并发的无锁编程 （lock free programming），lockprogramming

海量并发的无锁编程 （lock free programming），lockprogramming

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

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

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

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

先想一个比较粗暴的办法：使用一个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)

lock 是锁止 free 是无锁状态
 

locked unlocked