分布式系统案例课
杨波
前携程 / 拍拍贷技术总监,微服务技术专家
11809 人已学习
新⼈⾸单¥59
课程目录
已完结/共 66 讲
第一章 课程介绍 (2讲)
时长 09:20
时长 04:42
第二章 如何设计一个分布式计数服务 - 系统设计面试案例 (7讲)
第五章 如何设计一个高并发无状态的会话缓存服务 - 携程SessionServer案例 (5讲)
第十章 课程回顾&结课测试 (1讲)
分布式系统案例课
登录|注册
留言
11
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 06 | 计数服务设计(下)
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 | 结课测试&结束语
登录 后留言

全部留言(11)

  • 最新
  • 精选
Bill
可以更简单一些,流量直接打到网关上记录日志,然后起个普通的统计聚合服务,面向写的场景写入DB就了。 简化掉中间很多环节,可用性提升。

作者回复: 当然,环节越少越简单,出故障的概率就小,但是还是要看量级,因为体量决定架构。根据具体的体量大小,可以适当简化。 1. 可以通过采集网关(或者反向代理)的访问日志,来实现计数服务。 2. 通常原始访问日志也需要保存起来,中间一般引入kafka消息队列,主要考虑一个是流量消峰,另外一个是前后解耦合。

2020-09-05
3
jhren
感谢杨老师核心名词都提供了英文翻译

作者回复: ⛽️

2020-06-17
3
静水流深
这节课,让我感受到了,知识储备的重要性!!需要不断地去深入学习。

作者回复: ⛽️

2020-06-16
3
波波老师讲的很精彩,可惜报名的人数那么少,可能大部分学员看到标题就没太大兴趣了。

作者回复: 本课程主要面向中高级工程师和架构师,受众有一定限制

2020-10-12
2
G小调
有个疑问,计算服务,怎么计算一个窗口期时间内的请求聚合,再推送到数据库存储

作者回复: 简单用一个ConcurrentHashMap,key是videoId,value是1分钟内的点击数量累加值。 弄个后台线程每分钟,新建一个ConcurrentHashMap,替换那个老的,然后把老的值打包写入本地MQ。

2020-06-24
2
何凌
有没有可能直接写MQ?Kafka会有auth的问题,如果是带auth的MQ呢?

作者回复: 一般不直接写mq,前面放一个代理服务去写mq,这样客户端不耦合具体的mq技术。 kafka的auth,可以根据需要关闭,即使有auth也没有关系,客户端用官方方法做auth就好了。

2020-06-20
2
不忘初心
观看事件的产生,老说讲的是浏览器主动发送,是否可以在api网关里用过滤器来产生观看事件?

作者回复: 可以,甚至还可以通过nginx或者网关的访问日志来收集。课程只是一个演示场景。

2020-06-19
1
tt
看得真过瘾

作者回复: ⛽️

2020-06-18
1
Sky
计数服务如果是一个窗口期时间内的请求聚合,再推送到数据库存储, 在还没推送前,计数服务器crash,那存储与concurren hashmap中的计数就丢失了。如果为了放丢失,写入硬盘又慢,这个有什么好的办法解决?

作者回复: 如果通过内存做聚合并且要保证数据不丢,那么一般必须先写入磁盘文件。相当于在每台counting service的主机上要有磁盘queue(相当于write ahread log),然后在磁盘queue的一端写入数据,另外一端做消费聚合,同时在磁盘上记录queue的消费指针。后面如果计数服务crash了,重启服务后,从上次的消费指针重新消费即可,这样可以保证可靠性(但是可能重复消费)。

2021-04-25
瞌睡的李先生
作为一个0年经验的实习生,感觉波波老师讲的东西为我打开了一扇新世界的大门

作者回复: 加油💪

2021-04-23
收起评论