17 | 正确性案例（上）：如何实现分布式的事件溯源架构？
任杰
你好，我是任杰。这一讲我想和你聊一聊怎么实现分布式的事件溯源架构。
所以，这节课我们一起来看看，如何一步一步解决系统扩容和容灾的问题。这里我先做个提示，因为这节课会用到很多前面讲过的内容，必要的地方我会给你说明关联到前面哪一节课。我建议你先把握整体思路，有弄不懂的，可以再温习一下前面的内容。
这节课要讲的解决问题的思路，不仅仅适用于事件溯源架构，很多和计算及数据相关的系统也会碰到同样的挑战。所以，你在学习这节课时，重点要放在理解为什么会有这些问题，以及为什么有这些解决方案，而不是放在解决方案的细节上。
多机容灾
我们先来看看分布式环境下我们能解决的第一个问题，那就是容灾。
容灾的思路是花钱来换取服务质量。如果单台机器出问题之后无法对外提供服务，那么只要我们能把同一个功能部署在多台机器上就行，这些机器作为一个整体对外提供服务。如果一台机器坏掉了的话，只要集群里还有其他的机器，那么就能再找一台机器，替换掉前面那台坏掉的。
刚才的分析看似正确，但隐含着三个重要的假设。这几个假设会直接影响到我们的架构能达到的正确性级别。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了如何实现分布式的事件溯源架构，涵盖了在分布式环境下的容灾问题、复制状态机版本的事件溯源框架、分布式环境下的数据查询问题、分库处理以及分布式事务等内容。文章强调了对正确性级别的要求和选用一致性算法的重要性，并详细讨论了如何通过一致性算法来同步事件队列以及引入反向代理来解决主节点切换后的通知问题。此外，还探讨了分布式环境下的数据查询问题，包括一致性读和常规查询。文章还介绍了分库处理和分布式事务的解决方法，以及如何通过共识算法实现容灾能力。总体而言，本文对于需要了解分布式系统架构的读者具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《分布式金融架构课》，新⼈⾸单¥59
《分布式金融架构课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(4)
- 最新
- 精选
贺可不可以结合具体的业务场景分享一下 eBay 里面是怎么做这些组件的技术选型的? 比如说是用了开源的还是自研的?作者回复: 这位同学你好。我在第4节课提到过，核心系统需要自研。账务系统是支付业务最核心的组件之一，虽然自研投入高，但是回报也高，因此是一个值得自研的系统。
2021-02-011
Kyle Liu必须要无脑赞一个，分布式这方面在国内似乎没有什么好的资料，老师可以推荐点靠谱的资料吗。作者回复: 小编指路专栏加餐2的书单，希望有帮助。
2021-02-08
webmin使用推或拉，需要根据同步事件量、及时性和需要同步事件的消费者数量三个方面来评估， 1. 对于及时性要求非常高的场景需要使用推的方式，推是同步处理； 2. 拉的方式可以周期性批量处理，减少网络通信量，消费者可以根据自身能力来调节拉取量； 3. 需要同步事件的消费者众多时，使用推送方式容易阻塞，增加推送者重试的负担，如消费者处理慢或是网络原因； 推是同步处理，拉是异步处理。2021-02-026
tt如果选择从主节点复制数据，为了避免增加主节点的压力，是不是选择推模式比较好，这样主节点可以选择在空闲的时间（片）内调度推送任务的执行时间。但这样会增加复制的延时——由于忙，无法及时推送。 如果是选择从从节点上复制事件对列，那么可以选择拉模式，这样由于从节点负载比较轻，拉去请求可以及时被响应。 我觉得最简单的就是增加消息中间件，让写模式状态机把消息发布到消息中间件上去，由别人来订阅。2021-02-012
收起评论
