如何分析ApacheTubeMQ数据可靠性

这篇文章主要为大家分析了如何分析Apache TubeMQ数据可靠性的相关知识点，内容详细易懂，操作细节合理，具有一定参考价值。如果感兴趣的话，不妨跟着跟随小编一起来看看，下面跟着小编一起深入学习“如何分析Apache TubeMQ数据可靠性”的知识吧。

创新互联专注于余江网站建设服务及定制，我们拥有丰富的企业做网站经验。热诚为您提供余江营销型网站建设，余江网站制作、余江网页设计、余江网站官网定制、微信小程序开发服务，打造余江网络公司原创品牌,更为您提供余江网站排名全网营销落地服务。

1. 前言

我们在Apache TubeMQ的适用场景有介绍，TubeMQ适用于极端情况下容忍少量数据丢失的业务场景，那么TubeMQ到底在什么情况下可能会出现数据丢失？为什么要这么设计？同类MQ在这方面是怎么做的？这篇文档计划解答这几个问题。

2. 结论

Apache TubeMQ系统数据存储采用的是单节点多磁盘RAID10的副本方案进行存储，数据只在如下场景存在可能丢失情况：

机器断电，已回复成功但还没有被消费且处在内存中的数据会丢；机器上线后，已存储在磁盘上的数据不受影响；
RAID10 hold不住的磁盘异常，已返回成功但还没有被消费的数据会受影响；磁盘修复后，已存储但没有恢复回来的数据会丢失；
RAID10 能hold住的日常坏盘，坏盘Broker节点的生产和消费不受影响；

3. 能否给出一个量化的数据可靠性指标来评估Apache TubeMQ系统的可靠性？

这个问题也是交流最多的一个话题，大家最直观的感受是：机器很容易挂，TubeMQ只有单节点，数据的可靠性是不高的。这里个人的观点还是如其他场合介绍里一直表达的：用数据可靠性指标来反应系统的数据可靠性其实是不太合适，因为它只是反映了系统数据可靠性的果，对如何解决数据可靠性其实没有太直接的关系；从介绍的数据可能存在丢的场景介绍我们可以看到，生产环境的机房情况、服务器硬件情况，以及业务能否即时消费完数据等直接影响到系统的数据可靠性，是这些内容故障导致了系统数据可靠性的高或者低，如果没有上述这些问题，TubeMQ系统的数据可靠性其实就是100%，所以，我们应该通过对应环境导致数据可能丢失的故障率指标来评估、分析系统的数据可靠性，个人觉得这个是根本。

按照2019年我们线上环境的故障数据统计，TubeMQ集群在我们环境，全年导致数据可能丢失的故障率大概是2.67%：整个TubeMQ集群1500台机器，日均有35万亿条的数据接入量前提下，全年大概有40台左右的服务器出现过机器ping异常，以及RAID10 hold不住的磁盘组损坏异常。个人觉得我们环境的故障率指标还可以再降低，因为TubeMQ集群里用的机器多是重点业务用了几年后淘汰下来的二手机器设备。

4. 为什么要将Apache TubeMQ设计为单节点存储？

降成本：大家都知道，要达到完全100%的数据可靠性是非常耗费成本的，一个MQ管道要做成类似太空飞船设计样构造多套独立节点的冗余数据备份，来保证数据不丢；而从我们的分析来看，通过MQ传递的业务数据，90%左右的数据是可以容许极端情况下丢失少量数据的，有10%左右的数据是要求一条都不能丢，比如交易流水，涉及到钱相关的日志数据等；如果我们将这10%的高可靠数据单独拎出来处理的话，我们就可以节约大量的成本，基于这个思路，TubeMQ负责完成要求高性能、极端情况下容许数据少量丢失的数据服务。如何分析Apache TubeMQ数据可靠性

如上图示，除了方案上的考量外，我们在TubeMQ的存储方案设计上也是做了仔细的斟酌：我们按照Topic维度进行了数据和索引的组件；我们在文件之上再叠加了一层内存存储作为磁盘文件存储的延申。但我们又没有因为业务容忍少量丢失而完全的无所顾忌，比如：我们数据生产采用的是QoS1方案；我们的数据存储是有强制的缓存刷盘（按条、按时间、按size）控制的刷盘控制；我们的磁盘故障是有服务端基于运营策略的Broker节点自动只读或者下线管控（ServiceStatusHolder）；生产端针对Broker节点的服务质量也是有自动异常节点感知和算法屏蔽，等等等等，以此来达到高性能同时尽可能的提高数据的可靠性，降低数据丢失的可能。

能降多少成本？拿外部多个使用Kafka的厂商已经公开的运营数据来看，1万亿日均接入量，Kafka大概需要200 ~ 300台万兆机，按照2019年的运营数据，TubeMQ大概40 ~ 50台万兆机；这里还包含一些可以区分的特殊情况，比如独立集群、特定业务份数的不同等，但机器的成本指标数据的比值应该是相差不大的。如果把这些数据指标换算成钱的话，这个节约的成本仅服务器成本都可以以亿单位来计算。

