直播当天到底发生了啥,让两位老师变身“德X社”的相声演员捧/逗起哏来了?
快看以下内容,揭晓答案

为了让线上的小伙伴都能听懂,导师们也是操碎了心
在直播伊始就猝不及防的演起戏来,嗯,还被小伙伴看穿了哈哈哈哈
当然,导师们的初衷大家都懂
对此,我只想说,有没有人给导师们颁个小金人呀!!
看中奖公布和回放请直接拉到最底部哦
话不多说,我们还是来关注技术吧!
直播当晚,线上的小伙伴们提问太踊跃了,老师们来不及一一解答。
于是,小助手下了直播后赶忙整理好问题列表后请老师们答疑解惑,快来看看有没有你提的问题被选中了呀!!

问
TCC 本质上还是两阶段协议是吗,老师
答

从表面上来看TCC是两个阶段的提交,但是和传统意义的两阶段提交有本质不同。 TCC从业务层面提供了锁的机制,相比传统的两阶段提交来说锁的力度可以更小,效率会更高,当然没有传统的两阶段的一致性强。

问
实现 TCC 增加业务代码的复杂度,太麻烦了
答

TCC的业务代码复杂度要比Saga复杂得多,但是由于Saga很难解决事务隔离性问题, TCC在业务层面提供了锁或者申请资源的机制,从应用层面可以比较好的解决事务隔离的问题。

问
架构的日志处理和安全方面是如何做的呢?
答

是通用的架构问题,还是问ServiceComb Pack的架构实现。
ServiceComb Pack目前是使用数据库来存储事件信息的。 安全上Omega和Alpha可以使用SSL进行通信。

问
TCC的Alpha Coordinator如果是单点怎么办?也需要高可靠吗?
答

单点就实现不了高可靠了, 目前的Alpha是支持集群的。

问
这个和 dubbo 有什么不同啊
答

Dubbo是RPC框架,ServiceComb Pack是分布式事务解决方案, ServiceComb Pack 有一个 Dubbo传输插件,可以与Dubbo集成。

问
try 成功了, confirm 成功也可能失败,这个一般如何处理?
答

一般我们可以通过重试的方式来确保confirm方法调用成功。但如果多次尝试不成功,系统会记录下来,并交人工进行处理。

问
TiDB这类数据库 将来成熟了 是不是除了和外部系统交互的部分外 系统内部本身的分布式事务问题基本就全部规避掉了呢 也是数据库层的趋势吧
答

微服务的事务解决方案和分布式数据库解决方案是两个层面的问题。 都会有各自的发展。从使用者的角度, 微服务架构并不推荐使用单一数据库,所以微服务的事务解决方案还会一直发展下去。

问
看阿里最近开源那个分布式事务中间件那种思路 RM在app侧做协调而不是事务资源像数据库原生提供 这种思路是未来一种趋势吗
答

这种实现方式是把以往资源层面上的锁放到的事务管理器层面来提升系统性能,从本质上来讲没有把锁的机制去除。具体是否好用,留给时间来检验。

问
华为有自己独立的分布式事务的解决方案么?
答

华为公有云有独立的分布式事务解决方案,最近会上线,欢迎关注。

问
怎么保证分布式集群的事务一致性?
答

这个问题不是很明确, 是分布式集群的数据一致性还是分布式事务的一致性。
分布式事务一致性是本次直播要回答的问题, 分布式集群的数据一致性可以参考CAP原理中的C的实现。

问
华为现在2B端业务使用的服务化框架是什么
答

使用了基于ServiceComb的商业版:微服务引擎CSE

问
请问一下,微服务和docker有结合吗?
答

目前ServiceComb Pack的集成测试(涉及到多个服务之间的协同)是使用docker来进行管理的。

问
可以和springcloud比较下?
答

据我所知 SpringCloud目前还没有提供分布式事务的解决方案。
我是华丽丽的昏割线

中
奖
名
单
本次直播过程中提问互动获奖的几位同学如下,快来看看有没有你!
PS:小助手发来电报,反馈了地址的小伙伴们的书已经寄出去了,但是!还有两位小伙伴至今没能联系上,所以,看到消息请于下周一(1月21号)下班前联系小助手哦~逾期就作废啦(小声说:快递指不定哪天就停啦!人家也要过年哩~)。
长按小助手微信
加入组织,互帮互助,一起学习成长~
前
排
福
利
关注公众号并评论本文,点赞前三的小伙伴,将获得由“华为云微服务云应用平台(ServiceStage)”赞助的《Netty进阶之路》赠书1本。
直播回放已生成,点击下方“阅读原文”前往观看啦~