高并发架构技术解决方案？

高并发架构的难点是什么？

高并发架构最大问题主要是由于网站PV访问量大，单台服务器承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个请求访问会被 发送到不同的服务器。

这样架构的难点就在管理、维护、监控、负载等等都面临很大的技术问题，同时还需要应对某些业务的突发流量，像秒杀、促销等场景化使用什么技术解决高并发？

互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。

不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。

水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践。

水平扩展要怎么来做？首先是软件服务拆分到不同的服务器进行部署，全部堆积在一台上性能将会受限。例如：Redis 就只是部署在独立的服务器上，其它软件都在这服务器上出现增加各个软件服务部署的服务后，采用技相关技术手段分担到各个服务器上。nginx反向代理层可以通过“DNS轮询”的方式来进行水平扩展。dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。PHP站点层可以通过修改nginxconf实现负载均衡机制来进行水平扩展。从而设置多个web后端。服务层可以通过服务连接池来进行水平扩展；这里一部需要实现服务化，PHP像swoole tarsphp等数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；那高并发架构是什么样的？

常见互联网分布式架构如上，分为：

（1）客户端层：典型调用方是浏览器browser或者手机应用APP

（2）反向代理层：系统入口，反向代理

（3）站点应用层：实现核心应用逻辑，返回html或者json数据

（4）服务层：服务化，例如像Swoole

（5）数据-缓存层：缓存加速访问存储

（6）数据-数据库层：数据库固化数据存储

不同类型的网站对于服务器资源的占用情况也不一样

如果是普通的企业站或者文字为主的网站不需要做负载均衡,用一台四核至强处理器4G以上内存10M以上带宽的配置基本上就能满足

如果是较大规模或者是视频内容较多的网站,则会对服务器资源占用较高推荐用双至强八核处理器32G内存1T硬盘的配置来放数据库,然后再用几台普通四核配置的机器放网站前端来做负载均衡即可带宽需要根据你们的具体需求来决定

1、这个题目问得不那么准确，你必须要精准计算出每秒查询时间（QPS）和事务时间（TPS），好比你感冒了，你说要配什么药，医生只能凭经验，你如果去抽象化验，知道是病毒还是细菌感染，数量是多少后，才能进一步诊断和配置服务器硬件。

2、接下来，你要了解常用发中间件和数据库的极限并发量。比如redis一般是11w左右（纯粹内存读写）、mysql每秒写8w左右，读10来万（单表，多表就不一定，得看SQL的写法），一般单表的存储极限是5千万左右，如果超出范围，那么配置再好也是慢。总的说来，要精确配置服务器，你需要尽可能地评估最复杂的业务每秒并发时间，同时要考虑最复杂的情况，比如数据库的数据规模、代码在最高并发下，所耗费的时间，同时对网络I/O也要有一个预估，知道带宽的大小，总之，需要具体问题具体分析。

3、如果以上情况不考虑，就是想知道一个简单粗暴的大概结果，一般8核、16G、256SSD，同时跑DB和web服务器的话，足够支持1w的并发量，而且还有很大的冗余。如果火力全开，满血跑，大概跑个8-10w都是有可能的。边压测，边优化，如果恰好旁边有高手，榨干每一个环节，你的并发量超出你的想象

问题一：java程序员面试时被问到：如何在j2ee项目中处理高并发量访问？ 该怎么回答？ 请仔细看题干再回答 blogcsdn/y_h_t/article/details/6322823

你是一名java程序员，这些应该知道些吧

问题二：如何处理高并发带来的系统性能问题 那必须了解linux中的基本使用，比如如何找到某个路径，如何打开一个文件，如何编辑修改一个文件等等，那就是linux中命令的使用；还有就是必须知道linux服务器中所用的什么服务器（有weblogic、websphere等等）；精通相关服务器的重要属性配置等等。

问题三：JAVA中高访问量高并发的问题怎么解决 你指的高并发量大概有多少？

几点需要注意：

尽量使用缓存，包括用户缓存，信息缓存等，多花点内存来做缓存，可以大量减少与数据库的交互，提高性能。

用jprofiler等工具找出性能瓶颈，减少额外的开销。

优化数据库查询语句，减少直接使用hibernate等工具的直接生成语句（仅耗时较长的查询做优化）。

优化数据库结构，多做索引，提高查询效率。

统计的功能尽量做缓存，或按每天一统计或定时统计相关报表，避免需要时进行统计的功能。

能使用静态页面的地方尽量使用，减少容器的解析（尽量将动态内容生成静态html来显示）。

解决以上问题后，使用服务器集群来解决单台的瓶颈问题。

基本上以上述问题解决后，达到系统最优。

至于楼上有人提到别用JAVA来做，除非是低层的连接数过大（如大量的端口占用需求），这种情况下考虑直接C来写，其他的可以用JAVA来做。

问题四：项目中怎么控制多线程高并发访问 synchronized关键字主要解决多线程共享数据同步问题。

ThreadLocal使用场合主要解决多线程中数据因并发产生不一致问题。

ThreadLocal和Synchonized都用于解决多线程并发访问。但是ThreadLocal与synchronized有本质的区别:

