数据架构和CAP定理：它们在哪里冲突？
数据架构和CAP定理：冲突之处在哪？
编辑注：Joep Kokkeler是本秋ODSC West的演讲人。一定要去看看他的演讲“在Kappa数据架构中捕捉CAP”!
在深入研究不同类型的数据架构之前，让我们先关注一下CAP定理。CAP定理指出，在任何系统中（暂时不包括原子事务），你可以同时拥有以下两种，但永远不能同时拥有三种：一致性、可用性和容错性。为了处理这个问题，在选择架构类型时，你可以做出正确的选择。
当谈到架构时，人们总是假设他们知道各种架构类型的含义。但如果你不知道呢？假设你了解lambda架构的技术实现，但不知道与其他实现相比有何不同。
让我用一个简单的类比来解释。
每个人一生中都去过动物园。那里有很多不同的动物，需要不同的技能来照顾这些动物。所以你需要有正确的知识来经营动物园，或者你雇佣懂得如何照顾动物的人，这样你就可以享受你的动物园。选择架构几乎是一样的，你不需要了解每个实现的所有细节，但你需要知道你正在处理什么。
单体架构
让我们从单体架构开始，顾名思义，它很大，很老，占用了很多空间，可能是一只大象。具体来说，是一只非洲丛林大象，是最大的象种。在你的团队中有一个老人知道如何正确照顾它，他知道可以按哪些按钮，哪些按钮要远离。有个实习生试图与这只伟大的野兽合作，但在他走过的地方，火灾不断，所以最好让那个和“架构”这个词同一时间诞生的人来照顾这只巨兽。
微服务
接下来是微服务。在微服务架构中，创建具有各自责任的服务非常重要。有时这些责任会溢出，不知不觉中，你正在运行一个迷你单体。指导年轻的灰色大象去你想要它去的地方，需要完全不同的技能。我最好的比较对象是一群狼。在野外，一群狼会笔直地向前移动（为了节省能量），每只狼在队伍中都有特定的责任。
互联网上有一张流传的照片，你可以看到一群狼在雪地中，标题说前面的狼生病或老了，要注意不要让它们落后或被用作“缓冲区”当遇到攻击时。考虑到在雪地中移动会消耗很多能量，让已经虚弱的狼站在前面是没有意义的。与你的微服务相同：第一个服务可能有点臃肿，但它确实为其他服务做了很多重活。lambda架构以其小组件大小而闻名，并且你总是希望有更多的它们。
所以它更像是一群猫鼬。一群猫鼬被称为一群，这个名字我更喜欢。不要说你运行了多个lambda组，你有一些群体在你的控制下。猫鼬和lambda的共同之处是你必须尽可能地将责任分解得越小越好，否则猫鼬会将其保持原样。过去，猫鼬需要几分钟才能真正做你想让它做的事情，但我们通过给它提供要做的事情来解决了这个问题，使其永不停止。这使得猫鼬很容易做好它的工作，并确保将工作结果传递给下一个猫鼬，你可以控制许多群体做你想让它们做的事情。
Kappa
最后但并非最不重要的是kappa架构。想象一只胖乎乎的企鹅，就是那些来自《马达加斯加的逃亡》的家伙们。企鹅总是需要成群结队地行动，所以在你的kappa架构中，有很多成群的企鹅在微笑和挥手。但我们实际上希望我们的架构非常快速和聪明。所以想象一下同样的企鹅，现在它背上绑着一枚火箭。那就是我们kappa架构的基础。许多企鹅背上都装着火箭。请注意，你不必是火箭科学家才能在kappa架构上工作。
结论
现在我们已经了解了我们正在研究的是什么样的怪物，我们如何实现这些架构中的一个来具备CAP定理的三个组件呢？想知道什么样的怪物（或者是一只带火箭的企鹅）最适合CAP定理吗？请来参加我在旧金山ODSC西部的活动，详细了解这个问题，并观看我进行不同实现的实时演示。
关于作者：
Joep Kokkeler拥有超过12年的开发、工程、架构和可视化数据产品的经验，涵盖能源到服装制造等各种市场。他致力于帮助团队更好地处理数据，并为团队提供上线和持续生产所需的工具和知识。
他曾是Teqnation项目委员会的成员，在足球期间进行了关于Kafka和Hue使用的演讲，开发和部署Hololens上的应用，使用Gitlab进行全面Devops，数据科学产品的演化，从PoC到生产使用弹性堆栈，以及在Devoxx London上使用Xbox Kinect骑车。
