核心业务需求及逻辑架构分析

简介:
12306的已知信息、数据及问题
  需求分析(一)—— 售票系统领域知识(区间票、订票、预留票)
  需求分析(二)—— 涉众、用户体验
  核心业务需求及逻辑架构分析
  需求分析(三)—— 票仓
  票仓设计(一)—— 预生成车票方案的优缺点
  票仓设计(二)—— 区间二进制方案的优缺点
  票仓设计(三)—— 平衡方案的优缺点
  票务并发冲突处理原则设计(基于平衡方案)
  缓存逻辑架构设计
   数据库逻辑设计
  灾难备份与恢复
  快要太监了 :-(
  由于各种个人原因, 铁道部的这个博文系列中止了很久。最近终于连自己都不好意思了。所以还是继续完成它吧,估计1-2周一篇的节奏。
  感觉不先划分一下大的系统架构总会让大家感觉有点头晕, 不过没能力对整个12306进行设计,这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想
   朴素的面向对象分析
  面向对象是一个万金油,但是据说真正懂的人不多是吧?
  我对面向对象的感觉就是: 他本质上是对现实世界的抽象,其表面现象是不断细分对象的粒度,提升对象的抽象度。最终形成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。
  而系统级别的分析也大致如此,我们可以借鉴类分析中的很多概念,不断划小系统规模,剥离职责,抽出依赖性。
   一般系统结构
  这里只是一个简单模型,用以表达我对多数项目的结构分析。
  配置数据服务:系统运行所需要的动态配置信息
  资产数据服务:所有实际或虚拟的“物”的管理(CRUD),甚至可以包括人。
  业务数据服务:该企业实际经营的业务产生的数据。超市的收银记录,企业的销售记录,铁道部的售票记录
  报表数据服务:各类统计报表需要的
  其中业务系统和业务数据服务应该是最核心的部分。
  一般而言,那些配置和资产管理的部分不会造成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求,努力做到任何资产的属性变动时,确保相关的业务完整性就好(出租公司管理系统里,一辆出租车今天还在运营,后台系统绝对不应该可以轻松地把它标记成报废车辆,连软删除都是不合理的做法)。
  12306之所以能招全国人民围观,我觉得主要还是花的钱和大家的感受之间有落差。而我阴暗的以为这个问题的核心部分就在票务处理的部分。
  所以我后续的几篇博文都会围绕票务处理里面的内容展开。
  另外,我要大家了解的是,我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他自己的需求,而太极公司的需求分析有可以进一步深挖的可能。
   12306核心需求及模块分析
  整体架构没法子设计,太大了。有兴趣的可以参考
  中国铁路客票发售和预订系统5_0版的研究与实现
  国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操作说明
  目前我专注的是用于订票的部分。我感觉这个是最重要的部分。
  12306最大的问题,就是如何在订票的时候高效率得并且适当优化得找到需要数量的车票。并且要能彻底保证一张票不会被两个请求同时处理成功。
  只要这个问题无法彻底解决,任何分布式处理,最终都会卡在这个问题上。
  我会涉及到的模块
12306票务处理功能模块分析
  假想完整网络订票流程图
  这里实际的用户和系统的交互有4种类型。
  1、车次和余额查询
  2、订票
  3、取消订票
  4、确认订票
  这里希望广大围观群众都来评估一下这个假设的订票流程及其参数是不是都合理?如果这个流程本身不合理,则我后续的分析都要重写了。不熟悉售票流程的,可以看看我之前的分析文章。
  然后我们继续来细化一下
   车次和余额查询
  输入:起始站,终到站,日期,座位类型集合
  输出:车次,对应座位类型可售余额
  作用:最终用户根据查询结果选择需要出行的车次,并进一步进入订票操作。但是系统不保证显示为有票的车次在下一步操作中必然有票。
  这里其实涉及到两个类型的查询
  1、哪些车次符合用户的查询结果,可以通过一个基本固定不变的数据源来提供。而该数据源可以实现分布式缓存以缓解查询压力,甚至可以考虑客户端部分结果缓存。
  输入:起始站,终到站,日期
  输出 :车次列表,
  2、特定车次,特定座位类型的可售票数量。这个数据的来源应该和第一个查询不同。
  输入:起始站,终到站,车次,日期
  输出:数量
   订票(我喜欢称它为锁票)
  输入:起始站,终到站,日期,座位类型,需要车票数量,用户ID
  输出:实际到的获取车票数量
  作用:最终用户通过订票操作,顺利锁定需要数量的车票。系统保证用户在规定的时间段内对这几张车票具有优先订购权利,且其他人不得购买这些车票。
  目前我感觉留给用户10-15分钟时间继续后续操作,以进入支付环节(当然,这必须是在系统本身性能良好条件下。否则点个按钮就要等10分钟,那就不对了。)
  同时如果超时,则系统会在后续订票操作中忽视该锁定状态。
   取消订票
  输入:起始站,终到站,日期,座位类型,数量,用户ID
  输出:成功标志
  作用:用户放弃已经获得的被锁定的售票权利,系统恢复对应的数据为可售。
   确认订票(确认支付)
  输入:起始站,终到站,日期,座位类型,数量,用户ID,支付相关信息
  输出:成功标志/确认失败(刚好锁定超时,且被他人订走)
  作用:最终确认售票,系统向第三方支付服务提交确认请求。

最新内容请见作者的GitHub页:http://qaseven.github.io/
相关文章
|
5天前
|
SQL 运维 BI
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
浙江霖梓早期基于 Apache Doris 进行整体架构与表结构的重构,并基于湖仓一体和查询加速展开深度探索与实践,打造了 Doris + Paimon 的实时/离线一体化湖仓架构,实现查询提速 30 倍、资源成本节省 67% 等显著成效。
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
|
20天前
|
机器学习/深度学习 安全 算法
十大主流联邦学习框架:技术特性、架构分析与对比研究
联邦学习(FL)是保障数据隐私的分布式模型训练关键技术。业界开发了多种开源和商业框架,如TensorFlow Federated、PySyft、NVFlare、FATE、Flower等,支持模型训练、数据安全、通信协议等功能。这些框架在灵活性、易用性、安全性和扩展性方面各有特色,适用于不同应用场景。选择合适的框架需综合考虑开源与商业、数据分区支持、安全性、易用性和技术生态集成等因素。联邦学习已在医疗、金融等领域广泛应用,选择适配具体需求的框架对实现最优模型性能至关重要。
285 79
十大主流联邦学习框架:技术特性、架构分析与对比研究
|
1月前
|
测试技术 双11 开发者
一文分析架构思维之建模思维
软件里的要素不是凭空出现的,都是源于实际的业务。本文从软件设计本源到建模案例系统的介绍了作者对于建模的思维和思考。
|
2月前
|
机器学习/深度学习 存储 人工智能
基于AI的实时监控系统:技术架构与挑战分析
AI视频监控系统利用计算机视觉和深度学习技术,实现实时分析与智能识别,显著提升高风险场所如监狱的安全性。系统架构包括数据采集、预处理、行为分析、实时决策及数据存储层,涵盖高分辨率视频传输、图像增强、目标检测、异常行为识别等关键技术。面对算法优化、实时性和系统集成等挑战,通过数据增强、边缘计算和模块化设计等方法解决。未来,AI技术的进步将进一步提高监控系统的智能化水平和应对复杂安全挑战的能力。
|
3月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
3月前
|
运维 NoSQL Java
后端架构演进:微服务架构的优缺点与实战案例分析
【10月更文挑战第28天】本文探讨了微服务架构与单体架构的优缺点,并通过实战案例分析了微服务架构在实际应用中的表现。微服务架构具有高内聚、低耦合、独立部署等优势,但也面临分布式系统的复杂性和较高的运维成本。通过某电商平台的实际案例,展示了微服务架构在提升系统性能和团队协作效率方面的显著效果,同时也指出了其带来的挑战。
120 4
|
4月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
338 1
|
5月前
|
存储 监控 安全
SaaS业务架构:业务能力分析
【9月更文挑战第20天】在数字化时代,软件即服务(SaaS)模式逐渐成为企业软件解决方案的首选。SaaS 业务架构设计对于提供高效、可靠的服务至关重要。其核心业务能力包括:用户管理(注册登录、角色权限)、数据管理(存储备份、安全共享)、业务流程管理(设计定制、工作流自动化)、应用集成(第三方应用、移动应用)及客户服务(支持培训、反馈改进)。通过优化这些能力,可为企业提供更高效、可靠的 SaaS 服务。
101 11
|
5月前
|
安全 数据处理 数据安全/隐私保护
C/S架构与B/S架构的适用场景分析
C/S架构(客户端/服务器架构)与B/S架构(浏览器/服务器架构)在适用场景上各有特点,主要取决于应用的具体需求、用户群体、系统维护成本、跨平台需求等因素。
425 6
|
5月前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。

热门文章

最新文章