泰坦尼克号》是一部1997年奥斯卡获奖影片，由伦纳德-迪卡普里奥和凯特-温斯莱特（从现在起将被称为K8温斯莱特）主演，讲述了在命运多舛的泰坦尼克号上的爱情故事。正如我们所知，泰坦尼克号是一艘 "不沉的船"--当时世界上最大的船--然而它在首航后仅几天就沉没了，在1912年4月15日撞上冰山并沉入北大西洋底，使船上的1500人丧生。
我想重新想象一下泰坦尼克号的结局，包括船的结局和电影的结局。我们将通过Kubernetes和分布式数据库技术的视角来审视这个故事，看看这个故事本来可以有一个幸福的结局。
泰坦尼克号。一个巨大的、昂贵的、单实例的数据库
把最初的泰坦尼克号想象成一个单实例数据库。这可以是云中的一个大型实例，或者是一个大型的内部Oracle设置。它是宏伟的、昂贵的、单体的。当航行顺利的时候，事情就会很好！有花哨的晚餐，也有漂亮的衣服。有华丽的晚宴和狂热的派对。
但是，如果你的单实例数据库撞上了一座冰山，那么就没有实际的、立即的恢复。如果发生故障，可能需要几个小时或几天的时间来恢复所有的损失。无论是由于自然灾害、人为错误，还是冰山，中断都会发生。你的数据库（和你的船）难道不应该准备好处理最坏的情况吗？
为什么泰坦尼克号会沉没？快速转移到不良架构中
以下是泰坦尼克号--"不沉之船"--沉没背后的一些机制。泰坦尼克号的船体上有16个隔间，被称为舱壁的隔板隔开。它们被设计成这样，所以如果船上有一个洞，舱壁确保只有一个舱室会被水填满。问题是，隔板并没有到达上面的甲板。相反，每个隔板都停在水线以上10英尺处。可以把这想象成一堵几乎达到上方天花板的墙。当泰坦尼克号撞上冰山时，16个舱室中的5个被撞破，这导致船头下沉。这使得水流入所有的舱室。一旦一个舱被填满，水就会继续从舱壁上涌入，这艘 "不沉 "的船在3小时内就沉没了。
一旦船体被攻破，就没有任何东西可以阻止船的沉没。更糟糕的是，没有足够的救生艇来拯救船上的所有人。
船只和数据库的灾难恢复
单一实例 "泰坦尼克号数据库 "的灾难恢复通常是通过异步复制完成的，当事务较多且吞吐量有限时，异步复制的速度会大大降低。只有拥有大量额外资源的公司才有能力为其单实例数据库的高可用性版本付费。
在泰坦尼克号的案例中，有太多的人需要被拯救（事务），而没有足够的救生艇（吞吐量）。唯一能够获救的人是上层阶级，他们为他们的高端体验支付了更多的钱。
好吧，那么这些和Kubernetes有什么关系？
让我们用Kubernetes和分布式数据库重新想象泰坦尼克号的样子
现在让我们想象一下，泰坦尼克号可以被重建，以消除其单一的故障点。怎样才能使它成为我们梦想中的高可用、灾难恢复的船只？
分布和复制。如果我们有更多的泰坦尼克号呢？让我们分布和复制我们的泰坦尼克号，让它有两艘相同的船与它并肩作战，而不是单一的、单一的船。这样就可以把队伍分成三条船，而不是一条船，同时也增加了容量，以防其中一条船出现灾难性问题。即使面对灾难，我们也可以增加更多的复制品!不需要担心救生艇用完。把这些看作是你的分布式数据库。
让我们添加一个 "舵手图"
在字面上的舵手，让我们引入一个舵手图。舵手让我们的船在水中运行，帮助我们制定成功的路线，但如果没有人盯着所有的仪表，它也做不了什么。
船长将由 "操作员 "来扮演
现在让我们想象一下升级后的船长，由 "操作员 "扮演，控制船上的所有功能。操作员向船员提供有关方向、外部条件和船舶状态的信息。它允许我们的船员在船舶行驶时升级船舶的各个部分。想象一下，在不耽误任何时间的情况下更换发动机。它甚至还配备了住在船上的安保人员。操作员使带数据库的Kubernetes的运行大大简化。有了操作员，泰坦尼克号可能一开始就不会撞上冰山。
我们重新想象的泰坦尼克号
在我们重新想象的泰坦尼克号上--或者说是泰坦尼克号，因为我们将运行三艘船而不是一艘--我们现在可以演绎罗斯-K8-温斯莱特和杰克之间的爱情，并将结局改写成一个幸福的结局。
罗丝-K8-温斯莱特。拘束的、静止的、无状态的
我们的女主人公罗斯-K8-温斯莱特，感觉到她的生活方式就像她的胸衣一样被束缚住了。K8是她所处环境的产物--20世纪初的一个上层社会的年轻女性，她被培养成在社会中扮演一个非常特殊的角色。我们可以说，K8被培养成了无国籍人。无聊、静态，类似于一个不变的网页。
杰克-道森。活泼、动态、充满...状态？
Jack Dawson代表CockroachDB参与了Kubernetes（K8）和CockroachDB的合作。杰克活泼、充满活力、无所畏惧。当K8遇到杰克时，她的观点发生了变化。有了Jack/CockroachDB，K8可以变得有状态。K8终于可以变得有活力、有趣，并充分发挥她的潜力。
在我们重新想象的分布式泰坦尼克号上，如果我们的一艘船撞上了冰山，一个（Kubernetes）容器可能会灌满水，但它不会影响其他任何容器。这意味着，如果船体中的一个容器被攻破，船就不会沉没。
在发生故障的情况下，如果我们的一艘船沉没，会有另外两艘船来转移乘客，以及有足够的救生艇供船上的所有人使用。同样，在使用Kubernetes和CockroachDB的灾难恢复场景中，一个被摧毁的节点上的所有数据范围都能够安全地转移到另一个节点上。没有一个乘客或船员会丢失。数据库事务可以继续在近处、远处、任何地方进行，并且不间断地进行下去。
罗斯K8温斯莱特和杰克（CockroachDB）是书中的爱情故事，如果最初的泰坦尼克号遵循分布式系统的设计模式，最后就不会有人死亡。舱壁会建得很好，分布式船舶会确保在灾难面前的恢复，而且有足够的救生艇给每个人。
如果有人想知道，假想一下，那块木头上当然有足够的空间容纳K8和CockroachDB!CockroachDB和Kubernetes是命中注定的，你可以在Kubernetes上的CockroachDB上运行关键任务操作。而这是需要 "永远不放手 "的事情!