也有人会说，是不是我拿Kafka的单副本进行业务服务，就可以达到TubeMQ一样的成本效果了？我想表达的是，如果可以的话，我们就不会耗费这么长的时间和资源去改进TubeMQ，直接使用Kafka单副本方案了，在我们开源初期做过一份全面的单Broker的性能压测对比总结报告tubemq_perf_test_vs_Kafka，大家可以在上面找到对应的具体差异。

这里想表达的是，实际上，TubeMQ系统本身的数据可靠性其实并不低。这里大家有没有想过，各个MQ，在多副本方案下，系统数据可靠性又有多高呢？

5. 同类MQ的多副本方案分析：

Kafka：以我个人分析的观点，在高性能场景下Kafka的多副本方案也只是尽力而为的保证数据多副本存储不丢。

Kafka副本机制通过一个AR集合以及ISR集合来识别和区分副本份数以及在线同步副本数，通过replica.lag.time.max.ms参数记录各个副本最近同步的时间来判定各个Follower是否仍与Leader处于同步在线；在0.9X版本之前Kafka还有另外一个已经去掉的replica.lag.max.messages参数，Follower副本滞后Leader副本的消息数，结合起来判定失效副本。线上运行时Kafka又通过ISR的个数及请求的副本应答个数保证数据多个节点存储：服务器端通过min.insync.replicas来确保ISR里最少处于同步状态的副本个数，客户端可以指定请求的Ack个数（0：不应答，1：Leader存储即OK，-1：所有ISR节点都应答）结合起来确保数据可以被多个副本所接收。

从这个机制的设计我们可以很清晰的看到，即使是Kafka的设计者，也是很清楚数据很有可能没有从Leader同步到各个Follower，存在复制不及时的情况，所以将ISR识别由（滞后条数，同步时间）改为了（同步时间），因为滞后量太大影响到了ISR副本数的判定。而这个ISR的副本数又影响到了对应Topic的写入，如果Topic的ISR个数为0，原生Kafka是无法写入消息的；为此Kafka又增加了一个unclean.leader.election.enable参数，允许未处于同步状态的Topic副本可以选为Leader对外服务，做尽力而为的服务。

从如上分析，在大数据场景下Kafka的这种副本机制，可以满足回溯消费业务需要，主副本所在机器故障后，已经同步到副本的数据可以被回溯业务消费到，但是，由于上述问题存在数据丢的问题，对于要求回溯并保证数据不丢的场景无法满足；同时，这种方案资源消耗大利用率非常的低，按照2副本的配置，资源增加了至少1倍、网络带宽下降1/2，同时为了避免2副本形成ISR为0的情况，使用方很有可能配置3副本，从而资源增加更多而资源利用率则更低，用如此高的成本维系的却是一个不可靠的数据服务，方案并不廉价有效；最后，Kafka在分区无副本存活时阻塞生产流量直接掉0，这对大流量环境的业务个人觉得是无法接受的，而即使采用配置3副本模式，因为3副本保活是动态的，极端情况下仍然存在生产受阻问题。

Pulsar：以我个人的分析观点，可以保证数据不丢，但大数据场景下是有影响的。

Pulsar采用了类似Raft协议模式，多数副本写成功即返回成功，并且是采用的服务器主动Push请求到各个Bookeeper副本节点的模式。这种实时的多副本同步方案可以满足绝大多数的高可靠业务需要，用户的眼睛是雪亮的，我想近期的Pulsar火热，也是与它满足了市场上这方面业务需求有关系。不过，如果把它放置在大数据场景下，上千的Topic上万的Partition时，这种多副本方案就需要耗费大量的机器资源。所以，我们TEG数据平台部对于高可靠的数据，使用的是Pulsar对内进行服务；同时我们也将我们对Pulsar的改进捐献给社区。

TubeMQ：就如其适用场景介绍，TubeMQ就是为了满足在容忍极端情况下允许数据少量丢失的业务数据上报管道需求，结合业务成本、数据可靠性的要求走了一条不一样的自研路，针对致命异常在系统可靠性上也达到了不一样的效果：

只要Topic分配的Broker集合里还有任意一台Broker存活，该Topic的对外服务都可用；
基于第1点，只要集群里所有的Topic都还有任意一台Broker存活，整个集群的Topic对外服务都是可用；
即使管控节点Master全部挂掉，集群里新增的生产、消费会受影响，但已注册了的生产、消费不受影响，仍可继续生产和消费；

TubeMQ基于有损服务的前提下采用尽可能保证数据不丢、服务不受阻的思路进行设计，力求方案简单维护简便：TubeMQ的设计里，分区故障并不影响Topic的整体对外服务，只要Topic有一个分区存活，整体的对外服务就不会受阻；TubeMQ的数据时延P99可以做到毫秒级，这样保证了业务可以尽可能快的消费完数据，做到尽可能不丢；TubeMQ独有的数据存储方案设计性能要比Kafka的TPS至少高出50%以上（有些机型上还是翻倍的效果），同时借助存储方案的不同，单机容纳的Topic数和分区数更多，进而可以使得集群规模更大，减少维护成本。这些不一样的考虑和实现结合起来从而使得TubeMQ做到低成本，高性能，高稳定性基础。

关于“如何分析Apache TubeMQ数据可靠性”就介绍到这了,更多相关内容可以搜索创新互联以前的文章，希望能够帮助大家答疑解惑，请多多支持创新互联网站！