甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
它们是按SMP、NUMA、MPP、集群、分布处理从最紧密到最松散的排列。
创新互联是一家专业提供江宁企业网站建设,专注与成都网站设计、成都网站制作、H5高端网站建设、小程序制作等业务。10年已为江宁众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
SMP(多处理系统):这种系统是在一台计算机里有多个CPU,CPU之间的地位是平等的，它们共享内存空间和I/O设备。其工作方法是由操作系统负责将任务分解成多个并发进程，然后让其在不同的CPU上运行。
NUMA(非统一内存存取):这种系统可以让多处理计算机的CPU比SMP更高效地共享本地内存，CPU可以更快速地存取单一的内存区域，不过如需要也可以用间接方式存取其他区域的内存，这种方法是让某些CPU在给定范围的物理内存中有更大的优先使用权。
MPP(巨型并行处理):这种系统的节点都有自己的CPU，并有自己的专有资源。此种结构相对独立，但各个节点一般没有完全存取I/O的能力。
集群:集群系统是由独立的计算机组成，但有控制管理工具统一管理。
分布处理:它是比我们要构筑的集群系统更松散的连接，一般是任务在不同的地方完成，没有可以作为整体管理的单一实体。
以上的聚合方式有紧有疏，它们都有自己的适用范围，这里就不多说了，有兴趣可自己找些资料看，这里只是想让大家了解它所处的位置。
实现负载均衡的方法
集群的目的是共享和高效地利用资源，提供大型运算，提供负载均衡分配请求压力以及出现故障时能够进行切换实现高可用性。
限于篇幅，本文只对负载均衡的实现做些介绍(针对TurboLinux Cluster Server)。通过对相关软件的分析，实现集群负载的功能是通过流量管理实现的，具体有这样几种实现方法:直接路由(Direct forwarding)、网络地址转换(NAT)、隧道技术(Tunneling)。
直接路由(Direct forwarding)
当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法，控制管理的计算机接收到请求包时直接送到参与集群的节点。优点是返回给客户的流量不经过控制主机，速度快开销少。
网络地址转换(NAT)
这种方法可能大家较熟悉，地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址，外界看起来包是来自地址转换器本身，当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。优点是节省IP地址，能对内部进行伪装;缺点是效率低，因为返回给请求方的流量经过转换器。
隧道技术(Tunneling)
这种方式是在集群的节点不在同一个网段时可用的转发机制，是将IP包封装在其他网络流量中的方法，为了安全的考虑，应该使用隧道技术中的VPN,也可使用租用专线。
集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务、Proxy服务器等等，下面我们将就具体的产品TurboLinux Cluster Server 来实现一个进行负载均衡集群系统，用于提供Web和FTP的服务。四台服务器的负载均衡实例
所提供的服务:Web、FTP。
系统的实现目的:做一个较完善负载均衡的系统，以便能用到其中的较多的功能。
采用设备状况:使用四台服务器，其中3台装TurboLinux Cluster Server,1台安装Windows 2000 Sever。系统安装1.在两台服务器上安装TurboLinux， apache和wu-ftpd也要安装，因为集群要提供这种服务,安装完后重启，挂接光驱在目录/mnt/cdrom下，执 行./TLCS-install,然后按提示完全安装。
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.
1. 优化一览图
2. 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.
2.1 软优化
2.1.1 查询语句优化
1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.
2.例:
显示:
其中会显示索引和查询数据读取数据条数等信息.
2.1.2 优化子查询
在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.
2.1.3 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者MySQL数据库索引一文,介绍比较详细,此处记录使用索引的三大注意事项:
2.1.4 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
2.1.5 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.
2.1.6 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询.
2.1.7 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.
1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.
2.2 硬优化
2.2.1 硬件三件套
1.配置多核心和频率高的cpu,多核心可以执行多个线程.
2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.
3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.
2.2.2 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.
2.2.3 分库分表
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。
2.2.4 缓存集群
如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.
mysql负责高可用，可以参考如下几种方案：
1.基于共享存储的方案SAN
方
案介绍：SAN(Storage Area
Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统
并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。共享存储的架构如下:
优点:
1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应用透明。
3.保证主备数据的强一致。
限制或缺点:
1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格比价昂贵。
2.基于磁盘复制的方案 DRBD
方
案介绍：DRBD(Distributed Replicated Block
Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务
器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相
同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：
优点：
1.切换对应用透明
2.保证主备数据的强一致。
限制或缺点：
1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2.一般配置两节点同步，可扩展性比较差
3.备库不能提供读服务，资源浪费
3.基于主从复制(单点写)方案
前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决MYSQL服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖
MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方
案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。
您好，很高兴为您解答。
第一先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果
非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务.
处理方法: set global innodb_thread_concurrency=16;
第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了.
DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的.
限制单用户连接数在500以下. 如:
set global max_user_connections=500;
(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因)
另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也可以考虑禁用该参数)
处理依据:
当学校的一个食堂一分钟只能为两个打饭, 忽然来了100个时人来打饭,又没排队, 不出会现了打饭的师傅要用点时间
去选择为那个用户服务了, 人越多,场面就越乱, 难免出现用户大吼该他的场面, 最后有可能就出现不是打饭了,而时之间相互
打架了,打饭的师傅也将收到同时有90个以上的Server too busy. 如果能排一下队.最多也就50分钟能处理完了.
以前办法,应该可以让MySQLD不会挂掉.如果业务支撑受到限制,还是想办法处理一下.
如若满意，请点击右侧【采纳答案】，如若还有问题，请点击【追问】
希望我的回答对您有所帮助，望采纳！
~ O(∩_∩)O~
大家好，一起来搞一下mysql的负载均衡这个技术点。
1. haproxy介绍与配置
2. keeplived介绍与配置
3. mysql高可用搭建
1. 可靠性与稳定性都非常出色，可与硬件级设备媲美。
2. 支持连接拒绝，可以用于防止 DDoS 攻击
3. 支持长连接、短连接和日志功能，可根据需要灵活配置
4. 路由 HTTP 请求到后端服务器,基于 cookie 作会话绑定;同时支持通过获取指定的 url 来检测后 端服务器的状态
5. HAProxy 还拥有功能强大的 ACL 支持，可灵活配置路由功能，实现动静分离，在架构设计与实现上 带来很大方便
6. 可支持四层和七层负载均衡，几乎能为所有服务常见的提供负载均衡功能
7. 拥有功能强大的后端服务器的状态监控 web 页面，可以实时了解设备的运行状态 ，还可实现设备上 下线等简单操作。
8. 支持多种负载均衡调度算法，并且也支持 session 保持。
9. Haproxy 七层负载均衡模式下，负载均衡与客户端及后端的服务器会分别建立一次 TCP连接，而在 四层负载均衡模式下(DR)，仅建立一次 TCP 连接;七层负载均衡对负载均衡设备的要求更高，处理能力 也低于四层负载均衡。
全局设定
global settings:主要用于定义 haproxy 进程管理安全及性能相关的参数。
代理设定
proxies 共分为4段:defaults，frontend，backend，listen
注意：此处只做配置文件介绍，不做为后期负载均衡配置
在192.168.199.175与192.168.199.172(负载均衡服务器)中安装与配置如下
haproxy状态检测脚本不执行问题，如果是使用的service keeplived start 或者是 systemctl 方式启动，脚本可能会不执行，可以使用 Keepalived -f /etc/keepalived/keepalived.conf方式启动Keepalived