全栈工程师修炼指南
熊燚（四火）
Oracle首席软件工程师
立即订阅
2289 人已学习
课程目录
已完结 44 讲
0/4登录后，你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看，为什么你应该成为全栈工程师？
免费
学习路径 | 怎样成为一名优秀的全栈工程师？
导读 | 如何学习这个专栏？
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天：HTTP 协议的演化
02 | 为HTTP穿上盔甲：HTTPS
03 | 换个角度解决问题：服务端推送技术
04 | 工整与自由的风格之争：SOAP和REST
05 | 权衡的艺术：漫谈Web API的设计
06 | 特别放送：北美大厂如何招聘全栈工程师？
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题：MVC框架的发展
08 | MVC架构解析：模型（Model）篇
09 | MVC架构解析：视图（View）篇
10 | MVC架构解析：控制器（Controller）篇
11 | 剑走偏锋：面向切面编程
12 | 唯有套路得人心：谈谈Java EE的那些模式
13 | 特别放送：选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天：从后端到前端
15 | 重剑无锋，大巧不工：JavaScript面向对象
16 | 百花齐放，百家争鸣：前端MVC框架
17 | 不一样的体验：交互设计和页面布局
18 | 千言万语不及一幅画：谈谈数据可视化
19 | 打开潘多拉盒子：JavaScript异步编程
20 | 特别放送：全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑：缓存（上）
22 | 赫赫有名的双刃剑：缓存（下）
23 | 知其然，知其所以然：数据的持久化和一致性
24 | 尺有所短，寸有所长：CAP和数据存储技术选择
25 | 设计数据持久层（上）：理论分析
26 | 设计数据持久层（下）：案例介绍
27 | 特别放送：聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一：配置管理
29 | Ops三部曲之二：集群部署
30 | Ops三部曲之三：测试和发布
31 | 防人之心不可无：网站安全问题窥视
32 | 和搜索引擎的对话：SEO的原理和基础
33 | 特别放送：聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化（上）
35 | 网站性能优化（下）
36 | 全栈开发中的算法（上）
37 | 全栈开发中的算法（下）
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化：让全栈意味着更多
全栈回顾 (1讲)
全栈回顾 | 成为更好的全栈工程师！
全栈工程师修炼指南
登录|注册
36 | 全栈开发中的算法（上）
四火 2019-12-02
你好，我是四火。
在本专栏中，我们已经接触到了全栈开发中的一些算法了。在这一讲和下一讲中，我又精心挑选了几个比较重要的。和单纯地从数学角度去介绍算法不同，我想结合几个全栈开发中实际、典型的问题场景，向你介绍这几个相关的重要算法。毕竟，我们关心的算法，其实就是可以解决实际问题的方法的一种数学抽象。
希望通过这两讲的学习，你能理解这些算法。除了理解算法原理本身，我们更要抓住它们的用途和算法自身的巧妙之处。今天我们来讲其中的第一个典型的问题场景——流量控制。
流量控制系统中的算法
对于全栈工程师来说，无论是网站，还是其它 Web 应用，一旦对外商用，就要考虑流量控制的问题。因此我们往往需要设计使用单独的流量控制模块，我们来看下面这样的一个问题。
假如说，我们现在需要给一组 Web API 设计一个流量控制系统，以避免请求对系统的过度冲击，对于任意一个用户账户 ID，每一个 API 都要满足下面所有的要求：
每分钟调用不能超过一万次；
每小时调用不能超过十万次；
每天调用不能超过一百万次；
每周调用不能超过一千万次；
……
在继续往下阅读之前，请你先从算法和数据结构的角度思考，你觉得该怎么设计这个流量控制系统呢？
简化问题
在解决实际问题的时候，我们面临的问题往往是复杂的、多样的，因此，我们可以考虑能不能先简化问题，再来尝试映射到某一个数学模型上。那些先不考虑的复杂条件，有的可能就是可以忽略掉的，而有的则是为了思路的清晰。一开始我们可以先忽略，有了解题的方法原型以后，再逐步加回来考虑。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(5)
許敲敲现在知道面试题滑动窗口的意义了 还有密匙交换算法作者回复: 👍🏻
2019-12-02
安琪既然秒杀都是耍猴，请问淘宝代拍这类是怎么实现高成功率的？这里边是否涉及到不合规的操作呢？作者回复: 我不太懂“代拍”的机制，如果有谁知道，可以分享一下。
不过关于秒杀的一些简单机制，我在另一个留言下面回复了。2019-12-02
leslie其实算法贯穿了整个计算机系统-不出不在：算法的好坏直接决定了某件事情的效率，除非单纯的去堆硬件。即使单纯的堆硬件你都得要算法，否则就是纯粹的人多力量大了。作者回复: 很多时候，能单纯堆硬件解决的问题往往都不是什么问题。成为问题的，是堆硬件也没法解决的。
2019-12-02
靠人品去赢这篇文章，让我联想到秒杀活动的设计，反正就是不让你大流量直接进入到服务器就是了，想了一下所谓的秒杀，真的就是耍猴。作者回复: 秒杀的话，不能光靠服务端这一个节点的流控。因为流量太大，即便有流控，中心节点的网络压力也很大，而且流控的判断逻辑也是有消耗的——虽然因为流控，请求没有处理，可是连接依然是建立的，这依然是显著的开销。
比如说，秒杀需要 CDN 等本地节点，按比例“放行”少量的请求到中心节点的服务端，而大部分请求，直接拒绝掉。用这种方法尽可能地保护中心服务节点。2019-12-02
许童童老师的文章写得真好，读起来意犹未尽作者回复: 😎
2019-12-02
收起评论