OSC 第 120 期高手问答 -- 分布式实时处理系统:原理、架构与实现

开源中国股瞎 发布于 2016/07/12 18:30
阅读 10K+
收藏 23
OSCHINA 本期高手问答(7月13日- 7月22日) 我们请来了@samblg (卢誉声)为大家解答关于分布式实时处理系统:原理、架构与实现方面的问题。

@samblg (卢誉声),Autodesk系统软件研发工程师,从事平台架构方面的研发工作。在此之前,他曾在思科系统(中国)研发中心云产品研发部工作多年,并参与了大 规模分布式系统的服务器后端、前端以及SDK的设计与研发工作,在分布式系统设计与实现、性能调优、高可用性和自动化等方面积累了丰富的敏捷实践与开发经 验。他主要从事C/C++开发工作,致力于高性能平台架构的研究与开发。此外,对JavaScript、Lua以及移动开发平台等也有一定研究。著有《分布式实时处理系统:原理、架构与实现》一书。

本书由多位大数据专家联袂推荐,Autodesk资深系统研发工程师撰写,参透大规模分布式实时处理系统。抽丝剥茧,从概念、原理到分布式实时计算框架实现,兼顾理论与实践,带领读者逐步实现一个高性能、基于C++11的分布式实时处理系统Hurricane。
 
为了鼓励踊跃提问,@华章图书 会在问答结束后从提问者中抽取 5 名幸运会员赠予《分布式实时处理系统:原理、架构与实现  》一书。

购买链接:http://item.jd.com/11965338.html

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就 分布式实时处理系统:原理、架构与实现 方面问题向@samblg (卢誉声)提问,请直接回帖提问。
加载中
0
华章
华章

OSC 第 120 期高手问答 -- 分布式实时处理系统:原理、架构与实现(公布中奖名单)

@Nick_路  @吹乱我的发  @The blood elves   @jerrywong @pangtouy

恭喜以上五位网友获得《分布式实时处理系统:原理、架构与实现》一本

