分片
经常能够听到这样的建议:“要尽早分片，经常分片。”我的建议则大为不同“除非不得已，不要分片”。假如有足够的经验，明白不得不分片，那就要对分片做好准备，但仍然要等到需要分片的时候再进行分片。分片存在一些问题。
主要问题是分片现在已经很流行，而且人们分片做得太早、太频繁。我看到的大多数系统，要么已经做了分片，要么正在考虑做分片，实际上根本就不需要一一只需要对目前可用的商品硬件进行充分利用即可。以我的观点看来，对一个中等规模的应用，就要将其构建在跨越数百台低档机器的分片架构上，试图提供无限伸缩能力，是非常愚蠢的。其实，只需要购买几台足够好的机器，在工程上多做些考虑，就足够了。对每个睁大眼睛、指着分片的成功故事的人(我曾经就是其中之一)，我可以给你看一些没有使用分片的大规模应用，只是靠了几个聪明的人，就能运维这种大规模应用。我的同事，还有我，也曾经看到过大量的最流行的分片应用，透过表面现象，内部却是资源的极大浪费。
分片架构比你预想的要昂贵得多，甚至在短期内也是如此，长期则一定如此。这方面的例子有:分片一旦建立，则无法为了重新均衡的目的而再次构建；或者使用一种过于简单的方法，如用简单的取模算法作为分片函数。用低劣的工程方法构建分片架构，无疑是一种短视行为，从而也是根本无法实现可伸缩的。对于真正重要的事情也就很难考虑和设计，如常见的失效情形。如果要在很多台机器上分布应用，或哪怕只有几台，都要认真地考虑失效转移和故障后回切。应用程序也可能需要考虑失效的容错性，假如一部分数据集不可用，要能够降级运行。
分片的第三个问题涉及过度设计(overengineering)的风险。大多数事情都很难做到正好，不是做过头了，就是没有做到位。害怕架构没有足够的灵活性，或害怕不知道怎么做到正好，很容易导致过度设计。这不仅使事情过于复杂，还会产生无休止的麻烦。
写入多台主服务器
存在很多诱惑性的陷阱，其中之一就是，将复制拓扑中的多台服务器配置成可写的，你认为这样做就万事大吉了。通常的想法是，“这样就能够提高写操作的性能”或者“所有节点都是平等的，从而失效转移就容易实现了。”然而，这两者都是错误的。
在主-主配置中，通过向两台主服务器写，是无法提高性能的。所有的写操作都要通过复制发送给从服务器，在每个节点上都要重复执行该写操作，所以，写操作从哪台服务器上发出，是无关紧要的。
因为复制是异步执行的8，在多个位置进行写操作非常容易出错，而且几乎肯定在很多情况下都会产生麻烦，这些情况包括失效转移、应用程序错误、程序员错误，以及大量的其他常见情形。通常导致的结果有丢失数据，以及长时间的、没日没夜的苦干，试图将系统恢复到合理的、一致的状态。试图说服你的老板或同事不要这样做，肯定很困难，但一定要试试。
多级复制
如果可能的话，尽量不要使用多级复制。使用一台主服务器和N台从服务器，而不是从服务器的从服务器的从服务器，要简单得多。麻花链链的从服务器结构，有的时候是有优点的，但可能的话最好避免使用。孙子辈的从服务器和重孙子辈的从服务器很难管理，假如在这些从服务器和位于金字塔顶端的主服务器之间的中间级别上发生问题的话。常见的问题有复制延迟、服务器崩溃、错误以及网络问题。
环形复制(多于两个节点)
要像躲避瘟疫一样避免使用环形复制，其失效情形，不管是数量还是复杂度，都大得超乎想象。就在几天前，我接到一个请求支持的电话，那是由5台服务器构成的环，在试图移掉其中一台而用另外的服务器替换时，却发生了语句死循环的问题。这种架构非常脆弱，随时都会引发灾难。
依赖于DNS
我已经说过这一点，但仍然值得再重复一次。DNS很脆弱，依赖于DNS最终会自食苦果。将DNS用于域名查询是没问题的，但DNS不应该受失效转移的影响。不要将循环DNS∞用于负载均衡。同理，也不要使用/letc/hosts，对这个文件的版本变更、管理以及部署都要是原子操作。
所谓的实体一属性一值(EAV)设计模式
每当有人对我说，“我有一个托管的多租户Saas应用…”我都能够补充他的下半句：“你使用的是EAV，而且有性能问题。”在你不知道最终的数据模式是什么，或者根本就没有最终的数据模式时，EAV是有诱惑力的。这往往出现在“托管的、多租户的SaaS应用”中，这只是因为公司想销售有灵活性的东西。他们想这样告诉客户:“不管你的数据是什么样的，都会适合我们的系统的。”但这并不是关系数据库的工作方式。因为很快就会产生100个表的自连接(self-joins)，而产生的查询计划除了由于搜索整个磁盘而产生的随机IO之外，不会做更多的事情。这些搜索在网站建设索引中找到一点儿数据，然后将这些简单的值按行拼接起来一一这个过程很慢的。在 MYSQL中，你是无法做100个连接的， MYSQL的限制是每个查询只能最多对61个表做连接，实际上不到20个表的时候就已经有问题了，因为执行计划的计算太复杂了。
本文地址：//www.gogoparty.cc//article/3320.html
