架构师之路十一分布式系统-高并发下热卖商品的读操作

最新推荐文章于 2024-04-26 20:43:31 发布

技术引领者

最新推荐文章于 2024-04-26 20:43:31 发布

阅读量477

点赞数

分类专栏：经验分享互联网之路文章标签： redis java 缓存

本文链接：https://blog.csdn.net/qq_37022150/article/details/126545121

版权

经验分享同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

互联网之路

5 篇文章 0 订阅

订阅专栏

上一章节，我们提到了配置文件的管理，其中介绍了本地配置，集中式配置2种方式，以及springcloud的配置文件管理，Diamond的配置文件管理，和disconf的配置文件管理，以及zookeeper的配置文件管理，其中以diamond的配置文件管理，搭配其很好的容灾机制，基本可以达到360度无死角去查看配置文件等信息

这一章节，我们重点介绍下高并发下热卖商品的读操作，这里就不得不提及缓存的问题

常规的一级缓存，二级缓存等可以解决部分简单的静态页面资源的问题，但是对于高并发下的热卖商品还得是以下几种方式，这里重点提及的是思路，从架构师的角度去考虑多种方案

第一种分布式缓存

这里以redis缓存为例，缓存，分布式锁，

存储的形式是key-value的形式，支持的数据结构
String, list, hash ,set,zset

redis 集群一共包含 16384个slot, 不同的redis节点维护不同的

slot, 当使用jedis 进行存储的时候，将Key作为路由先进行

CRC16运算, 再mod 16384,以此路由到指定Redis节点的slot区间内

对于集群我们也可以通过HostandPort指定到redis的具体节点

对于分布式缓存，涉及多个key 会改变的方式，我们依然会涉及到
需要解决的方式: 	当热卖商品来临的时候，我们需要对热卖商品设置其Key, 并缓存到n个
节点，其实也就是做了一个冗余的操作，多写多读的方案有潜在的问题
就是数据一致性的问题，解决方式就是引入zookeeper 的wathcher机制，
当watcher监听到znode的变化之后，所有的客户端都会感知znode的变化，
并进行批量的更新