公司网站费用,wordpress的集成环境搭建,关于网站策划书描述准确的有,企业建设网站的功能是什么意思网上对于消息中间件的介绍文章比较多#xff0c;这里我们不再赘述#xff0c;我们换个思路来理解消息中间件#xff0c;从软件开发架构的角度来看下消息中间件是如何诞生和演进的。 一、概述 上图中P代表 Provider#xff0c;C代表Consumer#xff0c;下同。P和C是一个典型… 网上对于消息中间件的介绍文章比较多这里我们不再赘述我们换个思路来理解消息中间件从软件开发架构的角度来看下消息中间件是如何诞生和演进的。 一、概述 上图中P代表 ProviderC代表Consumer下同。P和C是一个典型的生产消费者模式也可以理解为客户和服务端。如果P生产效率为200qps200/秒而C的消费效率只有100qps长此以往必将造成数据的积压积压到一定程序应用就有可能崩溃了。
解决方案也先简单架构方案的万能公式通过中间层解决当然了也可以再添加一个C形成一个消费集群但这里我们暂时不讨论这种方案如果加一层不行就再加一层。当然了如果能一层解决的最好不要再二层是不这次的中间层就是消息中间件Kafka。
二、消息中间件的由来
紧接上图描述上面这种性能不对等的问题出现的一定会比kafka要早那么当时是如何解决的呢所以此处先忘掉kafka吧让我们从头来看下kafka是如何沉淀出来的。 性能不对等可以选择在C端加入一个中间管道-队列Queue即数据消息Msg先到达C端的队列中先缓冲一下然后再传给消息程序正式处理此处的数据在下文中就用消息来代替这样就解决了Msg积压的问题也能保证所有的Msg全能被C消费。
看似性能不对等的问题解决了但引入了另一个问题就是Queue和C同属于同一个进程如果C崩溃了话未来得及消息的消息就全部丢失了如下图所示
三、消息中间件的设计演进
1、 Msg丢失问题
如何解决呢方案也很简单把Queue独立到单独进程中就可以了 非常好没啥问题了消息不对等数据丢失问题全解决了。回头看下初具消息中间件的样子了但有一个问题就是在分布式生产环境下上面的设计对于高性能、高可用、高扩展是一点没有提呀如果Queue进程突然崩了那这设计也真够糊弄人的。所以接下来还要考虑可用和稳定的问题。
2、 高性能解决方案
这个问题很好理解呀原来Queue的两端各是一个P和C那么多增加几个就行了。 现在再看下Queue现在可以同时连接多个P和C了只要假设Queue足够NB那么这个系统理论上就很无敌了不过呢假设就是假设先不说Queue性能有多好就是无限的增加P之间的资源争抢也够Queue喝一壶的了本来P1就要发1条消息好吧还要等P2的10000条发完才能发哭死了。如下图所示好吗白设计一圈了又回到了最原始的状态的。 分析上图不就是Queue被争抢吗那么多增加几个Queue不就行了但这里的增加不是增加多个节点而是把P1和P2发送的消息分离开因为多增加节点还是解决不了问题所以就有了下面的设计
Topic设计 好吧这样一区分P1和P2的消息就分离开了相互之间不再相互影响了这里有了消息中间件的另一个概念Topic用于给不同类型消息定义一个标签。同样的P这边处理了C端也存在资源争抢的问题呀如下图
Partition 设计
虽然P端的消息通过Topic隔离开了但如果某个Topic消息过多还是会产生同样的问题现在上述的隔离方案又不能用了怎么办呢没啥好办法还得隔离 单队列再拆分吧数据多了就分开放置即采用Partition这里就有了另一个概念。非常好数据存储问题解决了。然后让C与Partition对应 这样C也不会争抢资源了。至此可以解决了大部分性能问题但还是存在问题即某个Patition中的消息过多还是会存在C端性能问题。
Consumer Group设计
既然有性能问题那么就多加几个吧。 针对每个Patition对应一个消费组每个组会从指定的队列位置消费消息指定的位置在消息中间件中称为offset。 至此好像性能问题没啥了通过各种护展和分组解决的七七八八了那么解决其它问题了哈。 3、高可用解决方案
上面我们对Queue的设计全是单机进行的时间一长肯定会引发单点问题这个是不可接受的。
Broker
解决吧即然是单点那就多加几个节点了。 如上图我们把不同的Prtition放布到不同的节点上这样可以减少一些单点问题。至少当机器A宕机了只丢失了Partition1和Partition2的数据还保留了一部分。没办法还得解决呀
Replicas
增加副本吧给机器A和B分别增加副本使其数据保持一致这样当机器A坏了机器C顶上就行了如果机器A和C同时坏了呢那就增加了机器D这样1主2副本同时坏的可能性不大了吧。 那么问题又来了当机器A坏了机器C咋顶上谁来切换总不能每次出问题了穿衣下地、打车去公司切吧真要这样黄花菜都冻冰了。估计程序员也会凉凉了。所以还是自动吧。
Leader和Follower
怎么个自动法呢好办我们把主和副本机器分别标注一下角色主称为Leader 从称为Followr然后呢再指定一个管理者Manager然后让Manager与L和F互相通信实时监控这时当Leaer坏了Manager就指定一个Follower为新的Leader这样就成了一个自动切换程序了程序员们也可以晚点凉凉了。 上面需要注意Leader和Follower不能位于同一个主机上呀如果位于同一个机器上那么Manager也无能为力了所以要放在不一样的机器上。
我们已经做的很好了但老天不做美停机了整个IDC机房都停电了。这回切也没用了一锅端了。 哎还得解决呀。 manger 这种自动选举机制可集成zk这样的软件来处理。 4、 高扩展解决方案
如上如果停机这东西无法处理那么扯啥呢。解决吧不就是丢数据吗kafka数据在运行时数据是存放在内存中的。
那么存磁盘吧。 不错当时存磁盘来电了后重启服务从磁盘重新加载就行了。至于能不能全部恢复那么就不再处理了吧实际上可以做到0数据丢失。到这差不多了。 可是但可以是磁盘毕竟空间有限你这成天往里存一会就爆了内存是同样的道理。
过期策略
没用的数据就删除了吧。 定几个超时策略吧FIFO还是FILO自己按场景选择吧。 EN差不多了基本可用了吧。 四、 小结
一套组合拳下来一个简单的队列就完成了现在的MQ消息中间件了。起个名吧就中Kafka。 您学废了吗
