分布式系统案例课
杨波
前携程 / 拍拍贷技术总监,微服务技术专家
11809 人已学习
新⼈⾸单¥59
课程目录
已完结/共 66 讲
第一章 课程介绍 (2讲)
时长 09:20
时长 04:42
第二章 如何设计一个分布式计数服务 - 系统设计面试案例 (7讲)
第五章 如何设计一个高并发无状态的会话缓存服务 - 携程SessionServer案例 (5讲)
第十章 课程回顾&结课测试 (1讲)
分布式系统案例课
登录|注册
留言
10
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 28 | 拍拍贷系统拆分项目案例
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 内容综述
03 | 需求收集和总体架构设计
04 | 存储设计
05 | 计数服务设计(上)
06 | 计数服务设计(下)
07 | 查询服务设计
08 | 技术栈选型
09 | 进一步考量和总结
10 | PMQ 2.0项目背景
11 | PMQ 2.0的设计解析(上)
12 | PMQ 2.0的设计解析(中)
13 | PMQ 2.0的设计解析(下)
14 | PMQ 3.0的演进
15 | Kafka的动态重平衡是如何工作的?(上)
16 | Kafka的动态重平衡是如何工作的?(下)
17 | 消息队列设计和治理最佳实践
18 | 第四章目录和大纲
19 | 微服务的四大技术难题是什么?
20 | 如何解决微服务的数据一致性分发问题?
21 | 如何解决微服务的数据聚合Join问题?
22 | 如何解决微服务的分布式事务问题?(上)
23 | 如何解决微服务的分布式事务问题?(下)
24 | 阿里分布式事务中间件Seata解析
25 | Uber微服务编排引擎Cadence解析
26 | 如何理解Uber Cadence的架构设计?
27 | 如何实现遗留系统的解耦拆分?
28 | 拍拍贷系统拆分项目案例
29 | CQRS/CDC技术在Netflix的实践
30 | 第四章总结
31 | SessionServer项目背景
32 | 总体架构设计
33 | 如何设计一个高性能基于内存的LRU Cache?
34 | 如何设计一个高性能大容量持久化的ConcurrentHashmap?
35 | 设计评估和总结
36 | SaaS项目healthchecks.io的背景和架构(上)
37 | SaaS项目healthchecks.io的背景和架构(下)
38 | 如何设计一个轻量级的基于DB的延迟任务队列?
39 | 如何设计一把轻量级的锁?
40 | 如何设计一个分布式限流系统?
41 | 如何设计一个分布式TopK系统实现实时防爬虫?
42 | 第七章目标和大纲
43 | 为什么说ServiceMesh是微服务的未来(上)
44 | 为什么说ServiceMesh是微服务的未来(下)
45 | 解析Envoy Proxy(上)
46 | 解析Envoy Proxy(下)
47 | Envoy在Lyft的实践
48 | 解析Istio
49 | K8s Ingress、Istio Gateway和API Gateway该如何选择?(上)
50 | K8s Ingress、Istio Gateway和API Gateway该如何选择?(下)
51 | Spring Cloud、K8s和Istio该如何集成?
52 | 第八章目标和大纲
53 | 拍拍贷案例:大型网站架构是如何演进的?
54 | 最小可用架构:Minimum Viable Architecture(上)
55 | 最小可用架构:Minimum Viable Architecture(下)
56 | 如何构建基于OAuth2/JWT的微服务架构?(上)
57 | 如何构建基于OAuth2/JWT的微服务架构?(下)
58 | 拍拍贷案例:如何实现数据中心机房的迁移?
59 | 携程/Netflix案例:如何实现同城双活和异地多活?
60 | 第九章大纲
61 | 学习开源项目的6个层次和8种方法(上)
62 | 学习开源项目的6个层次和8种方法(中)
63 | 学习开源项目的6个层次和8种方法(下)
64 | 百万年薪架构师是如何炼成的?
65 | 解读一份大厂的研发岗职级体系
66 | 结课测试&结束语
登录 后留言

全部留言(10)

  • 最新
  • 精选
飞翔
老师数据分发是怎么去join的?

