负载均衡 + 分布式数据库

关注
发布于: 2020 年 07 月 18 日
负载均衡架构负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
负载均衡实现方式HTTP重定向负载均衡
用户的http请求通过负载均衡服务器返回的http请求响应头，重定向到所要访问的应用服务器地址。访问过程中先要和负载均衡服务器建立连接，然后再和应用服务器建立连接。一共有两次http通信对用户端的网络消耗比较大同样耗时较长。比较致命的缺陷是应用服务器的地址直接暴露在公网存在安全问题。补充一张OSI（Open System Interconnect）七层模型和TCP/IP四层概念模型图对比。
DNS负载均衡
有DNS（域名解析服务器）负载维护应用服务器网络地址列表。用户可以直接与应用服务器建立连接，相对于HTTP重定向负载均衡将通信次数下降为一，但同样存在安全问题。此外应有服务器地址维护在DNS中如果服务出现当机情况，即使变更了服务器列表的配置也无法保证用户的客户端程序中保存的服务器地址的有效性，所以对于高可用的应用来说是不可取的。
反向代理负载均衡（7层负载均衡）
反向代理服务器实现代理处理用户端的请求，代理服务器接受到请求后将请求转发至应用服务器处理返回结果，再由反向代理服务器返回给用户。此种实现方式比较简单，也比较常用。但是对于高并发的应用来说会受到单个代理服务器的性能限制。数据传输的HTTP协议的包也比较重。
IP负载均衡（3层负载均衡）
IP负载均衡是属于OSI七层协议中的网络层的负载均衡，性能会比应用层的负载均衡要高。IP负载均衡服务器接受到用户请求之后通过解析用户请求的目标ip地址（TCP/IP的数据协议包中）然后将目标ip地址修改为应用服务器ip地址，将源地址修改为自己的IP地址。然后将请求转发到目标应用服务器上，由应用服务器解析http协议进行处理。应用服务器将处理结果返回给负载均衡服务器，负载均衡服务器将数据包目标地址和源地址修改为用户真实地址将数据返回。处理能力不是瓶颈，出口的网络带宽容易出现瓶颈。如：一张1M照片，在千兆网卡下每秒最多返回多少张照片？1000Mbps=1,000,000,000比特/秒=125,000,000字节（1字节B=8比特位b）/秒=125MB/s。
数据链路层负载均衡（2层负载均衡）
负载均衡均衡服务器与应用服务器共享一个虚拟的IP地址，负载均衡请求的mac地址修改为应用服务器的的mac地址。应用服务器处理完成之后将请求直接返回给客户端不需要经过负载均衡服务器。因为在网络层上客户端是与应用服务器直接通信的。
负载均衡算法轮询：所有的请求被依次分发到每个应用服务器上，适于所有服务硬件相同的场景。
加权轮询：根据应用服务的硬件性能，在轮询的基础之上。按照配置的权重将请求分发到每个应用服务器。
随机：请求被随机分配到每个应用服务器。
最少链接：记录每个应用服务器正在处理的连接数，将新的请求分发到做少连接的服务器上。
源地址散列：根据请求来源的ip进行hash计算，得到应用服务器。该算法保证同一来源的请求总在同一个服务器上处理。实现会话粘滞。
应用服务器集群的Session管理session 管理的主要几种手段
session复制（应用服务器直接同步session信息）
session绑定（session与固定的应用服务器引用程序绑定，应用重启后session丢失）
利用cookie记录session（http协议中的一部分，增加网络开销。）
session 服务器（专门的服务器处理session 如 Redis）
分布式数据库MySql 主从复制执行顺序（如图）
客户端发生update命令更新数据库同时将update执行命令写入Mysql的本地Binlog日志文件中。
Mysql主服务器启动一个客户端程序获取Binlog中的执行命令，并与从服务器进行网络通信。
从服务器获取到主服务器的执行命令，将命令追加到Mysql的Relay Log 日志文件中。
从服务器的SQL执行线程将Relay Log 中的执行命令按照顺序执行到本地数据库中完成数据同步。
 实践过程中 DDL（数据声明语言）不建议同步，执行过程时间过长产生阻塞。导致数据不一致。 
一主多从复制优点：分摊负载，专机专用，便于冷背，高可用。
缺点：主服务器当机，整个服务不可用。
MySql 主主复制执行顺序（如图）
客户端更新数据操作主服务器A的本地数据，并将执行命令追加到Binlog日志文件中。
主服务器B与主服务器A保持通信，主服务器B并将A中执行命令追加到Relay Log日志文件中。
主服务器B的SQL执行线程将Relay Log 中的执行命令按照顺序执行到本地数据库中，完成主服务器A到主服务器B的复制工作。主服务器B到主服务器A的复制工作同理。
主主复制并是为了支持双写的。负责会出现数据冲突。
主主失效恢复执行顺序（如图）
客户端数据的写操作会写入主服务器A，主服务器A同时将数据复制到A的从服务器和主服务器B中
当主服务器A失效的时候，所有的写操作会切换到主服务器B上。
主服务器B接受写服务并将dml语句添加到Binlog 日志文件中。
主服务器A恢复后，会将主服务器B的中的数据复制到主服务器A中。恢复完成后主服务A正常工作。
Mysql 复制注意事项主主复制两个数据库不能并发写入
复制只能增加了数据的读并发处理能力，并没有增加写并发能力和存储能力
更新表结构会导致巨大的同步延迟
数据分片当一张表的数据量已经超过了一个服务器的存储能力的时候或数据的并发写入一台服务器无法承受。需要考虑将一张表拆分成若干片，部署在不同的服务器上来提高存储能力和并发写入能力这就是数据分片。
硬编码实现数据分片用户表的写入操作时，可按照用户id进行取模运算（3%2=1 or 3%3=0），所得到的余数(1,0)对应服务器地址。这样就可以将数据写入不同的服务器上了。
映射表外部存储用户表的写入操作时，可将userId与服务器建立一个映射关系。每次写入需要查询映射关系表中的对应的服务器结点信息。返回给应用程序，然后有应用程序进行数据写入。产生的问题有映射表会是一个非常大的表。映射表的读写速度也会成为瓶颈。
数据分片的挑战需要大量额外代码，处理逻辑因此会变得更加复杂。
无法执行多分片的联合查询。
无法使用数据库的事物。
随着数据的增长，如果增加更多的服务器。
分布式数据库中间件（Cobar）系统组件
     前段通信模块，sql解析模块，sql路由模块，sql执行代理模块，后端通信模块，结果合并模块。
服务器选择的路由配置。（hash(key)%2）余数hash方式选择服务器。
如何作集群的伸缩，扩容的策略。
余数hash策略：一个数据库实例中创建多个数据库，假设一个存在12个分片，当前有三台数据库实例。每一个数据库实例均匀分布4个数据库分别为 Schema0～11。如果需要新增一个数据库结点，分片规则不发生变化还是 hash 对 12 取余数。只需要改变 取余后的结果对应的url地址修改成新的地址即可。先将数据库迁移到新的数据库机器上再进行切换。
﻿
数据库部署方案单一服务与单一数据库
主从复制实现伸缩
两个Web服务及两个数据库
综合部署方案
总结架构的演变过程中应用服务高可用，高性能的要求得到满足的同时，就会同时对数据库也提出同样的要求。系统架构每个阶段面对的问题不同，解决方案也不同。分布式缓存，分布式应用服务，分布式数据库。只是实现系统高可用，高性能的手段。并不是应用了就能带来好处，作为架构者投入产出比也很重要。有的时候当火烧的小一点的时候扑灭它比提前预防火灾更重要。