知识点
相关文章
更多最近更新
更多影响可扩展性的十宗罪
2019-03-27 01:11|来源: 网路
第一宗:磁盘I/O慢,使用RAID5,使用多租户EBS
磁盘是所有服务器的基础,也是服务器性能性能的基础。虽然主内存变得越来 越大,很多都可以作为缓存使用,但是服务器仍然需要不时从磁盘上读取数 据,从内存清出数据。所以磁盘对于性能和可扩展性非常重要。
Raid 5有什么问题?
Raid 5是为了用更少磁盘提供更多的空间。常常用于磁盘插槽比较少的服务 器,或者就是因为运维人员不知道它对性能的影响有大。在数据库服务器上用 会特别不好。
所有的写操作都会影响性能。更大的问题在于:如果你失去了一块磁盘,虽然 RAID原则上还在线,但是会巨慢无比,就跟掉线了一样。重建需要耗费N多小 时。更糟糕的是:在重建过程中,可能会有另外一块磁盘也失效。要是你刚订 购磁盘要好几天才能到,那该怎么办?
解决方案是采用RAID 10。每两个磁盘做镜像,然后对它们做Stripe操作。即使 只有四个硬盘插槽,这么做也值得。读写性能都很好,并且有保护。
多租户的问题是尼玛怎么回事?
在云上,可以共享服务器、网络和磁盘,就像共享某间公寓一样。Amazon的 EBS(Elastic Block Storage,弹性块存储)是对这个比喻的扩展,为你提供存 储网络令人欣喜的灵活性。但是你的瓶颈就是:与其他租户争抢同一个存储网 络。
Amazon提供的默认服务器存在这个问题,不过AWS解决了这个严重的问题, 用一个不太为人熟知但是超级有用的特性——Provisioned IOPS。用它你可以 锁定可靠的磁盘I/O。
第二宗:用数据库处理队列
MySQL在很多地方都做得很好,但是在处理应用程序排队方面却并不理想。你 的数据库中是不是有类似JOBS这样的表,其中有一个状态列,包括“queued”、 “working”、“completed”这样的值。如果是,你可能把数据库来处理应用中的队 列工作了。这样使用MySQL不好,因为会出现锁的问题,还有查找下一个任务 时的搜索和扫描任务也会遇到麻烦。
建议使用RabbitMQ或者Amazon的SQS方案,因为这些外部服务更容易扩展。
第三宗:用数据库进行全文搜索
Oracle提供全文搜索支持,为什么MySQL却不能用呢?MySQL确实有这项功 能,但是在很多版本中,只能配合老的MyISAM存储引擎使用。最好采 用Apache Solr等经过验证的搜索解决方案,它专门用作搜索,有非常好的库, 开发者可以使用多种现代web语言进行开发,并且非常容易扩展。只要在网络 中增加服务器,或者做整体分布即可。
对于前沿技术感兴趣的同学,MySQL 5.6中提供了Innodb的崩溃安全和事务存 储引擎。既便如此,还是建议使用外部解决方案,如Solr,或者Sphinx及 MySQL Sphinx SE插件解决。
第四宗:每个层次的缓存不够
缓存,缓存,及更多的缓存。在web服务器和数据库之间可以使用memcache 或者其他对象缓存机制。所有这些小结果集将会主流在内存中,等待未来需要 它们的web页面。
也要考虑使用varnish这样的页面缓存,它位于web服务器之前,不妨将其看成 一个迷你web服务器,处理很简单的页面,但是速度非常快。就像在堵塞的道 路上开摩托车,让你的web服务器加速以完成更复杂的工作。
浏览器缓存也非常重要,但是你无法控制用户的浏览器,也许你可以?当然不 是直接控制,但是你可以指导他们缓存哪些东西。还要使用合适的过期报头。 让你的管理员配置Apache来支持这一点。
第五宗:太多技术欠债
技术欠债总有一天要还的。这是什么?探索新的点子,你会搭建一个原型。当 这个原型已经部署给客户使用之后,要修改就变得更困难,因为某些问题可能 有些东西还得掩盖起来。一个团队离开,另外的人接手这个应用,问题变得更 复杂。随时间推移,你的技术债务不断积累,团队会花更多时间去维护老的代 码以及修复bug,开发新功能的时间会越来越少。在某个时候就有必要重写代 码了。
第六宗:对象关系映射器
ORM很受开发人员的欢迎,但是对于性能专家来说却不是这样。为什么会这 样?原因主要是由于这两类人看待web应用视角不同。一种是功能开发,以满 足业务需求作为考察的结果。性能和可扩展性在这种情况下往往位于较低优先 级。ORM能让开发者更有效率,通过后端的数据存储将SQL的交互难度抽象出 来,让开发者将注意力集中在功能的开发上。
从性能角度出发,看到的是另外的场景。如果用ORM实现SQL查询,数据库将 无法优化复杂的查询。而且ORM不允许对查询的简单调整,拖慢调优过程。
第七宗:同步、串行、耦合或锁定进程
在web应用里,锁相当于现实世界中的交通信号灯。如果将交通灯换成环形交 通枢纽可以显著提升流量。因为如果你去一个交通流量很小的地方,没有人会 在交通灯下做无用的等待。更重要的是:如果有车流量很大,环形枢纽可以让 车辆保持流动。如果需要锁,最好使用InnoDB数据表,因为它们能提供粒度更 细的行级锁定,而不是MyISAM的表级锁定。
要避免出现等待其它节点消息而无法执行程序的半同步复制。在高事务并发的 web应用中,成千上万的并发会话会导致这种等待的增加。
避免任何类型的两阶段提交机制。多阶段提交提供了一个串行入口,让多个节 点投票决定数据应该是什么样子,但是它们是扩展性的毒药。最好使用采取最 终一致性算法的技术。
第八宗:只有一份数据库拷贝
如果没有复制机制,那么你的数据库就只有一份。所有的web服务器只能使用 唯一的后端数据存储,它就会成为漏斗或瓶颈。
第九宗:没有定量衡量标准
没有衡量标准是可扩展性的一剂毒药,因为你无法以可视化方式看见系统中发
生了什么。没有可视化的线索,业务部门、开发者和执行团队很难对扩展性方 面的问题达成一致。如果团队认识不到这一点,要让大家理解:这些简单的工 具可以提供基础设施的分析。
第十宗:缺乏功能标志
应用程序如果缺乏功能标志,会很难实现优雅升级。如果你的网站流量猛增, 而你不能施展魔法来扩展和提升流量,有内建的功能标志,运维团队就可以在 不让网站宕机的前提下,降低服务器负载。你也得以有更多时间来扩展web服 务器或是数据库,甚至是改进你的应用,允许同时读写多个数据库。
不提供这些开关,扩展性和可用性就受到了很大限制。
转自：http://www.cnblogs.com/fanelephant/p/3216567
相关问答
更多-
java中多态如何实现程序的可扩展性[2022-07-23]
C++中：用基类的引用指定派生类的对象，然后通过该引用来访问派生类的方法，这是基本的多态形式。（Java中用的接口的概念） 这样的好处是，程序的已知流程在没有派生类的时候就可以写好，以后要有新的功能，只要再写个派生类就可以了。举个例子，在电脑上显示图片，基本上要有读文件，解析文件，显示图形三个步骤，这些步骤可以写在基类中，然后具体的如何读文件，如何解析文件，如何显示，就交给派生类去做。 -
ZeroMQ的可扩展性如何？(How Scalable is ZeroMQ?)[2023-09-14]
我们尽量使其尽可能地扩展，但我个人仅在最多16个核心盒上进行了测试。 达到这个极限我们已经看到几乎线性缩放。 We've tried to make it as scalable as possible but I personally tested only on up to 16 core boxes. Up to that limit we've seen almost linear scaling. -
Oracle的RAC体系结构是可扩展的，它可以在节点间进行负载均衡，并行查询可以拆分并推送到其他节点进行处理。 一些技巧就像从另一个节点的缓冲区缓存加载块而不是磁盘，使性能更具可扩展性。 此外，RAC的滚动升级可维护性有助于使大型系统的运行更加健全。 可伸缩性还有一个不同方面 - 存储可伸缩性。 ASM增加了存储容量，非常简单。 一个精心设计的基于ASM的解决方案，应该可以超过100兆兆字节的大小，而不需要做任何特别的事情。 这些是否使Oracle比其他RDBMS更具可扩展性，我不知道。 但是我想我会对尝试 ...
-
可扩展性是程序扩展的能力。 例如，如果您可以在一个小型数据库（比如少于1000个记录）上执行某些操作，那么高度可扩展性的程序可以在一个小的集合上运行良好，并在一个大集合上运行良好（比如说数百万或数十亿条记录）。 像差距一样，资源需求将呈线性增长。 查看Big-O符号，以获取有关程序如何需要更多计算的更多详细信息，数据输入越大。 像大O（x ^ 2）这样的抛物线像大的x输入效率远远低于像Big-O（x）这样的线性像素。 Scalability is the ability of a program to sc ...
-
.NET Web服务的可扩展性(Scability of .NET webservices)[2022-12-08]
性能与可伸缩性分开。 可伸缩性意味着您可以添加更多服务器以线性增加系统吞吐量（即更多客户端连接）。 最好的方法是使用无状态Web服务。 这样任何客户端都可以在n台不同的机器上调用任何n个webservice。 如果最后有一个共享数据库用于持久性最终将成为你的瓶颈。 有一些方法可以通过数据分区和分片来减少这种情况，但只有在达到这一点时才能实现。 Performance is separate from scalability. Scalability means that you can add more s ... -
MEF当然有很多优点，大部分都是你提到的......可扩展性，模块化，生命周期管理以及我想要的第一类框架中的任何其他东西。 它也随框架一起提供，因此没有什么可以做的，你知道它将在各个实现中保持一致。 它在VS 2010中使用，所以在游戏中没有更广泛使用的现实世界的例子。 MAF并不是一回事。 它非常特定于System.AddIn，并且有一些更严格的要求和合同要满足。 话虽如此，它还专门针对某些人可能想要的特定类型的可扩展性。 如果我有一个非常小的占用空间或应用程序，只是不需要所有额外的开销，我只会采用自定义 ...
-
芝麻可扩展性(Sesame scalability)[2021-12-09]
有几种方法可以扩展。 我不会在这里给你一个关于所有可能性的完整概述，而是给你一些指示。 单个芝麻本机商店在典型硬件上可扩展至约1亿至1.5亿个三元组。 除此之外，你可以使用第三方芝麻兼容的商店，如USeekM，Bigdata，CumulusRDF或OWLIM（可以很好地扩展到数十亿的三元组），或者你可以使用Sesame自己的Federation SAIL 。 联合成员可以是与Sesame兼容的存储的任意组合，包括本地运行的本机存储或可通过HTTP访问的远程存储。 Federation SAIL使用简单的依赖 ... -
何时设计可扩展性？(When to design for scalability?)[2024-02-10]
首先简单地设计模型，为其构建单元测试，然后在其上设置表示层。 只要您的模型合理，就可以轻松扩展播放到任意数量的机器。 如果您在JPA支持中进行构建，则可以始终处理要使用哪个DB的问题。 你的盘子上暂时有更大的东西。 因此，只需确保您的设计一致且合理，然后缩放不会成为问题。 Start out by simply designing you model, build unit tests for that and then set your presentation layer on top of it. A ... -
当我想到“大规模应用程序”时，我想到了三个截然不同的东西： 跨越大型横向扩展群集（远远大于1024个内核）的应用程序。 将处理比物理内存大得多的数据集的应用程序。 具有非常大的代码源基础的应用程序。 每种“可扩展性”引入了一种不同类型的复杂性，并且需要一套不同的折衷方案。 横向扩展应用程序通常依赖于使用MPI协调各种进程的库。 某些应用程序是“令人尴尬的并行”，并且为了完成任务（例如渲染动画电影的不同帧），需要在不同进程之间进行很少（甚至没有）通信。 这种应用程序往往是基于CPU时钟速率或内存带宽的性能限制 ...
-
如何推出可扩展性？(How scalable is launchd?)[2022-02-23]
使用FSEvents或kqueues可以更好地处理是否已重命名文件或以其他方式修改文件。 Handling whether or not files have been renamed created or otherwise modified is better accomplished using FSEvents or kqueues.