高并发处理思路与手段(一):扩容

当一个开发人员提升计算机系统负荷时,通常会考虑两种方式垂直扩展和水平扩展。选用哪种策略主要依赖于要解决的问题以及系统资源的限制。在这篇文章中我们将讲述这两种策略并讨论每种策越的优缺点。如果你已经有一个软件系统需要不断成长,那么你将有意或者无意中选择这两种策略中的一种。

垂直扩展

在垂直扩展模型中,想要增加系统负荷就意味着要在系统现有的部件上下工夫,即通过提高系统部件的能力来实现。例如,假设你现在负责一批木材采伐的操作。

在这个例子中,我们假设有3辆卡车,每辆车一次可以运25根木材,计算花费1小时的情况下可以运送到指定地点等待处理的木材数量。通过这些数字我们可以算出我们系统最大的负荷量:

3辆卡车 * 25根木材 * 1小时=75根木材/小时

如果我们选择垂直扩展模型,那么我们将怎么做来使我们每小时可以处理150根木材?我们需要至少做以下两件事中的一件:

使每辆卡车的运输量增加一倍(50棵树每小时),或者使每辆卡车的运输时间减半(每辆卡车30分钟)。

3辆卡车 * 50棵树 * 1小时 = 150棵树/每小时

或者

3辆卡车 * 25棵树 * 30分钟 = 150棵树/每小时

我们没有增加系统的成员数,但是我们通过增加系统成员的生产效率来获得期望的负荷量。

水平扩展

在水平扩展模型中,我们不是通过增加单个系统成员的负荷而是简单的通过增加更多的系统成员来实现。也就是说,在以上运送木材的例子中,通过增加卡车的数量来运送木材。因此,当我们需要将负荷从75棵树每小时增加到150棵树每小时,那么只需要增加3辆卡车。

6辆卡车 * 25棵树 * 1小时 = 150棵树/每小时

假如我们已经选择了垂直扩展方式,那么我们想要每小时处理150棵被砍伐的树时需要怎么做呢?我们需要做到以下两方面之一:要么使每辆卡车的运输量翻倍(50棵木材一次),要么使每辆开车的运输时间减半(30分钟)。

3辆卡车 * 50棵树 * 1小时 = 150棵树/每小时

或者

3辆卡车 * 50棵树 * 30分钟 = 150棵树/每小时

在这个例子中,系统每个成员的生产力依然没变,我们通过增加更多的卡车来提高系统的能力。

扩展你的web数据库

通过对水平扩展和垂直扩展的基本了解,下面让我们来关注web系统的扩展。一个网站通常有很多组件都需要去考虑它们的扩展性,但是我通常喜欢关注处在最边缘的一个:数据库。为什么数据库是最边缘的?因为数据库通常是共享资源,是几乎所有请求最终的连接点。

你的系统是什么类型的?

在 扩展你的数据库时,你必须要问的一个重要问题是:“我所面对的系统是什么类型的?”你所面对的是一个读操作多还是写操作多的系统?读操作多的网站一般包 括:在线商城,在商城里用户大部时间是在浏览(读操作),只有少数时间在付款(写操作)、或者博客,在博客上人们大部分时间是在浏览博文(读操作),只有 少数时间是在评论或者发表博文(写操作)。相反的,关于写操作非常多的很好的例子包括:信用卡交易处理器,这个系统的主要负载时在处理记录交易(写操 作),偶尔会查找交易(读操作)、或者Google分析,主要工作实在记录业务数据(写操作),偶尔会展示分析图(读操作)。

了解你所创建的网站是什么类型的,可以在网站成长过程中帮助你选择正确的技术。

读操作扩展

如 果你的系统读操作非常多,那么通过关系型数据库如mysql或者PostgreSql来垂直扩展数据存储是一个不错的选择。结合你的关系型数据库通过使用 memcached或者CDN来构建一个健壮的缓存系统,那么你的系统将非常容易扩展。在这种模式中,如果数据库超负荷运行,那么将更多的数据放入缓存中 来缓解系统的读压力。当没有更多的数据往缓存中放时,可以更换更快的数据存储硬件或者买更多核的处理器来获取更多的运行通道。摩尔定律使通过这种方法来垂 直扩展变得和购买更好的硬件一样简单。

