高并发缓存实践 01

很多技术文章，介绍高并发查询DB（或其它数据源）的解法，中心思想，就是缓存。在服务和DB中间，加一层缓存，大致方案是：

1. 查询全部走缓存；
2. 用一定的策略，构建缓存的key；
3. 实现一种缓存更新的触发策略，例如任务轮训更新或查询时自动触发更新；
4. 设置缓存更新延时，并通过分布式锁，按照设定的延时，控制缓存更新；

问题来了：

缓存延时带来了数据不准，如何缩小缓存更新延时？

问题很简单，但背后有一坨思考：

以tair为例，tair在写入（或更新）时，读取是阻塞的，也就是，一个key，要写入（或更新）完成后，才能读取到值；在高并发下，如果写入间隔太短，那么读取就会有问题；如果写入间隔很长，意味着缓存的更新延时很长，数据就会不准；

并发量太高的时候，单一的key，很容易造成热点，引起tair击穿（限流）；

另外，如果想把缓存更新延时控制到1s以下，也是很难的；因为计算的延时、tair读写延时、网络延时等等，耗时加起来， 可能有几十上百毫秒，会干扰我们设定的缓存更新间隔时间；

带着这这些问题，基于“空间换时间的原理”，我们来设计一套分桶策略，解决缓存延时问题；

 

业务场景

抢票，选座：

1. 用户会在开抢的的瞬间，点击演出场馆图上的看台，获取看台的座位数据，进行选座；
2. QPS可达到1w~2w；
3. 数据源需要通过http方式调用，带宽有限，不容易扩展，并发承受能力有限；

方案：缓存+分桶

1.把一份数据拆成多份进行缓存；目的是取数据的时候，取多份数据中，最新的数据，达到减小缓存延时的目的；
2.用户查询数据，会触发缓存的异步更新，根据调用的key和调用的时间，会命中其中一个分桶，更新该桶的缓存；
3.根据key查询数据，会拿到该key对应的所有分桶数据中，最新的一份数据；
4.理论上，缓存延时=缓存更新时间（1s）/分桶个数（10）=100ms；

Key的构建：
基于看台的id，构建缓存的key；

分桶策略：
将一个key，分成若干个key，根据用户查询的时间戳，对分桶个数取模，作为分桶的key的后缀；