腾讯云TDSQL审计原理揭秘

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

版权声明：本文由孙勇福原创文章，转载请注明出处:
文章原文链接：https://www.qcloud.com/community/article/244

作者简介：孙勇福，腾讯云高级工程师，负责腾讯云TDSQL产品研发，毕业至今一直从事数据存储系统运维和研发工作，在数据库领域以及NoSQL领域具有丰富的运维和开发经验。

开源数据库往往不具备商业数据库一样的高端能力，但是却因简单易用，无需license费用等深得大家喜欢，但在云服务时代，打造一款同时具备了开源数据库的性价比和商业数据库的安全性的数据库，几乎是所有使用者心中的梦想。腾讯云数据库TDSQL基于这样的考虑，实现了云化的审计能力，下面就让我们一起来看看具体的技术细节。

产品架构

各模块特点

1) proxy

三个无差别proxy Ip，保证一个或者两个proxy 故障时，剩余proxy Ip 正常工作用户无感知。
旁路信息进入kafka时，对数据进行压缩上传同时kafka必须半数节点响应成功后才算正确上传。
每个用户实例都有自己单独的proxy，在数据上传是不同实例消息并发上传到kafak的topic,保证每个用户信息及时进入审计消息队列。

2) Kafka

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输
同时支持离线数据处理和实时数据处理

Kafka解析

Terminology

Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
Partition：parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
Producer：负责发布消息到Kafka broker
Consumer：消费消息。每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。

Kafka框架

如上图所示，一个典型的kafka集群中包含若干producer（可以是web前端产生的page view，或者是服务器日志，系统CPU、memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干consumer group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。

3) audit-server

audit-server 是分布式服务，采用一致性hash算法进行路由
多协程并发处理模式保证kafka数据秒级别消费

一致性hash

在分布式集群中，对于机器的添加和删除已经故障机器自动脱离集群不影响服务是分布式集群的最基本的功能。本次审计服务采用一致性hash完成这种基本功能。

具体描述如下：按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中，即0~(2^32)-1的数字空间中，也就是将object1，object2, object3, object4 四个（假设有四个实例对象）实例对象通过hash 散列到hash环上。如图（来自于网络）

同时将三个服务节点（假设三个服务节点），通过hash也散列到hash环上。如图（来自于网络），通过找出距离自己最近的node节点，即可找到服务节点。

在服务节点添加删除或故障时实例对象都会自动的调整找到距离自己最近的服务节点进行审计服务。

同时，在引入audit-server路由时，我们发现node服务节点分布越均匀，每个服务节点的负载也就越均匀。这里引用了虚拟节点来解决这一问题。

审计策略

独立规则加载协程：在规则加载时，不影响审计规则功能区性能
优先级：策略支持用户自定义优先级，在策略匹配时，优先匹配到优先级较高的策略。
规则设置丰富: 支持规则=, !=，>, >=, <, <= 以及正则匹配。
权限：支持二次认证，保证数据安全性。

多并发协程

协程，不需要抢占式调度，可以有效提高线程的任务并发性，而避免多线程的缺点（go原生支持）

故障优化

耦合关系：保证一个子系统发生故障时，不会影响其他系统的正常运行。
审计服务故障时保障数据不丢：消息消费时会动态的记录匹配到规则的或者超过一定阈值消息的offset，保证服务被分配到其他节点或者故障服务修复启动时都会从正确的位置消费消息。
数据旁路kafka数据不丢：在数据传入到kafka是必须保证半数以上的节点响应此消息时，才进行下面的数据传输。
告警及时感知：kafka 或者MongoDB不可用时会秒级别感知，发送告警信息给系统负责人，及时恢复服务。
自动扩容：匹配规则消息存储采用腾讯云MongoDB，通过后台打通，在存储空间不够时支持自动扩容。
数据顺序性：每个消息在旁路时都会被打上一个时间戳同时消息也是按顺序进入消息队列，在数据读取时按照时间戳顺序读取。

3) 腾讯云MongoDB

腾讯云MongoDB特点

设计服务数据存储采用，腾讯云自有的MongoDB服务，该产品具备以下特点：

云存储服务，是腾讯云平台提供的面向互联网应用的数据存储服务。
提供了高性能、高可靠、易用、便捷的MongoDB集群服务，每一个实例都是至少一主一从的副本集或者包含多个副本集的分片集群。
整合了备份、扩容等功能，尽可能的保证用户数据安全以及动态伸缩能力

当然，为了用户的安全考虑，我们所有的数据，都是需要用户主动开启审计的前提下，才会记录流水数据，并对数据进行过滤和存储。

使用云数据库MongoDB服务的好处：

安全：提供在线的至少两份数据存储，确保线上数据安全。同时通过备份机制保存多天的备份数据以便于在灾难情况进行数据恢复。
高性能：集中安装专用高性能存储服务器（高内存全SSD机型）来支持海量访问。
省心：提供7×24小时的专业服务，扩容和迁移对用户透明且不影响服务。提供全面监控，可随时掌控MongoDB服务质量。

来源：oschina

链接：https://my.oschina.net/u/2987407/blog/804187

标签

Kafka

云数据

mongodb

消息队列

hash