yaclty/Java-Interview-Guide
1
0
Fork 0
mirror of https://github.com/Snailclimb/JavaGuide synced 2025-06-16 18:10:13 +08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #543 from gpqhl0071/master

Browse Source 
修改错别字
This commit is contained in:
SnailClimb 2019-11-14 11:21:26 +08:00 committed by GitHub
commit cbb1e677e9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/system-design/data-communication/summary.md
View File

@ -44,7 +44,7 @@
**消息中间件，也可以叫做中央消息队列或者是消息队列（区别于本地消息队列，本地消息队列指的是JVM内的队列实现）**，是一种独立的队列系统，消息中间件经常用来解决内部服务之间的 **异步调用问题** 。请求服务方把请求队列放到队列中即可返回，然后等待服务提供方去队列中获取请求进行处理，之后通过回调等机制把结果返回给请求服务方。
异步调用只是消息中间件一个非常常见的应用场景。此外，常用的消息队列应用场景还偷如下几个：
异步调用只是消息中间件一个非常常见的应用场景。此外，常用的消息队列应用场景还有如下几个：
- **解耦 ：** 一个业务的非核心流程需要依赖其他系统，但结果并不重要，有通知即可。
- **最终一致性 ：** 指的是两个系统的状态保持一致，可以有一定的延迟，只要最终达到一致性即可。经常用在解决分布式事务上。
- **广播 ：** 消息队列最基本的功能。生产者只负责生产消息，订阅者接收消息。

10
docs/system-design/data-communication/why-use-rpc.md
View File

@ -74,7 +74,11 @@ Server: Apache 0.84
</html>
```
**使用自定义 TCP 协议进行传输就会避免上面这个问题，极大地减轻了传输数据的开销。**这也就是为什么通常会采用自定义 TCP 协议的 RPC 来进行进行服务调用的真正原因。初次之外，成熟的 RPC 框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择 RPC 进行服务注册和发现的一方面原因吧！
**使用自定义 TCP 协议进行传输就会避免上面这个问题，极大地减轻了传输数据的开销。**
这也就是为什么通常会采用自定义 TCP 协议的 RPC
来进行进行服务调用的真正原因。除此之外，成熟的 RPC
框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择
RPC 进行服务注册和发现的一方面原因吧！
**相关阅读：**
@ -88,7 +92,9 @@ Server: Apache 0.84
### 题外话
初次之外，还需要注意的一点是 Spring Cloud Netflix 并没有使用 RPC 框架来进行不同服务之间的调用，而是使用 HTTP 协议进行调用的，速度虽然不比 RPC ,但是使用 HTTP 协议也会带来其他很多好处（这一点，可以自行查阅相关资料了解）。
除此之外，还需要注意的一点是 Spring Cloud Netflix 并没有使用 RPC
框架来进行不同服务之间的调用，而是使用 HTTP 协议进行调用的，速度虽然不比 RPC
,但是使用 HTTP 协议也会带来其他很多好处（这一点，可以自行查阅相关资料了解）。