F*n
2 楼
这个吵了几年了，今天才有幸翻出来看了看，实话说技术有意思吵得更有意思：）
我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
商搜索应用，也是这个思路。
但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
到）。这个问题不解决，老魏的架构面临一个比较尴尬的局面：抢票机的效率越是BEAT
后台数据库，系统越不好用。这个问题还不好通过提高抢票机和后台之间的同步效率来
解决，因为后台的TRANSACTION是无法实时的，要高度同步只好降低抢票机的效率，那
就跟现成的架构没区别了。
一个解决办法是在抢票机上也实现搜索功能，用户搜索综合后台和抢票机上的结果。但
这个单机就不现实了，因为要处理很多并发搜索。
总之老魏的思路没问题，但是这个单机的抢票节点实际应用中如何有待验证。
我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
商搜索应用，也是这个思路。
但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
到）。这个问题不解决，老魏的架构面临一个比较尴尬的局面：抢票机的效率越是BEAT
后台数据库，系统越不好用。这个问题还不好通过提高抢票机和后台之间的同步效率来
解决，因为后台的TRANSACTION是无法实时的，要高度同步只好降低抢票机的效率，那
就跟现成的架构没区别了。
一个解决办法是在抢票机上也实现搜索功能，用户搜索综合后台和抢票机上的结果。但
这个单机就不现实了，因为要处理很多并发搜索。
总之老魏的思路没问题，但是这个单机的抢票节点实际应用中如何有待验证。
a*y
3 楼
of course
【在 b*******x 的大作中提到】
: 4有没有必要升级啊~~~~
【在 b*******x 的大作中提到】
: 4有没有必要升级啊~~~~
b*s
4 楼
你想多了，或者想少了
b*x
5 楼
不是有人说等一段时间吗，新推出的可能会有些错误啊bug啊之类的？我刚用iphone不
久……嗯
【在 a***y 的大作中提到】
: of course
久……嗯
【在 a***y 的大作中提到】
: of course
d*a
6 楼
总结的精练。
关于抢票机和数据库一致性问题，你再仔细想想，其实在正常情况下不是一个问题。（
和这普通的caching不同。）在正常情况下，如果抢票机说有票，那数据库里就一定有
票；抢票机说没有票，那就是没有票。
正常情况指的是，1) 没有软硬件出错，2) 没有和用户相关的异常，主要是收款不成功
，数据库系统没有出票。前者是小概率事件。后者是用户需求的问题，任何实现都不能
完美。出现第二种情况，抢票机可以很快地收回座位，不会有大的延迟问题。
txn,
【在 F****n 的大作中提到】
: 这个吵了几年了，今天才有幸翻出来看了看，实话说技术有意思吵得更有意思：）
: 我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
: 加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
: persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
: 的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
: 商搜索应用，也是这个思路。
: 但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
: 过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
: 索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
: 数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
关于抢票机和数据库一致性问题，你再仔细想想，其实在正常情况下不是一个问题。（
和这普通的caching不同。）在正常情况下，如果抢票机说有票，那数据库里就一定有
票；抢票机说没有票，那就是没有票。
正常情况指的是，1) 没有软硬件出错，2) 没有和用户相关的异常，主要是收款不成功
，数据库系统没有出票。前者是小概率事件。后者是用户需求的问题，任何实现都不能
完美。出现第二种情况，抢票机可以很快地收回座位，不会有大的延迟问题。
txn,
【在 F****n 的大作中提到】
: 这个吵了几年了，今天才有幸翻出来看了看，实话说技术有意思吵得更有意思：）
: 我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
: 加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
: persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
: 的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
: 商搜索应用，也是这个思路。
: 但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
: 过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
: 索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
: 数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
j*a
7 楼
我反正是升了 不管你升不升
【在 b*******x 的大作中提到】
: 4有没有必要升级啊~~~~
【在 b*******x 的大作中提到】
: 4有没有必要升级啊~~~~
T*i
8 楼
其实数据库可以就是一个book keeping功能。就要他的ACID特性就好了。
退票和抢票一样，都要先经过抢票机。抢票机先更新状态，然后送到数据库。数据库
ACK，退票成功。
查询其实是多个抢票机的hotstandby完成。无限scalable。multicast消息更新状态，
unicast recovery。都是现成的架构。
查询可能会有微秒级别的延迟。但是因为退票很少。即使有延迟，也是查询有票结果抢
不到，很正常。查询就是个pre filter。
这东西，和其他的大型网购网站一样，都是message based。message based system是
唯一靠谱的东西。这里大多数人都意识不到。
【在 d***a 的大作中提到】
: 总结的精练。
: 关于抢票机和数据库一致性问题，你再仔细想想，其实在正常情况下不是一个问题。（
: 和这普通的caching不同。）在正常情况下，如果抢票机说有票，那数据库里就一定有
: 票；抢票机说没有票，那就是没有票。
: 正常情况指的是，1) 没有软硬件出错，2) 没有和用户相关的异常，主要是收款不成功
: ，数据库系统没有出票。前者是小概率事件。后者是用户需求的问题，任何实现都不能
: 完美。出现第二种情况，抢票机可以很快地收回座位，不会有大的延迟问题。
:
: txn,
退票和抢票一样，都要先经过抢票机。抢票机先更新状态，然后送到数据库。数据库
ACK，退票成功。
查询其实是多个抢票机的hotstandby完成。无限scalable。multicast消息更新状态，
unicast recovery。都是现成的架构。
查询可能会有微秒级别的延迟。但是因为退票很少。即使有延迟，也是查询有票结果抢
不到，很正常。查询就是个pre filter。
这东西，和其他的大型网购网站一样，都是message based。message based system是
唯一靠谱的东西。这里大多数人都意识不到。
【在 d***a 的大作中提到】
: 总结的精练。
: 关于抢票机和数据库一致性问题，你再仔细想想，其实在正常情况下不是一个问题。（
: 和这普通的caching不同。）在正常情况下，如果抢票机说有票，那数据库里就一定有
: 票；抢票机说没有票，那就是没有票。
: 正常情况指的是，1) 没有软硬件出错，2) 没有和用户相关的异常，主要是收款不成功
: ，数据库系统没有出票。前者是小概率事件。后者是用户需求的问题，任何实现都不能
: 完美。出现第二种情况，抢票机可以很快地收回座位，不会有大的延迟问题。
:
: txn,
p*n
9 楼
个人感觉还是priceline好用
p*0
10 楼
还在吵呢
txn,
【在 F****n 的大作中提到】
: 这个吵了几年了，今天才有幸翻出来看了看，实话说技术有意思吵得更有意思：）
: 我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
: 加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
: persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
: 的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
: 商搜索应用，也是这个思路。
: 但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
: 过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
: 索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
: 数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
txn,
【在 F****n 的大作中提到】
: 这个吵了几年了，今天才有幸翻出来看了看，实话说技术有意思吵得更有意思：）
: 我觉得老魏的架构不错，没必要意气之争，这个是很好的设计。就像老姜说的，相当于
: 加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
: persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
: 的TXN是很一种很常用的技术，我没做过高频但是做过一个对实时update要求较高的电
: 商搜索应用，也是这个思路。
: 但老魏这个架构在实际应用中估计会碰到一个问题，就是后台搜索和抢票机之间的差异
: 过大。一般异步系统搜索数据和实时数据有一定误差很正常，比如可以直接告诉用户搜
: 索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
: 数据差距可能会很大，导致用户体验极差甚至整个系统无法有效使用（搜到的票都订不
相关阅读
java ---> Kotlin --- > NativeGame over了,兄弟们求介绍一本general programming design 的书．问个spark的问题How to exit Vim?等下午有空我写个机器人意识路线图王垠说的没错 (转载)大而不强，落后与先进的差距怎么快速学习PYTHON到中级水平？ 有做项目的R，Matlab的经验，学过JAVA。Great learning路线图cost a cloud来收钱了超级新手， 求助 python pandas 和pandas_DataReaderCNN里面不用max pooling但是用更大的stride step人性不是一成不变的小札所谓的基本收入会加剧AI的危害。hci, Clojure有类似windows COM那种东西吗？Alpha go退役了Team 以前都是用dot.net的,新项目上.net core 还是golang ?转发个关于演化论的讨论楼王垠造剑 (转载)