巧用 HTTP 协议，设计一个基 于B/S 架构的缓存框架！

程序员的成长之路

互联网/程序员/技术/资料共享 

关注

阅读本文大概需要 11 分钟。

来自：https://blog.csdn.net/qq_34347620/article/details/127762617

1. 基于B/S架构的HTTP协议三级缓存设计

1.1. 骚话连篇

程序设计无非就是和，但是现在本质已经变了现在的软件工程师已经不在乎软件质量以及代码质量，以增加的来解决并发问题，软件变成变成了PPT编程。

其实大家都知道很多缓存方案 Redis读写缓存呀，MongoDB文档缓存呀，网页静态化呀，，其实玩来玩去也就那样子这么多年了也没有什么创新的点子出现。既然大家都知道缓存方案为啥我还要专门写一篇文章去解释这个缓存方案设计哪，主要原因就是因为我没有找到这个方案的轮子，我是真的没有轮子，Spring和其他Java社区都没有提供。

难道服务端就不能去控制缓存嘛在思考这个问题，服务端控制代理服务器和浏览器的缓存，并且做好缓存协商和缓存过期，利用好http缓存可以极大的减小服务端压力，无论是网络传输还是servlet容器对http的解析。

秉承着百度和Google都不能解决解决你的问题甚至没有答案，那么恭喜你了，你要自己去解决问题并且发布解决方案了，所以我要造轮子以及写博客了。

1.2. 设计初衷

HTTP协议作为B/S架构最通用的协议，但是大家都没有很好的利用HTTP协议。（中国开发工程师就那点水平吧，纸上谈兵之士，我也是纸上谈兵，哈哈哈）

提升网站并发首先就是要缩短距离和减小体积以加快响应（我称之为“短小快”）

HTTP协议的缓存策略可以缩短网页请求资源的距离，减少延迟，节省网络流量，并且由于缓存文件可以重复利用，降低网络负荷，加快客户端响应。

其实一个高并发网站的流量95%都是，甚至都达不到5%，Java工程师引用Redis将大量数据放入Redis来解决其实是错误甚至是致命的，在重后端轻前端的软件开发环境下大家都是优先从后端入手去解决很少从网络传输协议入手去解决问题。运维工程师对于HTT议缓存也仅仅是Nginx对静态资源设置一个。

其实运维工程师也很难判断缓存什么时候过期，过期时间设置多大，毕竟谁知道后端工程师什么时候更新数据呐。（这里就没有前端什么事情了，浏览器都已经维护好HTTP缓存了）

1.3. 解决思路

哼，感觉Spring对HTTP协议支持太少了（有点郁闷），以至于我觉得他们是不是故意不开源部分代码用于商业支持。

以后端方式来控制HTTP缓存（当然不是后端返回数据加一个），后端来决定HTTP缓存的时间，其中涉及到 HTTP协议缓存失效机制、反向代理缓存、后端缓存控制。

HTTP协议大家很熟悉吧，废话少说写文章打字很累，直接上链接吧

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

• https://web.dev/i18n/en/http-cache/

这两篇文章看完大概心里对HTTP缓存就心里有数了，其目的是尽可能的把数据缓存在浏览器中减少网络请求（用户的电脑性能不会那么拉胯的啦）。

画个时序图来看看吧

+的模式再也不存在了，现在只有一层，因为消除了Spring Cloud Gateway的存在 性能上略有提升，性能上面大概会提升2%-8%吧。

尽量不要让网关 去和业务扯上关系，让网关做好反向代理和负载均衡将可 （Spring Cloud Gateway上面一大堆业务，能不慢嘛）

别小看这种小小的性能提升，失之毫厘差之千里，流量上来了效果就不一样了。

2.2. 数据之小

上面已经把网关的距离缩短了，如何让数据变得小一点。

其实从架构较多来说，JSON和XML这些传统的通讯格式很通用，换成其他的Kryo，dubbo这些之类的也只是适合服务和服务之间传递，并不适合前后端之间交互，就是JSON解析框架从Jackson换成了FastJSON（温少出了）也只是从在解析速度上的提升

