主要流程为：

1）请求先达到Nginx，先读取Nginx本地缓存，如果命中缓存则返回缓存数据。这里的负载均衡路由策略，采用轮询的方式相对而言访问压力分布的更加均衡，一致性哈希方式能够提升缓存命中率，但是同时也会存在单点压力过大的问题，可以考虑使用一致性哈希策略时流量达到一定阈值的时候切换成轮询的方式；

2）如果没有命中Nginx缓存，则读取分布式缓存，为了高可用以及提升系统吞吐量，一般远程分布式缓存会采用主从结构，这里读取的就是从缓存服务集群数据，如果命中缓存则返回数据；

3）如果从缓存没有命中缓存，则读取应用本地缓存（堆内/堆外缓存），这里的路由策略同样可以采用轮询或者一致性哈希。如果命中，则返回数据，并回写到Nginx缓存中；为避免由于从缓存服务出现问题，造成过大的流量冲垮数据库，这里可以尝试读取主缓存服务；

4）如果所有缓存没有命中，则查询数据库并返回数据，并异步回写到主缓存以及应用本地缓存中。主缓存通过主从同步机制同步到从缓存服务集群中。这里会写到主缓存的时候需要考虑多个应用实例在异步写，需要考虑数据是否会乱序的问题。

另外，对于一些非预期热点数据比如微博中”某某明星结婚“等等热门话题带来的访问流量瞬间冲击到后端，针对以上多级缓存设计，可以通过引入热点发现系统来发现非预期的热点数据，利用flume订阅Nginx日志，然后通过消息进行消费，最后通过storm等实时计算框架进行热点数据的统计，当监控发现到热点数据，将其推送到各个缓存节点上，整体的缓存设计如下：

8. 总结

为了追求高性能，每个开发者最先使用的就是缓存，也在潜意识里将缓存作为了系统性能瓶颈的一剂良药，经过系统化的总结和分析缓存后，就可以发现缓存如果使用不当真的就会事与愿违，成为毒药，并不会系统迭代出那个局部最优解。如果贸然的使用缓存，需要考虑的地方真的很多稍有不注意，反而会让系统投入更多的维护成本，陡增更高的复杂度。那是不是就不使用缓存呢？也不是，缓存在高并发的情况下通过IO高速的缓存获取数据能使得每个请求能够快速响应，并且能够大大提升系统吞吐量以及支撑更高的并发用户数，在现有的高并发大流量的互联网应用中应用缓存的例子太多了，也足以证明缓存在优化系统整体性能是一种行之有效的方案。

作为开发者不是每个人都有机会和机遇去挑战高并发的互联网架构以及高量级的访问流量和应用规模的，那是不是就意味着这些通用的技术方案就不用深刻分析呢？很显然不是，单从缓存使用中就会发现在高并发下读写带来的数据不一致性分析下来就会有很多并发场景，单线程下都是正常的，但在并发下就会出现很多意想不到的case，而这些分析的思路是最核心的，也是开发者逐渐形成自己的方法论的有效训练途径。在系统化学习每一种技术组件时，业界的通用解决方案都是经过历史经验慢慢沉淀下来的智慧，如同品酒，是需要静下心来好好去品的。

技术最终是服务于业务价值，而业务规模扩张会反哺技术的创新，要设计出一套适应于业务的合理的技术方案，需要很深的内功，需要既懂技术又要对业务理解十分深刻才行，懂业务而不懂技术，很难知道每种技术方案的局限性，也就是经常所说的PPT架构师，PPT很炫酷，一顿操作猛如虎但是并不是最适合业务的那个解，反而就像是跳梁小丑一样自嗨或者带着功利心去急于变现，只有业务与技术结合能够得到最大价值的那个解就是最合适的方案，需要在优与劣的trade-off上做出权衡。如果很懂技术，但是不懂业务，同样的就是废铜烂铁没办法发挥出功力。在不同的职业生涯阶段，每个人的精力有限，投入技术以及业务的精力分配也是不同的，专注的点会有所不同，就像业务与技术一样，在人生的赛道中在不同阶段也需要迭代出那个最合适的局部最优解，至于什么最合适，答案在每个人心中！

作者：科怀

本文为云栖社区原创内容，未经允许不得转载。