高并发
1.1 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。
1.2 高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。
1.2.1 响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。
1.2.2 吞吐量:单位时间内处理的请求数量。
1.2.3 QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。
1.2.4 并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。
1,服务器网络带宽不够(增加网络带宽)
2,web线程连接数不够(DNS域名解析分发多台服务器,负载均衡,前置代理服务器nginx、apache等等)
3,数据库连接查询瓶颈(数据库查询优化,读写分离,分表等等)
4,尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能;用jprofiler等工具找出性能瓶颈,减少额外的开销。
5,优化数据库查询语句,减少直接使用hibernate等工具的直接生成语句(仅耗时较长的查询做优化)。
6,优化数据库结构,多做索引,提高查询效率。
7,统计的功能尽量做缓存,或按每天一统计或定时统计相关报表,避免需要时进行统计的功能。
能使用静态页面的地方尽量使用,减少容器的解析(尽量将动态内容生成静态html来显示)。
8,不要频繁的new对象,对于在整个应用中只需要存在一个实例的类推荐使用单例模式;对于String的连接操作,使用StringBuffer或者StringBuilder;对于utility类型的类通过静态方法来访问。
9,避免使用错误/异常的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要;不要使用 instanceof做条件判断,尽量使用比的条件判断方式;使用JAVA中效率高的类,比如ArrayList比Vector性能好。
10,出现超时的情况,一般说明并发数量已经超过了数据库所能处理的极限,数据库无限等待导致超时,此时,建议采用线程池的方案,支付宝的单号就是用的线程池的方案进行的。数据库 update 不是一次加1,而是一次加几百甚至上千,然后取到的这 1000个序号,放在线程池里慢慢分配即可,能应付任意大的并发,同时保证数据库没任何压力。
首先我们要知道高并发下会出现某一个时刻流量猛增,还有就是如果是抢购之类的库存类并发可能会导致超卖库存为负数之类的,对于并发锁来说主要是解决抢购超卖问题的,并不能很好的解决流量猛增给服务器带来的压力,有时候甚至会加重服务器的压力,所以我们并发量小及服务器配置比较高的时候可以用并发锁来处理,下面就介绍几种常用的并发锁
这个对于java开发来说肯定不陌生,它可以让各个线程同步执行,缺点是极度的耗费性能,临时处理可以使用,经常使用的情况下不推荐
mysql数据库也是自带锁的,这种情况一般用行锁,不过这个会产生事务阻塞数据库,极度耗费性能,且容易造成死锁,一般在内部确定的极低的并发(一般就2个并发)的时候使用
Redis是一个开源(DBS许可)的,内存中的数据结构存储系统,他可以用作数据库,缓存和消息中间件,他支持多种类型的数据结构,如字符串(String),散列表(hashes),列表(lists),集合(sets),有序集合(sorted sets)与范围查询, bitmaps, hyperloglogs 和 地理空间(geospatial) 索引半径查询。
Redis 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的 磁盘持久化(persistence), 并通过 Redis哨兵(Sentinel)和自动 分区(Cluster)提供高可用性(high availability).
速度快: tomcat: 150-220/秒; nginx: 3-5万/秒 ;redis: 写 8.6万/秒 读 11.2万/秒 ~ 平均10万次秒
本站主要用于日常笔记的记录和生活日志。本站不保证所有内容信息可靠!(大多数文章属于搬运!)如有版权问题,请联系我立即删除:“abcdsjx@126.com”。
QQ: 1164453243
邮箱: abcdsjx@126.com