ClassIn：如何打造更稳定的Zabbix监控系统

提及翼鸥教育可能大家比较陌生，但说到北京大学、清华大学、中国科技大学、上海交通大学等数十所高校所在使用的ClassIn，应该就有不少人有所耳闻。而ClassIn就是由翼鸥教育打造的核心产品。

此前，翼鸥教育的业务数据主要存储在MySQL，生产环境有近百套集群，数据库架构也主要是MySQL主从架构，业务通过读写域名的方式访问数据库。另外，针对核心的、数据量较大的集群，翼鸥教育也进行了分库分表。

但在使用MySQL的过程中，翼鸥教育遇到了三个棘手的问题。首先，读写卡顿。由于疫情期间的网课盛行，翼鸥教育的业务也实现翻倍，流量猛增，但因为MySQL属于单机版数据库，无法像分布式数据库一样做到平滑的水平扩展，导致线上许多集群存在明显的读写瓶颈。其次，容量局限。依旧是前面所说的问题，随着翼鸥教育的数据快速增长，许多大表开始超负荷，磁盘空间慢慢遇到容量瓶颈，导致运行不畅。再者，分库分表的历史遗留问题。由于一些历史原因，翼欧教育线上的分库分表分的并不彻底，分表之间也存在关联的一些操作。这些不合理、不规范的使用，导致数据库不断出现新的问题。以上三个问题，大大影响了翼鸥教育的业务数据使用、存储与导出，为了更好地适应公司的业务发展，其开始寻找新的数据库解决方案。而这一次，他们把目标投向具备水平扩展、高可用以及数据强一致等优势的分布式数据库，并锁定了OceanBase。

相较于 MySQL，OceanBase 的优势更加显著。

首先，数据容量上，OceanBase 可以把业务数据压缩至 MySQL 的 1/5 甚至 1/4，在相同规格的机器上，这样的数据压缩率可以支持企业存放期限更长的监控数据，一些线上数据迁移到 OceanBase 后的大小和压缩率如下表所示。

可以看出，针对不同的表，OceanBase 的数据压缩率也不同。综合来看，平均压缩率是 4.71。

其次，数据读写方面，由于 OceanBase 是基于 LSM-Tree 的分布式数据库，所以在数据写入方面有天然优势。根据生产环境规格的机器 sysbench 写入性能测试的结果，OceanBase 的综合写入性能是 MySQL 的 3 倍以上。

最后，针对分区表的维护，OceanBase 的Online DDL特性使它对分区表的维护非常平滑，不需要特定维护窗口停监控系统去做分区表的维护。在 OceanBase 3.x版本中，如果表的数据比较大，需要使用者进行手动分区，在 OceanBase 4.0 版本后，开始支持大数据自动分区。并且，truncate 表分区都是秒删，数据清理非常方便。相比之下，MySQL 在清除分区的时候不仅会锁表，还会造成大量的磁盘I/O。

另外，OceanBase支持多租户和资源隔离，也是翼鸥教育格外看重的点。一个集群在承担众多业务的情况下，做到业务不互相影响是非常重要的。同时，当使用者遇到问题时，在OceanBase 社区也能快速得到解决方案，并且为了能让客户及时收到别人对自己提问、解答的回复，OceanBase还特别设置了消息提醒，通过服务号绑定社区帐号就能在问题得到解答时第一时间看到，十分人性化。

基于优秀的使用体验，是翼鸥教育决定在核心业务中使用 OceanBase 数据库。未来其将把MySQL集群数据汇聚到OceanBase，通过租户隔离供大数据抽取和大后台业务使用。同时还会将部分增量数据通过OMS同步Kafka供大数据实时场景消费，并会陆续在其他业务中接入OceanBase。