接着老柯开始讲第二个故事："话说智者有一位朋友开了一家餐饮店，经营炒菜，他的隔壁紧挨着是一家汉堡店，两家店生意都不错。不巧这家汉堡店的老板家中有事，想把店转让给智者的朋友，朋友有两个思路：1. 把这个汉堡店改造成炒菜馆，扩大炒菜馆的规模；2.保留汉堡店，同时经营这两类菜品。考虑到这家汉堡店经营的比较成功，设备和配方也都留给这位朋友，最终这位朋友决定同时经营两类菜品。该如何经营为好呢，保持原样还是整合成一个店面？于是朋友找到智者来商讨此事。

智者提议对两个餐饮店进行改造，将其合并成一个店面，并给出了一个大致的改造思路：首先将两店之隔的墙拆开，形成一个整体。接着将原来各自的前台改造成一个统一的前台，在这里既可以点炒菜又可以点汉堡。而餐厅则是一个统一的餐厅。厨房是独立的区域，内部划分成两块子区域，分别是炒菜区和汉堡区，并分别配有厨师长。前台发来的任何指令，都要确保服务员能快速准确的将指令送达厨房，交由两个区域的厨师长去安排处理，最终由服务员根据前台指令将菜送达顾客餐桌上。

至此，顾客无论是只要炒菜、还是只要汉堡、还是又要炒菜又要汉堡，都可以得到很好的满足。

// 餐厅点餐系统简化代码class 统一餐厅 {
    前台 frontDesk;
    厨房 kitchen;
    服务员[] waiters;
    
    // 处理顾客点餐
    public void 接收点餐(菜单 menu) {
        // 前台接收点餐
        订单 order = frontDesk.创建订单(menu);
        
        // 根据菜品类型分发到对应厨房区域
        if (order.包含中餐()) {
            kitchen.中餐区.处理订单(order.获取中餐项());
        }
        
        if (order.包含西餐()) {
            kitchen.西餐区.处理订单(order.获取西餐项());
        }
        
        // 安排服务员送餐
        waiters[分配服务员()].负责送餐(order);
    }}

朋友根据智者的建议进行餐厅店改造，生意更加的红火了。一段时间后，智者来到朋友餐饮店，发现店变更大了。此外厨房似乎也大了许多，走进一看，厨房区域变多了，增加了煲汤区、卤味区，也都配有对应的厨师长。厨房、餐厅、餐厅依然有序。智者看了非常满意，并继续给朋友出主意，建议朋友开连锁店，将这种模式推广到全国各地。朋友愉快的接受了智者的建议，后来，他成为了全国规模最大的餐饮店老板。
在这里插入图片描述

各位，两个故事都讲完了，大家听完后，有没有信心建成超融合数据库城堡？”

37. 超融合数据库城堡的建立

这故事又是啥寓意呢，众人越发困惑了。

看到众⼈有些困惑，老柯继续往下说。“这是非常精彩的思路，分布式数据库的本质是将数据分散到各个不同的节点上。等同于将一个‘大数据库’切割成多个’小数据库’，如’小数据库A’，‘小数据库B’，'小数据库C’等，并分散在各个不同的物理机上。由于这些‘小数据库’是一个个独立的小王国，所以统一协调这些小王国共同工作成为了一种难题。以张三转账给李四的转账操作为例，在集中式数据库中操作很简单，有点像变成救援队人员和智者在一个房间里，救援人员把地图给智者，手一递，智者手一接，救援人员手中的地图就没了，转到智者手中了。如果在传递对过程中不小心失败，掉落地上，救援人员就地捡起来，又回到救援人员手中。大家在同一房间，所见即所得。

而分布式数据库中就出现张三的这条账户信息存在‘小数据库A’上，而李四的这条账户信息存在‘小数据库B’上，在‘小数据库A’的张三账户要完成扣款，‘小数据B’上的李四账户要实现余额增加，如果李四余额增加失败，张三就需要对扣款进行回退。有点像救援人员和智者分处于不同的房间，彼此看不见对方，也无法与对方进行消息传递，救援人员把地图给出了，智者到底有没有收到，救援人员是不知道的。大家在不同房间，无法所见即所得。

// 分布式事务简化代码function 转账(用户A, 用户B, 金额) {
    // 创建分布式事务
    事务ID = 开始分布式事务();
    
    try {
        // 第一阶段：预提交
        数据库A.准备(事务ID, "扣款", 用户A, 金额);
        数据库B.准备(事务ID, "增款", 用户B, 金额);
        
        // 第二阶段：正式提交
        数据库A.提交(事务ID);
        数据库B.提交(事务ID);
        
        return "转账成功";
    } catch (异常) {
        // 发生错误，回滚事务
        数据库A.回滚(事务ID);
        数据库B.回滚(事务ID);
        return "转账失败: " + 异常.消息;
    }}

故事中指挥部介入后，形成了救援方、智者分别和指挥部进行多次响应的机制，有效的解决了问题。这种机制是可以很好的应用到关系型数据库的分布式架构设计中去的。”

大家听了后恍然大悟，老王带头鼓掌，众人纷纷鼓掌。

“关于智者餐饮店改造的故事，也点醒了我，其实我们并不需要打造一个无所不能的厨房，而是要打造一个无所不包的厨房，只要前台的指令处理机制能够足够完善，可以高效的涵盖各种需求，各厨师长的分工能明确，服务员的送菜能准确抵达顾客这里，那无论炒菜、汉堡、煲汤、卤味其实就是一体的。

这里的前台其实就是数据库的优化器；厨房的各个区域就是数据库的存储引擎；往返于前台、厨房、餐厅中传达指令的服务员就是数据库的执行器；这里的连锁店就是数据库的分布式技术，由于各个区域的菜系差不多，所以对于数据库来说是似乎是一种复制分片，不过这对我来说也很受启发，复制分片是可以在很多场景发挥作用的。大家是否发现餐饮店和数据库何其相似，智者改造的餐饮店是超融合餐饮店，我们接下来要做就是打造超融合数据库。这两个故事我稍做总结，请大家参考。”

众人倍受启发，热情高涨，梳理了当下七个城堡的优势与不足，并探索了超融合数据的解决方案，如下图所示：

在众人的不懈努力，超融合数据库城堡终于破土而出！

未完待续...

公众号：收获不止数据库

微信：ljbyxl1213

系列回顾

ITPub博客

七座城堡⑨ 混元归一【下】（第一部大结局）

36. 老柯讲述的第二个故事

37. 超融合数据库城堡的建立

最新文章