关于高并发的一些思考

1.什么是高并发?
高并发是解决大数据量业务的一种思路,源于现实的生产生活中的问题。

举一个现实生活中的例子:去银行办业务,银行里段时间来了100个人办理业务,但是只有一个窗口来办理,平均一个人办完业务需要5分钟,100个人需要500分钟。

当出现类似问题的时候,我们应该怎样去解决呢?
(1)提高单个窗口办理业务的效率,比如提高柜台营业员的业务水平,之前5分钟能够办理1个人,
现在可以办理2个人,提高单人处理效率,那么100个人办完需要250分钟;

(2)当单个人的处理效率达到最大时,应该如何继续提高办理效率呢?
一个窗口处理能力达到最大时,就要考虑其他方法了。一个问题如果纵向上没有好的解决办法,可以考虑横向来处理。比如这个问题,我们可以增加窗口并行处理,增加4个窗口,每个窗口都达到最大处理能力,比如都是5分钟办理两个人的业务,那么办完100个人需要50分钟。

用通俗的话来说,就是众人拾柴火焰高 说的就是这个道理,单个人的力量是有限的 ,大家一起干 处理效率自然就快很多。那么我们在处理海量数据的思路也是这样的,一台机器处理达到瓶颈时 我们增加几台机器 并行处理。

所以总结来说:高并发,就是高效率的并行处理 多通道处理,每个通道的功能相同,通过累加效应 体现整体的高效率。

2.如何实现高并发
目前有很多实现高并发的框架,比如netty、disruptor、消息中间件,他们有一个共同特点:多线程+缓存队列。
(1)并发是多通道并行,那么多线程就是实现多通道,一个线程负责一个处理通道;
(2)缓存队列用来干什么呢?
比如来了100个人办业务,5个窗口同时处理5个人,那么剩余的人就在等待区的座位上等待 当叫到下一位就会离开休息区到窗口去办业务。休息区起到了缓冲作用,否则大家都排在窗口面前堵在那里。在处理数据时候,等到数据来了放到缓冲队列里暂时存放,等到线程空闲了,就继续处理。
有一个问题是,为什么不放到数据库里,而是要创建一个缓存去存放?
要回答这个问题,需要了解两件事情:
1、搞清楚数据库和缓存的区别:
数据库是用来持久存放数据的,是记录到磁盘里,读取或者插入有磁盘IO操作,有一定的耗时的,一般是在业务设计中,如果是业务需要必需存下来的数据,就需要记录到数据库里;
缓存是用来存放少量临时数据的,不需要记录到磁盘,优点是处理速度快。
2、高并发的目的就是高效率,所以一切提高效率的事情都是必要的。
CPU是按照寄存器>内存条>磁盘的次序,效率依次降低,所以这里相对于数据库,使用缓存队列,效率高。 比如JDK的concurrenthashmap,消息中间件、netty等都是加载到内存里,disruptor更厉害,加载到寄存器里,效率更高。

原文地址:https://www.cnblogs.com/cac2020/p/9687164.html

时间: 2024-08-24 07:06:38

关于高并发的一些思考的相关文章

【转】腾讯高级工程师:一道面试题引发的高并发性能调试思考

https://dbaplus.cn/news-21-625-1.html 这样打破沙锅问到底的精神十分可贵!注意其中用到的工具 4月份的时候看到一道面试题,据说是腾讯校招面试官提的:在多线程和高并发环境下,如果有一个平均运行一百万次才出现一次的bug,你如何调试这个bug?(知乎原贴地址如下:https://www.zhihu.com/question/43416744) 遗憾的是知乎很多答案在抨击这道题本身的正确性,虽然我不是这次的面试官,但我认为这是一道非常好的面试题.当然,只是道加分题,

对于高并发的一些思考

夜宵时的思考 刚刚排错了一个小时,终于搞定了,奖励自己一碗泡面,在等微波炉前等待的时候想了挺多事的. 并发似乎是所有程序员的噩梦,也是所有程序员的"粮食",如果计算机不支持并发,世界上的Error Log应该能少一半,同时程序员的"魔力"也少了三分. 所谓的秒杀系统,其实是一种泛指,代表着多并发,高可用系统.为什么说至今没有一个类似Spring一样的框架,能在并发领域脱颖而出呢,因为每个领域,各个场景的情况不一样,每个解决并发的方案,脱离了实际,就没了价值. 面熟了

高并发秒杀系统--课程总结与思考

