挂一部分机器,不会丢数据、不会不可服务,是对现代数据库的一个比较基本的要求。 对于早期的单机数据库,一般使用主备架构。主备架构有很多的缺陷,并且这些缺陷是无解的。穿过主备架构里各种“优化”的名词,最后也无非是选择一碗毒药而已,这几个毒药包括: 1.脑裂,两个节点同时写入的冲突数据无法合并,只能丢掉一部分。想要不脑裂?那只能牺牲可用性。 2.同步复制,备机不可用的情况下,算不算写入成功?算,可能丢数据;不算,备机不可用==集群不可用,牺牲可用性。 3.异步复制,这完全躺平了,不考虑一致性。 4.所谓semi-sync等方案,也属于主备架构的一种。 5.业务自己去容错,做针对自己业务场景的对账、补偿等方案。 其实可以看出,主备架构是CAP理论做取舍的重灾区,一致性和可用性之间的关系特别矛盾。所谓一致性和可用性“兼顾”的主备方案,实际上是“兼不顾”。
分库分表是大型互联网应用经常采用的一种数据层优化方案,常见的分库分表中间件如 sharding-jdbc、mycat 都已经比较成熟,基本上可以应对我们一般的分库分表需求。做过分库分表的同学应该知道,在给业务系统做分库分表改造过程中,难的不是如何使用这些组件进行分库分表,而是如何将非分库分表的系统平滑的升级成一个分库分表的系统,升级期间业务不可暂停,升级过程及升级后风险可控,这个过程就像是给飞行中的飞机更换引擎,处理不好会产生重大的业务事故。去哪儿网机票辅营业务就经历过从主从读写分离系统升级到分库分表系统的过程,并在多次迭代过程中形成了一种与业务轻相关的平滑的分库分表方案,后续业务升级分库分表只需通过配置切换就可以将单库单表系统瞬切至分库分表系统。