33 | 知识串联：以购买火车票的流程串联分布式核心技术

主备和主从的区别是什么呢？ 为什么有时候说主备，但是又把被叫做slave节点，都搞混了

老师能不能讲讲高并发下的库存扣减方案？如果完全依赖数据库的话容易出瓶颈吧？一般的大厂如何做这一块的？是不是要借助缓存？缓存的话要考虑缓存和数据库的一致性。感觉这一块要做好不容易。

分布式系统里面涉及太多知识点了，细节才是魔鬼

发现前面的知识忘差不多了😂需要规划一下二刷了

重要的文章看三遍👀

现在的系统RMDB真正承担的是和付款相关的事情，MQ和NOSQL 承担了上面的环节。我记得这套系统早期是单独用了sybase,然后跪了，换了oracle效果提升不明显。 如同老师之前课程所说的电商案例：拆分成了多个库，付款环节都有等待时间，这个时间才是真实与数据库的交互；最近看到的一些系统这方面做的很不好，导致数据库异常以及有时压力过大，这也是引发今年我仅仅是数据库性能优化问题然后就把组成原理和系统架构以及老师的分布式技术原理不惜一遍的原因。 从原理的角度去看：有时有些业务问题更加看的清楚更能明白问题的根源所在；知道问题的根据就知道后续如何真正去处理和解决。 谢谢老师今天的分享：一路跟随的过程其实很快，不知不觉发现课程居然快结束了，从初秋已至深冬了。谢谢老师一路的教诲，期待老师下周的分享。

回想一下我们的系统使用了那些分布式技术： 1：分布式负载均衡，几乎所有的服务都是分布式的，所以，负载均衡策略必不可少 2：分布式锁，比如控制只有一个业务用户可以导入数据或者刷新缓存 3：RPC、MQ、REDIS这些标配也少不了 4：有集群那分布式选主，故障隔离和恢复也必不可少 回想一下老师讲的这些都是会使用到的，在分布式系统中，这些好像是自行车的链条一般一个紧扣一个少了那个环节，整个链条就不再完整了，那自行车想跑起来就困难啦！ 这一整套技术信息量比较多，也不是一个人或一个团队就能搞定的，就像分布式系统一样研发团队也是分布式的。有不同的研发小组就像一个小集群，里面会有一个小组长，然后有了需求组长会负责负载均衡的分发出去，根据不同组员的能力采用不同的策略。

老师问下，是否采用半同步复制技术这种需要视业务场景而来吧，如果对于数据一致性要求很高是否完全采用同步方案呢

文中“比如，用户 A 购买 2019 年 10 月 12 日北京到上海的 T12 的火车票，已购买成功，座位号为 3 车厢 23B。假设主节点和备节点之间数据不一致，主节点上已经减去该火车票，但未在备节点上减去。此时，若主节点故障，备节点升主，用户 B 此时申请购买相同火车票，系统将 3 车厢 23B 火车票又卖给了用户 B。等到乘车时，用户 A 和 B 就难免“打架”了”这个问题的解决方案是什么呢？