Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
wushizhenking
advanced-java
提交
bbe7c8fd
A
advanced-java
项目概览
wushizhenking
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
bbe7c8fd
编写于
1月 07, 2019
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
docs: update doc description
上级
a7cb2432
变更
6
隐藏空白更改
内联
并排
Showing
6 changed file
with
30 addition
and
14 deletion
+30
-14
README.md
README.md
+2
-1
docs/distributed-system/dubbo-service-management.md
docs/distributed-system/dubbo-service-management.md
+3
-4
docs/high-availability/e-commerce-website-detail-page-architecture.md
...ailability/e-commerce-website-detail-page-architecture.md
+19
-4
docs/high-availability/hystrix-timeout.md
docs/high-availability/hystrix-timeout.md
+1
-0
docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md
...ow-to-ensure-that-messages-are-not-repeatedly-consumed.md
+1
-1
docs/high-concurrency/mq-interview.md
docs/high-concurrency/mq-interview.md
+4
-4
未找到文件。
README.md
浏览文件 @
bbe7c8fd
...
...
@@ -14,7 +14,7 @@
### [消息队列](/docs/high-concurrency/mq-interview.md)
-
[
为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么优点和缺点?
](
/docs/high-concurrency/why-mq.md
)
-
[
如何保证消息队列的高可用?
](
/docs/high-concurrency/how-to-ensure-high-availability-of-message-queues.md
)
-
[
如何保证消息不被重复消费?(如何保证消息消费
时
的幂等性)
](
/docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md
)
-
[
如何保证消息不被重复消费?(如何保证消息消费的幂等性)
](
/docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md
)
-
[
如何保证消息的可靠性传输?(如何处理消息丢失的问题)
](
/docs/high-concurrency/how-to-ensure-the-reliable-transmission-of-messages.md
)
-
[
如何保证消息的顺序性?
](
/docs/high-concurrency/how-to-ensure-the-order-of-messages.md
)
-
[
如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
](
/docs/high-concurrency/mq-time-delay-and-expired-failure.md
)
...
...
@@ -87,6 +87,7 @@
-
[
基于本地缓存的 fallback 降级机制
](
/docs/high-availability/hystrix-fallback.md
)
-
[
深入 Hystrix 断路器执行原理
](
/docs/high-availability/hystrix-circuit-breaker.md
)
-
[
深入 Hystrix 线程池隔离与接口限流
](
/docs/high-availability/hystrix-thread-pool-current-limiting.md
)
-
[
基于 timeout 机制为服务接口调用超时提供安全保护
](
/docs/high-availability/hystrix-timeout.md
)
### 高可用系统
-
如何设计一个高可用系统?
...
...
docs/distributed-system/dubbo-service-management.md
浏览文件 @
bbe7c8fd
...
...
@@ -88,14 +88,13 @@ public class HelloServiceImpl implements HelloService {
我们调用接口失败的时候,可以通过
`mock`
统一返回 null。
mock 的值也可以修改为 true,然后再跟接口同一个路径下实现一个 Mock 类,命名规则是
`接口名称+Mock`
后缀。然后在 Mock 类里实现自己的降级逻辑。
mock 的值也可以修改为 true,然后再跟接口同一个路径下实现一个 Mock 类,命名规则是
“接口名称+
`Mock`
”
后缀。然后在 Mock 类里实现自己的降级逻辑。
```
java
public
class
HelloServiceMock
implements
HelloService
{
public
void
sayHello
()
{
// 降级逻辑
}
}
```
...
...
@@ -109,9 +108,9 @@ public class HelloServiceMock implements HelloService {
举个栗子。
某个服务的接口,要耗费 5s,你这边不能干等着,你这边配置了 timeout
之后,我等待
2s,还没返回,我直接就撤了,不能干等你。
某个服务的接口,要耗费 5s,你这边不能干等着,你这边配置了 timeout
之后,我等待
2s,还没返回,我直接就撤了,不能干等你。
可以结合你们公司具体的场景来说说你是怎么设置这些参数的:
-
`timeout`
:一般设置为
`200ms`
,我们认为不能超过
`200ms`
还没返回。
-
`timeout`
:一般设置为
`200ms`
,我们认为不能超过
`200ms`
还没返回。
-
`retries`
:设置 retries,一般是在读请求的时候,比如你要查询个数据,你可以设置个 retries,如果第一次没读到,报错,重试指定的次数,尝试再次读取。
\ No newline at end of file
docs/high-availability/e-commerce-website-detail-page-architecture.md
浏览文件 @
bbe7c8fd
...
...
@@ -5,18 +5,33 @@
![
e-commerce-website-detail-page-architecture-1
](
/images/e-commerce-website-detail-page-architecture-1.png
)
-
好处:用户每次浏览一个页面,不需要进行任何的跟数据库的交互逻辑,也不需要执行任何的代码,直接返回一个 html 页面就可以了,速度和性能非常高。
-
坏处:仅仅适用于一些小型的网站,比如页面的规模在几十到几万不等。对于一些大型的电商网站,亿级数量的页面,你说你每次页面模板修改了,都需要将这么多页面全量静态化,靠谱吗?
下面是页面模板的简单 Demo 。
```
html
<html>
<body>
商品名称:#{productName}
<br>
商品价格:#{productPrice}
<br>
商品描述:#{productDesc}
</body>
</html>
```
这样做,
**好处**
在于,用户每次浏览一个页面,不需要进行任何的跟数据库的交互逻辑,也不需要执行任何的代码,直接返回一个 html 页面就可以了,速度和性能非常高。
对于小网站,页面很少,很实用,非常简单,Java 中可以使用 velocity、freemarker、thymeleaf 等等,然后做个 cms 页面内容管理系统,模板变更的时候,点击按钮或者系统自动化重新进行全量渲染。
**坏处**
在于,仅仅适用于一些小型的网站,比如页面的规模在几十到几万不等。对于一些大型的电商网站,亿级数量的页面,你说你每次页面模板修改了,都需要将这么多页面全量静态化,靠谱吗?每次渲染花个好几天时间,那你整个网站就废掉了。
### 大型电商网站的商品详情页系统架构
大型电商网站商品详情页的系统设计中,当商品
信息发生变更时,会将变更消息压入消息队列中。
**缓存服务**
从消息队列中消费此消息时,发现有信息发生变更,便通过调用接口,获取变更后的数据。将整合好的数据推送至 redis 中。Nginx 获取到最新的缓存数据,并且缓存到 Nginx 自己本地中
。
大型电商网站商品详情页的系统设计中,当商品
数据发生变更时,会将变更消息压入 MQ 消息队列中。
**缓存服务**
从消息队列中消费这条消息时,感知到有数据发生变更,便通过调用数据服务接口,获取变更后的数据,然后将整合好的数据推送至 redis 中。Nginx 本地缓存的数据是有一定的时间期限的,比如说 10 分钟,当数据过期之后,它就会从 redis 获取到最新的缓存数据,并且缓存到自己本地
。
用户浏览网页时,动态将 Nginx 本地数据渲染到本地 html 模板并返回给用户。
![
e-commerce-website-detail-page-architecture-2
](
/images/e-commerce-website-detail-page-architecture-2.png
)
虽然没有直接返回 html 页面那么快,但是因为数据在本地缓存,所以也很快,其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更,不需要将所有的页面重新静态化,直接将数据渲染进最新的 html 页面模板后响应即可。
虽然没有直接返回 html 页面那么快,但是因为数据在本地缓存,所以也很快,其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更,不需要将所有的页面重新静态化,
也不需要发送请求,没有网络请求的开销,
直接将数据渲染进最新的 html 页面模板后响应即可。
在这种架构下,我们需要
**保证系统的高可用性**
。
...
...
docs/high-availability/hystrix-timeout.md
0 → 100644
浏览文件 @
bbe7c8fd
## 基于 timeout 机制为服务接口调用超时提供安全保护
\ No newline at end of file
docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md
浏览文件 @
bbe7c8fd
## 面试题
如何保证消息不被重复消费?或者说,如何保证消息消费
时
的幂等性?
如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性?
## 面试官心理分析
其实这是很常见的一个问题,这俩问题基本可以连起来问。既然是消费消息,那肯定要考虑会不会重复消费?能不能避免重复消费?或者重复消费了也别造成系统异常可以吗?这个是 MQ 领域的基本问题,其实本质上还是问你
**使用消息队列如何保证幂等性**
,这个是你架构里要考虑的一个问题。
...
...
docs/high-concurrency/mq-interview.md
浏览文件 @
bbe7c8fd
...
...
@@ -24,7 +24,7 @@
**面试官**
:那你说说用消息队列都有什么优点和缺点?
(面试官此时心里想的是,你的
`MQ`
在项目里为啥要用
?你没
考虑过,那我稍微简单点儿,我问问你消息队列你之前有没有考虑过如果用的话,优点和缺点分别是啥?)
(面试官此时心里想的是,你的
`MQ`
在项目里为啥要用
,你没怎么
考虑过,那我稍微简单点儿,我问问你消息队列你之前有没有考虑过如果用的话,优点和缺点分别是啥?)
**候选人**
:这个。。。(确实平时没怎么考虑过这个问题啊。。。胡言乱语了)
...
...
@@ -36,7 +36,7 @@
**候选人**
:我们就用过
`ActiveMQ`
,所以别的没用过。。。区别,也不太清楚。。。
(面试官此时
却
是觉得你这哥儿们平时就是瞎用,根本就没什么思考,觉得不行)
(面试官此时
更
是觉得你这哥儿们平时就是瞎用,根本就没什么思考,觉得不行)
**面试官**
:那你们是如何保证消息队列的高可用啊?
...
...
@@ -52,7 +52,7 @@
**面试官**
:那如何保证消息的顺序性?
**候选人**
:顺序性?什么意思?我为什么要保证消息的顺序性?
**候选人**
:顺序性?什么意思?我为什么要保证消息的顺序性?
它不是本来就有顺序吗?
**面试官**
:如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
...
...
@@ -64,6 +64,6 @@
---
这
是面试官的一种面试风格,就是
面试官的问题不是发散的,而是从一个小点慢慢铺开。比如说面试官可能会跟你聊聊高并发话题,就这个话题里面跟你聊聊缓存、
`MQ`
等等东西,
**由浅入深,一步步深挖**
。
这
其实是面试官的一种面试风格,就是说
面试官的问题不是发散的,而是从一个小点慢慢铺开。比如说面试官可能会跟你聊聊高并发话题,就这个话题里面跟你聊聊缓存、
`MQ`
等等东西,
**由浅入深,一步步深挖**
。
其实上面是一个非常典型的关于消息队列的技术考察过程,好的面试官一定是从你做过的某一个点切入,然后层层展开深入考察,一个接一个问,直到把这个技术点刨根问底,问到最底层。
\ No newline at end of file
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录