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

上一章节，我们提到了配置文件的管理，其中介绍了本地配置，集中式配置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的变化，
并进行批量的更新
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

---

第二种 本地缓存 + 分布式缓存

这种方案，其实也是redis分布式缓存搭配 localencache 这种方式， 其实就是使用localcache与redis集群多级缓存方案，甚至加入消息队列，但是风险就上来了，运维成本增加了

---

第三种 实时热点自动检测平台

---

对于HotKey我们可以进行埋点操作
将热卖中真实的hotkey以异步的方式存储到日志系统，我们在实时热点自动平台
进行数据的收集与分析，真正做到精确，立即通知交易系统做好保护

---

更多内容，请关注博客