今天被一个架构师面了
来源:互联网 发布:淘宝订单清洗三次机会 编辑:程序博客网 时间:2024/06/05 07:51
(点击上方公众号,可快速关注)
1. 上来就问读过什么框架源码
说实话,没读过什么框架源码,这个以后要研究下了
2. 用过什么设计模式
我说了十来个
3. Redis有哪些数据类型
这个问的有点小二科了
4. 设计一个连接池
估计是问你设计能力
5. 分布式事务更好的解决方案是什么
两阶段提交中的第二阶段, 协调者需要等待所有参与者发出yes请求,或者一个参与者发出no请求后,才能执行提交或者中断操作。这会造成长时间同时锁住多个资源,造成性能瓶颈,如果参与者有一个耗时长的操作,性能损耗会更明显。
实现复杂,不利于系统的扩展,不推荐。
TCC (Try-Confirm-Cancle)
TCC,是基于补偿型事务的AP系统的一种实现,具有最终一致性。
对比与前面提到的两阶段提交法, 有两大优势:
TCC能够对分布式事务中的各个资源进行分别锁定,分别提交与释放,例如,假设有AB两个操作,假设A操作耗时短,那么A就能较快的完成自身的try-confirm-cancel流程,释放资源,无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可。
TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作),也就是各服务之间可以在一定程度上”异步并行”执行。
适用场景
严格一致性
执行时间短
实时性要求高
举例:红包、收付款业务。
异步确保型
通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响。
需要额外说明的一点,就是事务消息投递到MQ订阅方后,并不一定能够成功执行。需要MQ订阅方主动给予消费反馈(ack):
如果MQ订阅方执行远程事务成功,则给予消费成功的ack,那么MQ Server可以安全将事务消息移除;
如果执行失败,MQ Server需要对消息重新投递,直至消费成功。
注意事项
消息中间件在系统中扮演一个重要的角色,所有的事务消息都需要通过它来传达,所以消息中间件也需要支持 HAC 来确保事务消息不丢失。
根据业务逻辑的具体实现不同,还可能需要对消息中间件增加消息不重复,不乱序等其它要求。
适用场景
执行周期较长
实时性要求不高
例如:
跨行转账/汇款业务(两个服务分别在不同的银行中)
退货/退款业务
财务,账单统计业务(先发送到消息中间件, 然后进行批量记账)
最大努力通知型
这是分布式事务中要求最低的一种,也可以通过消息中间件实现,与前面异步确保型操作不同的一点是,在消息由MQ Server投递到消费者之后,允许在达到最大重试次数之后正常结束事务。
适用场景
交易结果消息的通知等。
出处:http://blog.csdn.net/hxpjava1/article/details/77841791
推荐程序员必备微信号
▼
- 今天被一个架构师面了
- 今天被一个架构师面了
- 今天被一个架构师面了
- 今天被一个架构师面了
- 今天被一个架构师面了
- 今天腾讯三面,被一个SB的博士后给毙了
- 今天下载了一个
- 今天面了两个人
- 今天又吃面了
- 朋友今天问我一个面试题,我看了看,给大家分享一下
- 今天的一个面试题。回来想了好久才明白。
- 今天理了一个光头!
- 今天换了一个BLOG
- 今天做了一个刷票机~
- 今天听了一个讲座
- 今天开了一个blog
- 今天做了一个程序
- 今天明白了一个道理
- git diff 配置 meld diff
- mysql max 与 where 间的执行问题
- 使用eval("("+data+")")转json格式
- 页面请求包含中文的文件及URL--linux服务器
- linux命令--rm
- 今天被一个架构师面了
- 共享单车系统又被黑客盯上,多账户押金被盗
- 图片自适应和footer的定位方式
- 2年Java开发工作经验面试总结
- Like What You Like: Knowledge Distill via Neuron Selectivity Transfer 论文翻译
- ForeverViewPager 无限循环轮播图
- 理解卷积的概念
- jsp基础
- C++ 模板详解(二)