Day268.预约系统添加预约资格业务链路、高流量预约活动热点key读问题解决方案、RedisCluster架构对写用户资格缓存对应情况、高流量下预约人数热点key更新 -Redis的高并发预约抢购
一、预约系统添加预约资格的业务链路
1、添加预约资格的业务链路
添加预约资格涉及到的缓存数据有哪些，但是对添加预约资格的整体业务链条，可能需要学习，如↓下图：
看到肉色箭头代表读操作，红色代表写操作，user集群要面对比较多的写操作，SKU集群只有一个读一个写
二、高流量预约活动热点key读问题解决方案
1、通过一主多从+CDN+静态化模版技术
之前的内容，预约SKU的redis集群最终采用的是一主多从的redis架构并且由于CDN的增设让绝大部分关于预约的商品信息部分可以通过静态化模板技术，直接呈现给用户，那么唯一受用户行为的影响并且要展现给用户的数据就是预约人数了。
那下面，一主多从的架构下对于高并发的读操作是否能扛得住？。如图↓所示：
可看到如果单论读预约人数，主从架构是完全扛得住的slave，让master专注于承担写数据，和少量的分发工作即可，因为slave与slave之间可以进行数据同步，但要注意的是redis主从架构下不是实时同步的，也就是最终一致性。
三、RedisCluster架构对写用户资格缓存的应对情况
1、应对情况
由于每个用户的用户Id都是唯一的，那么针对用户相关的数据读写操作都是非常容易最大限度的利用集群里的机器资源，做到较为平均的分配如图↓所示：
可以看到 根据用户id来做hash分发 是非常容易的保持原先rediscluster架构是完全可以胜任的。至于rediscluster的slave机器因为只能是一个单纯的备份所以没有画出。
2、维护用户的预约场次列表应对情况
只要是单纯的分发用户的请求都是非常容易的，哪怕是牵扯到数据库实际上每台机器的压力也不会很大。
四、高流量下进行预约人数热点key更新
1、预约系统关于SKU的写缓存操作影响因素
之前我们知道对于单个SKU的读操作，主要是在预约活动的状态和预约人数上。
至于商品信息，完全可以通过页面静态化技术让用户直接访问到，并不会给机器带来什么压力。
预约活动的状态：
是受当前时间与当前商品预约人数有关的，与用户的行为没有直接的关系。
预约的状态是根据预约人数来调整的，那么就只有预约人数的统计会直接受用户本身的影响，也就是说用户再点击预约按钮的时候会进行一个预约人数递增的写操作，既然是写操作，哪怕发生在redis中，如果数百万的用户同时点击预约操作，让一台redis去扛怎么高的并发，也是非常不靠谱的。
那么在一主多从的SKU redis集群架构下又该怎么办呢？
2、统计预约人数实时性&数据绝对精确的必要性
既然SKU的redis集群写缓存永远会受到单机瓶颈的限制.
那么只能对写操作一下限流并且同时也要保证数据尽可能地准确性。
那么此时就要思考根据业务场景去制定写缓存的 限流方案 ，因为脱离业务的架构设计就是耍流氓。
那么首先思考一下预约统计人数对买家和卖家的意义了：
-
买家：
既然是预约，就是让
买家了解预约的参与人数，本质就是预约统计对用户的最大意义就是通过一串数字激发起用户的购买欲，让其加入到购买大军之中，数据有一点看到的数据有一点偏差从业务的角度来说是完全可以接受的。也就是说当一个买家点击预约按钮的时候，刚一点击就立马进行累加，意义并没有那么大，既然意义不是很大，就没必要让机器承受那么大的负载，同时为了保证意义不大的时效性，也给不少的人带来很不好的用户体验。
-
卖家：
卖家只是通过预约的人数，对之后的发展战略进行调整，所以数据
时效性，甚至数据少量的丢失都是可以容忍的。
3、应对方案
（1）既然时效性要求不高，那我们在每一台预约服务器定义一个本地变量作为本地缓存，由它来负责累加请求，每隔一段时间将这些累加数据一次性的，与redis中的预约人数相加 如图↓所示：
（2）既然是每隔一段时间将数据刷入redis,那么自然就需要一个定时任务,并更新本地缓存。
因为涉及到缓存的自动过期与刷新本地缓存为了方便起见，我即将要引入一个缓存框架JetCache。
4、JetCache简介
JetCache 是阿里巴巴开源的一款功能极为丰富的缓存框架比我们常用的springCache支持更多丰富的功能。
例如：可以原生的支持TTL、两级缓存、分布式自动刷新，还提供了Cache接口用于手工缓存操作,以及方便整合现在市面主流的本地缓存框架。
它的功能，如图↓：
有了它之后就可以非常轻松的实现累加器统计的数据与redis数据进行累加并更新到本地缓存，代码示例大致如图↓：
策略设置
将本地的计数器的数据同步给redis并且刷新了本地缓存，每10秒一次刷新。留意一下红框部分那个设置还是比较重要的，那个是防止缓存穿透的问题，如图↓的这种情况
启用了该参数之后，如果本地缓存失效，有多个请求同时打到机器上，也只有一个请求可以去redis刷新缓存，其它的请求就会有短暂的阻塞，之后当本地缓存有了数据之后，其余的请求就可以直接从内存加载数据了。
场景大致如图↓所示：
5、JetCache源码
1、源码内容
从方法名字就可以看出来是同步加载数据的意思，如图7所示：
从图中我们可以看到 当一个线程要执行数据加载逻辑时，有可能会获取一个针对这个加载方法的锁对象，当用户顺利创建之后就会去执行这个加载逻辑，执行完成之后再把锁对象移除，并通过countDown方法唤醒阻塞线程。那么没获取到锁对象的加载数据请求会怎么样呢？如图↓所示：
这就一目了然了，没获取到锁的请求，直接阻塞，当唤醒之后判断缓存是否加载成功，此时直接把加载到的值返回就行了。
是不是有一种如释重负的感觉呢？接下来我带着大家再来看看定时刷新的相关源码，如图↓所示：
可以看到，这是我们设置定时刷新的地方，接着我们根据refreshMillis这个变量名发动，连懵带猜的传统艺能找一找，哪里会有定时刷新的执行方法 如图↓：
找到这个方法看名字就比较靠谱了，然后映入眼帘的是一个定时调度线程池，和一个刷新任务，我们想都不要想，点进RefreshTask找一找run方法，如图↓所示：
大家看过jetCache的文档就知道，它支持本地和远程的多级缓存同时操作，那么很明显，此时我们操作的是本地缓存，自然走else逻辑了，如图↓所示：
直接调用我们传入的加载逻辑取得数据，之后就直接放入缓存组件了。
5、总结
梳理现在的添加预约的黄金·链路，如图↓所示：
