• DFighting
    2019-10-25
    其实存储计算分离在数据的相关性不大的情况下优势会很明显,我理解这种是对数据和计算进行了一种操作和对象的切分,在大多数情况下,操作和对象的耦合度不高,可以使用,因为无状态、单一功能这就是微服务架构的优势。但是这里有个天然的缺陷就是牺牲了大量的磁盘读写和网络IO的性能,如果计算和对象耦合度过大,也就是计算需要频繁读写多数据源的数据,那这种就不如传统的MQ了。不过随着数据量的增大,读写计算分离应该是趋势,如果数据和计算耦合度过高,优先思路应该是重新划分业务模块和整合数据源,把耦合相关的劣势转换为优势,不过这一点很难,需要业务专家、技术专家、架构专家和数据专家等的一起努力。

    作者回复: 👍

    
     5
  • 好好写代码
    2019-09-26
    消息队列大部分应用的场景还是需要快速去消费数据,吞吐量比持久化优先级高。
    
     2
  • DFighting
    2019-10-25
    读了文章才发现,我们使用Flink做ETL真的很不适合,因为Flink适合计算,存储应该另外设计,系统设计存在明显的缺陷
    
     1
  • 亚洲舞王.尼古拉斯赵...
    2019-10-11
    我有一下的几点想法:
    1.性能方面的考虑:像文中说的,使用计算存储分离的设计方式,原本broker只需要在本地进行消息查找,但是现在却需要连接到另一个集群中进行查找消息,增加了网络耗时,一旦并发大,带宽占满了,性能就会明显下降。
    2.成本原因:
    这里的成本包括两方面:一方面是部署成本,本来只需要一个集群部署,现在我还好增加一个存储集群,增加了使用者的钱方面的成本;另一方面是使用者的学习成本,新引入一个集群,无论使用的是什么存储系统,如果想要更好的解决可能出现的问题,使用者都要去学习这个新的存储系统,增加了使用者的学习成本。
    展开
    
     1
  • 游弋云端
    2019-09-26
    个人觉得从微服务的思想来讲,专业的人干专业的事,进行服务的细粒度拆分,不做大而全的系统,这样架构清晰,可扩展性强。其他消息队列适合快速部署,可以做到对外依赖少的精简配置,例如kafka要去ZK,要支持单节点配置等,这与Pulsar是不同的。在后续的微服务、容器等演进的趋势下,个人认为Pulsar会更具有竞争力。目前来看,只能说各有千秋,各有不同的应用场景。
    
     1
  • 峰
    2019-12-25
    本来就是数据管道结果管道还要套层管道,计算本来就很轻,分离出去一种浪费的感觉。
    
    
  • Jxin
    2019-11-10
    回答问题:
    1.mq这一侧的计算复杂度和存储管理难度都未到做更细拆分的程度。
    2.在这些mq出来前,k8s这种容器编排的方案还没有。做结构拆分势必会增加复杂度,导致入门门槛提高,进而就不易于推广。而开源项目,亲和易推广也是很重要的指标。



    自己的想法:
    存储层在引入k8s的pv,pvc管理后,存储的管理复杂度就可以跟业务开发说再见了。毕竟上云后,这块东西就由云服务商承接走了。这样有利于更轻量的开发,亲和拥抱变化的市场环境。所以老师说是趋势。
    展开
    
    
  • boyxie
    2019-10-30
    可以用在对实时性要求不高的应用,比如定时任务类型的,可以存储海量数据
    
    
  • 张天屹
    2019-09-27
    老师你好,请教一个本章的题外问题,对于严格的局部顺序性要求场景,比如十个分区,十个消费者线程,一一对应是可以保证的。但是绝不能一对多/批量预取,这个不设置多线程消费就可以了,但是在进程角度的话,为了保证顺序性,一个分区也只能被一个进程消费,那就没办法做消费者集群了吗,只有一个单体的消费者服务的话,可靠性是不是不太好,如果宕机了下游就完全挂了,这种情况怎么办呢?

    作者回复: 使用消息队列来保证严格顺序时,对于消费者是没有要求的。不需要单线程或者单进程,所以使用消费者集群是完全没有问题的,依然可以保证严格顺序。

    消费者唯一需要保证的和接收普通消息是一样的,就是:先执行消费逻辑,再确认消费。

     2
    
  • Better me
    2019-09-26
    消息队列本身作为中间层应该以提升更好的性能为导向,但目前Pulsar的存储计算分离架构等于在中间层在分层,在架构上可以做到服务化单一职责,以及无状态的broker节点,但却有少许的性能损耗,如果以后能解决性能损耗的问题,那么存储计算分离架构必然是未来的趋势
    
    
  • A9
    2019-09-26
    是否使用存储计算分离也是一种trade off的体现。采用分离的架构,整个架构上模块更加清晰,能够降低开发成本,提升开发效率。不采用存储计算分离的架构,可能开发难度较大,不过整体效率更高。对于开发消息中间件来说,尤其是之前消息队列诞生时,计算机性能普遍性能交叉,可能牺牲一点开发的效率,获取更高的性能才是更重要的。
    另外,最近流计算的流行,同样的存储计算分离架构可能有能直接进行配合(并不太了解流计算)
    总结来说,算是诞生的时代背景占了相当大的原因吧
    
    
  • leslie
    2019-09-26
    不一样的思路:非常喜欢老师这种方式,不仅仅是基于当下,而是持久;让我觉得不仅仅是一个User,而是在User中去扩展。
          就像之前学计算机组成原理是徐老师曾经提过基于CPU的MQ:当时问徐老师为什么有了CPU还需要有GPU?老师让我去看David Patterson老爷爷的文章,包括现在阿里做的GPU减负的是内存,应当是差不多的不一样的思路吧。
         感谢老师分享不一样的新东西:让我们不仅仅基于当下、研究当下,甚至可以在MQ的方向上扩展研究下去。期待老师后面的继续分享。
    
    
  • 有铭
    2019-09-26
    消息队列的性能是个很重要的需求,既然存储计算分离了也就等于加了中间层。我们都知道加了中间层那是会损失性能的
    
    
我们在线,来聊聊吧