一种面向高负载Sakai 系统的性能优化方案

罗贵章

(1.广西大学计算机与电子信息学院，广西 南宁 530004;2.百色职业学院，广西 百色 533000;3.百色市机电工程学校，广西 百色 533000)

0 引言

Sakai［1］是由美国印第安纳大学、密西根大学、斯坦福大学和麻省理工学院发起的一项开源课程与教学管理系统开发计划［2］。Sakai 的核心是交互，包括学生与学生交互、学生与教师交互以及学生与学习资源交互。虎二梅［3］等使用Think Aloud 测试结合访谈法和观察法，对Sakai 平台的可用性进行深入的测试和研究，发现Sakai 平台存在可用性问题，大量用户并发访问时候的响应速度慢。Sakai 是典型的Web应用系统。吴锐［4］基于Nginx 融合页面压缩构建了高性能的静态页面Web 系统。王亚楠［5］等针对高并发的Web 系统，通过前端资源压缩以及延迟加载，以及后端数据分页和缓存技术，实现了高并发的Web系统。谢杰涛［6］等针对Web 缓存压力，提出了一种基于定期更新和请求驱动更新的本地数据缓存机制，应用程序能够根据待存储数据的特点选择合适的缓存方式。针对关系数据库在非结构化数据存储上的不足，MongoDB 等NoSQL 数据库被应用于高性能Web 系统中［7］。针对Web 服务器的阻塞通信方式的不足，刘伟［8］等通过异步I/O 的方式构建高性能Web 服务系统。

本文在前人Web 系统相关工作基础上，针对高负载Sakai 系统的特定情况，提出基于Linux 集群的优化方案，通过HAProxy 实现负载均衡和热备，并实现了主从/读写分离的MySQL 架构。通过实验验证，该系统具有良好的负载均衡、响应能力以及数据库读性能。

1 系统架构

图1 显示了本文提出的针对Sakai 在线协作学习系统特性的、具有高可用性的Linux 集群的架构。主要配置包括:前端基于HAProxy［9］和Keepalived［10］的负载均衡器、NFS 集群、Apache 集群、Session 共享结点(Memcached［11］)、MySQL 数据主从备份、MySQL 从服务器负载均衡层。

图1 高可用的Linux 集群架构

2 负载均衡设计

在线协作学习系统主要应用部署于Web 服务器上。如果仅设置单个Web 服务器作为应用服务器，显然无法满足海量访问请求的冲击。于是本文提出了搭建Web 服务集群的方案，多个结点同时提供服务。

简单地增加Web 服务器是不可行的。服务器增加后，出现了访问请求的分发问题，即负载均衡问题［12］。如果负载均衡做得不好，会出现某些结点一直处于重载状态，甚至导致宕机。而另外一些结点在同一时刻可能处于空闲状态，造成资源的分配严重不合理［13］。因此，本文提出了基于HAProxy 的负载均衡集群。

图2 HAProxy 负载均衡

图1 中的Load Balancer 即为系统中的Web 服务器负载均衡层。如图2 所示，显示了HAProxy 的配置架构。HAProxy 作为前端直接面向外部网络，提供请求代理分发服务。而应用服务器则是作为后端，专注于业务系统，与前端耦合度为0。下面通过HAProxy的配置文件对负载均衡架构进行分析。本系统架构包括3 台Web 服务器，其内部IP 地址分别为172.18.16.2，172.18.16.3 和172.18.16.4。其中部署了2 个Web 应用:sakai_portal 和sakai_resource。HAProxy 工作的层次配置在HTTP 层。通过负载均衡机制，3 台应用服务器可以根据权重获得指定份额的访问请求，达到高并发和高可用性的目的。

3 热备机制

在图1 中，HAProxy 结点使用了热备机制，保证负载均衡结点的高可用性。采用的是Keepalived 作为备份监控工具。双机热备的模式有2 种:Active-Standby 模式和Active-Active 模式。Active-Standby 模式下，只有一个可用的虚拟IP(对外IP)。一个结点对外提供服务，称为MASTER 结点，该结点持有虚拟IP。而另一个结点只作为备份结点，不对外提供服务，称为BACKUP 结点。当MASTER 结点不可用时，BACKUP 结点接管虚拟IP，进而接管MASTER 结点服务，如图3 所示。

