| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -16,4 +16,10 @@ | |||
| 16 | 16 |  | |
| 17 | 17 | ||
| 18 | 18 | ||
| 19 | - 虽然没有直接返回 html 页面那么快,但是因为数据在本地缓存,所以也很快,其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更,不需要将所有的页面重新静态化,直接将数据渲染进最新的 html 页面模板后响应即可。 | ||
| 19 | + 虽然没有直接返回 html 页面那么快,但是因为数据在本地缓存,所以也很快,其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更,不需要将所有的页面重新静态化,直接将数据渲染进最新的 html 页面模板后响应即可。 | ||
| 20 | + | ||
| 21 | + 在这种架构下,我们需要**保证系统的高可用性**。 | ||
| 22 | + | ||
| 23 | + 如果系统访问量很高,Nginx 本地缓存过期失效了,redis 中的缓存也被 LRU 算法给清理掉了,那么会有较高的访问量,从缓存服务调用商品服务。但如果此时商品服务的接口发生故障,调用出现了延时,缓存服务全部的线程都被这个调用商品服务接口给耗尽了,每个线程去调用商品服务接口的时候,都会卡住很长时间,后面大量的请求过来都会卡在那儿,此时缓存服务没有足够的线程去调用其它一些服务的接口,从而导致整个大量的商品详情页无法正常显示。 | ||
| 24 | + | ||
| 25 | + 这其实就是一个商品接口服务故障导致缓存服务资源耗尽的现象。 | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -45,7 +45,7 @@ person = { | |||
| 45 | 45 | ### list | |
| 46 | 46 | list 是有序列表,这个可以玩儿出很多花样。 | |
| 47 | 47 | ||
| 48 | - 比如可以通过 list 存储一些列表型的数据结构,类似粉丝列表了、文章的评论列表了之类的东西。 | ||
| 48 | + 比如可以通过 list 存储一些列表型的数据结构,类似粉丝列表、文章的评论列表之类的东西。 | ||
| 49 | 49 | ||
| 50 | 50 | 比如可以通过 lrange 命令,读取某个闭区间内的元素,可以基于 list 实现分页查询,这个是很棒的一个功能,基于 redis 实现简单的高性能分页,可以做类似微博那种下拉不断分页的东西,性能高,就一页一页走。 | |
| 51 | 51 | ```bash | |
| Back | FazBrowse Home | New Git URL |
0 commit comments