这里的架构和设计模式存在许多问题，有些只用于异常有限的几种情况中，之所以在这几种情况中有效，是因为你真的明确在做什么。如果如许的话，你可以跳过这章不读。但为了使我的说法可以或许平安地实用于所有情形，我建议你不要应用这些架构。

分片

经常可以或许听到如许的建议:“要尽早分片，经常分片。”我的建议则年夜为分歧“除非不得已，不要分片”。假若有足够的经验，明确不得不分片，那就要对分片做好预备，但仍然要比及须要分片的时刻再进行分片。分片存在一些问题。

重要问题是分片如今已经很风行，并且人们分片做得太早、太频仍。我看到的年夜多半体系，要么已经做了分片，要么正在斟酌做分片，现实上基本就不须要一一只须要对今朝可用的商品硬件进行充足应用即可。以我的不雅点看来，对一个中等范围的运用，就要将其构建在跨越数百台低档机械的分片架构上，试图供给无穷伸缩才能，长短常愚昧的。其实，只须要购置几台足够好的机械，在工程上多做些斟酌，就足够了。对每个睁年夜眼睛、指着分片的胜利故事的人(我曾经就是个中之一)，我可以给你看一些没有应用分片的年夜范围运用，只是靠了几个聪慧的人，就能运维这种年夜范围运用。我的同事，还有我，也曾经看到过年夜量的最风行的分片运用，透过外面现象，内部倒是资本的极年夜糟蹋。

分片架构比你预想的要昂贵得多，甚至在短期内也是如斯，历久则必定如斯。这方面的例子有:分片一旦树立，则无法为了从新平衡的目标而再次构建；或者应用一种过于简略的办法，如用简略的取模算法作为分片函数。用拙劣的工程办法构建分片架构，无疑是一种短视行动，从而也是基本无法实现可伸缩的。对于真正主要的工作也就很难斟酌和设计，如常见的掉效情况。假如要在许多台机械上散布运用，或哪怕只有几台，都要卖力地斟酌掉效转移和故障后回切。运用法式也可能须要斟酌掉效的容错性，假如一部门数据集弗成用，要可以或许降级运行。

分片的第三个问题涉及过度设计(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个表的时刻就已经有问题了，因为履行筹划的盘算太庞杂了。