图3 主-备模式热备方案

主-备模式下，MASTER 结点一直处于工作状态，而BACKUP 结点永远处于备用状态，这无疑给系统造成了资源较大浪费。双主模式(Active-Active)下，2个服务器都处于工作状态。如图4 所示，此时需要分配2 个虚拟IP 地址，Node#1 配置为192.168.1.1 的虚拟IP 为MASTER 结点，192.168.1.2 为BACKUP结点;而Node#2 则与Node#1 完全反过来。这样2 个结点互相认为对方是自己的后备结点，自己是主结点，从而实现了两者的互备关系，形成了双主模式。

图4 双主模式热备方案

主-备模式的切换算法如图5 所示。

图5 主-备模式的切换算法

由图5 算法ACTIVE-STANBY-FAILOVER 可知，主备模式的双机热备机制，在失效切换时，只需要将虚拟IP 漂浮到后备结点，并由后备结点接管所有已失效的主结点的连接，然后广播消息即可完成。双主模式的切换算法与主备模式的切换算法基本一致，只不过切换完成之后，仍然可用的结点拥有2 个虚拟IP地址，既充当Master 又扮演Backup 的角色。所有的连接都由该结点接管。

4 Session 共享

当Web 应用的业务规模和流量增大时，单台服务器组成的网站架构是无法满足发展需求的［14-15］。如图1 所示的架构中，通过配置多台Web 服务器，构建应用服务器集群，让多台服务器分摊高压状态下的请求量，从而提高系统吞吐能力、并发能力，进而增强了系统的高可用性。但是跨服务器的应用会产生Session 共享的问题，解决Session 共享问题变得非常重要。Session 共享的解决方案通常由以下几种:基于Cookie、基于数据库、基于内存共享系统。内存共享系统内存中的HashMap 具有数据淘汰机制，完全符合Session 的过期机制。由于Sakai 的Session 数据量较大，综合数据量和I/O 压力，本文采取了基于Memcached 的Session 共享机制。

5 主从/读写分离的数据库架构

随着业务量增加，数据库读写压力随之增加，存储设备I/O 负载提高［16］。提高数据库的读写性能通常的做法是:1)增加数据库缓存;2)采用一主多从式结构，将读和写分离;3)业务数据分库处理。如图6所示，本文针对在线协作学习系统具有大量“站点”和内容资源的特性，提出数据库高可用的架构。主结点的MySQL 实例只负责整个数据库系统的写操作。从结点可以有多个，根据系统需求可以灵活扩展从结点数量，而不会对原有系统造成任何影响。从结点只负责数据读服务。显然，对于大多数Web 应用，绝大多数请求都是对资源读取的请求，要求写数据库的请求只是少数。因此，单个写结点、多个读结点正符合这种规律。多个从结点将极大地提高数据库的并发读能力。

图6 主-从架构读写分离MySQL 集群

多个从结点同时提供读服务，就会产生负载均衡问题。因此，对于从结点多于2 个时，需要加入负载均衡机制，保证Slave 集群高效、稳定运行。

6 实验分析

由于实验条件的限制，本文所设置的实验环境的服务器配置相对较低，服务器数据为4 台，通过虚拟化实现多台虚拟服务器。其中，3 个Web 服务器共用1 台实体服务器，Memcached 和NFS 共用1 台实体服务器，MysQL 集群共用1 台实体服务器，而HAProxy共用1 台实体服务器。Web 服务器的性能测试采用的是压力测试工具Apache Jmeter［17］。

6.1 负载均衡

当服务器的配置相当时，通过HAProxy 负载均衡层处理之后的请求，理论上应平均地根据服务器的配置和负载状况，分发到各个服务器上。如图7 所示，显示了服务器连接的分发结果。显然，由于Sakai 平台请求基本上都是短连接请求，因此可以近似地认为每个服务器接收到的连接处理的平均时间相等。从实验结果可以看出，实验用的3 台Web 服务器在经过负载均衡层后，所分配得到的连接数量相差不大。因此，从连接分配这个角度说明原型系统应用了高可用Linux 集群之后的负载均衡有了一定效果。

