mirror of
https://github.com/doocs/advanced-java.git
synced 2026-08-18 10:43:29 +08:00
feat: update duplicate files and generate pagination
移除冗余文件，激活页面底部导航
This commit is contained in:
yanglbme
@@ -54,7 +54,7 @@ end
|
||||
5. 要是锁建立失败了，那么就依次之前建立过的锁删除；
|
||||
6. 只要别人建立了一把分布式锁，你就得**不断轮询去尝试获取锁**。
|
||||
|
||||
|
||||
|
||||
|
||||
[Redis 官方](https://redis.io/)给出了以上两种基于 Redis 实现分布式锁的方法，详细说明可以查看：https://redis.io/topics/distlock 。
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
分布式业务系统，就是把原来用 Java 开发的一个大块系统，给拆分成**多个子系统**，多个子系统之间互相调用，形成一个大系统的整体。假设原来你做了一个 OA 系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1 台机器部署。现在如果你把这个系统给拆开，权限系统、员工系统、请假系统、财务系统 4 个系统，4 个工程，分别在 4 台机器上部署。一个请求过来，完成这个请求，这个员工系统，调用权限系统，调用请假系统，调用财务系统，4 个系统分别完成了一部分的事情，最后 4 个系统都干完了以后，才认为是这个请求已经完成了。
|
||||
|
||||
|
||||
|
||||
|
||||
> 近几年开始兴起和流行 Spring Cloud，刚流行，还没开始普及，目前普及的是 dubbo，因此这里也主要讲 dubbo。
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
|
||||
下面我给个我们用过的方案吧，简单来说，首先你得用 dubbo 的一致性 hash 负载均衡策略，将比如某一个订单 id 对应的请求都给分发到某个机器上去，接着就是在那个机器上，因为可能还是多线程并发执行的，你可能得立即将某个订单 id 对应的请求扔一个**内存队列**里去，强制排队，这样来确保他们的顺序性。
|
||||
|
||||
|
||||
|
||||
|
||||
但是这样引发的后续问题就很多，比如说要是某个订单对应的请求特别多，造成某台机器成**热点**怎么办？解决这些问题又要开启后续一连串的复杂技术方案......曾经这类问题弄的我们头疼不已，所以，还是建议什么呢？
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
如果你要操作别人的服务的库，你必须是通过**调用别的服务的接口**来实现，绝对不允许交叉访问别人的数据库。
|
||||
|
||||
|
||||
|
||||
|
||||
### TCC 方案
|
||||
TCC 的全称是：`Try`、`Confirm`、`Cancel`。
|
||||
@@ -43,7 +43,7 @@ TCC 的全称是：`Try`、`Confirm`、`Cancel`。
|
||||
|
||||
但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码是很难维护的。
|
||||
|
||||
|
||||
|
||||
|
||||
### 本地消息表
|
||||
本地消息表其实是国外的 ebay 搞出来的这么一套思想。
|
||||
@@ -59,7 +59,7 @@ TCC 的全称是：`Try`、`Confirm`、`Cancel`。
|
||||
|
||||
这个方案说实话最大的问题就在于**严重依赖于数据库的消息表来管理事务**啥的，如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
|
||||
|
||||
|
||||
|
||||
|
||||
### 可靠消息最终一致性方案
|
||||
这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。
|
||||
@@ -73,7 +73,7 @@ TCC 的全称是：`Try`、`Confirm`、`Cancel`。
|
||||
5. 这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。
|
||||
6. 这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你就用 RocketMQ 支持的，要不你就自己基于类似 ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的。
|
||||
|
||||
|
||||
|
||||
|
||||
### 最大努力通知方案
|
||||
这个方案的大致意思就是：
|
||||
|
||||
@@ -29,7 +29,7 @@ MQ、ES、Redis、Dubbo，上来先问你一些**思考性的问题**、**原理
|
||||
- 第三步：consumer 调用 provider
|
||||
- 第四步：consumer 和 provider 都异步通知监控中心
|
||||
|
||||
|
||||
|
||||
|
||||
### 注册中心挂了可以继续通信吗？
|
||||
可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息**拉取到本地缓存**，所以注册中心挂了可以继续通信。
|
||||
@@ -9,7 +9,7 @@ dubbo 支持哪些通信协议？支持哪些序列化协议？说一下 Hessian
|
||||
## 面试题剖析
|
||||
**序列化**，就是把数据结构或者是一些对象，转换为二进制串的过程，而**反序列化**是将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。
|
||||
|
||||
|
||||
|
||||
|
||||
### dubbo 支持不同的通信协议
|
||||
- dubbo 协议
|
||||
@@ -20,11 +20,11 @@ dubbo 支持哪些通信协议？支持哪些序列化协议？说一下 Hessian
|
||||
|
||||
长连接，通俗点说，就是建立连接过后可以持续发送请求，无须再建立连接。
|
||||
|
||||
|
||||
|
||||
|
||||
而短连接，每次要发送请求之前，需要先重新建立一次连接。
|
||||
|
||||
|
||||
|
||||
|
||||
- rmi 协议
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
|
||||
那就需要基于 dubbo 做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将**各个服务之间的依赖关系和调用链路生成出来**，做成一张图，显示出来，大家才可以看到对吧。
|
||||
|
||||
|
||||
|
||||
|
||||
#### 2. 服务访问压力以及时长统计
|
||||
需要自动统计**各个接口和服务之间的调用次数以及访问延时**，而且要分成两个级别。
|
||||
|
||||
@@ -82,7 +82,7 @@ hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
|
||||
```
|
||||
provider 启动的时候，就会加载到我们 jar 包里的`my=com.bingo.MyProtocol` 这行配置里，接着会根据你的配置使用你定义好的 MyProtocol 了，这个就是简单说明一下，你通过上述方式，可以替换掉大量的 dubbo 内部的组件，就是扔个你自己的 jar 包，然后配置一下即可。
|
||||
|
||||
|
||||
|
||||
|
||||
dubbo 里面提供了大量的类似上面的扩展点，就是说，你如果要扩展一个东西，只要自己写个 jar，让你的 consumer 或者是 provider 工程，依赖你的那个 jar，在你的 jar 里指定目录下配置好接口名称对应的文件，里面通过 `key=实现类`。
|
||||
|
||||
|
||||
BIN
docs/distributed-system/images/redis-redlock.png
Normal file
BIN
docs/distributed-system/images/redis-redlock.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
@@ -19,19 +19,19 @@ zookeeper 都有哪些使用场景？
|
||||
### 分布式协调
|
||||
这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上**对某个节点的值注册个监听器**，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。
|
||||
|
||||
|
||||
|
||||
|
||||
### 分布式锁
|
||||
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作；然后另外一个机器也**尝试去创建**那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。
|
||||
|
||||
|
||||
|
||||
|
||||
### 元数据/配置信息管理
|
||||
zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？
|
||||
|
||||
|
||||
|
||||
|
||||
### HA高可用性
|
||||
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个**重要进程一般会做主备**两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user