(完整word版)互联网高并发架构设计
高并发架构设计
高并发架构设计随着互联网的快速发展，越来越多的网站和应用面临着高并发的问题。
高并发指的是在短时间内同时有大量用户访问一个网站或应用程序，这样就会给网站或应用程序带来很大的压力，甚至导致它们崩溃。
因此，如何设计出高并发的架构成为了现代网站和应用程序开发的重要问题之一。
一、什么是高并发架构设计？高并发架构设计是指在分布式环境下，通过合理的架构设计，能够尽可能地利用系统硬件资源，使得系统能够在高并发的情况下运行稳定，满足客户端的请求。
高并发架构主要包括三个方面：高性能、高可用和高扩展性。
二、高并发架构设计的挑战在高并发的情况下，网站或应用程序会遇到很多挑战。
其中包括以下几个方面：（一）高并发访问当有大量用户同时访问网站或应用程序时，服务器的负载会变得非常高。
这时候服务器的响应速度会变得非常缓慢，或者直接崩溃。
（二）高数据量访问高并发会带来大量的数据写入和读取操作。
这就需要正确地处理数据库操作，避免死锁和数据被覆盖的问题。
（三）高安全性要求高并发情况下，网站或应用程序会遇到大量的网络攻击。
为了保护系统的安全，需要正确的安全策略和防御机制，保证系统不被恶意攻击。
（四）高可用性要求高并发情况下，系统要保证稳定运行，避免因为某个节点的故障导致整个系统崩溃。
要实现高可用性，需要为系统配置正确的冗余和备份机制。
（五）高扩展性要求高并发下，网站或应用程序需要快速扩展系统资源，以应对大量的请求。
扩展性是高并发架构设计的关键技术，要充分考虑横向扩展和纵向扩展的策略。
三、高并发架构设计策略为了面对高并发访问的挑战，需要采用一些有效的架构策略。
以下是一些常见的策略：（一）多层架构多层架构是一种模块化的架构方式，它将整个系统拆分成多个模块，每个模块处理一个具体的功能，这样能有效地降低代码的耦合度，并且对代码的扩展和维护也有很好的支持。
常见的多层架构包括MVC、MVP和MVVM等模式。
（二）负载均衡负载均衡是指在服务器集群中，将请求分配给多个服务器来处理，以达到平衡系统负载的一种技术。
高并发设计模式
⾼并发设计模式
互联⽹⾼并发架构的8种设计模式：
1、单库单应⽤模式
这种是最简单的模式，即⼀个数据⼀个应⽤服务器，⼀般在产品发布初期使⽤会⽐较⽅便，单⽇30万到50万PV以下⼀般没有问题。
2、内容分发模式
在主机中使⽤了静态⽂件缓存之后，还可以使⽤CDN的⽅式把静态⽂件分发到离⽤户最近的节点上以达到快速响应的⽬的，⼀般在百万级别的PV时需要使⽤
3、查询分离模式
主要是指数据库的读写分离，能够降低响应延时，在千万级别的PV时会使⽤。
4、微服务模式
微服务就是把⼀个单应⽤拆分成多个服务，每个服务部署在各⾃的主机中，最后通过⼀个ESB来管理和调度这些服务，优点是各司其职不会出现混乱和⼀致性瘫痪，缺点也很明显，就是集成测试和协同发布难度⼤增。
5、分库分表模式
当⼀个表的数据出现上亿级别的时候就要考虑分表了，⽐如订单数据等，根据⽤户的属性或者时间来拆分成多个表存储，甚⾄是拆分成多个库存储。
6、多级缓存模式
可以把数据缓存到redis、memcache或者分布式⽂件系统之中，⼀般是在500万PV之上需要使⽤。
7、弹性伸缩模式
当应⽤容易出现波峰波⾕的情况时使⽤弹性伸缩模式可以有效降低硬件资源的成本，特别是在使⽤公有云的时候这个成本的下降积累会是⼀个⽐较⼤的值。
8、多机房模式
如果是⾃建机房可以在南北⽅各地安置机房以达到有效降低延迟，以及防⽌同时宕机的可能性出现。
如果是使⽤公有云可以采⽤多个节点部署。
另外⼀⽅⾯，采⽤CDN的也是多机房的⼀种实际应⽤。
以上就是在互联⽹⾼并发情况下可能采⽤的⼏种架构策略。
高并发架构方案
高并发架构方案摘要:高并发架构方案是当今互联网行业中常遇到的一个挑战。
随着用户对网站和应用程序的需求不断增长，传统的单机架构已经无法满足高并发访问的需求。
本文将介绍一些常见的高并发架构方案，帮助开发者设计和搭建符合高并发需求的系统。
一、背景随着平台用户数量的增长和访问量的提升，传统的单机架构面临着访问并发量过大、性能下降、数据存储和处理能力不足等问题。
为了解决这些问题，我们需要设计和搭建高并发架构方案。
二、高并发架构的基本原则1.水平扩展水平扩展是实现高并发的关键。
通过增加服务器的数量，实现负载均衡，将访问请求分散到多个服务器上，从而提高系统整体的并发处理能力。
2.缓存技术合理使用缓存技术可以大大提升系统的性能。
将常用的数据和计算结果保存在缓存中，减少服务器对数据库的频繁访问，提高响应速度。
3.异步处理对于一些耗时的操作，可以将其放到消息队列中进行异步处理。
比如发送邮件、生成报表等操作，可以通过消息队列将请求发送到后台进行处理，提高并发处理能力。
4.数据库读写分离将数据库进行读写分离，主库负责写操作，从库负责读操作。
通过这种方式，可以提高数据库的访问性能，增加系统的并发能力。
5.负载均衡负载均衡可以将访问请求分发到多个服务器上，提高系统的整体并发处理能力。
常见的负载均衡技术有DNS负载均衡、反向代理负载均衡和应用层负载均衡。
6.分布式文件系统对于大文件的存储和传输，可以使用分布式文件系统进行处理。
分布式文件系统将文件切分为多个块进行存储，并提供高可用性和高并发的访问能力。
三、常见的高并发架构方案1.分布式架构分布式架构是一种将系统拆分为多个服务节点的架构方式。
每个服务节点负责处理客户端的部分请求，通过负载均衡将请求分配到不同的节点。
这样可以提高系统的并发处理能力，同时增加系统的可扩展性和容错性。
2.微服务架构微服务架构是一种将系统拆分为多个小而独立的服务的架构方式。
每个微服务负责处理特定的功能模块，通过接口通信，实现松耦合。
前台门户网站高并发架构设计方案
前台网站架构设计方案2015-6目录1设计思路 (1)2系统架构设计 (3)2.1网站总体架构 (3)2.1.1网站的系统架构 (3)2.1.2网站的软件架构 (5)2.1.3网络拓扑结构 (6)2.2负载均衡 (7)2.2.1通过硬件实现负载均衡 (7)2.2.2通过软件四层交换实现负载均衡 (7)2.2.3通过反向代理服务器实现负载均衡 (7)2.2.4Apache +tomcat集群实现负载均衡。
(10)2.3缓存 (11)2.3.1系统架构方面的缓存 (11)2.3.2应用程序方面的缓存 (12)2.4页面静态化 (13)2.5数据库集群及表库散列 (14)2.5.1数据库集群 (14)2.5.2数据库及表的散列 (14)2.6文件存储 (14)2.6.1文件共享 (14)2.6.2文件的多服务器自动同步 (15)2.6.3图片服务器分离 (15)2.7镜像 (15)2.8WEB应用架构设计思路 (15)2.8.1MVC架构示意 (16)2.8.2Struts架构 (17)3性能测试 (18)3.1测试环境 (18)3.2测试项目 (20)3.2.1测试点 (20)3.2.2测试结果要求 (20)3.3测试结果 (20)3.4结果分析 (21)1 设计思路为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计:1)实现web请求的网络负载均衡的设计思路a)通过硬件实现负载均衡。
b)通过第三方软件来实现负载均衡,同时实现页面请求的缓存。
c)通过web服务器的配置来实现负载均衡即通过apache将客户请求均衡的分给tomcat1,tomcat2....去处理。
2)WEB应用架构设计思路a)应用开发实现MVC架构三层架构进行web应用开发b)采用第三方开源的CMS系统来实现网站内容的管理。
c)页面尽可能静态化以减少动态数据访问。
d)采用页面缓存机制和数据缓存来实现页面请求的缓冲和数据的缓存3)数据存储的设计思想a)数据库拆分,把生产数据库和查询数据库分离，对生产数据库采用RAC实现数据库的集群。
高并发下的网站架构
何崚:曾先后就职于中科院下属的两家基因研究所，从事基因组测序中的算法设计和高性能运算。
2006年加入阿里巴巴B2B，此后一直就职于阿里巴巴中国站，最近在关注性能优化和服务化相关领域。
业余除了JAVA开发外，还对游戏开发和三维动画制作兴趣浓厚。
精彩文字内容（请各位下载PPT，结合PPT看文字）何崚：我做一个自我介绍，我叫何崚，来自中国网站技术部网站架构组，主要负责中文站架构设计，性能优化的话是我日常工作中非常重要的部分，所以我今天跟大家探讨一下这个问题。
很多同学对网站性能状况不是很了解，我讲一下基本现状，我们中国站的网站正常流量情况，现在主要的服务器，单台并发，高峰期的时候不会超过10，吞吐量在高峰期也就是10：00-11：00点钟，每一台服务器单台CPU使用率，一般只占1颗核，平均60%左右，服务器平均响应时间在高峰期一般也不会超过150毫秒，图片每天总流量带宽，就是各个网站总和不会超过1.8G。
但是在特定情况下，比如说运营推广的时候，会遇到一个高并发的情况，所谓高并发，就是很多用户在同一个时间点访问我们网站，这个时候看什么问题，首先第一个，如果这么多用户同时访问网站，那么我们的网络带宽可能在一个瞬间内耗尽，服务器Load迅速飙高，一般情况下不会超过2，推广时期经常出现几十甚至上百的现象，这样基本上就停止响应了。
高并发症德士古，比如说是旺旺弹出，过去运营在旺旺引入一个大的图片，有一兆，旺旺在瞬间弹出来以后，那1兆大图片导致带宽耗尽，那我们现在增加审核机制，运营推广增加的图片流量不能超过现有流量的30%。
我们找一些合作媒体推广，比如迅雷、暴风影音浮出广告，导致旺铺集群Crash，另外是秒杀，像开业88小时不间断秒杀活动。
（第三张PPT）这个是非常典型的高并发的情况，这是我们自己对自己的一个DEOS的攻击，我们看这三张图，反映了一个高并发对网站性能的影响，左上角是并发数对吞吐量的影响，大家看到在并发数比较小的情况下面，吞吐量是缓慢上升，但是到了其中一个点，大概120左右，这个点就是一个拐点，过了这个点以后，吞吐量迅速下降，非常快，所以我们性能优化一个很重大责任就是把拐点尽量往后推。
大型高并发高负载网站的系统架构
说说大型高并发高负载网站的系统架构(转载)摘要：一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了。
随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。
前言鄙人先后在CERNET做过拨号接入，在Yahoo&3721搞过搜索前端，在猫扑处理过的架构升级，在 视频网站从事开发工作，还在多年的工作中接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，希望和大家一起探讨。
一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。
大型网站，比如门户网站。
在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。
但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。
上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。
1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。
高并发网站架构设计（转）
⾼并发⽹站架构设计（转）所谓⾼并发，指的是同⼀时间可以处理⼤量的WEB请求，这个指标⽤来衡量⼀个架构的体量和性能。
这⾥的⼤量如何评估呢？1000算不算？10000算不算？对于中⼩型的站点来说，可能并发100多就很不错了，但对于像淘宝这样的⼤型站点，单凭⼀个接⼝调⽤的量就有可能达到百万的并发。
在双11这样的⼤型活动场景⾥，淘宝的并发请求数都能达到上亿次，这样的体量⽆论是在国内还是在国际都是排在前列的。
⽽本章节要讲述的内容是如何设计⼀个可以承载巨量并发请求的架构。
要想设计⼀个⾼并发的架构，⾸先要搞清楚架构的分层，因为每⼀个层⾯都有可能造成影响⾼并发的瓶颈点。
找到瓶颈点后，只要把瓶颈点解除，⾃然会提升整个架构的并发处理能⼒。
我们先来看⼀个综合分层的架构图：1. CDN对于⼤型⽹站来说增加CDN这⼀层是⾮常有必要的，CDN（Content Delivery Network，内容分发⽹络），它属于⽹络范畴的⼀个技术，它依靠部署在各个区域的边缘服务器，实现负载均衡、内容分发调度等功能。
它使得⽤户就近获取内容，降低⽹络堵塞，提供⽤户访问响应速度。
来举⼀个通俗点的例⼦：⼩明公司做了了⼀个针对全国⽤户的业务，服务器放在了北京，但是深圳⽤户在访问⽹站的时候⾮常卡顿，有时候甚⾄访问不到。
经排查，造成该问题的原因是深圳⽤户所在⽹络到北京的机房延迟⾮常⼤。
⼩明想到了⼀个办法，他在深圳的某机房假设了⼀台服务器，把北京服务器上的⽂件传输到深圳的服务器上，当深圳⽤户访问⽹站时，让该⽤户直接去访问深圳的服务器，⽽不是访问北京的服务器。
同理，其他城市也效仿深圳假设了类似的服务器，这样全国各地的⽤户访问公司业务都很顺畅了。
例⼦中的解决⽅案其实就是CDN实现原理，当然，真正的CDN技术要复杂得多，要考虑很多问题，⽐如边缘服务器的分布、机房的⽹络、带宽、服务器的存储、智能DNS解析、边缘服务器到真实服务器之间的⽹络优化、静态和动态资源的区分、缓存的优化、压缩、SSL等等问题。
高并发下的网站架构
万能出错页面：秒杀活动已经结束
任何出错都302跳转到此页面 位于另外集群
万幸：最终所有的预案都没有用上
秒杀活动结果
88小时秒杀，坚守阵地，大获成功 秒杀还是被秒杀？终于有了答案 三道阀门设计非常有效，拦住了秒杀器
静态集群总并发情况 （首页，秒杀列表，秒杀商品页面）
交易系统集群总并发情况 （下单页面）
高并发对网站性能的影响
并发数对吞吐量的影响
并发数对服务器平均请求响应时间的影响
并发数对用户平均请求等待时间的影响
高并发实例：开业秒杀活动
商业需求
为庆祝开业退出88小时不间断秒杀活动 每小时整点推出8款商品，拖拉机，牛，马桶，沙发…… 每款商品供168件，每人限批3件，成交人数56人 CCTV黄金广告时间，各种网络,平面媒体轰炸，总广告费：1.5亿 接到运营通知，距秒杀开始仅仅 5 天时间
秒杀商品列表/秒杀商品介绍页面，如何判断秒杀开始否
答案： valid-offer.js
三道阀门的设计
阀门：基于TT的计数器
序号 1 2 3 阀门上限
限制进入秒杀页面 ，1000 限制进入下单页面 ，100 100 限制进入支付宝系统，56
秒杀器的预防
秒杀Detail页面
URL：随机 秒杀前2秒放出,脚本生成，秒杀前 1000次访问上限控制【每件商品只能放入1000人浏览】
CDN准备：Chinacache沟通；借用Taobao CDN
秒杀系统：架构目标
1.图片网络带宽：1.0G
新增图片带宽：必须控制在 1.0G 左右 每件商品秒杀页面的图片总大小不得超过： 1000000/(1000*8) = 125K/每商品
2.网站并发：
单件商品并发：1000 【来自运营的预估】 总并发: 8（件商品）X 1000（人/商品）=8000
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
前言
高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。
为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。
在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。
服务器架构
业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。
服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。
大致需要用到的服务器架构如下：
•服务器
o均衡负载(如：nginx，阿里云SLB)
o资源监控
o分布式
•数据库
o主从分离，集群
o DBA 表优化，索引优化，等
o分布式
•nosql
o redis
▪主从分离，集群
o mongodb
▪主从分离，集群
o memcache
▪主从分离，集群
•cdn
o html
o css
o js
o image
高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。
测试高并发可以使用第三方服务器或者自己测试服务器，利用测试工具进行并发请求测试，分析测试数据得到可以支撑并发数量的评估，这个可以作为一个预警参考，俗话说知己自彼百战不殆。
第三方服务:
•阿里云性能测试
并发测试工具：
•Apache JMeter
•Visual Studio性能负载测试
•Microsoft Web Application Stress Tool
实战方案
通用方案
日用户流量大，但是比较分散，偶尔会有用户高聚的情况；
场景：用户签到，用户中心，用户订单，等
服务器架构图：
说明：
场景中的这些业务基本是用户进入APP后会操作到的，除了活动日(618,双11，等)，这些业务的用户量都不会高聚集，同时这些业务相关的表都是大数据表，业务多是查询操作，所以我们需要减少用户直接命中DB的查询；优先查询缓存，如果缓存不存在，再进行DB查询，将查询结果缓存起来。
更新用户相关缓存需要分布式存储，比如使用用户ID进行hash分组，把用户分布到不同的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。
•用户签到获取积分
o计算出用户分布的key,redis hash中查找用户今日签到信息
o如果查询到签到信息，返回签到信息
o如果没有查询到，DB查询今日是否签到过，如果有签到过，就把签到信息同步redis缓存。
o如果DB中也没有查询到今日的签到记录，就进行签到逻辑，操作DB添加今日签到记录，添加签到积分(这整个DB操作是一个事务)
o缓存签到信息到redis，返回签到信息
o注意这里会有并发情况下的逻辑问题，如：一天签到多次，发放多次积分给用户。
o我的博文[大话程序猿眼里的高并发]有相关的处理方案。
•用户订单
o这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据
o用户访问订单列表，如果是第一页读缓存，如果不是读DB
o计算出用户分布的key,redis hash中查找用户订单信息
o如果查询到用户订单信息，返回订单信息
o如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息
•用户中心
o计算出用户分布的key,redis hash中查找用户订单信息
o如果查询到用户信息，返回用户信息
o如果不存在进行用户DB查询，然后缓存redis，返回用户信息
•其他业务
o上面例子多是针对用户存储缓存，如果是公用的缓存数据需要注意一些问题，如下
o注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询，可以使用管理后台更新缓存，或者DB查询的锁住操作。
o我的博文[大话Redis进阶]对更新缓存问题和推荐方案的分享。
以上例子是一个相对简单的高并发架构，并发量不是很高的情况可以很好的支撑，但是随着业务的壮大，用户并发量增加，我们的架构也会进行不断的优化和演变，比如对业务进行服务化，每个服务有自己的并发架构，自己的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；
消息队列
秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求
场景：定时领取红包，等
服务器架构图：
说明：
场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；
像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB；
设计这块业务的时候就会使用消息队列的，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包；
方案如：
•定时领取红包
o一般习惯使用 redis的 list
o当用户参与活动，将用户参与信息push到队列中
o然后写个多线程程序去pop数据，进行发放红包的业务
o这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险
附加：
通过消息队列可以做很多的服务。
如：定时短信发送服务，使用sset(sorted set)，发送时间戳作为排序依据，短信数据队列根据时间升序，然后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，如果超过就进行短信发送。
一级缓存
高并发请求连接缓存服务器超出服务器能够接收的请求连接量，部分用户出现建立连接超时无法读取到数据的问题；
因此需要有个方案当高并发时候时候可以减少命中缓存服务器；
这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，并且缓存的数据量要控制，不能过分的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存需要设置秒单位的过期时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可以让数据的获取命中到一级缓存，而不用连接缓存nosql数据服务器，减少nosql数据服务器的压力
比如APP首屏商品数据接口，这些数据是公共的不会针对用户自定义，而且这些数据不会频繁的更新，像这种接口的请求量比较大就可以加入一级缓存；
服务器架构图：
合理的规范和使用nosql缓存数据库，根据业务拆分缓存数据库的集群，这样基本可以很好支持业务，一级缓存毕竟是使用站点服务器缓存所以还是要善用。
静态化数据
高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。
对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，如果没有获取到数据再从缓存，数据库中获取，当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN，这样在高并发的时候可以使数据的获取命中在CDN服务器上。
CDN节点同步有一定的延迟性，所以找一个靠谱的CDN服务器商也很重要
其他方案
•对于更新频繁度不高的数据，APP,PC浏览器，可以缓存数据到本地，然后每次请求接口的时候上传当前缓存数据的版本号，服务端接收到版本号判断版本号与最新数据版本号是否一致，如果不一样就进行最新数据的查询并返回最新数据和最新版本号，如果一样就返回状态码告知数据已经是最新。