synchronized是利用锁的机制，使变量或代码块在某一时该只能被一个线程访问。而ThreadLocal为每一个线程都提供了变量的副本，使 得每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。而Synchronized却正好相反，它用于在多个线程间通信 时能够获得数据共享。

Synchronized用于线程间的数据共享，而ThreadLocal则用于线程间的数据隔离。当然ThreadLocal并不能替代synchronized,它们处理不同的问题域。Synchronized用于实现同步机制，比ThreadLocal更加复杂。

1、Java中synchronized用法

使用了synchronized关键字可以轻松地解决多线程共享数据同步问题。

synchronized关键字可以作为函数的修饰符，也可作为函数内的语句，也就是平时说的同步方法和同步语句块。如果再细的分 类，synchronized可作用于instance变量、object reference（对象引用）、static函数和class literals(类名称字面常量)身上。

synchronized取得的锁都是对象；每个对象只有一个锁（lock）与之相关联；实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。

问题五：如何处理高并发或列举处理高并发的业务逻辑 1、提高系统的并发能力　　2、减轻数据库的负担　　这两种用途其实非常容易理解。由于memcached高性能，所以可以同时服务于更多的连接，大大提高了系统的并发处理的能力。另外，memcached 通常部署在业务逻辑层（前台应用）和存储层（主指数据库）之间，作为数据库和前台应用的数据缓冲，因此可以快速的响应前端的请求，减少对数据库的访问。

问题六：数据库怎样处理高并发 1用一个标识，在选择那张票的时候先用(Update 表 set 票flag=‘占用了！’ where 票flag=‘未占用’ and )这样是保险的，不可能存在并发问题，这就牵扯到sql锁机制问题了，你可以测试一下，其实sql中update是先查询出然后删除再添加，但由于使用了update，过程中就自动加锁了，很方便吧2加锁。Microsoft® SQL Server™ 2000 使用锁定确保事务完整性和数据库一致性。锁定可以防止用户读取正在由其他用户更改的数据，并可以防止多个用户同时更改相同数据。如果不使用锁定，则数据库中的数据可能在逻辑上不正确，并且对数据的查询可能会产生意想不到的结果。虽然 SQL Server 自动强制锁定，但可以通过了解锁定并在应用程序中自定义锁定来设计更有效的应用程序。

问题七：数据库怎样处理高并发 理论上不限制并发连接数的就是服务器受硬件的限制过高的并发是会使服务器无法完成并发任务,而造成服务器死机或者假死机不过数据库软件可以优化并发连接,使并发持续的时间更短,以减起服务器的负担,但是一台服务器不能完成几十万的并发

问题八：如何处理大量数据并发操作 如何处理大量数据并发操作

文件缓存，数据库缓存，优化sql,数据分流,数据库表的横向和纵向划分，优化代码结构！

锁述的概

一 为什么要引入锁

多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:

丢失更新

A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统

脏读

A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致

不可重复读

A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数据时发现前后两次的值不一致

并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致

二 锁的分类

锁的类别有两种分法：

1 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁

MS-SQL Server 使用以下资源锁模式。

锁模式 描述

共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。

更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。

排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。

意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。

架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。

大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。

共享锁

共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。

更新锁

更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。

若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。

排它锁

排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。

意向锁

意向锁表示 SQL Server 需要在层次结构中的某些底层资源上获取共享 (S) 锁或排它 (X) 锁。例如，放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享 (S) 锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它 (X) 锁。意向锁可以提高性能，因为 SQL Server 仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁>>

问题九：高并发是什么和如何解决 数据库建立多表关联，关键业务数据字段和查询字段建立索引，对唯一性建立好，同时多任务并发时程序设计时注意数据的合理性检验和用户处理数据有问题时的友好提示见面，建立好的结构文档说明，同时对关键字段的关系型作好记录，有效地设计多表的结构安排，尽量减少数据的冗余，同时又要避免对历史数据的影响，保持良好的数据管理

问题十：如何处理高并发量的HTTP请求 尽量减少页面的HTTP请求，可以提高页面载入速度。减少页面中的元素网页中的的、form、flash等等元素都会发出HTTP请求，尽可能的减少页面中非必要的元素，可以减少HTTP请求的次数。

mysql的高并发其实是基于硬件的

这个配置要和服务器的硬件配置和负载来慢慢调

没有统一配置的

简单的说一点 其他的你最好去查手册

然后根据你的业务需要来调整

default-storage-engine=INNODB //事务引擎，如果不用事务支持可以不用，速度稍慢于MYSIM

max_connections=20000 //这个需要看你的硬件是否足够牛

query_cache_size=440M //查询的缓存 如果内存够大可以再大点

table_cache=2028 //表的缓存 表如果很对的话可以大点

tmp_table_size=512M //临时表空间，看你的应用了，是否用了临时表

thread_cache_size=80 //线程缓存 看你的业务是否有很多重复的请求

myisam_max_sort_file_size=100G //排序或索引文件的最大值（看你的表友多少数据和有多少索引）

后面的查手册吧 这东西设置太高太低都不太好 ，从小到大按业务需要慢慢调整吧