写操作扩展

如 果你的系统写操作非常多,那么你可能更希望考虑使用可水平扩展的数据存储方式,比如Riak,Cassandra或者HBase。和大多数关系型数据管理 系统不同,这种数据存储随着增长增加更多的节点。由于你的系统大部分时间是在写入,所以缓存曾并不能像在读操作比较频繁的系统中起到那么大作用。很多写频 繁的系统一开始使用垂直扩展的方式,但是很快发现并不能根本解决问题。为什么?因为硬盘数和处理器数在某一点达到平衡,在这个边界上再增加一个处理器或者 一个硬盘都会是每秒钟的I/O操作数成指数性增长。相反,如果对写频繁的系统采取水平扩展策略,那么你将达到一个拐点,在这个拐点之后如果在增加一个节点 都远比使用更多的硬盘来的实惠。

其他注意事项

另 一件事需要记住的是每种扩展策略下预想不到的开销。采用垂直扩展的系统将开销凡在单独的组件上。当我们去提升系统负荷时,这些单独的组件需要在管理上花费 更多。拿我们运送木材的例子来说,如果需要使每辆卡车的货运量翻倍,那么我们需要更宽、更长、或者更高的车厢。也许有的路因为桥的高度对车辆高度有要求, 或者基于巷子宽度车宽不能太大,又或者由于机动车安全驾驶要求车厢不能太长。这里的限制就是对单个卡车做垂直扩展做的什么程度。同样的概念延伸到服务器垂 直扩展:更多的处理器要求更多的空间,进而要求更多的服务器存储架。

相反的,采用水平扩展的系统将额外的开销放在系统中连接起来的共享组件 上。当我们去提升系统负荷时,共享的开销和新增加的成员之间的协调性有关。在我们运送木材的例子中,当我们在路上增加更多卡车时,那么路就是共享资源也就 成了约束条件。这条路上适合同时跑多少量卡车?我们是否有足够的安全缓冲区使得所有的车可以同时装运木材?如果再来看我们水平扩展的数据库系统,那么经常 被忽略的开销就是服务器同时连接时的网络开销(译者注:网络为各个系统的共享资源)。当你为系统增加更多的节点时,共享资源的负荷也就越来越重,通常呈非 线性改变。

综合说明

和 计算机的大多数东西一样,好的解决办法通常并不像我这里列出来的这么简单。而我在这里尝试简化这种思想用来来说明这中概念而不是讲具体的解决办法。扩展是 个困难的问题,这是个需要在实际处理的每个步骤中都要思考的问题。扩展策略没有魔法,也没有魔法般的软件帮你建立一个完整可靠的可扩展系统。就像扩展中的 其他问题一样,一个大的解决方案通常是由很多个一起协调工作的小的解决办法组成的。这需对每一个中解决方案进行精心正确的设计和开发。

原文地址:https://www.cnblogs.com/shamo89/p/9778293.html

时间: 2024-11-06 03:37:03

高并发处理思路与手段(一):扩容的相关文章

高并发处理思路与手段(四):应用拆分

比如一个股票系统有用户信息.开户.股票行情.交易.订单等,拆分后如下图所示: 原则 业务优先 每个系统都会有多个模块,每个模块又有多个业务功能:按照业务边界进行切割,再对模块进行拆分. 循序渐进 边拆分边测试,保证系统的正常运行. 兼顾技术:重构.分层 不能为了分布式而分布式,拆分过程不仅是业务梳理也是代码重构的过程,根据技术进行分层来分配工作,ui对用户体验,熟悉C和C++对服务器,熟悉数据库的对数据库,做到术业有专攻,合适的人去做合适的事情. 可靠测试 测试完毕后,才可进行下一步,每一步都要

高并发处理思路与手段(三):消息队列

