diff --git a/docs/database/Redis/redis-all.md b/docs/database/Redis/redis-all.md index 16264dc1..8bfda557 100644 --- a/docs/database/Redis/redis-all.md +++ b/docs/database/Redis/redis-all.md @@ -127,7 +127,7 @@ _简单，来说使用缓存主要是为了提升用户体验以及应对更多 #### 6.1. string 1. **介绍** ：string 数据结构是简单的 key-value 类型。虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种 **简单动态字符串**（simple dynamic string，**SDS**）。相比于 C 的原生字符串，Redis 的 SDS 不光可以保存文本数据还可以保存二进制数据，并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)）,除此之外,Redis 的 SDS API 是安全的，不会造成缓冲区溢出。 -2. **常用命令:** `set,get,strlen,exists,dect,incr,setex` 等等。 +2. **常用命令:** `set,get,strlen,exists,decr,incr,setex` 等等。 3. **应用场景** ：一般常用在需要计数的场景，比如用户的访问次数、热点文章的点赞转发数量等等。 下面我们简单看看它的使用！ diff --git a/docs/network/计算机网络.md b/docs/network/计算机网络.md index d89e1e9e..07028ccf 100644 --- a/docs/network/计算机网络.md +++ b/docs/network/计算机网络.md @@ -44,7 +44,6 @@ **数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。** 在两个相邻节点之间传送数据时，**数据链路层将网络层交下来的 IP 数据报组装成帧**，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。 在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。 - 控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。 ### 1.5 物理层 @@ -293,3 +292,4 @@ URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL - [https://blog.csdn.net/zixiaomuwu/article/details/60965466](https://blog.csdn.net/zixiaomuwu/article/details/60965466) - [https://blog.csdn.net/turn__back/article/details/73743641](https://blog.csdn.net/turn__back/article/details/73743641) - + diff --git a/docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md b/docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md index 73953f0a..532e2cde 100644 --- a/docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md +++ b/docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md @@ -6,23 +6,17 @@ RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络 ### **RPC原理是什么？** -我这里这是简单的提一下，详细内容可以查看下面这篇文章： - -http://www.importnew.com/22003.html - ![RPC原理图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-6/37345851.jpg) -1. 服务消费方（client）调用以本地调用方式调用服务； -2. client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体； -3. client stub找到服务地址，并将消息发送到服务端； -4. server stub收到消息后进行解码； -5. server stub根据解码结果调用本地的服务； -6. 本地服务执行并将结果返回给server stub； -7. server stub将返回结果打包成消息并发送至消费方； -8. client stub接收到消息，并进行解码； -9. 服务消费方得到最终结果。 +1. 服务消费端（client）以本地调用的方式调用远程服务； +2. 客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：`RpcRequest`； +3. 客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端； +4. 服务端 Stub（桩）收到消息将消息反序列化为Java对象: `RpcRequest`； +5. 服务端 Stub（桩）根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法； +6. 服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：`RpcResponse`（序列化）发送至消费方； +7. 客户端 Stub（client stub）接收到消息并将消息反序列化为Java对象:`RpcResponse` ，这样也就得到了最终结果。 -下面再贴一个网上的时序图： +下面再贴一个网上的时序图，辅助理解： ![RPC原理时序图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-12-6/32527396.jpg) @@ -35,10 +29,13 @@ http://www.importnew.com/22003.html - **RMI（JDK自带）：** JDK自带的RPC，有很多局限性，不推荐使用。 - **Dubbo:** Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。 - **gRPC** ：gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务，以实现负载平衡，跟踪，运行状况检查和身份验证。它也适用于分布式计算的最后一英里，以将设备，移动应用程序和浏览器连接到后端服务。 - - **Hessian：** Hessian是一个轻量级的remotingonhttp工具，使用简单的方法提供了RMI的功能。 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。 - **Thrift：** Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。 +### RPC学习材料 + +- [跟着 Guide 哥造轮子](https://github.com/Snailclimb/guide-rpc-framework) + ## 既有 HTTP ,为啥用 RPC 进行服务调用? ### RPC 只是一种设计而已 diff --git a/docs/公众号历史文章汇总.md b/docs/公众号历史文章汇总.md index 5e698dba..5741f714 100644 --- a/docs/公众号历史文章汇总.md +++ b/docs/公众号历史文章汇总.md @@ -12,6 +12,7 @@ ## Java + ### 必看书籍 - [Java学习必备书籍推荐终极版！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485113&idx=1&sn=e4dd1bb22778e4e9139bf29d98a7492b&chksm=cea24972f9d5c064e5b454b84b9bc0d42f4aec007f20f79b564398e6dec7c0cdcda0e64193b5&token=1482344439&lang=zh_CN&scene=21#wechat_redirect)