关于大型票务系统的数据同步问题，请有关经验的大虾帮忙！

wdd89 2015-03-30 06:10:23

一个大型的票务系统，一个客户端是在售票处，同时开放接口给票务网站，爷可以开放给移动服务商或者其他第三方，大家同时卖票，最显著的问题就是数据同步，比方说各个客户端都在卖同一个演唱会的票子，位子A被一个客户端卖了，同时其他客户端就不能卖了，这个数据在服务器是实时同步的吗，如果是实时，对服务器压力是不是很大，如果不是，比如几十分钟同步一次，这样数据一致性就肯定有问题，还是大家分开卖不同位子的票，我从来没涉及过这样的系统，所以请各位有经验的大虾指点迷津！！！
谢谢了！！！

...全文

993 18 打赏收藏转发到动态举报

写回复

用AI写文章

18 条回复

切换为时间正序

请发表友善的回复…

发表回复

zh6335901 2015-06-26

打赏
举报

sp1234大哥的回答让人受益匪浅

sp1234_maJia 2015-06-04

打赏
举报

引用 16 楼 changjiangzhibin 的回复:

简单的处理：保证事务处理，每单有个锁定状态（或其他），防止并发

现在所说的“高并发、秒杀”等等系统，根本不是这种简单的“关系数据库事务”所能比的。这就好像一个是现在实用的电商系统设计，另一个是以前垮掉的、永不起来的小破程序。

changjiangzhibin 2015-06-03

打赏
举报

简单的处理：保证事务处理，每单有个锁定状态（或其他），防止并发

以专业开发人员为伍 2015-05-27

打赏
举报

关于程序员在类似系统中的“排队”概念的分析，这个问题其实也应该是经常出现的争议性的问题，我回答了另一个帖子，请参考：http://bbs.csdn.net/topics/390607959?page=1#post-399265031 排队的意思绝不是技术上的，它不是一种数据结构，而是一个业务逻辑和UI设计问题。

以专业开发人员为伍 2015-05-26

打赏
举报

由于分布式负载均衡，可以保证毫秒内完成 --> 由于分布式负载均衡，可以保证毫级内完成如果第三步”分布式处理“的问题比较难以解决（其实写上100行代码也就能解决了），至少第一步和第二步是比较简单的。第一步，实现了一个SOA思想。第二步，实现了”异步处理“思想（不是异步页面，是后台业务流程的异步处理）。这第三步，则是分布式服务集群的任务调度思想。架构就是这样，只有在一些性能或者功能达到极端情况下时，才会出现真正的架构设计的。整天研究什么架构名词儿，而实际上没有极端性的影响，那种架构概念往往是可以更快被修改的。

以专业开发人员为伍 2015-05-26

打赏
举报

在传统的网页程序中，可能许多人的思路，不但是要反复查询数据库并且最终去修改每一张票的记录，而且要将票进行各种库存、成本计算之后，在购物车之后的一系列后台业务操作完成之后，才在用户订票界面上进行返回。这样页面就会很“卡”。这就是最为“悲观”的事务想法。它不适合长事务操作。更不适合“秒杀、抢票”等操作。实际上，你的系统（仅作极少的必要判断就）如果先出票，然后再延迟200毫秒进行几步后续业务操作（由于分布式负载均衡，可以保证毫秒内完成），能慢多少呢？几乎感觉不到慢。而你的系统的后台操作失败的概率又有多少呢？（万一）出错后能不能有业务流程来弥补呢？这肯定也很容易做到。只要调整设计思路。这类系统，要的不是一段时间内的吞吐量有多大，而是平均每一个请求的响应时间一定要短在300毫秒之内，界面不能“卡”。因此买一个昂贵的IBM服务器、装上昂贵的数据库系统也无济于事，就是用全免费软件就能解决广大草根的秒杀需求问题了。这种就是互联网软件思维。

taz01 2015-05-26

