标签

监控

工具

字数

794 字

阅读时间

4 分钟

服务端原理

架构设计

CAT服务端在整个实时处理中，基本上实现了全异步化处理。

• 消息接受是基于Netty的NIO实现。
• 消息接受到服务端就存放内存队列，然后程序开启一个线程会消费这个消息做消息分发。
• 每个消息都会有一批线程并发消费各自队列的数据，以做到消息处理的隔离。
• 消息存储是先存入本地磁盘，然后异步上传到HDFS文件，这也避免了强依赖HDFS。

当某个报表处理器处理来不及时候，比如Transaction报表处理比较慢，可以通过配置支持开启多个Transaction处理线程，并发消费消息。

消息id设计

CAT每个消息都有一个唯一的ID，这个ID在客户端生成，后续都通过这个ID在进行消息内容的查找。典型的RPC消息串起来的问题，比如A调用B的时候，在A这端生成一个Message-ID，在A调用B的过程中，将Message-ID作为调用传递到B端，在B执行过程中，B用context传递的Message-ID作为当前监控消息的Message-ID。

CAT消息的Message-ID格式ShopWeb-0a010680-375030-2，CAT消息一共分为四段：

• 第一段是应用名shop-web。
• 第二段是当前这台机器的IP的16进制格式，0a01010680表示10.1.6.108。
• 第三段的375030，是系统当前时间除以小时得到的整点数。
• 第四段的2，是表示当前这个客户端在当前小时的顺序递增号。

存储数据设计

消息存储是CAT最有挑战的部分。关键问题是消息数量多且大，目前美团每天处理消息1000亿左右，大小大约100TB，单物理机高峰期每秒要处理100MB左右的流量。CAT服务端基于此流量做实时计算，还需要将这些数据压缩后写入磁盘。

CAT在写数据一份是Index文件，一份是Data文件.

• Data文件是分段GZIP压缩，每个分段大小小于64K，这样可以用16bits可以表示一个最大分段地址。
• 一个Message-ID都用需要48bits的大小来存索引，索引根据Message-ID的第四段来确定索引的位置，比如消息Message-ID为ShopWeb-0a010680-375030-2，这条消息ID对应的索引位置为2*48bits的位置。
• 48bits前面32bits存数据文件的块偏移地址，后面16bits存数据文件解压之后的块内地址偏移。
• CAT读取消息的时候，首先根据Message-ID的前面三段确定唯一的索引文件，在根据Message-ID第四段确定此Message-ID索引位置，根据索引文件的48bits读取数据文件的内容，然后将数据文件进行GZIP解压，在根据块内偏移地址读取出真正的消息内容。