[高并发秒杀系统的开发流程及技术要点] DAO层 1.数据库设计和实现,手写DDL 2.Mybatis理解和使用技巧,主配置,XML中SQL的编写 3.Mybatis与Spring的整合,包扫描,DAO实现,别名识别 Servcie层 4.业务接口的设计和封装,使用者角度设计接口 5.SpringIOC配置技巧,注解+XML 6.Spring声明式是事务使用和理解 Web层 7.Restful接口运用 8.SpringMVC的使用技巧 9.前端交互分析过程 10.Bootstrap和JS的使用,

多 “维” 优化——前端高并发策略的更深层思考

作者:徐嘉伟,腾讯web前端开发 高级工程师 商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处. WeTest 导读 一项指标的变好,总少不了相应优化策略的实施.优化并不是简单的一蹴而就,而是个不断迭代与推翻的过程.更深层的优化方案,往往是在某种思维策略之下,对问题场景和基本策略优缺的深刻理解后做出的当下最优的权衡结果.本文笔者从前端高并发优化这一具体点出发,逐步向大家阐述笔者在优化的"术"之上思维层面的一些思考.希望能给各位带来共鸣和感悟. 背景: 之所以会以前端高并发这

对mysql的高并发优化配置的一些思考

对mysql的高并发优化配置的一些思考 mysql的高并发优化配置方案很多,但是适应你自己的就变得很少了,我们对数据库的优化,无非就是为了应对mysql的高并发情况罢了.随着大数据的时代的到来和网络用户的增多,很多企业中,可能每天应对的数量达百万,千万,甚至上亿的pv量,这样的量已经是超过普通配置的mysql所承受的量,所以应对日益增长的pv量,我们需要对mysql做出相应的对策,进一步优化mysql,达到我们所预期的效果,预防因为高并发所引起的mysql宕机,通过调试优化mysql,我们便可以

高并发高可靠性系统思考1

CPU不是瓶颈,网络才是: 墨菲定律:任何事情都没表面看起来那么简单:会出错的总会出错: 可靠性: 集群:无状态集群:有状态集群,很难处理,尽量剥离出状态部分做集中式部署,其他做无状态部署: mater/slave,极端情况下快速切换,恢复系统的可用性,软件层面和硬件层面: 数据:raid磁盘阵列,双写(同步,可靠性高,影响效率:异步,可靠性低): 跨机房,跨网络(电信,移动),跨交换机部署: 限流/流量切换:超过系统预估负载能力时,可选择直接将部分请求丢弃,来保证部分用户的适用,一般在硬件或h

高并发思考和解决办法

系统高并发操作会出现系统访问性能问题,死锁,数据不同步等一系列问题.用电商系统来说,高并发下,会出现访问的订单状态不一致的情况.那么可以考虑对此问题做集群处理. 客户端2亿访问量就是高并发业务场景,会出现相应的问题. 现在考虑组成集群 经过负载后 压力平摊到多个节点,分担单实例的压力(多实例+负载),如图: 应用组成了集群,但是连接的还是一个存储,这个时候,所有的实例如果在储存上还是一个库,瓶颈就在存储这一边了,在mysql下,可以考虑住数据库集群,主从配置,读写分离. 这样就储存的压力也分开了

思考如何做一个普通网站和高并发的网站

写写总结一下,分别用C#和Java如何构建一个普通网站和一个高并发.安全的网站. 构建一个普通网站的checklist:.net mvc:mvc+EF+mysqljava:主流仍然使用ssh2?纯前端如node.js的优势和缺点如何? 注意事项:基本架构,前端框架,数据库事务 脚本构建一个高并发的网站:基本架构上的调整:缓存的加入(如memcached等),多线程的使用,需不需要做成分布式结构(web service等),图片等静态资源的CDN网络:数据库表之间字段关联的设计,字段冗余的合理使用

php高并发秒杀系统的搭建总结思考(一)

秒杀系统大致分为三大块.客户端,服务器,后台管理.秒杀系统具有大流量高并发的特点. 对于web前端的处理,一般是页面静态化+CDN分布式缓存. 因为静态页面的处理速度是最快的.假设单台服务器nginx,1秒内可以处理的静态页面请求是1w,处理php程序可能是500每秒.这样在效率上就差很多.原因是php属于动态语言,服务器需要解释运行,这当中可能大量的I/O操作,加载扩展等.这就导致处理的时间比较长. 所以对于秒杀产品,一般都是在活动快要开始时,上线静态页面. 原文地址:https://blog