binlog:binglog 是 MySQL 数据库开启 Row 模式时提供的二进制日志, 以 binlogEvent 形式记录对数据发生或潜在发生更改 (事务开启) 的 SQL 语句和数据, 类似于 oracle 数据库的归档日志, 可以用来查看数据库的变更历史, 数据库增量备份和基于时间点的恢复及 MySQL 的复制等.
同步监听原理: 简单来说就是模拟 MySQL 的主从复制过程, 先伪造成 slave 向 master 库发送 COM_REGISTER_SLAVE 命令注册客户端, 这样 master 才会发送 binlogEvent; 接着发送 COM_BINLOG_DUMP 命令, 并指定 binlog 文件和 Position 信息, 即可从 Master 库获得包含详细数据的 binlogEvent 二进制流, binlogEvent 包含了所有数据库的事件类型(DDL,DML,TCL, 授权等), 库表信息, 字段信息和行数据, 余下的工作经过过滤, 解析, 协议反序列化得到想要的订单数据.
Hamal 作为虚拟订单中心数据管道的入口, 其首要的任务是保证数据库数据变动的精准消费, 因此必须谨慎设计 binlog 的消费记录和异常消费后续处理机制等.
快消费: Hamal 采用类似 TCP 滑动窗口的 binlogEvent 消费的 Get 和 ACK 机制: 每次接收批量 binlog 记录, 并行解析数据的变更, 发送 JMQ 消息后确认消费(ACK), 以窗口长度作为 binlogPosition 的增长步调. Hamal 通过自产自销 MQ 消息方式继续驱动订单数据的后续业务处理, 后续过程包含数据变更的去重, DML 过滤, 存储等, 同时也可以为风控, 营销, 订单交易等系统提供个性化数据订阅服务. 这样即可以解耦 binlog 消费环节以加速消费, 又可以隔离同步监听服务和业务逻辑.
读写分离: Hamal 采集的订单数据转换成订单模型后继续流向虚拟订单中心的三重存储介质中: 传统 MySQL 数据库作为原始数据的第一重存储, ES 和缓存系统用于数据索引和分析, 以实现读写分离. 存储订单数据上, DAO 模块同样使用消息队列解耦, 订单数据存储到数据库后, 以自产自销 JMQ 的形式推送订单数据到 ES 和缓存系统以轻量化存储过程, 减少多级存储间耦合又能够均衡集群负载.
多级搜索: 作为数据管道出口, 订单网关系统 (GW) 对外提供了可定制模版数据或消息数据订阅, 数据分页查询, 订单搜索统计等服务, 是对接数据应用的关键环节. 网关系统实现了非常完备且强悍的多级平滑搜索过程, 当订单搜索超时或失败时立刻跳转到下级搜索, 降级搜索的结果反补上级数据源; 如果虚拟订单中心检索失败, 搜索会落地到产品线数据库做最终检索, 检索成功则会反补该订单到订单中心的各级存储中, 检索失败则必然是单号有误; 当虚拟订单服务完全不可用时, 网关搜索将直接降级到原产品线生产数据库拉取订单数据. 多级检索方案, 保证最完善的用户体验!
来源: http://www.bubuko.com/infodetail-3097537.html