图7 服务器连接分发平衡性

图8 显示的是各服务器在测试过程中CPU 空闲率的对比。显然，3 个服务器的CPU 空闲率很接近，这是由于3 台服务器的硬件配置是相同的，并且负载均衡层分配到的连接请求数量均衡，因此得到的结果如图所示。

图8 服务器CPU 资源的空闲率对比

6.2 响应时间

如图9 所示，在大量读操作情况下，HAProxy 的负载均衡机制实现多个服务器并行对外提供读服务。系统的读取响应时间较小，并且随着请求压力的增加，响应时间没有呈现暴涨的状况。而无负载均衡的情况则随着请求量增加，出现了响应时间急剧增加的状况;尤其是达到16 000 次左右请求时候，服务器对请求的增加极其敏感。请求量达到30 000 次之后，服务器响应出现了大量的超时现象，而达到100 000次之后，基本上停止响应。

图9 大量多读操作下的响应时间对比

如图10 所示，针对大量读操作应用场景进行测试。通过实验结果发现，写请求很显然比读操作耗费系统资源。在无负载均衡层的情况下，系统响应时间较早地进入了快速增加的阶段，请求量达到1 000 次左右，就急剧增加，到2 000 次时，增速又一次提升。此时的服务器对新增请求非常敏感了，少量的请求量增加就会导致响应实现的大幅增加，请求量达到6 000 次时就出现大量的连接超时。HAProxy 的架构在本测试中，在写操作达到3 000 次之前响应时间都较为稳定，没有出现较大的增加。但达到3 000 次后就出现了响应时间增加的现象，此时的服务器总的计算能力接近满载荷。此后服务器虽然仍然有能力处理增加的请求量，但是由于服务器的I/O 能力已经达到了瓶颈，虽然有负载均衡器的作用，仍然无法避免响应时间陡增。负载均衡器的作用，还是使得在响应时间虽然增加的情况下，仍然比无负载机制的情况要小很多。

图10 大量写操作下的响应时间对比

6.3 数据库读写性能

前文给出了针对原型系统的高可用数据库的架构，即主从、读写分离的MySQL 集群，并为负责读操作的Slave 结点集群加入负载均衡层，以实现高效的读取操作。

由于Sakai 这类在线协议学习系统与大多数常规的Web 应用系统类似，都是以大量的读请求居多，写操作请求相对较少，因此，针对该特性提出重点加强读操作的并发能力的要求。本文的原型系统读操作的预期要比非读写分离的架构有较大性能提升，而读操作预期性能则与非读写分离架构相当，甚至可能要差于后者(由于Slave 结点需要同步，故引发Master结点I/O 任务加重)。

图11 数据库读操作性能对比

如图11 所示，对比了MySQL 数据库集群非读写分离结构(ds)和主从读写分离结构(ds(LB))的读性能。读写分离的结构应对数据库连接量的增加，其读取操作的延迟并没有巨大的增加，而维持在20 ms 左右。非读写分离结构随着数据库连接增加，延迟明显增加。并且主从分离结构的查询延迟明显低于前者，这是由于Slave 结点并发的响应读操作。本实验环境下的Slave 结点数量为3，并且是虚拟机环境而非实体服务器，而非读写分离的服务器是单个实体服务器。在这种配置下，读写分离的结构就已经达到接近非读写分离结构的3 倍性能，生产环境下其性能将更加优秀。

从图11 的实验结果还可以看出，如预期的那样，数据量的增加，对查询的性能的影响并不大。由于关系数据库使用了各种优秀的索引技术和缓存技术，在服务器内存可以承受的范围内，增加数据库记录的数量，会使得索引数据增加。但对于查询的性能并不会受到很大影响。因此，实验结果中，不管是主从读写分离结构还是非分离结构，数据量增加的查询延迟增加不大。