一.消息队列在实际场景中的使用 流程A在处理时没有在当前线程同步的处理完而是直接发送了一条消息A1到队列里,然后消息队列过了一段时间(可能是几毫秒 几秒 几分钟)这个消息开始被处理,消息处理的过程就相当于流程A被处理;当然这只是一个简单的模型下面我们套用实际的场景来看一下,比如下单成功后发送短信提醒;如果没有消息队列我们会选择同步调用发短信的接口并等待短信发送成功,正常情况下这么做是没有问题的但是如果发短信的时候短信接口出问题了或者说调用超时了等意外情况,这个时候我们就需要设计对应的方案来解决前

高并发处理思路与手段(五):应用限流

限流就是通过对并发访问/请求进行限速或一个时间窗口内的请求进行限速,从而达到保护系统的目的.一般系统可以通过压测来预估能处理的峰值,一旦达到设定的峰值阀值,则可以拒绝服务(定向错误页或告知资源没有了).排队或等待(例如:秒杀.评论.下单).降级(返回默认数据). 限流不能乱用,否则正常流量会出现一些奇怪的问题,从而导致用户抱怨. 假设有130W到140W的数据插入到数据库中,如果没有做限流,数据库的主库会突然接收到130w的插入操作. 首先是网络上的开销,很可能直接把带宽占满,导致其他请求无法正

java web开发 高并发处理

java web开发 高并发处理 java 高并发 java处理高并发高负载类网站中数据库的设计方法(java教程,java处理大量数据,java高负载数据) 一:高并发高负载类网站关注点之数据库 没错,首先是数据库,这是大多数应用所面临的首个SPOF.尤其是Web2.0的应用,数据库的响应是首先要解决的. 一般来说MySQL是最常用的,可能最初是一个mysql主机,当数据增加到100万以上,那么,MySQL的效能急剧下降.常用的优化措施是M-S(主-从)方式进行同步复制,将查询和操作和分别在不

被神化的海量数据处理和高并发处理

http://blog.csdn.net/hawksoft/article/details/7192207 实任何简单的问题,只要规模大了都会成为一个问题,就如中国人口多,很多小问题都会变成大问题一样.但处理这种海量数据的方法无非就是分治和”人海”战术.使用人海战术的前提是问题的划分能够支持这种人海战术,其手段无非是切割(纵向,横向)和负载均衡.纵向分隔主要是按业务(功能)来分,也就是所谓面向服务架构,横向分隔方式比较多,主要依赖于所处理的对象属性,比如时间属性或者特定业务数据属性划分(比如铁路

Linux统系统开发11 Socket API编程2 多进程 多线程 高并发处理

[本文谢绝转载原文来自http://990487026.blog.51cto.com] <纲要> Linux统系统开发11 Socket API编程2 多进程 多线程 高并发处理 UDP服务器 客户端最小模型,处理字符转大写 TCP 多进程并发服务器模型,为每个客户端开启一个进程: TCP 多线程服务器模型,使用wrap函数封装 作业: ---------------------------------------------------- UDP服务器 客户端最小模型,处理字符转大写 [em

张左峰的分享 网页游戏制作技术 加密的设计思路与手段

网页游戏制作技术 加密的设计思路与手段 必备工具:Doswf 好朋友Laan开发,请自行百度搜索 今天太晚了,明天再更新内容...咔咔咔

淘宝双11促销背后高并发处理之淘宝网采用什么技术架构来实现网站高负载

转自:http://china-chill.blog.163.com/blog/static/2049210522012101782432304/ 时间过得很快,来淘宝已经两个月了,在这两个月的时间里,自己也感受颇深.下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 伸缩,高性能,高可用性的分布式互联网应用. 一 应用无状态(淘宝session框架) 俗 话说,一个系 统的伸缩性的好坏取决于应用的状态如何管理.为什么这么说呢?咱们试想一下,假如我们在session中保存

C# 多线程与高并发处理并且具备暂停、继续、停止功能

原文:C# 多线程与高并发处理并且具备暂停.继续.停止功能 --近期有一个需要运用多线程的项目,会有并发概率,所以写了一份代码,可能有写地方还不完善,后续有需求在改 1 /// <summary> 2 /// 并发对象 3 /// </summary> 4 public class MeterAsyncQueue 5 { 6 public MeterAsyncQueue() 7 { 8 MeterInfoTask = new MeterInfo(); 9 } 10 11 publi