如何实现MySQL负载均衡功能（什么是服务器负载均衡）
什么是服务器负载均衡，如何实现MySQL负载均衡功能？
感谢邀请。
MySQL是一个高速度、高性能、多线程、开放源代码，建立在客户/服务器(Client/Server)结构上的关系型数据库管理系(RDBMS)。它始于1979年，最初是MichaelWidenius为瑞典TcX公司创建的UNIREG数据库系统。目前Mysql数据库也深受中小型企业的青睐。
一、负载均衡基本思路
在一个服务器集群中，尽可能的平均负载量。通常做法是在服务器前端设置一个负载均衡器（专门的硬件设备），MySQL的负载均衡，通常都离不开数据分片（把数据分割成小块，存储到不同的db节点中）、复制等操作。
在一个服务器集群中，尽可能的平均负载量。通常做法是在服务器前端设置一个负载均衡器（专门的硬件设备），MySQL的负载均衡，通常都离不开数据分片（把数据分割成小块，存储到不同的db节点中）、复制等操作。
负载均衡的主要贡献，除了均发数据库请求，还可提供管理读/写策略。在分发请求时则确定那些节点可写，可读，随即将请求发送到指定节点上执行操作。
二、实现负载均衡的方式
1、mysql读写分离
mysql复制时，产生了多个数据副本（备库），为减少服务器压力，备库用于处理读操作，主库可同时处理读写是mysql集群实现读写分离的常用策略。
由于备库的复制是异步的，无法实时同步，读写分离的主要难点也在于备库上的脏数据。通常如果使用备库进行读，一般对数据的实时性要求不能太高。对此，mysql提供了几种常见的读写分离方式，例如基于查询的读写分离、基于脏数据、基于会话等，有兴趣可继续研究。
mysql设置的读写分离，减少了主库的请求量，将大量读的操作发送给备库，实现负载均衡。
2、修改DNS
在高并发负载均衡（一）——企业架构分析和DNS中详细介绍了DNS以及DNS如何实现负载，简言之，通过n个服务器IP指定到一个域名，根据请求的不同标识特征，将请求发送给不同的IP服务器进行处理。
3、引入中间件
mysql官方提供了一个mysql负载的中间件，mysql_proxy，也需要在服务器上进行安装，修改配置文件（mysql的服务器IP）,实质与nginx类似，也是一个代理服务器。
4、利用mysql复制分流查询操作
利用mysql的主从复制可以有效的分流更新操作和查询操作，具体的实现是一个主服务器，承担更新操作，多台从服务器，承担查询操作，主从之间通过复制实现数据的同步。多台从服务器一方面用来确保可用性，一方面可以创建不同的索引满足不同查询的需要。
对于主从之间不需要复制全部表的情况，可以通过在主的服务器上搭建一个虚拟的从服务器，将需要复制到从服务器的表设置成blackhole引擎，然后定义replicate-do-table参数只复制这些表，这样就过滤出需要复制的binlog，减少了传输binlog的带宽。因为搭建的虚拟的从服务器只起到过滤binlog的作用，并没有实际纪录任何数据，所以对主数据库服务器的性能影响也非常的有限。
通过复制分流查询的存在的问题是主数据库上更新频繁或者网络出现问题的时候，主从之间的数据可能存在差异，造成查询结果的异议，应用在设计的时候需要有所考虑。
高可用负载均衡方案1、虚拟IP技术
haproxy双机互备离不开一个关键的技术，这个技术是虚拟IP，linux可以在一个网卡内定义多个虚拟IP，得把这些IP地址定义到一个虚拟IP。
2、利用keepalived实现双机热备
定义出来一个虚拟IP，这个方案叫双机热备，准备2个keepalived，keepalived 就是为了抢占虚拟IP的，谁手快谁能抢到，没抢到的处于等待的状态。抢到的叫做主服务器，未抢到的叫做备服务器。两个keepalived之前有心跳检测的，当备用的检测到主服务挂了，就立马抢占虚拟IP。
nginx负载均衡可以指定不同ip吗？
可以的。Nginx支持多组server,可以配置不同IP和端口；同时，Nginx还支持多组upstream,也可以配置不同IP和端口。
微服务架构如何实现客户端负载均衡？
考虑到微服务架构的特殊性，我以「微信」的技术架构举例，回答题主问题。
微信开发者团队最近一篇论文“Overload Control for Scaling WeChat Microservices（超大规模微信微服务中的过载控制）”透露了部分细节，主要讲述了微服务的过载控制。
基于这篇论文，本文核心要点有二。其一，解析微信的后端; 第二，解析微信五年生产化运行过程中，得到实践检验的过载控制系统DAGOR的设计思路。当然，如果你希望为自己的微服务制定策略，这是一份上手指南。
截至目前，微信后端共包含超过3000项移动服务，其中包括即时消息收发、社交网络、移动支付以及第三方验证等等。该平台每天接收到的外部请求量在 10^10-10^11次之间，其中每一项请求都会触发更多的内部微服务请求，这意味着微信后端整体每秒需要处理数亿次请求。
微信的微服务系统能够在微信业务系统中的2万多台设备上运行超过3000项服务。而随着微信的广泛普及，这一数字仍然不断增加……伴随着微信的不断发展，微服务系统一直在快速迭代并进行服务更新。举例来说，从2018年3月到5月，微信的微服务系统每天平均经历近千次变化。
微信将其微服务分类为“入口跳转”服务（用于接收外部请求的前端服务）、“共享跳转”服务（中间层协调服务）以及“基本服务”（不向任何其它服务扇出，因此可充当请求接收方的服务）。
图：微信的微服务架构
以普通的单日运行场景为例，微信的峰值请求率约为每日平均值的3倍。在一年中的某些特定时段（例如在中国的农历新年期间），峰值工作负载甚至有可能增长至每日平均值的10倍。
基于大规模微服务平台的过载控制挑战“Overload control… is essential for large-scale online applications that need to enforce 24×7 service availability despite any unpredictable load surge.”（过载控制……对于大规模在线应用程序而言至关重要，这些应用程序需要在遭遇不可预测的负载激增时实现24 x 7全天候服务可用性。）
传统的过载控制机制专门面向具有少量服务组件、“入口”相对狭窄且依赖性较为普通的场景所设计。
“… modern online services are becoming increasingly complex in their architecture and dependencies, far beyond what traditional overload control was designed for…”（…现代在线服务在架构与依赖性方面则变得越来越复杂，这远远超出了传统过载控制方案的设计目标。）
• 由于发送至微信后端的服务请求不存在单一入口点，因此在全球入口点（网关）进行集中式负载监控的传统方案将不再适用。
• 特定请求中的服务调用图可能取决于因请求而异的数据与服务参数，即使是相同类型的请求也可能存在这种差异。因此，当特定服务出现过载时，很难确定应该删除哪些类型的请求以缓解过载情况。
• 过多的请求中止（特别是在调用图中较深或请求流程内偏后的部分时）会浪费计算资源，并带来影响用户体验的高延迟问题。
• 由于微信的服务DAG（有向无环图）极其复杂且不断发展，因此用于实现高效跨服务协调的维护成本与系统开销都将超出可承受范围。
由于某项服务可能会对其所依赖的服务发出多次请求，并且有可能向多项后端服务发出请求，因此我们必须高度关注过载控制。对于调用多项过载服务或多次调用单一过载服务的情况，作者在论文中专门创造了一个新的词汇，即“后续过载”。
“Subsequent overload raises challenges for effective overload control. Intuitively, performing load shedding at random when a service becomes overloaded can sustain the system with a saturated throughput. However, subsequent overload may greatly degrade system throughput beyond that intended…”（后续过载会对过载控制机制的有效性提出挑战。直观来讲，在服务过载时执行随机减裁操作可以将系统的实际吞吐量维持在饱和状态。而后续过载则可能大大降低超出预期的系统吞吐量……）
这里考虑一个简单的场景，其中服务A对服务B进行了两次调用。如果B开始对全部传入请求中的半数加以拒绝，则服务A的调用成功率将下降至0.25。
DAGOR概述微信采用的过载控制系统被称为DAGOR，其旨在为所有服务提供过载控制功能，因此必须具有服务中立性。由于集中式全局协调将带来高昂的实现成本，因此过载控制需要以单一机器的细粒度方式运行。然而，其中还包含有处理后续过载情况所必需的轻量级机器间协调协议。最后，当由于严重过载而导致的减载变得不可避免时，DASGOR应尽可能维持服务的请求成功率。换言之，其应尽量减少浪费在失败服务任务上的计算资源（例如CPU与I/O等等）。
这里，我们有两项基本任务需要解决：检测过载情况，并在检测到过载之后决定如何加以处理。
过载检测对于过载检测，DAGOR着眼于待处理队列中各请求的平均等待时间（或者说排队时间）。排队时间的最大优势，在于能够抵消呼叫图中较低延迟的平均化影响（相较于请求处理时间等指标）。即使本地服务器本身没有发生过载，请求处理时间也有可能增加。DAGOR可采用基于窗口的监控机制，其中的容器为1秒或者2000次请求，以先到者为准。微信显然一直处在高效紧张地的运行状态之中：
“For overload detection, given the default timeout of each service task being 500ms in WeChat, the threshold of the average request queuing time to indicate server overload is set to 20ms. Such empirical configurations have been applied in the WeChat business system for more than five years with its effectiveness proven by the system robustness with respect to WeChat business activities.”（对于过载检测，假设微信中每个服务任务的默认超时为500毫秒，则表示服务器过载的平均请求排队时间阈值将设置为20毫秒。这种基于经验的配置方式已经在微信业务系统中应用了超过五年之久，其有效性通过系统对微信业务活动支持的稳健性表现得到了证实。）
接纳控制一旦检测到过载状况，我们就必须决定如何加以处理。或者更具体地讲，我们需要考量放弃哪些请求。这时，我们首先需要明确一点，各项请求之间并不是平等的：
“The operation log of WeChat shows that when WeChat Pay and Instant Messaging experience a similar period of service unavailability, user complaints against the WeChat Pay service are 100x those against the Instant Messaging service.”（微信的运营日志显示，每当与微信支付与即时消息体验相关的服务发生不可用问题时，用户对微信支付服务的投诉是针对即时消息收发服务的100倍。）
为了以服务中立性方式处理这个问题，每项请求在首次进入系统时都会被赋予一种业务优先级。这项优先级会随着所有下游请求一同继承。用户请求的业务优先级由其请求的操作类型决定。虽然存在数百个入口点，但实际其中只有几十个具有显性优先级，其它所有入口点都默认属于较低优先级。优先级设定保留在复制的哈希表当中。
图：用于存储微信入口服务内操作执行业务优先级的哈希表
当过载控制被设定为业务优先级n时，所有来自n+1等级的请求都将被放弃。这种方式对于混合型工作负载来说效果良好，但假定我们面对的是大量付款请求，而所有请求都具有相同的优先级（假定为p），那么一旦系统遭遇过载，我们就需要调整过载阈值以实现轻载，即将过载阈值变更为p-1。而一旦检测到轻载，过载阈值将再次增加至p，这时我们将重新面对过载状态。因此，要在大量具有相同优先级的请求引发超载时停止这种无意义的转换，我们需要采用超越业务优先级的细粒度调整。
微信对此拿出了一种良好的解决方案。其增加了基于用户ID的第二层接纳控制机制。
“User priority is dynamically generated by the entry service through a hash function that takes the user ID as an argument. Each entry service changes its hash function every hour. As a consequence, requests from the same user are likely to be assigned to the same user priority within one hour, but different user priorities across hours.”（用户优先级由入口服务通过以用户ID为参数的哈希函数动态生成。每项入口服务每小时变更一次其哈希函数，因此来自同一用户的请求很可能在一小时之内被分配予相同的用户优先级，但在数小时内被分配予不同的用户优先级。）
这就提供了公平性，同时亦能够在相对较长的时间周期内为个人用户提供一致的使用体验。另外，其还有助于解决后续过载问题，因为来自被分配予高优先级用户的请求更有可能在整体调用图中得到及时处理。
将业务优先级与用户优先级结合起来，即可为每个业务优先级提供配合128种用户优先级的复合接纳级别。
图：复合接纳级别
“With each admission level of business priority having 128 levels of user priority, the resulting number of compound admission levels is in the tens of thousands. Adjustment of the compound admission level is at the granule of user priority.”（由于每项业务优先级的接纳级别都包含128种用户优先级，因此其得出的复合接纳级别数量将达到数万种。对复合接纳级别的调整，能够细化至用户优先级粒度。）
另外值得一谈的是，为什么要采用用户ID而非会话ID来解决上述问题：因为如果以会话ID为解决方案，用户最终只会通过注销并重新登录的方式解决服务无影响问题，而由此带来的重新登录风暴将带来新的过载冲击！
DAGOR在每台服务器上都维持着一套关于请求的直方图，用于追踪超过接纳优先级的请求的大体分布情况。当在窗口期间检测到过载时，DAGOR会移动至另一“桶”（范围），这将使预期负载减少5%。而如果过载消失，其同样会移动至新的“桶”（范围），这将使预期负载增加1%.
服务器会在发送至上游服务器的每条响应消息中附带其当前接纳级别。通过这种方式，上游服务器将获知下游服务的当前接纳控制设置，甚至能够在发送之前即对该请求执行本地接纳控制操作。
因此，DAGOR的端到端过载控制系统将如下所示：
图：DAGOR过载控制工作流
实验DAGOR设计有效性的最佳证明，在于其已经在微信的生产环境中拥有长达五年的良好运作记录。不过这无法为学术论文提供必要的图表，因此我们进行了一组模拟实验。下图突出显示了基于排队时间——而非响应时间——的过载控制成效。在后续过载的情况下，这种收益最为明显（如图（b）所示）。
与CoDel以及SEDA相比，在进行一次后续调用时，DAGOR凭借着后续过载机制使请求成功率提高了50%。后续请求数量越大，这种收益就越是明显：
图：不同工作负载类型下的过载控制
最后，在公平性方面，CoDel在高压场景下更倾向于使用扇出量较小的服务，而DAGOR则在各类请求当中表现出大致相同的成功率水平。
图：过载控制的公平性
构建处有系统中的三项经验
即使你不打算完全按照微信的方式使用DAGOR，作者仍然总结出了三项宝贵的实践经验：
• 超大规模微服务架构下的过载控制必须在每项服务中实现分散与自治。
• 过载控制应当考虑到各种反馈机制（例如DAGOR的协调接纳控制），而非仅仅依赖于开环启发式机制。
• 应当通过对实际工作负载的处理行为进行分析，从而探索过载控制的设计思路。
多台服务器代码如何同步？
分布式：服务分散部署在不同服务器组成一个整体应用，分散压力，解决高并发。
假设访问量特别大，就可以做成分布式，将一个大项目拆分出来单独运行。跟cdn一样的机制。
Redis分布式：将redis中的数据分布到不同的服务器上，每台服务器存储不同内容。Mysql集群是每台服务器都存放相同数据。分布式部署：系统应用部署在2台或以上服务器或虚拟机上，服务间通过RPC、WCF(包含WebService）等交互，即可称作分布式部署。微服务也算作分布式的一种，反之则不然。 分布式优点: 1、将模块拆分，使用接口通信，降低模块之间的耦合度。 2、将项目拆分成若干个子项目，不同团队负责不同子项目。 3、增加功能时只需再加一个子项目，调用其它系统接口即可。 4、可灵活进行分布式部署。 5、提高代码的复用性，比如service层，如果不采用分布式rest服务方式架构，在手机Wap商城、微信商城、PC、Android、ios每个端都要写一个service层逻辑，开发量大，难以维护和一起升级，此时可采用分布式rest服务方式共用一个service层。 缺点：系统之间交互要使用远程通信，接口开发增大工作量，但利大于弊。 微服务：可单独部署运行的微小服务，一个服务只完成单一功能分散能力，服务之间通过RPC等交互，至少有一个数据库。用户量过大高并发时，建议将应用拆解为多个子系统，各自隔离，独立负责功能。缺点：服务数量大，后期运维较难。分布式、微服务区别：分布式依赖整体组合，是系统的部署方式；微服务是架构设计方式，粒度更小，服务之间耦合度更低。独立小团队负责，敏捷性更高。集群：多台服务器复制部署相同应用，由负载均衡共同对外提供服务，逻辑功能仍是单体应用。项目如果跑在一台机器上，这台机器如果出现故障，或者用户请求量比较高一台机器支撑不住，网站可能就访问不了。那怎么解决呢？就需要使用多台机器，复制部署一样的程序，让几个机器同时运行网站。那怎么分发请求到所有机器上？所以负载均衡的概念就出现了。负载均衡：将请求分发以分摊服务器压力。基于反向代理能将所有的请求根据指定的策略算法，分发到不同的服务器上。实现负载均衡常用Nginx、LVS。负载均衡服务器出现问题了怎么办？所有冗余的概念就出现了。冗余：两台或多台服务器，一个主服务器，一个从服务器。 假设一个主服务器的负载均衡服务器出现问题，从服务器能替代主服务器来继续负载均衡。实现的方式就是使用Keepalive来抢占虚拟主机。双机双工模式：目前Cluster（集群）的一种形式，两台服务器均为活动状态，同时运行相同的应用，保证整体的性能，也实现了负载均衡和互为备份。WEB服务器或FTP服务器等用此种方式比较多。实现多台服务器代码（文件）同步方案：1、负载均衡中实现代码同步rsync。2、rsync+inotify逐一文件监听并实时同步。3、实现redis共享session。nginx的负载均衡如何配置？
nginx负载均衡用于从“upstream”模块定义的后端服务器列表中选取一台服务器接受用户的请求。一个最基本的upstream模块是这样的，模块内的server是服务器列表：
#动态服务器组
upstream dynamic_zuoyu {
server localhost:8080; #tomcat 7.0
server localhost:8081; #tomcat 8.0
server localhost:8082; #tomcat 8.5
server localhost:8083; #tomcat 9.0
}
upstream 支持4种负载均衡调度算法:
A):每个请求按时间顺序逐一分配到不同的后端服务器;
B):每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。
C):按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器。后台服务器为缓存的时候效率。
D):这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。本身是不支持 的，如果需要使用这种调度算法，必须下载Nginx的 模块。
轮询：
打开 nginx 配置文件
[root@master ~]# vi /etc/nginx/conf.d/default.conf
写轮训配置
#设定负载均衡服务器列表upstream roundrobin { #后端服务器访问规则 server 192.168.1.115:8080 weight=1; #server1 server 192.168.1.131:8081 weight=1; #server1 server 192.168.1.94:8090 weight=1; #server3}server { listen 80; server_name 192.168.1.131; location / { proxy_pass http://roundrobin; } }
配置完成后
//检查 nginx 配置是否正确nginx -t //重新加载 nginx 配置service nginx reload
当访问 的时候，会把这个请求负载到 的 端口、 的 端口、 的 端口。负载的权重由 weight 来决定，默认为 1 ，weight 越大，权重就越大。
IP_hash：
#设定负载均衡服务器列表upstream roundrobin { #后端服务器访问规则 ip_hash; #添加参数支持哈希 server 192.168.1.115:8080 weight=1; #server1 server 192.168.1.131:8080 weight=1; #server1 server 192.168.1.94:8090 weight=1; #server3 } server { listen 80; server_name 192.168.1.131; location / { proxy_pass http://roundrobin; } }
down，表示当前的server暂时不参与负载均衡。backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因 此这台机器的压力最轻。#设定负载均衡服务器列表upstream roundrobin { #后端服务器访问规则 server 192.168.1.115:8080 weight=1; #server1 server 192.168.1.131:8080 down; #server2 不参与负载 server 192.168.1.94:8090 backup; #server3 备份机 }server { listen 80; server_name 192.168.1.131; location / { proxy_pass http://roundrobin; } }