作者回复: 假设A是用户表,B是订单表,那么传统数据库做法,C用户订单表=A join B。 如果采用数据分发+实时聚合方法,可以先建一张C表和一个实时聚合服务D,每次B表有数据变化(添加/更新或者删除),通过事务性发件箱或者CDC机制,将B表的变化发送给D,D可以根据C和A+B的变更,直接计算出并更新C。后面需要查找用户订单的时候,可以直接查C,不需要再Join。 在拍拍贷系统拆分场景中,主要是为了避免数据迁移过程中的跨库join,所以把涉及迁移的相关数据分发一份给依赖的服务,这样依赖的服务可以在本地DB做join(当然也可以用实时聚合技术消除本地join),这样对涉及迁移的数据就不是强依赖了,降低迁移的复杂度。

2020-07-24
5
what if
单体系统在做拆分时,可以有很多种不同的子系统定义和划分放弃,每种当时可能采取的分类聚类的范畴是不一样的,但是肯定会有一些是比较好的拆分,有一些是比较差的查分,老师有没有关于拆分的指导思想或者方法论,能够让我们获得相对好一些的拆分,比如从技术侧,从业务侧,从功能,从职能。

作者回复: 理论上应该按照业务领域或者团队边界进行拆分。实际拆分的时候,没有所谓比较好的拆分手段,很多时候都是见招拆招+简单粗暴+计划执行最能解决问题。

2020-10-20
2
what if
还有数据分发一般实时性比较差,对于实时性要求高的子系统应该怎么办

作者回复: 采用高性能消息队列+流计算,例如kafka-stream,同时设计要支持和接收最终一致性。另外做好性能监控告警+优化。

2020-10-20
2
what if
老师,你说双写分布式事物一致性是由后台团队写程序实现的,我想知道这部分一致性检验的原理和非一致性数据的修复逻辑是怎样的,这部分一定程度上决定了双写是否能够保证一致性,应该是非常关键的对于业务系统,怎么保证这部分功能的健壮可靠

作者回复: 我们当时的实现是采用job定期比对,job定期跑(例如30秒跑一次),先从源数据库获取增量时间范围内的数据,然后再去目标数据库获取增量数据,然后做两边数据的比对,比对有误则发出告警。这个job是基于xxl-job实现,xxl-job采用高可用部署,也有job监控日志和告警。所以健壮主要靠监控和告警。

2020-10-20
2
2
Akira
老师,拆分步骤一,拆分了服务,但是还没有拆分出数据库。其他应用从操作DB改成操作拆分出来的服务。这一阶段马上就会面临分布式事务问题。一般是先引入分布式解决方案后再进行拆分吗?

作者回复: 拆分服务的时候,尽量避免出现分布式事务的情况,如果两个服务涉及分布式事务,那么在拆的时候尽量合并作为一个服务一起拆出来,涉及分布式事务的操作也封装在一个接口中。 只有在不得已情况下,才考虑引入分布式事务解决方案。

2021-05-13
1
丁小明
数据双写采用mq的方式,如果mq有confirm机制,配合本地事物,是不是也能保证双写一致性呢?

作者回复: 阿里的rocketmq支持你说的这种mq带confirm的机制,业界实践反馈也可以保证双写一致性,当然mq本身的设计和实现会比较复杂。

2020-11-17
2
1
叮叮董董
1,2,3阶段需要系统支持多数据源吗

作者回复: 这个具体要看业务系统的情况,如果业务系统需要连多个DB,那么就需要支持多数据源。 不管需不需要多数据源,揭耦拆分的一般步骤都是类似的。

2020-08-13
1
独孤九剑
数据库迁移和数据分发可以用阿里云的DTS服务

作者回复: 是的,数据同步分发(包括CDC)是重要的迁移手段。

2021-06-22
Akira
老师,迁移技术2的1 老DB对新DB的补偿一般怎么做? 老DB拷贝一份数据到新DB,只要老DB不停机,新DB总会有时间差导致数据不完全相同。

作者回复: 这个新老DB如果要完全不停机的实时同步是比较难的,我们当时是可以停机的,在凌晨业务量小时公告停机,等没有了流量,DBA将老数据一把导入新DB,然后停机结束开始接入流量,这时候两边是双写,数据可以保证一致。

2021-05-14
约书亚
数据迁移的4个步骤太有价值了,很少见到其他文章中有提到,重点是每一步都可回滚到上一步
2020-08-15
1
收起评论