发信人: Foxman (今狐冲), 信区: Programming
标 题: TeacherWei 的订票机的问题
发信站: BBS 未名空间站 (Sat Jan 9 02:15:14 2016, 美东)
这个吵了几年了,今天才有幸翻出来看了看,实话说技术有意思吵得更有意思:)
我觉得老魏的架构不错,没必要意气之争,这个是很好的设计。就像老姜说的,相当于
加了个In Memory Cache, 可以减少不必要的后台并行而且这个Cache本身并不需要txn,
persistence, 完蛋了可以从后台reload。实际上这种用smart caching来避免不必要
的TXN是很一种很常用的技术,我没做过高频但是做过一个对实时update要求较高的电
商搜索应用,也是这个思路。
但老魏这个架构在实际应用中估计会碰到一个问题,就是后台搜索和抢票机之间的差异
过大。一般异步系统搜索数据和实时数据有一定误差很正常,比如可以直接告诉用户搜
索的票无法锁定。但按魏老师这个构架如果并发量大后台搜索的数据和抢票机上的实时
数据差距可能会很大,导致用户体验极差甚至整个系统无法有效使用(搜到的票都订不
到)。这个问题不解决,老魏的架构面临一个比较尴尬的局面:抢票机的效率越是BEAT
后台数据库,系统越不好用。这个问题还不好通过提高抢票机和后台之间的同步效率来
解决,因为后台的TRANSACTION是无法实时的,要高度同步只好降低抢票机的效率,那
就跟现成的架构没区别了。
一个解决办法是在抢票机上也实现搜索功能,用户搜索综合后台和抢票机上的结果。但
这个单机就不现实了,因为要处理很多并发搜索。
总之老魏的思路没问题,但是这个单机的抢票节点实际应用中如何有待验证。
Saturday, January 9, 2016
TeacherWei 的订票机的问题
http://www.mitbbs.com/article_t/Programming/31466825.html
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment