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

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

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

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

上文中之所以锁冲突严重，是因为所有司机都公用一把锁，锁的粒度太粗(可以认为是一个数据库的“库级别锁”)，是否可能进行水平拆分(类似于数据库里的分库)，把一个库锁变成多个库锁，来提高并发，降低锁冲突呢?显然是可以的，把1个Map水平切分个Map的并发量(变成了1/N)和数据量都降低(变成了1/N)了，所以理论上，锁冲突会成平方指数降低。

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

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

假设driver_id是递增生成的，并且缓存的内存比较大，是可以把Map优化成Array，而不是拆分成N个Map，是有可能把锁的粒度细化到最细的(每个记录一个锁)。和上一个方案相比，这个方案使得锁冲突降到了最低，但锁资源大增，在数据量非常大的情况下，一般不这么搞。数据量比较小的时候，可以一个元素一个锁的(典型的是连接池，每个连接有一个锁表示连接是否可用)。

上文中提到的另一个例子，用户操作类型计数，操作类型是有限的，即使一个type一个锁，锁的冲突也可能是很高的，还没有方法进一步提高并发呢对缓存进行操作，对key想要写入value2

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

【数据完整性问题】

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

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

回答：md5

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

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

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

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!