美文网首页
第四章数据编码和更新-part4,designing Data-

第四章数据编码和更新-part4,designing Data-

作者: cheng_e819 | 来源:发表于2018-02-19 16:28 被阅读0次

    消息队列数据流

    这部分会简要介绍一种异步消息传递系统,在某种意义上讲是在数据库和RPC的折中方案。他与RPC相似点在于都是一个客户端用一个很短的延迟将请求传递给另一个进程。他与数据库相似点在于他并不是通过网络直接将数据发送给对方进程,而是通过一个消息传递代理,message broker,broker可以临时储存消息。跟RPC相比,消息队列有几个明显的好处

    • 当接收方临时不可用时,broker可以充当缓存临时将消息储存起来,这就提高了整个系统的可靠性。
    • 当一个处理进程崩溃后,他能够自动的将没处理的消息重新发给另一个处理进程,使得消息不会丢失。
    • 发送客户端不在需要知道接收进程的ip和端口号,这在云端部署的时候特别有用
    • 允许一个消息发送给多个接收方
    • 在逻辑层面上将客户端和服务器,在消息队列中我们称为发送者和接收方,进行了解耦。发送发只需要发布消息,而不再关心谁去消费这些消息

    但是有一个问题和RPC不太相同,消息队列只是单向的。也就是说发送方没办法指望从接收方获得什么反馈。如果硬要发送反馈也是可以,但是一般都是通过另外一个消息通道完成的,也就是说这是一个异步的过程。发送方只管发送消息,不管这个消息是不是已经投递给了接收方或者是不是已经处理过了。发完了就不管了。

    message broker(消息传递中间件)

    过去这个组件都被大型商业公司承保了,但是现在有很多开源工具可供选择,RabbitMQ, ActiveMQ, HornetQ, NATS, Apache Kafka 都是比较有名的工具。消息队列的实现细节在不同项目中都不相同,总的来说都是这么一个流程。一个进程将消息发送到一个指定名字的队列(queue)或者主题(topic)中, broker保证消息能够至少传递给一个消费者(consumer) 或者订阅者(subscribers), 对于同一个topic,可能会有多个生产者和消费者。

    一个topic一般都是单向的数据流,但是消费者可能同时需要发布消息给另一个消费者,这就形成了一个生产消费链,上级发送消息给下一级,下一级再生产消息给下下一级。或者消费者需要把消息发送到反馈队列传给发布者,这就和RPC的request/response模式很像了。

    message broker不对数据模型有任何要求,因为一个消息只是一个字节流儿加一个metadata而已,所以你可以使用任意编码格式。如果你的编码能够做到向前向后兼容,那就就获得了极大的灵活性。你可以任意的修改你的发布者和消费者,或者按照任意顺序去部署他们。

    如果你的消费者需要再发布一个消息到他的下游,你需要注意保留那些未知字段,就好像之前数据库遇到的问题一样,不要出现把新加的未知字段搞丢的情况出现。

    分布式actor框架

    actor model 是一种编程模型,他能让你编写的单进程得程序获得并发的效果。每个线程在逻辑层面封装成一个actor.每个actor实际代表一个线程或者某一个实体。这些实体拥有自己的内部状态,这些状态并不与外界共享,他们通过异步发送和接收消息的方式和其他actor进行通信。消息的传输是不可靠的,在特定的场景下,消息是可能丢失的。每个actor每次只处理一个消息,所以也不用操心什么多线程的问题,那些死锁或者其他奇奇怪怪的问题都不用担心了。 另外每个actor可以由框架独立部署。

    在分布式actor框架下(distributed actor frameworks), 这个编程模型可以方便的把一个应用部署成多机应用。无论消息的发送者和接收者是不是在同一个节点上,他们都是用相同的消息传输机制。如果在不同节点上,那就会消息编码成字节流,发送到对应节点然后进行解码处理。

    actor model相比RPC,有着更好的位置透明性,也就是你不再需要关心你的接收方到底是跟你在同一个机器上,还是不在。因为actor model本身就假设消息是可能会丢的,所以有些事情模型框架就帮你处理了。尽管消息如果通过网络进行传输,在延迟上会比在单机上处理慢,但是整体上来说,本地和远程通信在actor model下的区别还是要少一些的。

    一个分布式的actor框架就是把一个broker和一个actor model集成为一个框架。尽管如此,如果你想做到灰度更新,你还是需要担心向前向后兼容的问题。

    下面是3个主流的框架,

    • Akka使用java默认的编解码库,并不提供向前向后兼容性。但是你可以把它编码库替换掉,比如用Protocol Buffer就可以支持灰度更新了。
    • Orleans默认情况下使用自定义的编码格式,无法支持灰度更新。如果你要更新你的数据格式,你需要启用一个新的消息集群,把老的集群的消息导到新的上面,然后停掉老的(这简直了啊!)但是他和Akka一样,可以替换掉默认的编码库
    • Erlang OTP,十分令人吃惊,修改消息的schema是一个异常困难的事情。灰度更新虽然可以,但是要十分十分的小心。一种目前还在试验的数据类型,map,可能会让他在未来方便一些。

    相关文章

      网友评论

          本文标题:第四章数据编码和更新-part4,designing Data-

          本文链接:https://www.haomeiwen.com/subject/kggitftx.html