西西河

主题:【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

共:💬135 🌺246
全看分页树展 · 主题 跟帖
家园 你的设计方法是错的

而在于当中间件可用连接数有限的情况下,应当使每个用户尽快完成交易。

这个是设计原则,正确。

我认为目前的售票系统网银支付方法是阻碍用户在短时间内完成交易的主要瓶颈。

这个分析是错误的。事实上支付前和支付后确认在本地系统看来是两次交易,之间可以无状态。这样间隔多久对系统都没有影响,和中间件也没关系。你把我们人的交易概念和系统的交易概念混淆了。对系统来说点一次查询就是一次交易。提交订单和确认支付是两个独立的交易——至少我设计的所有有支付功能的网站都是这样的。

最终问题都会表现到中间件到db的可用连接数量上

这也是对的,在处理页面请求的时候,我们现在使用数据库都是临时打开连接(用连接池),批量执行,然后立刻关闭连接——即将连接交回连接池。保持数据库连接使用时间尽可能短。但是连接为何会不足,原因通常是查询变慢,就像一条拥挤的车道,前面某辆车稍微减一下速。就会导致后面一段车要停下来一样。当某些查询时间超长,无法迅速归还数据库连接的时候。这时连接数就不够了。因此瓶颈在数据库上,和用户无关。如果所有查询可以在20毫秒内完成,10个连接至少可以支持1000个用户同时查询。

如果12306的网站需要用户缩短支付周期来避免瓶颈,先不说这种设计是否能实现。在设计思路上就是大错特错,无论如何不能把系统性能依赖于用户怎么使用上。尤其是公共网站。

还有,中间件的设计也应该和用户无关,要尽可能做到不受用户会话进程影响无状态编码。这样才可以做到横向扩展和负载均衡。这也是一条基本原则。所以我不怀疑中间件,由于没有足够的情报,我总是先怀疑最大嫌疑者——数据库。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河