如何实现超高并发的无锁缓存？

1、需求缘起

【业务场景】

有一类写多读少的业务场景：大部分请求是对数据进行修改，少部分请求对数据进行读取。

例子1：滴滴打车，某个司机地理位置信息的变化（可能每几秒钟有一个修改），以及司机地理位置的读取（用户打车的时候查看某个司机的地理位置）。

void SetDriverInfo(long driver_id, DriverInfoi); // 大量请求调用修改司机信息，可能主要是GPS位置的修改

DriverInfo GetDriverInfo(long driver_id);  // 少许请求查询司机信息

 

例子2：统计计数的变化，某个url的访问次数，用户某个行为的反做弊计数（计数值在不停的变）以及读取（只有少数时刻会读取这类数据）。

void AddCountByType(long type); // 大量增长某个类型的计数，修改比较频繁

long GetCountByType(long type); // 少许返回某个类型的计数

 

【底层实现】

具体到底层的实现，每每是一个Map（本质是一个定长key，定长value的缓存结构）来存储司机的信息，或者某个类型的计数。

Map<driver_id, DriverInfo>

Map<type, count>

 

【临界资源】

这个Map存储了全部信息，当并发读写访问时，它做为临界资源，在读写以前，通常要进行加锁操做，以司机信息存储为例：

void SetDriverInfo(long driver_id, DriverInfoinfo){

         WriteLock (m_lock);

         Map<driver_id>= info;

         UnWriteLock(m_lock);

}

 

DriverInfo GetDriverInfo(long driver_id){

         DriverInfo t;

         ReadLock(m_lock);

         t= Map<driver_id>;

         UnReadLock(m_lock);

         return t;

}

 

【并发锁瓶颈】

假设滴滴有100w司机同时在线，每一个司机没5秒更新一次经纬度状态，那么每秒就有20w次写并发操做。假设滴滴日订单1000w个，平均每秒大概也有300个下单，对应到查询并发量，多是1000级别的并发读操做。

上述实现方案没有任何问题，但在并发量很大的时候（每秒20w写，1k读），锁m_lock会成为潜在瓶颈，在这类高并发环境下写多读少的业务仓井，如何来进行优化，是本文将要讨论的问题。

 

2、水平切分+锁粒度优化

上文中之因此锁冲突严重，是由于全部司机都公用一把锁，锁的粒度太粗（能够认为是一个数据库的“库级别锁”），是否可能进行水平拆分（相似于数据库里的分库），把一个库锁变成多个库锁，来提升并发，下降锁冲突呢？显然是能够的，把1个Map水平切分红多个Map便可：

void SetDriverInfo(long driver_id, DriverInfoinfo){

         i= driver_id % N; // 水平拆分红N份，N个Map，N个锁

         WriteLock (m_lock [i]);  //锁第i把锁

         Map[i]<driver_id>= info;  // 操做第i个Map

         UnWriteLock (m_lock[i]); // 解锁第i把锁

}

 

每一个Map的并发量（变成了1/N）和数据量都下降（变成了1/N）了，因此理论上，锁冲突会成平方指数下降。

分库以后，仍然是库锁，有没有办法变成数据库层面所谓的“行级锁”呢，难道要把x条记录变成x个Map吗，这显然是不现实的。

 

3、MAP变Array+最细锁粒度优化

假设driver_id是递增生成的，而且缓存的内存比较大，是能够把Map优化成Array，而不是拆分红N个Map，是有可能把锁的粒度细化到最细的（每一个记录一个锁）。

void SetDriverInfo(long driver_id, DriverInfoinfo){

         index= driver_id;

         WriteLock (m_lock [index]);  //超级大内存，一条记录一个锁，锁行锁

         Array[index]= info; //driver_id就是Array下标

         UnWriteLock (m_lock[index]); // 解锁行锁

}

和上一个方案相比，这个方案使得锁冲突降到了最低，但锁资源大增，在数据量很是大的状况下，通常不这么搞。数据量比较小的时候，能够一个元素一个锁的（典型的是链接池，每一个链接有一个锁表示链接是否可用）。

 

上文中提到的另外一个例子，用户操做类型计数，操做类型是有限的，即便一个type一个锁，锁的冲突也多是很高的，尚未方法进一步提升并发呢？

 

4、把锁去掉，变成无锁缓存

【无锁的结果】

void AddCountByType(long type /*, int count*/){

         //不加锁

         Array[type]++; // 计数++

         //Array[type] += count; // 计数增长count

}

若是这个缓存不加锁，固然能够达到最高的并发，可是多线程对缓存中同一块定长数据进行操做时，有可能出现不一致的数据块，这个方案为了提升性能，牺牲了一致性。在读取计数时，获取到了错误的数据，是不能接受的（做为缓存，容许cache miss，却不容许读脏数据）。

 

【脏数据是如何产生的】

这个并发写的脏数据是如何产生的呢，详见下图：

1）线程1对缓存进行操做，对key想要写入value1

2）线程2对缓存进行操做，对key想要写入value2

3）若是不加锁，线程1和线程2对同一个定长区域进行一个并发的写操做，可能每一个线程写成功一半，致使出现脏数据产生，最终的结果即不是value1也不是value2，而是一个乱七八糟的不符合预期的值value-unexpected。

 

【数据完整性问题】

并发写入的数据分别是value1和value2，读出的数据是value-unexpected，数据的篡改，这本质上是一个数据完整性的问题。一般如何保证数据的完整性呢？

例子1：运维如何保证，从中控机分发到上线机上的二进制没有被篡改？

回答：md5

 

例子2：即时通信系统中，如何保证接受方收到的消息，就是发送方发送的消息？

回答：发送方除了发送消息自己，还要发送消息的签名，接收方收到消息后要校验签名，以确保消息是完整的，未被篡改。

当当当当 => “签名”是一种常见的保证数据完整性的常见方案。

 

【加上签名以后的流程】

加上签名以后，不但缓存要写入定长value自己，还要写入定长签名（例如16bitCRC校验）：

1）线程1对缓存进行操做，对key想要写入value1，写入签名v1-sign

2）线程2对缓存进行操做，对key想要写入value2，写入签名v2-sign

3）若是不加锁，线程1和线程2对同一个定长区域进行一个并发的写操做，可能每一个线程写成功一半，致使出现脏数据产生，最终的结果即不是value1也不是value2，而是一个乱七八糟的不符合预期的值value-unexpected，但签名，必定是v1-sign或者v2-sign中的任意一个 

4）数据读取的时候，不但要取出value，还要像消息接收方收到消息同样，校验一下签名，若是发现签名不一致，缓存则返回NULL，即cache miss。

 

固然，对应到司机地理位置，与URL访问计数的case，除了内存缓存以前，确定须要timer对缓存中的数据按期落盘，写入数据库，若是cache miss，能够从数据库中读取数据。

 

5、总结

在【超高并发】，【写多读少】，【定长value】的【业务缓存】场景下：

1）能够经过水平拆分来下降锁冲突

2）能够经过Map转Array的方式来最小化锁冲突，一条记录一个锁

3）能够把锁去掉，最大化并发，但带来的数据完整性的破坏

4）能够经过签名的方式保证数据的完整性，实现无锁缓存

 

以上内容均来自微信公众号“架构师之路”胡剑老师的文章，欢迎关注。