你们都是怎么确保系统不被突然的访问流量压垮的？（mongodb还原超时如何解决）

你们都是怎么确保系统不被突然的访问流量压垮的？

在系统的设计之初就要想到这个问题，建议使用微服务架构，对流量压力大的微服务，多配置服务器，没有什么流量压力是多配置一台服务器不能解决的，如果不够，那就多配10台，再不够，就100台，简单粗暴而有效，我就不信那个邪。代码优化得再好，不如增加一个实例。

三河网站制作公司哪家好，找成都创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站设计等网站项目制作，到程序开发，运营维护。成都创新互联于2013年成立到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联。

两个方向来思考和回答这个问题：

第一点是努力提升整体系统的性能，

首先需要做压测，分析系统当前的容量和瓶颈，对照对业务场景容量的评估，评估是否要提前做扩容。

性能瓶颈的问题，那就是更细的活了，需要从系统、架构、接口、代码层面来优化。

第二点就是当前系统总有性能的上限，遇到流量异常突增，那该怎么办？

限流，思路是确保能处理的流量可以得到处理，超限的流量拒绝，典型场景是秒杀。

降级，思路是保证业务的关键流程，舍弃分支流程。实际上降级主要用在服务不稳定情况下，当然高并发流量是导致系统不稳定的一个重要因素。

另外，需要对系统的各个环节做好监控，以便及时发现异常，及时处理。

把系统部署在弹性云上，则可以进行动态的扩容和缩容。

最后，并不是说上述的一个策略就能解决所有问题，保证系统的高可用是一个很复杂的工作，需要方方面面的努力。

确保系统的高可用，要做的事情非常多，比如使用 Redis 缓存数据库的数据，降低数据库的压力，同时也要注意缓存穿透、雪崩、击穿等问题；但要是说到“不要被突增的访问量击垮”，通常就会到我们常说的分布式架构三板斧：限流、熔断、降级。

限流理解起来很简单，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患；只卖N张票，这就是一种限流的手段。

软件架构中的限流也一样，就是流量徒增的时候，只允许一部分流量进来，而多余的那部分，就拒绝掉。

通常我们可以通过限流算法达到这样的效果，比如计数器法、滑动窗口法、漏桶算法、令牌桶算法，每个算法的详解之前的文章有介绍过，这里就不在占用篇幅了。上面的例子中，故宫每天只卖八万张票，有点儿类似于令牌桶算法，票就相当于令牌，只有拿到令牌的请求，才能访问到服务。

有些程序员一直坚持反对使用redis怎么办？

一方面我肯定是不支持这些“上古”程序员做法的，但是另外一方面，我也是非常理解他们的想法的。

首先，有些公司的风格就是：“可以不干，但是不能犯错”。

我曾经在一家央企的 IT 部门工作，对此有着深刻的认识：你的系统可以一年到头没有什么新功能，几年不做升级，但是千万不能有生产事故，否则可能真的会“万劫不复”，也就是绩效会低、奖金会少，甚至升职无望。

在这种环境中工作的大部分老员工，除非是迫不得已，几乎不会主动去升级和完善系统的，“能稳定运行就行了”。

分享大佬的回答，似乎很有道理。

不要告诉我们用不用redis，你得告诉我们你为什么想要用redis，不用redis业务会有什么问题？天下没有免费的午餐，不动脑子直接上缓存/NOSQL可能会带来更多更严重的问题。

单一数据库最大的好处在于事务性实现简单，由数据库自己保证。举个简单的例子，下订单需要扣除一个库存，然后插入一条订单条目，如果库存和订单都是数据库表项的话这个事务是无懈可击的，如果库存在redis里，订单条目是MySQL，通常就需要先写redis，成功之后再写数据库，如果写数据库失败了还需要回滚redis，如果最后这个回滚因为网络之类的原因失败了，就会多扣一个库存。不要以为这些事情很好解决，事务性处理的复杂性远远超过你的想象，比如说还有写MySQL在提交的一瞬间连接断了这种情况，你都没法判断提交到底成功了还是失败了，那你的redis是回滚还是不回滚？

