京东虚拟业务多维订单系统架构设计读后感

阅读文章:京东虚拟业务多维订单系统架构设计

文章网址:https://mp.weixin.qq.com/s?__biz=MzU1MzE2NzIzMg==&mid=2247486428&idx=1&sn=382f9d307073839f7900df7168916cf1&chksm=fbf7bb33cc80322599a586248c4bf92880374dcb8c48249c91b03170230112492b3ec628206e&scene=21#wechat_redirect

京东虚拟订单中心定位于订单数据的汇聚、变更及状态维护等。虚拟订单中心的核心功能主要围绕数据搬运工(Hamal)产品运行, Hamal 是京米依托开源项目研发的 MySQL 数据库 binlog 监听产品,在保证高可用的前提下实现了高指标的监听转换过程。

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)对外提供了可定制模版数据或消息数据订阅、数据分页查询、订单搜索统计等服务,是对接数据应用的关键环节。网关系统实现了非常完备且强悍的多级平滑搜索过程,当订单搜索超时或失败时立刻跳转到下级搜索,降级搜索的结果反补上级数据源;如果虚拟订单中心检索失败,搜索会落地到产品线数据库做最终检索,检索成功则会反补该订单到订单中心的各级存储中,检索失败则必然是单号有误;当虚拟订单服务完全不可用时,网关搜索将直接降级到原产品线生产数据库拉取订单数据。多级检索方案,保证最完善的用户体验!

原文地址:https://www.cnblogs.com/lijing925/p/11041739.html

时间: 2024-10-12 19:47:16

京东虚拟业务多维订单系统架构设计读后感的相关文章

饿了么:业务井喷时订单系统架构的演进

摘要:饿了么是一家创业公司,业务发展非常快,可能准备不是很充分,比如说监控.日志.告警.框架.消息.数据库,很多基础设施还在建设之中.在这个过程中出现一些问题是在所难免的,对系统的要求不是不能挂.不能出问题,而是出了问题要第一时间能恢复. 关于它的服务架构的演进: 图中所示是订单的早期架构图,比较简单.这个架构在2014年的时候支撑了日均10万的订单,是一套很不错的架构,依然在很多系统中完美运行.但是对于后来发展的场景,它已经曝露问题了,比如业务逻辑严重耦合.代码管理很困难,因为数据库都在一起,

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试

NET ERP系统架构设计

解析大型.NET ERP系统架构设计 Framework+ Application 设计模式 我对大型系统的理解,从数量上面来讲,源代码超过百万行以上,系统有超过300个以上的功能,从质量上来讲系统应该具备良好的可扩展性和可维护性,系统中的功能紧密关联.除去业务上的复杂性,如何设计这样的一个协作良好的系统,搭建开发人员基础平台,一直是我研究的方向. SouceCounter(版本3.3.91.79)对源代码的统计信息如下: 下面来详细解析一下这个系统的设计架构,纯.NET技术架构方案,C/S W

面向业务的立体化高可用架构设计

面向业务的立体化高可用架构设计 摘要:为了实现阿里九游游戏接入系统的业务高可用,技术人员跳出传统的面向系统的高可用的思路,转而从业务的角度来整体考虑高可用,最终实现了一套立体化的高可用架构,本文逐一展示这套立体化高可用架构的一些具体实践. 通常情况下我们在谈论高可用架构设计的时候,主要关注的是系统结构的高可用,例如主备架构.集群架构.多中心架构.我们做架构设计的时候,也主要是从系统结构本身出发,例如我们把单机改为双机.双机改为集群.单机房改为异地多机房等等. 这种以系统结构为目标的高可用架构设计

机票实时搜索系统架构设计

机票实时搜索系统架构设计 ? 不同的业务场景,不同的特征 ? 结合特征去进?设计和优化 ? 通?!=最优 ? 量体裁? 分布式系统的CAP理论 首先把分布式系统中的三个特性进行了如下归纳:    ● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) ● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求.(对数据更新具备高可用性) ● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求.系统如果不能

系统架构设计了解

系统架构设计的关键点 单一应用结构 当网站流量很小时,只需要一个应用,将所有的功能都部署在一块儿,以减少部署节点和成本,当流量增加时,通过搭建集群增加主机的水平扩展方式可以提升整个系统的性能,此时用于简化CRUD工作量的数据访问框架是关键 锤子应用架构 当访问量随着推广不断增大,单一应用的水平扩展所带来的速度提升越来越小时,此时可以将应用拆分为几个互不相干的几个应用( 没有交互 ),以提升效率,这是用于加速前端叶念开发的框架是关键 分布式服务架构 当垂直应用越来越多,应用之间的交互是不可避免的,