请私信@华章 告知快递信息(格式:姓名+电话+地址+邮编

2
Nick_路
Nick_路

@samblg :   我觉得, 分布式最恶心的应该是分布式事务, 带来很多诸如 某个服务timeout (重试 / 不重试 )引起的连锁反应. 对于分布式事务, 有较好的解决方案么? 

Nick_路
Nick_路
回复 @samblg : 多谢老司机
s
samblg
已回复在下方
1
吹乱我的发
吹乱我的发
@samblg : 你好,我想问一下目前是否有新的概念或者思路去打破分布式系统的CAP定理?
s
samblg
在目前我接触的应用领域里Lambda架构可以部分解决这个问题,当然在实时业务处理方面也有不足,并不是万金油。
ihuotui
ihuotui
cap已经是理论上无解了。
1
s
samblg

引用来自“Nick_路”的评论

@samblg :   我觉得, 分布式最恶心的应该是分布式事务, 带来很多诸如 某个服务timeout (重试 / 不重试 )引起的连锁反应. 对于分布式事务, 有较好的解决方案么? 

非常抱歉,这里的确无法给出一个通用的解决方案。我们需要根据具体问题对数据一致性的要求来确定解决方案。

如果想要确保强数据一致性,好的方案应该就是构建一个事务框架,当事务中一部分失败后自动回滚,我相信大多数强一致性应用都是这么做的,而且不少框架的行为也是如此。而Hurricane对事务性的处理策略就是这种方式。

但是上面那种方式可能会导致难以容忍的性能问题,这时候就不存在一个通用方案可以解决这个问题。基本的优化思路应该是只重新处理那些需要重新处理的部分,而不是整个事务的回滚,但这样应该就是要涉及到事务的细化(将一个大事务划分成许多小的事务)。比如像HurricaneStorm其实也可以采用这种策略(以单个节点或部分节点为回滚单位)。不过实现起来就要更加复杂了。

s
samblg
回复 @Nick_路 : 既然是分布式系统,那么就可以在服务分发进行处理。升级需要注意有控制性地局部升级,正在升级的服务器暂时不接受请求。如果升级过程中涉及依赖问题,那么就要扩大升级的控制范围,将每个服务和其依赖的且需要升级的服务看成一个整体,当这些服务都升级完毕的时候这些机器才能接受请求,相当于每个服务的worker都有启用/停用的状态。总之想要构建一个全自动的热升级系统的确非常复杂。
Nick_路
Nick_路
非常感谢! 另一个问题, 如果将事务拆分成了N个较小的单元,那在消费的过程中就极有可能产生循环依赖( A --> B -->C -->A) 这种情况下就很有可能因为依赖的服务还没有发布新版本导致一些异常,并直接影响一部分用户的使用. 生产环境部署的时候,有什么建议么?
0
xpbob
xpbob
@samblg :我感觉分布式最麻烦的就是数据的统一,有时候需要引入分布式的锁,但同时锁带来了很多问题,有比较好的方法规避吗
xpbob
xpbob
回复 @samblg : 学习了,谢谢指导
s
samblg
最后一种可能性是确保非常弱的一致性,那么B也会扣票成功,这个时候只能采取业务上的弥补方案,比如向B赔钱。 所以是否采用分布式锁,采用何种锁完全取决于你的业务以及对实际情况的取舍,并不能完全规避。如果你能牺牲一定的数据一致性,那么就可以采用比较弱的锁或者不适用锁。
s
samblg
但如果我们只确保单调读一致性,可能在服务器扣票失败之后B依然还能看到1张票,但永远无法成功扣票,但是如果1分钟之后再次刷新,可能就看到该车次无票了(根据实际经验,12306大概用的是这种模型),在这种情况下扣票业务必须上“写锁”,但是不必要上“读锁”,而且可以从本地缓存中读取数据,只要一定时间刷新过期数据即可。
s
samblg
如果我们采用强一致性,那么B必定扣票失败,并且看到该车次已经无票,这种情况下就需要使用悲观的分布式锁,确保数据完全同步。
s
samblg
而对于12306这种系统,我们可以根据实际情况进行权衡。举个例子,如果系统中还剩下1张票,A和B两个人同时买票,都看到该车次仅有1张票,且A先于B扣票成功。
下一页
0
j
jerrycai_hf
@samblg : 卢老师好,我对分布式实时处理系统很感兴趣,而且在日常工作中也涉及到,想问下 分布式实时处理系统 在同步和一致性方面,有没有现成的框架或者模式 可以复用?
0
j
jerrycai_hf
@samblg  另外,还有个问题就是关于卢老师写的书 分布式实时处理系统:原理、架构与实现 ,想买一本好货学习下,能先介绍下该书对分布式实时系统如此 hot的情况下,的主旨思想是什么吗?



0
stroller
stroller
@samblg : 卢大神,您好,请问现在的分布式实时处理系统很多,而且开源的也很多,基本每个组件都有,例如分布式协调器,分布式日志,消息队列等,所以请教下大神,以后是不是自己开发的越来越少,反而更多是组合起来应用?
0
jerrywong
jerrywong

@samblg :卢老师您好,我对实时数据处理方面的事务性原理非常感兴趣,能否简单归纳一下事务性实现的基本思路呢?

另外,实时数据处理一般能应用在哪些领域?刚毕业,想从事这方面的工作。谢谢。

0
s
samblg

引用来自“jerrycai_hf”的评论

@samblg : 卢老师好,我对分布式实时处理系统很感兴趣,而且在日常工作中也涉及到,想问下 分布式实时处理系统 在同步和一致性方面,有没有现成的框架或者模式 可以复用?
不知道你想要同步哪些信息或是维护哪些数据的一致性。
在分布式系统中,进行分布式同步和一致性维护上最著名的开源项目应该就是ZooKeeper。我们常常使用ZooKeeper维护集群中不同节点的元数据(确保这些数据的同步和一致性),并借助其完成leader节点的筛选。但这种方案并不适用于完成大量业务数据的同步。
如果是分布式实时处理系统的业务数据同步,一般会使用分布式数据库自己的集群功能,完成数据库数据的同步和一致性管理,需要的就是适当配置参数。
返回顶部
顶部