w******f
发帖数: 620 | 1 我碰巧是在这两个领域都做过，app 层在A做AWS EC2 DynamoDB, 系统层做kindle 和
kindle fire. 我觉得大家要有肚量，没有一个人是什么领域都牛B，没有一种办法对所
有的问题都最优。
如果说是春运的订票出票是象老魏说的那样高耦合，魏老师的办法显然要好，说到底分
布式还是不能把高耦合的东西分开，所以瓶颈还是在单机的处理速度。 |
b*******s
发帖数: 5216 | 2 这个结论靠谱
【在 w******f 的大作中提到】
: 我碰巧是在这两个领域都做过，app 层在A做AWS EC2 DynamoDB, 系统层做kindle 和
: kindle fire. 我觉得大家要有肚量，没有一个人是什么领域都牛B，没有一种办法对所
: 有的问题都最优。
: 如果说是春运的订票出票是象老魏说的那样高耦合，魏老师的办法显然要好，说到底分
: 布式还是不能把高耦合的东西分开，所以瓶颈还是在单机的处理速度。
|
m*******l
发帖数: 12782 | 3 明明是C++和JAVA斗法
【在 w******f 的大作中提到】
: 我碰巧是在这两个领域都做过，app 层在A做AWS EC2 DynamoDB, 系统层做kindle 和
: kindle fire. 我觉得大家要有肚量，没有一个人是什么领域都牛B，没有一种办法对所
: 有的问题都最优。
: 如果说是春运的订票出票是象老魏说的那样高耦合，魏老师的办法显然要好，说到底分
: 布式还是不能把高耦合的东西分开，所以瓶颈还是在单机的处理速度。
|
g*****g
发帖数: 34805 | 4 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
张，
没有什么不行的。
【在 w******f 的大作中提到】
: 我碰巧是在这两个领域都做过，app 层在A做AWS EC2 DynamoDB, 系统层做kindle 和
: kindle fire. 我觉得大家要有肚量，没有一个人是什么领域都牛B，没有一种办法对所
: 有的问题都最优。
: 如果说是春运的订票出票是象老魏说的那样高耦合，魏老师的办法显然要好，说到底分
: 布式还是不能把高耦合的东西分开，所以瓶颈还是在单机的处理速度。
|
N******K
发帖数: 10202 | 5 爪哇程序猿被魏老师打的头破血流
【在 m*******l 的大作中提到】
: 明明是C++和JAVA斗法
|
N******K
发帖数: 10202 | 6 你这个分票方法很弱
记得以前铁路售票窗口也是这样人肉分票的 一个人排队到了窗口 售票员告诉这个人
没票了 但是另外的窗口有票 要是这个人有ak 绝对就把售票员突突了
如果这个人知道是你设计的系统 绝对把你突突了
1000
【在 g*****g 的大作中提到】
: 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
: 张，
: 没有什么不行的。
|
g*****g
发帖数: 34805 | 7 可惜技术不是打嘴炮，对于质疑的处理大家想必看见了。
【在 N******K 的大作中提到】
: 爪哇程序猿被魏老师打的头破血流
|
f****4
发帖数: 1359 | 8 不靠谱，我们讨论了这么多个来回了。你分得越多，复杂度越上去；等待时间相应增加。
你给一个高耦合的分布式成功案例看看。
1000
【在 g*****g 的大作中提到】
: 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
: 张，
: 没有什么不行的。
|
w******f
发帖数: 620 | 9 这样分是可以，但是牺牲了一定的公平性。 另外一趟车可能有很多站，这样又多了很多
组合，需要分的就更细，组合之间又有关联，如果全国人民都集中抢某一段的票，你又
不能很准确的预测是抢哪一地段的票，还是会有瓶颈。AWS虽然是可以动态scale up,
但是也是需要反应时间的。
1000
【在 g*****g 的大作中提到】
: 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
: 张，
: 没有什么不行的。
|
l*****9
发帖数: 9501 | 10 弱智分法
一个车次肯定一起处理，事实上每个单机都会处理许多车次
我毛估一下，处理量是10万车次量级的，估计要用5000量级的单机并行处理
1000
【在 g*****g 的大作中提到】
: 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
: 张，
: 没有什么不行的。
|
|
|
g*****g
发帖数: 34805 | 11 淘宝就是呀，我说了，你买电脑可以同时买尿布，就是个概率问题。
总归这么多人，这么多票，订单有哪些票的耦合，这些都是有历史数据。
你要说一个合理划分不存在，本身就是不合理的。我不断言该怎么分，但我可以
断言可以分。
分布式本来就是复杂度高，都单机都解决，找魏老师就好了，要我这种做架构的干嘛？
加。
【在 f****4 的大作中提到】
: 不靠谱，我们讨论了这么多个来回了。你分得越多，复杂度越上去；等待时间相应增加。
: 你给一个高耦合的分布式成功案例看看。
:
: 1000
|
g*****g
发帖数: 34805 | 12 你也够弱智的，春运有10万车次吗？就算有票是同天出来的吗？
【在 l*****9 的大作中提到】
: 弱智分法
: 一个车次肯定一起处理，事实上每个单机都会处理许多车次
: 我毛估一下，处理量是10万车次量级的，估计要用5000量级的单机并行处理
:
: 1000
|
x****d
发帖数: 1766 | 13 现在人家的app server运行正常是不是事实？
分票绝对没有问题，公平与否在于怎么包装。分票这个问题不全在技术。
所以我还是说要上rest api，你的app/网站有票（分到票了），就有销量/流量，你能
处理过来活该你赚钱，你也理应给我付费使用api。我铁道部管好票源。用rest api分
票，做的好，前端谁能感觉到，多卖多分，少卖少分。
up,
【在 w******f 的大作中提到】
: 这样分是可以，但是牺牲了一定的公平性。 另外一趟车可能有很多站，这样又多了很多
: 组合，需要分的就更细，组合之间又有关联，如果全国人民都集中抢某一段的票，你又
: 不能很准确的预测是抢哪一地段的票，还是会有瓶颈。AWS虽然是可以动态scale up,
: 但是也是需要反应时间的。
:
: 1000
|
s*****V
发帖数: 21731 | 14 车票要复杂多了，有直达票，还有中途多次停车的，还有大量跨区的票。
1000
【在 g*****g 的大作中提到】
: 淘宝能分，自然车票也能分。最通用的就是分票，一车次1万张，10个数据库每个1000
: 张，
: 没有什么不行的。
|
l*****9
发帖数: 9501 | 15 哈，1万步笑10步的来了。我不知道准确的车次，但是我至少没有弱智如你那样同一车
次的票分开
【在 g*****g 的大作中提到】
: 你也够弱智的，春运有10万车次吗？就算有票是同天出来的吗？
|
g*****g
发帖数: 34805 | 16 请问这个跟分票啥关系？
【在 s*****V 的大作中提到】
: 车票要复杂多了，有直达票，还有中途多次停车的，还有大量跨区的票。
:
: 1000
|
g*****g
发帖数: 34805 | 17 你倒是说说为啥不能分？
【在 l*****9 的大作中提到】
: 哈，1万步笑10步的来了。我不知道准确的车次，但是我至少没有弱智如你那样同一车
: 次的票分开
|
w******f
发帖数: 620 | 18 淘宝好分，应为不同的产品就是不同的分类，淘宝上没有出现象春运车票这样的资源，
集中在短时间，大量的买家抢票。
如果把车票预先分好，按时间，车次，同时在同一车次内最大限度的去掉关联，比如说
从北京到上海的全程票多少，区域
票多少，相互间没有动态关联，同时堆积后面数据库的数量，这个问题是可以按照你的
方法解决。关键就看成本和维护费用。
【在 g*****g 的大作中提到】
: 淘宝就是呀，我说了，你买电脑可以同时买尿布，就是个概率问题。
: 总归这么多人，这么多票，订单有哪些票的耦合，这些都是有历史数据。
: 你要说一个合理划分不存在，本身就是不合理的。我不断言该怎么分，但我可以
: 断言可以分。
: 分布式本来就是复杂度高，都单机都解决，找魏老师就好了，要我这种做架构的干嘛？
:
: 加。
|
l*****9
发帖数: 9501 | 19 铁道部卖票网站可以帮助客户设计转车吗？这个真的难了很多。我觉着可以让用户自己
输入多段车票，虽然不如人肉服务，也可以接受了
【在 s*****V 的大作中提到】
: 车票要复杂多了，有直达票，还有中途多次停车的，还有大量跨区的票。
:
: 1000
|
g*****g
发帖数: 34805 | 20 我不提了另外一种分法。10个数据库平均分票。你该转车还转车。淘宝11/11一天300亿
交易，
肯定秒了春运。
【在 w******f 的大作中提到】
: 淘宝好分，应为不同的产品就是不同的分类，淘宝上没有出现象春运车票这样的资源，
: 集中在短时间，大量的买家抢票。
: 如果把车票预先分好，按时间，车次，同时在同一车次内最大限度的去掉关联，比如说
: 从北京到上海的全程票多少，区域
: 票多少，相互间没有动态关联，同时堆积后面数据库的数量，这个问题是可以按照你的
: 方法解决。关键就看成本和维护费用。
|
|
|
s*****V
发帖数: 21731 | 21 定一个旅程，很可能要出多张票，你要同时得到好几个数据库的最新DATA。
【在 g*****g 的大作中提到】
: 请问这个跟分票啥关系？
|
l*****9
发帖数: 9501 | 22 单车次内有强耦合问题。一个车次就算一万张票，单机处理也不成问题，显然要按车次
来分。
【在 g*****g 的大作中提到】
: 你倒是说说为啥不能分？
|
s*****V
发帖数: 21731 | 23 按什么东西分票？车次？票号？
【在 g*****g 的大作中提到】
: 我不提了另外一种分法。10个数据库平均分票。你该转车还转车。淘宝11/11一天300亿
: 交易，
: 肯定秒了春运。
|
g*****g
发帖数: 34805 | 24 按数目平分票，改出多张票就出多张票。等票出得差不多了还可以合库。
关键是余票库操作不是由用户直接发起的，灵活度很高。你要转车，要出多票，有啥不
行？
【在 s*****V 的大作中提到】
: 定一个旅程，很可能要出多张票，你要同时得到好几个数据库的最新DATA。
|
f****4
发帖数: 1359 | 25 淘宝的是低耦合的
买电脑必须同时买尿布这才是高耦合
【在 g*****g 的大作中提到】
: 淘宝就是呀，我说了，你买电脑可以同时买尿布，就是个概率问题。
: 总归这么多人，这么多票，订单有哪些票的耦合，这些都是有历史数据。
: 你要说一个合理划分不存在，本身就是不合理的。我不断言该怎么分，但我可以
: 断言可以分。
: 分布式本来就是复杂度高，都单机都解决，找魏老师就好了，要我这种做架构的干嘛？
:
: 加。
|
s*****V
发帖数: 21731 | 26 淘宝你买了电脑，没买到尿布不是问题，如果你转三趟车，中间一趟没买到，两头买到
了不要哭死。
【在 g*****g 的大作中提到】
: 淘宝就是呀，我说了，你买电脑可以同时买尿布，就是个概率问题。
: 总归这么多人，这么多票，订单有哪些票的耦合，这些都是有历史数据。
: 你要说一个合理划分不存在，本身就是不合理的。我不断言该怎么分，但我可以
: 断言可以分。
: 分布式本来就是复杂度高，都单机都解决，找魏老师就好了，要我这种做架构的干嘛？
:
: 加。
|
g*****g
发帖数: 34805 | 27 那我平均分票，不就是没啥耦合了。能不能不那么死脑筋。
【在 f****4 的大作中提到】
: 淘宝的是低耦合的
: 买电脑必须同时买尿布这才是高耦合
|
m*******l
发帖数: 12782 | 28 终于有个考普的贴子
【在 s*****V 的大作中提到】
: 淘宝你买了电脑，没买到尿布不是问题，如果你转三趟车，中间一趟没买到，两头买到
: 了不要哭死。
|
l*****9
发帖数: 9501 | 29 订买分开，设定时间订票作废
【在 s*****V 的大作中提到】
: 淘宝你买了电脑，没买到尿布不是问题，如果你转三趟车，中间一趟没买到，两头买到
: 了不要哭死。
|
t*******y
发帖数: 1289 | 30 当初上系统就是为了能最大化的满足乘客需求，而不浪费资源，原来的分票制度是有一
定问题的，想坐车的买不到票了，有票的地段没人买。还有就是希望能通过总体的控制
，达到资源最大化利用。好比有人只坐到中途，那他下车后就空出资源了，可以再利用
。而且是为了能任何地方买任意的票，从而实现和汽车，飞机交通的联动。你们这样一
分票，是不是又回到老路上去了？ |
|
|
g*****g
发帖数: 34805 | 31 处理数据库是支持transaction的，一段没了，你一张都买不下来，不会出现这个问题。
【在 s*****V 的大作中提到】
: 淘宝你买了电脑，没买到尿布不是问题，如果你转三趟车，中间一趟没买到，两头买到
: 了不要哭死。
|
g*****g
发帖数: 34805 | 32 当然不一样，这是个动态的过程，票卖没了，可以自动调整数据库。比如K50 1号数据
库没了，
10号数据库有100张，难道我就不能写个监控程序分50张过来？
【在 t*******y 的大作中提到】
: 当初上系统就是为了能最大化的满足乘客需求，而不浪费资源，原来的分票制度是有一
: 定问题的，想坐车的买不到票了，有票的地段没人买。还有就是希望能通过总体的控制
: ，达到资源最大化利用。好比有人只坐到中途，那他下车后就空出资源了，可以再利用
: 。而且是为了能任何地方买任意的票，从而实现和汽车，飞机交通的联动。你们这样一
: 分票，是不是又回到老路上去了？
|
l*****9
发帖数: 9501 | 33 同一车次单机处理
【在 t*******y 的大作中提到】
: 当初上系统就是为了能最大化的满足乘客需求，而不浪费资源，原来的分票制度是有一
: 定问题的，想坐车的买不到票了，有票的地段没人买。还有就是希望能通过总体的控制
: ，达到资源最大化利用。好比有人只坐到中途，那他下车后就空出资源了，可以再利用
: 。而且是为了能任何地方买任意的票，从而实现和汽车，飞机交通的联动。你们这样一
: 分票，是不是又回到老路上去了？
|
N******K
发帖数: 10202 | 34 爪哇程序猿根本考虑不到这些 这个所谓的分票 以前铁道部就搞 骂声一片
【在 t*******y 的大作中提到】
: 当初上系统就是为了能最大化的满足乘客需求，而不浪费资源，原来的分票制度是有一
: 定问题的，想坐车的买不到票了，有票的地段没人买。还有就是希望能通过总体的控制
: ，达到资源最大化利用。好比有人只坐到中途，那他下车后就空出资源了，可以再利用
: 。而且是为了能任何地方买任意的票，从而实现和汽车，飞机交通的联动。你们这样一
: 分票，是不是又回到老路上去了？
|
N******K
发帖数: 10202 | 35 哈哈 动态调整资源 要调整的多了 你怎么设计这个算法 复杂度如何 ？
资源调整过程中 会不会死循环？
【在 g*****g 的大作中提到】
: 当然不一样，这是个动态的过程，票卖没了，可以自动调整数据库。比如K50 1号数据
: 库没了，
: 10号数据库有100张，难道我就不能写个监控程序分50张过来？
|
s*****V
发帖数: 21731 | 36 所以说还是要多车次放在一起搞
题。
【在 g*****g 的大作中提到】
: 处理数据库是支持transaction的，一段没了，你一张都买不下来，不会出现这个问题。
|
t*******y
发帖数: 1289 | 37 不同意，你这个动态调整要有一个阈值的，不能等到票卖没了才调整，而且确实存在联
票的耦合问题。
好比我买 a -> b -> c
a->b的在一个数据库查询有，c的分票到几个不同的数据库，这个是不是要把所有的都
查一遍，还是随机选择一个？
我觉的反而不是分票的问题，是流量分流的问题，在后面是分流后的同步问题。
我觉得你说的分票不准确。
同时非常不同意用淘宝来比较，那个是有很长的交易后的货物准备期的，售后可调整。
车票这个绝对不能卖出去再说的。一定当时就有。
【在 g*****g 的大作中提到】
: 当然不一样，这是个动态的过程，票卖没了，可以自动调整数据库。比如K50 1号数据
: 库没了，
: 10号数据库有100张，难道我就不能写个监控程序分50张过来？
|
N******K
发帖数: 10202 | 38 我早说过 要分票 就得同车次单机处理
【在 l*****9 的大作中提到】
: 同一车次单机处理
|
g*****g
发帖数: 34805 | 39 这有啥复杂度，我每个车次一个线程专门负责。10个数据库。
每秒poll一次，看到票快见底了就调整。distributed transaction负责Integrity。
【在 N******K 的大作中提到】
: 哈哈 动态调整资源 要调整的多了 你怎么设计这个算法 复杂度如何 ？
: 资源调整过程中 会不会死循环？
|
N******K
发帖数: 10202 | 40 你先说说单机上负责多少个车次
【在 g*****g 的大作中提到】
: 这有啥复杂度，我每个车次一个线程专门负责。10个数据库。
: 每秒poll一次，看到票快见底了就调整。distributed transaction负责Integrity。
|
|
|
g*****g
发帖数: 34805 | 41 我当然不会卖没了才调整，我可以等快卖没了才调整。出票的是后台异步处理程序，
该等调整就等调整，又没有延迟问题。
【在 t*******y 的大作中提到】
: 不同意，你这个动态调整要有一个阈值的，不能等到票卖没了才调整，而且确实存在联
: 票的耦合问题。
: 好比我买 a -> b -> c
: a->b的在一个数据库查询有，c的分票到几个不同的数据库，这个是不是要把所有的都
: 查一遍，还是随机选择一个？
: 我觉的反而不是分票的问题，是流量分流的问题，在后面是分流后的同步问题。
: 我觉得你说的分票不准确。
: 同时非常不同意用淘宝来比较，那个是有很长的交易后的货物准备期的，售后可调整。
: 车票这个绝对不能卖出去再说的。一定当时就有。
|
g*****g
发帖数: 34805 | 42 单数据库负责所有车次，1/10票。一个或者几个应用，专门负责重新分票。另外有一个
负责出票的应用。
【在 N******K 的大作中提到】
: 你先说说单机上负责多少个车次
|
l*****9
发帖数: 9501 | 43 1。同车次单机处理，事实上单机可以处理多个车次，但是所有车次一个单机是不行的。
2。不管转车，用户分段输入订票要求REQUEST。不够用户友好，但是系统简单很多。
3。订BOOKED 买 PURCHASED 分开，限时BOOKED EXPIRE
【在 N******K 的大作中提到】
: 我早说过 要分票 就得同车次单机处理
|
f****4
发帖数: 1359 | 44 洗洗早点睡去了，mitbbs又不给发工资
魏老师很大一部分原因就吃亏在不熟悉网络争论。
【在 g*****g 的大作中提到】
: 那我平均分票，不就是没啥耦合了。能不能不那么死脑筋。
|
N******K
发帖数: 10202 | 45 你用什么算法保证 订单近似平均的分配到所有单机 从而不造成瓶颈？
【在 g*****g 的大作中提到】
: 单数据库负责所有车次，1/10票。一个或者几个应用，专门负责重新分票。另外有一个
: 负责出票的应用。
|
t*******y
发帖数: 1289 | 46 同意你这个调整的思路，这个应该就是典型的分流问题。但是还有一个不明白，你前面
说单机处理同车次（可能不是你说的）这个同车次的票就不分了，对吗？
【在 g*****g 的大作中提到】
: 我当然不会卖没了才调整，我可以等快卖没了才调整。出票的是后台异步处理程序，
: 该等调整就等调整，又没有延迟问题。
|
s*****V
发帖数: 21731 | 47 你这种设计MAKE NONSENSE，客户来说我就是要从黑龙江到乌鲁木齐，中间要过哪里我
那里知道？
的。
【在 l*****9 的大作中提到】
: 1。同车次单机处理，事实上单机可以处理多个车次，但是所有车次一个单机是不行的。
: 2。不管转车，用户分段输入订票要求REQUEST。不够用户友好，但是系统简单很多。
: 3。订BOOKED 买 PURCHASED 分开，限时BOOKED EXPIRE
|
g*****g
发帖数: 34805 | 48 不需要，只要任何一种票都没卖完，就可以继续出票。出完了，可以要求调整。
调整是快卖完做上一次的，不是一直要做的。当票少到了一定数目，
合并到单机处理即可。
总的写的次数是由票的数目决定的，不是由订单数目决定的。
【在 N******K 的大作中提到】
: 你用什么算法保证 订单近似平均的分配到所有单机 从而不造成瓶颈？
|
l*****9
发帖数: 9501 | 49 什么事情都有TRADE OFF
MEGA BUS就这么卖票
【在 s*****V 的大作中提到】
: 你这种设计MAKE NONSENSE，客户来说我就是要从黑龙江到乌鲁木齐，中间要过哪里我
: 那里知道？
:
: 的。
|
g*****g
发帖数: 34805 | 50 我一直说的是，票可以分，有很多种方法，那种最好我不知道。但是没有不能分的道理。
【在 t*******y 的大作中提到】
: 同意你这个调整的思路，这个应该就是典型的分流问题。但是还有一个不明白，你前面
: 说单机处理同车次（可能不是你说的）这个同车次的票就不分了，对吗？
|
|
|
N******K
发帖数: 10202 | 51 如果本着为人民服务的态度来设计系统 就要保证各种联程车票 不能买了首位段的 中
间段的车票没搞到。 这是紧耦合
的。
【在 l*****9 的大作中提到】
: 1。同车次单机处理，事实上单机可以处理多个车次，但是所有车次一个单机是不行的。
: 2。不管转车，用户分段输入订票要求REQUEST。不够用户友好，但是系统简单很多。
: 3。订BOOKED 买 PURCHASED 分开，限时BOOKED EXPIRE
|
N******K
发帖数: 10202 | 52 没错 看来你买过火车票
这种设计就要外加一层进行路径规划
【在 s*****V 的大作中提到】
: 你这种设计MAKE NONSENSE，客户来说我就是要从黑龙江到乌鲁木齐，中间要过哪里我
: 那里知道？
:
: 的。
|
l*****9
发帖数: 9501 | 53 BOOKED AND PURCHASED 分步，首尾订了，中间没有，不买就行了
做事情有TRADE OFF，很正常
【在 N******K 的大作中提到】
: 如果本着为人民服务的态度来设计系统 就要保证各种联程车票 不能买了首位段的 中
: 间段的车票没搞到。 这是紧耦合
:
: 的。
|
s*****V
发帖数: 21731 | 54 当然可以，但是还要搞个后台调度，搞不好就成了新的瓶颈。
理。
【在 g*****g 的大作中提到】
: 我一直说的是，票可以分，有很多种方法，那种最好我不知道。但是没有不能分的道理。
|
l*****9
发帖数: 9501 | 55 还有同伴耦合呢，要不要搞？咱先做个工作的应用，再一步步完美好么？
【在 N******K 的大作中提到】
: 如果本着为人民服务的态度来设计系统 就要保证各种联程车票 不能买了首位段的 中
: 间段的车票没搞到。 这是紧耦合
:
: 的。
|
l*****9
发帖数: 9501 | 56 路径规划可以等到3。0
【在 N******K 的大作中提到】
: 没错 看来你买过火车票
: 这种设计就要外加一层进行路径规划
|
z****e
发帖数: 54598 | 57 孺子可教
一学就会
【在 l*****9 的大作中提到】
: 路径规划可以等到3。0
|
N******K
发帖数: 10202 | 58 比如 三趟车票 A B C 对应三个路线
铁道部发票比例是 1:1:1
搞一个 1/3：1/3:1/3 比例放在三台单机
假设1：实际需求比例 是 1：1：1
要尽量减少单机之间票源交换 就要引导三个车票的用户平均分配到三台单机 否则频
繁的单机之间的票源交换 对用户来讲就是”系统死机“ 啥反应都没有
单机太多 发票不成比例 就会造成很多的再分配 极端情况就是 每个单机对应每一个车
次都只有一张票 第一次售票后 就会马上进行票源再分配 单机数量多少是个最优值？
假设2：实际需求比例 是 1：2：1
指定的车票计划不一定符合实际 春运的时候 是要进行运力调度的 某些路线要加开 也
就是各种票比例要调节 各个路线也要调节 怎么一边进行卖票 一边进行动态规划？
分布式系统的动态规划算法如何设计？ 单机是否能支持这种算法？
【在 g*****g 的大作中提到】
: 不需要，只要任何一种票都没卖完，就可以继续出票。出完了，可以要求调整。
: 调整是快卖完做上一次的，不是一直要做的。当票少到了一定数目，
: 合并到单机处理即可。
: 总的写的次数是由票的数目决定的，不是由订单数目决定的。
|
g*****g
发帖数: 34805 | 59 这就可以了，分库是要看具体数据的。没有历史数据都是不靠谱的，只能提供思路，
不能说哪个最好。在这里谈架构，说到可以分就可以了。
【在 s*****V 的大作中提到】
: 当然可以，但是还要搞个后台调度，搞不好就成了新的瓶颈。
:
: 理。
|
g*****g
发帖数: 34805 | 60 订单本来就是按照车次或者头张票车次)排不同queue的，我就是简单的round
robin，也不会出现你这么多调整的要求。
最重要的我再说一遍，没有用户，出票的是后台处理订单的程序。所有的票，一个车次
一个线程也够了。
【在 N******K 的大作中提到】
: 比如 三趟车票 A B C 对应三个路线
: 铁道部发票比例是 1:1:1
: 搞一个 1/3：1/3:1/3 比例放在三台单机
: 假设1：实际需求比例 是 1：1：1
: 要尽量减少单机之间票源交换 就要引导三个车票的用户平均分配到三台单机 否则频
: 繁的单机之间的票源交换 对用户来讲就是”系统死机“ 啥反应都没有
: 单机太多 发票不成比例 就会造成很多的再分配 极端情况就是 每个单机对应每一个车
: 次都只有一张票 第一次售票后 就会马上进行票源再分配 单机数量多少是个最优值？
: 假设2：实际需求比例 是 1：2：1
: 指定的车票计划不一定符合实际 春运的时候 是要进行运力调度的 某些路线要加开 也
|
|
|
N******K
发帖数: 10202 | 61 你没看懂我说的东西‘
【在 g*****g 的大作中提到】
: 订单本来就是按照车次或者头张票车次)排不同queue的，我就是简单的round
: robin，也不会出现你这么多调整的要求。
: 最重要的我再说一遍，没有用户，出票的是后台处理订单的程序。所有的票，一个车次
: 一个线程也够了。
|
g*****g
发帖数: 34805 | 62 是你没看懂架构，单车次都可以是单线程处理了，哪里有那么多资源需要竞争？
又不是客户发起的。
【在 N******K 的大作中提到】
: 你没看懂我说的东西‘
|
N******K
发帖数: 10202 | 63 我说的是两件事
1. 票源再分配 单机的A票卖光 就要进行再申请重新分配A票 这个也是耗时耗力的事
情 你别搞一个忽略不计就搪塞过去 用户可是在等着呢
2. 分布式系统 怎么搞动态规划 支持运力动态调整
分布式系统的数据的收集分析 比 魏老师的单机系统 更耗时间
你别来一个mapreduce就搪塞过去
【在 g*****g 的大作中提到】
: 是你没看懂架构，单车次都可以是单线程处理了，哪里有那么多资源需要竞争？
: 又不是客户发起的。
|
n****1
发帖数: 1136 | 64 淘宝是粥多僧少,多少订单他们都可以fulfill,当然可以随便分.可是车票是僧多粥少,
大部分人都以失败告终的,这种分法难免惹非议吧.
【在 g*****g 的大作中提到】
: 淘宝就是呀，我说了，你买电脑可以同时买尿布，就是个概率问题。
: 总归这么多人，这么多票，订单有哪些票的耦合，这些都是有历史数据。
: 你要说一个合理划分不存在，本身就是不合理的。我不断言该怎么分，但我可以
: 断言可以分。
: 分布式本来就是复杂度高，都单机都解决，找魏老师就好了，要我这种做架构的干嘛？
:
: 加。
|
g*****g
发帖数: 34805 | 65 一台机器1000张票，到100张票我调整一次，90%的票都已经卖掉了。等待的不是客户，
是处理程序。写数据库的次数是票的张数，不是订单数目。
这算什么复杂的动态规划，低于threshold (比如100)，把最高的和最低的平均一下，
这有啥难度？当一个车次所有的票加起来低于1000，都放在一个库上，不也就跟初始一
样多而已。最多写1000次没了。
【在 N******K 的大作中提到】
: 我说的是两件事
: 1. 票源再分配 单机的A票卖光 就要进行再申请重新分配A票 这个也是耗时耗力的事
: 情 你别搞一个忽略不计就搪塞过去 用户可是在等着呢
: 2. 分布式系统 怎么搞动态规划 支持运力动态调整
: 分布式系统的数据的收集分析 比 魏老师的单机系统 更耗时间
: 你别来一个mapreduce就搪塞过去
|
N******K
发帖数: 10202 | 66 1、 你这个调整一次花多长时间？ 会不会系统阻塞？
比如 你有 500张A票 500张B票
B票先买完了 这时候还有A票300张 你是否进行调整？
不按照需求比例进行分配车票(其实也根本不知道实际需求) 这种情况非常容易出现
除非你用单机
2、 我说的动态规划不是你说的这个 gps上有交通图 会显示那个地方流量大 那个地
方流量小 同理 铁路也要根据流量进行分配比如加开车次 这里的流量是查票和卖票的
信息
【在 g*****g 的大作中提到】
: 一台机器1000张票，到100张票我调整一次，90%的票都已经卖掉了。等待的不是客户，
: 是处理程序。写数据库的次数是票的张数，不是订单数目。
: 这算什么复杂的动态规划，低于threshold (比如100)，把最高的和最低的平均一下，
: 这有啥难度？当一个车次所有的票加起来低于1000，都放在一个库上，不也就跟初始一
: 样多而已。最多写1000次没了。
|
g*****g
发帖数: 34805 | 67 一个分布式transaction，像这样锁不多的，也就是10倍普通交易的时间差不多了。
无关的线路，可以照常进行。也就是1000个线路，一次堵塞了一个线路罢了。
【在 N******K 的大作中提到】
: 1、 你这个调整一次花多长时间？ 会不会系统阻塞？
: 比如 你有 500张A票 500张B票
: B票先买完了 这时候还有A票300张 你是否进行调整？
: 不按照需求比例进行分配车票(其实也根本不知道实际需求) 这种情况非常容易出现
: 除非你用单机
: 2、 我说的动态规划不是你说的这个 gps上有交通图 会显示那个地方流量大 那个地
: 方流量小 同理 铁路也要根据流量进行分配比如加开车次 这里的流量是查票和卖票的
: 信息
|
N******K
发帖数: 10202 | 68 第一个会不会触发链式反应？ 这种不和需求匹配的分配方案 频繁调整是必不可少的
会不会一个调整引起一系列调整？
第二个流量优化问题 你怎么解决？
【在 g*****g 的大作中提到】
: 一个分布式transaction，像这样锁不多的，也就是10倍普通交易的时间差不多了。
: 无关的线路，可以照常进行。也就是1000个线路，一次堵塞了一个线路罢了。
|
g*****g
发帖数: 34805 | 69 第一次调整，某台机器90%这个票都出了。还链式反应。算法我不是大拿，调优可以找
大拿。我提供个基本思路U足够了。
【在 N******K 的大作中提到】
: 第一个会不会触发链式反应？ 这种不和需求匹配的分配方案 频繁调整是必不可少的
: 会不会一个调整引起一系列调整？
: 第二个流量优化问题 你怎么解决？
|
N******K
发帖数: 10202 | 70 A票500张 B票0张 调整门限100张 你调还是不调？
第二个流量优化问题 你怎么解决？ 分布式系统是否支持这样的功能？ 要是不支持 拿
只好枪毙这个方案
【在 g*****g 的大作中提到】
: 第一次调整，某台机器90%这个票都出了。还链式反应。算法我不是大拿，调优可以找
: 大拿。我提供个基本思路U足够了。
|
|
|
g*****g
发帖数: 34805 | 71 b 票 到100就调了好不好。至于优化，故雇几个喜欢琢磨算法的程序猿
来搞好了。
【在 N******K 的大作中提到】
: A票500张 B票0张 调整门限100张 你调还是不调？
: 第二个流量优化问题 你怎么解决？ 分布式系统是否支持这样的功能？ 要是不支持 拿
: 只好枪毙这个方案
|
