负载均衡层设计方案之负载均衡技术总结篇

一说到关系型数据库，大家自然会联想到Oracle、MS SQL、DB2 和Mysql。在移动互联网领域，通常很多公司在走去OEI的路程。这里我们不去讨论去OEI是否是正确的，也不去讨论怎样走去OEI这条路才合理，一个不可争辩的事实是，目前很多移动互联网公司在使用Mysql数据库。

单台Mysql数据库的处理能力确实赶不上Oracle，甚至赶不上MS SQL这些商用数据库，但是我们可以为Mysql做集群来提高整个数据服务的性能。Mysql从5.1.X版本开始，就已经支持单数据节点的“表分区”功能了，但这个支持仅限于每个节点的配置，提高单个Mysql上的读写性能(还要配合底层的块存储选型，例如DAS)。而想要实现整个Mysql集群性能，就需要从更高级别实现读写分离了。

其中有一种成熟的Mysql集群读写分离的做法，是一台写节点做成Master节点(Master节点单机性能可以做得较高，后端可以使用DAS系统);然后多台读节点做成Salve节点，并接受来源于Master节点的同步日志(MySQL Replication技术)，并通过另一个LVS进行读请求的负载，而且可以再配合单个节点上的“表分区”功能。这个做法在80%以上都是读请求的任何系统上，都可以大大增强数据库系统的整体性能，如下图所示：

从上图可以看到，来源于程序的“写”操作通过一个数据源提交给了Mysql Master，而所有的读操作则通过LVS-DR模式分发给3个Mysql Salve。这里要说明几个问题：

1. Mysql Master和Mysql Salve的数据同步是通过MySQL Replication同步技术来实现的，这是一种基于操作日志的异步同步，虽然响应时间不能达到“毫秒”级，但是基本上还是很快很快的。如果不是银行系统、或者“秒杀系统”基本上可以满足事实性
2. MySQL Replication会降低Mysql Master节点的20%的工作性能，但是转移了原来Mysql Master负责的所有读操作。当然，我们以后介绍“多主”方式和使用HiveDB横向切分的时候，还会重点介绍如何提高Mysql的写性能。
3. 事实上正式的开发架构中，我们不会给程序员两个数据源，这样既不利于代码的管理，也增加了开发难度。我们会采用类似Mysql-Proxy、Amoeba之类的软件实现数据源的整个。
4. 后面在介绍数据存储层架构的时候，我还会介绍多种成熟的可靠的Mysql集群、Mysql读写分离、Mysql横向扩展方式，和读者讨论如何实现几十台Mysql节点的运行和管理。

5-2、分布式存储系统的负载均衡

分布式存储系统目前有很多，Ceph、Swift、MFS、HDFS。他们有的是基于对象存储的，有的是基于快存储的(在《标准Web系统的架构分层》这篇博文中，我对块存储、文件存储和对象存储做了较详细的介绍，后文我们还将详细介绍存储系统)。但是他们有一个或者多个主控节点(有的叫namenode、有的叫master、有的叫Metadata)，无论怎么叫，他们都有一些相同的功能：

1. 计算“数据该存储在哪里”的问题
2. 协调控制“数据是否正确存储”的问题
3. 监控“数据节点”的健康状态
4. 转移数据
5. 回答客户端“到哪里取数据”的问题
6. 。。。。。

在处理问题的过程中，这些控制节点实际上起到的就是负载分发的作用，他们的基本原理都是通过“一致性hash算法”，对“数据该存储在”哪里的问题进行分析(用来做hash的属性依据不同而已)：

5-3、更广义的负载均衡系统

相同的客流量下，银行多个窗口排队的等待时间肯定比一个窗口排队的时间短;同样的车流量，8车道肯定比6车道的通过率高;把一个任务拆分成多个任务由多个人负责处理其中的一部分，肯定比一个人做一个大任务的时间短;

负载均衡的核心思想在于分流、关键问题在于如何分流、评价标准在于分流后的吞吐量。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!