以前看有人解决铁道部订票方案的时候，提供的思路。网友评价是：陷入了纯技术思维路子。
仔细想想非常有道理。
这里还是一种调度的思想原则。现实中很多事情像公交车，列车，拥堵的时候进行调度，运作的不错。如果陷入纯技术思维就会是：我如何才能把道路扩宽,让车子更快地通过道路….这些方案都可行。但实际意义要考虑成本与实用性。这种思维可以用到网站技术上去。然后技术作为一种工具，在思想指导下实现(比如代码锁定金额，不能操作等等)。
即便用复杂的技术解决了快速访问，下单的问题，那接下来新的问题来了：
所以还是要限额调度的思想。那个时候我发现，学会相通性思考。把现实中的东西道理带到技术中去。比如现实中解决交通问题的调度思想就完全很好。
之所以归纳总结，今天我在看石展《mysql开发军规》分享一个dba的经验时候，找到了思想的共鸣，他也用交通问题这个例子来说明解决问题的思路：
他举例，说明现实生活在堵车，只要其中一辆车抛锚了，就会导致所有的车都无法前进，被卡死了(本身道路宽度就有限)。所谓一个抛锚拖死全部。
在传统的数据库系统中，是建议，尽量使用更少是sql完成更多是事情。也就是尽量少到使用一条sql实现更多的查询。
但是这个使用原则在mysql中就不适合(我觉得在互联网大并发访问情况下都不适合，不清楚oracle什么情况)，因为mysql被设计成适合高效的连接和断开，响应查询。所以很适合拆分成多条sql去实现。
假设一个情况：在5000个qps中(每秒响应5000个sql请求)，如果一条sql查询超过了一秒，就会导致整个拖慢，就像交通中道路一辆车抛锚了，整个交通都会堵掉。
我曾经在思考这方面：现实生活中，堵车，道路宽度有限。如果单纯依靠扩宽道路来解决交通问题，是解决不了根源问题的，因为道路宽度即便扩宽，也有更多车去拥挤，扩宽是有极限，扩到不能扩了才麻烦(类似于服务器，数据库方面使劲去扩，已经达到极限化了,换种思维模式往往柳暗花明)。我的理解是，无论你把道路扩宽多少，总会有更多的车辆不够用，然后占据车道去了。原来3米，后来变成5米宽。开车的车主仍然会去占据剩下2米的宽度。应该是一种调度思想指导。
我曾经想：坐火车，每到过节车厢就那么拥挤。如果多增加一些车厢了。是不是就不会那么拥挤了。后来我想了想，随便增加多少。仍然会拥挤得满满的。增加更多的车厢，仍然会提供更多的售票，人还是会去买的(毕竟中国人都更加倾向于做火车，因为穷人多，比较经济。高铁的话为什么反而是空空，因为价格贵。火车当然安全也是一大因素。)
网友提到一点，让我印象深刻，那就是：在订票系统没出来之前，现实中的铁路售票系统都足够应付全国范围的售票了。说明这个系统足够应付。只是网络自助售票系统没有解决好调度问题。在怎么往大并发的技术方面去着力，也只是付出与产出不成正比。
把业务模式稍微调整一下，参考现实中已经有的成功例子：交通调度。把这类思想运用，也许发现会更好。
现在也逐渐感悟到技术跟哲学之间的关系。哲学是一种道的层面，思想层面的东西。具体的技术，mysql，java，php等都是具体的术。就是战术与战略之间的关系了。不过我承认还是的多了解一些战术，这样战略才能知道自己制定，这个战略是否能实现
技术工作者，提升到哲学层面才是方向。我发现，同样是技术，有的人，虽然做了7、8年。仍然可能纠结在具体的技术层面。无法上升到思想层面去看待问题。
”这个世界好像没有一个完美的技术解决方案“，好像跟哲学都是相通的。选了a方案，可能失去的是其他方面。总会有失去。有既符合a，b，c的方案很少。比如，数据库设计中，空间换性能，需要提高性能。有时候就要损失一定数据的一致性(不符合三大范式)。
往往都是一个取舍的过程，得到我想要的，然后失去的是我不是非常关注的。
补充一下，后来看这本书《大型网站技术技术架构》提到一点我很认同，现在收藏下来如下：
最典型的例子就是2012年年初12306故障事件后，软件开发技术界的反应。
各种专业和非专业人士众说纷纭地帮12306的技术架构出谋划策，甚至有人提议帮12306写一个开源的网站，解决其大规模并发访问的问题。
12306真正的问题其实不在于它的技术架构，而在于它的业务架构：12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票（零点开始出售若干天后的车票）。12306需要重构的不仅是它的技术架构，更重要的是它的业务架构：调整业务需求，换一种方式卖票，而不要去搞促销秒杀这种噱头的游戏。
后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制，整点售票调整为分时段售票。其实如果能控制住并发访问的量，很多棘手的技术问题也就不是什么问题了。
技术是用来解决业务的问题，而业务的问题，也可以通过业务的手段去解决。
