景区计数器,

大家好，今天小编关注到一个比较有意思的话题，就是关于景区计数器的问题，于是小编就整理了1个相关介绍景区计数器的解答，让我们一起看看吧。

1. 系统接口的请求量，会在某些时间内突然增加，有什么应对措施么？

系统接口的请求量，会在某些时间内突然增加，有什么应对措施么？

我们现在的系统，最开始只面向内网系统，这种情况下，访问量都不是特别的大并且比较平稳，最近开始接了一些互联网区的系统，访问量一下子上来了，所以也不得不考虑这方面的问题。

首先要说明，我们公司虽然也号称上了云，但是基本上还是基础的IasS这个级别，并没有PasS，也没有容器管理平台什么的，所以网上说的那些自动的流量监控、自动扩容缩容什么的，我们并没有使用过；所以针对这种情况，基本上还是一些土办法。

什么系统会调用？这些系统的使用用户是谁？每日调用量是多少？高峰期预计是多少？

每个公司的情况可能不太一样，我们公司也成了好多年了，这些数据参考之前的产品/活动/需求基本上可以评估个大概范围，比如一个业务场景下，每天大概会有10万的调用量，在开发、压力测试和生产***申请的过程中，就按照（评估数量*N）的一个值进行估量。

如果是小公司的话，或者某个业务场景是第一次上，那么这个数量是比较难估计的，这时候只能猜一个数量，不过就算是猜的，也比没有强。

对于软件系统而言，若特定时间段内流量暴增，那软件系统及相关API的性能瓶颈立马就会表现出来，服务器***被占满，随之导致服务及系统不可用。所以我们要在系统架构时充分考虑到洪峰带来的性能压力，以达到“三高架构”。

架构领域所说的“三高”是指：

高并发：并行处理的请求越多则代表并发越高；

高性能：服务性能好，响应处理速度快；

高可用：服务不可用的时间短、或基本没有。

如何使我们的API达到“三高”呢？可以通过一些技术方案来实现，我这里整理了一些以供大家参考：

1、合理的缓存设计

在API层提缓存，很多人就觉得API不应该加缓存，因为大多数接口数据对实时性都是有要求的，但这里说的缓存主要是指借助内存来缓解DB层的查询（因为内存读写速度比硬盘读写速度快得多）。

要知道，API的数据来源主要是从数据库中查询出来的，所以在流量洪峰时，所有的流量都会打到DB层，这样数据库的查询压力很大。我们建议在用Redis等NoSQL产品来同步一份热点数据，API直接从Redis中取数据，取不到数据再从DB层查询。

2、数据库主从同步、读写分离

对于开发人员来说，在开发接口时是需要考虑高并发的情况的，在开发时要尽量优化代码提升接口性能，***用缓存机制以降低对数据库的操作；接口需要进行压力测试，并且将测试结果作为接口指标，在实际业务场景中，可以通过日常检测提前预估接口的访问情况，及时对服务器作出调整和扩容，以应对高并发的情况。

对于突然性的并发访问，可以***用流量限制的方式，通过对线程、数据库连接数等进行限制从而降低服务器的压力，如果是在分布系统中，也可以***用消息队列的模式，通过消息队列作为缓冲削弱访问压力；或者***用页面静态化的方式，将一些信息动态生成html页面，通过访问html页面降低对数据库的访问、提升效率；也可以搭建服务器集群，通过集群的图片分离、负载均衡等方式来分散访问压力，提升访问效率。

到此，以上就是小编对于景区计数器的问题就介绍到这了，希望介绍关于景区计数器的1点解答对大家有用。

[免责声明]本文来源于网络，不代表本站立场，如转载内容涉及版权等问题，请联系邮箱:83115484@qq.com，我们会予以删除相关文章，保证您的权利。转载请注明出处：http://www.onosokkii.com/post/75828.html