简历优化的好伙伴 - 高并发读

大家好，我是爱吃芝士的土豆倪，今天想给大家分享的是 - 简历优化的好伙伴 - 高并发读。

近期马上就要到一年一度的秋招季了，我看b站留言上很多小伙伴都在留言up主能不能出一些简历优化方面相关的视频，这方面的内容我之前做过一些，但是讲的很大很空，没有一些深入的例子来说明一些问题，因此我接下来相出的一些视频都是尽可能讲一些实际的问题，当然这个前提是我能够找到一些具体的例子。

那么话不多说，就让我们开始吧。

现在我们假设，存在一个优惠券服务，可以理解为上层存在很多服务都会调用它，包括红包雨、直播间、抽奖平台、玩法平台、任务平台、小黄车、商品详情页、店铺页，为这些业务场景赋能，可以说是对稳定性要求非常高的系统了。

那么我们简单想一下，就会涉及到两个情况嘛对吧，一个是领劵，一个是发劵，当然还有别的，在这里我们不多说了，只聊这两个。

由于我们前面说了，很多服务调用我们优惠卷系统，那么也就意味着发劵 和 领劵会有很高的流量。

那么高并发问题也就由生而来。

针对对优惠卷的分析，我们的高并发问题就细分成两种呗。

读qps高: 简单来说就是查的很多，查优惠卷的信息

写qps高：主要就是优惠卷的库存的扣减了。

我们这期主要讲的是高并发读。

主要是分为四个方面：

第一，内存缓存，你海量的查，要么走db，要么走redis，还可以走本地缓存，这个适用于流量很高的情况，刚好适用于一些不常变化的，如优惠卷信息，可以有效地保护好下游的服务，但是需要注意的是，使用了本地缓存，也就代表着要提前考虑数据一致性的问题，毕竟这个没考虑好还比较致命。

第二，冗余写，随机读，如果不想采用本地缓存的方式，那么可以考虑下这个方案，具体就是数据写入缓存的时候，分为n份，读取的时候随机选择一个key进行查询，从而实现流量分流的目的。但是这个方案也放大了写流量，之前只需要写一份对吧，现在写多份，所以这个具体的冗余数量需要根据实际情况进行均衡。

第三，redis分片，如果某种场景下需要对key里面的value进行遍历呢？如果量级太大，那么就会有大key的问题，因此可以根据某个值进行hash分片，这样既可以控制对应的key的大小，还能尽可能的使得查询流量平衡。但是可能会有极端情况，就是倾斜的问题，所以这个也需要讨论代价。

第四，内存过滤，某些场景下，要高效的判断是否在这个集合中，比如说实际场景中某个功能只对少部分用户开放，功能入口的查询流量很高，因此就可以使用布隆过滤器去过滤无效的请求，虽然布隆过滤器不能做到百分百，但是漏过去的流量不足以打垮底层系统。但是也存在一定的问题，就是构建布隆过滤器的数据不一定是实时全量的，因此可以设置定时器或者钩子函数，定时的重新构建布隆过滤器。

以上就是整理的一些常见的高并发读的实际问题。我们可以将其结合进我们自己的项目中。

最后我想说的是，任何一种优化，可能都会带来一定的代价，需要自己权衡利弊后才可以改造，以上就是我的分享了，我是爱吃芝士的土豆倪，谢谢大家收看。