所以引入新的层一定要说清楚，你为了什么目的一定要用缓存/NOSQL，能接受什么样的一致性模型，否则就是在胡闹。

这和眼镜一样 需要的时候 自然就会去用了 你说我就不喜欢戴眼镜 那可以 要不你就眼前一片模糊自己忍着 要不你就去做手术 只不过戴眼镜是解决你近视问题的一种比较简单高效又多人用而且成熟的手段而已

一个非常好的问题。我是工作多年的Web应用架构师，来回答一下这个问题。欢迎关注我，了解更多IT专业知识。

题主没有说明原因和理由，在实际项目中可能出现多种场景，不能一概而论。

1，前期预研项目，Demo演示功能，没必要使用

如果原型验证的重点是某一项技术，没时间开发那么完善的系统，这时先不用Redis搭建缓存优化性能什么的，是可以接受的。

2，小型单机项目，功能简单，业务逻辑单一

功能简单的小项目，用户量少，或者对运行效率没那么敏感，为了保持一个简单的系统架构，方便运维管理，倒是不必要引入那么多的依赖服务，也不用占用不必要的服务器资源。

3，公司内部项目，早期开发阶段，快速迭代，业务需求变化大

有那么一类软件系统，是给公司内部自己人用的，各个部门老大就是拍脑袋定需求的核心用户，带来的问题就是需求改动大、开发返工甚至项目取消都有很大的可能性。尤其是在早期开发阶段，还没有沉淀下来一个相对明确的系统框架，这时的重点应该放在业务需求上，不用过度设计技术架构。

4，项目中已经使用了其它类似的技术框架，比如Memcached, MongoDB，等等

Redis是一个高性能的key-value数据库，常用于搭建缓存系统，提高并发响应速度。Redis使用非常普遍，简单轻量，部署维护方便，是很多人使用的第一个NoSQL数据库，很受欢迎。

类似的技术解决方案也可以使用其它框架，比如Memcached，MongoDB，不同技术背景的个人和团队有不同偏好，很正常。

搞Linux运维的,需要学习些什么语言？

Linux运维主要学习以下语言：

运维工作尤其是linux运维，其实最考验你的能力，因为需要学习的东西实在太多，

你既要懂网络：思科华为设备的配置;

要懂性能调优：包括lamp或者lnmp的性能调优，也包括linux操作系统调优;

要懂数据库mysql或者nosql(例如mongodb)：

要懂编程语言：Shell是最基本的，还要学习perl，python，甚至ruby和C++等(因为一些软件是这些语言编写的)，还得熟练掌握awk，sed，grep以及正则表达式;

要懂一些调试排错的命令工具的使用，比如htop，dstat，strace,systemtap,iostat,sar等;

要有比较好的英语水平：因为很多软件或者工具以及出现问题排错的答案都不是国人所做，甚至还需要和原作者交流，在谷歌group里面留言讨论

要有坚强的体魄和超时工作的心理准备：升级维护都是在大家还在做梦时候。夜里2点网站挂了你也得起来，手机不停的接收各种报警短信...

要有背黑锅的忍耐力：运维一直是公司爹不疼娘不爱的位置，别人做好了和你无关，你做差了别人作不好就是你影响的。人力和财务是技术部门的服务，运维就是各技术部门的服务，大到线上操作，小到帮助公司其他使用linux桌面的同事，公司内部机房，IDC维护(跑腿搬服务器)。

到此，以上就是小编对于mongodb数据还原的问题就介绍到这了，希望这3点解答对大家有用。

网页名称：你们都是怎么确保系统不被突然的访问流量压垮的？（mongodb还原超时如何解决）
网页URL：http://www.shufengxianlan.com/qtweb/news8/25008.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联