mirror of
https://github.com/doocs/advanced-java.git
synced 2024-12-28 04:10:08 +08:00
docs: update doc description
This commit is contained in:
parent
55512c67e6
commit
efcc3ef2f4
@ -83,7 +83,7 @@ TCC 的全称是:Try、Confirm、Cancel。
|
||||
3. 要是系统 B 执行成功就 ok 了;要是系统 B 执行失败了,那么最大努力通知服务就定时尝试重新调用系统 B,反复 N 次,最后还是不行就放弃。
|
||||
|
||||
### 你们公司是如何处理分布式事务的?
|
||||
如果你真的被问到,可以这么说,我们某某特别严格的场景,用的是 TCC 来保证强一致性;然后其他的一些场景基于阿里的 RocketMQ 来实现了分布式事务。
|
||||
如果你真的被问到,可以这么说,我们某某特别严格的场景,用的是 TCC 来保证强一致性;然后其他的一些场景基于阿里的 RocketMQ 来实现分布式事务。
|
||||
|
||||
你找一个严格资金要求绝对不能错的场景,你可以说你是用的 TCC 方案;如果是一般的分布式事务场景,订单插入之后要调用库存服务更新库存,库存数据没有资金那么的敏感,可以用可靠消息最终一致性方案。
|
||||
|
||||
|
@ -2,11 +2,11 @@
|
||||
说一下的 dubbo 的工作原理?注册中心挂了可以继续通信吗?说说一次 rpc 请求的流程?
|
||||
|
||||
## 面试官心理分析
|
||||
MQ、ES、Redis、Dubbo,上来先问你一些思考的问题,原理(kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理),生产环境里可能会碰到的一些问题(每种技术引入之后生产环境都可能会碰到一些问题),系统设计(设计MQ,设计搜索引擎,设计一个缓存,设计 rpc 框架)
|
||||
MQ、ES、Redis、Dubbo,上来先问你一些思考的问题,原理(kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理),生产环境里可能会碰到的一些问题(每种技术引入之后生产环境都可能会碰到一些问题),系统设计(设计 MQ,设计搜索引擎,设计一个缓存,设计 rpc 框架)
|
||||
|
||||
那既然开始聊分布式系统了,自然重点先聊聊 dubbo 了,毕竟 dubbo 是目前事实上大部分公司的分布式系统的 rpc 框架标准,基于 dubbo 也可以构建一整套的微服务架构。但是需要自己大量开发。
|
||||
|
||||
当然去年开始 spring cloud 非常火,现在大量的公司开始转向spring cloud了,spring cloud 人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用 dubbo,所以 dubbo 肯定会是目前面试的重点,何况人家 dubbo 现在重启开源社区维护了,未来应该也还是有一定市场和地位的。
|
||||
当然去年开始 spring cloud 非常火,现在大量的公司开始转向 spring cloud 了,spring cloud 人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用 dubbo,所以 dubbo 肯定会是目前面试的重点,何况人家 dubbo 现在重启开源社区维护了,捐献给了 apache,未来应该也还是有一定市场和地位的。
|
||||
|
||||
既然聊 dubbo,那肯定是先从 dubbo 原理开始聊了,你先说说 dubbo 支撑 rpc分布式调用的架构啥的,然后说说一次 rpc 请求 dubbo 是怎么给你完成的,对吧。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user