打赏
举报

这么好的帖子没人顶？？？

sp1234_maJia 2015-05-25

打赏
举报

在秒杀、抢购等系统中，有千分之九百九十五以上的请求都是“垃圾请求”。有些人会不断地“点点点”，你的系统越是在第一个环节（还有没有余票，能不能锁定票环节）响应慢，越是会激起额外地几十倍的垃圾刷新操作。因此把好流程的第一关就好了。忘掉传统的数据库，先从系统架构入手去设计。

以专业开发人员为伍 2015-05-25

打赏
举报

引用 4 楼 wdd89 的回复:

[quote=引用 2 楼 starfd 的回复:] 这个怎么可能不统一处理呢？不知道你的票务系统有多大，其实并发并不会有那么高，你可以按位置划分区域，然后同一个区域的进行相关lock

我设想的项目是某个二线城市的电影售票中心，这个城市所有的售票终端，票务网，APP等等都在通过这个系统，并发不算大也不算少，如果是实时的Lock一个区域，能不能具体解释一下？！各位有没有做过这类项目的大侠来阐述一下，谢谢罗！[/quote] 这个不太现实。只有在所有的条件都很“死”的情况下，可能你也不太容易设计出来一个通用而合理又灵活可调的“分区策略”。开发一个真正的“互联网思维的”（而不是传统的局域网小管理软件思维的）业务系统，其实并不复杂。但是在csdn上很少这方面的讨论，主要因为csdn上学生党很多很多，刷屏很厉害 :-)

以专业开发人员为伍 2015-05-25

打赏
举报

基本上只是负责维护两个 HashSet<string> 集合的服务器，你会做么？使用asp.net也是可以的（尽管asp.net并不高效）。因此其实这个道理人人都能懂，关键是能不能去实践的问题。实践了才有体会，而不实践的人总是不相信有时候是自己想得太多了所以才效率低。进一步说，如果你真的是开发一个大型的票务系统，那么你应该能用上（比如说）5台web网站（作为前端，例如支持web UI展现，客户端可以自动寻找一台联网最快的web服务器接入），20台应用服务器作为业务处理（例如处理客户关系数据、财务核算、大数据分析），至少2台数据库服务器（读写分离处理，或者分片且自动备份）。你的程序应该是异步的，例如页面在处理用户请求时，只是对于页面上需要的内容才立刻回复，而其它大部分处理工作都应该是异步并发处理的，甚至是（如果某业务操作晚启动200毫秒也没有关系的话）自动分发到其它比较空闲的服务器上去处理。你的产品经理在要求程序员配合产品人员进行程序开发时如果会做这种简单的启发，就能保证系统朝着高效、安全、可随时水平扩展。这也是常见一个“大型票务系统”的最基础的要求。

以专业开发人员为伍 2015-05-25

打赏
举报

简单来说，你可以在一台服务器端上单独维护2个 hash 集合，一个用来查询票是否被卖出去了、另一个用来查询是否还未卖出。然后这个服务器还有一个功能，就是把一张票从第二个集合移到第一个集合。既然是单独一个服务器，这个服务器别的什么都不干，就是专门干这个的。就算是在“移动票”的操作进行同步加锁，每秒钟处理50万笔交易总是轻轻松松地吧！你的业务能够达到每秒50万事务请求吗？可能达不到。一张票也许有库存，有许有其它许多属性。但是你可以使用这样一个独立的服务把流程的“大门”守住。在售票环节，只要先访问一下这个服务，取得需要的票（同时把票从“未售出”移动到“已售出”集合中），随后就可以把这张票的id放到顾客的购物车中慢慢地处理了（甚至异步、分布式处理了），这里就不设计“抢票”问题了，因为单个货品已经被分配出去。所以关键是这第一步查询票是否已经售出的操作，绝对不能访问数据库，而是访问一个独立的内存机制(而且结构异常简单)。就抗住了。