第一宗:磁盘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服 务器或是数据库,甚至是改进你的应用,允许同时读写多个数据库。

不提供这些开关,扩展性和可用性就受到了很大限制。