程序猿眼中的外环线拥堵

堵车，塞心

一、现象

每周五集卡进堆场，直接导致外环线两边的下匝道堵塞，间接导致了外环线浦东机场方向堵塞，间接导致了中环线五洲大道下匝道堵塞，从而导致了浦西到浦东的交通大拥堵

二、类比

1、进程：外环线、中环线，类似与进程；

2、线程：外环线、中环线的每一根车道，类似与线程；

3、请求：类似与车辆；大致可以将请求分为两类：集卡为时效性较弱的请求，小客车为时效性较高的请求；

4、堆场卸货：类似与一端业务逻辑，是一段消耗资源的业务逻辑，打个比方是存储在低端存储上的海量数据；

5、所以，我们再来看看，上面描述的交通拥堵现象，用技术语言来翻译是怎么样的：

a、每周五，发起了大量的【集卡】请求，要去访问【堆场卸货】的逻辑，但是由于【堆场卸货】逻辑执行效率太低，完全占用了【外环线】进程中原先分派给它用的【3号车道】【4号车道】两个线程，进而占用了【1号车道】【2号车道】两个原先分派给【小客车】的线程，导致了【小客车】请求无法处理；

b、【外环线】进程和【中环线】进程设计上是独立的，但是有进程间通信，且是同步调用，所以【外环线】进程处于瘫痪状态后，也蔓延到了【中环线】的五洲大道段；

三、方案

如果城市的拥堵问题变成了系统的性能问题，我们该怎么样来解决

1、治本方案：核心问题是【堆场卸货】服务的性能问题，究其原因两点：一点是中心化，另外一点是性能差；所以方案是：a、将【堆场卸货】服务设计成分布式；b、优化【堆场卸货】的算法；c、对于【堆场卸货】进行硬件升级，或者纵向扩容；

2、治标方案

a：线程保护：从原先的道路设计上，已经考虑到了【车道】线程的割离，但是主要还是设计上的，要有相关功能的实现。比如有限高杆，比如割离栏，比如密集探头，保证【1号车道】线程 就是处理【小客车】请求的；

b：请求分散：交通拥堵聚焦在每周五，说明由于某种原因导致了在周五【集卡】请求密集，那是否可以采用点手段，将每周五的密集的【集卡请求】分散到一周7天，也能一定程度缓解问题；

作者：up方方土，一个混在金融行业的屌丝程序员，喜欢代码，喜欢咖啡，喜欢旅行