后前端其实没有多少可以说的，HTTP协议很通用，JSON通讯格式也方便解析稍微主意一下几个问题就好了

1. 后端不需要把null值给前端，前端仔自行处理undefined，null，NaN的问题

2. 后端仔别一股脑  返回全部数据了，和前端确定好字段后定制化的返回所需要的字段

3. JSON的key其实压缩一下，apple可以用a替代，user这个可以用u来替代，这些注解之类的压缩一下key

4. 数据库字段尽可能使用小字段，少用宽表

微服务，微服务嘛看PRC框架了，或者dubbo这些都有自己的压缩算法的

Spring Boot其实有gzip的开关，可以考虑开起来压缩一下，但是开启后CPU会上来，没有办法问题。

TCP协议有三次握手能快到那里呐，UDP可靠性问题也是一个很大的问题，其实有打算使用http2.0的，但是http2.0似乎只是提升了client的性能没有提升server性能， 还不如用http缓存方案来解决这个问题好一点。

http缓存上面介绍过了，各个节点之间的缓存做好缓存和缓存协商接本上就能解决这些个问题了。

呃呃呃， 上面都是没有营养的东西，写偏题了（理科生啦没有办法就是文笔差劲）

来看看如何让数据在变的小一点吧

那么网关升级一下吧。

当然上面是对API进行优化当然还有一个大杀器，那就是网页，这个没有专门研究过，针对app和小程序无效只能用在web网页上面。

2.4. 性能之悍

物理计算机性能如何强悍，其实没有没有以上的短小精悍都不可能做到真正的强悍的。为什么想要强悍在设计及编码之时必须抠门，是的抠门。

做过一个很有趣的功能，Java对300M的csv文件进行关键字检索，开发环境硬件是 MacMini2018顶配，生产环境是 2C8G的服务器， 开发环境各种测试都没有问题，但是到了生成环境性能未达标，差了20%。

硬盘IO，CPU频率，内存带宽等等因素造成性能未达标，在无法改变硬件的情况下，只能在low逼硬件上面进行设计，经过多天的设计终于弥补那20%，可以在low逼硬件上面性能达标。把数据和程序放在开发环境上面运行性能居然提升了50%。

用最拉胯的硬件写出高性能的软件，这才是性能强悍。

2.5. 短板效应

软件开发的性能问题永远是短板效应，IO阻塞，cpu线程竞争，网卡带宽等等，性能取决于最low的那个，但是为什么现在硬件如此强度的情况下为什么还是不能提升性能呐，这是一个很有趣的问题。

短板效应渐渐的不是出现在硬件上面了，而是代码，短板效应居然是代码，其次是架构。再优秀的架构都抵不垃圾代码带来的性能损耗。

不注重代码管理的何须谈性能呐，

3. 手撕http缓存框架

感觉说没有意思，框架请自取，目前没有发布到中央仓库，应该会等到22年6月7日发布吧

项目源码：

https://github.com/galaxy-sea/heifer/tree/main/heifer/heifer-common/heifer-common-http

http-example：

https://github.com/galaxy-sea/heifer/tree/main/heifer/heifer-examples/heifer-common-http-example

在线预览，开启F12， 注意看

 会在  上返回  和 

主要用于刷新标签

呃呃呃，懒得写了，要去修复http模块的bug了，还有好多功能和配置没有加上去呐。

考虑要不要把模块独立出来，作为一个单独的项目发展呐

4. 终章

鲁迅曾经说过 “艺术源于灵感”，高潮既是终章也是很不错的，美剧《Godless Season》男主角最后离开西部一样的风格也是很不错的。

推荐阅读：

支付系统就该这么设计（万能通用），稳的一批！

简单几步，快速实现封装多级树结构对象（Java版）

文章知识点与官方知识档案匹配，可进一步学习相关知识网络技能树支撑应用程序的协议HTTP协议22055 人正在系统学习中

来源：程序员的成长之路