前面已经把用于功能开发的 整体技术架构 基本搭建好了，感觉已经可以落地使用了。
但是，仍然会有很多没有考虑全面的地方，比如缓存和异步消息的架构， 这两个基本上是 目前 做实际应用的标配了，因此在高层架构设计阶段， 同样要对这样通用的、或者是公共的架构进行架构设计。
我们先来聊一聊如何确定缓存架构的话题。
大家都知道，合理使用缓存能大大提升应用的性能，因此设计合理的缓存架构就是架构设计当中一个非常重要的内容了。
一：考虑缓存分级，也就是多级缓存
简单点说，就是把缓存分成很多个层级，基本上是数据从发出开始，经过的所有环节，都有可能做缓存。常见的有：
1：浏览器缓存：前端缓存，这个不多说
2：CDN缓存：这个是花钱买的服务，也不多说
3：负载均衡缓存：
比如Nginx的缓存，可以把一些较少变化的数据，放到Nginx缓存中
也可以在Nginx里面，直接使用插件，去直接访问缓存中的数据，这样就无须调用后面的应用服务。
4：进程内缓存：
对Java而言，就是JVM缓存
5：分布式缓存
比如：使用redis，存放共享的session信息、权限信息等
这里是高层架构设计阶段，主要还是制定整体的架构形式，因此比较粗略，并不会深入具体的业务，也不会去过多的关注具体如何使用缓存的一些细节，比如：具体使用什么数据类型、存储数据的格式等等，那些具体的设计，放到概要设计或者是详细设计阶段再去完成。
二：确定基本的缓存技术方案
这里除了要决策在哪些地方使用缓存，另外要确定下来 具体要使用的缓存框架，比如：使用Redis、ElasticSearch、MongoDB、内存数据库等等。
具体的方案要结合着具体的应用来思考，这里只是举例，不是说每个项目都是这样来做缓存，这一点大家要注意。比如：
对于热点数据，使用Nginx本地缓存
对于使用特别频繁的数据，考虑使用JVM缓存
对于实体类的缓存数据，使用ElasticSearch，特别擅长按条件查找数据
其它缓存数据使用Redis，比如：幂等控制数据，类似于分布式锁，当然这个也可以使用Zookeeper来实现； session共享数据 ；登录控制数据 等等
到这里我们就基本确定下来，缓存的技术方案，要使用几级缓存，大概每一级用什么样的技术去做。
三：需思考的点
实际应用中，需要思考的地方很多，这里讲几个常见的：
1：缓存拆分
就是要思考，是否需要拆分？
比如：用户数据、产品数据、订单数据、登录session等，是放在一个Redis里面，还是需要进行拆分，放到不同的Redis里面去。
这个又涉及很多，要去估算业务量，估算数据量的大小，估计访问Redis的频率，估计读写的比例、并发访问量等等的。
如果拆分，该如何拆分？
通常就是做横向和纵向的拆分，类似于数据库的 分库分表 ，也就是所谓的纬度化缓存。
2：缓存持久化
是否需要持久化？如何持久化？比如对Redis：AOF、RDB
3：集群
是否需要集群？
ElasticSearch是天生支持集群，对于Redis，就要考虑是只采用主从复制，还是真的需要做集群，集群又要考虑是做哨兵集群，还是采用redis cluster来做集群。
以及集群的形式、集群方案、分片键的选择（这个可以放到后面的概要或者详细设计中去）等
4：常见问题：
需要为失败而设计，准备好相应的处理方案
（1）雪崩
其实就是请求缓存的数据在缓存中不存在，这样大量的请求最后都落到了数据库上，从而造成数据库压力大，甚至无法访问的情况。
至于为啥缓存中没有对应的缓存数据，有可能是还没有加载到缓存中来，也有可能是因为缓存过期被清除，或者是缓存节点故障等。
对于这个问题，我们要合理的设计缓存数据的方案，哪些数据放入缓存、什么时候放入缓存、是否过期、什么时候过期、超时时间是多少 等等。
另外：也要准备一些Plan B，比如：
限流：当缓存服务无法支持高并发的时候，可以把无法响应的请求放入到请求队列或者是直接返回。
隔离：当缓存无法提供服务的时候，把请求放入队列中，这样可以实现请求隔离，避免这个请求被路由到其它缓存节点，从而导致其他缓存节点故障。
（2）穿透
缓存一般是 Key，Value 方式存在，一个 Key 对应的 Value 不存在时，请求会回源到数据库。
假如对应的 Value 一直不存在，则会频繁的请求数据库，对数据库造成访问压力。
解决方法：第一种是缓存层缓存空值
将数据库中的空值也缓存到缓存层中，这样查询该空值就不会再访问DB，而是直接在缓存层访问就行。
但是这样有个弊端就是缓存太多空值占用了更多的空间，可以通过给缓存层空值设立一个较短的过期时间来解决，例如60s。
第二种是布隆过滤器
将数据库中所有的查询条件，放入布隆过滤器中，
当一个查询请求过来时，先经过布隆过滤器进行查，如果判断请求查询值存在，则继续查；如果判断请求查询不存在，直接丢弃。
（3）缓存击穿
在数据请求的时候，某一个缓存刚好失效或者正在写入缓存，同时这个缓存数据可能会在这个时间点被超高并发请求，成为“热点”数据。
这就是缓存击穿问题，这个和缓存雪崩的区别在于，这里是针对某一个缓存，前者是针对多个缓存。
解决方案：导致问题的原因是在同一时间读/写缓存，所以只有保证同一时间只有一个线程写，写完成以后，其他的请求再使用缓存就可以了，比较常用的做法是使用 mutex（互斥锁）。
在高层架构设计中，确定缓存架构的话题，就先聊到这里。
至于还有很多其他缓存使用上的一些细节，留到后面概要设计和详细设计阶段再设计，比如：
提高缓存命中率
缓存和数据库双写不一致问题
如何分片
热点问题
如何写缓存
如何更新缓存？增量？全量？
数据如何被移除
过期的策略
数据如何恢复
数据如何迁移
如何预热
如何冷启动
……
如果你觉得本系列文章还不错，能够给你一些启发和思考的话，请关注、点赞、收藏加转发，让更多的朋友加入到我们的行列，谢谢啦！
更多架构师之路干货文章，已在路上，稍后就到！