http://mp.weixin.qq.com/s/bu86p2IcOFmHW5TJ9Xc_2A
一、需求缘起
【业务场景】
有一类写多读少的业务场景：大部分请求是对数据进行修改，少部分请求对数据进行读取。
例子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会成为潜在瓶颈，在这类高并发环境下写多读少的业务仓井，如何来进行优化，是本文将要讨论的问题。
二、水平切分+锁粒度优化
上文中之所以锁冲突严重，是因为所有司机都公用一把锁，锁的粒度太粗（可以认为是一个数据库的“库级别锁”），是否可能进行水平拆分（类似于数据库里的分库），把一个库锁变成多个库锁，来提高并发，降低锁冲突呢？显然是可以的，把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吗，这显然是不现实的。
三、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一个锁，锁的冲突也可能是很高的，还没有方法进一步提高并发呢？
四、把锁去掉，变成无锁缓存
【无锁的结果】
void AddCountByType(long type /, int count/){
//不加锁
Array[type]++; // 计数++
//Array[type] += count; // 计数增加count
}
【脏数据是如何产生的】
这个并发写的脏数据是如何产生的呢，详见下图：
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，可以从数据库中读取数据。
五、总结
在【超高并发】，【写多读少】，【定长value】的【业务缓存】场景下：
1）可以通过水平拆分来降低锁冲突
2）可以通过Map转Array的方式来最小化锁冲突，一条记录一个锁
3）可以把锁去掉，最大化并发，但带来的数据完整性的破坏
4）可以通过签名的方式保证数据的完整性，实现无锁缓存
评论
- 签名只是解决了原子性问题，没有解决可见性问题。写线程写入了，读线程不一定能读到。文中用的int16，主要是因为CPU保证原子写入吧，其实目前主流CPU能保证int32和int64原子写入的，但是不能保证的是跨线程可见性。比如没有volatile，一个int16就能够多线程++么，文中也是一样的，值和签名可能都是成功的，但是读线程来读时候，这这两个值可能都对其不可见。这时候产生脏读了。不过主存肯定会被刷新，所以看是否能够容忍，看过的主流实现，无锁java用的最多的还得加入CAS和volatile，golang很多用单goroutine操作读写。
- 还有就是对于addCountByType，内存直接++是不对的，加完直接刷主存，刷回去的数据可能是错的。因为读取到内存之后，写回主存之前，可能数据已经改变，刷回绝对值就让数据出错了
