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

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

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

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

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

每个Map的并发量(变成了1/N)和数据量都降低(变成了1/N)了，所以理论上，锁冲突会成平方指数降低。

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

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

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

（编辑：阿坝站长网）

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