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

全部留言(6)

  • 最新
  • 精选
hunterlodge
滑动窗口算法并非完全避免了边界问题,而是通过降低粒度,减少了发生的概率

作者回复: 你的理解也合理

2020-09-01
1
白小龙
老师,怎么觉得令牌桶和固定窗口是同一个算法呢,只不过是令牌桶做的是--,额外需要一个塞令牌的job,固定窗口做的是++。他们都是用过期时间来使时间窗口失效。

作者回复: 两种限流实现方式,最后的限流效果可以相同。在平滑流量方面,各有不同的实现机制。

2021-03-23
2
白小龙
老师,比如每秒限流10个,如果使用redis的zset,score作为时间戳(ms),某一时刻1615386799000过来一笔请求 var count = zcount user_1 (1615386799000-1000) 1615386799000; //获取当前时间-1s至当前时间段的请求数 if (count >= 10 ) return "too many request"; zadd user_1 1615386799000 geek; 这样处理是不是也只是把窗口细化到了1ms而已,严格意义上的平滑是不存在的,能做的只是像微积分一样无限逼近,但是在应用中其实已经够用了难道不是么?

作者回复: 你提出来的可以算是一种使用redis限流的新思路,实际还需要进一步测试验证。平滑只能趋近,不能绝对。

2021-03-10
丁小明
老师,如果集中式限流,对于同一个接口请求量如果很大超过50w每秒,对于api网关入口和限流服务由于可以水平扩展是能承受的,但是对于同一个请求都是路由到同一台redis,超过redis承受范围那该如何优化呢。

作者回复: 量特别大对redis可以做分片sharding,例如采用一致性hash技术进行分片

2020-11-19
Jxin
还有guava的均速限流器

作者回复: 对,guava rate limiter也是经典的本地限流器,应该也是基于令牌桶的,参考这里: https://dzone.com/articles/detailed-explanation-of-guava-ratelimiters-throttl

2020-08-08
青阳
固定窗口:有边界问题; 滑动窗口:将窗口再细粒度划分,实现任一个窗口限流,但还是不能解决比窗口更细粒度的时间内流量高峰,不平滑; 漏桶算法:控制出口,比较平滑; 令牌桶算法:可以预放令牌,有一定的泄洪作用,不平滑。
2022-07-13
收起评论