如图12 所示，在数据库写操作的性能对比中，可以看出主从读写分离架构的写操作性能并不比单点的架构优秀。从本架构和相关分析可以知道，主从架构的主结点只负责用户的写请求，如果仅此而已其性能理论上会比单点架构要优越。但是主从架构的一个重要操作就是主结点与从结点的数据同步操作。如果系统要求是强一致性，那么一个写操作到达时，必须按照一致性要求，保证从结点是最新的数据，同步操作就会耗去一定的时间。因此，从实验的结果来看，主从结构的写性能，稍差于单点结构。其中的另一个因素与本实验环境配置有关，因为主从结构的实验室在虚拟机环境下实现，而单点结构则是实体机。

图12 数据库写操作性能对比

从本节的实验结果可以得出，主从读写分离的结构极其适合于读密集型的Web 应用或其他类似应用，但是对于写操作要求较高的(写密集型)应用，则应适当地调整结构。

7 结束语

本文针对开源在线协同学习系统Sakai 在高负载应用场景下，产生服务质量不稳定、可靠性低的问题，提出了基于Linux、HAProxy、Keepalived 以 及Memcached 的性能优化方案。该方案在外围接口采用HAProxy 进行第一级别的负载均衡。Memcached失效Web 服务器的Session 共享机制。在MySQL 数据库性能提升上，采取“一主多从”架构，并且进行读写分离，在MySQL 读服务器上融合了HAProxy 负载均衡，最终构成了适合高负载Sakai 系统的架构。实验表明，本方案在Web 服务器负载均衡、响应能力以及数据库读性能上表现良好，但在数据库写性能上仍有待提高，这将是笔者未来工作的方向。

［1］Sakai.Sakai Project Homepage［EB/OL］.http://www.sakaiproject.org/，2014-09-05.

［2］朱珂，刘清堂.Sakai 网络教学平台应用的影响因素探究［J］.中国远程教育，2013(15):71-74.

［3］虎二梅，郭玉清，马海夫.开源教学平台的可用性研究——以Sakai 为例［J］.数学的实践与认识，2013，43(2):138-144.

［4］吴锐.高并发Web 系统的设计与应用［J］.电脑知识与技术，2013，13(9):3049-3052.

［5］王亚楠，吴华瑞，黄锋.高并发Web 应用系统的性能优化分析与研究［J］.计算机工程与设计，2014，35(8):2976-2981.

［6］谢杰涛，吴敏，吴娟，等.Web 系统高性能本地数据缓存实现机制［J］.计算机应用研究，2014，31(7):2074-2077.

［7］张文盛，郑汉华.基于MongoDB 构建高性能网站技术研究［J］.吉林师范大学学报(自然科学版)，2013，34(1):123-127.

［8］刘伟，杨慧勇，乔建，等.使用异步I/O 构建高性能Web服务器［J］.科技创新与生产力，2013(1):83-85，88.

［9］HAProxy.HAProxy Homepage［EB/OL］.http://www.haproxy.org/，2014-06-23.

［10］Keepalived.Keepalived Homepage［EB/OL］.http://www.keepalived.org/，2014-06-23.

［11］Brad Fitzpatrick.Distributed caching with memcached［J/OL］.http://www.linuxjournal.com/issue/124，Linux Journal，2004(124)，2004-08-01.

［12］Wei W，Dong S，Zhang L，et al.Animproved ganglia-like clusters monitoring system［M］// Grid and Cooperative Computing.Springer Berlin Heidelberg，2004:89-96.

［13］Liang Z，Sun Y，Zhang L，et al.Reverse auction-based grid resources allocation［M］// Agent Computing and Multi-Agent Systems.SpringerBerlin Heidelberg，2006:150-161.

［14］卢旭，程良伦.ASP 和ASP.NET 共享Session 状态研究［J］.计算机应用与软件，2009，26(6):54-56.

［15］张颖楠，顾乃杰，彭建章，等.一种内核级多进程负载均衡会话保持方法［J］.计算机工程，2014，40(3):76-81.

［16］刘毅，王峰，周子健.主从模式研究所群组集成知识平台设计与实现［J］.现代图书情报技术，2012，28(7/8):6-12.

［17］Apache.Apache Jmeter［EB/OL］.http://jmeter.apache.org/，2014-06-23.